plik

2/18

Struktura przedmiotu



wykład 15 godz.



laboratorium 15 godz.



projekty 15 godz.



egzamin



kontakt: skowronek@mech.pk.edu.pl

3/18

Literatura cz.1



Praktyczne podejście do inżynierii oprogramowania,
Roger S. Pressman, WNT, Warszawa 2004



Podstawy techniczne inżynierii oprogramowania, Dick
Hamlet, Joe Maybee , WNT, Warszawa 2003



Inżynieria oprogramowania. Jak zapewnić jakość

tworzonym aplikacjom

Bogdan Bereza-Jarociński,

Bolesław Szomański, Helion, Gliwice 2009



Inżynieria oprogramowania, Krzysztof Sacha,
Wydawnictwo Naukowe PWN 2010



Podstawy inżynierii oprogramowania, Włodzimierz
Dąbrowski, PJWSTK 2005

4/18

Literatura cz.2



Problemy i metody inżynierii oprogramowania,
Zbigniew Huzar, Zygmunt Mazur, WNT 2003



Inżynieria oprogramowania w projekcie
informatycznym, Janusz Górski, Mikom 2000



Software Engineering: Theory and Practice, Shari
Lawrence Pfleeger,Joanne M. Atlee, Prentice Hall,
2009



Software engineering, Ian Sommerville, Pearson
Education, 2007



Essentials of software engineering. Frank F. Tsui,
Orlando Karam, Jones & Bartlett Publishers, 2006

6/18

Zagadnienia



produkt i proces wytwórczy



zarządzanie przedsięwzięciem programistycznym (analiza,
planowanie, modelowanie, tworzenie, testowanie,
implementacja, konfiguracja, obsługa)



tradycyjne metody inżynierii oprogramowania



inżynieria oprogramowania obiektowego



zaawansowane metody inżynierii oprogramowania
(oprogramowanie komponentowe, klient-serwer, aplikacje
internetowe)

7/18

Inżynieria oprogramowania –
definicja i cel stosowania



definicja → dziedzina inżynierii systemów zajmująca
się wszelkimi aspektami produkcji oprogramowania: od
analizy i określenia wymagań, przez projektowanie i
wdrożenie, aż do ewolucji gotowego oprogramowania
(wg pl.wikipedia.org)



cel → zapewnienie jakości (niezawodności,
funkcjonalności i przyjazności dla użytkownika)
produktowi - programowi komputerowemu

8/18

Model warstwowy inżynierii
oprogramowania



narzędzia → automatyzacja lub wspomaganie procesu
wytwórczego → CASE (computer aided software
engineering)



metody (różne techniki modelowania i projektowania)



proces wytwórczy – łączy poszczególne warstwy,
efektem jest gotowy produkt



dbanie o jakość – cel inżynierii oprogramowania



procedury



normy ISO



kontrole



miary procesu wytwórczego i produktu

9/18

Aspekty inżynierii
oprogramowania



produkt



oprogramowanie stosowane w różnych dziedzinach życia



obejmuje właściwy program oraz związane z nim
dokumentację i dane



proces wytwórczy → proces wytwarzania
oprogramowania (analiza, projekt, kodowanie,
testowanie, wdrażanie, wprowadzanie zmian), kluczowy
w inżynierii oprogramowania

10/18

Definicja oprogramowania



(…) to rozkazy (programy komputerowe),
których wykonanie pozwala wypełnić określone
funkcje w oczekiwany sposób, struktury
danych, które umożliwiają programom
manipulowanie informacjami, oraz dokumenty,
które opisują działanie i sposób użytkowania
programów.

(źródło: Roger S. Pressman)

11/18



jest produktem → przetwarzanie danych



gromadzenie danych



analiza danych



udostępnianie danych



przesyłanie danych



dostarcza produkt



sterowanie pracą komputerów



kontrola innych programów



tworzenie innych programów

Rola oprogramowania



jest produktem → przetwarzanie danych



gromadzenie danych



analiza danych



udostępnianie danych



przesyłanie danych



dostarcza produkt



sterowanie pracą komputerów



kontrola innych programów



tworzenie innych programów

aplikacje

użytkowe

m. in. systemy

operacyjne

środowiska

programistyczne

12/18

Cechy odróżniające oprogramowanie od
innych produktów



wytwarzanie zamiast konstruowania



fizyczne konstruowanie może być źródłem późniejszych usterek – dla
oprogramowania są łatwiejsze do usunięcia, w obu przypadkach istotną
rolę odgrywa dobry projekt (uniknięcie usterek)



koszty wytwarzania oprogramowania są wysokie zwłaszcza na etapie
projektowania, produkcja sprzętu generuje większą część kosztów na
etapie wytwarzania



