Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Analiza i Projektowanie Systemów Informatycznych, Wykład 1b, Slajd 1 Projektowanie systemów informacyjnych Ewa Stemposz, Kazimierz Subieta Instytut Podstaw.

Podobne prezentacje


Prezentacja na temat: "Analiza i Projektowanie Systemów Informatycznych, Wykład 1b, Slajd 1 Projektowanie systemów informacyjnych Ewa Stemposz, Kazimierz Subieta Instytut Podstaw."— Zapis prezentacji:

1 Analiza i Projektowanie Systemów Informatycznych, Wykład 1b, Slajd 1 Projektowanie systemów informacyjnych Ewa Stemposz, Kazimierz Subieta Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa Wykład 1 Model przypadków użycia, cd.

2 Analiza i Projektowanie Systemów Informatycznych, Wykład 1b, Slajd 2 Zagadnienia Rational Unified Process Model kaskadowy Dlaczego nie model kaskadowy ? Recepta: rozwój iteracyjny Aktywności a fazy i iteracje Korzyści z podejścia iteracyjnego Podsumowanie Planownie z uwzględnianiem iteracji

3 Analiza i Projektowanie Systemów Informatycznych, Wykład 1b, Slajd 3 Rational Unified Process (RUP) Rational Unified Process produkt firmy Rational Software, poprzez promowanie zdyscyplinowanego podejścia do rozwoju oprogramowania, ułatwia produkcję oprogramowania wysokiej jakości, w przewidywalnym dla klienta czasie i budżecie. RUP oparty został o zbiór sześciu najlepszych praktyk: iteracyjny rozwój, zarządzanie wymaganiami, architektura oparta o komponenty, modelowanie wizualne, systematyczna weryfikacja jakości i zarządzanie zmianami. RUP był wykorzystywany w małych i dużych projektach (dla różnych zastosowań) przez więcej niż 1000 organizacji dane z końca 1999 roku: Telekomunikacja: Ericsson, Alcatel, MCI Transport, lotnictwo, obrona: Lockheed-Martin, British Aerospace Produkcja: Xerox, Volvo, Intel Finanse: Visa, Merrill Lynch, Schwab Inne: Ernst & Young, Oracle, Deloitte & Touche.

4 Analiza i Projektowanie Systemów Informatycznych, Wykład 1b, Slajd 4 Model kaskadowy Analiza wymagań Projektowanie Implementacja (kodowanie, testowanie) Integracja (weryfikacja) Specyfikacja wymagań Specyfikacja projektu implementacji Kod Wypuszczenie produktu Wymagania użytkownika W ten sposób, w 5 podstawowych krokach, rozwiązuje się większość problemów inżynierskich, np. buduje wieżowce i mosty. Jeszcze w latach 80-tych model kaskadowy był uważany za jedyne rozsądne podejście do budowy oprogramowania Model kaskadowy Inne nazwy: model wodospadowy, model sekwencyjny

5 Analiza i Projektowanie Systemów Informatycznych, Wykład 1b, Slajd 5 Dlaczego nie model kaskadowy ? (1) 1.Błędne założenia: (a) wymagania mogą być zamrożone po przeprowadzeniu analizy, (b) projekt implementacji będzie od razu dobry. 2.Błędna ocena kontekstu rozwoju oprogramowania. 3.Błędna ocena czynnika ludzkiego. 4.Błędna ocena możliwości wykorzystania podejścia sekwencyjnego. 5.Niedojrzałość inżynierii oprogramowania – zaledwie kilkadziesiąt lat doświadczenia, w przeciwieństwie do tysięcy lat prób i błędów w innych dziedzinach, np. w budowie budynków czy mostów. Dlaczego nie model kaskadowy? Ad. 1. Błędne założenie (a): wymagania mogą być zamrożone. W modelu kaskadowym przyjmuje się założenie, że wymagania na system zostaną poprawnie zdefiniowane po przeprowadzeniu fazy analizy, co w praktyce prawie zawsze okazuje się niemożliwe do osiągnięcia. W większości przypadków, wymagania zmieniają się cały czas w trakcie rozwoju oprogramowania i fakt ten należy przyjąć do wiadomości !!!

