Inżynieria oprogramowania, wykład 1, slajd 1

Pojęcia podstawowe inżynierii

oprogramowania

dr inż. Grzegorz Bliźniuk

Inżynieria oprogramowania

wykład 1

Inżynieria oprogramowania, wykład 1, slajd 2

W czasie przygotowywania prezentacji do wykładów,
oprócz materiałów własnych wykładowcy i literatury
przedmiotu, wykorzystano materiały przygotowane przez
następujących Autorów (w kolejności alfabetycznej):

J.Górskiego, K.Kowalczyka,

D.Pierzchałę, K.Subietę, T.Tarnawskiego.

Podziękowania

Inżynieria oprogramowania, wykład 1, slajd 3

Literatura podstawowa przedmiotu

1. Paul Beynon-Davies, „Inżynieria systemów

informacyjnych”, WNT, Warszawa 1999;

2. Kazimierz Subieta, „Wstęp do inżynierii

oprogramowania”, wyd. PJWSTK, Warszawa 2003;

3.

Ian Sommerville, „Inżynieria oprogramowania”, WNT,

2003

4. Grzegorz Bliźniuk, „Badanie jakości programów

współbieżnych”, wyd. BelStudio, Warszawa 2004;

5. Janusz Górski (redakcja), „Inżynieria oprogramowania w

projekcie informatycznym”, w. II, wyd. Mikom, Warszawa
2000;

6. Grady Booch, James Rumbaugh, Ivar Jacobson, „UML.

Przewodnik użytkownika”, WNT, Warszawa, 2002;

7. Plus zasoby Internetu (tylko zdroworozsądkowo!)

Inżynieria oprogramowania, wykład 1, slajd 4

Literatura podstawowa przedmiotu

Inżynieria oprogramowania, wykład 1, slajd 5

Plan wykładu 1

1. Ewolucja języków i technik

programowania

2. Geneza i dziedzina inżynierii

oprogramowania

3. Modele procesu tworzenia

oprogramowania

4. Czynności procesu tworzenia

oprogramowania

Inżynieria oprogramowania, wykład 1, slajd 6

Ewolucja języków

i technik programowania

Inżynieria oprogramowania, wykład 1, slajd 7

Trochę historii maszyn … cyfrowych



1812

- Charles P. Babbage opracował i zbudował mechaniczną

"maszynę różnicową", wykonującą skomplikowane działania

metodą powtarzania kombinacji elementarnych operacji;



1840

- Augusta Ada, córka lorda Byrona, opublikowała pracę

na temat dorobku Babbage'a. W swoich notatkach zawarła

przemyślenia na temat przewagi systemu dwójkowego nad

dziesiętnym w konstrukcji maszyn matematycznych oraz pętlą

programową - została pierwszą w dziejach programistką;



1850

- George Boole opracował zasady algebry Boole'a;



1946

- powstał ENIAC (Electronic Numerical Integrator and

Computer), skonstruowany przez Johna W. Mauchly'ego i J.

Presper Eckerta z amerykańskiego Ballistic Research

Laboratory;

Inżynieria oprogramowania, wykład 1, slajd 8

Trochę historii …c.d.



1964

– w WAT zbudowano prototyp komputera analogowego

ELWAT produkowanego przez zakład Elwro;



1967

– opracowano w Norweskim Centrum Obliczeniowym w

Oslo język Simula, uważany za przodka obiektowości;



1972

- w Bell Laboratories opracowano język C;



1985

- Microsoft wypuścił na rynek Windows 1.0.



1991

- Linus Torvalds z Unwersytetu Helsińskiego opracował

odchudzoną wersję Unixa – Linux;



1996

- Microsoft zaprezentował Windows 95;



1996

- … era sieci globalnych, urządzeń programowalnych,

komputerów przenośnych;



… proponuję rozwinąć samodzielnie

Inżynieria oprogramowania, wykład 1, slajd 9

Język programowania



Język programowania jest środkiem umożliwiającym
zapis algorytmów w postaci zrozumiałej dla człowieka, a
równocześnie przetwarzanej do postaci zrozumiałej dla
komputera (maszyny algorytmicznej)

Kod źródłowy programu
(w języku programowania)

Kod wynikowy programu
(w języku maszynowym)

Przetworzenie

programu

źródłowego

w kod

maszynowy

Inżynieria oprogramowania, wykład 1, slajd 10

Semiotyka języka programowania



Semiotyka zajmuje się badaniem symboli, znaków. W
jej skład wchodzą:

– syntaktyka, zajmująca się określaniem przynależności danego

słowa do zestawu słownika określonego języka programowania

– semantyka, zajmująca się określeniem znaczenia programu,

zapisanego w określonym języku programowania



Zapis algorytmu w języku programowania jest
traktowany jako zapis formalny. Program
komputerowy jest uznawany za jeden z rodzajów
modeli matematycznych. Jest to algorytmiczny model
zadania czy też rzeczywistości, którą modelujemy.

Inżynieria oprogramowania, wykład 1, slajd 11

Syntaktyka języka programowania



Syntaktyka jest częścią ogólnej teorii znaków (semiotyki)
i zajmuje się strukturą i formą wyrażeń, a także
dopuszczalnymi zmianami ich formy, zwanymi
„przekształceniami”.



Wyróżnia się dwa rodzaje reguł składniowych:

– reguły formowania, określające zbiór wyrażeń poprawnie

zbudowanych na określonym alfabecie języka

– reguły przekształcania, określające zbiór możliwych

przekształceń na bazie słów z zadanego zestawu słownika



