Metodyki projektowe
• Proces kaskadowy
• Procesy
interakcyjne
- UP
• Rational
Unified Process
•
Open Unified Process (Eclipse OpenUP)
- Agile –
techniki zwinne
•
UP – w fofmie uproszczonej (np. OpenUP)
• Scrum
•
Kanban
•
XP – eXtreme Programming
Charakterystyka metod zwinnych
• Charakterystyka
metod zwinnych została przedstawiona w Agile Manifesto (Manifest
zwinnego wytwarzania oprogramowania)
• Główne jego
założenia to stawianie:
- Ludzi i
komunikacji przed procesami i narzędziami
- Działającego
oprogramowania przed wyczerpującą dokumentacją – przecież
nie można oddać na koniec projektu tylko i wyłącznie, nawet
najlepiej, przygotowanej dokumentacji
- Współpracę z
klientem przed uzgodnieniem umowy – początkowe wymagania
mogą się zmieniać, co więcej nie wszystkie mogą zostać ujawnione.
Zaangażowanie klienta jest więc konieczne przez cały czas trwania
projektu
- Elastyczne
podejście do zmian przed sztywnym planem – szybka reakcja
na zmiany projektowe
Założenia technik zwinnych
• Satysfakcja
klienta poprzez szybkie i okresowe dostarczanie działającego
oprogramowania
• Wprowadzanie
zmian, nawet w końcowych fazach budowy oprogramowania
• Działające
oprogramowanie jest główną miarą postępów
• Utrzymywanie
stałego tempa budowy oprogramowania
• Codzienna i
bliska współpraca deweloperów z ludźmi z biznesu
• Bezpośredni
kontakt jako najlepsza forma komunikacji
• Nastawienie się
na aspekty techniczne i dobry projekt
• Prostota
rozwiązania
• Adaptacja do
zmieniających się wymagań
Ogólny proces tworzenia oprogramowania w UP
Major Milestones
|
Inception
|
Elaboration
|
Construction
|
Transition
|
▬▬▬▬▬▬▬▬▬▬▬▬▬▬TIME▬▬▬▬▬▬▬▬▬▬▬▬▬▬►
|
• Inception:
Zrozum co będziesz budował
- wizja,
wysokopoziomowe wymagania, przypadek biznesowy
• Elaboration:
Wymyśl jak to zbudujesz
- Bazowa architektura,
szczegółowe wymagania, projekt ogólny
•
Construction: Zbuduj oprogramowanie
-
Działające i przetestowane oprogramowanie
• Transition:
Wdróż oprogramowanie użytkownikom
- Zatwierdzenie
wykonania projektu przez udziałowców
Dlaczego UML
• Graficzna forma
komunikacji – jeden rysunek jest więcej wart niż 1000 słów
• Jest to notacja,
która jest zrozumiała przez wszystkich:
- Usuwa większość
problemów z prawidłowym zrozumieniem problemu
- Pozwala uchwycić
zarówno strukturę jak i zachowanie
- Pokazuje związki
pomiędzy poszczególnymi elementami oprogramowania
- Pozwala utrzymać
projekt i implementację w spójny sposób
- Ukrywa bądź ujawnia
szczegóły w zależności od potrzeb
• UML stosuje się
praktycznie w każdej z faz budowy oprogramowania
Diagramy w UML
Charakterystyka diagramów – statyczne
Za pomocą UML można
przedstawić ten sam problem z kilku różnych perspektyw. UML dostarcza
notacji pozwalającej na stworzenie diagramów:
• Przypadków
użycia (Use-Case) do zilustrowania interakcji pomiędzy użytkownikami
i systemami oraz ich odpowiedzialności
• Klas (Class) do
pokazania logicznej struktury programu
• Pakietów
(Package) – uchwycenie struktury pakietów
• Obiektów
(Object) do pokazania obiektów i powiązań między nimi
• Komponentów
(Components) do zapisania fizycznej struktury programu
• Wdrożeniowych
(Deployment) do pokazania powiązania między oprogramowaniem i
sprzętem
Charakterystyka diagramów – dynamiczne
• Przypadków
użycia
• Czynności
(Activity) do pokazania przepływu zdarzeń między elementami
oprogramowania
• Stany
(Statechart) do opisu zachowań (np. można projektować protokoły
komunikacyjne jako maszyny stanowe)
• Interakcji
(Interaction) do szczegółowego opisu zachowania:
-
Sekwencji (Sequence) opis sekwencji operacji
-
Komunikacji (communication)
Korzystając z
poszczególnych diagramów jesteśmy w stanie w prosty sposób uchwycić
wymagania dla budowanego oprogramowania. Zarówno te najbardziej
ogólne jak i szczegółowe.