6 Analiza i Projektowanie Systemów Informatycznych, Wykład 1b, Slajd 6 Dlaczego nie model kaskadowy ? (2) Zmiany w środowisku pracy użytkownika: Zmiany wprowadzane w środowisku pracy użytkownika są tym bardziej prawdopodobne, im dłużej trwa projekt, np. nie tygodnie (czy miesiące) a lata. Wzrost świadomości użytkownika odnośnie rozwiązywanego problemu, czego efektem może być i z reguły jest zmiana specyfikacji wymagań. Użytkownik wie dokładnie czego chce nie na dwa lata przed datą, kiedy oprogramowanie ma być gotowe, ale kilka tygodni po tej dacie (po oddaniu systemu), gdy oprogramowanie przejdzie już fazę rozpoznawania – efekt IKIWISI (Ill Know It When I See It). Co może powodować zmiany wymagań? Ponadto, poważną przeszkodą na drodze do zamrażania wymagań jest niemożność zdefiniowania wymagań z dostateczną precyzją, na wystarczającym poziomie szczegółowości. Formalne specyfikacje wymagań nie sprawdziły się nigdzie, poza małymi, specjalizowanymi zastosowaniami. Są trudne do wykorzystania i nieprzyjazne dla użytkownika.

7 Analiza i Projektowanie Systemów Informatycznych, Wykład 1b, Slajd 7 Dlaczego nie model kaskadowy ? (3) Ad. 1. Błędne założenie (b): Projekt implementacji – zbudowany w drugim kroku – będzie dobry (i to najlepiej od razu). Przez dobry projekt implementacji rozumie się taki projekt, który zapewnia realizację nie tylko oczekiwanej funkcjonalności, ale też osiągnięcie własności systemu takich jak np. poprawność, odpowiednia wydajność czy niezawodność, itp. Można wyprodukować tony papierowej dokumentacji, przeprowadzić tysiące przeglądów, a w praktyce i tak nie zabezpiecza to przed uniknięciem błędów w projekcie logicznym. Inżynieria oprogramowania nie osiągnęła jak dotąd poziomu innych dyscyplin inżynieryjnych. Być może nigdy nie osiągnie i być może powinna częścią sztuki, ponieważ wytwarzanie oprogramowania czasami przypomina działalność na pograniczu psychologii, filozofii czy socjologii. Zmiany technologicze: Software czy hardware, z którym rozpoczynano projekt, może już nie być wytwarzany w momencie wypuszczania produktu. Konkurencja na rynku: Tu na niekorzyść projektu działa czas jego realizacji – nawet doskonały produkt nie ma szans na rynku, który poszedł już o krok dalej. Ad. 2. Błędna ocena kontekstu rozwoju oprogramowania

8 Analiza i Projektowanie Systemów Informatycznych, Wykład 1b, Slajd 8 Dlaczego nie model kaskadowy ? (4) Ad. 3. Błędna ocena czynnika ludzkiego Jeśli projekt trwa krótko, ludzie szybko widzą namacalne rezultaty swojej działalności i pozostają przez cały czas skoncentrowani na pracy. Błędy, wykrywane w trakcie pracy, nie wymagają zbyt dalekich powrotów w celu przeprowadzenia korekty. Próba wykorzystania modelu kaskadowego odpowiedniego dla małych projektów (kilka tygodni czy miesięcy), dla projektu trwającego np. kilka lat, naraża ten projekt na subtelne (ale znaczące efekty) związane z ludźmi, uczestnikami projektu: Progres jest widoczny w postaci rosnącego stosu papierów i diagramów – brakuje drobnego zastrzyku adrenaliny, by być odpowiednio zmotywowanym. Błędy są wykrywane poźno – dopiero podczas testowania czy integracji – w efekcie słabego sprzężenia zwrotnego cechującego proces sekwencyjny. Uczestnicy projektu mają mało okazji do ulepszania swojej pracy – ważne dla osób niedoświadczonych lub jeśli praca odbywa się w nowym środowisku narzędziowym.

9 Analiza i Projektowanie Systemów Informatycznych, Wykład 1b, Slajd 9 Dlaczego nie model kaskadowy ? (5) W podejściu sekwencyjnym każdy krok kończy się wyprodukowaniem zbioru artefaktów, które po przeglądzie, akceptacji i zamrożeniu są wykorzystywane jako punkt startowy dla następnej aktywności. W praktyce, w podejściu sekwencyjnym nacisk jest z reguły kładziony na produkcję i zamrażanie dokumentów. Ograniczone powroty w celu drobniejszych korekt są tolerowane, w przeciwieństwie do zmian, które wymagałyby powrotu do początkowych kroków, co mogłoby być przyczyną całkowitego niepowodzenia projektu. Stąd – dla długich projektów opartych o podejście sekwencyjne – często obserwuje się znaczący opór kierownictwa w sytuacji zaistnienia potrzeby zmian (wewnętrzni oponenci są często usuwani ze składu zespołu projektowego), co w efekcie skutkuje pogorszeniem jakości produktu finalnego.

