Podstawy Inżynierii Oprogramowania

Prezentacja na temat: "Podstawy Inżynierii Oprogramowania"— Zapis prezentacji:

1 Podstawy Inżynierii Oprogramowania
WYKŁAD 2 Modele cyklu życia oprogramowania Dr hab. inż. Barbara Dębska, prof. PWSZ Dr hab. inż. Barbara Dębska, prof. PWSZ

2 REALIZACJA KIEROWANA DOKUMENTAMI
Model: został zaproponowany przez armię amerykańską (wysoki koszt), jest ścisłą realizacją modelu kaskadowego, więc składa się z szeregu sekwencyjnych faz, zakłada, że każda faza kończy się opracowaniem szeregu dokumentów, w pełni opisujących wyniki tej fazy, dokumenty są podstawą do realizacji kolejnych faz, dokumenty udostępnia się klientowi, i kolejna faza rozpoczyna się po zaakceptowaniu dokumentów przez klienta. Dr hab. inż. Barbara Dębska, prof. PWSZ

3 REALIZACJA KIEROWANA DOKUMENTAMI c.d.
Zalety modelu Realizacja Kierowana Dokumentami: takie same jak modelu kaskadowego, a ponadto możliwość (teoretyczna) przerwania realizacji w jednej firmie i wznowienie realizacji w innej po przekazaniu jej kompletu dokumentów. Wady modelu Realizacja Kierowana Dokumentami: takie same jak modelu kaskadowego, a ponadto duży nakład pracy na opracowanie dokumentów (ponad 50% całkowitych nakładów), przerwy w realizacji przedsięwzięcia niezbędne dla weryfikacji dokumentów przez klienta. Dr hab. inż. Barbara Dębska, prof. PWSZ

4 PROTOTYPOWANIE Na potrzeby przedsiębiorstwa tworzone są dwa rodzaje systemów informatycznych: 1. takie, które jedynie automatyzują pracę organizacji. Systemy automatyzują przechowywanie i wyszukiwanie danych. Systemy te wykonują więc praktycznie funkcje, które już były wykonywane w danej organizacji bez technologii komputerowych. 2. które, będą wyposażone w funkcje praktycznie niewykonalne bez pomocy komputera. Systemy wykonują złożone analizy, optymalizują produkcję, wspomagają podejmowanie decyzji, czy służą do automatycznego sterowania produkcją. Dla takich funkcji systemu trudne jest dobre zdefiniowanie wymagań klienta i w takich przypadkach stosuje się prototypowanie. Prototypowanie jest modelem, którego celem jest minimalizacja ryzyka związanego z niewłaściwym określeniem wymagań. Dr hab. inż. Barbara Dębska, prof. PWSZ

5 Faza Prototypowania lepiej określa wymagania, czyli:
Fazy Prototypowania: ogólne określenie wymagań, budowa prototypu, weryfikacja prototypu przez klienta, pełne określenie wymagań, realizacja pełnego systemu zgodnie z modelem kaskadowym. Faza Prototypowania lepiej określa wymagania, czyli: pozwala na wykrycie nieporozumień pomiędzy klientem a twórcami systemu, dzięki możliwości szybkiej demonstracji pracującej wersji systemu, wykrywa brakujące funkcje, umożliwia wskazanie trudnych usług, wskazuje na braki w specyfikacji wymagań, a ponadto daje możliwość szkoleń zanim zbudowany zostanie cały system. Dr hab. inż. Barbara Dębska, prof. PWSZ

6 Metody budowy Prototypu:
niepełna realizacja, prototyp obejmuje jedynie te funkcje systemu, które są trudne do określenia, wykorzystanie gotowych komponentów, generatory interfejsu użytkownika, niekiedy wystarcza, ze prototyp realizuje tylko interfejs użytkownika, szybkie programowanie, prototyp realizuje wszystkie funkcje systemu, ale został opracowany bez wyczerpującego testowania, a zatem nie jest niezawodny, rysunek na papierze, często w taki sposób powstaje przewidziana do dyskusji wersja interfejsu użytkownika, programowanie odkrywcze. Dr hab. inż. Barbara Dębska, prof. PWSZ

7 Dr hab. inż. Barbara Dębska, prof. PWSZ

8 Dr hab. inż. Barbara Dębska, prof. PWSZ

9 Wady modelu Prototypowania:
dodatkowy koszt budowy prototypu, potencjalne zdziwienie klienta (?), który musi długo czekać i sporo zapłacić za system, który został ”prawie całkowicie” wykonany w tak krótkim czasie, zazwyczaj prototyp jest porzucany i jedynie niektóre jego funkcje można wykorzystać w dalszych etapach prac, prototyp buduje się z reguły szybko, zazwyczaj kosztem jego niezawodności i efektywności. Dr hab. inż. Barbara Dębska, prof. PWSZ

