plik


ÿþWykBad 2 Metody i procesy rozwoju oprogramowania Metody i postpowanie itm / MVLab (c) 2007-2008 Metodologia planowania dziaBaD Postpowanie metodyczne Postpowanie Koncepcja Zapis / notacja Modele Analiza obiektowa, Unified Modeling postpowania Projektowanie Language (UML) obiektowe itm / MVLab (c) 2007-2008 Modele postpowania itm / MVLab (c) 2007-2008 Cele wykBadu lð zrozumienie jakie aspekty powinien zawiera model postpowania lð umiejtno[ opisu i porównania przedstawionych dalej modeli postpowania lð umiejtno[ wyboru wBa[ciwego modelu dla konkretnego zastosowania itm / MVLab (c) 2007-2008 Motywacja lð PodziaB skomplikowanych projektów na szereg faz o wyraznie okre[lonym zakoDczeniu powoduje wzrost efektywno[ci. Dlatego zostaBy opracowane modele postpowania dla projektów z ró|nych dziedzin, które w odpowiedni sposób koordynuj przebieg tych faz. przykBadowo: przepis kulinarny, plan budowy, rozwój produktu lð Powody stosowania modeli w in|ynierii oprogramowania: lð zBo|ono[ programów (rodzaj zadaD, wielko[) lð du|a skala (ludzie, koszty) lð dBugi czas rozwoju (3,5,10 lat) lð Cele stosowania modeli: lð obni|enie kosztów lð zwikszenie jako[ci lð skrócenie czasu projektowania itm / MVLab (c) 2007-2008 Zawarto[ modeli postpowania lð kolejno[ prac, (stopnie, fazy) lð dziaBania jakie nale|y wykona podczas poszczególnych faz lð okre[lenie produktów skBadowych i dokumentacji lð kryteria zakoDczenia fazy (kiedy cele zostan osignite) lð wymagane kompetencje osób zaanga|owanych lð odpowiedzialno[ i kompetencje lð standardy i wytyczne dot. projektu itm / MVLab (c) 2007-2008 Wybór odpowiedniego modelu V-Model Model sawtooth Prototypowanie Model Model kaskadowy spiralny Model XP Code&fix stopieD innowacyjno[ci itm / MVLab (c) 2007-2008 rozlegBo[ projektu Rozwój modeli postpowania Code and fix Kaskadowy Spiralny XP QC Prototypowanie V-Model 97 PiBozbny itm / MVLab (c) 2007-2008 Code and fix lð typowy model postpowania w przypadku maBych, jednoosobowych projektów lub zadaD treningowych (poziom podstawowy) lð Zalety: lð brak pracy organizacyjnej, lð metoda prób i bBdów Pisanie kodu lð Wady: lð wysokie prawdopodobieDstwo wystpienia bBdów; bBdy ci|kie do wykrycia, lð brak prawidBowej dokumentacji, Testy lð nieprzejrzysty kod, lð ograniczona pielegnowalno[ lð czsto wymagania klienta nie s speBnione Poprawki itm / MVLab (c) 2007-2008 Model wodospadowy lð wszystkie operacje wykonywane s w [ci[le okre[lonym porzdku (sekwencyjnie) i do koDca lð ssiednie fazy s spite ptl sprz|enia zwrotnego lð ka|da faza jest dokumentowana  model zintegrowany dokumentacyjnie lð kierunek przej[cia: top-down Studium wykonalno[ci Analiza Wynik zakoDczenia jednej fazy  wpada do nastpnej Projektowanie Implementacja Testowanie Instalacja itm / MVLab (c) 2007-2008 Utrzymanie Fazy modelu wodospadowego lð Studium wykonalno[ci: oszacowanie kosztów i mo|liwo[ci technicznych (wynik: plan projektu, kalkulacja, specyfikacja wymagaD) lð Analiza: okre[lenie zapotrzebowaD oraz wBa[ciwo[ci systemu (wynik: specyfikacja zobowizaD) lð Projekt: okre[lenie architektury i algorytmów (wynik: dokumentacja projektowa) lð Implementacja: realizacja modelu projektowego (wynik: kod zródBowy, dokumentacja techniczna) lð Testowanie: testy moduBów i systemu oraz testowanie przez u|ytkownika (wynik: protokoBy testów) lð Instalacja: wdro|enie aplikacji u klienta lð Pielgnacja: optymalizacja, dopasowywanie, rozszerzenia itm / MVLab (c) 2007-2008 Zalety i wady modelu wodospadowego lð Zalety: lð strukturalna konstrukcja programów lð tworzenie dokumentacji równolegle z pozostaBymi pracami lð wsparcie na etapie organizacji oraz koDczenia projektu lð Wady: lð konieczno[ zamro|enia specyfikacji lð niebezpieczeDstwo |e dokumentacja stanie si wa|niejsza ni| wBa[ciwy system lð Niewielki udziaB klienta itm / MVLab (c) 2007-2008 V-Modell 97 lð wzorowany na modelu postpowania dla projektów programistycznych armii niemieckiej (Bundeswehry) lð integracja systemów zapewniania jako[ci, zarzdzania projektem i konfiguracj w modelu wodospadowym lð Podstawowymi elementami s czynno[ci i produkty walidacja scenariusze Analiza Odbiór techn. u|ycia przypadki Projekt systemu Test integracji testowe przypadki Projekt obiektów Test moduBów testowe Implementacja Konstrukcja Zapewnienie jako[ci weryfikacja itm / MVLab (c) 2007-2008 Weryfikacja a Walidacja W in|ynierii oprogramowania: lð weryfikacja rozumiana jest jako porównanie gotowego produktu z jego specyfikacj Czy zrobiBem to dobrze? lð walidacja to okre[lenie warto[ci gotowego programu w konkretnym zastosowaniu, dla którego zostaB on zaprojektowany Czy zrobiBem to co potrzeba? itm / MVLab (c) 2007-2008 Weryfikacja a Walidacja Czy ja |em to, W in|ynierii oprogramowania: Halinka, tak zrobiB lð weryfikacja rozumiana jest jako jak oni chcieli? porównanie gotowego produktu z jego weryfikacja specyfikacj wg Kiepskich lð walidacja to okre[lenie warto[ci gotowego programu w konkretnym zastosowaniu, dla którego zostaB on Czy ja |em, Halinka, zrobiB to zaprojektowany o co mie, kurde, chodziBo? itm / MVLab (c) 2007-2008 walidacja wg Kiepskich V-Modell 97: zalety i wady lð Zalety: lð zintegrowana koncepcja budowy systemu, zapewnienia jako[ci oraz zarzdzania projektem i konfiguracj lð ogólny model postpowania z okre[lonymi mo|liwo[ciami dopasowania lð dobrze dostosowany do du|ych projektów lð podstawa do certyfikacji (ISO 9000) lð dobra dokumentacja tworzona podczas caBego procesu lð Wady: lð niebezpieczeDstwo niekontrolowanego rozrostu biurokracji lð konieczne wymaga wsparcie narzdziowego lð czasochBonny itm / MVLab (c) 2007-2008 V-Model XT: podziaB lð Jakie czynno[ci s konieczne do realizacji projektu? lð Jakie produkty musz by osignite w czasie jego realizacji? Idee (wyobra|enia) o Cechy projektu projekcie wybór Czynno[ci Uzasadnienie i produkty projektu Cele: lð uniknicie wykonywania niepotrzebnych czynno[ci lð uniknicie bezsensownych dokumentów lð pewno[ opracowania wszystkich koniecznych dokumentów itm / MVLab (c) 2007-2008 Podej[cie nakierowane na produkt (V-Model XT) Grupa produktów Grupa czynno[ci produkcja odpowiedzialno[ Rola Produkt Czynno[ wspóBpraca Rola opracowanie Temat Podczynno[ Rola itm / MVLab (c) 2007-2008 Prototypowanie lð Problemy typowego modelu etapowego lð wymagania s trudne do peBnego wyspecyfikowania i zauwa|enia na pocztku projektu lð prezentacja wyników pracy po jej zakoDczeniu, brak komunikacji klient - wykonawca lð najlepsze rozwizania znajduje si dziki eksperymentom lð Rozwizanie: Prototypowanie lð Rodzaje prototypów (wg celów) lð demonstracyjny -umo|liwia komunikacj ze zleceniodawc lð w dosBownym rozumieniu -analiza obszarów zastosowaD, prowizorycznie dziaBajcy program lð wzorzec laboratoryjny -rozwizanie problemów konstrukcyjnych, analiza architektury i sposobów wdro|enia lð system pilota|owy - podstawy dla produktu itm / MVLab (c) 2007-2008 Rodzaje prototypów Prototyp pionowy: Realizuje wybrane cz[ci systemu ze wszystkich poziomów; Prototyp funkcjonalny realizujcy wycinek konkretnych mo|liwo[ci. Interfejs u|ytkownika Jdro aplikacji Prototyp poziomy: Patformy Realizuje w peBni Dane (middleware) funkcje jednego z poziomów systemu, Oprogramowanie systemowe np. interfejs u|ytkownika. itm / MVLab (c) 2007-2008 Prototypy - zalety i wady Zalety: lð redukcja ryzyka lð integrowalne w tradycyjnych modelach postpowania lð wzrost bezpieczeDstwa planowania lð lepsza wspóBpraca z u|ytkownikiem docelowym i zamawiajcym Wady: lð wy|sze nakBady lð niebezpieczeDstwo: odrzucenie prototypu z uwagi na ograniczenia czasowe, wi|e si z produktem koDcowym lð prototypy s czsto pojmowane jako usprawiedliwienie dla brakujcej dokumentacji lð ograniczenia prototypów czsto nie s reprezentatywne itm / MVLab (c) 2007-2008 Model sawtooth rozszerzenie V-Modelu o prototypowanie klient Zapotrzebowanie Prototyp 1 Prototyp 2 Testy-klient Analiza Walidacja Koncepcja Testy integralno[ci systemu Koncepcja Testy moduBów obiektu Implementacja projektant itm / MVLab (c) 2007-2008 Model sawtooth zalety i wady Zalety: lð Wysokie zaanga|owanie klienta podczas procesu projektowania lð Minimalizacja ryzyka lð Wysoka jako[ produktu Wady: lð Du|e nakBady na tworzenie prototypów lð Kiepskie dostosowanie do maBych i [rednich projektów itm / MVLab (c) 2007-2008 Model spiralny lð Model bazujcy na analizie ryzyka lð Koncentracja na kluczowych problemach w fazach pocztkowych lð Cele ka|dego z cykli wyprowadzane s na podstawie wyników cyklu poprzedzajcego lð Osobne cykle spiralne mog by wykorzystane dla ró|nych komponentów oprogramowania itm / MVLab (c) 2007-2008 Model spiralny zalety i wady Zalety: lð Elastyczny model minimalizujcy ryzyko lð Mo|liwo[ wczesnej eliminacji bBdów lub nienadajcych si propozycji alternatywnych lð Wsparcie ponownego wykorzystania moduBów SW dziki rozwa|aniu propozycji alternatywnych Wady: lð Du|a trudno[ zarzdzania projektem. Trudno okre[li jakie warunki bra pod uwag dla specyfiki projektu. lð Nieefektywny dla maBych projektów itm / MVLab (c) 2007-2008 eXtreme Programming lð szybki model spiralny 1. Okre[l cel. lð opracowany w roku 1995 2. Wykonaj dziaBanie. 3. Odbierz informacj zwrotn. przez Kenta Becka, Warda 4. Skoryguj dziaBanie tak, Cunninghama i Rona by kolejny efekt byB bli|szy sukcesowi. Jeffriesa lð model postpowania dla programowania obiektowego lð zwinny proces rozwoju aplikacji dla maBych zespoBów lð praca sterowana testami itm / MVLab (c) 2007-2008 XP -to co najwa|niejsze lð Iteracyjno[ -program tworzy si w iteracjach (krótkie, przyrostowe kroki programistyczne); planuje tylko nastpn iteracj. Efektem powinna by wersja speBniajc zaBo|enia danej iteracji. Nastpnie planuje si co zrobi dalej. -Zasada Open Source: "release early, release often". lð Nie projektowa z góry -nie mo|na z góry przewidzie, jaka architektura bdzie najlepsza dla danego problemu -nale|y j tworzy w miar rozszerzania programu. lð Testy podzespoBów -testy podzespoBów pisze si zanim w ogóle zacznie si pisa kod - najlepiej na pocztku iteracji. Potem pisze si kod, który potrafi je wszystkie przej[. Rezultat: to, co wa|ne, zostanie zaprojektowane, na reszt nie bdzie tracony czas. lð CigBe modyfikacje architektury -architektura nie jest niczym staBym; je[li jej modyfikacja uBatwi przej[cie danej iteracji i nie zepsuje wyników testów z poprzednich, nale|y j wykona. Pod t zasad podlega tak|e usuwanie wszystkich znanych bBdów przed rozszerzeniem funkcjonalno[ci. lð Programowanie parami -programi[ci pisz w parach: jeden przy klawiaturze (gBówny koder), drugi obserwuje, zgBasza poprawki, zadaje pytania wyja[niajce (szybkie wyBapanie wielu bBdów). Kod, którym zajmuje si tylko jedna osoba, ma tendencje do stawania si caBkowicie niezrozumiaBym dla kogokolwiek innego ni| autor, a wic dodatkowy programista zwiksza jako[ kodu. lð StaBy kontakt z klientem -specyfikacje s prawie zawsze wieloznaczne, dziurawe i sprzeczne ze sob -nale|y mie staBy kontakt z tym, dla kogo to oprogramowanie jest tworzone (klient zamawiajcy program, czy te| u|ytkownicy koDcowi). itm / MVLab (c) 2007-2008 Praktyki XP CigBa integracja Programowanie w parach i testowanie Wspólna odpowiedzialno[ Otwarta przestrzeD robocza Klient jest cz[ci zespoBu Efektywno[ Refaktoryzacja itm / MVLab (c) 2007-2008 Refaktoryzacja lð Refaktoryzacja (czasem te| refaktoring, ang. refactoring) to pojcie zwizane z wytwarzaniem systemów informatycznych, w szczególno[ci z programowaniem. Jest to proces wprowadzania zmian w strukturze wewntrznej projekcie/programie, w wyniku którego zasadniczo nie zmienia si funkcjonalno[ i interfejs u|ytkownika. W ramach refaktoryzacji podejmowane s nastpujce dziaBania: lð modyfikowanie elementów systemu w celu wpasowania ich w przyjte standardy i wzorce lð poszukiwanie nowych standardów i wzorców, które pojawiBy si w systemie w trakcie jego rozwoju i ich precyzyjne definiowanie (Bcznie z wpasowywaniem istniejcych elementów w te definicje) itm / MVLab (c) 2007-2008 XP - zalety i wady lð du|y wpByw klienta podczas procesu projektowania lð wysoka motywacja programistów lð wiarygodno[ terminów lð pierwsza dziaBajca wersja oprogramowania powstaje bardzo szybko (cho w bardzo ograniczonej formie) lð wysoka jako[ produktu koDcowego lð brak mo|liwo[ci stosowania w du|ych projektach lð brak wyraznej specyfikacji lð brak dokumentacji projektowej lð testy s jedyn kontrol poprawno[ci dziaBania - brak dodatkowej kontroli jako[ci itm / MVLab (c) 2007-2008 Wybór odpowiedniego modelu V-Model Model sawtooth Prototypowanie Model Model kaskadowy spiralny Model XP Code&fix stopieD innowacyjno[ci itm / MVLab (c) 2007-2008 rozlegBo[ projektu Cykle |ycia projektów lð Opisywanie i przyporzdkowywanie trzech istotnych faz procesu projektowania oprogramowania lð Znajomo[ i zrozumienie zasadniczych koncepcji rozwoju oprogramowania lð Przegld obydwu najwa|niejszych koncepcji procesu tworzenia oprogramowania Analiza Projektowanie Implementacja itm / MVLab (c) 2007-2008 Analiza Projektowanie Implementacja Analiza wymagaD Problem Analiza systemu Model w Implementacja dziedzinie Wymagania problemu Model Problemu Rozwizanie (np. w UML) Projektowanie systemu Model w dziedzinie rozwizaD: Model Rozwizania Podczas analizy i projektowania tworzone s modele problemów lub ich rozwizaD ’! redukcja stopnia trudno[ci itm / MVLab (c) 2007-2008 Definicje lð Analiza wymagaD (zapotrzebowaD): zapotrzebowania wyznaczaj jako[ciowe i ilo[ciowe wBa[ciwo[ci produktu z punktu widzenia zleceniodawcy. Wymagania s definiowane podczas fazy analizy lð Analiza systemu: przeBo|enie wymagaD na nowy produkt programistyczny w postaci modelu problemu. lð Projektowanie: rozwijanie takich [rodków technicznych (programistyczne), które doprowadz do rozwizania problemu; tworzony jest model produktu w przestrzeni rozwizaD; na koDcu otrzymuje si koncepcj rozwizania. lð Implementacja: budowanie dziaBajcego rozwizania programistycznego na bazie utworzonych koncepcji. itm / MVLab (c) 2007-2008 Historia metodyk projektowania D|ungla metodyk podej[cie Analiza obiektowa (OOA) proceduralne Analiza strukturalna (SA) Strukturalny design (SD) Obiektowy design (OOD) Programowanie strukturalne (SP) Programowanie obiektowe (OOP) podej[cie obiektowe itm / MVLab (c) 2007-2008 Podstawowe koncepcje projektowania aplikacji I Modele daj odpowiednie podej[cie do problemu ew. jego rozwizania. WBasno[ci koncepcji podstawowych: lð koncepcja atomowa lð koncepcyjnie dBugowieczna lð koncepcje wielokrotnego u|ycia lð koncepcje stosowalno[ci w ró|nych kontekstach itm / MVLab (c) 2007-2008 Podstawowe koncepcje projektowania aplikacji II Modele daj odpowiednie podej[cie do problemu ew. jego rozwizania. Dla ró|nych sposobów patrzenie na problem z biegiem czasu powstaBy ró|ne sposoby ich opisu: lð podej[cie funkcjonalne: funkcjonalna hierarchia, przepByw informacji, lð podej[cie orientowane na dane: struktury danych, encje i relacje, lð podej[cie orientowane obiektowo: struktury klasowe, lð podej[cie algorytmiczne: struktury sterujce, lð podej[cie reguBowe: struktury je[li-to, lð podej[cie stanowe: automat skoDczony, struktury wspóBbie|ne lð podej[cie oparte na scenariuszach: schematy interakcji itm / MVLab (c) 2007-2008 Zastosowanie koncepcji bazowych Podej[cie obiektowe Podej[cie proceduralne Metody: Metody: lð lð Analiza obiektowa (OOA), Analiza strukturalna (SA), lð lð Projektowanie obiektowe Projektowanie strukturalne (SD), (OOD), Stosow. koncepcje bazowe: Stosow. koncepcje bazowe: lð podej[cie funkcjonalne lð podej[cie OO lð podej[cie orientowane na dane, lð podej[cie orientowane na dane, lð podej[cie algorytmiczne lð podej[cie algorytmiczne, lð podej[cie stanowe, lð podej[cie oparte na scenariuszach itm / MVLab (c) 2007-2008

Wyszukiwarka

Podobne podstrony:
PodstawyProgramowania W02
inf2 w06
W02 AK1 Biernat
Aire W02
W02 manual ES v 1
Instrukcja GECO G 203 P01P S v03 w02 POL
469 W02 SKiTI wprowadzenie podstawowe pojecia
TO2 ETK W02 MetodaKlasyczna cz1
Instrukcja GECO G 203 P00 S v02 w02 POL
inf2 w01
w02
podst inf2 dzialana na liczbach dwojkowych
podst inf2 jezyki formalne
w02 2 Klasyfikacje

więcej podobnych podstron