Inżynieria oprogramowania

część 3 - Proces tworzenia oprogramowania

mgr inż. Piotr Greniewski

Europejska Wyższa Szkoła Informatyczno-

Ekonomiczna

Slajd nr 2

©Ian Sommerville 2000 - Inżynieria oprogramowania

Materiały do wykładu



Wykład opracowano na podstawie książki:



Inżynieria oprogramowania - Jan Sommerville



Wydawnictwa Naukowo – Techniczne



Warszawa 2003 r.



Prawa własności:



Rysunki, diagramy oraz układ prezentowanych treści są
własnością:

©Ian Sommerville 2000

.



Prezentacja stanowi tłumaczenie prezentacji autora
książki pobranej z witryny

http:/www.software-

engin.com.



Zgodnie z wolą autora: ”wykładowcy mają prawo
dowolnie modyfikować i adoptować tę prezentacje”
(Przedmowa – Witryna WWW – punkt 2 ) co też czynię.

Slajd nr 3

©Ian Sommerville 2000 - Inżynieria oprogramowania

3. Proces tworzenia oprogramowania

Zawartość:



Modele procesu tworzenia oprogramowania



Iteracja procesu



Specyfikowanie oprogramowania



Projektowanie i implementowanie
oprogramowania



Zatwierdzanie oprogramowania



Ewolucja oprogramowania



Zautomatyzowane wspomaganie procesu

Slajd nr 4

©Ian Sommerville 2000 - Inżynieria oprogramowania

Proces tworzenia oprogramowania



Proces tworzenia oprogramowania jest zbiorem czynności i
związanych z nimi wyników, które prowadzą do powstania
produktu.



Może to być tworzenie od zera lub przez rozszerzenie
istniejącego oprogramowania.



Procesy tworzenia oprogramowania są złożone i zależą od
ludzi jak wszystkie procesy intelektualne. Rozsądek i
kreatywność są niezbędne. Automatyzacja procesu
tworzenia nie przynosi spodziewanych rezultatów.



Narzędzia CASE mogą jedynie wspomóc niektóre czynności.



Przyczyną ograniczenia możliwości automatyzacji jest
niezmierna różnorodność procesów tworzenia.



Nie ma idealnego procesu twórczego – różne firmy
wypracowały różne podejścia.

Slajd nr 5

©Ian Sommerville 2000 - Inżynieria oprogramowania

Proces tworzenia oprogramowania



Czynności wspólne dla wszystkich procesów
tworzenia oprogramowania;



Specyfikowanie oprogramowania. Funkcjonalność
oprogramowania i ograniczenia jego działania muszą
być zdefiniowane.



Projektowanie i implementowanie oprogramowani.
Stworzone musi być oprogramowanie spełniające
specyfikację.



Zatwierdzenie oprogramowania. Oprogramowanie musi
być zweryfikowane, aby zapewnić to, czego oczekiwał
klient.



Ewolucja oprogramowania. Oprogramowanie musi
ewoluować, aby spełniać zmieniające się potrzeby
użytkowników.

Slajd nr 6

©Ian Sommerville 2000 - Inżynieria oprogramowania

Modele procesu tworzenia
oprogramowania



Model kaskadowy. W tym modelu podstawowe

czynności specyfikowania, tworzenia,

zatwierdzania i ewolucji są odrębnymi fazami

procesu takimi jak specyfikowanie wymagań,

projektowanie oprogramowania, implementacja,

testowanie itd.



Tworzenie ewolucyjne. W tym procesie czynności

specyfikowania, projektowania i zatwierdzania

przeplatają się. Pierwsza wersja systemu powstaje

bardzo szybko na podstawie abstrakcyjnych

specyfikacji. Później jest udoskonalana zgodnie z

informacjami otrzymanymi od klienta. Prowadzi to

do stworzenia systemu spełniającego oczekiwania

klienta.

Slajd nr 7

©Ian Sommerville 2000 - Inżynieria oprogramowania

Modele procesu tworzenia
oprogramowania



Tworzenie formalne systemu. To podejście jest
oparte na budowaniu formalnych matematycznych
specyfikacji systemu i przekształcaniu tych
specyfikacji w program za pomocą metod
matematycznych.Weryfikacja komponentów
systemu polega na wnioskowaniu matematycznym
o ich zgodności ze specyfikacją.



Tworzenie z użyciem wielokrotnym. W tym
podejściu zakłada się istnienie dużej liczby
komponentów zdatnych do ponownego użycia.
Proces budowy systemu polega głównie na
integracji tych fragmentów, a nie tworzeniu ich od
początku.

Slajd nr 8

©Ian Sommerville 2000 - Inżynieria oprogramowania