10 Analiza i Projektowanie Systemów Informatycznych, Wykład 1b, Slajd 10 Dlaczego nie model kaskadowy ? (6) Dla projektów małych (czas realizacji: kilka tygodni czy miesięcy), czy też projektów z niewielką liczbą nowości (doświadczeni ludzie, znane narzędzia, znany problem, itp.) model sekwencyjny sprawdza się dobrze. Nie sprawdza się, gdy jest dużo ryzyk, np. dużo niewiadomych czy dużo nowości. W modelu sekwencyjnym jedyne, co można zrobić dla obsługi przyszłych ryzyk, to pozostawienie zapasu czasu na obsługę wszelkich nieprzewidzianych wydarzeń. Ad. 4. Model sekwencyjny jest nieodpowiedni dla dużych, złożonych projektów z dużą liczbą ryzyk? Ad. 5. Inżynieria oprogramownia – dziedzina niedojrzała Brak fundamentalnych praw w rozwoju oprogramowania i tempo w jakim zmienia się rynek czyni produkcję oprogramowania dziedziną o dużym stopniu ryzyka. Dlatego ryzyka muszą być bezwzględnie brane pod uwagę przez organizacje zajmujące się wytwarzaniem oprogramowania.

11 Analiza i Projektowanie Systemów Informatycznych, Wykład 1b, Slajd 11 Recepta: rozwój iteracyjny (1) Podejście oparte o realizację kompletnego zbioru funkcjonalności kontra podejście oparte o realizację stopniową (volume-based versus time-based scheduling) Wszystko czego potrzebujesz, zrobimy w ciągu dziewięciu miesięcy kontra w ciągu dwóch pierwszych miesięcy zrobimy trzy pozycje z twojej listy, w kolejnych trzech miesiącach zrobimy to i tamto, itd.. To pierwsze podejście, typowe dla procesu sekwencyjnego, nie przynosi zbyt wielkich zysków, kiedy brakuje czasu: jak np. decyzja o nie realizowaniu własności X, podjęta w środku implementacji, gdy poświęciliśmy już czas na jej specyfikowanie, projekt implementacji i częściową implementację. Drugi sposób pracy, typowy dla podejścia iteracyjnego, wymusza dzisiejszy rynek: produkt zostaje wypuszczony z pewnym zbiorem własności, a potem tworzona jest następna, ulepszona i/lub rozszerzona wersja.

12 Analiza i Projektowanie Systemów Informatycznych, Wykład 1b, Slajd 12 Recepta: rozwój iteracyjny (2) Jak wykorzystać podejście sekwencyjne w procesie iteracyjnym? Jeśli proces sekwencyjny sprawdza się zarówno dla małych projektów, jak i dla tych z niewielką liczbą ryzyk, dlaczego nie realizować dużych projektów podzieliwszy je na małe, z których każdy będzie przeprowadzany w oparciu o model kaskadowy. Można wybrać podzbiór wymagań, zrobić dla nich projekt logiczny i implementację, poddać weryfikacji, po czym rozpocząć pracę z kolejnym podzbiorem wymagań, i tak dalej aż do osiągnięcia kompletnego, stabilnego produktu finalnego. Jak dokonywać wyboru, co powinno być zrealizowane w kolejnych iteracjach – jaki podzbiór wymagań i jakie ryzyka brać pod uwagę? Jak się ustrzec przed zjawiskiem, by każda kolejna iteracja nie rozpoczynała się ponownie początkiem realizacji projektu?

13 Analiza i Projektowanie Systemów Informatycznych, Wykład 1b, Slajd 13 Recepta: rozwój iteracyjny (3) Aw P Im In Aw - Analiza wymagań, P - Projektowanie, Im- Implementacja, In - Integracja Aw P Im In Aw P Im In Aw P Im In jedna iteracja czas

