Inżynieria oprogramowania
wykład 1
Pojęcia podstawowe inżynierii oprogramowania
dr inż. Grzegorz Bliz
niuk
Inżynieria oprogramowania, wykład 1, slajd 1
Podziękowania
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.
Inżynieria oprogramowania, wykład 1, slajd 2
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;
1. Ian Sommerville,  Inżynieria oprogramowania , WNT, 2003
1. Grzegorz Bliz
niuk,  Badanie jakości programów współbieżnych ,
wyd. BelStudio, Warszawa 2004;
2. Janusz Górski (redakcja),  Inżynieria oprogramowania w projekcie
informatycznym , w. II, wyd. Mikom, Warszawa 2000;
3. Grady Booch, James Rumbaugh, Ivar Jacobson,  UML. Przewodnik
użytkownika , WNT, Warszawa, 2002;
4. Plus zasoby Internetu (tylko zdroworozsÄ…dkowo!)
Inżynieria oprogramowania, wykład 1, slajd 3
Literatura podstawowa przedmiotu
Inżynieria oprogramowania, wykład 1, slajd 4
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 5
Ewolucja języków
i technik programowania
Inżynieria oprogramowania, wykład 1, slajd 6
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
Inżynieria oprogramowania, wykład 1, slajd 7
Johna W. Mauchly'ego i J. Presper Eckerta z
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;
Inżynieria oprogramowania, wykład 1, slajd 8
& proponuję rozwinąć samodzielnie
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)
Przetworzenie
programu
z
ródłowego
w kod
maszynowy
Kod z
ródłowy programu
Kod wynikowy programu
(w języku programowania)
(w języku maszynowym)
Inżynieria oprogramowania, wykład 1, slajd 9
 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ą
Inżynieria oprogramowania, wykład 1, slajd 10
modelujemy.
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
Inżynieria oprogramowania, wykład 1, slajd 11
matematycznej
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 12
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
Inżynieria oprogramowania, wykład 1, slajd 13
zdania logicznego wyprowadzanego na podstawie
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%
y
ródło: www.tiobe.com
Inżynieria oprogramowania, wykład 1, slajd 14
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 15
Ranking popularności języków programowania
na marzec 2008
Position Programming Language Ratings Delta
Position Mar 2007 Mar 2008 Mar 2007
Mar 2008
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%
y
ródło: www.tiobe.com
Inżynieria oprogramowania, wykład 1, slajd 16
Zmiany popularności języków programowania
w ostatnich kilku latach
y
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;
Loop
ate (póz
no)
L
ver budget (przekroczony budżet)
O
vertime (nadgodziny)
O
oor quality (kiepska jakość)
P
1968, 1969 - konferencje sponsorowane przez NATO w
Inżynieria oprogramowania, wykład 1, slajd 19
Garmisch i Rzymie;
Kryzys oprogramowania
Lata Oprogramowanie Kryzys Stan  Inż.
Opr.
1950 Tworzone dla siebie Błędy własne Brak

1960
1960 Duże systemy Początek Powstaje,
 kryzysu,
1970 kosztowne
błędy
1970 Powszechnie Błędy Rozkwit
 dostępne komputery, powszechnie inżynierii
1990 duże i masowo występujące
dystrybuowane
oprogr.
1990 Uzależnienie Kryzys trwa w Rozwój trwa 
Inżynieria oprogramowania, wykład 1, slajd 20
 & gospodarki i wielu dalszym ciÄ…gu nowe teorie i
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óz
ne wykrywanie błędów i słabych punktów;
 brak koordynacji w pracy zespołów projektowych;