Modele: - Model kaskadowy



Definiowanie i analiza wymagań. Usługi, ograniczenia i
cele systemu są ustalane w czasie narad z użytkownikami
systemu. Są później szczegółowo definiowane i służą jako
specyfikacja systemu.



Projektowanie systemu i oprogramowania. Proces
projektowania systemu prowadzi do podziału wymagań na
systemy sprzętu i oprogramowania. Ustala ogólną
architekturę systemu. Projektowanie oprogramowania
obejmuje identyfikowanie i opisywanie zasadniczych
abstrakcji systemu oprogramowania i związki między nimi.



Implementacja i testowanie jednostek. W tym kroku
projekt oprogramowania jest realizowany w postaci zbioru
programów albo jednostek programów. Testowanie
jednostek polega na sprawdzeniu, czy każda jednostka
spełnia swoją specyfikację.

Slajd nr 9

©Ian Sommerville 2000 - Inżynieria oprogramowania

Modele: - Model kaskadowy



Integracja i testowanie systemu. Jednostki programów
albo programy są integrowane i testowane jako
kompletne systemy, aby upewnić się czy spełniono
wymagania. Po zakończeniu testowania system jest
dostarczany klientowi.



Działanie i pielęgnacja systemu. Zwykle jest to
najdłuższa faza życia systemu. System jest
zainstalowany i przekazany do praktycznego
użytkowania. Pielęgnacja obejmuje poprawianie
błędów, których nie wykryto we wcześniejszych fazach
życia, poprawianie implementacji jednostek systemu i
wzbogacanie usług w miarę odkrywania nowych
wymagań.

Slajd nr 10

©Ian Sommerville 2000 - Inżynieria oprogramowania

Modele: - Model kaskadowy

Definiowanie

wymagań

Projektowanie

systemu i oprogr.

Implementacja i

testow. jednostek

Integracja i

testowanie syst.

Działanie

i pielęgnacja

Cykl życia oprogramowania

Slajd nr 11

©Ian Sommerville 2000 - Inżynieria oprogramowania

Modele: - Model kaskadowy



Wynikiem każdej fazy jest co najmniej jeden dokument, który
podlega akceptacji.



Następnej fazy nie powinno się rozpoczynać zanim poprzednia nie
zakończy się. W praktyce jednak te etapy zazębiają się i przekazują
nawzajem informacje. Proces ten nie jest prostym modelem
liniowym ale obejmuje ciąg iteracji czynności tworzenia.



Koszty opracowania dokumentów są wysokie i dlatego iteracje są też
kosztowne i wymagają powtórzenia wielu prac. Często po wykonaniu
kilku iteracji zostawia się problem do późniejszego rozwiązania,
pomija lub rozwiązuje się go metodami poza modelowymi.



Powoduje to ryzyko powstania złej struktury systemu lub otrzymanie
systemu który nie będzie robił tego co chce użytkownik.



W trakcie ostatniej fazy cyklu życia oprogramowanie jest
przekazywane do użytku i odkrywa się w nim błędy i zaniedbania w
pierwotnych wymaganiach. System musi ewoluować aby pozostać
użytecznym.

Slajd nr 12

©Ian Sommerville 2000 - Inżynieria oprogramowania

Modele: - Model kaskadowy



Wady modelu kaskadowego



nieelastyczny podział na rozłączne etapy.



zobowiązania muszą być podejmowane w bardzo wczesnej
fazie procesu. Stwarza to trudności z reagowaniem na
zmieniające się wymagania.



Model kaskadowy powinien być używany wtedy gdy
wymagania są jasne i zrozumiałe. Model ten jednak
odzwierciedla normalną praktykę inżynierską. Jest on
często używany mimo wad

.

Slajd nr 13

©Ian Sommerville 2000 - Inżynieria oprogramowania

Tworzenie ewolucyjne



Tworzenie ewolucyjne polega na opracowaniu
wstępnej implementacji, pokazaniu jej
użytkownikowi z prośbą o komentarze i
udoskonalaniu jej w kolejnych wersjach aż do
powstania odpowiedniego systemu

Slajd nr 14

©Ian Sommerville 2000 - Inżynieria oprogramowania

Validation

Final

version

Development

Intermediate

versions

Specification

Initial

version

Outline

description

Concurrent

activities

Tworzenie ewolucyjne

Slajd nr 15

©Ian Sommerville 2000 - Inżynieria oprogramowania

Tworzenie ewolucyjne



Dwa typy tworzenia ewolucyjnego:



Tworzenie badawcze – celem procesu jest praca z
klientem polegająca na badaniu wymagań i
dostarczenie ostatecznego systemu. Tworzenie
rozpoczyna się od tych części systemu które są
dobrze rozpoznane. System ewoluuje przez dodanie
nowych cech proponowanych przez klienta.