W dziedzinie algorytmiki, jak również logiki
matematycznej mają zastosowanie wyłącznie reguły
inferencyjne, tzn. takie przekształcenia, które są
prawdziwe w sensie logiki matematycznej

Inżynieria oprogramowania, wykład 1, slajd 12

Syntaktyka języka programowania



Najczęściej przyjmuje się, że mamy do czynienia z
dwoma podzbiorami dziedziny nazywanej syntaktyką:

– syntaktyka formalna, która jest rozumiana jako ogólne

badania formalne, dotyczące języków logiki i matematyki, jak
również języków naturalnych,

– syntaktyka logiczna, która zajmuje się badaniem języków

logiki i matematyki (np. rachunek predykatów, rachunek
zdań)



Językami programowania, badaniem ich
algorytmiczności zajmuje się syntaktyka języków
programowania, która jest jednym z rodzajów
syntaktyk formalnych

Inżynieria oprogramowania, wykład 1, slajd 13

Semantyka języka programowania



Semantyka zajmuje się interpretacją formuł zapisanych
zgodnie z określonymi regułami syntaktycznymi języka



Tarski (1936r.) zaproponował używanie pojęcia semantyka
naukowa dla określenia semantyki zajmującej się formalnym
badaniem prawdziwości formuł w zakresie znaczeniowym
definiowanego języka.



Od lat 70-tych 20 wieku rozwija się tzw, semantyka
wartości logicznych (SWL), inaczej nazywana semantyką
prawdziwo-ściową. Bazuje ona na pojęciu prawdy logicznej,
na wyrażeniach zwanych tautologiami.



Podstawą wnioskowania w SWL o prawdziwości reguły
logicznej jest dowiedzenie poprawności zdania logicznego
wyprowadzanego na podstawie kombinacji innych,
prawdziwych zdań logicznych

Inżynieria oprogramowania, wykład 1, slajd 14

Rodzaje języków oprogramowania

Category

Ratings March

2008

Delta March

2007

Object-Oriented Languages 54.9%

+3.0%

Procedural Languages

42.8%

-1.4%

Functional Languages

1.6%

-0.6%

Logical Languages

0.7%

-1.0%

Źródło: www.tiobe.com

Inżynieria oprogramowania, wykład 1, slajd 15

Przykłady języków programowania



Poruszamy się w kręgu języków programowania z rodziny

Algol’60. Przedstawicielami tej rodziny są między innymi

takie języki programowania, jak:

– Simula,

– Pascal (Niklaus Wirth),

– Modula2 (Niklaus Wirth),

– MODSIM II – symulacyjny język programowania (CACI),

– C (Dennis Ritchie),

– C++ (obiektowe rozszerzenie języka C)

– C# - obiektowy dla środowiska .NET

– Visual Basic (Microsoft)

– Ada (na zamówienie Pentagonu)

– Java (pochodna języka C++)

Inżynieria oprogramowania, wykład 1, slajd 16

Zmiany popularności języków

programowania

w ostatnich kilku latach

Źródło: www.tiobe.com

Inżynieria oprogramowania, wykład 1, slajd 17

Geneza i dziedzina

inżynierii oprogramowania

Inżynieria oprogramowania, wykład 1, slajd 18

Kryzys oprogramowania



Od początku lat 60-tych trwa walka z syndromem LOOP;



1968, 1969 - konferencje sponsorowane przez NATO w Garmisch i Rzymie;

L

O

O

P

ate (późno)

oor quality (kiepska
jakość)

ver budget (przekroczony
budżet)

vertime (nadgodziny)

Loop

Inżynieria oprogramowania, wykład 1, slajd 19

Kryzys oprogramowania

Lata Oprogramowanie

Kryzys

Stan ‘Inż.
Opr.’

1950

–

1960

Tworzone dla siebie

Błędy własne

Brak

1960

–

1970

Duże systemy

Początek

kryzysu,

kosztowne

błędy

Powstaje,

1970

–

1990

Powszechnie

dostępne komputery,

duże i masowo

dystrybuowane

oprogr.

Błędy

powszechnie

występujące

Rozkwit

inżynierii

1990

– …

Uzależnienie

gospodarki i wielu

dziedzin życia od

komputerów

Kryzys trwa w

dalszym ciągu

Rozwój trwa –

nowe teorie i

praktyki

Inżynieria oprogramowania, wykład 1, slajd 20

Kryzys oprogramowania



Zasadnicze problemy wytwórców oprogramowania:

–wzrost mocy sprzętu zwiększa zapotrzebowanie na nowe,

bardziej złożone oprogramowanie;

–długi i kosztowny cykl wytwarzania oprogramowania;
–frustracje projektantów oprogramowania i programistów

wynikające ze zbyt szybkiego postępu w zakresie języków,

narzędzi i metod;

–uzależnienie organizacji od systemów komputerowych i

przyjętych technologii przetwarzania informacji, które nie są

stabilne w długim horyzoncie czasowym;

–brak kontaktów pomiędzy użytkownikiem i firmą;
–problemy współdziałania niezależnie zbudowanego

oprogramowania, szczególnie istotne przy dzisiejszych

tendencjach integracyjnych;

–niska kultura ponownego użycia wytworzonych komponentów

projektów i oprogramowania;

–zbyt późne wykrywanie błędów i słabych punktów;
–brak koordynacji w pracy zespołów projektowych;
–ogromne koszty utrzymania oprogramowania;

Inżynieria oprogramowania, wykład 1, slajd 21

Kryzys oprogramowania



Podstawowym powodem kryzysu
oprogramowania jest złożoność produktów
informatyki i procesów ich wytwarzania



Dane empiryczne:

–27% projektów powstaje w założonym czasie,

budżecie i funkcjonalności

–

33% projektów przekracza czas, budżet i ma
mniejszą funkcjonalność

–

40% projektów jest przerywanych

–

53% projektów przekracza koszty o 51%

–

68% projektów przekracza czas o 51%

Inżynieria oprogramowania, wykład 1, slajd 22

Kryzys oprogramowania

Inżynieria oprogramowania, wykład 1, slajd 23

Kryzys oprogramowania



Źródła złożoności projektu oprogramowania:

–

Dziedzina problemowa - obejmuje ogromną liczbę
wzajemnie uzależnionych aspektów i problemów;

–

Środki i technologie informatyczne - sprzęt,
oprogramowanie, sieć, języki, narzędzia, udogodnienia;

–

Zespół projektantów - podlega ograniczeniom pamięci,
percepcji, wyrażania informacji i komunikacji;

–

Potencjalni użytkownicy - czynniki psychologiczne,
ergonomia, ograniczenia pamięci i percepcji, skłonność
do błędów i nadużyć, tajność, prywatność;

Inżynieria oprogramowania, wykład 1, slajd 24

Walka z kryzysem oprogramowania

Stosowanie technik i narzędzi ułatwiających pracę
nad złożonymi systemami;

Korzystanie z metod wspomagających analizę
nieznanych

problemów

oraz

ułatwiających

wykorzystanie wcześniejszych doświadczeń;

Usystematyzowanie

procesu

wytwarzania

oprogramowania, tak aby ułatwić jego planowanie i
monitorowanie;

Wytworzenie wśród producentów i nabywców
przekonania, że budowa dużego systemu wysokiej
jakości jest zadaniem wymagającym profesjonalnego
podejścia.

Podstawowym powodem kryzysu oprogramowania

jest

złożoność produktów informatyki i procesów ich

wytwarzania.

Inżynieria oprogramowania, wykład 1, slajd 25

Co to jest inżynieria oprogramowania?



Jest to dziedzina inżynierii, która obejmuje wszystkie

aspekty tworzenia oprogramowania od fazy początkowej do

jego pielęgnacji;



Inżynieria oprogramowania jest wiedzą empiryczną,

syntezą doświadczenia wielu ośrodków zajmujących się

budową oprogramowania;



Informatyka obejmuje teorie i podstawowe zasady działania

komputerów a inżynieria oprogramowania obejmuje

praktyczne problemy konstruowania oprogramowania;



Zajmuje się efektywnymi teoriami, metodami i narzędziami

związanymi z procesem wytwarzania oprogramowania;



Zastosowanie systematycznego, zdyscyplinowanego,

ilościowego podejścia do wykonywania,

wykorzystywania

i konserwowania oprogramowania [IEEE 93];

Inżynieria oprogramowania, wykład 1, slajd 26

Co to jest inżynieria oprogramowania?



Kierunki rozwoju Inżynierii Oprogramowania:

–formalny − stosowanie metod formalnych (języków

specyfikacji, transformacji, dowodów poprawności) w celu
dowodzenia, że program spełnia specyfikację:

»indukcja matematyczna we wszystkich możliwych odmianach;
»formalna transformacja specyfikacji w spełniający ją program – np.

metoda VDM Johns’a;

»metody uproszczone - np. logika Hoare'a oparta na niezmiennikach

pętli, logika Pnuelli’ego,

–empiryczny − notacje nie w pełni sformalizowane,

graficzne, w których dużą rolę odgrywa wiedza i
doświadczenie ludzkie;
To tzw. dobre praktyki – słabo zintegrowana lista
zdroworozsądkowych rad na różne sytuacje;

Inżynieria oprogramowania, wykład 1, slajd 27

Przedmiot inżynierii oprogramowania

Inżynieria

oprogramowania

jest

wiedzą

techniczną

dotycząca wszystkich faz cyklu życia oprogramowania.
Traktuje oprogramowanie jako produkt, który ma spełniać
potrzeby techniczne, ekonomiczne lub społeczne.

Dobre oprogramowanie powinno być:



zgodne z wymaganiami użytkownika,



niezawodne,



efektywne,



łatwe w konserwacji,



interoperacyjne (jeżeli nie jest autonomiczne)



ergonomiczne.

Produkcja oprogramowania jest procesem składającym się z
wielu faz. Kodowanie (pisanie programów) jest tylko jedną z
nich, niekoniecznie najważniejszą.

Inżynieria oprogramowania jest wiedzą empiryczną,
syntezą doświadczenia tysięcy ośrodków zajmujących się
budową oprogramowania.

Inżynieria oprogramowania, wykład 1, slajd 28

Zagadnienia inżynierii

oprogramowania

Sposoby

prowadzenia

przedsięwzięć

informatycznych.
Techniki

planowania,

szacowania

kosztów,

harmonogramowania i monitorowania przedsięwzięć
informatycznych.
Metody analizy i projektowania systemów.
Techniki

zwiększania

niezawodności

oprogramowania.
Sposoby

testowania

systemów

i

szacowania

niezawodności.
Sposoby przygotowania dokumentacji technicznej i
użytkowej.
Procedury kontroli jakości.
Metody redukcji kosztów konserwacji (usuwania
błędów, modyfikacji i rozszerzeń)
Techniki pracy zespołowej i czynniki psychologiczne
wpływające na efektywność pracy.

Inżynieria oprogramowania, wykład 1, slajd 29

Struktura rynku informatycznego w

USA

Programiści i Użytkownicy Końcowi

(55 mln w Stanach Zjednoczonych)

Generatory Aplikacji i