14 Analiza i Projektowanie Systemów Informatycznych, Wykład 1b, Slajd 14 Korzyści z podejścia iteracyjnego Braki (błędy) o dużej wadze dla produktu finalnego mogą być wykrywane wcześniej, co umożliwia wcześniejszą reakcję. Łatwiej (bo częściej) można uzyskiwać informacje zwrotne od użytkownika, dzięki czemu wzrastają szanse na prawidłową specyfikację wymagań. Niespójności między wymaganiami, projektem implementacji i kodem mogą być wykrywane wcześniej. Zespół projektowy może poświęcić większą uwagę elementom krytycznym w aktualnej fazie projektu. Praca, wykonywana przez różne grupy członków zespołu projektowego może być bardziej równomiernie rozłożona w czasie. Dzięki iteracyjnemu (ciągłemu i systematycznemu) testowaniu łatwiej szacować statusu projektu. Cały czas są dostępne niezbite dowody ułatwiające to zadanie ważne dla wszystkich uczestników projektu. Doświadczenia, nabyte w jednym cyklu, można z powodzeniem wykorzystywać w następnych cyklach, czy w ogóle do ulepszania całości procesu. Korzyści wynikające z wykorzystania podejścia iteracyjnego

15 Analiza i Projektowanie Systemów Informatycznych, Wykład 1b, Slajd 15 Aktywności a fazy i iteracje (1) PoczątkowaOpracowywanie Planowanie Wymagania Architektura Projekt implementacji Implementacja Testowanie, weryfikowanie KonstrukcjaWdrażanie Integracja Iter. wstępna Iter. #1, Iter. #2Iter.#n, Iter. #..., Iter.#mIter. #m+1, Iter.#m+2 Każda iteracja przebiega w oparciu o model kaskadowy; 4 fazy tworzą jeden cykl 10%30%50%10%

16 Analiza i Projektowanie Systemów Informatycznych, Wykład 1b, Slajd 16 Aktywności a fazy i iteracje (2) W każdej z faz położony jest różny nacisk na różne aktywności: Faza początkowa: tu wysiłki koncentrują się na określeniu kontekstu systemu (aktorów), wymagań funkcjonalnych, zakresu odpowiedzialności (głównych wymagań), ograniczeń (wymagań niefunkcjonalnych), kryteriów akceptacji dla produktu finalnego oraz zgrubnego planu projektu. Faza opracowywania: wymaganiom nadal poświęca się wiele uwagi, ale też prowadzone są prace projektowe i implementacyjne (w celu określenia projektu architektury i wytworzenia prototypu, stanowiącego podstawę dla dalszych prac) oraz planuje się mitygację technicznych ryzyk poprzez testowanie różnych technik i narzędzi. Faza konstrukcji: nacisk jest położony na prace projektowe i implementacyjne. W tej fazie prototyp jest rozwijany, aż do uzyskania pierwszego operacyjnego produktu. Faza wdrażania: prace są skoncentrowane na zapewnieniu produktowi odpowiedniej jakości: usuwa się błędy, ulepsza i/lub uzupełnia o brakujące elementy, wypełnia bazę, trenuje użytkowników.

17 Analiza i Projektowanie Systemów Informatycznych, Wykład 1b, Slajd 17 Aktywności a fazy i iteracje (3) Podstawowe zadania: (1) przeprowadzić bardziej dokładną analizę, (2) wypracować fundamenty dla architektury, (3) wyeliminować elementy obarczone największym ryzykiem, (4) uszczegółowić plan projektu (czyli skonstruować szczegółowe plany dla iteracji). Decyzje architektoniczne muszą bazować na zrozumieniu całości systemu: jego funkcjonalności i ograniczeń (zrozumienie z perspektywy na milę szerokiej i na cal głębokiej). Faza opracowywania – najbardziej krytyczna z czterech faz (wysoki koszt, wysokie ryzyko): wymagania, architektura, plany powinny osiągnąć stabilną postać, ryzyka muszą być zmitygowane, tak aby była możliwa realna werfikacja zaplanowanych kosztów i czasu potrzebnego na ukończenie projektu. Bada się różne rozwiązania budując prototyp(y) – w jednej lub kilku iteracjach (zakres, rozmiar, nowości, inne ryzyka). Budowa prototypów ułatwia mitygowanie ryzyk oraz ustanawianie kompromisów między wymaganiami a możliwościami środowiska implementacji. Faza opracowywania

