Jarosław Kuchta Dokumentacja i Jakość Oprogramowania

Slides:



Advertisements
Podobne prezentacje
SKUTECZNOŚĆ i EFEKTYWNOŚĆ SYSTEMU
Advertisements

Jakość w procesie wytwarzania oprogramowania
Modelowanie przypadków użycia
Jakość w procesie wytwarzania oprogramowania
Projektowanie w cyklu życia oprogramowania
Jarosław Kuchta Dokumentacja i Jakość Oprogramowania
Złożoność procesu konstrukcji oprogramowania wymusza podział na etapy.
Część 2 OiZPI Iteracyjny przyrostowy model cyklu życiowego Rational Unified Process™ w materiałach wykorzystano: K.Subieta: Budowa i integracja systemów.
Analiza ryzyka projektu
Referat 3. Planowanie zadań i metody ich obrazowania
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 28Slide 1 Restrukturyzacja oprogramowania l Reorganizowanie i modyfikowanie istniejącego.
FIT Środowisko Testów Integracyjnych
Plan działania Wrocław, PLAN DZIAŁANIA – STATUS DOKUMENTU W SYTEMIE REALIZACJI DOPRECYZOWANIE ZAPISÓW PO KL SzOP PD -
Propozycja metodyki nauczania inżynierii oprogramowania
DOKUMENTOWANIE PROCESU ZINTEGROWANEGO
Budowanie wspólnoty uczących się MODUŁ VIII Sesja 8.1 Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego PROGRAM.
Jarosław Kuchta Jakość Systemów Informatycznych
Jakość systemów informacyjnych (aspekt eksploatacyjny)
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
Projekt zaliczeniowy z przedmiotu "Inżynieria oprogramowania"
Dalsze elementy metodologii projektowania. Naszym celem jest...
Analiza, projekt i częściowa implementacja systemu obsługi kina
Wykład 2 Cykl życia systemu informacyjnego
Zadanie: Integracja oprogramowania w gminach i starostwie
Wykonawcy:Magdalena Bęczkowska Łukasz Maliszewski Piotr Kwiatek Piotr Litwiniuk Paweł Głębocki.
o granicy funkcji przy obliczaniu granic Twierdzenia
Digitalizacja obiektów muzealnych
Microsoft Solution Framework
Zarządzanie jakością projektu
Rozwiązania informatyczne dla przedsiębiorstw
UTWORZENIE SPÓJNEJ ANTYTERRORYSTYCZNEJ STRATEGII INFORMACYJNEJ
Zarządzanie projektami
Rynek tłumaczeń i lokalizacji w Polsce, Wrocław marca 2009r. Małgorzata Haas-Tokarska Maksymilian Nawrocki MORAVIA IT.
Spotkanie Centrum Poczty i Postdata S.A.
Propozycja zmian w dokumencie Zasady i tryb postępowania akredytacyjnego Bohdan Macukow.
Dr Karolina Muszyńska Na podst.:
Modelowanie obiektowe Diagramy UML – diagram przypadków użycia
Sebastian Wojczyk Inżynieria wymagań Sebastian Wojczyk
Projektowanie relacyjnych baz danych – postacie normalne
Moduł III Definiowanie i planowanie zadań typu P 1.
Treści multimedialne - kodowanie, przetwarzanie, prezentacja Odtwarzanie treści multimedialnych Andrzej Majkowski 1 informatyka +
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.
Treści multimedialne - kodowanie, przetwarzanie, prezentacja Odtwarzanie treści multimedialnych Andrzej Majkowski informatyka +
Temat 6: Dokumentacja techniczna urządzeń sieciowych.
Projektowanie relacyjnych baz danych – diagramy związków encji
Podstawy zarządzania projektami Karta projektu
Copyright © Jerzy R. Nawrocki Team Software Process Inżynieria oprogramowania II Wykład.
Wdrażanie SYSTEMU Jacek WĘGLARCZYK.
Projektowanie obiektowe. Przykład: Punktem wyjścia w obiektowym tworzeniu systemu informacyjnego jest zawsze pewien model biznesowy. Przykład: Diagram.
Nie jesteśmy w stanie odpowiedzieć na wszystkie wyzwania... ~ … ale jesteśmy Nie jesteśmy w stanie odpowiedzieć na wszystkie wyzwania... ~ … ale jesteśmy.
Ergonomia procesów informacyjnych
Ocena jakości systemów informacyjnych (aspekt eksploatacyjny)
Dane – informacje - wiadomości Kodowanie danych i problem nadmiarowości.
Eksploatacja zasobów informatycznych przedsiębiorstwa.
1 © copyright by Piotr Bigosiński DOKUMENTACJA SYSTEMU HACCP. USTANOWIENIE, PROWADZENIE I UTRZYMANIE DOKUMENTACJI. Piotr Bigosiński 1 czerwiec 2004 r.
Wstęp do systemów informatycznych Model przypadków użycia.
Departament Polityki Regionalnej Wyniki badania ewaluacyjnego: „Ocena systemu kryteri ó w wyboru projekt ó w zastosowanych w Regionalnym Programie Operacyjnym.
Inżynieria systemów informacyjnych
Zarządzanie projektami informatycznymi
Krzysztof Szymański, Krzysztof Leja Wydział Zarządzania i Ekonomii
Inżynieria Oprogramowania Laboratorium
Projekt modułu BANK INTERNETOWY Moduł funkcji banku
IV Konferencja Naukowo-Techniczna "Nowoczesne technologie w projektowaniu, budowie.
Treści multimedialne - kodowanie, przetwarzanie, prezentacja Odtwarzanie treści multimedialnych Andrzej Majkowski informatyka +
Systemy eksperckie i sztuczna inteligencja
Zapis prezentacji:

Jarosław Kuchta Dokumentacja i Jakość Oprogramowania Inżynieria wymagań

Cele inżynierii wymagań Określenie celu biznesowego projektu Cel biznesowy określa korzyści, jakie osiągną udziałowcy projektu dzięki jego realizacji Identyfikacja wymagań funkcjonalnych niefunkcjonalnych Alokacja wymagań do poszczególnych składników systemu informatycznego Dokumentacja i Jakość Oprogramowania Inżynieria wymagań

Składniki systemu informatycznego System informatyczny Sprzęt Procedury Oprogramowanie Baza danych Ludzie Dokumentacja Dokumentacja i Jakość Oprogramowania Inżynieria wymagań

Alokacja wymagań – przykład Rejestracja opinii od klientów Rozwiązanie pierwsze – pracownik działu reklamacji analizuje opinie przychodzące telefonicznie lub pocztą i wpisuje je do odpowiedniego formularza. Dane są rejestrowane w bazie danych. Rozwiązanie drugie – serwis internetowy udostępnia formularz opinii. Klienci składający reklamacje muszą odpowiednio szczegółowo wypełnić formularz. Dane są rejestrowane w bazie danych. Rozwiązanie trzecie – włącza się automatyczny serwis telefoniczny. System rozpoznawania głosu wyławia kluczowe słowa z wypowiedzi klienta i tworzy skróconą charakterystykę opinii. Dane są rejestrowane w bazie danych wraz z pełnym nagraniem wypowiedzi. Dokumentacja i Jakość Oprogramowania Inżynieria wymagań

Ustalenie osób zainteresowanych użytkownicy końcowi (wymagania funkcjonalne) administrator systemu (szczególne wymagania funkcjonalne, niezawodność, dostępność, testowalność) wyższe kierownictwo (cele biznesowe) kierownik marketingu (cechy marketingowe) kierownik finansowy (koszty) kierownik ochrony (bezpieczeństwo) Dokumentacja i Jakość Oprogramowania Inżynieria wymagań

Ustalenie udziałowców Każda osoba zainteresowana może występować w kilku rolach (np. administrator może też być użytkownikiem końcowym). Z każdą rolą jest związany określony punkt widzenia. Osoba występująca w danej roli jest udziałowcem projektu. Każde urządzenie lub system współpracujący z projektowanym systemem również może mieć swoje wymagania i w tym sensie również jest udziałowcem projektu. Punkty widzenia różnych udziałowców są różne. Wszystkie punkty widzenia udziałowców są ważne, chociaż nie wszystkie w tym samym stopniu. Wszystkie punkty widzenia powinny zostać wzięte pod uwagę. Wszystkie punkty widzenia powinny zostać przeanalizowane. Pojawiające się konflikty powinny zostać rozstrzygnięte. Dokumentacja i Jakość Oprogramowania Inżynieria wymagań