Wspomaganie Wytwarzania

Oprogramowania

(0.6 mln)

Wytwarzanie Aplikacji

dla warstwy pośredniej

(0.7 mln)

Integratorzy Systemów

(0.7 mln)

Infrastruktura informatyczna

(0.75 mln)

Struktura rynku informatycznego USA w roku 2005

Inżynieria oprogramowania, wykład 1, slajd 30

Źródła złożoności projektu

oprogramowania

Zespół projektantów

podlegający
ograniczeniom pamięci,
percepcji, wyrażania
informacji i komunikacji.

Zespół projektantów

podlegający
ograniczeniom pamięci,
percepcji, wyrażania
informacji i komunikacji.

Dziedzina
problemowa,

obejmująca ogromną
liczbę wzajemnie
uzależnionych aspektów i
problemów.

Dziedzina
problemowa,

obejmująca ogromną
liczbę wzajemnie
uzależnionych aspektów i
problemów.

Środki i technologie
informatyczne:

sprzęt, oprogramowanie,
sieć,
języki, narzędzia,
udogodnienia.

Środki i technologie
informatyczne:

sprzęt, oprogramowanie,
sieć,
języki, narzędzia,
udogodnienia.

Oprogramowanie

:

decyzje strategiczne,

analiza,

projektowanie,

konstrukcja,

dokumentacja,

wdrożenie,

szkolenie,

eksploatacja,

pielęgnacja,

modyfikacja.

Potencjalni
użytkownicy:

czynniki psychologiczne,
ergonomia, ograniczenia
pamięci i percepcji,
skłonność do błędów i
nadużyć, tajność,
prywatność.

Potencjalni
użytkownicy:

czynniki psychologiczne,
ergonomia, ograniczenia
pamięci i percepcji,
skłonność do błędów i
nadużyć, tajność,
prywatność.

Inżynieria oprogramowania, wykład 1, slajd 31

Jak walczyć ze złożonością ?

Zasada dekompozycji:

rozdzielenie złożonego problemu na podproblemy, które można
rozpatrywać i rozwiązywać niezależnie od siebie i niezależnie
od całości.

Zasada abstrakcji:

eliminacja, ukrycie lub pominięcie mniej istotnych szczegółów
rozważanego przedmiotu lub mniej istotnej informacji;
wyodrębnianie cech wspólnych i niezmiennych dla pewnego
zbioru bytów i wprowadzaniu pojęć lub symboli oznaczających
takie cechy.

Zasada ponownego użycia:

wykorzystanie wcześniej wytworzonych schematów, metod,
wzorców,

komponentów

projektu,

komponentów

oprogramowania, itd.

Zasada

sprzyjania

naturalnym

ludzkim

własnościom:

dopasowanie modeli pojęciowych i modeli realizacyjnych
systemów

do

wrodzonych

ludzkich

własności

psychologicznych, instynktów oraz mentalnych mechanizmów
percepcji i rozumienia świata.

Inżynieria oprogramowania, wykład 1, slajd 32

Proces wytwarzania oprogramowania



Jest to zbiór czynności i związanych z nimi wyników,
które prowadzą do powstania produktu programowego;



Zasadnicze czynności wspólne dla wszystkich procesów:

–Specyfikowanie oprogramowania

»Funkcjonalność oprogramowania i ograniczenia jego działania muszą

być zdefiniowane;

–Projektowanie i implementowanie oprogramowania

»Oprogramowanie, które spełnia specyfikację, musi być stworzone;

–Zatwierdzenie oprogramowania

»Wytworzone oprogramowanie musi spełniać oczekiwania klienta;

–Ewolucja oprogramowania

»Oprogramowanie musi ewoluować, aby spełniać zmieniające się

potrzeby użytkowników;

Inżynieria oprogramowania, wykład 1, slajd 33

Modelowanie pojęciowe

Projektant i programista muszą dokładnie wyobrazić
sobie problem oraz metodę jego rozwiązania.
Zasadnicze procesy tworzenia oprogramowania
zachodzą w ludzkim umyśle i nie są związane z
jakimkolwiek językiem programowania.

Pojęcia modelowania pojęciowego (conceptual
modeling) oraz modelu pojęciowego (conceptual
model) odnoszą się procesów myślowych i wyobrażeń
towarzyszących pracy nad oprogramowaniem.

Modelowanie pojęciowe jest wspomagane przez
środki wzmacniające ludzką pamięć i wyobraźnię.
Służą

one

do

przedstawienia

rzeczywistości

opisywanej przez dane, procesów zachodzących w
rzeczywistości, struktur danych oraz programów
składających się na konstrukcję systemu.

Inżynieria oprogramowania, wykład 1, slajd 34

Perspektywy w modelowaniu

pojęciowym

Percepcja

rzeczywistego

świata

Analityczny

model

rzeczywistości

Model

struktur danych

i procesów SI

... ... ...

... ... ...

... ... ...

... ... ...

... ... ...

... ... ...

Trwałą tendencją w rozwoju metod i narzędzi projektowania
oraz konstrukcji SI jest dążenie do minimalizacji luki
pomiędzy myśleniem o rzeczywistym problemie a myśleniem
o danych i procesach zachodzących na danych.

odwzorowanie

odwzorowanie

Inżynieria oprogramowania, wykład 1, slajd 35

Co to jest metodyka (metodologia)?

Metodyka jest to zestaw pojęć, notacji, modeli,
języków, technik i sposobów postępowania
służący do analizy dziedziny stanowiącej przedmiot
projektowanego systemu oraz do projektowania
pojęciowego, logicznego i/lub fizycznego.