18 Analiza i Projektowanie Systemów Informatycznych, Wykład 1b, Slajd 18 Planowanie z uwzględnieniem iteracji (1) Planowanie projektu z uwzględnieniem iteracji wymaga rozstrzygnięcia kwestii, które nie istniały przy zastosowaniu tradycyjnego podejścia kaskadowego, jak np.: Jak wiele iteracji będzie potrzebne? Jak długo powinna trwać każda z nich? W jaki sposób należy ustalić cele i zawartość każdej iteracji? Jak należy śledzić postęp prac w trakcie realizacji iteracji? Planowanie dużych, złożonych projektów Ambitne próby planowania realizacji całości dużych, złożonych projektów z dokładnością co do minuty, wyróżniania aktywności i przypisywania osób do zadań na kilka miesięcy czy kilka lat do przodu, jak wykazała praktyka są z góry skazane na niepowodzenie. Tworzono diagramy Gantta (czy semantyczne sieci aktywności), które pokrywały całe ściany, a mimo to projekty kończyły się niepowodzeniem. Skuteczna realizacja szczegółowych planów wymaga posiadania zarówno dobrego zrozumienia problemu, jak i stabilnych wymagań, stabilnej architektury oraz ukończony choć jeden podobny projekt, tak by w oparciu o niego można było ustalić szczegółowy WBS.

19 Analiza i Projektowanie Systemów Informatycznych, Wykład 1b, Slajd 19 Planowanie z uwzględnieniem iteracji (2) Innymi słowy, jak można planować zbudowanie przez osobę X w tygodniu n modułu Y skoro w momencie planowania, w żaden sposób nie da się w tym czasie w ogóle wydedukować potrzeby posiadania modułu Y? Planowanie szczegółowe jest możliwe w tych dziedzinach inżynieryjnych, gdzie WBS jest mniej lub bardziej zestandaryzowane i stabilne, gdzie kolejność zadań jest wystarczajaco uporządkowana. Np. budując budynek nie można wznosić jednocześnie piętra pierwszego i czwartego. Po pierwszym musi powstać drugie, potem trzecie, aby można było zająć się czwartym. RUP rekomenduje, by realizacja projektu była opierana na dwóch rodzajach planów, różniących się stopniem szczegółowości: plan faz (zgrubny – nie więcej niż jedna, dwie strony opisu) i seria planów dla iteracji (szczegółowych). Plan faz Tworzony jest jeden plan faz, jeden na potrzeby całego projektu. Plan faz obejmuje z reguły jeden cykl czasami, stosownie do potrzeb, kilka kolejnych cykli. Tworzony jest bardzo wcześnie, w fazie początkowej. W każdej momencie, może być poddawany modyfikacji.

20 Analiza i Projektowanie Systemów Informatycznych, Wykład 1b, Slajd 20 Planowanie z uwzględnieniem iteracji (3) Plan faz zawiera poniższe elementy: Daty głównych kamieni milowych: LCO – określenie celów danego cyklu rozwijania projektu (koniec fazy początkowej; projekt ma dobrze określony zakres odpowiedzialności i zapewnione środki na realizację). LCA – specyfikacja architektury (koniec fazy opracowywania; stabilizacja architektury). IOC – osiągnięta początkowa zdolność operacyjna (koniec fazy konstrukcji; pierwsze beta). Wypuszczenie produktu (koniec fazy wdrażania i koniec danego cyklu). Profile zespołowe --> jakie zasoby ludzkie są wymagane na poszczególnych etapach cyklu. Specyfikację mniej ważnych kamieni milowych --> data zakończenia każdej iteracji wraz ze specyfikacją jej celów (o ile można je zidentyfikować).

21 Analiza i Projektowanie Systemów Informatycznych, Wykład 1b, Slajd 21 Planowanie z uwzględnieniem iteracji (4) Plan iteracji Tworzony jest jeden plan dla każdej iteracji (plan szczegółowy). Projekt z reguły posiada dwa plany iteracji aktywne w danym momencie: Plan dla bieżącej iteracji: jest wykorzystywany do śledzenia postępów prac w trakcie realizacji iteracji. Plan dla następnej iteracji: jest tworzony począwszy od połowy bieżącej iteracji i jest prawie (?) gotowy przy jej końcu. Plan iteracji tworzony jest za pomocą tradycyjnych technik (diagramy Gantta, itp.) i narzędzi do planowania (Microsoft Project, itp.). Cel – definiowanie zadań, przypisanie zadań do osób i zespołów. Plan zawiera ważne daty, takie jak np.: zakończenie budowy czegoś, dostarczenie komponentów z innej organizacji czy terminy głównych przeglądów. RUP – przyjmując za podstawę proces iteracyjny i niekończącą się akomodację zmian celów i taktyki – zakłada tym samym, że nie istnieją racjonalne powody, by marnować czas na przygotowywanie szczegółowych planów dla dłuższych horyzontów czasowych: takie plany są trudne do zarządzania, szybko stają się nieaktualne oraz z reguły są ignorowane przez organizacje wykonawcze).