Prototypowanie z porzuceniem – celem procesu jest
zrozumienie wymagań klienta i wypracowanie
lepszej definicji wymagań stawianych systemowi.
Budowanie prototypu służy do eksperymentu z
niejasnymi wymaganiami.

Slajd nr 16

©Ian Sommerville 2000 - Inżynieria oprogramowania

Tworzenie ewolucyjne



Podejście ewolucyjne jest bardziej efektywne
od kaskadowego



Powstają systemy bardziej odpowiadające
użytkownikom



Zaletą procesu tworzenia ewolucyjnego jest
przyrostowe powstawanie specyfikacji



Użytkownik coraz lepiej rozumie swoje
problemy a to daje bardziej przydatne
oprogramowanie.

Slajd nr 17

©Ian Sommerville 2000 - Inżynieria oprogramowania

Tworzenie ewolucyjne



Problemy tworzenia ewolucyjnego;



Proces nie jest widoczny. Menedżerowie potrzebują
regularnych wyników aby mierzyć postęp prac.
Jeżeli prace postępują szybko nie opłaca się
generować dokumentów opisujących każdą wersję
systemu.



System ma złą strukturę. Nieustanne modyfikacje
psują strukturę oprogramowania. Wprowadzanie
nowych zmian staje się kosztowne i trudniejsze.



Konieczne jest stosowanie specjalnych narzędzi i
technik. Ułatwiają one i przyspieszają proces
tworzenia ale są niekompatybilne z innymi
narzędziami.

Slajd nr 18

©Ian Sommerville 2000 - Inżynieria oprogramowania

Tworzenie formalne systemów



Podejście to ma wiele wspólnego z modelem
kaskadowym



Oparty jest na na matematycznych
przekształceniach specyfikacji systemu w
program wykonywalny

Slajd nr 19

©Ian Sommerville 2000 - Inżynieria oprogramowania

Tworzenie formalne systemów

Requirements

definition

Formal

specification

Formal

transformation

Integration and

system testing

Slajd nr 20

©Ian Sommerville 2000 - Inżynieria oprogramowania

Tworzenie formalne systemów



Zasadnicze cechy odróżniające model
kaskadowy od formalnego:



specyfikacja wymagań jest zapisywana za pomocą
notacji matematycznej



procesy projektowania, implementacji i testowania
jednostek są zastąpione przez proces tworzenia z
przekształceniem. Specyfikacja formalna jest
udoskonalana przez ciąg przekształceń, które
prowadzą do powstania programu

Slajd nr 21

©Ian Sommerville 2000 - Inżynieria oprogramowania

Tworzenie formalne systemów

R2

Formal

specification

R3

Executable

program

P2

P3

P4

T1

T2

T3

T4

Proofs of transformation correctness

Formal transformations

R1

P1

Slajd nr 22

©Ian Sommerville 2000 - Inżynieria oprogramowania

Tworzenie formalne systemów



W procesie przekształcenia formalna matematyczna
reprezentacja systemu jest metodycznie przekształcana
w bardziej szczegółowe ale wciąż matematycznie
poprawne reprezentacje systemu



Metoda przydatna do tworzenia systemów z surowymi
wymaganiami bezpieczeństwa



Metoda używana jedynie do specjalistycznych dziedzin.

Slajd nr 23

©Ian Sommerville 2000 - Inżynieria oprogramowania

Tworzenie z użyciem wielokrotnym



W większości projektów informatycznych występuje użycie
wielokrotne oprogramowania.



Dzieje się to zwykle nieformalnie, gdy zatrudnione osoby
znają projekty lub lub kody programów podobne do tych
wymaganych.



W podejściu ewolucyjnym użycie wielokrotne jest uważane za
podstawę szybkiego tworzenia systemów



W ostatnich latach wyłoniło się nowe podejście do tworzenia
oprogramowania (inżynieria oprogramowania
komponentowego) oparte na użyciu wielokrotnym.



Metoda zakłada istnienie wielkiego zbioru komponentów
programowych oraz integrującej je struktury.



Początkowa faza specyfikacji oprogramowania i faza
zatwierdzania są podobne do innych procesów, etapy
pośrednie są inne.

Slajd nr 24

©Ian Sommerville 2000 - Inżynieria oprogramowania

Tworzenie z użyciem wielokrotnym

Requirements

specification

Component

analysis

Development

and integration

System design

with reuse

Requirements

modification

System

validation

Slajd nr 25

©Ian Sommerville 2000 - Inżynieria oprogramowania