Ustalenie klienta Klientem jest osoba lub organizacja, która ma ostateczny wpływ na kształt projektu. Z klientem uzgadniamy specyfikację wymagań i podpisujemy kontrakt. Klient powinien należeć do udziałowców projektu, w przeciwnym wypadku nie jest zainteresowany wprowadzeniem systemu, stąd szanse powodzenia są minimalne. W organizacji musi być wyznaczona osoba odpowiedzialna reprezentująca klienta. Osoba ta musi mieć odpowiednią władzę nad innymi udziałowcami, aby zapewnić ich współpracę w fazie formułowania wymagań. W przypadku klienta szerokiego (produkt przeznaczony dla masowego odbiorcy) trzeba znaleźć osobę lub grupę osób reprezentujących udziałowców (najczęściej użytkowników końcowych) i od nich pozyskiwać wymagania. Dokumentacja i Jakość Oprogramowania Inżynieria wymagań

Proces pozyskiwania wymagań Wydobywanie informacji Wstępna reprezentacja Wstępna analiza Ocena specyfikacji Dokumentacja i Jakość Oprogramowania Inżynieria wymagań

Podstawowy problem – zrozumienie Wiem, że sądzisz, iż rozumiesz to, co myślisz, że ja powiedziałem, ale nie jestem pewien, czy zdajesz sobie sprawę z tego, że to co słyszałeś nie jest tym, co ja myślałem... Dokumentacja i Jakość Oprogramowania Inżynieria wymagań

Wydobywanie informacji Uświadomienie sobie przez udziałowców ich potrzeb. Sformułowanie potrzeb. Transformowanie potrzeb na wymagania względem systemu. Zdobycie informacji potrzebnych do zrozumienia wymagań. Dokumentacja i Jakość Oprogramowania Inżynieria wymagań

Uświadomienie potrzeb Udziałowiec może nie czuć potrzeby wprowadzenia systemu, a jedynie kierować się odgórnymi nakazami czy trendami. Udziałowiec może być na tyle przyzwyczajony do dotychczasowego sposobu pracy, że nie potrafi zrozumieć zmian, które nastąpią po wprowadzeniu nowego systemu. Udziałowiec prawie na pewno nie uświadamia sobie wszystkich swoich potrzeb. W przypadku, gdy udziałowcem jest urządzenie lub system, jego wymagania może reprezentować osoba eksperta lub mogą być one zapisane w dokumentacji. Dokumentacja i Jakość Oprogramowania Inżynieria wymagań

Formułowanie potrzeb Udziałowiec może mieć kłopoty z formułowaniem jasnych wypowiedzi. Udziałowiec może być niechętny do formułowania pewnych potrzeb, gdyż może uznać je za słabość swoją lub swojej organizacji i wstydzić się tej słabości. Udziałowiec może uznać pewne swoje potrzeby za oczywiste i nie zdawać sobie sprawy z tego, że ktoś inny może ich nie znać. Dokumentacja i Jakość Oprogramowania Inżynieria wymagań

Transformowanie potrzeb na wymagania systemowe Nie każdą potrzebę jest w stanie zaspokoić system informatyczny. Niektórych potrzeb nie da się zaspokoić bez zmiany organizacji. Wymagania mogą być funkcjonalne i niefunkcjonalne. Istnieje konieczność klasyfikacji wymagań. Wymagania powinny określać, co system ma robić, a nie w jaki sposób ma to robić. Różne potrzeby mogą prowadzić do sprzecznych wymagań. Istnieje konieczność określenia priorytetów ważności wymagań. Dokumentacja i Jakość Oprogramowania Inżynieria wymagań

Zdobycie informacji potrzebnych do zrozumienia wymagań Informacje mogą być „przechowywane w głowach” pewnych osób, które mogą nie być zainteresowane w dzieleniu się nimi. Informacje mogą być zapisane w trudno dostępnej dokumentacji. Informacje mogą być niekompletne. Informacje mogą być sprzeczne. Informacje mogą być mylące. Dokumentacja i Jakość Oprogramowania Inżynieria wymagań

Wstępna reprezentacja Opis słowny – może mieć niejednoznaczną interpretację, może być niejasny (sformułowany językiem specjalistycznym), duże prawdopodobieństwo nadmiarowości i sprzeczności. Opis graficzny – jest bardziej czytelny (notacja musi być znana dla udziałowców, np. diagramy blokowe, czytelne symbole), ułatwia precyzowanie faktów. Opis matematyczny (naukowy, tabelaryczny) – stosuje się jedynie do niektórych wymagań Opis kombinowany – problem spójności Potrzeba logicznego uszeregowania wymagań – ujawnia luki, nadmiarowości i sprzeczności w wymaganiach. Wymagania różnych udziałowców rejestruje się osobno i następnie tworzy ich kompilację. Wymagania muszą być ponumerowane, tak aby w późniejszych fazach móc się do nich odwoływać. Dokumentacja i Jakość Oprogramowania Inżynieria wymagań

