plik


In|ynieria oprogramowania Przegld modeli cyklu |ycia oprogramowania RafaB Kasprzyk worzenie oprogramowania nie jest spraw Okre[l wymagania Zbuduj Przetestuj prost i nikogo, kto braB udziaB w du|ym pro- na system system system Tjekcie, nie trzeba o tym przekonywa. Czasy, kiedy jedna osoba zajmowaBa si zbieraniem wyma- NIE Przetestuj gaD, analiz, projektowaniem, programowaniem, te- system stowaniem i wdra|aniem produktu informatycznego TAK dawno ju| si skoDczyBy.  Programowanie odkryw- Przetestuj cze nie jest obecnie dobrym sposobem budowy ja- system kichkolwiek systemw informatycznych. Tworzone dzi[ systemy s po prostu zbyt skomplikowane, aby Rysunek 1. Programowanie odkrywcze przez caBy cykl |ycia tych systemw mogBa nad nimi panowa jedna osoba. Popularne modele cyklu |ycia Trudno[ci w budowaniu du|ych systemw wymu- systemu informatycznego siBy, ju| wiele lat temu, konieczno[ usystematyzo- Najcz[ciej wymienianym procesem wytwarzania wania procesu wytwarzania systemw informatycz- oprogramowania jest model kaskadowy (zwany rw- nych. Stworzono wic modele porzdkujce podej- nie| modelem wodospadu, ang. waterfall) i model ite- mowane dziaBania i stany w jakich znajduje si pro- racyjny. Terminy te czsto s nie do koDca poprawnie dukt informatyczny. Obecnie zbir modeli cykli |y- rozumiane. Bardzo czsto mo|na si spotka z prze- cia oprogramowania jest niezwykle bogaty. Oczywi- konaniem, |e proces kaskadowy jest procesem prze- [cie wystarczy pozna tylko kilka kluczowych mode- starzaBym, a jedynie sBusznym podej[ciem jest proces li, pozostaBe s najcz[ciej hybrydami tych podsta- iteracyjny. Osobi[cie ostro|nie podchodz do takiej wowych. oceny tych dwch najpopularniejszych modeli wytwa- rzania oprogramowania. Uwa|am, |e wybr procesu Pojcie modelu cyklu |ycia w znacznym stopniu zale|y od charakteru projektu, a systemu informatycznego tym samym nie ma jednego sBusznego modelu cyklu Czym wBa[ciwie jest model cyklu |ycia systemu in- |ycia oprogramowania. Co wicej, najcz[ciej okazuje formatycznego (oprogramowania)? To szereg wza- si, |e w praktyce najlepiej radz sobie modele, ktre jemnie zale|nych od siebie etapw, w ktrych podej- s modyfikacjami lub hybrydami procesw podstawo- mowane s dziaBania, poczwszy od ujawnienia po- wych. Przyczyna ich powstania zwizana jest bdz to trzeby budowy systemu informatycznego, prezenta- z wadami bdz trudno[ciami w adaptacji do rzeczywi- cji jego idei, konstrukcj, u|ytkowanie, przystosowa- stych warunkw wytwarzania systemw informatycz- ne do ewentualnych zmian funkcjonowania (wyni- nych modelu kaskadowego. Zauwa|my, |e sam pro- kajcych najcz[ciej ze wzgldu na zmieniajce si ces iteracyjny stanowi swego rodzaju modyfikacj warunki otoczenia), a koDczc na wycofaniu z eks- procesu kaskadowego. Inne znane i popularne mode- ploatacji. Bdziemy zajmowa si tylko t cz[ci cy- le cyklu |ycia oprogramowania to model spiralny, mo- klu |ycia oprogramowania, ktra zwizana jest z pro- del V, prototypowanie, i wiele innych. cesem wytwrczym i w zwizku z tym nazywana jest cyklem wytwarzania oprogramowania. Model kaskadowy Ka|dy model cyklu |ycia oprogramowania ma na Najstarszym i prawdopodobnie najlepiej znanym cy- celu przedstawienie procesu wytwarzania oprogra- klem |ycia oprogramowania jest model wodospadu. mowania, ktry prowadzi do stworzenia dziaBajcego Najpowszechniej spotykanym argumentem zach- systemu speBniajcego oczekiwania klienta. cajcym do u|ycia tego modelu jest fakt, i| jest on dla czBowieka najbardziej naturalnym sposobem roz- wizywania wszelkich problemw. W modelu kaska- Autor jest absolwentem Wydziale Cybernetyki Wojsko- dowym, aby zbudowa system informatyczny nale- wej Akademii Technicznej, gdzie od roku zajmuje sta- |y przej[ przez kolejne etapy, ktrych realizacja ma nowisko asystenta w Instytucie Systemw Informatycz- zapewni zakoDczenie projektu. Etapy na jakie dzie- nych. Pracuje w firmie ISOLUTION bdc odpowiedzial- lony jest proces wytwarzania to: zbieranie wymagaD, nym za przygotowywanie, prowadzenie i audyt szkoleD obejmujcych analiz i projektowanie systemw infor- analiza, projektowanie, implementacja, testowanie i matycznych z u|yciem notacji UML. wdro|enie systemu. Kontakt z autorem: rafal.kasprzyk@wat.edu.pl W modelu wodospadu wyj[cie z jednego etapu jest rwnocze[nie wej[ciem w kolejny, bez mo|liwo- 52 www.sdjournal.org Software Developer s Journal 10/2006 Przegld modeli cyklu |ycia oprogramowania l Weryfikacja zgodno[ci produktu z wymaganiami i jego Zbieranie wymagaD u|yteczno[ci nastpuje dopiero w koDcowych krokach. l Prba dopasowania produktu do zmieniajcych si wyma- Analiza gaD, powoduje znaczcy wzrostu kosztw budowy systemu. l Kolejno[ci wykonywania prac musz by [ci[le przestrze- Projektowanie gane, co niekoniecznie trzeba uwa|a za wad. Warto jed- Implementacja nak zauwa|y, |e wikszo[ osb preferuje znacznie mniej rygorystyczne procesy wytwarzania oprogramowania. Testowanie l Wysoki koszt bBdw popeBnionych we wstpnych eta- pach jest bardzo charakterystyczn wBa[ciwo[ci modelu Wdro|enie kaskadowego. Przecie| bBdy popeBnione na etapie zbie- rania lub analizy wymagaD mog by wykryte dopiero na etapie testw akceptacyjnych, bdz eksploatacji, a ich Rysunek 2. Model kaskadowy koszt o kilka rzdw wielko[ci przewy|sza koszt bBdw [ci powrotu. Zostaje zatem utworzona sztywno narzucona ko- popeBnionych podczas implementacji. lejno[ poszczeglnych etapw. Analityk po stworzeniu mo- l Czstym argumentem podnoszonym przeciwko modelowi li- delu dziedziny problemu przekazuje wyniki swojej pracy pro- niowemu jest zmarginalizowanie roli klienta w procesie wy- jektantowi. Projektant, po stworzeniu projektu oprogramowa- twarzania oprogramowania. DBuga przerwa w kontaktach z nia, w oparciu o wyniki etapu analizy, przekazuje go w rce klientem, z ktrym [ci[le wspBpracuje si podczas okre[la- programisty, ktrego zadaniem jest jego implementacja. Na- nia wymagaD, pociga za sob ryzyko zmniejszenia zain- stpnie w celu zapewnienia wysokiej jako[ci produktu, kod teresowania klienta produktem, podczas gdy nie bierze on jest testowany, a dopiero na samym koDcu jest przekazywa- udziaBu w procesie wytwrczym. Klient  przypomina sobie o ny klientowi. systemie, ktry w koDcu byB przez niego zamawiany, na eta- W procesie kaskadowym bardzo istotna jest forma przeka- pie wdra|ania, kiedy to jego wizja na temat funkcjonalno[ci, zywania wynikw z jednego etapu do drugiego. Niekiedy po- jak system powinien zapewnia, mo|e ulec istotnej zmianie. jawiaj si powroty, ale mo|liwo[ wystpienia takiej sytuacji powinna by minimalizowana. Oczywistym jest przecie|, |e Warto nadmieni, |e model kaskadowy mimo swych licznych na przykBad podczas implementacji mo|e wystpi jaki[ pro- wad, w nieco zmodyfikowanej postaci, staB si standardem, blem, ktry zmusi zespB do powrotu do projektu lub co gor- zalecanym przez Departament Obrony Narodowej Stanw sza powtrnej analizy. Weryfikacja wynikw poszczeglnych Zjednoczonych (DOD STD 2167), stosowanym przy wytwa- etapw jest wic nieunikniona. rzaniu systemw informatycznych dla wojska. Standard ten Podstawowe cechy modelu kaskadowego niestety poka- jest [cisB realizacj modelu kaskadowego  kierowan doku- zuj jednocze[nie jego wady: mentami . Na czym owa modyfikacja polega? Po prostu, ka|- dy etap koDczy si opracowaniem szeregu dokumentw, ktre l Uzyskanie produktu speBniajcego oczekiwania klienta z zaBo|enia s wystarczajc podstaw do realizacji kolejnych niezwykle silnie zale|y od stabilno[ci wymagaD, ktra jest etapw. Dopiero akceptacja przez klienta dokumentacji zreali- przecie| trudna do uzyskania. zowanego etapu pozwala na rozpoczcie kolejnego. Zgrubna analiza wymagaD Zgrubna analiza wymagaD Proces Wybr podzbioru iteracyjny wymagaD do realizacji SzczeBowa analiza projekt, implementacja i testowanie Nowa wersja systemu Rysunek 3. Model iteracyjny Software Developer s Journal 10/2006 www.sdjournal.org 53 In|ynieria oprogramowania Testy Wymagania akceptacyjne Model Testy logiczny walidacyjne Projekt Testy logiczny integracyjne Projekt Testy fizyczny moduBw Implementacja Wdro|enie Rysunek 4. Model V Model iteracyjny go rodzaju rozpoznania wymagaD, w celu uzyskania oglnego W modelu iteracyjnym wymagania s porzdkowane i dzie- obrazu i zakresu projektu. Celem, jaki przy[wieca tym dziaBa- lone na mniejsze podzbiory. Ka|dy taki podzbir wymaganej niom, jest podziaB wymagaD na wBa[ciwe iteracje. Takie wstp- funkcjonalno[ci wymaga przej[cia przez etapy, o ktrych by- ne dziaBania polegaj najcz[ciej na stworzeniu oglnej archi- Ba mowa w modelu kaskadowym. Po zakoDczeniu ka|dej ite- tektury systemu, a niekiedy nawet jego prototypu. racji wybierany jest kolejny podzbir wymagaD do realizacji i Ciekaw i moim zdaniem niezwykle po|dan odmia- ponownie przechodzimy przez wszystkie etapy wytwarzania n procesu iteracyjnego jest mo|liwo[ przekazania sys- oprogramowania. temu do wdro|enia, gdy tylko jaki[ rozsdny podzbir wy- Zauwa|my, |e takie podej[cie pozwala na szybk imple- magaD zostanie zaimplementowany i przetestowany. Jest to mentacj przynajmniej cz[ci wymaganej funkcjonalno[ci (tej korzystne, co najmniej z dwch powodw: wcze[niej mo|- o najwy|szym priorytecie, lub te| stanowicej najwy|sze ry- na uzyska pewne korzy[ci (nie ma co ukrywa, |e chodzi zyko niepowodzenia realizacji). Model iteracyjny pozwala wic tu o korzy[ci finansowe) z wdro|enia systemu, ale rwnie|, na bardzo szybk weryfikacj realizowalno[ci wytwarzanego co w dBu|szej perspektywie jest wa|niejsze, mo|na uzyska systemu i informacj zwrotn od klienta, czy to, czego potrze- w peBni obiektywne opinie na temat jego dziaBania w rzeczy- buje, jest tym, co otrzyma jako produkt procesu wytwrczego. wistych warunkach. W takich sytuacjach system mo|na wy- Praktyka stosowania procesu iteracyjnego zaleca przed puszcza w kolejnych wydaniach, z ktrych ka|de podzielo- rozpoczciem rzeczywistych iteracji przeprowadzenie swe- ne jest na pewn liczb iteracji. Planowanie Identyfikacja kolejnej iteracji i analiza ryzyka Weryfikacja planu projektu oraz Analiza ryzyka w oparciu planowanie kolejnej iteracji o wymagania wstpne na podstawie ocen u|ytkownika Analiza ryzyka na podstawie Wymagania wstpne, ocen u|ytkownika plan projektu i pierwszej iteracjia Walidacja i ocena wydania Kolejne wydania produktu Ocena Kontrukcja przez klienta Rysunek 5. Model spiralny 54 www.sdjournal.org Software Developer s Journal 10/2006 Przegld modeli cyklu |ycia oprogramowania Bardzo czsto mo|na spotka si z pojciem procesu przy- jest wstanie oceni pod wzgldem zgodno[ci z wymaganiami rostowego, ewolucyjnego lub spiralnego, ktre w praktyce s tym (a czsto niestety maBo precyzyjnymi wyobra|eniami). samym, co proces iteracyjny. Oczywi[cie na gruncie teoretycz- nym rozwa|a si r|nice pomidzy tymi procesami, ale nie s Model V one wyrazne. W dalszej cz[ci artykuBu przedstawiony jednak Rozwiniciem modelu wodospadu jest model V, charakteryzu- zostanie model spiralny, ze wzgldu na czste odwoBania si do jcy si rozbudowan faz testw. Model V jest jednym z naj- niego w literaturze dotyczcej omawianego tematu. popularniejszych podej[ do procesu testowania. Testy maj na celu weryfikacj i walidacj poprawno[ci wykonania ka|- Model kaskadowy dego etapu stanowicego cykl |ycia oprogramowania. Dzi- i model iteracyjny  mo|liwe scalenie ki rozbudowaniu sekwencji etapw wytwrczych o testowanie Przedstawiony opis modelu kaskadowego i iteracyjnego zo- otrzymujemy produkt o najwy|szej jako[ci, speBniajcy wyma- staB znaczco uproszczony, aby czytelnik uchwyciB podsta- gania klienta. wow r|nic pomidzy tymi procesami. Praktyka pokazuje, Model V podobnie jak klasyczny model kaskadowy stwa- |e oba procesy mog podlega bardzo wielu zaburzeniom, co rza bardzo du|e niebezpieczeDstwo. Oczywistym jest prze- nie oznacza oczywi[cie, |e wwczas system jest realizowany cie|, |e im pzniej zostanie wykryty bBd lub niezgodno[ z niemetodycznie. wymaganiami, tym kosztowniejsza bdzie naprawa. Dziki te- Czsto proponowanym rodzajem procesu jest tzw. etapo- mu, |e ka|dy z etapw wytwrczych koDczy si r|nego ro- wy cykl tworzenia oprogramowania, ktre stanowi scalenie dzaju przegldami i inspekcjami prawdopodobieDstwo poja- modelu kaskadowego i modelu iteracyjnego. Proponuje si w wienia si bBdu lub niezgodno[ci z wymaganiami przy wdro- nim dokona wedBug modelu kaskadowego zbierania wyma- |eniu i eksploatacji jest du|o mniejsze ni| w modelu klasycz- gaD, analizy i projektowania, a implementacj i testowanie po- nym. Powoduje to znaczce obni|enie kosztw pielgnacji dzieli nastpnie na iteracje. Wdro|enia mo|na natomiast do- systemu. Dodatkowo wynikiem ka|dego etapu wytwrcze- kona po zaimplementowaniu i przetestowaniu caBo[ci wy- go s plany testw, ktre po zakoDczeniu zstpujcego cyklu magaD ponownie wedBug modelu kaskadowego lub te| mo- produkcyjnego (lewe rami litery V) realizowane s wstpuj- |e to polega na instalacji kolejnych wydaD systemu, co zale- co (prawe rami litery V). |y oczywi[cie od charakteru projektu i uzgodnieD z klientem. Oczywistym jest, co ju| zostaBo wspomniane, |e to drugie po- Model spiralny dej[cie wydaje si by z r|nych przyczyn korzystniejsze za- Model spiralny jest w pewnym sensie prb formalizacji po- rwno dla twrcw, jak i odbiorcw systemu. dej[cia iteracyjnego do wytwarzania oprogramowania. GBw- Mo|na [miaBo postawi tez, |e jednym z gBwnych po- n cech tego modelu jest analiza ryzyka wystpujca w ka|- wodw modyfikacji modelu kaskadowego elementami cha- dej iteracji. CigBe monitorowanie i pomiar zmian, ktre pod- rakterystycznymi dla procesu iteracyjnego s wzgldy finan- dawane s krytycznemu spojrzeniu u|ytkownika, umo|liwiaj sowe, a nie jak by si mogBo wydawa oczywiste zalety itera- dokonanie analizy ryzyka. Pierwsz czynno[ci, ktra nie jest cyjnego podej[cia do wytwarzania oprogramowania. Zauwa|- przedstawiona na rysunku obrazujcym model spiralny, jest my, |e wykonawca |da pienidzy za ka|dy wykonany etap. analiza wymagaD wstpnych. Je|eli wymagania wydaj si Z kolei klient, pBacc za wykonany etap, |da wynikw, ktre by realizowalne w zaBo|onym czasie, bud|ecie i przy dostp- R E K L A M A In|ynieria oprogramowania l ocena przez klienta  walidacja wydania i jego ocena z mo|liwo[ci modyfikacji wymagaD na system (mo|liwo[ wystpienia modyfikacji wymagaD powinna by minimali- zowana). GBwne zalety modelu spiralnego to prba minimalizacji ry- zyka niepowodzenia przedsiwzicia oraz cigBa weryfikacja produktu przez u|ytkownika, co ma na celu wytworzenie pro- duktu w peBni satysfakcjonujcego klienta. Prototypowanie Model prototypowania jest kolejn prb radzenia sobie z pro- blemem identyfikacji i braku stabilno[ci wymagaD. Prototy- powanie polega na budowaniu kolejnych  przybli|eD syste- mu do momentu a| prototyp stanie si dobrym odzwiercie- dleniem wymagaD. Oceny prototypw i kolejne wersje owych prototypw, w sposb bardzo naturalny prowadz do identy- fikacji wymagaD. Zauwa|my, |e prototypowanie w tym przy- padku pokrywa etap analizy wymagaD i std czsto przedsta- wiany model okre[la si jako  prototypowanie wymagaD . Ce- ch charakterystyczn  prototypowania wymagaD jest budo- wa  szybkiego projektu bez dbaBo[ci o jego jako[ i dostoso- wanie do [rodowiska docelowego. Oczywi[cie mo|liwe jest szersze spojrzenie na prototypowanie tak, aby obejmowaBo ono rwnie| etap projektowania w celu weryfikacji efektywno- [ci przyjtych rozwizaD. Ten rodzaj prototypowania okre[la- ny jest mianem  prototypowania wytwrczego . Gdy mamy ju| pewno[, |e wszystkie wymagania zosta- By zidentyfikowane, wwczas mo|na przystpi do konstruk- cji wBa[ciwego produktu zgodnie z modelem klasycznym wy- twarzania oprogramowania, rozpoczynajc od etapu projekto- wania. Tego typu podej[cie mo|e niekiedy spotka si z nie- zrozumieniem ze strony klienta, bdz te| pojawi si na wy|- szych szczeblach zarzdzania firm wykonawcy. Czsto po- jawiaj si pytania typu: Dlaczego trzeba zaczyna wszystko od nowa  je[li ju| prawie wszystko zrobiono ? Kolejn wad Rysunek 6. Model prototypowania prototypowania jest mo|liwo[  przyzwyczajenia si klienta do funkcjonalno[ci oferowanej przez prototyp, a ktra nie wy- nych zasobach (tzw. zasad trjkta) mo|na przej[ do plano- nika z przyjtych wymagaD. Rwnie| projektant mo|e  przy- wania projektu i pierwszej iteracji. zwyczai si do rozwizaD zastosowanych w prototypie. Re- WBa[ciwie kolejne iteracje maj posta  maBych wodo- asumujc, model prototypowy musi by dobrze rozumiany spadw. Po ka|dej takiej peBnej iteracji dokonuje si przegl- przez obie strony tj. zarwno twrc systemu informatyczne- du systemu. Je|eli dane przedsiwzicie wymaga dalszych go, jak i klienta. prac wwczas nale|y zaplanowa kolejn iteracj, a nastp- nie przeprowadzi analiz ryzyka realizacji kolejnego wyda- Planowanie predykcyjne i adaptacyjne nia. Model spiralny stanowi wic  obudowan wersj modelu Wybr procesu wytwarzania oprogramowania bardzo silnie wodospadu opart o bie|c analiz ryzyka. zale|e bdzie od stabilno[ci wymagaD. Rwnie| sposb pla- Model spiralny mo|na postrzega jako cyklicznie powta- nowania jest uzale|niony od stabilno[ci wymagaD. Przy zaBo- rzane cztery czynno[ci: |eniu, |e wymagania, ktre zostaBy zebrane nie bd ju| si zmieniaBy, jak rwnie| klient nie bdzie dodawaB nowych, za- l planowanie  na podstawie wymagaD i celw wyznaczo- nych przez klienta, dokonuje si okre[lenia alternatyw i Literatura ograniczeD oraz planowania iteracji przy ka|dorazowym rozpoczciu kolejnego cyklu spirali. l [1] Marin Fowler UML Distilled: A Brief Guide To The Standard l analiza ryzyka  sprowadza si do oceny rozwizaD alter- Object Modeling Language, Pearson Education, Inc., 2004; natywnych oraz prby identyfikacji i analizy ryzyka zwi- l [2] StanisBaw Szejko Metody wytwarzania oprogramowania, zanego z ka|d z mo|liwych alternatyw konstrukcji nowe- MIKOM, Warszawa 2002; go wydania. l [3] Graham I. In|ynieria oprogramowania  metody obiektowe l konstrukcja  ma posta  maBego wodospadu, a jej celem w teorii i praktyce, WNT, Warszawa 2004. jest wytworzenie kolejnego wydania systemu. 56 www.sdjournal.org Software Developer s Journal 10/2006 Przegld modeli cyklu |ycia oprogramowania leca si planowanie predykcyjne. Planowanie predykcyjne jest nej wspBpracy zespoBu projektowego z klientem, a zbir bardzo czsto narzucone w projektach rzdowych i dla woj- wymagaD mo|e by do[ elastycznie modyfikowany, roz- ska. Trudno wyobrazi sobie tutaj inny sposb planowania, szerzany, a niekiedy zaw|any, oczywi[cie wszystko za po- poniewa| mamy najcz[ciej sztywn dat zakoDczenia i kwo- rozumieniem obu stron. W tego typu projektach zastosowa- t bud|etu. Ustalenia pomidzy twrc systemu i zamawiaj- nie modelu kaskadowego z gry skazane jest na niepowo- cym musz jednoznacznie precyzowa, co wBa[ciwie jest do dzenie. Plan adaptacyjny mo|liwy jest do zastosowania je- zrobienia, ile produkt finalny bdzie kosztowaB i kiedy zosta- dynie w przypadku zastosowania procesu iteracyjnego i je- nie ukoDczony. To dlatego w tego typu projektach mo|liwe jest go licznych modyfikacji, z ktrych niektre przedstawione wykorzystania procesu kaskadowego. Dla administracji nic zostaBy w artykule. przecie| nie jest bardziej kBopotliwe ni| brak jasnej wizji kosz- tu wytworzenia jakiego[ produktu i czasu jego realizacji. Podsumowanie Powstaje jednak pytanie, czy projekty informatyczne mo- Badania prowadzone w Stanach Zjednoczonych wykazaBy, |e g by w ogle przewidywalne. Bez wtpienia w wikszo[ci ponad 2/3 wszystkich projektw informatycznych koDcz si projektw mo|na si spotka z  chaosem wymagaD . Chaos niepowodzeniem. Niepowodzenie byBo najcz[ciej rezultatem polega na wprowadzaniu zmian do wymagaD w pzniejszych braku [rodkw finansowych na kontynuowanie projektu (nie- etapach cyklu |ycia oprogramowania. Zmiany takie prak- doszacowanie kosztw), stworzenie produktu, ktry nie speB- tycznie zawsze powoduj konieczno[ przebudowy pierwot- nia wymagaD klienta lub zakoDczenie procesu wytwarzania z nie stworzonego planu projektu. Oczywi[cie mo|na prbo- bli|ej nieokre[lonych wzgldw (czsto politycznych). wa walczy z tak sytuacj. Powszechnie stosowanym spo- Powodw pora|ki mo|e by wiele, ale najcz[ciej wskazy- sobem radzenia sobie ze zmianami  |yczeD klienta jest za- wanymi byBy: mro|enie na pewnym etapie zbioru wymagaD. Powstaje jed- l nak pewien problem. Zamro|enie wymagaD powoduje ryzyko brak wikszego zaanga|owania ze strony klienta; stworzenia produktu, ktry wBa[ciwie nie jest potrzebny klien- l zbyt oglnie sformuBowane wymagania lub ich modyfika- towi ju| w chwili wdra|ania. cja; Mo|na jednak inaczej prbowa podej[ do proble- l brak  wBa[ciciela projektu; l mu zmieniajcych si wymagaD. ZakBadamy mianowicie, brak planu dziaBania. |e  chaos wymagaD jest zjawiskiem nieuniknionym, a peB- na przewidywalno[ to iluzja. Doskonale sprawdza si ww- Wydaje si wic, |e rozwa|ania na temat procesu wytwarza- czas planowanie adaptacyjne, ktre traktuje zmiany jako nia oprogramowania s potrzebne, poniewa| twrcom syste- co[ zupeBnie naturalnego. Zmiany musz by oczywi[cie mw informatycznych zale|y na tym, aby sukces jednego pro- kontrolowane. Ciekaw rzecz jest fakt, |e w przypadku jektu przekBadaB si na nastpny, aby byB powtarzalny. Takie planowania adaptacyjnego ci|ko powiedzie, |e system ja- podej[cie daje mo|liwo[ doskonalenia procesu wytwarza- ko caBo[ rozwija si zgodnie z planem, a to dlatego, |e taki nia oprogramowania poprzez dokonywanie pomiarw i osza- plan ulega cigBej modyfikacji. Oznacza to tyle, |e plan sBu- cowaD, a to z kolei wpBywa na polepszenie jako[ci produktu i |y raczej do mo|liwo[ci oszacowania konsekwencji wpro- zadowolenie klienta. wadzenia zmian ni| do przewidywania, kiedy system zosta- Nie wolno zapomina, |e proces wytwarzania oprogramo- nia oddany w rce klienta. W przypadku planowania adapta- wania powinien by wspomagany przez narzdzia CASE, kt- cyjnego mo|na oczywi[cie na staBe okre[li bud|et przewi- re oczywi[cie wymagaj odpowiedniej konfiguracji na potrze- dziany na projekt i czas jego zakoDczenia, jednak nie mo|- by danego projektu. Umiejtno[ wykorzystania tego typu na- na przewidzie zakresu wymagaD, ktre zostan zrealizo- rzdzi jest praktycznie warunkiem koniecznym powodzenia wane. Planowanie adaptacyjne wymaga [cisBej permanent- ka|dego wikszego przedsiwzicia informatycznego. n R E K L A M A

Wyszukiwarka

Podobne podstrony:
2006 10 Łączenie kodu C z zarządzanym kodem NET [Inzynieria Oprogramowania]
2006 09?ta Protection API i NET Framework 2 0 [Inzynieria Oprogramowania]
2006 10 Idle Cycles Building Distributed Applications with Boinc
OCENA CYKLU ŻYCIA
Adamczewski Zintegrowane systemy informatyczne w praktyce  Realizacja ZSI na tle cyklu życia syst
us iraq int sum 2006 10 25
Gemmologia 2006 10 Il Taglio Delle Gemme
2006 10 Tv in Linux Building a Home Media Center with Mythtv
2006 10 Skrypty powłoki w systemie Linux [Poczatkujacy]

więcej podobnych podstron