Dr Katarzyna Grzesiak-Koped
2
● Tworzenie oprogramowania ● Najlepsze praktyki IO ● Inżynieria wymagao ● Technologia obiektowa i język UML ● Techniki IO ● Metodyki zwinne ● Refaktoryzacja ● Mierzenie oprogramowania ● Jakośd oprogramowania ● Programowanie strukturalne ● Modelowanie analityczne ● Wprowadzenie do testowania © Katarzyna Grzesiak-Koped 2010/2011
3
1. 2. 3. 4. 5. 6.
Podejście iteracyjne Zarządzanie wymaganiami Architektura modułowa (komponenty) Wizualizacja modelu Ciągła weryfikacja jakości Zarządzanie zmianami
© Katarzyna Grzesiak-Koped 2010/2011
4
1. 2. 3. 4. 5. 6.
Podejście iteracyjne Zarządzanie wymaganiami Architektura modułowa (komponenty) Wizualizacja modelu Ciągła weryfikacja jakości Zarządzanie zmianami
© Katarzyna Grzesiak-Koped 2010/2011
5
Analiza wymagao Projektowanie Kodowanie i testowanie modułów
Integracja podsystemów Testowanie systemu
● Opóźnia identyfikację ryzyka ● Trudno ocenid rzeczywisty czas do ukooczenia projektu ● Odsuwa w czasie integrację i agreguje testowanie ● Wyklucza wczesne wdrażanie ● Częste niezaplanowane iteracje
© Katarzyna Grzesiak-Koped 2010/2011
6
Wymagania Planowanie
Analiza i projektowanie Implementacja
Wstępne planowanie
Zarządzanie procesami
Ewaluacja
W wyniku każdej iteracji powstaje wykonywalny moduł
Testowanie
Wdrażanie
© Katarzyna Grzesiak-Koped 2010/2011
7
● Rozwiązanie ryzykownych kwestii zanim będą duże inwestycje ● Umożliwia wczesną ocenę przez klienta ● Ciągłe integrowanie i testowanie ● Realizacja zadania w małych, krótkoterminowych krokach ● Umożliwia częściowe wdrażanie produktu
© Katarzyna Grzesiak-Koped 2010/2011
8
wodospad iteracje
RYZYKO
CZAS © Katarzyna Grzesiak-Koped 2010/2011
9
1. 2. 3. 4. 5. 6.
Podejście iteracyjne Zarządzanie wymaganiami Architektura modułowa (komponenty) Wizualizacja modelu Ciągła weryfikacja jakości Zarządzanie zmianami
© Katarzyna Grzesiak-Koped 2010/2011
10
● Należy upewnid się, że: o Rozwiązujemy właściwy problem o Budujemy właściwy system
● Po przez systematyczne: o gromadzenie, o organizację, o dokumentowanie, o zarządzanie
● zmieniającymi się wymaganiami. © Katarzyna Grzesiak-Koped 2010/2011
11
● Analiza problemu ● Zrozumienie potrzeb klienta ● Zdefiniowanie systemu ● Ogarnięcie całości ● Ciągła weryfikacja definicji systemu ● Budowa właściwego systemu
© Katarzyna Grzesiak-Koped 2010/2011
12
Obszar problemu Potrzeby klienta Charakterystyka
Problem
Obszar rozwiązań
Wymagania (PU) Procedury testowania
produkt Projekt
Dokumentacja użytkownika
© Katarzyna Grzesiak-Koped 2010/2011
13
● Ocena wpływu zmiany wymagania na nasz projekt ● Ocena stopnia realizacji wymagania na podstawie przygotowanych procedur ● Ogarnąd cały projekt ● Zweryfikowad, czy wszystkie wymagania zostały zrealizowane ● Zweryfikowad, czy aplikacja robi tylko to, co miała robid ● Zarządzad zmianami © Katarzyna Grzesiak-Koped 2010/2011
14
1. 2. 3. 4. 5. 6.
Podejście iteracyjne Zarządzanie wymaganiami Architektura modułowa (komponenty) Wizualizacja modelu Ciągła weryfikacja jakości Zarządzanie zmianami
© Katarzyna Grzesiak-Koped 2010/2011
15
ZBIÓR ZASAD, DECYZJI, REGUŁ LUB WZORCÓW DLA DOWOLNEGO SYSTEMU, KTÓRY ZAPOBIEGA NIEPOTRZEBNEJ RADOSNEJ TWÓRCZOŚCI
PROJEKTANTÓW.
© Katarzyna Grzesiak-Koped 2010/2011
16
● Architektura oprogramowania określa najważniejsze elementy organizacji systemu: o Wybór elementów strukturalnych oraz ich interfejsów o Określenie zachowania systemu jako interakcji pomiędzy tymi elementami o Kompozycja elementów strukturalnych i behawioralnych w podsystemy
© Katarzyna Grzesiak-Koped 2010/2011
17
● Ogólna budowa pewnego rozwiązania informatycznego, którego elementem jest zarówno oprogramowanie, jak i pewna infrastruktura techniczna, sprzęt ● Łączy własności strukturalne (komponenty fizyczne) oraz funkcjonalne (zewnętrzne i wewnętrzne funkcje systemu) ● Opisuje składowe, powiązania między nimi oraz sposoby i kierunki przepływu danych © Katarzyna Grzesiak-Koped 2010/2011
18
● Architektura logiczna o Podział na logiczne fragmenty (moduły, pakiety, komponenty), które powinny współpracowad w celu realizacji wymagao o UML – komponent + interfejsy
● Architektura fizyczna o Określenie fizycznych jednostek (maszyn) oraz metod komunikacji o UML – węzeł
© Katarzyna Grzesiak-Koped 2010/2011
19
● Określenie architektury, to podjęcie strategicznych decyzji, określenie reguł i wzorców determinujących projektowanie i konstrukcję – FUNDAMENTALNE DECYZJE Implementacja Projekt Architektura
© Katarzyna Grzesiak-Koped 2010/2011
20
● Elastyczna o Spełnia bieżące i przyszłe wymagania o Umożliwia rozbudowę o Umożliwia ponowne użycie o Enkapsuluje zależne części systemu
● Modułowa o Ponowne użycie i modyfikacja modułów o Wybór z komercyjnie dostępnych komponentów o Inkrementacyjny rozwój oprogramowania
© Katarzyna Grzesiak-Koped 2010/2011
21
Nietrywialna, prawie niezależna i wymienna część systemu, która realizuje zdefiniowaną funkcjonalność.
© Katarzyna Grzesiak-Koped 2010/2011
22
● Umożliwia ponowne wykorzystanie o Komponentów o Architektury
● Podstawa do zarządzania projektem o Planowanie o Ludzie o Dostarczanie produktu
● Kontrola o Zarządzanie złożonym systemem o Integracja © Katarzyna Grzesiak-Koped 2010/2011
23
1. 2. 3. 4. 5. 6.
Podejście iteracyjne Zarządzanie wymaganiami Architektura modułowa (komponenty) Wizualizacja modelu Ciągła weryfikacja jakości Zarządzanie zmianami
© Katarzyna Grzesiak-Koped 2010/2011
24
● ● ● ●
Uchwycenie struktury i zachowania Pokazanie zależności między elementami Utrzymanie spójnego projektu i implementacji Ukrywanie oraz wyróżnianie szczegółów kiedy trzeba ● Promuje jeden wspólny język wymiany informacji o UML: jeden język dla wszystkich osób związanych z tworzeniem projektu
© Katarzyna Grzesiak-Koped 2010/2011
25
● Język do specyfikowania, wizualizowania, konstruowania i dokumentowania tworów oprogramowania i modelowania biznesu ● Reprezentuje zbiór najlepszych praktyk inżynierskich które dowiodły przydatności przy modelowaniu dużych i skomplikowanych systemów
© Katarzyna Grzesiak-Koped 2010/2011
26
● Do połowy lat 90 – około 50 metod ● Potrzeba unifikacji ● `94 Booch, Jacobson i Rumbaugh z Rational Software ● `95 Unifikacja OMT, Boocha i OOSE w UML ● `96 standaryzacja UML pod skrzydłami OMG (http://www.omg.org) [wersje 1.1,..,1.5] ● 2005 OMG publikuje UML 2.0 ● Maj 2010 UML 2.3 © Katarzyna Grzesiak-Koped 2010/2011
27
● Object Management Group (OMG) ● Hewlett-Packard Company ● IBM Corporation (Rational Software Corporation) ● Microsoft Corporation ● Oracle Corporation ● i inne mniej znane...
© Katarzyna Grzesiak-Koped 2010/2011
28
Computer Aided Software Engineering
● IMB Rational Rose/IMB Rational Software Architect ● Microsoft Visio ● Poseidon for UML ● Sybase PowerDesigner ● Visual Paradigm ● Umbrello ● Eclipse ● NetBeans ● I wiele innych freeware, shareware i komercyjnych © Katarzyna Grzesiak-Koped 2010/2011
29
● Gotowy wizualny język modelowania do budowy i wymiany modeli ● Niezależny od języków programowania i procesów tworzenia ● Udostępnia podstawy formalne do zrozumienia języka modelowania ● Zachęca do wzrostu rynku narzędzi OO ● Wspomaga wysoko-poziomowe rozwiązania ● Integruje najlepsze praktyki © Katarzyna Grzesiak-Koped 2010/2011
30
● Wiele punktów widzenia ● Precyzyjna syntaksa i semantyka Use-Case Diagrams
Sequence Diagrams
Class Diagrams
Models
Communication Diagrams State Machine Diagrams
Activity Diagrams
© Katarzyna Grzesiak-Koped 2010/2011
Object Diagrams
Component Diagrams
Deployment Diagrams 31
DIAGRAMY
© Katarzyna Grzesiak-Koped 2010/2011
32
© Katarzyna Grzesiak-Koped 2010/2011
33
1. 2. 3. 4. 5. 6.
Podejście iteracyjne Zarządzanie wymaganiami Architektura modułowa (komponenty) Wizualizacja modelu Ciągła weryfikacja jakości Zarządzanie zmianami
© Katarzyna Grzesiak-Koped 2010/2011
34
Charakterystyka wyniku produkcji oprogramowania określona na podstawie tego, czy produkt spełnia lub przewyższa uzgodnione wymagania oraz czy zostało ono wytworzone zgodnie z ustalonym procesem, co jest mierzone zgodnie z ustalonymi kryteriami .
© Katarzyna Grzesiak-Koped 2010/2011
35
● Widoczna ● Ukryta ● Testy to za mało ● Oceny użytkownika o Inspekcje modeli o Inspekcje kodu
● Kontrola jakości w każdej iteracji!
© Katarzyna Grzesiak-Koped 2010/2011
36
● Wady oprogramowania są od 100 do 1000 razy droższe do zidentyfikowania i do naprawienia po wdrożeniu o Koszt naprawy błędów o Koszt straconych możliwości o Koszt straconych klientów
© Katarzyna Grzesiak-Koped 2010/2011
37
Czy osiągnięto zadawalającą niezawodnośd?
Czy aplikacja robi to co trzeba?
Czy system działa przy rzeczywistym obciążeniu?
© Katarzyna Grzesiak-Koped 2010/2011
38
1. 2. 3. 4. 5. 6.
Podejście iteracyjne Zarządzanie wymaganiami Architektura modułowa (komponenty) Wizualizacja modelu Ciągła weryfikacja jakości Zarządzanie zmianami
© Katarzyna Grzesiak-Koped 2010/2011
39
● Zmiany ● Podział pracy w zespole ● Integrację ● Równoległe prace
© Katarzyna Grzesiak-Koped 2010/2011
40
● Zarządzanie zgłoszonymi zmianami o Formalny proces zgłaszania zmian i oceny ich wpływu na projekt o Blokujemy „przeciekanie” nowych wymagao
● Raportowanie stanu konfiguracji o Mierzenie rodzaju i liczby błędów
● Zarządzanie konfiguracją o Narzędzia do wersjonowania i pracy grupowej
© Katarzyna Grzesiak-Koped 2010/2011
41
● Śledzenie zmian o Formalny proces realizacji zmian
● Wybór wersji i produkowanie systemu o Automatyzacja kompilacji, testowania, pakietowania i rozprowadzania
© Katarzyna Grzesiak-Koped 2010/2011
42
● Zarządzanie konfiguracją ● Zarządzanie katalogami, plikami i zmianami ● Architektura o Scentarlizowana klient-serwer o Rozproszona P2P
● Organizuje pracę w zespole
© Katarzyna Grzesiak-Koped 2010/2011
43
● Commit (checkin) ● Checkout ● Trunk (baseline, mainline) 7 ● Branch 2
1
6
3
4
5
© Katarzyna Grzesiak-Koped 2010/2011
10
8
9
11
44
© Katarzyna Grzesiak-Koped 2010/2011
45
© Katarzyna Grzesiak-Koped 2010/2011
46
1. 2. 3. 4. 5. 6. 7.
Podejście iteracyjne Zarządzanie wymaganiami Architektura modułowa (komponenty) Wizualizacja modelu Ciągła weryfikacja jakości Zarządzanie zmianami ?
© Katarzyna Grzesiak-Koped 2010/2011
47
● Poziomy ponownego użycia o Klasy o Wzorce projektowe o Komponenty o Interfejsy i wzorce analityczne o Wzorce architektury o Wzorce wymagao
● Wyższy poziom trudniej wykorzystad ● Wyższy poziom większe korzyści © Katarzyna Grzesiak-Koped 2010/2011
48
49
