In ż ynieria oprogramowania wykład II Modele i fazy cyklu życia oprogramowania prowadzący: dr hab. inż. Krzysztof Bartecki, prof. PO www.k.bartecki.po.opole.pl
Egzamin: część teoretyczna Test jednokrotnego wyboru, około 20-25 pytań. Przykładowe pytanie testowe: Pojęcie kryzysu oprogramowania odnosi się do: a) niewystarczającej znajomości technik informatycznych wśród społeczeństwa, b) niewystarczających, w stosunku do obecnych wymagań, możliwości sprzętu komputerowego, c) powiększającej się rozbieżności między mocą obliczeniową sprzętu komputerowego a rozwojem technik wytwarzania oprogramowania, d) skutków, jakie miał w roku 2000 wywołać sposób zapisu daty w programach komputerowych. Egzamin: zadanie praktyczne Zamodelować diagram związków encji dla opisanego systemu. Zamodelować w języku UML diagram klas dla opisanego systemu. K. Bartecki, Inżynieria oprogramowania, II/2
Oprogramowanie próba definicji Oprogramowanie (ang. software) to zbiorcza nazwa pewnej całości, umożliwiającej wykorzystanie sprzętu komputerowego (ang. hardware), na którą to całość składają się następujące elementy: zestaw instrukcji (kod programu), realizujący określone funkcje, wymagane przez użytkownika oprogramowania, zintegrowany zestaw danych, przetwarzanych przez program w celu osiągnięcia założonego efektu (realizacji określonej funkcji), interfejs użytkownika, umożliwiający interakcję oprogramowania z użytkownikiem (np. wprowadzanie nowych danych, odczyt danych), dokumentacja, opisująca mechanizmy działania programu oraz przedstawiająca sposoby korzystania z oprogramowania. K. Bartecki, Inżynieria oprogramowania, II/3
Rodzaje oprogramowania ze względu na przeznaczenie oprogramowanie systemowe realizujące funkcje niezbędne dla działania systemu komputerowego (np. systemy operacyjne, sterowniki, oprogramowanie serwerowe, itp.), oprogramowanie użytkowe (np. programy biurowe, programy do zarządzania firmą, do obsługi multimediów, itp.), oprogramowanie do projektowania i tworzenia oprogramowania (narzędzia CASE, w tym narzędzia RAD), biblioteki programistyczne oprogramowanie do wykorzystania przez inne programy, złośliwe oprogramowanie aplikacje, skrypty, itp., mające szkodliwe, przestępcze lub złośliwe działanie w stosunku do użytkownika komputera. K. Bartecki, Inżynieria oprogramowania, II/4
Klasyfikacja oprogramowania ogólnodostępne oprogramowanie komercyjne (ang. commercial software, off-the-shelf software) oprogramowanie tworzone przez przedsiębiorstwa, których celem jest zarabianie pieniędzy na jego sprzedaży i wykorzystywaniu. oprogramowanie niekomercyjne (ang. non-commercial software) gdy producent lub dystrybutor oprogramowania działa w celu innym, niż osiągnięcie zysku. oprogramowanie tworzone na zamówienie (ang. custom software, (bespoke software, tailor-made software) oprogramowanie specjalnie projektowane i wykonywane dla pewnej określonej organizacji, przedsiębiorstwa lub innego użytkownika. K. Bartecki, Inżynieria oprogramowania, II/5
Klasyfikacja oprogramowania c.d. Zarówno oprogramowanie komercyjne, jak i niekomercyjne może być: zamknięte, prawnie zastrzeżone (ang. proprietary software) objęte restrykcjami dotyczącymi używania, kopiowania lub modyfikacji, rozpowszechniane zwykle tylko w postaci binarnej (bez kodu źródłowego), wolne (ang. free software) może być uruchamiane, kopiowane, rozpowszechniane, analizowane oraz zmieniane i poprawiane przez użytkowników. Kod źródłowy oprogramowania jest dostępny. Uwaga: oprogramowanie zamknięte często jest błędnie utożsamiane z oprogramowanie komercyjnym w niektórych przypadkach oprogramowanie zamknięte może być dostępne za darmo, jak i oprogramowanie wolne może mieć częściowo charakter komercyjny (np. odpłatne szkolenia z obsługi, wsparcie klienta czy płatny dostęp do dodatkowych rozszerzeń, wtyczek, dodatków i modułów). K. Bartecki, Inżynieria oprogramowania, II/6
Proces tworzenia oprogramowania jest zbiorem czynności i związanych z nimi wyników, które prowadzą do powstania produktu programowego (programowania), może to być tworzenie oprogramowania od zera, ale coraz częściej nowe oprogramowanie powstaje przez rozbudowę i modyfikowanie istniejących systemów. K. Bartecki, Inżynieria oprogramowania, II/7
Idea przyświecająca wytwarzaniu oprogramowania: Myśląc o czymś bardzo skomplikowanym, nie próbuj robić wszystkiego jednocześnie. Podziel to na mniej złożone części i skoncentruj się kolejno na każdej z nich. Z tego względu proces wytwarzania oprogramowania dzieli się zwykle na pewne fazy. K. Bartecki, Inżynieria oprogramowania, II/8
Ogólne fazy procesu produkcji oprogramowania specyfikacja określenie i zapisanie wymagań, które musi spełniać oprogramowanie, projektowanie ustalenie ogólnej architektury systemu oraz wymagań dla poszczególnych jego składowych, implementacja realizacja ustalonej architektury poprzez tworzenie kodu składowych systemu (modułów) oraz połączeń między nimi, integracja zintegrowanie poszczególnych składowych (modułów) w jeden system, testowanie całego systemu, ewolucja uruchomienie systemu, usuwanie wykrytych podczas jego używania błędów, rozszerzanie systemu. K. Bartecki, Inżynieria oprogramowania, II/9
Modele cyklu życia oprogramowania model kaskadowy, model przyrostowy (iteracyjny), model V, model prototypowy, programowanie odkrywcze, model spiralny, model formalnych transformacji. K. Bartecki, Inżynieria oprogramowania, II/10
Model kaskadowy W modelu kaskadowym (ang. waterfall model), nazywanym także modelem liniowym, wszystkie podstawowe czynności przy tworzeniu oprogramowania wykonywane są jako odrębne fazy projektowe, jedna po drugiej. Wymagania Projektowanie Implementacja Testowanie Konserwacja K. Bartecki, Inżynieria oprogramowania, II/11
Model kaskadowy fazy Faza określenia wymagań (ang. requirements) określane są cele oraz szczegółowe wymagania wobec tworzonego systemu, Faza projektowania (ang. design) powstaje szczegółowy projekt systemu, spełniającego ustalone wcześniej wymagania, Faza implementacji (ang. implementation) projekt implementowany (kodowany) jest w określonym środowisku programistycznym oraz wykonywane są testy jego modułów, Faza testowania (ang. verification) następuje integracja oraz testowanie całości oprogramowania, Faza konserwacji (ang. maintenance) oprogramowanie jest wykorzystywane przez użytkowników, a producent dokonuje jego konserwacji (usuwanie błędów, rozszerzanie funkcji, wsparcie techniczne). K. Bartecki, Inżynieria oprogramowania, II/12
Dodatkowe fazy modelu kaskadowego Wymagania Projektowanie Implementacja Testowanie Konserwacja Strategiczna Analiza Instalacja Dokumentacja Faza strategiczna (ang. strategy) strategiczne decyzje dotyczące kolejnych etapów prac, Faza analizy (ang. analysis) budowa logicznego modelu systemu, Faza dokumentacji (ang. documentation) wytwarzanie dokumentacji użytkownika, Faza instalacji (ang. installation) instalacja systemu i przekazanie go użytkownikowi. K. Bartecki, Inżynieria oprogramowania, II/13
Model kaskadowy z iteracjami Jeśli któraś z faz da niezadowalający efekt, cofamy się, wykonując kolejne iteracje, aż do momentu, kiedy na końcu schodków otrzymamy satysfakcjonujący produkt. Wymagania Projektowanie Implementacja Testowanie Konserwacja K. Bartecki, Inżynieria oprogramowania, II/14
Zalety modelu kaskadowego: przejrzystość, łatwość zarządzania przedsięwzięciem, stanowi podstawę dla wielu innych modeli życia oprogramowania. Wady modelu kaskadowego: narzucenie twórcom oprogramowania ścisłej kolejności wykonywania prac nie można przejść do następnej fazy przed zakończeniem poprzedniej, wysoki koszt błędów popełnionych we wstępnych fazach iteracje są bardzo kosztowne, gdyż powtarzamy wiele czynności, długa przerwa w kontaktach z klientem projektowanie oraz implementacja wykonywane są wyłącznie przez firmę programistyczną. K. Bartecki, Inżynieria oprogramowania, II/15
Model przyrostowy (iteracyjny) W modelu przyrostowym (ang. incremental model), po określeniu wymagań oraz zbudowaniu ogólnego projektu systemu, wybierany, implementowany oraz dostarczany klientowi jest kolejny podzbiór funkcji systemu. wymagania ogólny projekt proces realizowany iteracyjnie wybór podzbioru funkcji projekt, implementacja, testy dostarczenie klientowi K. Bartecki, Inżynieria oprogramowania, II/16
Model przyrostowy fazy określenie całości wymagań (na ile uda się je sprecyzować), oraz wykonanie wstępnego, ogólnego projektu całości systemu, wybór pewnego podzbioru funkcji systemu, szczegółowy projekt (zgodnie z modelem kaskadowym) oraz implementacja części systemu realizującej wybrane funkcje, testowanie zrealizowanego fragmentu i dostarczenie go klientowi, powtarzanie kolejnych etapów (od wyboru nowego podzbioru funkcji), aż do zakończenia implementacji całego systemu. K. Bartecki, Inżynieria oprogramowania, II/17
Zalety modelu przyrostowego: częstsze niż w modelu kaskadowym kontakty z klientem, brak konieczności definiowania z góry całości wymagań, możliwość wcześniejszego wykorzystania przez klienta fragmentów systemu, możliwość elastycznego reagowania na opóźnienia realizacji fragmentu przyspieszenie prac nad innymi częściami. Wady modelu przyrostowego: dodatkowy koszt związany z niezależną realizacją fragmentów systemu, trudności z wycinaniem podzbioru funkcji w pełni niezależnych, konieczność implementacji szkieletów (interfejs). K. Bartecki, Inżynieria oprogramowania, II/18
źródło: testerzy.pl Model V jest rozwinięciem modelu kaskadowego, charakteryzującym się rozbudowaną fazą testów, testy te mają na celu weryfikację poprawności każdego etapu, dzięki temu, że każdy z etapów wytwórczych kończy się przeglądami i inspekcjami, prawdopodobieństwo pojawienia się błędu lub niezgodności z wymaganiami przy wdrożeniu i eksploatacji jest dużo mniejsze niż w klasycznym modelu kaskadowym, implementacja stanowi zakończenie lewego ramienia projektowania, prawe ramię, czyli weryfikacja, to sprawdzanie, czy wstępne założenia zostały wypełnione poczynając od sprawdzania najmniejszych komponentów na całym zintegrowanym systemie kończąc. K. Bartecki, Inżynieria oprogramowania, II/19
Zalety modelu V: mniejsze niż w modelu kaskadowym prawdopodobieństwo wystąpienia błędów, w związku z powyższym znaczące obniżenie kosztów pielęgnacji systemu, zachęca do jak najwcześniejszego rozpoczęcia procesu tworzenia planów testów, specyfikacji testowej i samego testowania. Wady modelu V: stanowi jedynie niewielką modyfikację modelu kaskadowego, powielając jego wady, stanowi jedynie propozycję (w dużej mierze teoretyczną) idealnego świata współpracy między architektami, a programistami, testerami i klientami. K. Bartecki, Inżynieria oprogramowania, II/20
Model prototypowy polega na stworzeniu podczas projektowania prototypu systemu w celu przedyskutowania oraz akceptacji ze strony klienta. Metody budowy prototypu: rozpisanie interfejsów użytkownika na kartce papieru, realizacja wyłącznie interfejsu użytkownika, np. z wykorzystaniem narzędzi RAD (ang. Rapid Application Development), niepełna realizacja np. implementacja jedynie kilku modułów systemu, implementacja metod działających jedynie w większości przypadków lub dla niektórych danych, w celu pokazanie jedynie idei, niskiej jakości system wykonany za pomocą modelu odkrywczego, który stosunkowo szybko się wykonuje. K. Bartecki, Inżynieria oprogramowania, II/21
Zalety modelu prototypowego: pozwala klientowi szybko zobaczyć jak mniej więcej będzie wyglądał system, zwiększa zrozumienie twórców systemu co do potrzeb klienta, w zależności od rodzaju prototypu, może pozwalać rozpocząć szkolenie obsługi systemu po stronie klienta, prototyp jest łatwy do zmiany. Wady modelu prototypowego: wysoki koszt budowy systemu po weryfikacji prototyp jest najczęściej porzucany lub tylko częściowo wykorzystywany do budowy właściwego systemu, możliwość nieporozumień z klientem klient widzi prawie gotowy produkt, który w rzeczywistości jest dopiero w początkowej fazie rozwoju. K. Bartecki, Inżynieria oprogramowania, II/22
Programowanie odkrywcze Programowanie odkrywcze (ang. exploratory programming) to model, w którym budowa systemu rozpoczyna się natychmiast po określeniu ogólnych wymagań. Zbudowany system jest weryfikowany przez klienta jeżeli zostanie uznany za nieodpowiedni, budowana (modyfikowana) jest kolejna jego wersja tak długo, aż jedna z kolejnych jego wersji zadowoli klienta. Określenie ogólnych wymagań Budowa systemu Testowanie systemu System działa poprawnie? Dostarczenie systemu K. Bartecki, Inżynieria oprogramowania, II/23
Zalety programowania odkrywczego: możliwość stosowania przy bardzo trudnych sytuacjach z określeniem wymagań klienta, dobrze opisuje amatorski sposób tworzenia oprogramowania, w profesjonalnych projektach dobrze nadaje się do budowy prototypu, Wady programowania odkrywczego: brak możliwości opracowania i zachowania sensownej struktury systemu, testowanie odbywa się jedynie przy obecności klienta ze względu na brak pełnych wymagań. K. Bartecki, Inżynieria oprogramowania, II/24
Model spiralny W modelu spiralnym (ang. spiral model) proces tworzenia oprogramowania ma postać spirali, której każda pętla reprezentuje jedną iterację procesu. Najbardziej wewnętrzna pętla przedstawia początkowe etapy projektowania, np. studium wykonalności, kolejna definicji wymagań systemowych, itd. Analiza ryzyka w oparciu o wymagania wstępne Weryfikacja planu projektu oraz planowanie kolejnej iteracji na podstawie ocen użytkownika Analiza ryzyka na podstawie ocen użytkownika Wymagania wstępne, plan projektu Kolejne wersje produktu K. Bartecki, Inżynieria oprogramowania, II/25
Model spiralny fazy Model spiralny składa się z czterech głównych faz, wykonywanych cyklicznie: planowanie definiowanie konkretnych celów, wymaganych w danej fazie przedsięwzięcia. analiza ryzyka identyfikacja ograniczeń i zagrożeń, ustalanie planów realizacji, tworzenie i zatwierdzanie tworzenie oprogramowania w oparciu o najbardziej odpowiedni model, wybrany na podstawie oceny zagrożeń, ocena i planowanie recenzja postępu prac i planowanie kolejnej fazy przedsięwzięcia, bądź zakończenie projektu. K. Bartecki, Inżynieria oprogramowania, II/26
Zalety modelu spiralnego: można wykorzystać gotowe projekty, faza oceny przeprowadzana w każdym cyklu pozwala uniknąć błędów lub odpowiednio wcześnie je wykryć, cały czas istnieje możliwość rozwijania projektu. Wady modelu spiralnego: metodologia nie do końca dopracowana każdy projekt jest inny i powstaje w innych warunkach, tworzenie w oparciu o ten model wymaga doświadczenia w prowadzeniu tego typu projektów oraz wiedzy ekonomicznej w zarządzaniu, przeznaczony tylko dla dużych przedsięwzięć programistycznych. K. Bartecki, Inżynieria oprogramowania, II/27
Model formalnych transformacji W metodzie formalnych transformacji (ang. formal transformations) zakłada się, że wymagania systemowe zapisywane są w pewnym formalnym języku. Następnie podlegają one automatycznym (tzn. bez udziału ludzi) transformacjom do kolejnych form coraz bliższych kodowi. Formalna specyfikacja wymagań Postać pośrednia... Postać pośrednia Kod K. Bartecki, Inżynieria oprogramowania, II/28
Zalety modelu formalnych transformacji: pełna automatyzacja procesu wytwarzania oprogramowania, wysoka niezawodność, jeśli nie popełniono błędów na etapie określania wymagań. Wady modelu formalnych transformacji: trudność formalnej specyfikacji wymagań polega ona tu właściwie na napisaniu programu rozwiązującego pewien problem, który podlegał będzie stopniowej kompilacji do poziomu kodu, mała efektywność tak uzyskanego kodu, brak dobrze rozwiniętych języków formalnej specyfikacji wymagań, model stanowi właściwie jedynie propozycję teoretyczną, związaną z tzw. nurtem formalnym inżynierii oprogramowania. K. Bartecki, Inżynieria oprogramowania, II/29
Co to jest RUP? RUP (ang. Rational Unified Process) to proces iteracyjnego wytwarzania oprogramowania opracowany przez firmę Rational Software Corporation (przedsiębiorstwo zostało przejęte przez IBM). Proces RUP został opracowany z użyciem tych samych technik, których zespół Rational używał do modelowania systemów czyli głównie języka UML. Język UML powstawał równolegle z RUP. Powstał na bazie analizy najczęstszych przyczyn niepowodzeń istniejących procesów wytwarzania oprogramowania. K. Bartecki, Inżynieria oprogramowania, II/30
RUP bazuje na zbiorze zasad inżynierii programowania oraz na tzw. najlepszych praktykach, wśród których można wymienić: iteracyjne wytwarzanie oprogramowania (Iterative Development), zarządzanie wymaganiami (Requirement Management) skupione na zaspokojeniu oczekiwań użytkowników końcowych systemu poprzez identyfikację i specyfikację ich potrzeb oraz wykrywanie zmiany tych wymagań, używanie architektury bazującej na komponentach (Component-based architecture) komponentem nazywamy zbiór powiązanych obiektów (w sensie programowania obiektowego), graficzne projektowanie oprogramowania, kontrolę jakości oprogramowania (Quality Assurance) RUP zakłada, że każdy członek zespołu jest odpowiedzialny za jakość w ciągu całego procesu, proces kontroli zmian w oprogramowaniu (Change Management). K. Bartecki, Inżynieria oprogramowania, II/31
Fazy RUP K. Bartecki, Inżynieria oprogramowania, II/32
Cykl życia oprogramowania na wesoło : K. Bartecki, Inżynieria oprogramowania, II/33