INŻYNIERIA OPROGRAMOWANIA [ 1968 ].

Prezentacja na temat: "INŻYNIERIA OPROGRAMOWANIA [ 1968 ]."— Zapis prezentacji:

1 INŻYNIERIA OPROGRAMOWANIA [ 1968 ]

2 Zasady skutecznego działania
[ Stephen Covey ] Bądź proaktywny – odpowiedzialnośc  świadomy wybór Zaczynaj mając koniec na względzie Aby rzeczy pierwsze były pierwsze Myśl o obopólnej korzyści Najpierw staraj się zrozumieć Dbaj o synergię – > 2 Ostrz piłę – odnowa fizyczna, umysłowa, społeczna i duchowa

3 OBIEKTOWE METODY PROJEKTOWANIA
Faza Projektowania Ogólny Opis Systemu Architektura Systemu Faza Analizy Faza Implementacji Specyfikacja Systemu Gotowy System

4 Unified Modeling Language
język modelowania – język do tworzenia modeli systemów modele : dokładne spójne łatwe do zmiany komunikatywne zrozumiałe

5 UML - unifikacja poprzednich metod :
języki modelowania : zazwyczaj języki wizualne – widoki, diagramy, opisy w języku naturalnym UML - unifikacja poprzednich metod : Booch, OMT, OOSE/Objectory, Fusion, Coad/Yourdon zdefiniowany głównie przez [1997] : G. Booch, J. Rumbaugh, I. Jacobson wspierany przez DEC, HP, IBM, Microsoft, Oracle, Rational i innych UML : język modelowania zorientowany obiektowo

6 Czym jest UML język wizualny do opisu struktury statycznej
dynamicznego zachowania się systemu główne części : widoki – obrazują główne aspekty systemu diagramy – opisują zawartość widoku elementy – pojęcia użyte w diagramach (klasy, obiekty, generalizacja ...)

7 Modelowanie przypadków użycia (use-case)
do modelowania najbardziej ogólnego poziomu działania systemu porozumienie pomiędzy Projektantem a Klientem (formalny kontrakt) podstawa dalszego projektowania podstawa testowania

8 tworzenie modelu przypadków użycia
definiowanie systemu znajdowanie aktorów znajdowanie przypadków użycia opisywanie przypadków użycia definiowanie relacji pomiędzy przypadkami użycia ocena modelu

9 diagramy przypadków użycia
system przypadek użycia aktor relacje

10 inicjuje wykonanie funkcji systemu wymaga dostępu do systemu
aktor inicjuje wykonanie funkcji systemu wymaga dostępu do systemu reprezentuje punkt widzenia na system jest osobą fizyczną lub innym systemem bibliotekarz kasjerka zegar

11 diagram przypadków użycia
p-u p-u p-u aktor aktor system diagram przypadków użycia

12 Komentarz Klient Klient Bezpośredni Klient Zdalny uogólnianie aktorów

13 relacja rozszerzania specyficzny przypadek użycia aktor_B « extend »
ogólny przypadek użycia aktor_A relacja rozszerzania

14 relacja zawierania wspólny przypadek użycia « include» « include »

15 temat przypadku użycia (cel) jak jest inicjowany
opisywanie przypadków użycia : język naturalny temat przypadku użycia (cel) jak jest inicjowany przepływ komunikatów pomiędzy aktorami a przypadkami użycia (główny i alternatywne) jak przypadek użycia kończy się i dostarcza wyniku aktorowi

16 testowanie przypadków użycia
weryfikacja i ocena (ręczna) odegranie przypadku użycia (testujący odgrywają rolę aktorów i systemu)

17

18

19 Specyfikacja wymagań opis systemu informatycznego będący podstawą kontraktu klient – wykonawca wymaganie  opis pojedynczej właściwości systemu specyfikacja wymagań  zbiór wymagań wymagania funkcjonalne i pozafunkcjonalne opisy wszystkich funkcji inne cechy realizowanych przez system systemu

20 Wymagania Pozafunkcjonalne  URPS
{ Usability, Reliability, Performance, Security } { Użyteczność, Niezawodność, Wydajność, Bezpieczeństwo } U - użyteczność, oznacza łatwość użytkowania systemu. Takie wymagania można precyzować np. poprzez maksymalny czas szkolenia pracownika, liczba kontaktów ze wsparciem klienta, liczbą sytuacji, w których konieczne jest skorzystanie z systemu pomocy.

21 R - niezawodność, może być mierzona poprzez: średnią liczbę godzin pracy bez awarii (MTBF - Mean Time Between Failure), maksymalną liczbą godzin w miesiącu w ciągu których system może być wyłączony w celach pielęgnacyjnych (maintainance) - ma to znaczenie szczególnie w przypadku systemów, które muszą pracować na okrągło - np. systemy bankowości elektronicznej P - wydajność - mierzona np. liczbą transakcji, którą system jest w stanie obsłużyć w ciągu godziny, liczbą użytkowników, którzy mogą być zalogowani jednocześnie do portalu S - bezpieczeństwo, to wymagania związane z szyfrowaniem, polityką praw, itp.

