In\
ynieria oprogramowania
część 3 - Proces tworzenia oprogramowania
System informacyjny
zbiór zasad, metod i procedur tworzenia, przesyłania,
magazynowania i przetwarzania informacji
formalny zespół środków kapitałowych oraz algorytmów,
których funkcjonowanie przejawia się w zbieraniu,
kodowaniu, magazynowaniu, przetwarzaniu, dekodowaniu
i u\
ytkowaniu danych potrzebnych dla podejmowania
decyzji i zarządzania
usystematyzowana i uporządkowana sieć powiązań między
takimi elementami jak: człowiek, dane, metody oraz
urządzenia do zbierania, gromadzenia, przesyłania i
przetwarzania danych, mających na celu zaspokojenie
potrzeb informacyjnych zainteresowanych ogniw
Podstawy in\
ynierii oprogramowania
Slajd nr 62
System informacyjny
celowe zestawienie ludzi, danych, procesów, sposobów
komunikacji, infrastruktury sieciowej i urządzeń
komputerowych, które to elementy współdziałają w celu
zapewnienia codziennego funkcjonowania organizacji jak
równie\
wspierają rozwiązywanie problemów i
podejmowanie decyzji przez kadrę kierowniczą
Podstawy in\
ynierii oprogramowania
Slajd nr 63
System informatyczny
spełnia funkcję systemu informacyjnego
określony, wyodrębniony obszar systemu informacyjnego
dla danego obiektu obsługiwany za pomocą technicznych
środków informatyki
oparte na technologii komputerowej rozwiązanie
pojedynczego problemu biznesowego. Mo\
e być to
aplikacja, rozwiązanie sprzętowe lub (najczęściej)
połączenie obu tych składników
system informatyczny mo\
e być jedną z części składowych
systemu informacyjnego
Podstawy in\
ynierii oprogramowania
Slajd nr 64
System informatyczny
system informacyjny mo\
e się składać z więcej ni\