Tworzenie z użyciem wielokrotnym



Etapy pośrednie:



Analiza komponentów. Na podstawie specyfikacji
wymagań poszukuje się komponentów
implementujących tę specyfikację. Zwykle nie
można znaleźć idealnie pasujących komponentów.



Modyfikacja wymagań. W trakcie tej fazy analizuje
się wymagania pod kątem uzyskanych
komponentów. Następnie modyfikuje się wymagania
aby odzwierciedlały dostępne komponenty. Jeśli
modyfikacje nie są możliwe analiza komponentów
musi być powtórzona.

Slajd nr 26

©Ian Sommerville 2000 - Inżynieria oprogramowania

Tworzenie z użyciem wielokrotnym



Projektowanie systemu z użyciem wielokrotnym. W
trakcie tej fazy projektuje się szkielet systemu lub
wykorzystuje istniejące szkielety. Projektanci biorą
pod uwagę. Jest on tworzony zgodnie z
wymaganiami użytych komponentów. Czasami
potrzebne są nowe fragmenty oprogramowania.



Tworzenie i integracja. Tworzy się oprogramowanie,
którego nie można było kupić. Integruje się w
system komponenty i zakupione systemy. W tym
modelu integracja systemu może być częścią
procesu tworzenia a nie oddzielną czynnością.

Slajd nr 27

©Ian Sommerville 2000 - Inżynieria oprogramowania

Iteracja procesu



Wymienione dotychczas modele procesów
mają szereg zalet i wad. W wypadku
projektowania dużych systemów stosujemy
modele hybrydowe.



Tworzenie przyrostowe, w którym specyfikacja,
projektowanie i implementacja są podzielone na ciąg
po kolei realizowanych przyrostów.



Tworzenie spiralne, w którym system rozwija się
ruchem spiralnym na zewnątrz od początkowego
szkicu do końcowego systemu.

Slajd nr 28

©Ian Sommerville 2000 - Inżynieria oprogramowania

Tworzenie przyrostowe



Model tworzenia przyrostowego łączy w sobie zalety modelu
kaskadowego i ewolucyjnego likwidując część ich wad.



Umożliwił on ograniczenie powtarzania prac oraz dał klientom
możliwość odkładania decyzji o szczegółowych wymaganiach aż
do czasu gdy zdobędą pewne doświadczenie w pracy z systemem.



Klienci identyfikują w zarysie usługi, które system ma oferować.
Wskazują które są najważniejsze a które mniej ważne.



Definiuje się pewną liczbę przyrostów, które mają być
dostarczone. Każdy z nich zawiera część funkcjonalności
systemu. Przyporządkowanie usług do przyrostów zależy od ich
priorytetu.



Usługi o najwyższym priorytecie dostarczane są jako pierwsze.



Po zdefiniowaniu przyrostów definiuje się szczegółowo
wymagania stawiane usługom dostarczonym w pierwszym
przyroście.

Slajd nr 29

©Ian Sommerville 2000 - Inżynieria oprogramowania

Tworzenie przyrostowe



Przyrost jest tworzony za pomocą odpowiedniego procesu
a w jego trakcie prowadzi się analizę dla następnych
przyrostów



Gdy przyrost jest gotowy klienci mogą go uruchomić –
szybko otrzymują część funkcjonalności systemu.



Po zakończeniu prac nad kolejnymi wymaganiami integruje
się je z istniejącymi przyrostami.



Funkcjonalność systemu wzrasta wraz z kolejnymi
przyrostami.



Nie ma konieczności aby tworzenia przyrostów odbywało
się zgodnie z tym samym procesem



Gdy usługi w przyroście mają mają staranną specyfikację
stosujemy model kaskadowy



Gdy specyfikacja jest niejasna stosujemy model ewolucyjny.

Slajd nr 30

©Ian Sommerville 2000 - Inżynieria oprogramowania

Tworzenie przyrostowe

Validate

increment

Develop system

increment

Design system

architecture

Integrate

increment

Validate

system

Define outline

requirements

Assign requirements

to increments

System incomplete

Final

system

Slajd nr 31

©Ian Sommerville 2000 - Inżynieria oprogramowania

Tworzenie przyrostowe



Zalety ( wady) tworzenia przyrostowego:



Klienci nie muszą czekać na dostawę całego systemu.
Pierwszy przyrost spełnia najbardziej istotne
wymagania i może być używany



Klienci mogą używać przyrostów jako prototypów i
zdobywać doświadczenia.



Ryzyko całkowitej porażki przedsięwzięcia jest
mniejsze.



Usługi o najwyższym priorytecie będą dostarczane jako
pierwsze, a późniejsze przyrosty będą z nimi
integrowane. Dzięki temu najważniejsze usługi będą
dokładnie przetestowane