Inżynieria oprogramowania, wykład 1, slajd 21
 ogromne koszty utrzymania oprogramowania;
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
y
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
Inżynieria oprogramowania, wykład 1, slajd 24
pamięci i percepcji, skłonność do błędów i
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,
Inżynieria oprogramowania, wykład 1, slajd 26
zdyscyplinowanego, ilościowego podejścia
do wykonywania, wykorzystywania
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;
Inżynieria oprogramowania, wykład 1, slajd 27
To tzw. dobre praktyki  słabo zintegrowana lista
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.
Inżynieria oprogramowania, wykład 1, slajd 29
Metody redukcji kosztów konserwacji (usuwania
Struktura rynku informatycznego w USA
Programiści i Użytkownicy Końcowi
(55 mln w Stanach Zjednoczonych)
Generatory Aplikacji i Wytwarzanie Aplikacji Integratorzy Systemów
Wspomaganie Wytwarzania dla warstwy pośredniej (0.7 mln)
Oprogramowania (0.7 mln)
(0.6 mln)
Infrastruktura informatyczna
(0.75 mln)
Struktura rynku informatycznego USA w roku 2005
Inżynieria oprogramowania, wykład 1, slajd 30
y
ródła złożoności projektu oprogramowania
Zespół projektantów
Dziedzina problemowa,
podlegajÄ…cy ograniczeniom
obejmujÄ…ca ogromnÄ… liczbÄ™
pamięci, percepcji, wyrażania
wzajemnie uzależnionych
Oprogramowanie:
informacji i komunikacji.
aspektów i problemów.
decyzje strategiczne,
analiza,
projektowanie,
konstrukcja,
dokumentacja,
wdrożenie,
szkolenie,
eksploatacja,
pielęgnacja,
modyfikacja.
Środki i technologie Potencjalni użytkownicy:
czynniki psychologiczne,
informatyczne:
ergonomia, ograniczenia pamięci
sprzęt, oprogramowanie, sieć,
i percepcji, skłonność do błędów
języki, narzędzia, udogodnienia.
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
Inżynieria oprogramowania, wykład 1, slajd 33

Oprogramowanie musi ewoluować, aby spełniać zmieniające
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 wyobraz
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
odwzorowanie odwzorowanie
... ...
...
...
... ...
... ... ...
...
... ...
... ...
...
... ... ...
Percepcja Analityczny Model
rzeczywistego model struktur danych
świata rzeczywistości 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.
Inżynieria oprogramowania, wykład 1, slajd 35
Co to jest metodyka (metodologia)?
methodology
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 wyobraz
nię i jako środek
komunikacji w zespołach oraz pomiędzy projektantami i klientem.
" fazy projektu, role uczestników projektu,
" modele tworzone w każdej z faz,
Metodyka
" scenariusze postępowania w każdej z faz,
ustala:
" reguły przechodzenia od fazy do następnej fazy,
" notacje, których należy używać,
" dokumentację powstającą w każdej z faz.
Inżynieria oprogramowania, wykład 1, slajd 36
Modele procesu
wytwarzania oprogramowania
Inżynieria oprogramowania, wykład 1, slajd 37
Cykl życia oprogramowania
software lifecycle
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
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ń
ProjektowanieImplementacjaTestowanie Konserwacja
Faza strategiczna Analiza Instalacja
Dokumentacja
Inżynieria oprogramowania, wykład 1, slajd 39
Model kaskadowy (wodospadowy)
waterfall mode
Określenie
Cele i szczegółowe wymagania wobec systemu.
wymagań
Analiza
Projektowanie
Szczegółowy projekt
systemu uwzględniający
wcześniejsze
Implementacja
wymagania.
Testowanie
Konserwacja
Modyfikacje producenta -
usunięcie błędów, zmiany i
rozszerzenia.
Inżynieria oprogramowania, wykład 1, slajd 40
Ocena modelu kaskadowego
Istnieją zróżnicowane poglądy co do przydatności
praktycznej modelu kaskadowego. Podkreślane są
następujące wady:
Narzucenie twórcom oprogramowania ścisłej kolejności wykonywania
Wysoki koszt błędów popełnionych we wczesnych fazach
DÅ‚uga przerwa w kontaktach z klientem
Z drugiej strony, jest on do pewnego stopnia niezbędny dla
planowania, harmonogramowania, monitorowania i rozliczeń
finansowych.
Określenie
Zmodyfikowany model
wymagań
kaskadowy z iteracjami
Analiza
Projektowanie
Implementacja
Testowanie
Konserwacja
Inżynieria oprogramowania, wykład 1, slajd 41
Piramida propagacji błędów
Wymaga
nia
Analiza
Projekt
Implementacja
Pielęgnacja
Rozmiar kosztu usunięcia błędów
Inżynieria oprogramowania, wykład 1, slajd 42
a
a
i
i
c
n
y
a
ż
w
u
o
kl
m
y
a
c
r
g
p
o
a
r
t
p
E
o
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.
A
atwe planowanie, harmonogramowanie oraz monitorowanie
Wady
przedsięwzięcia.
Dodatkowa zaleta: (teoretyczna) możliwość realizacji dalszych faz
przez innÄ… firmÄ™.
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
Projekt systemu z
Specyfikacja Modyfikacja
Analiza
użyciem
wymagań wymagań
integrujÄ…cych;
komponentów
wielokrotnym
Wada: niezamierzone przez
klienta lecz wymuszone przez
Tworzenie i
Zatwierdzenie
integracja
wytwórcę dostosowanie
systemu
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
Metody
zakup elementów ponownego użycia od dostawców
przygotowanie elementów poprzednich przedsięwzięć do
ponownego użycia
Zalety
wysoka niezawodność
zmniejszenie ryzyka
efektywne wykorzystanie specjalistów
narzucenie standardów
Wady
dodatkowy koszt przygotowania elementów ponownego
użycia
ryzyko uzależnienia się od dostawcy elementów
Inżynieria oprogramowania, wykład 1, slajd 45
niedostatki narzędzi wspomagających ten rodzaj pracy.
Model  V cyklu życia oprogramowania
Specyfikacja Testy akceptacyjne
systemu
Projekt Integracja i walidacja systemu
systemu
Projekt podsystemu Integracja i walidacja
podsystemu
Projekt modułu Formalne testowanie modułu
Kodowanie, wstępne testowanie
modułu
Model V jest często stosowany w metodykach  Rational bazujących na języku
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
Określ ogólne Zbuduj system
wymagania
Przetestuj system
tak nie
Dostarcz system zadawala
Model odkrywczy ma znaczenie wyłącznie w zastosowaniach amatorskic
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)
spiral model
Analiza ryzyka
Planowanie: Ustalenie
(ew. budowa prototypu)
celów produkcji
kolejnej wersji
systemu
Konstrukcja
(model kaskadowy)
Atestowanie (przez klienta).
Jeżeli ocena nie jest w pełni
pozytywna, rozpoczynany jest
kolejny cykl.
Istnieje wiele wariantów tego mode
Inżynieria oprogramowania, wykład 1, slajd 53
Model spiralny  inny wariant
Oceń inne strategie,
Tworzenie spiralne
rozpoznaj i zmniejsz
Określ cele,
zagrożenia
inne strategie
(ocena ryzyka technicznego
Analiza zagrożeń
i ograniczenia
Analiza zagrożeń
Działający
prototyp
Analiza zagrożeń Prototyp 3
Analiza Prototyp 2
zagrożeń
RECENZJA
Prototyp 1
Sposób Symulacje, modele, miary odniesienia
Plan wymagań
Szczegółowe
postępowania
Plan cyklu życia
projekto-
Wymagania
Projekto-
wanie
S/W
wanie
Plan tworzenia
Kodowanie
Zatwierdzenie
produktu
Testy
wymagań
jednostek
Plan testowania
Weryfikacja i
Testy
i integracji
zatwierdzenie
integracji
Testy
Zaplanuj następną
akceptacji
Utwórz, zweryfikuj
Działanie
fazÄ™
produkt następnego
poziomu
Inżynieria oprogramowania, wykład 1, slajd 54
Prototypowanie
prototyping
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.
ogólne określenie wymagań
Fazy
budowa prototypu
weryfikacja prototypu przez klienta
pełne określenie wymagań
realizacja pełnego systemu zgodnie z modelem kaskadowym
wykrycie nieporozumień pomiędzy klientem a twórcami syste
Cele wykrycie brakujÄ…cych funkcji
wykrycie trudnych usług
wykrycie braków w specyfikacji wymagań
możliwość demonstracji pracującej wersji systemu
Zalety
możliwość szkoleń zanim zbudowany zostanie pełny system
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)
planowanie
analiza i projektowanie
wymagania
planowanie
implementowanie
wstępne
zarzÄ…dzanie
środowiskiem
testowanie
ocena
dystrybucja
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ę;
Inżynieria oprogramowania, wykład 1, slajd 58
 zwraca szczególną uwagę na krótko-terminowość