10 PROGRAMOWANIE ODKRYWCZE
Stosowane wtedy, gdy określenie wymagań klienta jest tak trudne, że nawet budowa prototypu nie wystarcza do wyjaśnienia wszystkich wątpliwości. Określ ogólne wymagania Zbuduj system Przetestuj system System działa poprawnie Nie Tak Dostarcz system Budowany tą metodą system jest realizowany w kolejnych cyklach, przy czym kolejny system powstaje zazwyczaj jako modyfikacja poprzedniej wersji. Cykl kończy się, jeśli jedna z kolejnych wersji zadowala klienta, lub dojdzie on do wniosku, ze nie jest możliwe osiągnięcie lepszego efektu. Dr hab. inż. Barbara Dębska, prof. PWSZ

11 Zalety modelu Programowanie Odkrywcze:
model ten można stosować nawet w przypadku dużych trudności z określeniem wymagań klienta Wady modelu Programowanie Odkrywcze: praktycznie niemożliwe jest zachowanie sensownej struktury systemu, nawet wówczas, gdy na wstępie wykonano ogólny projekt, usuwanie w kolejnych iteracjach błędów i wprowadzanie zmian, powoduje powstawanie nowych błędów, a zatem wykonanie w ten sposób dużych, niezawodnie działających systemów jest niemożliwe, ponieważ model ten nie obejmuje pełnego określania wymagań, testowanie systemu musi odbywać się przy bezpośrednim udziale klienta, jest to amatorski sposób tworzenia systemów, nie zalecany profesjonalnym producentom oprogramowania. Dr hab. inż. Barbara Dębska, prof. PWSZ

12 REALIZACJA PRZYROSTOWA
Budowa systemu rozpoczyna się od określenia wymagań oraz wykonania wstępnego ogólnego projektu całości systemu. Z tego projektu wybierany jest podzbiór funkcji, które ma zrealizować system i budowany jest fragment systemu. Kolejne fragmenty powstają w cyklu iteracyjnym. Określenie wymagań Ogólny projekt Wybór podzbioru funkcji Proces realizowany iteracyjnie Szczegółowy projekt, implementacja testy Dostarczenie zrealizowanej części systemu Dr hab. inż. Barbara Dębska, prof. PWSZ

13 Zalety modelu Realizacja Przyrostowa:
skrócenie przerw w kontaktach z klientem, klient może wykorzystywać dostarczane mu fragmenty systemu, opóźnienie wykonania jednego fragmentu nie musi skutkować opóźnieniem całego projektu (można starać się przyśpieszyć prace nad dalszymi częściami budowanego systemu). Wady modelu Realizacja Przyrostowa: dodatkowy koszt związany z realizacją niezależnych modułów systemu, nie zawsze można wybrać podzbiór funkcji w pełni niezależnych i zachodzi konieczność budowy tzw. szkieletów modułów które znajdą się w pełnym systemie, ale nie realizujących w pełni ich funkcji, skutkuje to dodatkowym nakładem pracy oraz zwiększeniem ryzyka nie wykrycia błędów w fazie testowania. Dr hab. inż. Barbara Dębska, prof. PWSZ

14 MONTAŻ Z GOTOWYCH ELEMENTÓW
Ten model cechuje redukcja nakładów osiągnięta przez maksymalne wykorzystanie podobieństw tworzonego oprogramowania do wcześniej tworzonych systemów. Stopień ponownego wykorzystania elementów zależy od podobieństwa przedsięwzięć (niekiedy można wykorzystać nawet 90% opracowanych modułów). Zazwyczaj wielokrotnie wykorzystuje się: biblioteki, złożone instrukcje języków czwartej generacji odwołujące się do wbudowanych bibliotek, pełne aplikacje, np. przeglądarki, gotowe elementy otrzymane na etapie analizy i projektowania, modele i projekty opracowane w poprzednich przedsięwzięciach, a także gotowe projekty funkcjonowania różnych organizacji, np. banku. Dr hab. inż. Barbara Dębska, prof. PWSZ

15 Zalety stosowania modelu Montaż z Gotowych Elementów:
Gotowe elementy zakupuje się od zewnętrznych dostawców lub świadomie tak realizuje przedsięwzięcia programistyczne by pewne elementy mogły być wykorzystane przy tworzeniu kolejnych systemów. Zalety stosowania modelu Montaż z Gotowych Elementów: - wysoka niezawodność dobrze przetestowanych wielokrotnie używanych elementów, - zmniejszenie ryzyka, - efektywne wykorzystanie specjalistów, - narzucenie standardów, oraz - redukcja kosztów. Wady stosowania modelu Montaż z Gotowych Elementów: - dodatkowy koszt przygotowanie elementów w postaci umożliwiającej ich ponowne wykorzystanie, - ryzyko uzależnienia od dostawcy elementów, - niedostatki narzędzi wspierających ten rodzaj pracy (najnowsze narzędzia CASE zazwyczaj pozwalają na realizację tego modelu). Dr hab. inż. Barbara Dębska, prof. PWSZ