Przyrosty nie mogą być zbyt duże a każdy przyrost
powinien dostarczać pewną funkcjonalność.

Slajd nr 32

©Ian Sommerville 2000 - Inżynieria oprogramowania

Tworzenie spiralne



W modelu spiralnym proces nie jest
przedstawiany jako ciąg czynności z pewnymi
nawrotami od jednej do drugiej ale ma postać
spirali.



Każda pętla spirali reprezentuje jedną fazę
procesu



wykonalności



definicji stawianych wymagań



projektowaniu systemu



itd.

Slajd nr 33

©Ian Sommerville 2000 - Inżynieria oprogramowania

Tworzenie spiralne



Każda pętla spirali podzielona jest na cztery
sektory:



Ustalanie celów. Definiuje się konkretne cele tej
fazy przedsięwzięcia. Identyfikuje się ograniczenia
którym podlega proces i produkt. Rysuje się
szczegółowe plany zarządzania. Rozpoznaje się
zagrożenia i strategie ich unikania.



Rozpoznanie i redukcja zagrożeń. Przeprowadza się
szczegółową analizę każdego z rozpoznanych
zagrożeń przedsięwzięcia. Podejmuje się kroki aby
je zredukować. Gdy np. wymagania są
nieodpowiednie można opracować prototyp itp.

Slajd nr 34

©Ian Sommerville 2000 - Inżynieria oprogramowania

Tworzenie spiralne



Tworzenie i zatwierdzanie. Po ocenie zagrożeń
wybiera się model tworzenia systemu. Jeśli
zagrożenie jest związane z interfejsem użytkownika
to możemy wybrać prototypowanie ewolucyjne. Jeśli
zagrożone jest bezpieczeństwo to model kaskadowy.



Planowanie. Recenzuje się przedsięwzięcie i
podejmuje decyzję czy rozpoczynać następną pętlę.

Slajd nr 35

©Ian Sommerville 2000 - Inżynieria oprogramowania

Risk

analysis

Risk

analysis

Risk

analysis

Risk

anal

ysisProto-

type 1

Prototype 2

Prototype 3

Opera-

tional

protoype

Concept of

Operation

Simulations, models, benchmarks

S/W

requirements

Requirement

validation

Design

V&V

Product

design

Detailed

design

Code

Unit test

Integration

test

Acceptance

test

Service

Develop, verify

next-level product

Evaluate alternatives

identify, resolve risks

Determine objectives

alternatives and

constraints

Plan next phase

Integration

and test plan

Development

plan

Requirements plan

Life-cycle plan

REVIEW

Tworzenie spiralne

Slajd nr 36

©Ian Sommerville 2000 - Inżynieria oprogramowania

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.



Czynność ta nazywana bywa inżynierią wymagań



Jest to bardzo istotna faza ponieważ błędy w tej fazie
prowadzą do późniejszych kłopotów w fazach
projektowania i implementacji.

Slajd nr 37

©Ian Sommerville 2000 - Inżynieria oprogramowania

Specyfikowanie oprogramowania



Cztery fazy specyfikowania oprogramowania

:



Studium wykonalności. Ocenia się czy rozpoznane
potrzeby użytkowników mogą być spełnione przy
obecnych technologiach sprzętu i oprogramowania.
Ocenia się czy proponowany system będzie opłacalny z
punktu widzenia ekonomii i czy można go zbudować w
ramach założonego budżetu. Studium powinno być
krótkie i tanie. Jego wynik decyduje o dalszych analizach.



Określenie i analiza wymagań. Jest to proces określania
wymagań stawianych systemowi na podstawie obserwacji
istniejących systemów, rozmów z potencjalnymi
użytkownikami, analizy zadań. Może wymagać
opracowania jednego lub kilku modeli i prototypów
pomagających analitykom zrozumieć system.

Slajd nr 38

©Ian Sommerville 2000 - Inżynieria oprogramowania

Specyfikowanie oprogramowania



Specyfikowanie wymagań. Polega na zapisywaniu
informacji zebranych w czasie analizy w dokumencie
definiującym zbiór wymagań. Mogą wystąpić dwa
rodzaje wymagań. Wymagania użytkownika są
abstrakcyjnymi określeniami są abstrakcyjnymi
określeniami wymagań stawianych systemowi
spisanymi dla klienta i użytkownika. Wymagania
systemowe są bardziej szczegółowym opisem
funkcjonalności którą należy dostarczyć.



Zatwierdzanie wymagań. W tej czynności sprawdza
się realizm, spójność i kompletność wymagań. W jej
trakcie niemal pewne jest wykrycie błędów. Należy
zmodyfikować dokumentację wymagań tak, aby
usunąć te błędy.

