Inżynieria Oprogramowania- PROJEKT · 5.2 plan jakości (metryka systemu) (opisujący standardy...

5
Inżynieria Oprogramowania- PROJEKT 1. Nazwa Projektu +Akronim (np. System Mobilnej Księgowości- SMK ) 2. Definicja Wymagań 2.1 Opis słowny celu systemu i usług +Targeting Systemu (zdefiniowanie grupy użytkowników systemu) lub 2.2 Opis SPIN (Situation/Problem questions, Implied need/Needs pay off) Czyli opis istniejących rozwiązań, najczęściej występujących problemów, wynikających z nich potrzeb i listy typowych technologii im odpowiadających lub 2.3 Opis TOC (Theory of Constraints) czyli opis problemów, proponowanych rozwiązań organizacyjnych i wynikających z nich rozwiązań technologicznych 3. Specyfikacja wymagań ERS I (Engineering Requirement Specification, part 1) 3.1 Opis tabelaryczny/słowny lub 3.2 Diagram użycia USE-CASE DIAGRAM (Rys.1) + 3.3 Tabele przypadków użycia USE-CASE TEMPLATES (Tab.1) + 3.4 Diagram przepływu sterowania CONTROL-FLOW DIAGRAM (SEQUENCE DIAGRAM) (Rys. 2) + 3.5 Systematyzacja usług i/lub funkcji w kategorii od najważniejszych do nieistotnych np. typu MOSCOW (MUST/SHOULD/COULD/WON’T HAVE) + 3.6 Diagram komponentów/obiektów (Business Object Class Diagram)+opis (Rys.3,4) + 3.7 Diagram funkcjonalny/strukturalny +opis (Rys.5) 4. Specyfikacja wymagań ERS II (architektura/harmonogramowanie cz. 2) 4.1 Architektura Systemu SAAM(Software Architecture Analysis Model)(Rys.6) + 4.2 Harmonogram projektu (Diagram Gantta lub Person-Power-Matrix lub CPM (Critical Path Method)) uwzględniający tzw. Deliverables i milestones (Rys. 7) + 4.3 Projekt Interfejsu (programowego/sieciowego lub użytkownika) (Rys. 8) 5. Specyfikacja wymagań ERS III (plany zarządzania) 5.1 plan kosztów (koszty pracy, koszty wspólne, koszty sprzętu, koszty amortyzacji) + 5.2 plan jakości (metryka systemu) (opisujący standardy jakie spełni system) 5.3 plan testów/ewaluacji analiza ryzyka (RISK ANALYSIS) technologicznego/ekonomicznego np. (SIXSIGMA) www.isixsigma.com 5.4 plan bezpieczeństwa (jakie metody ochrony zasobów i danych będą użyte) 5.5 plan konserwacji/warunki licencji (na podstawie licencji GPL) (Zał. 1)

Transcript of Inżynieria Oprogramowania- PROJEKT · 5.2 plan jakości (metryka systemu) (opisujący standardy...

Inżynieria Oprogramowania- PROJEKT

1. Nazwa Projektu +Akronim (np. System Mobilnej Księgowości- SMK ) 2. Definicja Wymagań 2.1 Opis słowny celu systemu i usług +Targeting Systemu (zdefiniowanie grupy

użytkowników systemu) lub

2.2 Opis SPIN (Situation/Problem questions, Implied need/Needs pay off) Czyli opis istniejących rozwiązań, najczęściej występujących problemów, wynikających z nich potrzeb i listy typowych technologii im odpowiadających lub

2.3 Opis TOC (Theory of Constraints) czyli opis problemów, proponowanych rozwiązań organizacyjnych i wynikających z nich rozwiązań technologicznych

3. Specyfikacja wymagań ERS I (Engineering Requirement Specification, part 1) 3.1 Opis tabelaryczny/słowny

lub 3.2 Diagram użycia USE-CASE DIAGRAM (Rys.1)

+ 3.3 Tabele przypadków użycia USE-CASE TEMPLATES (Tab.1)

+ 3.4 Diagram przepływu sterowania CONTROL-FLOW DIAGRAM (SEQUENCE

DIAGRAM) (Rys. 2) +

3.5 Systematyzacja usług i/lub funkcji w kategorii od najważniejszych do nieistotnych np. typu MOSCOW (MUST/SHOULD/COULD/WON’T HAVE) +

3.6 Diagram komponentów/obiektów (Business Object Class Diagram)+opis (Rys.3,4) +

3.7 Diagram funkcjonalny/strukturalny +opis (Rys.5) 4. Specyfikacja wymagań ERS II (architektura/harmonogramowanie cz. 2) 4.1 Architektura Systemu SAAM(Software Architecture Analysis Model)(Rys.6)

+ 4.2 Harmonogram projektu (Diagram Gantta lub Person-Power-Matrix lub CPM

(Critical Path Method)) uwzględniający tzw. Deliverables i milestones (Rys. 7) +

4.3 Projekt Interfejsu (programowego/sieciowego lub użytkownika) (Rys. 8)

5. Specyfikacja wymagań ERS III (plany zarządzania) 5.1 plan kosztów (koszty pracy, koszty wspólne, koszty sprzętu, koszty amortyzacji) + 5.2 plan jakości (metryka systemu) (opisujący standardy jakie spełni system) 5.3 plan testów/ewaluacji analiza ryzyka (RISK ANALYSIS)

technologicznego/ekonomicznego np. (SIXSIGMA) www.isixsigma.com 5.4 plan bezpieczeństwa (jakie metody ochrony zasobów i danych będą użyte) 5.5 plan konserwacji/warunki licencji (na podstawie licencji GPL) (Zał. 1)

Rys. 1. Typowy diagram USE-CASE Nazwa przypadku (USE-CASE)- Login

Opis Uwagi

Nazwa funkcji – Wprowadz_NIK

Wprowadzenie numeru NIK NIK- numer identyfikacji klienta 4 cyfry

Warunek początkowy Użytkownik jest zarejestrowany w systemie

Warunki pośrednie Użytkownik ma aktywowaną transmisje danych cyfrowych

Protokół HSCSD

Skutek Identyfikacja użytkownika Funkcje połączone- password NIK jest elementem logowania, cookies

zapamiętujące hasła

Ograniczenia interfejsu Tylko cyfry W przyszłości możliwy pomiar biometryczny

Ograniczenia czasowe Time out po 30 sekundach Ograniczenia pozafunkcjonalne brak Ograniczenia ekonomiczne brak Obsługa krytycznych zdarzeń Możne pomylić się max. 3 razy Inne...(Nazwisko, ID projektanta, data ostatniej zmiany itp.

Inż. Kowalski, grupa A-21IZP, 30.01.2006 podpis

Tab.1 Typowa tabela specyfikacji funkcji do diagramu USE-CASE

Rys. 2. Diagram przepływu sterowania

Rys. 3. Diagram komponentów

Rys. 4 Diagram obiektów (Business Object Class Diagram)

Rys. 5. Diagram funkcjonalny/strukturalny

Rys. 6. Architektura Systemu SAAM Czas/aktywność 30.01-01.03 02.03-01.04 02.04-01.05 02.05-01.06 01.06-30.06 Plan wstępny Definicja

wym. 10.02 !

Targeting... .... Rys. 7. Harmonogram projektu

Rys. 8. Interfejs użytkownika