16 Przyszłość rozwoju aplikacji: ponowne wykorzystanie istniejących zasobów
(Wprowadzenie) Dr hab. inż. Barbara Dębska, prof. PWSZ

17 1. Fabryki oprogramowania – np
1. Fabryki oprogramowania – np. do budowy sklepów handlujących przez Internet 2. Budowa z szablonów – dostępne są 1000-ce szablonów (ww.patternsshare.org) Dr hab. inż. Barbara Dębska, prof. PWSZ

18 Dr hab. inż. Barbara Dębska, prof. PWSZ

19 Dr hab. inż. Barbara Dębska, prof. PWSZ

20 Dr hab. inż. Barbara Dębska, prof. PWSZ

21 Dr hab. inż. Barbara Dębska, prof. PWSZ

22 Dr hab. inż. Barbara Dębska, prof. PWSZ

23 Dr hab. inż. Barbara Dębska, prof. PWSZ

24 MODEL SPIRALNY To najbardziej ogólny model cyklu życia oprogramowania zaproponowany przez Bohema w 1988 roku, szczególnie przydatny dla firmy wytwarzającej kolejne rynkowe wersje oprogramowania. Dr hab. inż. Barbara Dębska, prof. PWSZ

25 Konstrukcja – zastosowanie modelu kaskadowego do budowy aplikacji.
Planowanie – ustalane są generalne cele produkcji kolejnej wersji systemu. Analiza ryzyka – rozważane są ogólne opcje budowy nowej wersji systemu i oceniane jest ryzyko związane z ich realizacją. Konstrukcja – zastosowanie modelu kaskadowego do budowy aplikacji. Atestowanie – klient ocenia kolejną wersję systemu. Jeśli ocena nie jest w pełni pozytywna rozpoczyna się kolejny cykl. Dr hab. inż. Barbara Dębska, prof. PWSZ

26 Formalna specyfikacja wymagań
FORMALNE TRANSFORMACJE W tym modelu zakłada się, że wymagania odnośnie systemu postulowane są w pewnym formalnym języku. Następnie wymagania te w sposób automatyczny są transformowane do postaci pośredniej (np. pseudokodu), która to postać jest poddawana dalszym automatycznym transformacjom coraz bliższym kodowi. W ostateczności po kolejnych transformacjach otrzymuje się taką postać, która będzie mogła być automatycznie przełożona na wybrany język programowania. Formalna specyfikacja wymagań ... Postać pośrednia Postać pośrednia Kod Dr hab. inż. Barbara Dębska, prof. PWSZ

27 Zalety modelu Formalne Transformacje:
Wysoka niezawodność oprogramowania. Jeśli nie popełniono błędów na etapie specyfikowania wymagań, kolejne automatycznie (bez udziału ludzi) generowane transformacje gwarantują, że otrzymany kod jest również bezbłędny. Wady modelu Formalne Transformacje: trudność formalnego wyspecyfikowania wymagań, mała efektywność kodu uzyskanego w ten sposób, brak dobrze rozwiniętych, uniwersalnych języków formalnej specyfikacji wymagań, co czyni z tego modelu propozycję teoretyczną. Dr hab. inż. Barbara Dębska, prof. PWSZ

28 Dr hab. inż. Barbara Dębska, prof. PWSZ

29 MODEL KASKADOWY FAZA STRATEGICZNA
Określenie wymagań Projektowanie Implementacja Testowanie Konserwacja Analiza Faza strategiczna Faza strategiczna Instalacja Dokumentacja Faza strategiczna - to faza wstępna w której: prowadzone są negocjacje z klientem lub/i firma bierze udział w przetargu, rozważana i planowana jest produkcja nowego programu (nowej wersji programu) lecz nie została jeszcze podjęta decyzja o rozpoczęciu prac. Dr hab. inż. Barbara Dębska, prof. PWSZ

30 Czynności fazy strategicznej:
przeprowadzenie serii rozmów (wywiadów) z przedstawicielami klienta, określenie celów przedsięwzięcia z punktu widzenia klienta, określenie zakresu oraz kontekstu przedsięwzięcia, ogólne określenie wymagań, wykonanie zgrubnej analizy i projektu systemu, propozycja kilku możliwych rozwiązań (sposobów realizacji systemu), oszacowanie kosztów oprogramowania, analiza rozwiązań, prezentacja wyników fazy strategicznej przedstawicielom klienta oraz korekta wyników na podstawie uzyskanych uwag, określenie wstępnego harmonogramu przedsięwzięcia oraz struktury zespołu realizującego przedsięwzięcie, określenie standardów zgodnie, z którymi realizowane będzie przedsięwzięcie. Dr hab. inż. Barbara Dębska, prof. PWSZ