nie występuje efekt zużywania się oprogramowania (chociaż w wyniku
szybkiego rozwoju technik informatycznych można zaobserwować
efekt „starzenia” – nowsze programy mogą pracować na lepszych
algorytmach, efektywniej wykorzystywać sprzęt i lepiej rozwiązywać
nowe problemy), usterki w działaniu oprogramowania są wynikiem
błędów przy projektowaniu lub kodowaniu („idealna krzywa
awaryjności”) a nie „zużycia”



stosunkowo rzadkie (chociaż coraz częstsze) wykorzystywanie
komponentów dostarczanych przez inne firmy

13/18

Zużywanie się produktów jako
przyczyna usterek

czas

błędy

młodości

efekt

zużycia

krzywa awaryjności dla sprzętu

krzywa awaryjności oprogramowania

źródło: „Praktyczne podejście do inżynierii oprogramowania”, R.S. Pressman

czas

krzywa

rzeczywista

krzywa

idealna

zmiany zwiększają

awaryjność

14/18

Etapy cyklu życia oprogramowania



analiza wymagań, specyfikacja (co program ma robić)



wymagania klienta



zapotrzebowanie na rynku danego produktu



funkcjonalności produktu



projektowanie



programowanie



testowanie



zmiany w programie



wprowadzanie na rynek, wdrażanie



ewolucja / wycofywanie

15/18

Etapy cyklu życia
oprogramowania (2)*



wersja niestabilna (testowa) – seria wydań, podczas której dodawane są nowe
możliwości oraz usuwane zauważone błędy:



wersja robocza (pre-alpha) , dostępna zazwyczaj tylko dla twórców programu w
postaci repozytorium kodu źródłowego, operacje: implementacja algorytmu programu,
tworzenie interfejsu i dodawane nowych funkcjonalności



wersja alfa (pre-beta), działający program, ewentualnie w ograniczonym zakresie



wersja beta, program przekazany wybranym użytkownikom ( beta-testerom),
wyszukiwane są błędy związane z różnymi środowiskami i warunkami pracy programu



RC (Release Candidate) – wydanie kandydujące, może być nawet kilka wersji, jeżeli
nie zostanie w nim znalezione żadne istotne odstępstwo od planu, zmieniany jest
numer wersji na wyższy i uznaje się wersję za stabilną



RTM (Release to manufacture lub Ready to market) – produkt gotowy do
wypuszczenia na rynek, nie jest dostępny publicznie do czasu premiery



wersja stabilna (wersja produkcyjna) – wersja nadająca się do użytkowania
zgodnie z założeniami autorów



wersja stabilna z poprawkami bezpieczeństwa lub innych błędów



starzenie programu – ograniczenie wsparcia technicznego, brak poprawek,
wycofanie (porzucenie) programu

* http://pl.wikipedia.org/wiki/Cykl_życia_programu

16/18

Podział oprogramowania ze względu
na dziedzinę zastosowania



oprogramowanie systemowe (intensywna komunikacja ze sprzętem,
działanie równoległe, dzielenie zasobów, zarządzanie procesami)



systemy czasu rzeczywistego (zbieranie i analiza danych, reakcja na
wyniki analizy)



systemy informacyjne dla przedsiębiorstw (głównie przetwarzanie danych,
częsta komunikacja z użytkownikiem)



oprogramowanie naukowe i inżynierskie (obliczenia)



systemy wbudowane (sterowanie pracą urządzeń i podzespołów)



oprogramowanie użytkowe komputerów osobistych



oprogramowanie internetowe (przeglądarki, komunikatory, itp..)



oprogramowanie wykorzystujące metody niezalgorytmizowane (sztuczna
inteligencja)

17/18

Etapy pracy przy wytwarzaniu
oprogramowania



definiowanie → lista wymagań stawianych programowi
(realizowane funkcje, sposób komunikacji,
przetwarzanie danych, weryfikacja poprawności
działania)



tworzenie → projektowanie, kodowanie, testowanie



pielęgnacja → obejmuje zmiany w gotowym programie
wynikające z:



usuwania błędów i usterek



rozszerzania możliwości i dostosowywania do aktualnych
potrzeb

18/18

Model dojrzałości CMM



CMM → Capability Maturity Model



jest to system oceny jakości procesów wytwórczych
oprogramowania



istnieje 5 poziomów dojrzałości



początkowy (poziom 1) → chaotyczny, brak ustalonych procedur,
uzależniony od aktualnych potrzeb



powtarzalny (poziom 2) → istnieje kontrola kosztów i
harmonogramów, możliwy do powtarzania z podobnymi produktami



zdefiniowany (poziom 3) → istnieje ustalony, udokumentowany
schemat procesu wytwórczego, spełnione warunki poziomu 2



zarządzany (poziom 4) → produkt i proces wytwórczy kontrolowane i
analizowane (również jakość), spełnione warunki poziomu 3



optymalizowany (poziom 5) → p.w. ulepszany na bazie poprzednich
doświadczeń i nowych rozwiązań, spełnione warunki poziomu 4