Ryzyko projektowe
Model kaskadowy
Model iteracyjny
Redukcja ryzyka
czas
Profil ryzyka
Inżynieria oprogramowania, wykład 1, slajd 59
ryzyko
Cykl życia oprogramowania w normie IEC 300-3-6
Cykl życia wyrobu
Koncepcja,
Projekt, Produkcja, Działanie,
Usunięcie
Definicja
Technologia Instalacja
Konserwacja
upływ czasu
Dezaktua-
lizacja
oprogra-
mowania
Utrzymywanie,
ulepszanie
oprogramowania
Analiza
Wdrożenie
wymagań
oprogramow.
Specyfikacja
Testy
systemu
akceptacyjne
Projekt
wstępny
Testy
systemu
Projekt
szczegółowy
Testy
Cykl życia
integracyjne
Kodowanie,
oprogramowania
Testy
komponentów
Cykl życia oprogramowania (według IEC 300-3-6)
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
Specyfikowanie oprogramowania
Specyfikowanie oprogramowania:
Studium
Określenie i analiza
wykonalności
wymagań
Specyfikacja
wymagań
Zatwierdzanie
Raport o
wymagań
wykonywalności
Modele
systemu
Wymagania użytko-
wnika systemu
Dokumentacja
wymagań
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
Specyfikacja
projektowania:
wymagań
Składowe projektowe
Projektowanie
Projektowanie Specyfikowanie Projektowanie Projektowanie Projektowanie
struktury danych
architektury abstrakcyjne interfejsów komponentów algorytmów
Specyfikacja
Architektura Specyfikacja Specyfikacja Specyfikacja
Specyfikacja
struktury
systemu programowania komponentów algorytmów
interfejsów
danych
Produkty projektowania
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;
Inżynieria oprogramowania, wykład 1, slajd 66
 Niestety wciąż jeszcze projektowanie jest
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 luz
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
Inżynieria oprogramowania, wykład 1, slajd 68
systemu do użytkowania;
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ę
Inżynieria oprogramowania, wykład 1, slajd 69
problemach;
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
Inżynieria oprogramowania, wykład 1, slajd 70
wciąż będzie niższy niż odpowiednie zmiany w
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ę
Inżynieria oprogramowania, wykład 1, slajd 71