Slajd nr 39

©Ian Sommerville 2000 - Inżynieria oprogramowania

Specyfikowanie oprogramowania

Feasibility

study

Requirements

elicitation and

analysis

Requirements

specification

Requirements

validation

Feasibility

report

System

models

User and system

requirements

Requirements

document

Slajd nr 40

©Ian Sommerville 2000 - Inżynieria oprogramowania

Projektowanie i implementowanie
wymagań



Faza implementowania to proces
przekształcania specyfikacji systemu w
działający system. Obejmuje zawsze
projektowanie i programowanie ale może
zawierać udoskonalanie specyfikacji gdy
wybraliśmy podejście ewolucyjne.

Slajd nr 41

©Ian Sommerville 2000 - Inżynieria oprogramowania

Projektowanie i implementowanie
wymagań

Architectur

al

design

Abstr

act

specifica

tion

Interface

design

Component

design

Data

structur

e

design

Algorithm

design

System

architectur

e

Softw

are

specifica

tion

Interface

specifica

tion

Component

specifica

tion

Data

structur

e

specifica

tion

Algorithm

specifica

tion

Requir

ements

specifica

tion

Design acti

vities

Design pr

oducts

Slajd nr 42

©Ian Sommerville 2000 - Inżynieria oprogramowania

Projektowanie i implementowanie
wymagań



Czynności procesu projektowania:



Projektowanie architektury. Identyfikuje i dokumentuje
podsystemy tworzące system oraz związki między nimi.



Specyfikowanie abstrakcyjne. Opracowuje się
abstrakcyjną specyfikację usług i ograniczeń każdego
podsystemu.



Projektowanie interfejsów. Projektuje się i dokumentuje
interfejsy każdego podsystemu z innymi podsystemami.
Specyfikacja musi być jednoznaczna ponieważ
umożliwia korzystanie z podsystemów bez znajomości
ich działania.



Projektowanie komponentów. Przypisuje się usługi do
różnych komponentów i projektuje interfejsy tych
komponentów.

Slajd nr 43

©Ian Sommerville 2000 - Inżynieria oprogramowania

Projektowanie i implementowanie
wymagań



Czynności procesu projektowania:



Projektowanie struktur danych. Szczegółowo
specyfikuje się i projektuje struktury danych użyte w
implementacji systemu.



Projektowanie algorytmów. Szczegółowo specyfikuje
się i projektuje algorytmy służące do realizacji
usług.

Slajd nr 44

©Ian Sommerville 2000 - Inżynieria oprogramowania

Metody projektowania



Metody niestrukturalne. Na podstawie zbioru
wymagań zapisanych w języku naturalnym
przygotowuje się nieformalny projekt. Rozpoczyna
się kodowanie a projekt jest modyfikowany w
miarę implementacji systemu. Gdy faza
implementacji jest ukończona projekt zwykle jest
różny od swego pierwotnego opisu. Brak
dokumentacji zmiany projektu itp.



Metody strukturalne. Opracowanie graficznych
modeli systemu. Metoda strukturalna zawiera
model procesu projektowania, notacje do zapisu
projektu, formaty raportów, zasady i porady dla
projektantów.

Slajd nr 45

©Ian Sommerville 2000 - Inżynieria oprogramowania

Metody projektowania



Modele systemu używane przez metody
strukturalne:



Modele przepływu danych, w którym system jest
opisywany za pomocą przekształceń danych
wykonywanych w trakcie ich przetwarzania.



Model encja-związek, który służy do opisu
podstawowych encji w projekcie i związków między
nimi.



Model strukturalny w którym dokumentuje się
komponenty systemu i ich interakcje.



Metody obiektowe zawierające model dziedziczenia w
systemie, modele statycznych i dynamicznych związków
między obiektami oraz modele interakcji obiektów w
czasie działania systemu.

Slajd nr 46

©Ian Sommerville 2000 - Inżynieria oprogramowania

Programowanie i wyszukiwanie błędów



Programowanie jest indywidualną czynnością i
nie istnieje żaden ogólny proces, zgodnie z
którym się postępuje.



Czasami zaczyna się od komponentów albo
zostawia się je na koniec.



Niektórzy programiści zaczynają od
zdefiniowania danych inni zostawiają dane bez
specyfikacji jak długo się da.



Programiści wykonują testy aby zlokalizować i
usunąć błędy.



Testowanie usterek i usuwanie błędów to dwa
różne procesy.

Slajd nr 47

©Ian Sommerville 2000 - Inżynieria oprogramowania

Programowanie i wyszukiwanie błędów

Locate