Metodyka jest powiązana z notacją służącą do
dokumentowania wyników faz projektu (pośrednich,
końcowych), jako środek wspomagający ludzką
pamięć i wyobraźnię i jako środek komunikacji w
zespołach oraz pomiędzy projektantami i klientem.

Metodyka
ustala:

Metodyka
ustala:

• fazy projektu, role uczestników projektu,

• modele tworzone w każdej z faz,

• scenariusze postępowania w każdej z faz,

• reguły przechodzenia od fazy do
następnej fazy,

• notacje, których należy używać,

• dokumentację powstającą w każdej z faz.

methodology

Inżynieria oprogramowania, wykład 1, slajd 36

Modele procesu

wytwarzania oprogramowania

Inżynieria oprogramowania, wykład 1, slajd 37

Cykl życia oprogramowania

Faza strategiczna: określenie strategicznych celów, planowanie i
definicja projektu
Określenie wymagań: co system ma robić?
Analiza: dziedziny przedsiębiorczości, wymagań systemowych
Projektowanie: projektowanie pojęciowe, projektowanie
logiczne
Implementacja/konstrukcja: rozwijanie, testowanie,
dokumentacja
Testowanie: sprawdzanie, czy system działa tak, jak założono w
specyfikacji
Dokumentacja: wszystkie produkty muszą być dokumentowane
Instalacja: uruchomienie systemu w środowisku pracy
Przygotowanie użytkowników, akceptacja, szkolenie
Działanie, włączając wspomaganie tworzenia aplikacji
Utrzymanie, konserwacja, pielęgnacja
Wycofanie wersji z ekploatacji: tzw. utylizacja oprogramowania

software lifecycle

Inżynieria oprogramowania, wykład 1, slajd 38

Modele cyklu życia oprogramowania

Model kaskadowy

(wodospadowy)

Model spiralny, przyrostowy, ewolucyjny

Prototypowanie

Programowanie odkrywcze

Model „V”

Montaż z gotowych komponentów

Tego rodzaju modeli (oraz ich mutacji) jest bardzo dużo.

Określenie wymagań

ProjektowanieImplementacjaTestowanieKonserwacja

Faza strategiczna Analiza

Instalacja

Dokumentacja

Inżynieria oprogramowania, wykład 1, slajd 39

Model kaskadowy

(wodospadowy)

Określenie

wymagań

Określenie

wymagań

Projektowanie

Projektowanie

Implementacja

Implementacja

Testowanie

Testowanie

Konserwacja

Konserwacja

Cele i szczegółowe wymagania wobec systemu.

Szczegółowy projekt

systemu uwzględniający

wcześniejsze

wymagania.

Modyfikacje producenta -
usunięcie błędów, zmiany i
rozszerzenia.

Analiza

Analiza

waterfall model

Inżynieria oprogramowania, wykład 1, slajd 40

Ocena modelu kaskadowego

 Narzucenie twórcom oprogramowania ścisłej kolejności wykonywania prac

 Wysoki koszt błędów popełnionych we wczesnych fazach

 Długa przerwa w kontaktach z klientem

Istnieją zróżnicowane poglądy co do przydatności
praktycznej modelu kaskadowego. Podkreślane są następujące
wady:

Z drugiej strony, jest on do pewnego stopnia niezbędny dla
planowania, harmonogramowania, monitorowania i rozliczeń
finansowych.

Określenie

wymagań

Określenie

wymagań

Analiza

Projektowanie

Analiza

Projektowanie

Implementacja

Implementacja

Testowanie

Testowanie

Konserwacja

Konserwacja

Zmodyfikowany model

kaskadowy z iteracjami

Inżynieria oprogramowania, wykład 1, slajd 41

Piramida propagacji błędów

Pielęgnacja

Implementacja

Projekt

Analiza

Wymag

ania

Rozmiar kosztu usunięcia błędów

E

ta

p

c

yk

lu

ż

yc

ia

op

ro

g

ra

m

ow

an

ia

Inżynieria oprogramowania, wykład 1, slajd 42

Realizacja kierowana dokumentami

 Przyjęty przez armią amerykańską dla realizacji projektów w
języku Ada.

 Jest to odmiana modelu kaskadowego.

 Każda faza kończy się sporządzeniem szeregu dokumentów, w
których opisuje się
wyniki danej fazy.

 Łatwe planowanie, harmonogramowanie oraz monitorowanie
przedsięwzięcia.
Dodatkowa zaleta: (teoretyczna) możliwość realizacji dalszych faz
przez inną firmę.

Wady

Duży nakład pracy na opracowanie dokumentów zgodnych
ze standardem (DOD STD 2167) - ponad 50% całkowitych
nakładów.

Przerwy w realizacji niezbędne dla weryfikacji
dokumentów przez klienta.

Inżynieria oprogramowania, wykład 1, slajd 43

Ponowne użycie - reuse



Tworzenie z użyciem wielokrotnym
(reuse):

•W przedsięwzięciach programistycznych

występuje wielokrotne użycie oprogramowania;

•Zakłada się zatem konieczność posiadania

zbioru komponentów programowych do
wielokrotnego użycia oraz elementów
integrujących;

Specyfikacja

wymagań

Zatwierdzen

ie

systemu

Tworzenie i

integracja

Projekt

systemu z

użyciem

wielokrotnym

Analiza

komponentów

Modyfikacja

wymagań

Wada: niezamierzone przez

klienta lecz wymuszone przez

wytwórcę dostosowanie

wymagań!

Inżynieria oprogramowania, wykład 1, slajd 44

Ponowne użycie - reuse

