Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

INŻYNIERIA OPROGRAMOWANIA [ 1968 ]. Zasady skutecznego działania [ Stephen Covey ] Bądź proaktywny – odpowiedzialnośc świadomy wybór Zaczynaj mając koniec.

Podobne prezentacje


Prezentacja na temat: "INŻYNIERIA OPROGRAMOWANIA [ 1968 ]. Zasady skutecznego działania [ Stephen Covey ] Bądź proaktywny – odpowiedzialnośc świadomy wybór Zaczynaj mając koniec."— 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 Analizy Specyfikacja Systemu Faza Projektowania Architektura Systemu Ogólny Opis Systemu Faza Implementacji Gotowy System

4 U nified M odeling L anguage język modelowania – język do tworzenia modeli systemów modele : dokładne spójne łatwe do zmiany komunikatywne zrozumiałe

5 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 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 system aktor p-u diagram przypadków użycia

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

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

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

15 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 systemsystemu

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: 1.Odwiedzający posiada konto użytkownika (UC5). 2.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 1.Fraza czasownikowa w nazwie Wystawianie faktury Generowanie raportu miesięcznego Główny przypadek użycia Przypadek użycia 23 Zarządzanie

28 2. 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 3.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


Pobierz ppt "INŻYNIERIA OPROGRAMOWANIA [ 1968 ]. Zasady skutecznego działania [ Stephen Covey ] Bądź proaktywny – odpowiedzialnośc świadomy wybór Zaczynaj mając koniec."

Podobne prezentacje


Reklamy Google