22 Wymagania Funkcjonalne
znaczenie słów i zwrotów nie zawsze jest identyczne dla obu stron wiedza świadoma i nieświadoma nieprecyzyjne przymiotniki szybka reakcja, duża czcionka, odpowiednio dobrane kolory

23 formułowanie wymagań funkcjonalnych za pomocą
definicji przypadków użycia ( use cases ) ID: Nazwa: Aktorzy główni: Aktorzy pomocniczy: Priorytet: Opis: Wyzwalacze: Warunki początkowe: Warunki końcowe: Scenariusz główny: Scenariusze alternatywne i rozszerzenia:

24 ID : LO_UC1 Nazwa : Logowanie na konto użytkownika Aktorzy główni: Odwiedzający Aktorzy pomocniczy: Brak Priorytet: Wysoki Opis: Odwiedzający posiada aktywne konto użytkownika i chce się na nie zalogować. Przechodzi na stronę logowania, wypełnia formularz wymaganymi danymi i je zatwierdza. Odwiedzający zostaje zalogowany w serwisie. Wyzwalacze: 1. Odwiedzający chce zalogować się do systemu. Warunki początkowe: Odwiedzający posiada konto użytkownika (UC5). Konto Odwiedzającego nie zostało zablokowane (UC7, US8).

25 Warunki końcowe: 1. Odwiedzający zalogował się na swoje konto użytkownika. Scenariusz Główny: 1. Odwiedzający przechodzi do strony logowania. 2. Serwis wyświetla formularz logowania. 3. Odwiedzający wypełnia formularz wymaganymi danymi i je zatwierdza. 4. Odwiedzający zostaje zalogowany. Scenariusze alternatywne i rozszerzenia: 3.A. Wprowadzone dane są nieprawidłowe lub niekompletne: 3.A.1. Serwis prezentuje informację o błędzie logowania. 3.A.2. Powrót do kroku 3.

26 3.B. Konto Użytkownika nie zostało aktywowane:
3.B.1. Serwis prezentuje informację o błędzie logowania z powodu nieaktywnego konta. 3.B.2. Powrót do kroku 2. 3.C. Konto zostało zablokowane: 3.C.1 Serwis prezentuje informację o błędzie logowania z powodu zablokowania konta. 3.C.2. Powrót do kroku 2. 3.D. Serwis wysyła do Odwiedzającego wiadomość SMS z kodem jednorazowym 3.D.1. Odwiedzający wprowadza kod jednorazowy i zatwierdza. 3.D.2. Kod jednorazowy jest poprawny – powrót do kroku 4. 3.D.3. Kod jednorazowy nie jest poprawny, serwis prezentuje informację o błędzie logowania – powrót do kroku 2.

27 Zasady definiowania przypadków użycia
Fraza czasownikowa w nazwie Wystawianie faktury Generowanie raportu miesięcznego Główny przypadek użycia Przypadek użycia 23 Zarządzanie

28 Scenariusz i rozszerzenia
maksymalna czytelność 3 – 9 punktów alternatywy i rozszerzenia ( nr punktu + litera ): głównego scenariusza nie da się zrealizować dodatkowe warianty można zagnieżdżać

29 Niezależność od technologii ( obojętność technologiczna )
technologie szybko się zmieniają szczegóły interfejsu graficznego (GUI) zaciemniają treść klient nie rozumie terminów informatycznych Pracownik klika na przycisk kalendarza System zapisuje dane w relacyjnej bazie danych Za pomocą protokołu SOAP system odczytuje temperaturę Dane wyświetlane są za pomocą elementu DataGrid w trybie JointTable

30 4. Scenariusze hierarchiczne
UC1. Przeprowadzenie badania ankietowego UC1.1. Przygotowanie ankiety UC1.2. Rozsyłanie ankiet UC1.2.1 Pozyskanie zbioru adresów UC1.2.2 Weryfikacja adresów UC1.2.3 Personalizowanie ankiet UC Wysyłanie ankiet UC1.3. Zbieranie odpowiedzi UC1.4. Analizowanie odpowiedzi

31 5. Zespół przygotowujący wymagania
pracownicy o różnych specjalnościach zespół niezbyt liczny ( 3 – 5 osób ) analitycy i klienci synergia: kompensowanie słabych stron jednej osoby silnymi stronami innej osoby większa liczba recenzentów

32 6. Często popełniane błędy
UC1: Faktura Główny scenariusz: 1. Sprzedawca wpisuje kod dostępu 2. System weryfikuje użytkownika 3. Kliknięcie przycisku wystawiania faktury 4. System prezentuje formularz 5. Wpisanie pozycji w dolnym okienku 6. Wpisanie wartości pozycji, stawki VAT, liczby pozycji i nr porządkowego 7. System podlicza faskturę i prezentuje sumę 8. System nadaje nowy numer i zapisuje w rejestrze faktur 9. Wydruk faktury 10. Jeżeli wystawianie faktury się zakończyło to użytkownik się wylogowuje