1
Inżynieria oprogramowania
wykład 1
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
5/18
Literatura cz. 3
Metryki i modele w inżynierii jakości
oprogramowania, Stephen H. Kan, Wydawnictwa
Naukowe PWN, Warszawa 2006
Software Measurement and Estimation: A Practical
Approach, Linda M. Laird, M. Carol Brennan, John
Willey & Sons, 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
a
w
a
ry
jn
o
ś
ć
błędy
młodości
efekt
zużycia
krzywa awaryjności dla sprzętu
a
w
a
ry
jn
o
ś
ć
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
19
Dziękuję za uwagę
źródło: „Praktyczne podejście do inżynierii oprogramowania”, R.S. Pressman
Wyszukiwarka
Podobne podstrony:
badania operacyjne, w1 Wstęp
W1 Wstep
w1 wstep, antropologia, notatki
SO W1 Wstęp do systemów operacyjnych
w1 Wstęp
W1 Wstęp bez tła
W1 Wstep
Wstep W1 PK
W1 MIKRO RYZYKO-tablice do wykladow, Prawo, Wstęp do ekonomii i przedsiębiorczości, MIKROEKONOMIA
W1 MIKRO ekonomia metody, Prawo, Wstęp do ekonomii i przedsiębiorczości, MIKROEKONOMIA
W1 tworzenie mapy kategorialnej bud teorii nauk paradygmaty spol, pedagogika, semestr I, wstęp do pe
(w1) SPG Wstep
W1 TS wstep, kraty, piaskowniki
SI wstep
Farmakologia pokazy, Podstawy Farmakologii Ogólnej (W1)
W1 wprow
Zajęcie1 Wstęp
Wstęp do psychopatologii zaburzenia osobowosci materiały
więcej podobnych podstron