Wstępna analiza Cel – walidacja wymagań przez udziałowców. Środek – analiza przez udziałowca wyspecyfikowanych przez siebie i zredagowanych przez analityka wymagań. Pytania stawiane przez analityka: Co takiego? Dlaczego? Czy istnieją inne możliwości? Dokumentacja i Jakość Oprogramowania Inżynieria wymagań

Środki pomocnicze prototypowanie podejście ewolucyjno-iteracyjne prototypem na etapie specyfikacji może być model systemu (rysunek szkicowy interfejsu użytkownika, wyszczególnienie najważniejszych pozycji menu, szkic najważniejszych raportów) prototypem może być uproszczony program realizujący jedynie wybrane funkcje podejście ewolucyjno-iteracyjne realizacja projektu ze świadomie ograniczoną funkcjonalnością przy założeniu dalszego udoskonalania systemu w przyszłości. Dokumentacja i Jakość Oprogramowania Inżynieria wymagań

Rezultaty wymagania poprawnie wyspecyfikowane wymagania niepoprawnie wyspecyfikowane zakres projektu Dokumentacja i Jakość Oprogramowania Inżynieria wymagań

Trzy grupy wymagań Wymagania jawnie wyspecyfikowane (dotyczące konkretnego projektu) Wymagania domyślne – nie wyspecyfikowane jawnie, lecz konieczne dla realizacji celów projektu Wymagania obligatoryjne – nie muszą być wyspecyfikowane jawnie, lecz występują ze względu na regulacje prawne lub wymogi rynku. Dokumentacja i Jakość Oprogramowania Inżynieria wymagań

Specyfikacja Wymagań Systemowych Wstęp Opis informacyjny Wymagania funkcjonalne Wymagania niefunkcjonalne Kryteria akceptacyjne Bibliografia Dodatki Dokumentacja i Jakość Oprogramowania Inżynieria wymagań

SWS – Wstęp Identyfikacja systemu Skrócony opis organizacji Cel wprowadzenia systemu (cel biznesowy) Podstawowe ograniczenia Dokumentacja i Jakość Oprogramowania Inżynieria wymagań

SWS – Opis informacyjny Szczegółowy opis problemów do rozwiązania Diagramy przepływu (sterowania lub danych) najwyższego poziomu Reprezentacja zawartości informacyjnej Opis interfejsów systemowych (użytkownika, softwerowych, sprzętowych) Dokumentacja i Jakość Oprogramowania Inżynieria wymagań

SWS – Wymagania funkcjonalne Lista funkcji (podział hierarchiczny) Opis każdej funkcji opis tekstowy ograniczenia wymagania wydajnościowe zastrzeżenia projektowe diagramy pomocnicze Opis sterowania specyfikacja sterowania Dokumentacja i Jakość Oprogramowania Inżynieria wymagań

SWS – Wymagania niefunkcjonalne Wymagania wydajnościowe Wymagania niezawodnościowe Wymagania dot. bezpieczeństwa inne Dokumentacja i Jakość Oprogramowania Inżynieria wymagań

SWS – Kryteria akceptacyjne Klasy testów Oczekiwane odpowiedzi systemu Zastrzeżenia szczególne Dokumentacja i Jakość Oprogramowania Inżynieria wymagań

SWS – Bibliografia Inne dokumenty inżynierii oprogramowania Instrukcje techniczne Literatura pomocnicza Standardy Dokumentacja i Jakość Oprogramowania Inżynieria wymagań

SWS – Dodatki Słownik pojęć Dane tabelaryczne Wykresy Specyfikacja szczególnych algorytmów Dokumentacja i Jakość Oprogramowania Inżynieria wymagań

Literatura Pressman R.S., Software engineering. A practitioner’s approach, McGraw-Hill, International Edition, 1992 Górski J. et al., Inżynieria oprogramowania w projekcie informatycznym,wyd. Mikom, Warszawa, 2000 Dokumentacja i Jakość Oprogramowania Inżynieria wymagań