Edytuj stronę Odnośniki Fold/unfold all ODT export Ta strona jest tylko do odczytu. Możesz wyświetlić źródła tej strony ale nie możesz ich zmienić. ~~SLIDESHOW thesis~~ ====== Cykle życia oprogramowania ====== {{http://upload.wikimedia.org/wikipedia/commons/thumb/5/5f/Three_software_development_patterns_mashed_together.svg/640px-Three_software_development_patterns_mashed_together.svg.png?400}} <fs xx-small>//Źródło: [[http://en.wikipedia.org/wiki/Software_development_process|wikipedia.org]]//</fs> ===== Model kaskadowy ===== * Kolejne etapy następują po sobie bezpośrednio: [[wppl>Model kaskadowy]] (waterfall), wodospadowy, liniowy {{http://upload.wikimedia.org/wikipedia/commons/thumb/e/e9/POL_model_kaskadowy.svg/567px-POL_model_kaskadowy.svg.png?500}} ===== ===== Zalety: * Klient wie dokładnie czego się spodziewać. Precyzyjnie określenie tego co program będzie realizował w ostatecznej wersji. * Możliwe całościowe oszacowanie kosztów i czasu trwania projektu. * Projekt dobrze udokumentowany na każdym etapie * Stabilność i bezpieczeństwo, np. dzięki dużej licznie dokumnetacji nowa osoba może byc szybko wdrożona do projektu * Łatwy nadzór Wady: * Brak możliwości powrotu do poprzedniego etapu * Początkowe założenia są bardzo istotne, projekt musi być w całości zaplanowany i wszystkie wymagania musza być rozpoznane od początku projektu * Błąd popełniony w początkowej fazie może mieś drastyczny wpływ na całość projektu * Produkt jest testowany wyłącznie na końcowym etapie. Późne wykrywanie błędów podnosi koszty. * Brak uwzględnienia zmian w zapotrzebowaniu klienta, rynku, zmian w technologiach ===== Ewolucyjne ===== Aktywności się przeplatają. Te same (zazwyczaj) czynności jak w modelu kaskadowym, ale pozwala się na powroty z pewnych faz do innych faz poprzedzających. {{:zajecia:ppz:ewolucyjny.jpeg?300|}} Cechy * adaptowanie systemu do zmian w wymaganiach i korygowanie popełnionych błędów * trudne w nadzorowaniu, wymaga dodatkowych strategii dla uporządkowania procesu wytwarzania oprogramowania ===== Metody ewolucyjne i odmiany ===== * [[wppl>Model prototypowy]] * [[wppl>Model spiralny]] * [[wppl>Model przyrostowy]], iteracyjny (incremental development) * [[wppl>Programowanie zwinne]] (Agile software development) [[http://www.agilemanifesto.org/iso/pl/|Manifest Agile]], [[zajecia:ppz:plan_prac#Scrum|Scrum]] * [[wppl>Programowanie ekstremalne]] * [[wppl>Rational Unified Process]] - IBM, lekka wersja OpenUP/Basic, wchodzi w skład [[http://www.eclipse.org/epf/|Eclipse Process Framework]] * programowanie odkrywcze * inne... ===== Model prototypowy (prototypowanie) ===== Prototyp - niepełny system, spełniający cześć wymagań, przeznaczonym do przetestowania rozwiązań wykorzystanych do jego wytworzenia. Produkt finalny może być (z zasady jest) różny od prototypu. Z założenia prototyp nie wchodzi w skład ostatecznego systemu.\\ Ostateczny system budowany jest od podstaw po zaakceptowaniu rozwiązań zastosowanych w prototypie. Cechy: * Prototyp jest łatwy do zmiany * Zwiększa zrozumienie programistów co do potrzeb klienta * Pozwala klientowi zobaczyć jak mniej więcej system będzie wyglądał * Wysoki koszt budowy systemu [[wppl>Model prototypowy]] ([[wp>Software prototyping]]) ===== Model spiralny ===== {{:zajecia:ppz:spiralny.jpg?300|}} * "Ogólny" model iteracyjny. * Fazy: 1) ustalanie celów, 2) rozpoznawanie zagrożeń, 3) tworzenie, 4) ocena i planowanie * Faza oceny w każdym cyklu pozwala uniknąć błędów lub wcześniej je wykryć * szczegółowe potraktowanie zagrożeń realizacji projektu (duże projekty) ===== Model przyrostowy (iteracyjny) ===== Określenie wymagań -> podział na kolejne „przyrosty” (iteracje), funkcje systemu dające się zaimplementować i testować\\ Pierwsze wersje zazwyczaj ujmują podstawowe funkcjonalności systemu. Problemem podstawowym wytwarzania przyrostowego jest określenie „przyrostów”, tak aby były one istotnymi fragmentami oprogramowania, a mimo to każdą z wersji dawało się niezależnie testować i oceniać {{:zajecia:ppz:iteracyjny1.jpeg?400|}} ===== Metodyki zwinne - Agile ===== * zakłada, że wymagania odbiorcy (klienta) często ewoluują podczas trwania projektu -> regularna adaptacja do zmieniających się wymagań * późne zmiany w specyfikacji nie mają destrukcyjnego wpływu na proces wytwarzania oprogramowania, * szybkie wytwarzanie oprogramowania wysokiej jakości, działające oprogramowanie jest dostarczane okresowo (tygodniowo), każda iteracja dostarcza **działające** i **przetestowane** funkcje * bezpośredni kontakt, jako najlepsza forma komunikacji w zespole i poza nim (zazwyczaj małe zespoły), potrzeba mniej dokumentacji * bardzo ważny jest odpowiedni nadzór nad procesem wytwórczym. ===== ===== Wady: * trudności z oszacowaniem czasu rezlizacji oraz budrzetu projektu * wymagana duża aktywność i współpraca członków zespołu, bezpośredni kontakt nie zawsze możliwy w projektach np. open source * sumaryczny czas wykonania projektu zazwyczaj bedzie dłuższy niż w modelu kaskadowym * zmiany personalne w zespole moga mieć katastrofalne skutki * końcowy produkt może znaczenie odbiegać od pierwotnych zależeń ===== Programowanie ekstremalne ===== * wydajne tworzenie małych i średnich "projektów wysokiego ryzyka", czyli takich, w których nie wiadomo do końca, co się tak naprawdę robi i jak to prawidłowo zrobić * krótkie iteracje, planowany wyłącznie najbliższy przyrost * brak ogólnego planu architektury, architektura powstaje i ewoluuje wraz z projektem * najpierw testy jednostkowe potem kod testowany (Test-driven development, TDD) * programowanie parami: wyłapywanie błędów, wzajemna nauka * stały kontakt z klientem, który może nawet zastąpić specyfikację ===== Żródła ===== - Wikipedia - [[http://brasil.cel.agh.edu.pl/~10sdczerner/page/wstep|Wykład "Inżynieria oprogramowania" - Dawid Czerner]] - Ilona Bluemke, //Inżynieria oprogramowania// - [[wp>Software development methodology]]