Kładzie nacisk na możliwość redukcji nakładów poprzez
wykorzystanie podobieństwa tworzonego oprogramowania do
wcześniej tworzonych systemów oraz wykorzystanie gotowych
komponentów dostępnych na rynku.

Jest również określany jako wykorzystanie
wielokrotne

 zakup elementów ponownego użycia od dostawców

 przygotowanie elementów poprzednich przedsięwzięć do
ponownego użycia

 wysoka niezawodność

 zmniejszenie ryzyka

 efektywne wykorzystanie specjalistów

 narzucenie standardów

 dodatkowy koszt przygotowania elementów ponownego
użycia

 ryzyko uzależnienia się od dostawcy elementów

 niedostatki narzędzi wspomagających ten rodzaj pracy.

Metody

Zalety

Wady

Inżynieria oprogramowania, wykład 1, slajd 45

Model „V” cyklu życia oprogramowania

Specyfikacja

Projekt
systemu

Projekt podsystemu

Projekt modułu

Integracja i walidacja systemu

Formalne testowanie modułu

Integracja i walidacja
podsystemu

Testy akceptacyjne
systemu

Kodowanie, wstępne testowanie
modułu

Model V jest często stosowany w metodykach „Rational” bazujących na języku UML

Inżynieria oprogramowania, wykład 1, slajd 46

Model ewolucyjny



Wytwarzanie ewolucyjne - polega na:

–opracowaniu wstępnej implementacji,
–pokazaniu jej użytkownikowi z prośbą o

komentarze

–oraz udoskonalaniu jej w wielu wersjach aż do

powstania odpowiedniego systemu;

Inżynieria oprogramowania, wykład 1, slajd 47

Rodzaje modelu ewolucyjnego

•

Rodzaje wytwarzania ewolucyjnego:

•Tworzenie badawcze:

»Celem procesu jest praca z klientem, polegająca na badaniu

wymagań i dostarczeniu ostatecznego systemu;

»Tworzenie rozpoczyna się od tych części systemu, które są

dobrze rozpoznane;

»System ewoluuje przez dodawanie nowych cech, które proponuje

klient;

•Prototypowanie z porzuceniem:

»Celem procesu tworzenia ewolucyjnego jest zrozumienie

wymagań klienta i wypracowanie lepszej definicji wymagań
stawianych systemowi;

»Budowanie prototypu ma głównie na celu eksperymentowanie z

tymi wymaganiami użytkownika, które są niejasne;

Inżynieria oprogramowania, wykład 1, slajd 48

Wady modelu ewolucyjnego

•

Wady modelu ewolucyjnego:

•Proces nie jest widoczny;
•System ma złą strukturę;
•Konieczne mogą być specjalne narzędzia i techniki;

•

Stosowanie:

–W wypadku systemów małych (mniej niż 100 000

wierszy kodu) lub średnich (do 500 000 wierszy kodu)
z krótkim czasem życia podejście ewolucyjne jest
dobre;

–W wypadku dużych systemów o długim czasie życia

wady tworzenia ewolucyjnego ujawniają się jednak z
całą ostrością;

Inżynieria oprogramowania, wykład 1, slajd 49

Modele formalne



Tworzenie formalne systemów:

–Tworzenie formalne systemów jest podejściem,

które ma cechy modelu kaskadowego;

–Proces tworzenia jest oparty na

matematycznych przekształceniach specyfikacji
systemu w program wykonywalny;

Podejście stosukowo słabo przydatne w pracach praktycznych,
co jest szkodliwe dla kunsztu matematycznego, ale wymusza to rynek.

Inżynieria oprogramowania, wykład 1, slajd 50

Programowanie odkrywcze

Model odkrywczy ma znaczenie wyłącznie w zastosowaniach amatorskich

Określ ogólne

wymagania

Przetestuj system

Zbuduj system

Dostarcz system

zadawala

tak

nie

Inżynieria oprogramowania, wykład 1, slajd 51

Rozszerzenia modeli cyklu życia

oprogramowania



Rozszerzenia modeli ogólnych:

–Wszystkie omówione modele nie są pozbawione

wad, zatem stosowane są podejścia hybrydowe
lub indywidualnie dostosowane do wymagań i
celów;

–Hybrydowe modele:

»model spiralny,
»model przyrostowy,
»prototypowanie;

Inżynieria oprogramowania, wykład 1, slajd 52

Model spiralny (Boehm, 1988)

Istnieje wiele wariantów tego modelu.

Planowanie: Ustalenie
celów produkcji
kolejnej wersji
systemu

Analiza ryzyka
(ew. budowa prototypu)

Konstrukcja
(model kaskadowy)

Atestowanie (przez klienta).
Jeżeli ocena nie jest w pełni
pozytywna, rozpoczynany jest
kolejny cykl.

spiral model

Inżynieria oprogramowania, wykład 1, slajd 53

Model spiralny – inny wariant



Tworzenie spiralne

Określ cele,
inne strategie
i ograniczenia

Oceń inne strategie,
rozpoznaj i zmniejsz
zagrożenia
(ocena ryzyka technicznego)

RECENZJA

Plan wymagań
Plan cyklu życia

Plan tworzenia

Plan testowania
i integracji

Zaplanuj następną
fazę

Analiza zagrożeń

Analiza zagrożeń

Analiza zagrożeń

Analiza
zagrożeń

Prototyp 1

Prototyp 2

Prototyp 3

Działający
prototyp

Sposób
postępowania

Symulacje, modele, miary odniesienia

Zatwierdzenie
wymagań

Wymagania
S/W Projekto-

wanie
produktu

Weryfikacja i
zatwierdzenie