jednego systemu informatycznego
system informacyjny niekoniecznie musi zawierać
elementy infrastruktury IT
Podstawy in\
ynierii oprogramowania
Slajd nr 65
3. Proces tworzenia oprogramowania
Zawartość:
Modele procesu tworzenia oprogramowania
Iteracja procesu
Specyfikowanie oprogramowania
Projektowanie i implementowanie oprogramowania
Zatwierdzanie oprogramowania
Ewolucja oprogramowania
Zautomatyzowane wspomaganie procesu
Podstawy in\
ynierii oprogramowania
Slajd nr 66
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.
Podstawy in\
ynierii oprogramowania
Slajd nr 67
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.
Podstawy in\
ynierii oprogramowania
Slajd nr 68
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óz
niej jest
udoskonalana zgodnie z informacjami otrzymanymi od
klienta. Prowadzi to do stworzenia systemu spełniającego
oczekiwania klienta.
Podstawy in\
ynierii oprogramowania
Slajd nr 69
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.
Podstawy in\
ynierii oprogramowania
Slajd nr 70
Modele: - Model kaskadowy
Definiowanie i analiza wymagań. Usługi, ograniczenia i cele
systemu są ustalane w czasie narad z u\
ytkownikami systemu. Są
póz
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ę.
Podstawy in\
ynierii oprogramowania
Slajd nr 71
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ń.
Podstawy in\
ynierii oprogramowania
Slajd nr 72
Modele: - Model kaskadowy
Określenie
wymagań
Fazy zasadnicze
Fazy zasadnicze
Projektowanie
Implementacja
Testowanie
Konserwacja
Fazy dodatkowe
Fazy dodatkowe
Faza strategiczna Analiza Instalacja
Dokumentacja
Podstawy in\
ynierii oprogramowania
Slajd nr 73
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óz
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.
Podstawy in\
ynierii oprogramowania
Slajd nr 74
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.
Podstawy in\
ynierii oprogramowania
Slajd nr 75
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
Podstawy in\
ynierii oprogramowania
Slajd nr 76
Tworzenie ewolucyjne
Podstawy in\
ynierii oprogramowania
Slajd nr 77
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.
Podstawy in\
ynierii oprogramowania
Slajd nr 78
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.
Podstawy in\
ynierii oprogramowania
Slajd nr 79
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.
Podstawy in\
ynierii oprogramowania
Slajd nr 80
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
Podstawy in\
ynierii oprogramowania
Slajd nr 81
Tworzenie formalne systemów
Podstawy in\
ynierii oprogramowania
Slajd nr 82
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
Podstawy in\
ynierii oprogramowania
Slajd nr 83
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.
Podstawy in\
ynierii oprogramowania
Slajd nr 84
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.
Podstawy in\
ynierii oprogramowania
Slajd nr 85
Tworzenie z u\
yciem wielokrotnym
Podstawy in\
ynierii oprogramowania
Slajd nr 86
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 znalez
ć 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.
Podstawy in\
ynierii oprogramowania
Slajd nr 87
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ą.
Podstawy in\
ynierii oprogramowania
Slajd nr 88
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.
Podstawy in\
ynierii oprogramowania
Slajd nr 89
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.
Podstawy in\
ynierii oprogramowania
Slajd nr 90
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.
Podstawy in\
ynierii oprogramowania
Slajd nr 91
Tworzenie przyrostowe
Definicja wymagań Projekt
Analiza Kodowanie i testowanie
Architektura Wdro\
enie
Projekt
Kodowanie i testowanie
Wdro\
enie
Projekt
Kodowanie i testowanie
Wdro\
enie
Podstawy in\
ynierii oprogramowania
Slajd nr 92
Tworzenie przyrostowe
Podstawy in\
ynierii oprogramowania
Slajd nr 93
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óz
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ść.
Podstawy in\
ynierii oprogramowania
Slajd nr 94
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.
Podstawy in\
ynierii oprogramowania
Slajd nr 95
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.
Podstawy in\
ynierii oprogramowania
Slajd nr 96
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ę.
Podstawy in\
ynierii oprogramowania
Slajd nr 97
Tworzenie spiralne
Podstawy in\
ynierii oprogramowania
Slajd nr 98
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óz
niejszych kłopotów w fazach projektowania i implementacji.
Podstawy in\
ynierii oprogramowania
Slajd nr 99
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.
Podstawy in\
ynierii oprogramowania
Slajd nr 100
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.
Podstawy in\
ynierii oprogramowania
Slajd nr 101
Specyfikowanie oprogramowania
Podstawy in\
ynierii oprogramowania
Slajd nr 102
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.
Podstawy in\
ynierii oprogramowania
Slajd nr 103
Projektowanie i implementowanie wymagań
Podstawy in\
ynierii oprogramowania
Slajd nr 104
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.
Podstawy in\
ynierii oprogramowania
Slajd nr 105
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.
Podstawy in\
ynierii oprogramowania
Slajd nr 106
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.
Podstawy in\
ynierii oprogramowania
Slajd nr 107
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.
Podstawy in\
ynierii oprogramowania
Slajd nr 108
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.
Podstawy in\
ynierii oprogramowania
Slajd nr 109
Programowanie i wyszukiwanie błędów
Podstawy in\
ynierii oprogramowania
Slajd nr 110
Zatwierdzanie oprogramowania
Weryfikacja i zatwierdzanie oprogramowania mają
wykazać, \
e system jest zgodny ze swoją specyfikacją i
spełnia oczekiwania klienta.
Podstawy in\
ynierii oprogramowania
Slajd nr 111
Zatwierdzanie oprogramowania
Podstawy in\
ynierii oprogramowania
Slajd nr 112
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.
Podstawy in\
ynierii oprogramowania
Slajd nr 113
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.
Podstawy in\
ynierii oprogramowania
Slajd nr 114
Zatwierdzanie oprogramowania
Podstawy in\
ynierii oprogramowania
Slajd nr 115
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.
Podstawy in\
ynierii oprogramowania
Slajd nr 116
Ewolucja oprogramowania
Podstawy in\
ynierii oprogramowania
Slajd nr 117
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.
Podstawy in\
ynierii oprogramowania
Slajd nr 118
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.
Podstawy in\
ynierii oprogramowania
Slajd nr 119
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.
Podstawy in\
ynierii oprogramowania
Slajd nr 120
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.
Podstawy in\
ynierii oprogramowania
Slajd nr 121
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.
Podstawy in\
ynierii oprogramowania
Slajd nr 122
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.
Podstawy in\
ynierii oprogramowania
Slajd nr 123
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.
Podstawy in\
ynierii oprogramowania
Slajd nr 124