31 Uwagi dotyczące fazy strategicznej:
Gdy oprogramowanie jest wykonywane na konkretne zamówienie, faza strategiczna musi być wykonywana w ścisłej współpracy z klientem, zarówno ze zleceniodawcą jak również z potencjalnymi użytkownikami systemu. Firmy produkujące oprogramowanie na rynek również powinny współpracować z potencjalnymi klientami. Pomocne są badania marketingowe oraz uwagi uzyskane od użytkowników poprzednich wersji systemu. Zadania wykonywane w fazie strategicznej: w jasny sposób określenie celów przedsięwzięcia z punktu widzenia klienta Pozwoli to uniknąć wielu nieporozumień. Cele te są ważnym punktem odniesienia w przypadku wątpliwości pojawiających się w dalszych fazach przedsięwzięcia. Dr hab. inż. Barbara Dębska, prof. PWSZ

32 Zadania wykonywane w fazie strategicznej: (c.d.)
ustalenie zakresu przedsięwzięcia, niezbędne do oszacowania kosztów. Zazwyczaj opracowywany system będzie wspomagać jedynie pewien zakres działalności klienta. W tym etapie dokładne określenie przez klienta zakresu przedsięwzięcia nie zawsze jest możliwe. Nie zawsze jest również jasne jaka część rozważanych funkcji będzie mogła być zrealizowana przez oprogramowanie, a jaka przez użytkowników, inne systemy lub sprzęt. opisanie kontekstu systemu, czyli systemów zewnętrznych, z którymi będzie współpracować tworzony system. System zewnętrzny to np. : grupa użytkowników wykorzystująca system w podobny sposób, inne działy firmy, które wykorzystują system , inne programy lub sprzęt współpracujący. bardziej precyzyjne określenie wymagań, wykonanie modelu systemu oraz wstępnego projektu. Dr hab. inż. Barbara Dębska, prof. PWSZ

33 Przykład. Cele systemu to:
Przedsięwzięciem jest opracowanie programu podatkowego PITy 2003 dla biura rozrachunkowego. Cele systemu to: przyspieszenie obsługi klientów, zwiększenie wydajności pracy pracowników biura, zmniejszenie ryzyka popełniania błędów, ponieważ w formularzu większość danych będzie automatycznie agregowana i przetwarzania. Dr hab. inż. Barbara Dębska, prof. PWSZ

34 Zakres przedsięwzięcia to:
działalność biura rozrachunkowego dotycząca przygotowania elektronicznej wersji formularzy rozliczeniowych dla klientów indywidualnych, system powinien nie tylko umożliwiać wypełnienie rubryk formularza, ale również drukować zeznania podatkowe, na tym etapie nie określa się czy firma będzie budować bazę danych o swoich klientach, np. w celu umożliwienia nanoszenia korekt w zeznaniach podatkowych. System zewnętrzny tworzą: pracownicy firmy podatkowej, którzy będą pracować z programem PITy i przygotowywać rozliczenia podatkowe klientów. Dr hab. inż. Barbara Dębska, prof. PWSZ

35 Ważne decyzje podejmowane w fazie strategicznej:
dokonanie wyboru modelu, z którym będzie realizowane przedsięwzięcie, wybór technik stosowanych w fazach analizy i projektowania, wybór środowiska implementacji, wybór narzędzia CASE, określenie stopnia wykorzystania gotowych komponentów, a także podjęcie decyzji o współpracy z innymi producentami oprogramowania lub/i zatrudnienie ekspertów z zewnątrz, określenie ograniczeń przy których przedsięwzięcie będzie realizowane (maksymalne nakłady jakie można ponieść, dostępny personel, dostępne narzędzia, ograniczenia czasowe), Dr hab. inż. Barbara Dębska, prof. PWSZ

36 Ważne decyzje podejmowane w fazie strategicznej: (c.d.)
ustalenie z klientem, które z zaproponowanych rozwiązań akceptuje, W fazie strategicznej rozważa się kilka możliwych rozwiązań, z których następnie wybiera się jedno najlepsze. uzgodnienie wstępnego harmonogramu przedsięwzięcia po jego podziale na pewne mniejsze zadania, ustalenie terminów ich realizacji i zasobów niezbędnych do ich wykonania, zdefiniowanie standardów określających wymagany sposób pracy w dalszych fazach przedsięwzięcia, wybór konkretnych narzędzi i notacji do wykorzystania, określenie sposobu opracowywania dokumentacji. Dr hab. inż. Barbara Dębska, prof. PWSZ

37 Dziękuję za uwagę Dr hab. inż. Barbara Dębska, prof. PWSZ