Transcript The Rational Unified Process

The Rational Unified Process
Philippe Kruchten
P. O. S. I., wykład 2002-3
Rational Unified Process
Etapy
•
•
•
•
Inception
Elaboration
Construction
Transition
•
•
•
•
Rozpoczęcie
Opracowanie
Budowa
Przekazanie
Dyscypliny
•
•
•
•
•
•
Business Modeling
Requirements
Analysis and Design
Implementation
Test
Deployment
•
•
•
•
•
•
Modelowanie przedsięwzięć
Wymagania
Analiza i projektowanie
Implementacja
Testowanie
Wdrożenie
Dyscypliny
• Configuration and
Change Management
• Zarządzanie
konfiguracją i zmianami
• Project Management
• Zarządzanie projektem
• Environment
• Otoczenie
Architektura procesu
• Obraz dynamiczny: upływ czasu, cykl życia
projektu, etapy, iteracje, punkty etapowe.
• Obraz statyczny: komponenty procesu,
dyscypliny, przepływy czynności, czynności,
artefakty, pracownicy.
Modelowanie przedsięwzięcia
Business Modeling
Cele:
• Zrozumieć strukturę i dynamikę organizacji, w której
system ma być wdrożony (organizacji docelowej)
• Zrozumieć bieżące problemy organizacji docelowej
oraz możliwości dokonywania w niej ulepszeń
• Doprowadzić do uzyskania wspólnych poglądów
klientów, użytkowników, twórców systemu na
organizację docelową
• Sformułować wymagania na system niezbędne dla
właściwego wspierania przezeń tej organizacji
Aby to osiągnąć, trzeba
• Uzyskać wizję docelowej organizacji i na tej
podstawie określić - w ramach modelu
przedsięwzięcia - procesy, role i zakresy
odpowiedzialności w tej organizacji. Model ten
składa się z modelu przypadków użycia
przedsięwzięcia i z modelu obiektów
przedsięwzięcia.
Użytkownicy przedsięwzięcia:
klienci, sprzedawcy, wspólnicy
są przedstawiani jako
aktorzy przedsięwzięcia
(business actors)
Procesy przedsięwzięcia
(business processes)
są przedstawiane jako
przypadki użycia przedsięwzięcia
(business use cases)
albo
realizacje przypadków użycia przedsięwzięcia
(business use case realizations)
Role
(roles)
odgrywane przez ludzi w organizacji
są przedstawiane jako
pracownicy przedsięwzięcia
(business workers)
Byty
(things),
którymi organizacja zarządza
lub które produkuje
są przedstawiane jako
encje przedsięwzięcia
(business entities)
Możliwe scenariusze
•
•
•
•
•
•
1. Schemat organizacyjny
2. Modelowanie dziedziny
3. Jedno przedsięwzięcie, wiele systemów
4. Typowy model przedsięwzięcia
5. Kompletnie nowe przedsięwzięcie
6. Rekonstrukcja
Szczegóły
(tylko pierwsze rozpoczęcie)
• Oceń stan przedsięwzięcia
Szczegóły
(tylko modelowanie dziedziny)
• Opracuj model dziedziny
Szczegóły
(w modelowaniu przedsięwzięcia)
•
•
•
•
Opisz aktualny stan przedsięwzięcia
Wyznacz procesy przedsięwzięcia
Udoskonal definicje procesów przedsięwzięcia
Zaprojektuj realizacje procesów
przedsięwzięcia
• Udoskonal role i zakresy odpowiedzialności
• Zbadaj automatyzację procesów
Artefakty projektanta
przedsięwzięcia
•
•
•
•
•
•
Jednostka organizacyjna
Aktor przedsięwzięcia
Encja przedsięwzięcia
Pracownik przedsięwzięcia
Przypadek użycia przedsięwzięcia
Realizacja przypadku użycia przedsięwzięcia
Artefakty analityka procesów
przedsięwzięcia
•
•
•
•
Słownik przedsięwzięcia
Reguły przedsięwzięcia
Ocena organizacji docelowej
Wizja przedsięwzięcia
Artefakty analityka procesów
przedsięwzięcia
•
•
•
•
Model przypadków użycia przedsięwzięcia
Model obiektów przedsięwzięcia
Dokumentacja architektury przedsięwzięcia
Specyfikacja uzupełniająca przedsięwzięcia
Modelowanie przedsięwzięcia
Narzędzia
• Obrazy modeli: Rose
• Zbieranie danych tekstowych o modelach
przedsięwzięć: RequisitePro
• Generowanie i utrzymywanie dokumentacji:
SoDA
Wymagania
Requirements
Cele (str. 1)
• Uzyskać i utrzymać zgodę z klientami i innymi
uczestnikami co do tego, co system powinien
robić i dlaczego!
• Pomóc budowniczym systemu lepiej zrozumieć
wymagania systemu
• Określić granice systemu
Cele (str. 2)
• Stworzyć bazę dla planowania technicznej
treści iteracji.
• Stworzyć podstawy estymacji kosztów i czasu
budowy systemu
• Określić interfejs użytkownika dla systemu,
koncentrując się na potrzebach i celach
użytkowników
Aby to osiągnąć, trzeba
• Zdefiniować wizję systemu
• Przetłumaczyć tę wizję na model przypadków
użycia, który, razem ze specyfikacjami
uzupełniającymi, określa szczegółowe
wymagania na oprogramowanie systemu.
• Ustalić, jak używać atrybutów wymagań w
zarządzaniu zakresem i zmianami wymagań
systemu
Wymagania
• Funkcyjne
• Niefunkcyjne, np. dotyczące
–
–
–
–
cech użytkowych,
niezawodności,
wydajności,
podtrzymywalności itd.
Uczestnik
stakeholder
• Każdy człowiek lub przedstawiciel organizacji,
który ma istotny interes w rezultatach prac nad
projektem, którego potrzeby powinny być w tym
projekcie uwzględnione.
• Na przykład: użytkownik, nabywca, kontrahent,
kierownik projektu, budowniczy, administrator
systemu, ktokolwiek zainteresowany w pożytkach
z działania systemu.
[Existing System]
[New Input]
[New System]
Analyze
the Problem
[Incorrect
problem]
[Correct problem]
Understand
Stakeholder
Needs
Refine
the System
[Can’t do
Definition
all the work]
[Work
in scope]
Define
the System
Manage
the Scope
of the System
Manage
Changing
Requirements
Szczegóły
(nowy system)
• Analizuj problem
• Zrozum potrzeby uczestników
[Existing System]
[New Input]
[New System]
Understand
Stakeholder
Needs
Analyze
the Problem
[Incorrect
problem]
[Correct problem]
[Can’t do
all the work]
[Work
in scope]
Define
the System
Manage
the Scope
of the System
Refine
the System
Definition
Manage
Changing
Requirements
Szczegóły
(istniejący system)
• Zrozum potrzeby uczestników
[Existing System]
[New Input]
[New System]
Analyze
the Problem
[Incorrect
problem]
[Correct problem]
Define
the System
Manage
the Scope
of the System
Understand
Stakeholder
Needs
Refine
Manage
the System Changing
[Can’t do
Definition Requirements
all the work]
[Work
in scope]
Szczegóły
(nowe dane wejściowe)
• Zarządzaj zmianami wymagań
[Existing System]
[New Input]
[New System]
Understand
Stakeholder
Needs
Analyze
the Problem
[Incorrect
problem]
[Correct problem]
[Can’t do
all the work]
Define
the System
Manage
the Scope
of the System
[Work
in scope]
Refine
the System
Definition
Manage
Changing
Requirements
Szczegóły
(niepoprawny problem)
• Analizuj problem itd. jak poprzednio
[Existing System]
[New Input]
[New System]
Understand
Stakeholder
Needs
Analyze
the Problem
[Incorrect
problem]
[Correct problem]
[Can’t do
all the work]
Define
the System
Manage
the Scope
of the System
[Work
in scope]
Refine
the System
Definition
Manage
Changing
Requirements
Szczegóły
(problem jest poprawny)
• Definiuj system
• Panuj nad zasięgiem systemu
[Existing System]
[New Input]
[New System]
Analyze
the Problem
[Incorrect
problem]
[Correct problem]
Understand
Stakeholder
Needs
Refine
the System
Definition
[Can’t do
all the work]
[Work
in scope]
Define
the System
Manage
the Scope
of the System
Manage
Changing
Requirements
Szczegóły
(nie da się wszystkiego zrobić)
• Zrozum potrzeby uczestników jak poprzednio
[Existing System]
[New Input]
[New System]
Understand
Stakeholder
Needs
Analyze
the Problem
[Incorrect
problem]
[Correct problem]
[Can’t do
all the work]
Define
the System
Manage
the Scope
of the System
[Work
in scope]
Refine
the System
Definition
Manage
Changing
Requirements
Szczegóły
(zasięg systemu prawidłowy)
• Udoskonal definicję systemu
[Existing System]
[New Input]
[New System]
Analyze
the Problem
[Incorrect
problem]
[Correct problem]
Understand
Stakeholder
Needs
Refine
the System
Definition
[Can’t do
all the work]
Define
the System
Manage
the Scope
of the System
[Work
in scope]
Manage
Changing
Requirements
Artefakty analityka systemu
•
•
•
•
•
•
•
Słownik
Wizja
Model przypadków użycia
Żądania uczestników
Atrybuty wymagań
Plan zarządzania wymaganiami
Specyfikacja uzupełniająca
Artefakty specyfikatora
przypadków użycia
• Przypadek użycia
• Pakiet przypadków użycia
• Specyfikacja wymagań na oprogramowanie
Artefakty projektanta
interfejsu użytkownika
•
•
•
•
Aktor (człowiek)
Klasa brzegowa
Scenariusz przypadku użycia
Prototyp interfejsu użytkownika
Wymagania
Narzędzia
• Formułowanie wymagań i ujmowanie ich w
dokumentach: RequisitePro
• Obrazy modeli artefaktów wymagań: Rose
• Aktorzy i przypadki użycia: Use-Case Model,
Use-Case Storyboards, Boundary Classes.
• Generowanie i utrzymywanie dokumentacji:
SoDA
Analiza i Projektowanie
Analysis and Design
Cel
• Przetłumaczyć wymagania na specyfikację,
opisującą jak zaimplementować system.
Aby to osiągnąć, trzeba
• Zrozumieć wymagania
• Przetworzyć je w projekt systemu, dobierając
najlepszą strategię implementacji.
• Na początku tak dobrać architekturę, aby móc
zaprojektować system, który będzie łatwo
zrozumieć, budować i przekształcać.
dalej, trzeba
• Dostosować projekt do warunków, w jakich
będzie implementowany, aby, poza innymi
zaletami, gwarantował wydajność, odporność,
skalowalność i sprawdzalność systemu.
Celem analizy jest
• Przetworzenie wymagań do takiej postaci, która
dobrze pasuje do obszaru zainteresowania
projektanta oprogramowania, czyli do zbioru
klas i podsystemów.
(Ta transformacja jest ukierunkowana na
przypadki użycia, a jej wyniki będą zależeć od
niefunkcyjnych wymagań systemu).
Analiza a projektowanie
• Analiza koncentruje się na zapewnieniu
realizacji wymagań funkcyjnych systemu.
• Gwoli prostoty analiza może ignorować wiele
wymagań niefunkcyjnych oraz ograniczeń
narzucanych przez otoczenie projektu.
• Dobra analiza może dać prawie idealny obraz
systemu.
Cele projektowania
• Dostosować wyniki analizy do ograniczeń,
narzuconych przez wymagania niefunkcyjne,
warunki implementacji, wymagania dotyczące
wydajności itd.
• Projektowanie jest udoskonaleniem wyników
analizy. Koncentruje się na optymalizacji
projektu systemu, połączonej z równoczesnym
zapewnieniem spełnienia wszystkich wymagań.
Jak szczegółowy projekt?
• Projekt powinien definiować system na tyle
dokładnie, aby jego implementacja była
jednoznaczna.
• Interpretacja tego „na tyle” może się zmieniać
od projektu do projektu i od firmy do firmy.
• Stopień szczegółowości zależy od kompetencji
implementatora, złożoności projektu i stopnia
ryzyka popełnienia błędów konstruktorskich.
Przykłady skrajne
• System opracowany do szczegółów tak, że
implementacja może stać się bezpośrednią
systematyczną transformacją projektu na kod.
• Projekt przypominający szkic, który jest na tyle
szczegółowy, by implementator mógł
skompletować zbiór komponentów,
spełniających wymagania.
Inżynieria i inżynieria wstecz
(forward and backward engineering)
Gdy projekt jest dokładnie sformułowany, kod
można ściśle powiązać z jego treścią w taki
sposób, że można przechodzić od jednego do
drugiego i z powrotem z pomocą inżynierii oraz
inżynierii wstecz, co pozwala uniknąć zbędnych
kroków transformacji i potencjalnych źródeł
błędów.
Wykonywalność projektu
• Gdy kompletność i dokładność projektu są
bardzo wysokie, można wykonać całą
transformację albo drogą bezpośredniej
interpretacji projektu, albo przez szybkie
generowanie z niego niewielkich kawałków
kodu. Taka transformacja staje się prawie
niewidoczna dla projektanta i taki projekt staje
się „wykonywalny” .
Analiza i Projektowanie:
pracownicy i artefakty (1)
• Architekt
–
–
–
–
Model projektu
Model analizy
Interfejs
Dokumentacja architektury oprogramowania
Analiza i Projektowanie:
pracownicy i artefakty (2)
• Projektant
–
–
–
–
Realizacja przypadku użycia
Klasa
Pakiet projektu
Podsystem projektu
• Projektant bazy danych
– Model danych
Model projektu
• W jego skład wchodzi zbiór kooperacji elementów
systemu, wyrażających zachowanie systemu. Z kolei to
zachowanie wywodzi się głównie z modelu
przypadków użycia i z wymagań niefunkcyjnych.
Model projektu składa się kooperacji klas, które można
agregować w pakiety i w podsystemy, aby ułatwić
nadanie temu modelowi odpowiedniej organizacji i
budowanie składowych bloków konstrukcyjnych w
ramach tego modelu.
Model projektu
Pojęcie modelu projektu angażuje pojęcia
• Klas,
• Pakietów,
• Podsystemów.
Model projektu:
klasy, pakiety, podsystemy
• Klasa jest opisem zbioru obiektów mających takie
same zakresy odpowiedzialności, związki, operacje,
atrybuty i semantykę.
• Pakiet jest logiczną grupą klas, która służy celom
organizacyjnym i zmniejsza złożoność systemu.
• Podsystem jest to rodzaj pakietu, którego zbiór klas,
działających jako jedna jednostka, zapewnia mu
pewnego konkretne zachowanie,
Model analizy
• Model analizy jest abstrakcją, albo uogólnieniem,
projektu systemu. Daje przegląd funkcji systemu, lecz
pomija większą część szczegółowej wiedzy o pracy
systemu.
(Dodatkowa praca w celu zapewnienia zgodności
wyników analizy i projektu powinna być
zrównoważona korzyściami z posiadania takiej
perspektywy systemu, która pokazuje jedynie
najważniejsze szczegóły wiedzy o tym, jak działa
system.)
Rola interfejsów
• Służą do specyfikowania zachowań klas,
podsystemów i komponentów tak, by te
specyfikacje były niezależne od tego, jak te
zachowania są zaimplementowane.
• Specyfikują zbiory operacji wykonywane przez
elementy modelu, łącznie z typem wyników,
liczbą i typami parametrów każdej z nich.
Model przypadków użycia
• Jest to rezultat przepływu zadań dla wymagań,
gdzie przypadki użycia służą do zapisywania,
co z punktu widzenia użytkowników powinien
robić system. Służą więc jako wspólny język
dla klientów lub użytkowników oraz dla
budowniczych systemu. W analizie i
projektowaniu stanowią pomost między
wymaganiami i czynnościami projektowania.
Realizacja przypadku użycia
• Opisuje wykonywanie przypadku użycia jako
interakcji obiektów w modelu projektu. Obiekty
i klasy wyznacza się najczęściej w trakcie
przeglądania przypadków użycia. Ten sposób
postępowania daje pewność, że całe wymagane
zachowanie będzie przedstawione w projekcie
systemu.
Analiza i Projektowanie:
pracownicy i artefakty
systemów czasu rzeczywistego
• Projektant kapsuły
–
–
–
–
Kapsuła
Protokół
Zdarzenie
Sygnał
Artefakty czasu rzeczywistego:
objaśnienie (str. 1)
• Kapsuła jest to wzorzec projektowy,
przedstawiający wyodrębniony wątek
sterowania, z wejściami i wyjściami, przez
które komunikuje się z innymi kapsułami.
• Protokół specyfikuje sposoby komunikowania
się wejść i wyjść, wymiany komunikatów i
ustalania ich kolejności.
Artefakty czasu rzeczywistego:
objaśnienie (str. 2)
• Zdarzenie: specyfikacja czegoś, co się zdarzyło
w przestrzeni i czasie; pojawienie się czegoś, na
co system musi zareagować.
• Sygnał: asynchroniczne zdarzenie, które może
spowodować przejście do innego stanu w
maszynie stanowej obiektu.
(Te cztery artefakty są stereotypami klas i
częściami modelu projektu).
Projektowanie z komponentów
• Komponenty są elementami modelu implementacji,
które mają pokazywać, jak system jest
implementowany z mniejszych „kawałków”.
• Komponenty mają po jednym lub więcej interfejsów i
zależą jedynie od interfejsów do innych komponentów.
• Używanie komponentów pozwala projektować,
implementować, dostarczać i wymieniać rozmaite
części systemu niezależnie od reszty tego systemu.
Analiza i projektowanie
Szczegóły
•
•
•
•
•
•
Definiuj architekturę kandydującą
Analizuj zachowanie
Projektuj komponenty
Projektuj komponenty czasu rzeczywistego
Projektuj bazę danych
Udoskonal architekturę
Definiuj architekturę kandydującą
Cele (str. 1)
• Przygotować wstępny szkic architektury
systemu, definiując
– początkowy zbiór elementów istotnych dla
architektury, jako bazę dla analizy,
– początkowy zbiór mechanizmów analizy,
– początkowy podział systemu na warstwy oraz
organizację systemu,
– realizacje przypadków użycia, którymi należy się
zająć w tej iteracji.
Definiuj architekturę kandydującą
Cele (str. 2)
• Wyznaczyć klasy analizy spośród istotnych dla
architektury przypadków użycia
• Zaktualizować realizacje przypadków użycia z
interakcjami klas analizy
Definiuj architekturę kandydującą
Objaśnienie (3)
• Podział systemu na warstwy
Definiuj architekturę kandydującą
Objaśnienie (4)
• Organizacja systemu
Definiuj architekturę kandydującą
Objaśnienie (5)
• Klasa analizy
Definiuj architekturę kandydującą
Objaśnienie (6)
• Realizacja przypadku użycia
Definiuj architekturę kandydującą:
pracownicy i czynności
• Czynności architekta:
– Analiza architektoniczna
• Czynności projektanta:
– Analiza przypadków użycia
Analiza i projektowanie
Szczegóły
•
•
•
•
•
•
Definiuj architekturę kandydującą
Analizuj zachowanie
Projektuj komponenty
Projektuj komponenty czasu rzeczywistego
Projektuj bazę danych
Udoskonal architekturę
Analizuj zachowanie
Cele
• Przekształcić opisy zachowania w postaci
przypadków użycia w zbiór elementów, na
których oprze się projekt. Zauważmy, że w
większym stopniu zwraca się tu uwagę na
zapewnienie niezbędnych właściwości aplikacji,
niż na wymagania niefunkcyjne dla tego
systemu.
Analizuj zachowanie:
pracownicy i czynności
• Projektant
– Analiza przypadku użycia
• Architekt
– Wyznaczenie elementów projektu
• Recenzent projektu
– Recenzja projektu
Analiza i projektowanie
Szczegóły
•
•
•
•
•
•
Definiuj architekturę kandydującą
Analizuj zachowanie
Projektuj komponenty
Projektuj komponenty czasu rzeczywistego
Projektuj bazę danych
Udoskonal architekturę
Projektuj komponenty
Cele (str. 1)
• Udoskonalić definicje elementów projektu, opisując w
szczegółach, jak ma być implementowane takie
zachowanie tych elementów, jakiego się od nich
oczekuje.
• Udoskonalić i zaktualizować realizacje przypadków
użycia korzystających z nowo wprowadzonych
elementów projektu, uzyskując tak aktualność
realizacji tych przypadków użycia.
• Recenzować projekt w miarę jego zmian.
Projektuj komponenty
Cele (str. 2)
• Po ukończeniu projektowania komponentów
mają być całkowicie wyspecyfikowane
– charakterystyki klas i ich związki,
– interfejsy podsystemów i ich realizowanie z pomocą
zawartych w nich klas,
– realizacje przypadków użycia ujęte w terminologii
współdziałań
Projektuj komponenty:
pracownicy i czynności
• Projektant
– Projekt przypadku użycia
– Projekt klasy
– Projekt podsystemu
• Recenzent projektu
– Recenzja projektu
Analiza i projektowanie
Szczegóły
•
•
•
•
•
•
Definiuj architekturę kandydującą
Analizuj zachowanie
Projektuj komponenty
Projektuj komponenty czasu rzeczywistego
Projektuj bazę danych
Udoskonal architekturę
Projektuj komponenty czasu rzeczywistego
Cele
• Podobne jak w przypadku projektowania
komponentów, z wyjątkiem tego, że tutaj ważną
rolę odgrywa kapsuła, jako artefakt używany do
definiowania współbieżnych wątków kontroli
systemu i protokołów współpracy między nimi.
Projektuj komponenty czasu rzeczywistego:
pracownicy i czynności
• Projektant
– Projekt przypadku użycia
– Projekt klasy
– Projekt podsystemu
• Projektant kapsuły
– Projekt kapsuły
• Recenzent projektu
– Recenzja projektu
Analiza i projektowanie
Szczegóły
•
•
•
•
•
•
Definiuj architekturę kandydującą
Analizuj zachowanie
Projektuj komponenty
Projektuj komponenty czasu rzeczywistego
Projektuj bazę danych
Udoskonal architekturę
Projektuj bazę danych
Cele
• Wyznaczyć w projekcie klasy trwałe
• Zaprojektować właściwe struktury bazy danych
do przechowywania trwałych klas.
• Określić mechanizmy i strategie
przechowywania i wyszukiwania trwałych
danych w taki sposób, by spełnić przyjęte dla
systemu kryteria wydajności.
Projektuj bazę danych:
pracownicy i czynności
• Projektant
– Projekt klasy
• Projektant bazy danych
– Projekt bazy danych
• Recenzent projektu
– Recenzja projektu
Analiza i projektowanie
Szczegóły
•
•
•
•
•
•
Definiuj architekturę kandydującą
Analizuj zachowanie
Projektuj komponenty
Projektuj komponenty czasu rzeczywistego
Projektuj bazę danych
Udoskonal architekturę
Udoskonal architekturę
Cele (str. 1)
• Zapewnić normalne przejście od czynności
analizy do czynności projektowania,
wyznaczając:
– Właściwe elementy projektu spośród elementów
analizy,
– Właściwe mechanizmy projektowania spośród
odpowiadających im mechanizmów analizy.
Udoskonal architekturę
Cele (str. 2)
• Utrzymać zwartość i spójność architektury,
dbając o to, by
– nowe elementy projektu, wyznaczone dla bieżącej
iteracji, zostały właściwie zintegrowane z poprzednio
istniejącymi elementami projektu, oraz by
– osiągnąć możliwie wcześnie maksymalne możliwości
ponownego wykorzystania dostępnych komponentów
i elementów projektu
Udoskonal architekturę
Cele (str. 3)
• Opisać organizację systemu w czasie jego pracy
oraz architekturę wdrożenia.
• Zorganizować model implementacji, aby
przejście pomiędzy projektem a implementacją
było ciągłe (bez „szwów”).
Udoskonal architekturę:
pracownicy i czynności
• Czynności architekta:
Wyznacz mechanizmy projektowania,
Wyznacz elementy projektowania,
Dołącz istniejące elementy projektu,
Opisz architekturę w czasie działania,
Opisz dystrybucję .
Udoskonal architekturę:
pracownicy i czynności
• Czynności recenzenta architektury:
Zrecenzuj architekturę.
Artefakty architekta
•
•
•
•
Model analizy
Model projektu
Interfejs
Dokumentacja architektury oprogramowania
Artefakty architekta
(komponenty czasu rzeczywistego)
•
•
•
•
•
•
•
Model analizy
Model projektu
Interfejs
Zdarzenie
Sygnał
Protokół
Dokumentacja architektury oprogramowania
Artefakty projektanta
•
•
•
•
Realizacja przypadku użycia
Klasa
Pakiet projektu
Podsystem projektu
Artefakt projektanta kapsuły
• Kapsuła
Artefakt projektanta
bazy danych (jeśli jest)
• Model danych
Najważniejsze są:
• Model projektu, który jest głównym szkicem
konstruowanego systemu.
• Dokumentacja architektury oprogramowania,
która ujmuje rozmaite perspektywy
architektoniczne systemu.
Analiza i projektowanie
Narzędzia
• Obrazy modeli: Rose
• Bezpośrednie wykonanie modelu projektu:
Rose Real Time
• Generowanie i utrzymywanie dokumentacji:
SoDA
Implementacja
Implementation
Cele
• Określić organizację kodu w terminach implementacji
podsystemów poukładanych w warstwy.
• Implementować klasy i obiekty w ramach
komponentów (pliki źródłowe, wykonywalne, binaria i
inne) .
• Testować zbudowane komponenty jako jednostki.
• Zintegrować wyniki prac zespołów lub pojedynczych
implementatorów w jeden wykonywalny system.
Testy w przepływie zadań
implementacji
• Testowanie w ramach przepływu zadań
implementacji sprowadza się do testowania
pojedynczych komponentów (bo to właśnie
należy do obowiązków implementatorów).
• W praktyce przepływy zadań implementacji
oraz testowania są ze sobą przeplecione.
Podstawowe pojęcia implementacji
• Wyrób
• Integracja
• Prototypy
• Build
• Integration
• Prototypes
Wyrób
• Operacyjna wersja systemu albo część systemu,
demonstrująca pewien podzbiór zestawu
możliwości końcowego produktu.
O wyrobach
• W iteracyjnym procesie budowy oprogramowania
powstają liczne wyroby, które w miarę ich pojawiania
będą ułatwiać przeprowadzanie wczesnych kontroli
oraz wykrywanie kłopotów z integracją zaraz jak tylko
one powstają.
• Każdy wyrób ma podlegać kontroli konfiguracji, by
umożliwić wycofanie do wcześniejszej wersji, gdy
rozbudowywanie funkcji spowoduje błąd lub inaczej
naruszy spójność wyrobu.
Integracja
• Czynność budowy oprogramowania, w czasie
której oddzielne komponenty oprogramowania
są składane w jedną całość.
Cele integracji:
• Scalić wyniki pracy zespołu pracującego nad
tym samym podsystemem przed przekazaniem
go integratorom systemu.
• Scalić podsystemy w jeden kompletny system.
Integracja narastająca
Incremental integration
• Kod pisze się i testuje w małych kawałkach.
• Składa się go w działającą całość, dodając po
jednym kawałku na raz.
Zalety narastającej integracji
• Łatwość wykrywania błędów: w razie kłopotów bada
się najpierw nowy komponent lub jego otoczenie.
• Komponenty są scalane i sprawdzane w czasie ich
budowy, częściej i dokładniej niż trakcie integracji
dokonywanej w jednym kroku.
• Fakt, że pewne komponenty były pomyślnie
uruchomione wcześniej, działa lepiej na pracowników
niż oczekiwanie na wyniki testów po jednorazowym
scaleniu wszystkiego.
Prototypy
• Służą obniżaniu zagrożeń, zwłaszcza mogą
pomóc rozstrzygnąć wątpliwości dotyczące
takich spraw, jak
Zakresy badań
• Możliwość wykorzystania proponowanego
produktu dla przewidywanych celów.
• Stabilność lub wydajność kluczowych
rozwiązań technicznych.
• Sensowność zaangażowania się w prace
projektowe albo finansowanie.
• Rozumienie wymagań.
• Wygląd i właściwości, a w ostatecznym
rachunku użyteczność rozważanego produktu.
Rodzaje prototypów
• Jakim badaniom mają służyć?
– Zachowania systemu.
– Struktury: architektury lub budowy.
• Jakim zmianom będą podlegać?
– Prototyp do badań doraźnych, wyrzucany po ich
zakończeniu.
– Prototyp ewoluujący aż do końcowej formy
systemu.
Prototypy do badań zachowania
• Na ogół są to prototypy do wyrzucenia po
ukończeniu badań, które nie mają odtwarzać
architektury opracowywanego systemu, ale
raczej mają przedstawiać go od strony
użytkowników. Często są one szybko i niedbale
budowane, „quick and dirty”, bez
zachowywania ścisłych reguł projektowania.
Prototypy do badań struktury
• Na ogół są to prototypy ewoluujące, które
korzystają z infrastruktury systemu w jego
postaci końcowej, czyli tej, ku której ewoluują.
Budując prototyp z pomocą zestawu narzędzi i
języków używanych przy budowie systemu,
stwarza się szansę wcześniejszego sprawdzenia
nowych narzędzi i procedur.
Prototypy do badań doraźnych
• Służą sprawdzeniu konkretnych założeń o
funkcjach systemu, technologii, lub obu tych
sprawach na raz. Mogą składać się z kilkuset
wierszy kodu dla sprawdzenia własności
konkretnego komponentu sprzętu lub
oprogramowania. Mogą też służyć do lepszego
wyjaśnienia wymagań a nawet do kontroli, czy
dobrze rozumie się jakiś warunek techniczny.
Prototypy ewoluujące
• Ewoluują poprzez kolejne iteracje i choć na
początku mogą nie spełniać wymagań jakości
obowiązujących dla budowy systemu, na ogół
kod jest w miarę upływu czasu poprawiany.
Aby nad tym panować, stosuje się z reguły
sformalizowane zasady budowy i dokładnego
testowania i to w miarę zaawansowania prac w
coraz większym stopniu.
Zalecenie
• RUP doradza zbudowanie jednego prototypu
ewoluującego w etapie opracowania oraz
pewnej liczby towarzyszących mu prototypów
do badań doraźnych.
Implementacja
Szczegóły przepływu zadań
•
•
•
•
•
Opracuj strukturę modelu implementacji
Opracuj plan integracji
Implementuj komponenty
Integruj każdy podsystem
Integruj system
Dla każdej iteracji należy wykonać
(1)
• Zaplanować, które podsystemy powinny być
zaimplementowane oraz kolejność, w jakiej
podsystemy należy scalać w bieżącej iteracji (co
opisuje Plan integracji).
Dla każdej iteracji należy wykonać
(2)
• Dla każdego podsystemu odpowiedzialny zań
implementator planuje jego scalenie, to znaczy
określa, w jakiej kolejności będzie się
implementować jego klasy.
Dla każdej iteracji należy wykonać
(3)
• Implementatorzy implementują klasy i obiekty z
modelu projektu: piszą kod źródłowy, adaptują
istniejące komponenty, kompilują, łączą oraz
wykonują. Jeśli znajdą w projekcie defekty,
przekazują żądania dokonania w nim
odpowiednich przeróbek.
Dla każdej iteracji należy wykonać
(4)
• Implementatorzy znajdują również defekty
kodu i wykonują testy poszczególnych
jednostek po wprowadzeniu w nich zmian.
Potem kod jest sprawdzany pod względem
jakości i zgodności z podręcznikami
oprogramowania.
Dla każdej iteracji należy wykonać
(5)
• W zespole wielu implementatorów, pracujących przy
jednym podsystemie, jeden z nich jest odpowiedzialny
za scalanie nowych i zmienionych komponentów.
Otrzymuje je od poszczególnych implementatorów i
scala w nową wersję implementowanego podsystemu.
W ten sposób w polu integracji zespołu pojawia się
czasie takiego scalania sekwencja wyrobów. Każdy z
nich zostaje poddany testowi integracji. Ostateczna
wersja podsystemu zostaje przekazana do scalania
systemu.
Dla każdej iteracji należy wykonać
(6)
• Integrator systemu, działając zgodnie z Planem
Integracji Wyrobów, integruje system,
przekazując wykonane podsystemy do pola
integracji i tworząc kolejne wyroby. Każdy
wyrób przechodzi test integracyjny. Po
dołączeniu ostatniego podsystemu wyrób
można poddać testowi systemu.
Implementacja
Szczegóły
•
•
•
•
•
Opracuj strukturę modelu implementacji
Planuj integrację
Implementuj komponenty
Integruj każdy podsystem
Integruj system
Artefakt Architekta
• Model Implementacji
Artefakt Integratora Systemu
• Plan integracji wyrobów
Artefakty Implementatora
• Komponent
• Podsystem implementacji
Implementacja
Narzędzia
• Na poziomie kodu narzędzia tradycyjne:
edytory, komplilatory, programy łączące,
debuggery itp.
• Rose.
• Wykrywanie defektów kodu: Purify, Quantify.
• Obsługa pól roboczych integracji oraz wsparcie
integracji podsystemów i systemu: ClearCase.
Testy
Tests
Cele
• Celem testowania jest ocena jakości produktu.
To dotyczy nie tylko produktu końcowego, ale
zaczyna się we wcześniejszych stadiach
projektu oceną architektury i jest kontynuowane
aż do ocen produktów końcowych, które są
dostarczane klientom.
Przepływ zadań dyscypliny Testy
obejmuje:
• Sprawdzanie interakcji komponentów
• Sprawdzanie właściwej integracji komponentów
• Sprawdzanie, czy wszystkie wymagania zostały
poprawnie zaimplementowane
• Wykrywanie błędów i kontrolowanie, czy zajęto
się wszystkimi wykrytymi defektami jeszcze
przed przystąpieniem do wdrażania
oprogramowania
Jakość
• W zwykłym rozumieniu oznacza to wiele
rzeczy: głównie brak defektów, ale, co jest
nawet ważniejsze, także zgodność z założonym
przeznaczeniem – coś obdarzone jakością
działa tak, jak się tego od niego się oczekuje.
Rzecz wolna od defektów, ale nie działająca tak
jak trzeba, jest tak samo bezużyteczna jak
produkt z defektami.
Cele (str. 2)
• Ostatecznym celem testowania jest ocena
jakości produktu końcowego, a przez to także
ocena jakości komponentów, które się nań
składają oraz architektury, która nadaje formę
tym komponentom.
Cele (str. 3)
• Taka ocena ma dać pewność, że ten produkt
spełnia, dokładnie albo z nadwyżką, zadany i
zatwierdzony zestaw wymagań, na podstawie
ocen dokonanych z pomocą zadanych i
zatwierdzonych kryteriów i metod pomiaru.
Jakość
• Oceny jakości nie można dokonywać w
całkowitej izolacji – oprogramowanie jest
wykonywane w organizacjach, stosujących
pewne procesy. Kiepski proces, albo taki, który
nie jest poprawnie przeprowadzany, może być
znaczącym powodem złej jakości. Wobec tego
oceny jakości zwykle biorą pod uwagę jakość
procesu i walory organizacji na równi z
rozumianą bezpośrednio jakością produktu.
Jakość
• Za wytworzenie produktu dobrej jakości
odpowiada każdy projektant w zespole. Nie
może tego zapewnić żadna organizacja od
„zapewnienia jakości”. Jeśli nie zaprojektuje się
i nie zbuduje produktu dobrej jakości od samego
początku, to nie będzie można „dodać” jej
później nawet z pomocą bardzo agresywnych
zabiegów zapewniania jakości.
Testowanie w procesie iteracyjnym
• Nie jest to pojedyncza czynność, ani etap
projektu, w którym oceniałoby się jakość. Jeśli
budowniczowie systemu mają otrzymywać na
czas informacje o zmieniającej się jakości
produktu, trzeba wykonywać testy w ciągu
całego cyklu jego życia.
Testowanie w procesie iteracyjnym
• Zbyt rozpowszechniony pogląd, że testowanie
jest rodzajem końcowego sprawdzenia, że
wszystko dobrze działa, pomija podstawową
zaletę prawidłowego podejścia: zapewnić
możliwość zareagowania na usterki, kiedy
jeszcze jest czas (i zasoby), aby można było z
nimi coś zrobić.
Klasyfikacje testów
• Ocena jakości produktu wymaga stosowania
różnych rodzajów testów, klasyfikowanych
według różnych działów lub grup spraw
(zwanych tu zakresami, dimensions):
– Zakres jakości: główna cecha lub atrybut jakości,
będąca przedmiotem testu
– Moment (etap), w którym się testuje,
– Typ testu: według konkretnego przeznaczenia.
Zakresy jakości
• Niezawodność: odporne na usterki w czasie
działania, nie ma przerw, zawieszania się,
przecieków pamięci itp.
• Funkcje: zachowanie i wykonanie przypadków
użycia są zgodne z oczekiwaniami.
• Działanie: zachowuje się zadowalająco w
warunkach normalnej pracy.
Testy według etapów (str. 1)
• Test jednostkowy: Indywidualne testowanie
najmniejszych testowalnych elementów, zwykle
w tym samym czasie, gdy są implementowane .
• Test integracji: Testowanie integrowanych
jednostek, albo komponentów, albo
podsystemów.
Testy według etapów (str. 2)
• Test systemu: Testowanie kompletnej aplikacji
(jednej lub więcej) i kompletnego systemu
• Test odbiorczy: Testowanie kompletnej aplikacji
albo systemu przez użytkowników (albo ich
przedstawicieli) w celu sprawdzenia gotowości
do wdrożenia.
Typy testów
•
•
•
•
•
•
•
•
Test szybkości
Test konfiguracji
Test funkcji
Test instalacji
Test integralności
Test obciążeń
Test wydajności
Test przeciążenia
Benchmark Test
Configuration Test
Function Test
Installation Test
Integrity Test
Load Test
Performance Test
Stress Test
Test szybkości
• Porównuje wydajność, wyrażoną przez wyniki
testowania, ze znanym wzorcem, takim jak
istniejące oprogramowanie albo wyniki pomiaru
lub pomiarów.
Test konfiguracji
• Sprawdza, czy działanie podmiotu testowania
dla rozmaitych konfiguracji sprzętu i
oprogramowania jest do przyjęcia.
Test funkcji
• Sprawdza, czy podmiot testowania działa
poprawnie, realizując wybrane dla tego testu
przypadki użycia zgodnie z oczekiwaniami.
Test instalacji
• Sprawdza, czy podmiot testowania poprawnie
się instaluje lub może być skutecznie
zainstalowany w różnych konfiguracjach lub w
rozmaitych warunkach, na przykład takich, jak
niewystarczająca przestrzeń dyskowa.
Test integralności
• Sprawdza niezawodność, wytrzymałość lub
odporność podmiotu testowania na usterki
występujące w czasie jego działania.
Test obciążenia
• Sprawdza poprawność działania podmiotu
testowania w rozmaitych warunkach pracy,
takich jak liczba użytkowników, liczba
transakcji itd., gdy konfiguracja pozostaje stała.
Test wydajności
• Sprawdza czy wydajność podmiotu testowania
jest do przyjęcia dla różnych konfiguracji, gdy
warunki pracy pozostają stałe.
Test przeciążenia
• Sprawdza czy wydajność podmiotu testowania
jest do przyjęcia w warunkach nienormalnych
lub skrajnych, jak uszczuplone zasoby albo
skrajnie duża liczba użytkowników.
Testy regresji
• Jest to strategia testowania, w której poprzednio
wykonywane testy powtarza się na innej wersji
podmiotów, aby przekonać się, że po dodaniu
nowych właściwości jakość tych podmiotów nie
uległa obniżeniu(regresji). Na ogół testy regresji
można wykonywać dla testów każdego typu.
Często pewne testy regresji wykonuje się dla
każdej iteracji, powtarzając testy z iteracji
poprzednich.
Testy regresji mają sprawdzić, czy
• Poprzednio wykryte defekty zostały objęte
nowym sprawdzeniem.
• Zmiany w kodzie nie spowodowały
wprowadzenia nowych błędów albo odnowienia
starych.
Model testu
• Przedstawienie tego, co będzie testowane i jak
będzie testowane.
Model testu
zawiera
•
•
•
•
•
•
Przypadki testowania
Procedury testowania
Scenariusze testowania
Klasy i komponenty testów
Kooperacje testów
Notatki o testowaniu
Przypadki testowania
• Zbiory danych testowych, warunków wykonania oraz
oczekiwanych wyników testów, przygotowane dla
konkretnego podmiotu i warunków testu.
• Przypadki testowania można wyprowadzić z
przypadków użycia, dokumentacji projektu lub kodu
oprogramowania.
• Przypadek testowania można zaimplementować z
pomocą jednej lub więcej procedur testowania.
Procedury testowania
• Zbiór szczegółowych instrukcji ustawiania,
wykonywania i oceny wyników testów dla przypadków
testowania.
• Procedura testowania może implementować jeden lub
więcej przypadek testowania.
• Procedura testowania może także implementować tylko
część przypadku testowania, np. tylko jeden z
przepływów alternatywnych w przypadku użycia.
Scenariusze testowania
• Instrukcje, czytelne dla komputera, które
automatyzują wykonywanie procedur
testowania.
• Scenariusz testowania automatyzuje wykonanie
w całości lub części jednej lub więcej procedur
testowania.
Klasy i komponenty testów
• Klasy i komponenty, które realizują projekty
testów.
Kooperacje testów
• Kooperacje, pokazywane w postaci diagramów
kooperacji lub diagramów przebiegów, które
przedstawiają występujące w trakcie testowania
sekwencje czasowe przepływów komunikatów
pomiędzy komponentami i podmiotami testów.
Notatki o testowaniu
• Informacje tekstowe, opisujące ograniczenia
albo dodatkowe informacje wprowadzone do
modelu testu.
• Takie notatki mogą być przyłączane do
dowolnego elementu modelu testu.
Artefakty projektanta testu
• Projektant testu jest odpowiedzialny za
panowanie, projektowanie, implementację i
ocenę wyników testowania. To obejmuje też
generowanie planu testowania i modelu testu,
implementowanie procedur testowania, ocenę
kompletności testu, wyników i skuteczności.
Przygotowuje modele obciążenia dla testów
wydajności.
Artefakty testera
• Tester jest odpowiedzialny za wykonanie testów
systemu. To obejmuje też nastawianie i
wykonywanie testów, ocenę wykonania testów,
odnowy po błędach, ocenianie wyników
testowania i zapisywanie żądań zmian.
Artefakty projektanta testu
• Klasy testu
• Pakiety testu
Artefakty implementatora testu
• Komponenty testu
• Podsystemy testu
Testy
Narzędzia
• Wspomaganie implementacji, wykonywania i
oceny testów: TestStudio
• Wspomaganie implementacji i wykonywania
scenariuszy testów wirtualnego użytkownika:
PerformanceStudio
• Wykrywanie trudnych błędów, nietestowanego
kodu i zakleszczeń: DevelopmentStudio
Testy
Narzędzia : TestStudio
•
•
•
•
Robot
LogViewer
TestManager
TestFactory
Testy
PerformanceStudio
• Implementuje i wykonuje (dla wirtualnego
użytkownika) scenariusze testowania
wydajności, a w ograniczonym zakresie także
testowania funkcji.
Testy
Narzędzia : DevelopmentStudio
• Rational Purify
• Rational PureCoverage
• Rational Quantify
Zarządzanie konfiguracją i
zmianami
Configuration and Change Management
Funkcje zarządzania konfiguracją
i zmianami
• Zarządzanie konfiguracją
• Zarządzanie żądaniami zmian
• Kontrola struktury projektu
Konfiguracja
• Niesprzeczny zbiór wzajemnie powiązanych
artefaktów
Zarządzanie konfiguracją
• Dotyczy spraw identyfikacji artefaktów, wersji,
zależności między artefaktami oraz
identyfikacji konfiguracji
• Dotyczy kwestii przydzielania przestrzeni
roboczych pojedynczym pracownikom i
zespołom, aby mogły pracować bez
następowania sobie wzajemnie na palce.
Przestrzeń robocza
• Wydziela potrzebującym „piaskownice”, w
których pracownicy lub małe zespoły mogą
pracować w izolacji od innych.
• Zapewnia każdemu pracownikowi lub
zespołowi dostęp do potrzebnego mu zbioru
artefaktów.
• Można jej używać do wykonywania prac
konstrukcyjnych lub scalania wyrobów
Żądanie zmian
• Udokumentowana propozycja zmiany w
jednym lub więcej artefaktach, sformułowana,
aby, na przykład,
–
–
–
–
Usunąć usterkę
Polepszyć jakość produktu
Dodać wymaganie
Udokumentować różnice pomiędzy produktami
otrzymanymi w kolejnych iteracjach.
Żądanie zmian: maszyna stanowa
• Przykładowe stany: nowe, zapisane,
zatwierdzone, przydzielone, wykonane.
• Przejściom od stanu do stanu towarzyszy
dopisanie informacji o zmianie: powód zmiany,
uzasadnienie, artefakty, których zmiana dotyczy
(i które trzeba zmieniać w tym samym czasie),
wpływy zmian na projekt, architekturę, koszty,
terminarz.
Wykonywanie żądań
• Decyzja o wykonaniu żądania należy do
kierownictwa, które musi uwzględniać takie
sprawy, jak wzajemne oddziaływania,
priorytety, wersje i możliwe terminy.
Rada Kontroli Zmian
Change Control Board
• Składa się z przedstawicieli wszystkich
zainteresowanych stron, w tym klientów,
konstruktorów i użytkowników.
• Jej rola polega na ocenianiu wpływów zmian,
określaniu priorytetów, podejmowaniu decyzji o
zatwierdzaniu zmian.
Realizacja żądania zmian
• Wybór konkretnego przepływu zadań zależy od
typów zmienianych artefaktów i wzajemnych
zależności między nimi. Jeżeli wykonanie
zadania wymaga z kolei wykonania innych, to
te także będą włączone do tego przepływu itd.
• Każda zmiana artefaktu ma przydzielone
żądanie zmiany, zamykane po jej wykonaniu,
przetestowaniu i włączeniu do właściwej wersji.
Zarządzanie konfiguracją i
zmianami: Szczegóły
• Planuj kontrolę konfiguracji i zmian projektu
• Uformuj wyposażenie zarządzania konfiguracją
projektu
• Zmieniaj i dostarczaj fragmenty konfiguracji
• Zarządzaj bazami odniesienia i wersjami
• Monitoruj i melduj sytuacje konfiguracji
• Zarządzaj żądaniami zmian
Planuj kontrolę konfiguracji
i zmian projektu
• Plan opisuje wszystkie czynności, które muszą
być przygotowywane i wykonywane w czasue
trwania projektu.
• Opisuje procedury i metody stosowane do
identyfikowania, ochrony i zapisywania w
raportach wszystkich artefaktów generowanych
w czasie trwania projektu.
Uformuj wyposażenie zarządzania
konfiguracją projektu: Cele
• Wyposażenie stanowisk pracy, na których będą
dostępne wszystkie niezbędne do pracy
artefakty i na których produkt będzie
konstruowany, scalany i archiwizowany dla
dalszego przechowywania i wykorzystania.
• Dostarczanie konstruktorom i integratorom
prywatnych i wspólnych przestrzeni roboczych
do budowy i scalania oprogramowania.
Zmieniaj i dostarczaj fragmenty
konfiguracji
• W ramach swej przestrzeni roboczej pracownik
może uzyskiwać dostęp do artefaktów projektu,
dokonywać w nich zmian, przekazywać te
zmiany w celu włączenia do całości projektu.
• Zmiany są przekazywane do przestrzeni
roboczej integracji, która może przyjmować je
od wielu pracowników. Integrator Systemu
buduje z nich produkt.
Zarządzaj bazami odniesienia i
wersjami
• Baza odniesienia jest opisem tych wszystkich
wersji artefaktów, z których można w
dowolnym momencie ułożyć produkt.
• Zwykle bazy odniesienia tworzy się w końcach
iteracji, punktach etapowych projektów i przed
odbiorami.
Zarządzaj bazami odniesienia i
wersjami: Cele
• Prowadzić i nadzorować bazy odniesienia i
wersje
• Sprawdzać bazę odniesienia każdego produktu,
który jest przekazywany klientowi.
• Korzystać z baz odniesienia w przypadkach
napraw produktów i rekonstruowania wersji.
Monitoruj i melduj sytuacje
konfiguracji
• Wyposażenie kontroli konfiguracji tworzy
otoczenie całej pracy nad budową
oprogramowania. Wszystkie artefakty powinny
być poddane kontroli konfiguracji, zaś
zarządzający kontrolą konfiguracji odpowiada
za tworzenie przestrzeni roboczych, gdy
konstruktorzy i integratorzy mają podjąć swą
pracę.
Obowiązki zarządzającego
kontrolą konfiguracji
•
•
•
•
•
Nadzorować kontrolę konfiguracji
Gospodarować przestrzeniami roboczymi
Pilnować bezpieczeństwa zasobów projektu
Składać raporty o stanie konfiguracji
Przez to umożliwiać śledzenie postępów
projektu oraz pojawiających się tendencji.
Zarządzaj żądaniami zmian
Cele
• Zapewnić niesprzeczność zmian w projekcie
• Informować właściwych uczestników o
– stanie produktu,
– zmianach,
– wpływie zmian na koszty i terminarz.
Unified Change Management
UCM
• Jest to metoda zarządzania zmianami w całym cyklu
życia systemu oprogramowania, od wymagań aż do
prowadzenia wersji.
• Umożliwia jednolite zarządzanie zmianami wymagań,
modeli projektu, dokumentacji, komponentów,
przypadków testowania oraz kodów źródłowych.
• Używana w ClearCode i ClearQuest
Zarządzanie
konfiguracją i zmianami
Narzędzia
• Wspomaganie zarządzania konfiguracją:
ClearCase
• Wspomaganie zarządzania żądaniami zmian
oraz części oceny sytuacji i wyników
pomiarów: ClearQuest
Zarządzanie projektem
Project Management
Dobra praktyka
budowy oprogramowania
Czyli dlaczego się tym wszystkim
w ogóle zajmujemy?
Objawy kłopotów z projektowaniem
• Zbyt wiele projektów natrafia na trudności i to z
najrozmaitszych powodów, ale można wyliczyć
spis objawów, ktore są typowe właśnie dla
takich projektów.
Objawy kłopotów z projektowaniem
d.c.
• Niedokładne rozumienie potrzeb użytkowników
końcowych
• Nie radzenie sobie ze zmiennością wymagań
• Nie pasujące do siebie moduły
Objawy kłopotów z projektowaniem
d.c.
• Oprogramowanie, które trudno utrzymywać
albo rozbudować
• Późne wykrycie poważnych wad projektu
• Kiepska jakość oprogramowania
Objawy kłopotów z projektowaniem
d.c.
• Niedopuszczalnie złe właściwosci
oprogramowania
• Zła współpraca zespołu, uniemożliwiająca
ustalanie, kto co zmieniał, kiedy, gdzie i
dlaczego.
• Proces budowania i przekazywania, na którym
nie można polegać.
Podstawowe przyczyny kłopotów
• Choć różne projekty napotykają na
niepowodzenia w rozmaity sposób, to w
większości przypadków jest to rezultatem
działania pewnych kombinacji następujących
przyczyn podstawowych
Podstawowe przyczyny (1)
• Zarządzanie wymaganiami od przypadku do
przypadku.
• Przekazywane informacje są wieloznaczne lub
nieścisłe.
• Przesztywniona i krucha architektura.
Podstawowe przyczyny (2)
• Przytłaczające zagmatwanie.
• Niewykryte niezgodnosci wymagań, projektu i
implementacji.
• Niedostateczne testowanie.
• Subiektywne ocenianie stanu projektu.
Podstawowe przyczyny (3)
• Zaniechanie usuwania zagrożeń.
• Niekontrolowana propagacja zmian.
• Niedostateczna automatyzacja.
Rozwiązania podstawowych
problemów: 6 zasad dobrej praktyki
•
•
•
•
•
•
1. Budowanie oprogramowania iteracyjnie.
2. Panowanie nad wymaganiami.
3. Budowanie z komponentów.
4. Używanie poglądowych modeli.
5. Ciągła kontrola jakości oprogramowania.
6. Kontrolowanie zmian oprogramowania.
Budowanie oprogramowania
iteracyjnie
• 1. Istotne nieporozumienia ujawniają się we
wczesnych stadiach cyklu projektowego, gdy
jeszcze można coś z nimi zrobić.
• 2. To podejście usprawnia i ułatwia taką
współpracę z użytkownikami, która umożliwi
opracowanie rzeczywistych wymagań dla
systemu.
Budowanie oprogramowania
iteracyjnie
• 3. Zespół projektowy jest zmuszony do
koncentrowania się na sprawach, które są
najważniejsze dla powodzenia projektu i jest
osłaniany przed tym, co odwraca uwagę od
rzeczywistych zagrożeń.
• 4. Ciagłe iteracyjne testowanie umożliwia
obiektywną ocenę stanu projektu
Budowanie oprogramowania
iteracyjnie
• 5. Wcześnie wykrywa się niezgodności
wymagań , projektu i implementacji.
• 6. Obciążenia zespołu, zwłaszcza jego części
zaangażowanej w testowanie, rozkładają się
bardziej równomiernie na cały cykl projektowy
Budowanie oprogramowania
iteracyjnie
• 7. Zespół może korzystać z gromadzonego
doświadczenia i dzięki temu stale doskonalić
swe działanie.
• 8. Osoby decydujące o projekcie mogą
uzyskiwać konkretne materiały o jego stanie w
ciągu całego cyklu projektowego.