Działanie

Testy
akceptacji

Testy
integracji

Testy
jednostek

Kodowanie

Szczegółowe
projekto-
wanie

Utwórz, zweryfikuj
produkt następnego
poziomu

Inżynieria oprogramowania, wykład 1, slajd 54

Prototypowanie

Sposób na uniknięcie zbyt wysokich kosztów błędów
popełnionych w fazie określania wymagań. Zalecany w
przypadku, gdy określenie początkowych wymagań jest
stosunkowo łatwe.

Fazy

 ogólne określenie wymagań

 budowa prototypu

 weryfikacja prototypu przez klienta

 pełne określenie wymagań

 realizacja pełnego systemu zgodnie z modelem kaskadowym

Cele

 wykrycie nieporozumień pomiędzy klientem a twórcami systemu

 wykrycie brakujących funkcji

 wykrycie trudnych usług

 wykrycie braków w specyfikacji wymagań

Zalety możliwość demonstracji pracującej wersji systemu

 możliwość szkoleń zanim zbudowany zostanie pełny system

prototyping

Inżynieria oprogramowania, wykład 1, slajd 55

Metody prototypowania

Niepełna realizacja: objęcie tylko części funkcji

Języki wysokiego poziomu: Smalltalk, Lisp, Prolog,
4GL, ...

Wykorzystanie gotowych komponentów

Generatory interfejsu użytkownika: wykonywany jest
wyłącznie interfejs, wnętrze systemu jest “podróbką”.

Szybkie programowanie (quick-and-dirty): normalne
programowanie, ale bez zwracania uwagi na niektóre jego
elementy, np. zaniechanie testowania

Dość często następuje ewolucyjne przejście od prototypu do
końcowego systemu. Należy starać się nie dopuścić do
sytuacji, aby klient miał wrażenie, że prototyp jest prawie
ukończonym produktem. Po fazie prototypowania najlepiej
prototyp skierować do archiwum.

Inżynieria oprogramowania, wykład 1, slajd 56

Model iteracyjny (przyrostowy)

ocena

wymagania

planowanie

planowanie
wstępne

analiza i projektowanie

implementowanie

testowanie

dystrybucja

zarządzanie
środowiskiem

Inżynieria oprogramowania, wykład 1, slajd 57

Model iteracyjny



wczesne iteracje zajmują się największym ryzykiem;



w każdej powstaje wersja uruchomieniowa;



każda iteracja zawiera integrację i testowanie;



projekt realizuje się przyrostowo - każdy; „przyrost” jest
podzbiorem funkcjonalnym systemu;



model iteracyjny:

–ułatwia detekcję ryzyka zanim się dokona dużych inwestycji;
–zapobiega utknięciu całego systemu w martwym punkcie;
–umożliwia wczesną reakcję użytkownika;
–zapewnia ciągłe testowanie i integrację;
–zwraca szczególną uwagę na krótko-terminowość wykonania

projektu;

–umożliwia dystrybucję częściowych implementacji;

Inżynieria oprogramowania, wykład 1, slajd 58

Ryzyko projektowe

czas

ry

zy

k

o

Model kaskadowy

Model iteracyjny

Profil ryzyka

Redukcja ryzyka

Inżynieria oprogramowania, wykład 1, slajd 59

Cykl życia oprogramowania w normie

IEC 300-3-6

Analiza
wymagań

Specyfikacja
systemu

Projekt
wstępny

Projekt

szczegółowy

Kodowanie,

Testy
komponentów

Testy
integracyjne

Testy
systemu

Testy
akceptacyjne

Wdrożenie
oprogramow.

Utrzymywanie,

ulepszanie

oprogramowania

Dezaktua-

lizacja

oprogra-
mowania

Cykl życia

oprogramowania

Cykl życia oprogramowania (według IEC 300-3-6)

upływ czasu

Koncepcja,

Definicja

Projekt,

Technologia

Produkcja,

Instalacja

Działanie,

Konserwacja

Usunięcie

Cykl życia wyrobu

Inżynieria oprogramowania, wykład 1, slajd 60

Czynności procesu

wytwarzania oprogramowania

Inżynieria oprogramowania, wykład 1, slajd 61

Specyfikowanie oprogramowania



Specyfikowanie oprogramowania:

–Ma na celu określenie, jakich usług wymaga się

od systemu i jakim ograniczeniom podlega
tworzenie i działanie oprogramowania;

–Obecnie jest nazywane inżynierią wymagań;
–W procesie inżynierii wymagań możemy

wyróżnić cztery główne fazy:

»studium wykonalności,
»określenie i analiza wymagań,
»specyfikowanie wymagań,
»zatwierdzanie wymagań;

Inżynieria oprogramowania, wykład 1, slajd 62

Określenie i analiza

wymagań

Specyfikacja

wymagań

Modele

systemu

Wymagania

użytko-

wnika systemu

Zatwierdza

nie

wymagań

Raport o

wykonywalności

Studium

wykonalnoś

ci

Dokumentacja

wymagań

Specyfikowanie oprogramowania



Specyfikowanie oprogramowania:

Inżynieria oprogramowania, wykład 1, slajd 63

Projekt i implementacja



Projektowanie i implementowanie wymagań:

–Projekt oprogramowania to opis struktury

oprogramowania, które ma być zaimplementowane,
opis danych, które są częścią systemu, opis
interfejsów między komponentami systemu i
użytych algorytmów;

–Proces projektowania może obejmować

opracowanie wielu modeli systemu na różnych
poziomach abstrakcji;

–Faza implementowania w tworzeniu

oprogramowania to proces przekształcania
specyfikacji systemu w działający system;