error

Design

error repair

Repair

error

Re-test

program

Slajd nr 48

©Ian Sommerville 2000 - Inżynieria oprogramowania

Zatwierdzanie oprogramowania



Weryfikacja i zatwierdzanie oprogramowania
mają wykazać, że system jest zgodny ze swoją
specyfikacją i spełnia oczekiwania klienta.

Slajd nr 49

©Ian Sommerville 2000 - Inżynieria oprogramowania

Zatwierdzanie oprogramowania

Sub-system

testing

Module

testing

Unit

testing

System

testing

Acceptance

testing

Component

testing

Integration testing

User

testing

Slajd nr 50

©Ian Sommerville 2000 - Inżynieria oprogramowania

Zatwierdzanie oprogramowania



Fazy procesu testowania:



Testowanie jednostek. Testuje się poszczególne
komponenty, aby zapewnić, że działają poprawnie.
Każdy komponent jest niezależnie testowany bez
udziału innych komponentów.



Testowanie modułów. Moduł to kolekcja
niezależnych komponentów takich jak klasy
obiektów, abstrakcyjne typy danych, procedury,
funkcje. Moduł testujemy bez udziału innych
modułów.



Testowanie podsystemów. Faza obejmuje testowanie
kolekcji modułów zintegrowanych w podsystem.
Służy głównie do wykrycia błędów w interfejsach.

Slajd nr 51

©Ian Sommerville 2000 - Inżynieria oprogramowania

Zatwierdzanie oprogramowania



Fazy procesu testowania:



Testowanie systemu. Podsystemy zintegrowano w

system. Ten proces ma wykryć błędy wynikające z

nieprzewidzianych interakcji między podsystemami i

problemów z interfejsami. W tej fazie sprawdza się czy

system spełnia stawiane mu wymagania funkcjonalne i

niefunkcjonalne. Bada się pojawiające się właściwości

systemu.



Testowanie odbiorcze. Końcowa faza procesu

testowania. System testuje się za pomocą danych

dostarczonych przez użytkownika. Testowanie może

doprowadzić do wykrycia błędów i zaniedbań w definicji

wymagań stawianych systemowi ponieważ prawdziwe

dane to co innego niż testy. Testowanie może wykazać

że udogodnienia nie odpowiadają użytkownikom lub

system nie jest efektywny.

Slajd nr 52

©Ian Sommerville 2000 - Inżynieria oprogramowania

Zatwierdzanie oprogramowania

Requirements

specification

System

specification

System

design

Detailed

design

Module and

unit code

and tess

Sub-system

integration

test plan

System

integration

test plan

Acceptance

test plan

Service

Acceptance

test

System

integration test

Sub-system

integration test

Slajd nr 53

©Ian Sommerville 2000 - Inżynieria oprogramowania

Ewolucja oprogramowania



Elastyczność oprogramowania – w
przeciwieństwie do nie elastyczności sprzętu.



Zmiany w oprogramowaniu mogą być
wykonywane po zakończeniu prac nad nim.



Rozgraniczenie pomiędzy tworzeniem
oprogramowania a jego pielęgnacją.



W chwili obecnej niewiele systemów
oprogramowania jest tworzonych od nowa.
Zaciera się więc granica pomiędzy
tworzeniem a pielęgnacją.



pojawia się pojęcie ewolucji systemu.

Slajd nr 54

©Ian Sommerville 2000 - Inżynieria oprogramowania

Ewolucja oprogramowania

Assess existing

systems

Define system

requirements

Propose system

changes

Modify

systems

New

system

Existing

systems

Slajd nr 55

©Ian Sommerville 2000 - Inżynieria oprogramowania

Zautomatyzowane wspomaganie procesu



Przykłady automatyzacji za pomocą CASE



Opracowanie graficznych modeli systemu, jako
części specyfikacji wymagań i projektu
oprogramowania.



Czytanie projektu za pomocą słownika danych, który
przechowuje informację o encjach i związkach w
projekcie.



Generowanie interfejsu użytkownika na podstawie
graficznego opisu interfejsu.



Śledzenie błędów przez udostępnianie informacji o
wykonującym się programie.



Automatyczne tłumaczenie programów.

Slajd nr 56

©Ian Sommerville 2000 - Inżynieria oprogramowania

Zautomatyzowane wspomaganie procesu



Ograniczenia CASE



Inżynieria oprogramowania jest oparta na
kreatywnym myśleniu. CASE automatyzują
rutynowe czynności. Próby zastosowania sztucznej
inteligencji nie były udane.



Inżynieria oprogramowania jest czynnością
zespołową, interakcja między użytkownikami jest
bardzo ważna – CASE nie daje tu żadnego wsparcia.

