Sebastian Wojczyk wojczyk@math.uni.lodz.pl Inżynieria wymagań Sebastian Wojczyk wojczyk@math.uni.lodz.pl.

Slides:



Advertisements
Podobne prezentacje
Agile w praktyce, czyli jak to robimy naprawdę
Advertisements

2.1. MISJA PRZEDSIĘBIORSTWA I JEGO CELE
SKUTECZNOŚĆ i EFEKTYWNOŚĆ SYSTEMU
Jarosław Kuchta Dokumentacja i Jakość Oprogramowania
Modelowanie przypadków użycia
Projektowanie w cyklu życia oprogramowania
OiZPI Część 4 zarządzanie procesem formułowania wymagań
Charakterystyka systemów zarządzania w przedsiębiorstwie
Analiza ryzyka projektu
Rola komputera w przetwarzaniu informacji.
Referat 3. Planowanie zadań i metody ich obrazowania
zarządzanie produkcją
Projektowanie Aplikacji Komputerowych
Propozycja metodyki nauczania inżynierii oprogramowania
DOKUMENTOWANIE PROCESU ZINTEGROWANEGO
Dokumentowanie wymagań w języku XML
Mapowanie procesów pracy i organizacja stanowisk
Systemy operacyjne Bibliografia:
Problemy organizacji usług publicznych świadczonych drogą elektroniczną wdrażanych przez MSWiA   współpraca między systemami lokalnymi a platformą ePUAP.
Pomiary w inżynierii oprogramowania
Administracja zintegrowanych systemów zarządzania
Jakość systemów informacyjnych (aspekt eksploatacyjny)
Projektowanie i programowanie obiektowe II - Wykład IV
Praca Inżynierska „Analiza i projekt aplikacji informatycznej do wspomagania wybranych zadań ośrodków sportowych” Dyplomant: Marcin Iwanicki Promotor:
Analiza i ocena procesów wdrożeniowych systemów klasy MRP/ERP w firmie
GENERATOR WNIOSKÓW I STUDIUM WYKONALNOŚCI WYBRANE INFORMACJE Wrocław, 22 listopada 2005 r. WOJCIECH WICZKOWSKI Dział Wdrażania Europejskiego Funduszu Rozwoju.
Wykład 2 Cykl życia systemu informacyjnego
Określanie wymagań Inżynieria wymagań
C.d. wstępu do tematyki RUP
SIEĆ P2P 1. Definicja sieci równouprawnionej. To taka sieć, która składa się z komputerów o takim samym priorytecie ważności, a każdy z nich może pełnić.
Elektroniczny Obieg Dokumentów i Elektroniczna Skrzynka Podawcza
Kompleksowe zarządzanie jakością informacji (TIQM)
Schemat przygotowywania wniosku o dofinansowanie zgodnie z założeniami metodyki Zarządzania Cyklem Projektu Metodyka Zarządzania Cyklem Projektu pozwala.
Digitalizacja obiektów muzealnych
Wanda Klenczon Biblioteka Narodowa
Szkolenia, Coaching, PR.
STAĆ CIĘ NA INNOWACJE System CRM w Focus Telecom Polska - cechy i funkcjonalność usługi Autor: Tomasz Paprocki.
POŚREDNIK Jak reprezentowana jest informacja w komputerze? liczby – komputer został wymyślony jako zaawansowane urządzenie służące do wykonywania.
Dr Karolina Muszyńska Na podst.:
Program Operacyjny Kapitał Ludzki
1 Każdy obiekt jest scharakteryzowany poprzez: tożsamość – daje się jednoznacznie wyróżnić; stan; zachowanie. W analizie obiektowej podstawową strukturą
Planowanie przepływów materiałów
Zarządzanie Projektami
1 (21) Modelowanie i opis wymagań Bogdan Bereza – blogomocja.blogspot.com –
Moduł III Definiowanie i planowanie zadań typu P 1.
PROCESY W SYSTEMACH SYSTEMY I PROCESY.
Zarządzanie zagrożeniami
Proces tworzenia oprogramowania Proces tworzenia oprogramowania jest zbiorem czynności i związanych z nimi wyników, które prowadzą do powstania produktu.
Eksploatacja zasobów informatycznych przedsiębiorstwa.
Wdrażanie SYSTEMU Jacek WĘGLARCZYK.
Diagramy przepływu danych
Ocena jakości systemów informacyjnych (aspekt eksploatacyjny)
7/1/ Projektowanie Aplikacji Komputerowych Piotr Górczyński Cykl życia systemu.
Eksploatacja zasobów informatycznych przedsiębiorstwa.
Eksploatacja zasobów informatycznych przedsiębiorstwa.
Zadania Architekta Zespół Architekta.
Logical Framework Approach Metoda Macierzy Logicznej
Moduł e-Kontroli Grzegorz Dziurla.
Joanna Zembaczyńska Departament Zarządzania Europejskim Funduszem Społecznym Europejski Fundusz Społeczny dla małych i średnich przedsiębiorstw 20 września.
Zintegrowane systemy informatyczne
Dobór systemów klasy ERP Prezentacja w Klubie Menedżera Jakości, 19 marzec z uwzględnieniem wymagań normy ISO 9001.
(c) InMoST 2006 Plan szkolenia ▪ Wprowadzenie (9:00-10:30): Czym jest szacowanie? (MO) Systematyczne podejście do planowania (ŁO) Planowanie, a kalendarz.
Inżynieria systemów informacyjnych
Inżynieria Oprogramowania Laboratorium
Projekt modułu BANK INTERNETOWY Moduł funkcji banku
{ Wsparcie informacyjne dla zarządzania strategicznego Tereshkun Volodymyr.
[Nazwa projektu] Analiza zamknięcia
Systemy eksperckie i sztuczna inteligencja
Piotr Jóśko Z-ca Dyrektora
Zapis prezentacji:

Sebastian Wojczyk wojczyk@math.uni.lodz.pl Inżynieria wymagań Sebastian Wojczyk wojczyk@math.uni.lodz.pl

Plan wykładu Podstawowe informacje Cel inżynierii wymagań Trudności w pozyskiwaniu wymagań Sposoby zbierania informacji Opis wymagań Wymagania funkcjonalne Wymagania niefunkcjonalne Sposoby wspomagania opisu wymagań Dokument specyfikacji wymagań klienta Użytkownicy dokumentu specyfikacji wymagań klienta

Podstawowe informacje Inżynieria wymagań – to etap realizacji projektu informatycznego związany z pozyskiwaniem, formułowaniem, analizą i zarządzaniem wymaganiami „klienta”. Etapy inżynierii wymagań: Studium wykonalności, Zebranie i analiza wymagań, Specyfikacja wymagań, Zatwierdzenie specyfikacji wymagań klienta. Niska jakość wymagań: przekonanie, że „programowanie jest najważniejsze!”, brak bezpośredniego efektu w postaci działających funkcji, Klient chce płacić za fizyczne oprogramowanie.

Cel inżynierii wymagań Rozpoznanie dziedziny przedmiotowej projektu, Pozyskiwanie wymagań, Grupowanie, klasyfikacja, Wykrywanie i usuwanie sprzeczności, Priorytetowanie wymagań, Weryfikacja wymagań, Specyfikacja wymagań, Dokumentacja wymagań, Ostatecznie – Specyfikacja Wymagań Klienta

Trudności Cel powstania oprogramowania Terminologia Wymagania ukryte Klient widzi cel, ale nie widzi ścieżki, Możliwe są różnie ścieżki osiągnięcia postawionych celów, Różni użytkownicy mają różne cele. Terminologia Uzgodnienie terminologii, Konieczność pogodzenia informatyków i użytkowników, Konfrontacja odległych grup zawodowych (analitycy, zarządy, kierownictwo, szeregowi pracownicy). Wymagania ukryte Użytkownicy nie są ich świadomi, Powstanie luk w dokumentacji. Niebezpieczeństwo uzyskania subiektywnych opinii

Trudności 2 Zleceniodawcy – cele ogólne Zleceniodawcy decydują – użytkownicy obsługują, Problemy z uwzględnieniem rzeczywistych potrzeb docelowych użytkowników. Użytkownicy – cele i potrzeby szczegółowe Brak motywacji i chęci współpracy, Obawy przed zmianami, Obawa o możliwość utraty pracy, Ukrywanie posiadanej wiedzy praktycznej (świadome lub niezamierzone), Ważność wymagań – moje najważniejsze, Brak spojrzenia na system jako całość.

Pozyskiwania wymagań Oprogramowanie na zamówienie Duże zaangażowanie klienta, Wspólne słownictwo, Iteracyjność procesu, Koszty i czas, Wydobywanie wymagań. Oprogramowanie gotowe Kontakt z potencjalnymi klientami, Analizy rynku, Spotkanie z ekspertami dziedzinowymi.

Sposoby pozyskiwania wymagań – źródła pisane Wszelkie dokumenty wewnętrzne, Opis struktury organizacyjnej firmy, Zakresy obowiązków pracowników, Opisy stanowisk, Dokumentacja użytkowanych systemów informatycznych, Dokumenty generowane z używanych systemów informatycznych, Akty prawne związane z dziedziną przedmiotową.

Sposoby pozyskiwania wymagań - obserwacja Oszacowania/pomiary (ilości dokumentów, klientów), Ilości i częstotliwość napływu danych, Wartości średnie i skrajne, Podział czasu pomiędzy różne czynności, Identyfikacji osób kompetentnych i komunikatywnych – potencjalnych ekspertów, Identyfikacja obecnego obiegu dokumentów (realnego), Identyfikacja powiązań/związków, Identyfikacja źródeł danych (bazy, „zbiory”, „archiwa”), Obserwacja zmienności w obciążeniu pracą.

Sposoby pozyskiwania wymagań - ankiety Tylko gdy to konieczne, Nie mogą służyć innym celom (np. ocenie pracownika), Konieczne zabezpieczenie czasu na ich wypełnienie, Typy pytań Pytania zamknięte, Pytania otwarte, Miejsce na sugestie pracowników.

Sposoby pozyskiwania wymagań – wywiady Od prezesa, do użytkowników bezpośrednich, Konieczność wiedzy merytorycznej, Precyzyjne określenie czasu i tematyki spotkań, Duża ilość czasu (wiele osób), Identyfikacja zagadnień otwartych (rzeczywista rozbudowa a nie odnowienie starego systemu), Konieczny raport/notatka z każdego spotkania Czas i miejsce, Skład osobowy, co ustalono, czego brakuje – ustalenie dodatkowych terminów spotkań i osób kompetentnych Weryfikacja raportu po jego sporządzeniu.

Opis wymagań Zamiana celów na konkretne wymagania, Definicja wymagań jako proces, Ogóle sformułowanie, Doprecyzowanie wymagań, Etapy: Definicja wymagań Ogólny opis w języku naturalnym, Specyfikacja wymagań Ustrukturyzowanie wymagań, Mapa powiązań, Sformalizowane notacje (diagram przypadków użycia) Specyfikacja oprogramowania Formalny opis, ale tylko w planowaniu dużych systemów

Wymagania funkcjonalne Usługi jakie ma oferować system, Spojrzenie z punktu widzenia użytkownika, Sposób reakcji na przykładowe dane wejściowe, Czego system nie powinien robić – odpowiedzialność użytkownika, Odpowiednia gradacja – często zbyt rozdrobnione na szczegółowe przypadki, Nie powinny narzucać sposobu rozwiązania problemów/osiągnięcia celów.

Wymagania niefunkcjonalne Typy wymagań niefunkcjonalnych mierzalnych Szybkość, Rozmiar, Łatwość użytkowania, Niezawodność i bezpieczeństwo, Stabilność, Elastyczność/Przenośność, Typy użytkowników i uprawnienia, Definicja systemów zewnętrznych, Struktury organizacyjne, Przepisy prawne, zarządzenia, statuty, instrukcje, Ograniczenia systemu.

Przykłady wymagań niefunkcjonalnych Szybkość Czas odpowiedzi (pożądany, maksymalny), Rozmiar Ilość użytkowników, urządzeń, Rozmiar danych, Dokładność Precyzja obliczeń i przechowywania danych, Ograniczenia systemu, Realia sprzętowe i komunikacyjne (sieć, wydajność, zabezpieczenia), Ograniczenia systemowe (wersje systemów operacyjnych i innego oprogramowania), Typ interfejsu użytkownika.

Przykłady wymagań niefunkcjonalnych 2 Adaptowalność, Podatność na zmiany, określenie punktów zmian i parametryzacji, Bezpieczeństwo, Zabezpieczenie, Szyfrowanie danych, Autoryzacja, Odporność na awarie, Standardy, Formaty plików, Wersje językowe, Zasoby Ograniczenia finansowe, Zasoby ludzkie, Skala czasowa Harmonogram prac Czas szkoleń, wdrożeń.

Miary wymagań niefunkcjonalnych Szybkość, Ilość transakcji w jednostce czasu, Konkretny maksymalny czas realizacji bardziej złożonych operacji, Czas reakcji (zapisu danych, odświeżenia ekranu), Rozmiar, Kilobajty, Megabajty, Gigabajty, Konkretne wartości liczbowe, Łatwość użytkowania, Czas szkoleń, Liczba punktów pomocy kontekstowej, Liczba samouczków, Niezawodność i bezpieczeństwo, Średni czas bez awarii, Częstość błędów, Automatyzacja i częstotliwość wykonywania kopii zapasowych, Stabilność, Czas uruchomienia kopii systemy Prawdopodobieństwo utraty danych, Elastyczność/Przenośność, Liczba wspieranych systemów operacyjnych, przeglądarek internetowych, Procent funkcji systemu zależny od platformy, środowiska.

Wspomaganie opisu wymagań Jeden obraz wart więcej niż tysiąc słów (przysłowie chińskie). Przejrzystość, Większa ilość informacji, Szybsza percepcja niż w przypadku ciągłego tekstu, Listy i wypunktowania, Ustalenie priorytetów, ważności elementów, Formularze, tabele Kojarzenie użytkowników i funkcji, Powiązania poszczególnych wymagań, Diagramy blokowe – przepływ informacji, Diagramy kontekstowe, Diagramy przypadków użycia, Wszelkie inne schematy i rysunki.

Specyfikacja wymagań klienta – struktura dokumentu Wstęp / Ogólny opis, Słownik, Definicja wymagań funkcjonalnych, Definicja wymagań niefunkcjonalnych, Opis ewolucji systemu, Specyfikacja wymagań funkcjonalnych, Inne Wymagania sprzętowe, Opis istniejącej bazy sprzętowej, Wymagania odnośnie bazy danych, Indeksy spisy (tabel, schematów, kluczowych definicji, itp.)

Specyfikacja wymagań funkcjonalnych Krótki opis funkcjonalności, Wejście, Definicja danych wejściowych, Określenie źródła danych (formularz, import, inna część systemu), Określenie ograniczeń (wartości skrajne, limity, ewentualne typy), Wyjście, Opis zwracanych rezultatów, Sposób ich zwracania (wartość, wydruk, dane w bazie, itp.) Interakcja z innymi częściami systemu, Blokowania działania innych funkcji, Wymuszenia kolejności pewnych funkcji.

Kto i do czego wykorzystuje? Klienci systemu Określają wymagania i weryfikują względem ich potrzeb, Określają ewentualne zmiany wymagań, Wykonawcy/Inżynierowie Przygotowanie oferty budowy systemu, Planowanie procesu (harmonogramu) tworzenia, Planowanie architektury systemu, Przygotowanie testów systemu (m. in. akceptacyjne), Zrozumienie działania systemu, Wykrycie powiązań pomiędzy częściami systemu,

Co wpływa na sukces? Zaangażowanie klienta Pełne rozpoznanie wymagań, Wszystkie szczeble decyzyjne, Przekonanie o sensowności procesu, Pełne rozpoznanie wymagań, Sytuacje typowe, Sytuacje skrajne i ograniczenia, Kompletność i spójność wymagań, Określenie wymagań niefunkcjonalnych Możliwość weryfikacji, Zdefiniowanie stosownych miar i określenie ich realnych wartości.