background image

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

background image

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

background image

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!)

background image

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

Literatura podstawowa przedmiotu

background image

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

background image

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

Ewolucja języków 

i technik programowania

background image

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;

background image

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

background image

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 

background image

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.

background image

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

background image

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

background image

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

background image

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

background image

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++)

background image

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

Ranking popularności języków 

programowania

na marzec 2008                                                

   

Position

Mar 2008

Position

Mar 2007

Programming Language

Ratings

Mar 2008

Delta 

Mar 2007

1

1

Java

20.651%

+2.61%

2

2

C

15.593%

-0.04%

3

5

(Visual) Basic

10.795%

+2.65%

4

4

PHP

10.138%

+0.68%

5

3

C++

9.776%

-1.33%

6

6

Perl

5.781%

-0.64%

7

7

Python

4.593%

+0.70%

8

9

C#

4.143%

+0.78%

9

12

Delphi

2.697%

+0.94%

10

10

Ruby

2.661%

-0.11%

11

8

JavaScript

2.462%

-1.02%

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

background image

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

Zmiany popularności języków 

programowania

w ostatnich kilku latach                                  

                 

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

background image

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

Geneza i dziedzina 

inżynierii oprogramowania

background image

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

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

background image

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

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

background image

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

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;

background image

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

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% 

background image

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

Kryzys oprogramowania 

background image

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

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ść;

background image

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

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. 

background image

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

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];

background image

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

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;

background image

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

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. 

background image

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

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 

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.

background image

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

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

background image

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

Ź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ść. 

background image

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

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. 

background image

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

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;

background image

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

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. 

background image

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

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

background image

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

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

background image

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

Modele procesu 

wytwarzania oprogramowania

background image

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

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

background image

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

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

background image

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

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

background image

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

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

background image

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

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

background image

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

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.

background image

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

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ń!

background image

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

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

background image

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

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

background image

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

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;

background image

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

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;

background image

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

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ą;

background image

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

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.

background image

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

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

background image

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

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;

background image

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

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

background image

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

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

background image

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

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

background image

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

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.

background image

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

Model iteracyjny (przyrostowy)

ocena

wymagania

planowanie

planowanie
wstępne

analiza i projektowanie

implementowanie

testowanie

dystrybucja

zarządzanie 
środowiskiem

background image

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

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;

background image

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

Ryzyko projektowe

czas

ry

zy

k

o

Model kaskadowy

Model iteracyjny

Profil ryzyka

Redukcja ryzyka

background image

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

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 

background image

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

Czynności procesu 

wytwarzania oprogramowania

background image

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

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ń;

background image

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

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:

background image

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

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;

background image

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

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

background image

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

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;

background image

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

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

background image

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

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;

background image

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

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;

background image

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

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;

background image

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

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ę


Document Outline