Slajd nr 57

©Ian Sommerville 2000 - Inżynieria oprogramowania

Klasyfikacja CASE



Narzędzia do planowania (PERT, arkusz kalkulac.)



Narzędzia do edycji (tekstów, diagramów)



Narzędzia do zarządzania zmianami



Narzędzia do zarządzania konfiguracjami (system zarządz.
wersjami)



Narzędzia do prototypowania



Narzędzia do wspomagania metod(edyt. proj., słowniki,
generat. kodu)



Narzędzia do przetwarzania języków (kompilatory)



Narzędzia do analizy programów (analizatory)



Narzędzia do testowania



Narzędzia do usuwania błędów



Narzędzia do dokumentowania



Narzędzia do inżynierii wstecz.

Slajd nr 58

©Ian Sommerville 2000 - Inżynieria oprogramowania

Klasyfikacja CASE

Activity-based classification

Reengineering tools

Testing tools

Debugging tools

Program analysis tools

Language-processing

tools

Method support tools

Prototyping tools

Configuration

management tools

Change management tools

Documentation tools

Editing tools

Planning tools

Specification

Design

Implementation Verification

and

Validation

©Ian Sommerville 2000 - Inżynieria oprogramowania

Slajd nr 60

©Ian Sommerville 2000 - Inżynieria oprogramowania

Klasyfikacja CASE



Kategorie systemów CASE



Narzędzia wspomagające poszczególne zadania w
ramach procesu takie jak kompilacja, spójność
projektu itp.



Warsztaty wspomagające całe fazy procesów lub
czynności, na przykład specyfikowanie lub
projektowanie. Zwykle jest to zintegrowany zbiór
narzędzi.



Środowiska wspomagają całość lub znaczącą część
procesu tworzenia oprogramowania.. Zwykle
składają się z kilku różnych zintegrowanych
warsztatów.

Slajd nr 61

©Ian Sommerville 2000 - Inżynieria oprogramowania

Klasyfikacja CASE

Single-method

workbenches

General-purpose

workbenches

Multi-method

workbenches

Language-specific

workbenches

Programming

Testing

Analysis and

design

Integrated

environments

Process-centred

environments

File

comparators

Compilers

Editors

Environments

Workbenches

Tools

CASE

technology

Slajd nr 62

©Ian Sommerville 2000 - Inżynieria oprogramowania

Główne tezy



Proces tworzenia oprogramowania to czynności zmierzające
do wyprodukowania systemu. Modele procesów tworzenia
oprogramowania to abstrakcyjne reprezentacje tych
procesów.



Wszystkie procesy tworzenia oprogramowania obejmują
specyfikowanie, projektowanie, implementację,
zatwierdzanie i ewolucję oprogramowania.



Ogólne modele procesów opisują organizację procesu
tworzenia oprogramowania. Przykładami takich modeli są:
model kaskadowy, tworzenie ewolucyjne, tworzenie
formalne oraz tworzenie z użyciem wielokrotny.



W modelach iteracyjnych tworzenie oprogramowania
przedstawia się w postaci cyklu czynności. Zaletą jest
uniknięcie zbyt wczesnego zatwierdzania specyfikacji lub
projektu. Model przyrostowy i spiralny.

Slajd nr 63

©Ian Sommerville 2000 - Inżynieria oprogramowania

Główne tezy



Inżynieria wymagań to proces opracowywania
specyfikacji oprogramowania. Obejmuje przygotowanie
specyfikacji zrozumiałej dla użytkowników systemu
oraz bardziej szczegółowej specyfikacji dla
budowniczych systemu.



Proces projektowania i implementowania polega na
przekształcaniu specyfikacji wymagań w działający
system oprogramowania. Metody systematycznego
projektowania mogą być elementem tego
przekształcenia.



Zatwierdzanie oprogramowania to proces sprawdzania
czy system jest zgodny ze swoją specyfikacją oraz czy
spełnia rzeczywiste potrzeby użytkowników.

Slajd nr 64

©Ian Sommerville 2000 - Inżynieria oprogramowania

Główne tezy



Ewolucja oprogramowania polega na modyfikowaniu
istniejącego systemu oprogramowania tak aby spełniał
nowe wymagania. Takie podejście staje się standardem
tworzenia oprogramowania dla małych i średnich
przedsięwzięć.



Technologia CASE zapewnia zautomatyzowane
wspomaganie procesu tworzenia oprogramowania.
Narzędzia CASE wspomagają poszczególne czynności
procesu. Warsztaty CASE wspomagają zbiory
powiązanych czynności. Środowiska CASE wspomagają
większość czynności procesu tworzenia
oprogramowania.