Inżynieria oprogramowania, wykład 1, slajd 64

Projekt i implementacja



Projektowanie i implementowanie
wymagań:

–Charakterystyczne składowe procesu

projektowania:

Projektowanie
architektury

Specyfikowanie
abstrakcyjne

Projektowanie
interfejsów

Projektowanie
komponentów

Architektura
systemu

Specyfikacja
programowania

Specyfikacja
interfejsów

Specyfikacja
komponentów

Projektowanie
struktury
danych

Specyfikacja
struktury
danych

Specyfikacja
algorytmów

Projektowanie
algorytmów

Specyfikacja
wymagań

Produkty projektowania

Składowe projektowe

Inżynieria oprogramowania, wykład 1, slajd 65

Projekt i implementacja



Projektowanie i implementowanie wymagań:

–Metody projektowania:

»Stosowanie metod strukturalnych i obiektowych, które są zbiorami

notacji i porad dla projektantów oprogramowania;

»Ich użycie polega głównie na opracowaniu graficznych modeli

systemu oraz opisów tekstowych wg ustalonych szablonów;

»Metody strukturalne obejmują np.:



modele przepływu danych,



modele encja-związek;

»Niezwykle popularne ostatnio są metody obiektowe, w tym np.:



modele klas, dynamiki,



modele architektury;

–Niestety wciąż jeszcze projektowanie jest działaniem ad

hoc, gdzie wymagania zapisuje się w języku naturalnym;

Inżynieria oprogramowania, wykład 1, slajd 66

Weryfikacja i walidacja



Zatwierdzanie oprogramowania:

–

Weryfikacja i zatwierdzenie mają wykazać, że

system jest zgodny ze swoją specyfikacją i
spełnia oczekiwania klienta;

–

Obejmuje proces sprawdzania, m.in. kontrole i

recenzje w każdym kroku procesu tworzenia od
definicji wymagań użytkownika do pisania
programów;

–

Większość kosztów zatwierdzania powstaje po

zaimplementowaniu, gdy testuje się działający
system

Inżynieria oprogramowania, wykład 1, slajd 67

Rodzaje testowania oprogramowania



Zatwierdzanie oprogramowania:

–Testowanie komponentów (jednostek)

»Testuje się poszczególne komponenty, aby zapewnić, że działają poprawnie;

–Testowanie modułów

»Moduł jest kolekcją niezależnych komponentów takich jak klasy obiektów,

abstrakcyjne typy danych, albo bardziej luźną kolekcją procedur i funkcji;

–Testowanie podsystemów

»Ta faza obejmuje testowanie kolekcji modułów, które zintegrowano w

podsystemie;

–Testowanie systemu

»Ten proces testowania ma wykryć błędy wynikające z nieprzewidzianych

interakcji między zintegrowanymi podsystemami i problemów z interfejsami
podsystemów;

–Testowanie odbiorcze

»Jest to końcowa faza procesu testowania przed przyjęciem systemu do

użytkowania;

Inżynieria oprogramowania, wykład 1, slajd 68

Walidacja oprogramowania



Zatwierdzanie oprogramowania:

–Testowanie alfa

»Jest testowaniem odbiorczym stosowanym, kiedy system jest

tworzony dla jednego klienta;

»Proces testowania trwa do momentu osiągnięcia zgody pomiędzy

wytwórcą systemu i klientem co do tego, że dostarczony system
jest możliwą do przyjęcia implementacją wymagań;

»Testy jeszcze w środowisku wytwórcy;

–Testowanie beta

»Stosuje się, kiedy system sprzedawany jako produkt programowy;
»Testowanie polega na dostarczeniu systemu pewnej liczbie

potencjalnych klientów, którzy zgodzili się z niego korzystać;

»Klienci informują wytwórców o pojawiających się problemach;
»Testy w środowisku klienta;

Inżynieria oprogramowania, wykład 1, slajd 69

Rozwój oprogramowania



Ewolucja oprogramowania:

–Polega na modyfikowaniu istniejącego oprogramowania,

tak aby spełniało nowe wymagania;

–Takie podejście staje się standardem tworzenia

oprogramowania w wypadku małych i średnich
przedsięwzięć;

–Elastyczność systemów oprogramowania jest jedną z

głównych przyczyn, iż coraz więcej oprogramowania
włącza się do wielkich, złożonych systemów;

–Zmiany mogą być wprowadzone w każdej chwili tworzenia

lub nawet po jego zakończeniu;

–Koszt tych zmian może być bardzo wysoki, ale wciąż

będzie niższy niż odpowiednie zmiany w sprzęcie systemu;

Inżynieria oprogramowania, wykład 1, slajd 70

Podsumowanie

1. Inżynieria oprogramowania jest wiedzą empiryczną

2. Można ją uznać za zbiór dobrych, inżynierskich i praktycznie

zweryfikowanych reguł działania mających doprowadzać do
wytwarzania dobrych systemów informatycznych

3. Systemy dobre, to takie, które spełniają oczekiwania ich

użytkowników i mieszczą się w ograniczeniach czasu i budżetu
przewidzianego ich realizację

4. Wymyślono już wiele dobrych metod, modeli i narzędzi inżynierii

oprogramowania, co nie musi oznaczać, że kryzys oprogramowania
mamy już za sobą

5. Obecnie znakomita większość projektów informatycznych nie jest

realizowana w zakładanym budżecie i czasie. Jest to regularność,
która powtarza się w projektach realizowanych w dowolnym
miejscu na Ziemi.

Jak sądzisz, z czego może to wynikać?

dziękuję za uwagę