22 Analiza i Projektowanie Systemów Informatycznych, Wykład 1b, Slajd 22 Planowanie z uwzględnieniem iteracji (5) W fazie początkowej często uważa się, że iteracji nie ma, tzn. nie ma czegoś, co można by nazwać prawdziwą iteracją (mini-projektem): żaden kod nie jest produkowany, wykonywane są przede wszystkim aktywności związane z rozpoznawaniem, planowaniem i marketingiem. Iteracje w fazie początkowej Zbudować prototyp, by przekonać siebie czy sponsora, że proponowane rozwiązanie (lepiej: pomysł na rozwiązanie) jest dobre. Zbudować prototyp, w celu mitygowania ryzyk technicznych (np. eksploracja nowych technologii czy nowych algorytmów) czy udowodnienia, że cele wydajnościowe są osiągalne. Przyspieszyć wdrażanie narzędzi i procesów w organizacji. Czasami jednak iteracja jest potrzebna, po to by:

23 Analiza i Projektowanie Systemów Informatycznych, Wykład 1b, Slajd 23 Planowanie z uwzględnieniem iteracji (6) Iteracje w fazie opracowywania Plany dla iteracji w fazie opracowywania muszą być budowane w oparciu o trzy, najważniejsze w tej fazie elementy: ryzyka, własności krytyczne dla osiągnięcia sukcesu i pokrycie : Plany powinny być budowane tak, by większość ryzyk została zmitygowana lub wysłana na emeryturę właśnie w fazie opracowywania. Ponieważ podstawowym celem fazy opracowywania jest budowa stabilnej architektury, plany muszą być konstruowane tak, by architektura adresowała wszystkie aspekty oprogramowania (pokrycie). Jest to ważne, bo architektura stanowi bazę dla dalszego planowania. Ryzyka są bardzo ważne, ale to nie mitygacja ryzyk jest celem ostatecznym. Ostatecznym celem jest uzyskanie produktu, posiadającego własności uznane za krytyczne dla osiągnięcia sukcesu.

24 Analiza i Projektowanie Systemów Informatycznych, Wykład 1b, Slajd 24 Podsumowanie (1) Podejście iteracyjne ułatwia dokonywanie zmian (związanych z użytkownikiem, rynkiem czy technologiami), mitygację ryzyk, wprowadzanie technologii ponownego użycia, podnoszenie umiejętności członków zespołu, ulepszanie procesu jako takiego – wszystko to w efekcie skutkuje uzyskaniem lepszej jakości produktu finalnego. Proces sekwencyjny jest odpowiedni dla realizacji małych projektów, czy tych z niewielką liczbą ryzyk (mało nowości, znane technologie, znana dziedzina problemowa, doświadczeni ludzie), natomiast niezbyt nadaje się dla projektów dużych, z dużą liczbą ryzyk. Proces iteracyjny jest realizowany w oparciu o sekwencję iteracji. W trakcie każdej iteracji, opartej o model kaskadowy, wykonywane są aktywności związane z wymaganiami, tworzeniem projektu implementacji, implementacją i szacowaniem rezultatów. W celu ułatwienia zarządzania procesem realizacji, iteracje zostały pogrupowane w cztery fazy: początkową, opracowywania, konstrukcji i wdrażania. W każdej z faz położono różny nacisk na różne aktywności.

25 Analiza i Projektowanie Systemów Informatycznych, Wykład 1b, Slajd 25 Podsumowanie (2) planowaniu iteracji, budowie i walidacji stabilnej architektury systemu, definiowaniu przypadków i procedur testowych w modelu testów, tworzeniu dokumentacji użytkownika, rozmieszczaniu aplikacji (ang. deployment). W RUP, przypadki użycia wspomagają członków zespołu przy: RUP jako proces prowadzony w oparciu o przypadki użycia uczynił z przypadków bazę dla całego procesu budowania produktu tworząc w oparciu o nie rodzaj języka stanowiącego podstawę do komunikacji między wszystkimi osobami zaangażowanymi w realizację projektu.


Pobierz ppt "Analiza i Projektowanie Systemów Informatycznych, Wykład 1b, Slajd 1 Projektowanie systemów informacyjnych Ewa Stemposz, Kazimierz Subieta Instytut Podstaw."

Podobne prezentacje


Reklamy Google