Zarządzanie projektem

Cele

•

Zrozumieć różnice między zarządzaniem przedsięwzięciem
programistycznym a zarządzaniem innymi rodzajami
przedsięwzięć inżynieryjnych;

•

Poznać podstawowe zadania menedżerów przedsięwzięcia
programistycznego;

•

Wiedzieć, dlaczego planowanie przedsięwzięcia jest niezbędne
w przedsięwzięciach programistycznych;

•

Wiedzieć, dlaczego planowanie przedsięwzięcia jest niezbędne
w przedsięwzięciach programistycznych;

•

Wiedzieć, dlaczego menedżerowie przedsięwzięć używają
postaci graficznej (wykresów paskowych i wykresów czynności)
do zapisywania harmonogramów przedsięwzięcia; rozumieć
proces zarządzania zagrożeniami i znać niektóre zagrożenia,
które mogą pojawić się w przedsięwzięciach programistycznych.

Tematy

•

Czynności zarządzania

•

Planowanie przedsięwzięcia

•

Tworzenie harmonogramu

•

Zarządzanie zagrożeniami

•

Zarządzanie zagrożeniami

Zarządzanie

•

Zarządzający programowaniem odpowiadają za planowanie i
tworzenie harmonogramu przedsięwzięcia. Kierują pracami tak,
aby zagwarantować ich prowadzenie zgodnie z wymaganymi
standardami. Śledzą postęp. aby sprawdzić, czy wytwarzanie
przebiega zgodnie z harmonogramem i w ramach budżetu.

•

Dobre zarządzanie nie zawsze gwarantuje sukces
przedsięwzięcia. Złe zarządzanie zwykle prowadzi do

przedsięwzięcia. Złe zarządzanie zwykle prowadzi do
niepowodzenia przedsięwzięcia. Oprogramowanie jest wówczas
dostarczane z opóźnieniem, kosztuje więcej, niż pierwotnie
założono, i nie spełnia stawianych mu wymagań.

Zarządzanie projektem programistycznym a „zwykłym”

inżynierskim

•

Produkt jest nieuchwytny. Zarządzający budową statku lub
przedsięwzięciem inżynierii lądowej może oglądać produkt w trakcie jego
tworzenia. Oprogramowanie jest nieuchwytne. Nie można go dotknąć ani
zobaczyć. Zarządzający przedsięwzięciem programistycznym nie może
zobaczyć postępu. Polega na tym, że inni dostarczą dokumentację
konieczną do oceny postępu.

•

Nie ma standardowych procesów tworzenia oprogramowania. Nie

•

Nie ma standardowych procesów tworzenia oprogramowania. Nie
rozpoznaliśmy jeszcze w sposób wystarczająco precyzyjny związków
między procesem a typem produktu. W wypadku dziedzin inżynierii o
długich tradycjach procesy są sprawdzone i przetestowane. Proces
inżynieryjny dostosowany do poszczególnych typów systemów (np.
mostów) jest dobrze znany i rozumiany.

Zarządzanie projektem programistycznym a „zwykłym”

inżynierskim

•

Wielkie przedsięwzięcia programistyczne są często
jednorazowe. Trudniej jest więc przewidywać kłopoty. Co
więcej, gwałtowne zmiany technologiczne dotyczące
komputerów i komunikacji powodują dezaktualizację tego
doświadczenia. Wiedza wynikająca z tego doświadczenia nie

doświadczenia. Wiedza wynikająca z tego doświadczenia nie
musi przenosić się na nowe przedsięwzięcia.

Czynności zarządzania

(zarządzającego)

•

opracowywanie oferty

•

planowanie i tworzenie harmonogramu
przedsięwzięcia

•

szacowanie kosztów przedsięwzięcia

•

szacowanie kosztów przedsięwzięcia

•

monitorowanie i ocenianie przedsięwzięcia

•

wybór i ocena personelu

•

opracowywanie raportów i prezentacji.

Wybieranie wykonawców - ograniczenia

•

Budżet przedsięwzięcia nie wystarczy do zatrudnienia dobrze
opłacanego personelu. Trzeba przyjąć mniej doświadczonych i
gorzej wynagradzanych pracowników.

•

Personel z odpowiednim doświadczeniem może nie być
dostępny w ramach firmy, a nawet w jej otoczeniu. Zatrudnienie
nowych osób może być niewykonalne. Najlepsi ludzie w firmie
mogą brać udział w innych przedsięwzięciach.

mogą brać udział w innych przedsięwzięciach.

•

Firma może oczekiwać, że pracownicy zwiększą swoje
umiejętności. Do przedsięwzięcia przydziela się wówczas mniej
doświadczone osoby, aby w jego trakcie uczyły się i zdobywały
doświadczenie.

Planowanie przedsięwzięcia

•

Najprawdopodobniej najbardziej
czasochłonna cześć projektu (dobrego)

•

Projekt ciągły – od momentu wstępnego
planowania – do pielęgnowania

planowania – do pielęgnowania

•

Różnorodne typy planów mogą być
opracowane do wspierania projektu (plan
dostarczania, plan budżetu itp.)

Planowanie przedsięwzięcia

•

Plan jakości Obejmuje procedury zapewniania jakości i
standardy obowiązujące w przedsięwzięciu

•

Plan zatwierdzania Obejmuje podejście, zasoby i harmonogram
zatwierdzania systemu

•

Plan zarządzania konfiguracjami Obejmuje procedury
zarządzania konfiguracjami i używane struktury.

zarządzania konfiguracjami i używane struktury.

•

Plan pielęgnacji Przewiduje się w nim wymagania stawiane
pielęgnacji systemu, jej koszty I niezbędne nakłady

•

Plan rozwoju umiejętności Opisuje się w nim, jak będą wzrastały
umiejętności i doświadczenie personelu

Planowanie przedsięwzięcia

Ogólny plan projektu

•

Plan jest to zbiór:

–

Zasobów dostępnych dla projektu;

–

Podziału zadań;

–

Czasu przeznaczony na poszczególne etapy.

–

Czasu przeznaczony na poszczególne etapy.

Szczegółowy plan projektu

•

Wprowadzenie, w którym krótko opisuje się cele przedsięwzięcia i ograniczenia (np. budżet,
czas itd.)

•

Organizacja przedsięwzięcia, w której opisuje się sposób organizacji zespołu wytwórczego,
osoby i ich funkcje w zespole.

•

Analiza zagrożeń, w której opisuje się zagrożenia przedsięwzięcia, prawdopodobieństwo ich
wystąpienia i zaproponowane strategie ich zmniejszenia.

•

Wymagania stawiane zasobom sprzętowym i programowym, w których opisuje się sprzęt i
pomocnicze oprogramowanie niezbędne do prowadzenia tworzenia.

•

Podział pracy, w którym opisuje się podział przedsięwzięcia na czynności oraz identyfikuje

•

Podział pracy, w którym opisuje się podział przedsięwzięcia na czynności oraz identyfikuje
etapy oraz produkty związane z każdą czynnością.

•

Harmonogram przedsięwzięcia, w którym opisuje się zależności między czynnościami,
oszacowanie czasu potrzebnego na dojście do etapów oraz przydział osób do poszczególnych
czynności.

•

Mechanizmy monitorowania i składania raportów, gdzie opisuje się raporty menedżerskie,
które należy opracować, terminy ich dostarczenia i stosowane mechanizmy monitorowania
przedsięwzięcia.

Etapy i produkty

•

Menedżerowie potrzebują informacji. Bez tej informacji nie
można ocenić postępów, oszacować kosztów ani skorygować
harmonogramu.

•

Planując przedsięwzięcie, należy ustalić etapy.

•

Etap oznacza ukończenie pewnej czynności procesu

•

Etap oznacza ukończenie pewnej czynności procesu
tworzenia oprogramowania. Każdy etap powinien wiązać się
z jakimś formalnym rezultatem, na przykład raportem, który
można przedstawić do zatwierdzania

Tworzenie harmonogramu przedsięwzięcia

•

Tworzenie harmonogramu przedsięwzięcia jest trudnym zadaniem dla
zarządzających programowaniem. Szacowanie harmonogramu jest
jeszcze bardzie skomplikowane wskutek tego, że w rozmaitych
przedsięwzięciach użyto różnych metod projektowania i języków
implementacji.

•

Jeśli przedsięwzięcie jest skomplikowane technologicznie, to wstępne
oszacowania niemal na pewno będą optymistyczne nawet wówczas,

oszacowania niemal na pewno będą optymistyczne nawet wówczas,
gdy menedżerowie próbowali przewidzieć wszystkie ewentualności.

•

Tworzenie harmonogramu przedsięwzięcia obejmuje dzielenie
całkowitego nakładu pracy na oddzielne czynności i kalkulowanie czasu
wymaganego na ich ukończenie.

•

Niektóre czynności mogą być prowadzone równocześnie. Autor
harmonogramu musi skoordynować te jednoczesne czynności i
zorganizować prace tak, aby optymalnie wykorzystywać siłę roboczą.
Musi uniknąć sytuacji, w której cale przedsięwzięcie jest opóźnione z
powodu nieukończenia poważnego zadania.

Tworzenie harmonogramu przedsięwzięcia

Harmonogram

Wykresy paskowe i sieci działań

•

Wykresy paskowe i sieci działań to notacje graficzne stosowane
do przedstawiania harmonogramów przedsięwzięcia.

•

Na wykresie paskowym obrazuje się, kto odpowiada za każdą
czynność oraz kiedy ta czynność ma się rozpocząć i skończyć.

•

Za pomocą sieci działań zapisuje się zależności między różnymi
czynnościami składającymi się na przedsięwzięcie.

czynnościami składającymi się na przedsięwzięcie.

•

Wykresy paskowe i sieci działań mogą być przygotowywane
automatycznie przez narzędzia wspomagające zarządzanie na
podstawie zawartości bazy danych przedsięwzięcia.

Harmonogram

Wykresy paskowe i sieci działań

Harmonogram

Ścieżka krytyczna

Harmonogram

•

Opóźnienia czynności, które nie leżą na
ścieżce krytycznej, me powodują jednak
poślizgu całego harmonogramu. Dopóki
opóźnienia nie przedłużą tych czynności do

opóźnienia nie przedłużą tych czynności do
tego stopnia, że ich łączny czas przekroczy
ścieżkę krytyczną, dopóty harmonogram
przedsięwzięcia nie ulegnie zmianie.

Wykres paskowy

Przydział osób do przedsięwzięcia

Przydział osób do przedsięwzięcia

Zarządzanie zagrożeniami

•

Przewidywanie zagrożeń, czyli przewidywanie zdarzeń, które
mogą mieć wpływ na harmonogram przedsięwzięcia lub jakość
budowanego oprogramowania, oraz podejmowanie działań w
celu uniknięcia tych zagrożeń.

•

Wyniki analizy zagrożeń powinny być udokumentowane w planie

•

Wyniki analizy zagrożeń powinny być udokumentowane w planie
przedsięwzięcia wraz z analizą konsekwencji wystąpienia
każdego zagrożenia.

•

W uproszczeniu można przyjąć, że zagrożenie jest
prawdopodobieństwem wystąpienia pewnych niesprzyjających
okoliczności.

Zarządzanie zagrożeniami- przykładowy

podział

•

Zagrożenia przedsięwzięcia mają wpływ na
zasoby i harmonogram przedsięwzięcia.

•

Zagrożenia produktu mają wpływ na jakość i
efektywność budowanego oprogramowania.

efektywność budowanego oprogramowania.

•

Zagrożenia przedsiębiorstwa mają wpływ na
przedsiębiorstwo budujące bądź zaopatrujące
się w oprogramowanie.

Zagrożenia w wytwarzaniu oprogramowania

Zarządzanie zagrożeniami

•

Identyfikacja zagrożeń.

–

Identyfikuje się możliwe zagrożenia przedsięwzięcia, produktu i
przedsiębiorstwa.

•

Analiza zagrożeń.

–

Ocenia się prawdopodobieństwo i konsekwencje tych
zagrożeń.

zagrożeń.

•

Planowanie przeciwdziałania zagrożeniom.

–

Opracowuje się plany radzenia sobie z tymi zagrożeniami przez
ich unikanie lub zmniejszanie ich następstw.

•

Monitorowanie zagrożeń.

–

Ustawicznie ocenia się zagrożenia i koryguje piany ich
łagodzenia w miarę napływu coraz lepszych informacji o tych
zagrożeniach.

Zarządzanie procesem określania zagrożeń

Identyfikacja zagrożeń

•

Zagrożenia technologiczne, które wynikają z technologii oprogramowaniai
sprzętu, użytych do tworzenia części systemu.

•

Zagrożenia ze strony ludzi, które są związane z członkami zespołu
wytwórczego.

•

Zagrożenia organizacyjne, które wynikają ze środowiska organizacyjnego,
w którym jest tworzone oprogramowanie.

•

Zagrożenia narzędziowe, które są powodowane przez narzędzia CASE i

•

Zagrożenia narzędziowe, które są powodowane przez narzędzia CASE i
inne oprogramowanie wspomagające budowanie systemu.

•

Zagrożenia wymagań, które wynikają ze zmian wymagań użytkownika i
procesu zarządzania zmianami wymagań.

•

Zagrożenia szacowania, które są związane z menedżerskimi
oszacowaniami charakterystyk systemu i zasobów niezbędnych do
zbudowania systemu.

Identyfikacja zagrożeń

Analiza zagrożeń

•

Prawdopodobieństwo zagrożenia może być
ocenione na bardzo małe (< 10%), małe (10 ÷
25%), średnie (25 ÷ 50%), duże (50 ÷ 75%) lub
bardzo duże (> 75%).

bardzo duże (> 75%).

•

Konsekwencje zagrożenia mogą być ocenione
jako katastroficzne, poważne, znośne lub
nieistotne.

Analiza zagrożeń

Planowanie przeciwdziałania zagrożeniom

•

Strategie unikania. Ich zastosowanie prowadzi
do zmniejszenia prawdopodobieństwa
wystąpienia zagrożenia.

•

Strategie minimalizacji. Ich zastosowanie

•

Strategie minimalizacji. Ich zastosowanie
prowadzi do zmniejszenia konsekwencji
zagrożenia.

•

Plany awaryjne. Ich zastosowanie polega na
przygotowaniu się i opracowaniu strategii
przeciwdziałania na wypadek najgorszego.

Monitorowanie zagrożeń

Czynniki ryzyka

Wymagania stawiane

oprogramowaniu

oprogramowaniu

Wymagania stawiane

oprogramowaniu

•

W przemyśle informatycznym pojęcie
wymaganie nie jest stosowane
konsekwentnie. Niekiedy wymaganie jest
postrzegane jako zapisane na wysokim

postrzegane jako zapisane na wysokim
poziomie, abstrakcyjne określenie usług, które
system powinien oferować, albo ograniczenie
działania systemu. Niektórzy określają
wymaganie jako szczegółową, matematycznie
formalną definicję funkcji systemu.

Wymagania stawiane

oprogramowaniu

•

Wymagania użytkownika to wyrażenia w języku naturalnym oraz
diagramy o usługach oczekiwanych od systemu oraz o ograniczeniach, w
których system ma działać.

•

Wymagania systemowe szczegółowo ustalają usługi systemu i
ograniczenia. Dokumentacja wymagań systemowych, zwana czasem
specyfikacją funkcjonalną, powinna być precyzyjna. Może służyć za
kontrakt między nabywcą systemu a wytwórcą oprogramowania.

kontrakt między nabywcą systemu a wytwórcą oprogramowania.

•

Specyfikacja projektu oprogramowania jest abstrakcyjnym opisem
projektu oprogramowania, który jest podstawą bardziej szczegółowego
projektu i implementacji. Ta specyfikacja dodaje nowe informacje do
specyfikacji wymagań systemowych.

Specyfikacja wymagań systemowych-

przykład

•

Oprogramowanie musi zapewnić mechanizmy reprezentowania i
dostępu do plików zewnętrznych tworzonych przez inne narzędzia

•

Użytkownik powinien mieć możliwość definiowania typów plików
zewnętrznych

•

Każdy typ pliku zewnętrznego może mieć przypisane narzędzie do
obróbki takich plików

•

Każdy typ pliku zewnętrznego może być przedstawiony w postaci

•

Każdy typ pliku zewnętrznego może być przedstawiony w postaci
charakterystycznej ikony na ekranie użytkownika

•

Należy zapewnić udogodnienia do definiowania przez użytkownika
ikon odpowiadających typom plików zewnętrznych

•

Gdy użytkownik wybierze ikonę powiązaną z plikiem zewnętrznym,
następuje zastosowanie do tego pliku narzędzia skojarzonego z
typem tego pliku

Do kogo adresowane

Wymagania funkcjonalne, niefunkcjonalne i

dziedzinowe

•

Wymagania funkcjonalne są stwierdzeniami, jakie usługi ma oferować
system, jak ma reagować na określone dane wejściowe oraz jak ma się
zachowywać w określonych sytuacjach. W niektórych wypadkach
wymagania funkcjonalne określają, czego system nie powinien robić.

•

Wymagania niefunkcjonalne to ograniczenia usług i funkcji systemu.
Obejmują ograniczenia czasowe, ograniczenia dotyczące procesu
tworzenia, standardy itd.

tworzenia, standardy itd.

•

Wymagania dziedzinowe pochodzą z dziedziny zastosowania systemu i
odzwierciedlają jej charakterystykę. Mogą być funkcjonalne lub
niefunkcjonalne.

Wymagania funkcjonalne - przykład

•

Użytkownik będzie mógł przeszukać zbiór
wszystkich baz danych lub wybrać tylko ich
podzbiór.

•

System udostępni odpowiednie narzędzia do
oglądania, aby użytkownik mógł czytać

oglądania, aby użytkownik mógł czytać
dokumenty z magazynu.

•

Każde zamówienie będzie oznaczone
unikatowym identyfikatorem, który będzie
można skopiować do pamięci trwałej konta
użytkownika.

Wymagania niefunkcjonalne - przykład

Wymagania niefunkcjonalne - przykład

•

Szybkość

–

Liczba przetworzonych transakcji na
sekundę

–

Czas reakcji na zdarzenie wywołane
przez użytkownika

–

Czas odświeżenia ekranu

•

Rozmiar

–

Kilobajty

–

Liczba układów pamięci RAM

•

Niezawodność

–

Średni czas bez awarii

–

Prawdopodobieństwo niedostępności

–

Częstość błędów

–

Dostępność

•

Solidność

–

Czas uruchomienia po awarii

–

Ułamek zdarzeń powodujących awarie

–

Liczba układów pamięci RAM

•

Łatwość użycia

–

Czas szkolenia

–

Liczba okien pomocy

–

Ułamek zdarzeń powodujących awarie

–

Prawdopodobieństwo zniszczenia
danych po awarii

•

Przenośność

–

Procent poleceń zależnych od platformy

–

Liczba docelowych systemów

Wymagania dziedzinowe- przykład

•

Wymagania stawiane systemowi biblioteki jako przykłady
wymagań dziedzinowych:

•

Wszystkie bazy danych powinny być dostępne przez jednolity
interfejs użytkownika, którego podstawą jest ogólnie znany
standard.

standard.

•

Ze względu na ochronę praw autorskich niektóre dokumenty
należy skasować natychmiast po ich otrzymaniu. Zależnie od
wymagań użytkownika, dokumenty te będą drukowane lokalnie
na serwerze systemowym i przekazywane do rąk czytelnika albo
wysyłane na drukarkę sieciową.

Wymagania użytkownika

•

Wymagania użytkownika stawiane systemowi powinny określać wymagania
funkcjonalne i niefunkcjonalne tak, aby były zrozumiale dla użytkowników systemu

•

Wymagania użytkownika nie powinny być zatem definiowane za pomocą modelu
implementacyjnego. Należy je zapisywać w języku naturalnym, używając
formularzy i prostych intuicyjnych diagramów.

•

Problemy

–

Brak jasności. Czasem trudno jest wyrażać się w języku naturalnym precyzyjnie i

–

Brak jasności. Czasem trudno jest wyrażać się w języku naturalnym precyzyjnie i
jednoznacznie bez czynienia dokumentów gadatliwymi i nieczytelnymi.

–

Sprzeczność wymagań. Trudno jest jasno rozgraniczyć wymagania funkcjonalne,
wymagania niefunkcjonalne, cele systemu i elementy projektu.

–

Łączenie wymagań. Kilka różnych wymagań może być zapisanych razem jako jedno
wymaganie.

Wymagania systemowe

•

Wymagania systemowe są bardziej szczegółowymi opisami
wymagań użytkownika. Mogą być podstawą kontraktu na
implementację systemu, powinny być zatem pełną i
niesprzeczną specyfikacją całego systemu. Są traktowane przez
inżynierów oprogramowania jako punkt wyjścia do
projektowania systemu.

•

Wymagania systemowe powinny określać, co system ma robić, a

•

Wymagania systemowe powinny określać, co system ma robić, a
nie, jak powinien być zaimplementowany.

•

Poziom szczegółowości niezbędny do wyspecyfikowania systemu
w pełni jest tak wysoki, że jest niemal niemożliwe całkowite
pominięcie informacji projektowych.

Wymagania systemowe – język naturalny

•

Rozumienie języka naturalnego zależy od tego, czy czytelnicy i autorzy
specyfikacji używają tych samych słów do oznaczenia tych samych pojęć
(symbole przy ruchomych schodach: „buty trzeba założyć” i ‚„psy trzeba
nieść”)

•

Specyfikacje wymagań w języku naturalnym są zbyt elastyczne. Tę samą
rzecz można wyrazić na kilka zupełnie różnych sposobów.

•

Nie ma łatwego sposobu podziału wymagań w języku naturalnym na

•

Nie ma łatwego sposobu podziału wymagań w języku naturalnym na
moduły. Znalezienie wszystkich powiązanych wymagań może być trudne.
Poszukiwanie konsekwencji zmian może wymagać przejrzenia każdego
wymagania, a nie jedynie grupy powiązanych wymagań.

Notacje specyfikacji wymagań

•

Strukturalny język To podejście polega na definiowaniu
standardowych formularzy i szablonów do wyrażania specyfikacji
wymagań

•

Języki opisu projektu oprogramowania W tym podejściu używa się
języka podobnego do języka projektu programowania, ale z bardziej
abstrakcyjnymi elementami do specyfikowania wymagań poprzez

abstrakcyjnymi elementami do specyfikowania wymagań poprzez
model operacyjny sytemu

•

Notacje graficzne Do definiowania wymagań funkcjonalnych
stawianych systemowi używa się języka graficznego z tekstowymi
dopiskami.

•

Specyfikacje matematyczne- są to notacje oparte na pojęciach
matematycznych, takich jak skończone maszyny stanowe lub zbiory.

20-11

Dokumentacja wymagań stawianych

oprogramowaniu

•

Powinna określać zachowanie systemu jedynie z zewnątrz.

•

Powinna określać ograniczenia implementacji.

•

Powinno być łatwo ją zmieniać.

•

Powinna być informatorem dla konserwatorów systemu.

•

Powinna obejmować przewidywania przyszłego cyklu życia

•

Powinna obejmować przewidywania przyszłego cyklu życia
systemu.

•

Powinna charakteryzować akceptowalne reakcje na niepożądane
zdarzenia.

Struktura dokumentacji wymagań

•

Przedmowa

–

Należy się w niej określić, dla jakich czytelników jest ten dokument, oraz
opisać historię jego wersji wraz z uzasadnieniem tworzenia każdej nowej
wersji i podsumowaniem zmian wprowadzonych w każdej wersji

•

Wstęp

–

Należy w nim wyjaśnić, dlaczego ten system jest potrzebny. Należy krótko
opisać funkcje systemu i sposób jego współpracy z innymi systemami. Należy
również przedstawić, jak system przystaje do ogólnych celów gospodarczych i

również przedstawić, jak system przystaje do ogólnych celów gospodarczych i
strategicznych firmy, która go kupuje

•

Słownik

–

Należy tu zdefiniować techniczne pojęcia używane w dokumencie. Nie należy
robić żadnych założeń o doświadczeniach i wiedzy czytelnika

Struktura dokumentacji wymagań

•

Definicja wymagań użytkownika

–

W tym punkcie należy opisać usługi dostarczane użytkownikowi i wymagania
niefunkcjonalne systemu. W tym opisie można posłużyć się językiem
naturalnym, diagramami lub inną notacją zrozumiałą dla klientów. Powinno się
także określić obowiązujące standardy dotyczące produktu i procesu

•

Architektura systemu

–

W tym rozdziale należy przedstawić ogólny przegląd spodziewanej
architektury systemu, z której wynika podział funkcji między modułami

architektury systemu, z której wynika podział funkcji między modułami
systemu. Należy wyróżnić ponownie użyte komponenty architektoniczne

•

Specyfikacja wymagań systemowych

–

Tu należy bardziej szczegółowo opisać wymagania funkcjonalne i
niefunkcjonalne. Jeśli jest to konieczne, to można uszczegółowić także
wymagania niefunkcjonalne, np. zdefiniować interfejsy do innych systemów

Struktura dokumentacji wymagań

•

Modele systemu

–

Tu należy ustalić jeden lub więcej modeli systemu, w
których odzwierciedlono związki między jego
komponentami oraz system i jego środowisko. Mogą
to być modele obiektowe, modele przepływu danych

to być modele obiektowe, modele przepływu danych
lub znaczeniowe modele danych

•

Ewolucja systemu

–

Powinno się tu opisać główne założenia systemu i
przewidywane modyfikacje, które nastąpią w wyniku
ewolucji sprzętu, zmiany potrzeb użytkowników itd.

Struktura dokumentacji wymagań

•

Dodatki

–

Należy w nich przedstawić szczegółową, specyficzną informację
związaną z budowanym programem użytkowym. Przykładami
dodatków są opisy sprzętu i opisy bazy danych. W wymaganiach
sprzętowych definiuje się konfiguracje minimalną i optymalną. W
wymaganiach bazy danych określa się logiczną organizację danych

wymaganiach bazy danych określa się logiczną organizację danych
używanych przez system i związki między tymi danymi

•

Skorowidz

–

Do dokumentu można dołączyć kilka skorowidzów. Oprócz
skorowidza alfabetycznego mogą to być skorowidz diagramów,
skorowidz funkcji itd.

Proces

inżynierii wymagań

inżynierii wymagań

Proces

inżynierii wymagań

•

Inżynieria wymagań to proces, który obejmuje
wszystkie czynności niezbędne do
opracowania i aktualizacji dokumentacji
wymagań systemowych. Istnieją cztery ogólne

wymagań systemowych. Istnieją cztery ogólne
czynności wysokiego poziomu w procesie
inżynierii wymagań. Są nimi: studium
wykonalności, określenie i analizowanie
wymagań, specyfikowanie i dokumentowanie
wymagań oraz zatwierdzanie wymagań.

Proces

inżynierii wymagań

Studium wykonalności

•

Czy system przyczyni się do realizacji ogólnych
celów przedsiębiorstwa?

•

Czy system może być zaimplementowany z
użyciem dostępnych technologii, w ramach

użyciem dostępnych technologii, w ramach
ustalonego budżetu i ograniczeń czasowych?

•

Czy system może być zintegrowany z
istniejącymi systemami, które już
zainstalowano?

Pytania, które mogą być zadane w procesie

inżynierii wymagań

•

Jak firma poradziłaby sobie, jeśli system nie byłby
zaimplementowany?

•

Jakie problemy występują w obecnie przyjętych procesach i jak
nowy system ma pomóc w ich eliminacji?

•

Jaki byłby bezpośredni wkład systemu w osiąganie celów
gospodarczych?

gospodarczych?

•

Czy można przekazywać informacje do i z innych systemów
przedsiębiorstwa?

•

Czy system wymaga technologii, których wcześniej w firmie nie
stosowano?

•

Co system musi wspomagać, a czego nie musi?

Określanie i analizowanie wymagań

•

Po wstępnych studiach wykonalności następną fazą inżynierii wymagań
jest określanie i analizowanie wymagań. W trakcie tej czynności techniczni
budowniczowie oprogramowania pracują z klientami i użytkownikami
systemu nad badaniem dziedziny zastosowania i usług, które system ma
oferować, pożądanej efektywności, ograniczeń sprzętowych itd.

•

W określaniu i analizowaniu wymagań mogą wziąć udział osoby z różnych
stanowisk w firmie. Pojęcie uczestnik odnosi się do każdego, kto powinien
mieć pewien pośredni lub bezpośredni wpływ na wymagania systemowe.

mieć pewien pośredni lub bezpośredni wpływ na wymagania systemowe.
Uczestnikami są użytkownicy, którzy będą pracować z systemem, oraz
wszystkie osoby w przedsiębiorstwie, na których system będzie miał
wpływ: inżynierowie budujący lub pielęgnujący inne powiązane systemy,
menedżerowie przedsiębiorstwa, eksperci z danych dziedzin;
reprezentanci związków zawodowych także mogą być uczestnikami
systemu.

Trudności w analizie wymagań

•

Uczestnicy często nie wiedzą, czego tak naprawdę oczekują od systemu
komputerowego, być może poza bardzo ogólnymi stwierdzeniami. Wyartykułowanie ich
prawdziwych oczekiwań wobec systemu może być dla nich zbyt trudne. Mogą stawiać
nierealne żądania, ponieważ nie są w stanie ocenić ich kosztu.

•

Uczestnicy systemu w naturalny sposób wyrażają wymagania za pomocą własnych pojęć
z wykorzystaniem niejawnej informacji o ich własnej pracy. Inżynierowie wymagań nie
mający doświadczenia w dziedzinie klienta, muszą umieć zrozumieć te wymagania.

•

Różni uczestnicy mogą stawiać różne wymagania i mogą je wyrażać na różne sposoby.
Inżynierowie wymagań muszą odkryć wszystkie potencjalne źródła wymagań i

Inżynierowie wymagań muszą odkryć wszystkie potencjalne źródła wymagań i
rozpoznać podobieństwa i sprzeczności.

•

Czynniki polityczne mogą mieć wpływ na system. Mogą pochodzić od menedżerów,
którzy żądają konkretnych wymagań systemowych, które umożliwią zwiększenie ich
wpływów w przedsiębiorstwie.

•

Środowisko ekonomiczne i gospodarcze, w którym prowadzi się analizę, jest
dynamiczne. Nieuchronnie zmienia się w trakcie procesu analizy. Znaczenie
poszczególnych wymagań może się zatem zmienić. Mogą wyłonić się nowe wymagania
pochodzące od nowych uczestników, z którymi wcześniej nie rozmawiano

Proces określania i analizowania wymagań

•

Rozpoznanie dziedziny. Analitycy muszą zrozumieć dziedzinę zastosowania. Jeśli
potrzebny jest na przykład system dla supermarketu, to analityk musi dowiedzieć
się, jak działa supermarket.

•

Zbieranie wymagań. Jest to proces interakcji z uczestnikami systemu, którego
celem jest wyjawienie ich wymagań. W trakcie tych badań analityk coraz lepiej
rozumie dziedzinę zastosowania.

•

Klasyfikacja. Ta czynność polega na podzieleniu bezładnego zbioru wymagań na
spoiste grupy.

spoiste grupy.

•

Usuwanie sprzeczności. Wymagania podane przez wielu uczestników będą
nieuchronnie zawierać sprzeczności. Ta czynność polega na znalezieniu i
wyeliminowaniu tych sprzeczności.

•

Nadawanie priorytetów. W każdym zbiorze wymagań będą bardziej i mniej
ważne. Ta czynność polega na interakcji z uczestnikami w celu wskazania
najważniejszych wymagań.

•

Sprawdzanie wymagań. Sprawdza się wymagania, aby stwierdzić, czy są pełne,
spójne i zgodne z tym, czego uczestnicy tak naprawdę chcą od systemu.

Proces określania i analizowania wymagań

Określanie oparte na punktach widzenia –

przykład bankomat

•

Obecni klienci banku, którzy korzystają z usług systemu.

•

Przedstawiciele innych banków, którzy podpisują umowy o wzajemnym udostępnieniu
bankomatów klientom banków.

•

Dyrektorzy oddziałów banków, którzy odbierają informacje o zarządzaniu systemem.

•

Pracownicy obsługi klienta w oddziałach, którzy biorą udział w codziennym działaniu
systemu, przyjmują reklamacje klientów itd.

•

Administratorzy baz danych, którzy odpowiadają za integrację systemu z bazą danych
klientów banku.

•

Osoby odpowiedzialne za bezpieczeństwo w banku, które mają obowiązek zapewnić, aby

•

Osoby odpowiedzialne za bezpieczeństwo w banku, które mają obowiązek zapewnić, aby
bezpieczeństwo systemu nie było w jakikolwiek sposób zagrożone.

•

Dział marketingu banku, który prawdopodobnie będzie chciał wykorzystać system do celów
marketingowych.

•

Inżynierowie pielęgnacji sprzętu i oprogramowania, którzy odpowiadają za pielęgnację i
unowocześnianie sprzętu i oprogramowania.

Metoda VORD (Viewpoint-Oriented

Requirements Definition)

•

Identyfikacja punktów widzenia, która polega na znajdowaniu punktów
widzenia, których reprezentanci korzystają z usług systemu, oraz na
wyszukiwaniu szczególnych usług oferowanych reprezentantom
konkretnych punktów widzenia.

•

Strukturalizacja punktów widzenia, która polega na grupowaniu
podobnych punktów widzenia w hierarchie. Wspólne usługi są oferowane
reprezentantom punktów widzenia położonych wyżej w hierarchii i są

reprezentantom punktów widzenia położonych wyżej w hierarchii i są
dziedziczone przez niżej położone punkty widzenia.

•

Dokumentacja punktów widzenia, która polega na udoskonalaniu opisu
znalezionych punktów widzenia i usług.

•

Przyporządkowanie punktów widzenia do systemu, które polega na
znalezieniu obiektów w projekcie obiektowym za pomocą związanej z
punktami widzenia informacji o usługach.

Określanie punktów widzenia i zadań

Scenariusze

•

Ludzie zwykle wolą przykłady wzięte z życia
niż abstrakcyjne opisy. Łatwo mogą zrozumieć
i skomentować scenariusz swojej interakcji z
systemem oprogramowania. Inżynierowie

systemem oprogramowania. Inżynierowie
wymagań mogą skorzystać z informacji
zebranych w trakcie tych dyskusji do
formułowania rzeczywistych wymagań
systemowych.

Scenariusze

Scenariusze

•

Opis stanu systemu na początku scenariusza.

•

Opis normalnego następstwa zdarzeń
scenariusza.

•

Opis tego, co może pójść źle, i jak to jest

•

Opis tego, co może pójść źle, i jak to jest
obsługiwane.

•

Informacje o innych czynnościach, które
można wykonywać w tym samym czasie.

•

Opis stanu systemu po zakończeniu
scenariusza.

Scenariusz - przykład

Etnografia

•

Systemy oprogramowania nie istnieją w izolacji. Są użytkowane
w środowisku społecznym i organizacyjnym. Wymagania
stawiane systemowi oprogramowania mogą więc wynikać lub
być ograniczone przez to otoczenie. Spełnienie tych wymagań
społecznych i organizacyjnych jest często podstawowe dla
sukcesu systemu. Jedną z przyczyn tworzenia wielu systemów

sukcesu systemu. Jedną z przyczyn tworzenia wielu systemów
oprogramowania, które nie są używane, jest niedostateczne
uwzględnienie ważności wymagań tego rodzaju przez twórców
tych systemów.

Zatwierdzanie wymagań

•

Zatwierdzanie wymagań polega na wykazaniu, że wymagania
naprawdę definiują system, którego chce użytkownik Ma wiele
cech wspólnych z analizą, ponieważ oznacza poszukiwanie
kłopotów z wymaganiami. Są jednak odrębnymi procesami,
ponieważ zatwierdzanie dotyczy kompletnej propozycji
dokumentacji wymagań, podczas gdy analiza to praca z
niekompletnymi wymaganiami.

niekompletnymi wymaganiami.

•

Zatwierdzanie wymagań jest istotne, ponieważ błędy w
dokumentacji wymagań mogą przyczynić się do poważnych
kosztów powtarzania prac po sukcesywnym wykrywaniu tych
błędów w trakcie tworzenia lub nawet po rozpoczęciu
korzystania z systemu.

Sprawdzanie wymagań

•

Sprawdzenia ważności. Użytkownik może być przekonany, że system powinien
spełniać pewne funkcje. Dalsze rozważania i analiza mogą doprowadzić do
znalezienia dodatkowych albo innych wymaganych funkcji.

•

Sprawdzenie niesprzeczności. Wymagania zapisane w dokumentacji nie
powinny być sprzeczne. To znaczy, że nie powinno być sprzecznych ograniczeń
lub różnych opisów tej samej funkcji systemu.

•

Sprawdzenie kompletności. Dokumentacja wymagań powinna zawierać
wymagania, w których zdefiniowano wszystkie funkcje i ograniczenia

wymagania, w których zdefiniowano wszystkie funkcje i ograniczenia
zamierzone przez użytkownika systemu.

•

Sprawdzenie realności. Znając obecną wiedzę techniczną, należy sprawdzić,
czy wymagania mogą być naprawdę zaimplementowane. Te sprawdzenia
powinny uwzględniać również budżet i harmonogram budowania systemu.

•

Możliwość weryfikacji. Aby uniknąć późniejszych sporów między klientem a
zleceniobiorcą, wymagania systemowe zawsze powinny być napisane tak, aby
można było je weryfikować. To oznacza, że można opracować zestaw
sprawdzianów, który wykaże, że dostarczony system spełnia te wymagania.

Zatwierdzanie wymagań

•

Przeglądy wymagań. Zespół recenzentów systematycznie analizuje wymagania.

•

Prototypowanie. W tym podejściu do zatwierdzania przedstawia się
użytkownikom i klientom wykonywalny model systemu. Mogą oni z nim
eksperymentować, aby sprawdzić, czy spełnia ich prawdziwe potrzeby.

•

Generowanie testów. Idealnie byłoby, aby wymagania dało się testować. Jeśli
częścią procesu zatwierdzania jest opracowywanie testów dla wymagań, to łatwiej
jest znajdować błędy w wymaganiach. Jeśli trudno jest albo w ogóle nie da się
zaprojektować testów, to można wywnioskować, że trudno będzie

zaprojektować testów, to można wywnioskować, że trudno będzie
zaimplementować wymagania i należy je ponownie rozważyć.

•

Zautomatyzowane sprawdzanie niesprzeczności. Jeśli wymagania wyrażono w
modelu systemu za pomocą strukturalnej lub formalnej notacji, to narzędzia CASE
mogą sprawdzić niesprzeczność modelu. Analizator wymagań generuje raport z
listą wykrytych sprzeczności.

Zarządzanie wymaganiami

•

Z wielkich systemów korzysta zwykle bardzo urozmaicona społeczność
użytkowników. Różni użytkownicy stawiają różne wymagania i przypisują
im inne priorytety. Może to powodować konflikty i sprzeczności.

•

Ludzie, którzy płacą za system i jego użytkownicy to zwykle różni klienci.
Klienci systemu formułują wymagania wynikające z ograniczeń
organizacyjnych i budżetowych. Te wymagania mogą być w konflikcie z
wymaganiami użytkowników.
Otoczenie technologiczne i gospodarcze systemu zmienia się. Te zmiany

•

Otoczenie technologiczne i gospodarcze systemu zmienia się. Te zmiany
muszą być odzwierciedlone w samym systemie. Może pojawić się nowy
sprzęt lub potrzeba sprzęgnięcia systemu z innymi systemami. Mogą
zmienić się priorytety gospodarcze, co powoduje odpowiednie zmiany w
oczekiwanym wspomaganiu systemu. Mogą wyłonić się nowe prawa,
które wymagają zaimplementowania w systemie.

Zarządzanie wymaganiami

•

Wymagania zmienne, które zmieniają się na skutek zmian środowiska, zmienne w
którym działa firma. W systemie szpitala może się zmienić na przykład
finansowanie opieki nad chorym, co może powodować konieczność gromadzenia
innych informacji o leczeniu

•

Wymagania pojawiające się, które pojawiają się w trakcie procesu tworzenia
pojawiające się w miarę coraz lepszego rozumienia systemu przez klienta. Proces
projektowania może doprowadzić do odkrycia nowych pojawiających się wymagań

projektowania może doprowadzić do odkrycia nowych pojawiających się wymagań

•

Wymagania wynikowe, które wynikają z wdrożenia systemu komputerowego.
Wprowadzenie takiego systemu może doprowadzić do zmiany procesów
przedsiębiorstwa i do wskazania nowych sposobów pracy, które prowadzą do
postawienia nowych wymagań

•

Wymagania zgodności, które zależą od konkretnych systemów lub procesów
gospodarczych wewnątrz firmy. Gdy wymagania te zmieniają się, wymagania
zgodności wobec kupionego lub zbudowanego systemu mogą również się zmieniać

Podsumowanie

•

Proces inżynierii wymagań obejmuje studium wykonalności, określanie i
analizowanie wymagań, specyfikowanie wymagań, zatwierdzanie
wymagań oraz zarządzanie wymaganiami.

•

Analizowanie wymagań to proces iteracyjny, który obejmuje rozpoznanie
dziedziny, zbieranie wymagań, klasyfikację, strukturalizację, nadawanie
priorytetów i zatwierdzanie.

•

Różni użytkownicy systemu mogą stawiać różne wymagania. Wszystkie

•

Różni użytkownicy systemu mogą stawiać różne wymagania. Wszystkie
złożone systemy należy więc analizować z kilku punktów widzenia. Punkty
widzenia odpowiadają źródłom lub przeznaczeniom danych różnym
reprezentacjom systemu albo bytom spoza systemu, które korzystają z
jego usług.

•

Czynniki społeczne i organizacyjne mają silny wpływ na wymagania
systemowe i od nich głównie zależy, czy system będzie faktycznie używany,
czy nie.

Podsumowanie

•

Zatwierdzanie wymagań to proces sprawdzenia wymagań pod względem
ważności, niesprzeczności, kompletności, realności i zdatności do
weryfikacji. Przeglądy wymagań prototypowanie są podstawowymi
metodami używanymi do zatwierdzania wymagań.

•

Zmiany gospodarcze, organizacyjne i technologiczne nieuchronnie
prowadzą do zmian wymagań stawianych systemowi oprogramowania.
Zarządzanie wymaganiami to proces kierowania i panowania nad tymi

Zarządzanie wymaganiami to proces kierowania i panowania nad tymi
zmianami.

•

Proces zarządzania wymaganiami obejmuje planowanie, w trakcie którego
specyfikuje się procedury zarządzania wymaganiami, i zarządzanie
zmianami, które polega na analizowaniu zmian i szacowaniu ich wpływu.

Modele systemu

Modele systemu

•

Wymagania użytkownika należy spisać w języku naturalnym, ponieważ
muszą być zrozumiale dla osób, które nie są ekspertami od technologii.
Bardziej szczegółowe wymagania systemowe mogą być zapisane w
bardziej techniczny sposób. Jednym z szeroko stosowanych sposobów jest
dokumentowanie systemu za pomocą zbioru jego modeli. Są one
graficznymi prezentacjami, w których przedstawia się problem do
rozwiązania i system do zbudowania. Dzięki użyciu graficznych środków
wyrazu modele są zwykle bardziej zrozumiale niż szczegółowy opis

wyrazu modele są zwykle bardziej zrozumiale niż szczegółowy opis
wymagań systemowych w języku naturalnym. Są też ważnym pomostem
między procesami analizy i projektowania. W procesie analizowania
modele mogą służyć do wypracowania lepszego zrozumienia istniejącego
systemu, który ma być zastąpiony lub ulepszony. Mogą też służyć do
wyspecyfikowania pożądanego systemu.

Różne punkty widzenia

•

Zewnętrzny, przy którym modeluje się
kontekst lub środowisko systemu

•

Zachowania, przy którym modeluje się
zachowanie systemu.

zachowanie systemu.

•

Strukturalny, przy którym modeluje się
architekturę systemu lub strukturę
przetwarzanych danych.

Niedoskonałości metody strukturalnej

•

Niewystarczająco wspomagają rozpoznawanie i modelowanie
niefunkcjonalnych wymagań systemowych.

•

Są ogólne pod tym względem, że zwykle nie zawierają wskazówek
pomagających użytkownikom w podjęciu decyzji, czy konkretna metoda
jest odpowiednia dla określonego problemu, czy nie. Często nie obejmują
też porad, jak przystosować wybraną metodę do ustalonego środowiska.

•

Prowadzą zwykle do utworzenia zbyt obszernej dokumentacji. Istota

•

Prowadzą zwykle do utworzenia zbyt obszernej dokumentacji. Istota
wymagań systemowych może być ukryta w masie zapisanych szczegółów.

•

Opracowywane modele są bardzo szczegółowe i użytkownikom trudno j je
zrozumieć. Tacy użytkownicy nie mogą autentycznie sprawdzić realizm
tych modeli.

Różne typy modeli systemu

•

Model przetwarzania danych. Na diagramach przepływu danych obrazuje
się, jak dane są przetwarzane w różnych krokach pracy systemu.

•

Model składania. Na diagramach encja-związek przedstawia się, w jaki
sposób encje systemu są złożone z innych encji.

•

Model architektoniczny. W modelach architektonicznych obrazuje się
zasadnicze podsystemy, z których składa się system.

•

Model klasyfikacyjny. Na diagramach klas obiektów i dziedziczenia
przedstawia się wspólne cechy encji.

•

Model bodziec-reakcja. Na diagramach stanów obrazuje się, w jaki sposób
system reaguje na zdarzenia wewnętrzne i zewnętrzne.

Model kontekstowy

Model kontekstowy – model zakupu

wyposażenia

Modele zachowania

•

Modele zachowania są używane do ogólnego opisywania zachowania
systemu. Dwa typy:

–

Modele przepływów danych, w których opisuje się przetwarzanie danych w
systemie,

–

Modele maszyn stanowych, w których opisuje się reakcje systemu na
zdarzenia.

•

Większość systemów przedsiębiorstw jest głównie sterowana danymi.

•

Większość systemów przedsiębiorstw jest głównie sterowana danymi.
Działanie systemów zależy od danych wejściowych systemu i obejmuje
stosunkowo niewiele przetwarzania zewnętrznych zdarzeń. Model
przepływu danych może zapewnić wszystko, co jest potrzebne do
przedstawienia zachowania takich systemów. Systemy czasu rzeczywistego
są często sterowane zdarzeniami i obejmują minimalną ilość
przetwarzanych danych.

Modele przepływu danych

•

Modele przepływu danych są intuicyjnym sposobem przedstawienia, jak
dane są przetwarzane przez system. Na etapie analizy należy ich użyć do
modelowania przetwarzania danych w istniejącym systemie. Notacje
używane w tych modelach służą do przedstawiania przetwarzania
funkcjonalnego, magazynów danych i przekazywania danych między
funkcjami.

•

Modele przepływu danych są stosowane do pokazania, jak dane
przepływają w sekwencji kroków przetwarzania. Dane podlegają

przepływają w sekwencji kroków przetwarzania. Dane podlegają
przekształceniu w każdym kroku przed przejściem do następnych kroków.
Te kroki lub przekształcenia są funkcjami programu, gdy diagramów
przepływu danych używa się do dokumentowania projektu
oprogramowania. W modelu analitycznym przetwarzanie może być jednak
wykonywane przez ludzi albo komputery.

Modele przepływu danych

•

Modele przepływu danych są bardzo przydatne, ponieważ
śledzenie i dokumentowanie, jak przepływają przez system dane
związane z konkretnym procesem, pomaga analitykom
zrozumieć, co się dzieje. Zaletą diagramów przepływu danych
jest to, że w odróżnieniu od kilku innych notacji są proste i
intuicyjne. Często można je łatwo wytłumaczyć przyszłym

intuicyjne. Często można je łatwo wytłumaczyć przyszłym
użytkownikom systemu, którzy dzięki temu mogą brać udział w
kontrolowaniu analizy.

Modele przepływu danych

•

Modele przepływu danych są stosowane do pokazania, jak dane
przepływają w sekwencji kroków przetwarzania. Dane podlegają
przekształceniu w każdym kroku przed przejściem do następnych
kroków. Te kroki lub przekształcenia są funkcjami programu, gdy
diagramów przepływu danych używa się do dokumentowania
projektu oprogramowania. W modelu analitycznym

projektu oprogramowania. W modelu analitycznym
przetwarzanie może być jednak wykonywane przez ludzi albo
komputery.

Model przepływu danych – obsługa

zamówień

Modele maszyn stanowych

•

Modele maszyn stanowych służą do opisywania zachowania systemu, gdy
reaguje na wewnętrzne lub zewnętrzne zdarzenia. Model maszyny
stanowej zawiera stany i zdarzenia, które powodują przejścia z jednego
stanu do innego. Nie obejmuje przepływu danych w ramach systemu. Ten
rodzaj modelu jest szczególnie przydatny w wypadku systemu czasu
rzeczywistego, ponieważ zwykle są one sterowane przez bodźce
pochodzące ze środowiska. (alarm i detektory)

pochodzące ze środowiska. (alarm i detektory)

•

W modelu maszyny stanowej zakłada się, że w każdej chwili system jest w
jednym z kilku dopuszczalnych stanów. Otrzymany bodziec może
spowodować przejście do innego stanu. System sterujący zaworem
przechodzi na przykład od stanu „Zawór otwarty” do „Zawór zamknięty”
po nadejściu polecenia operatora (bodźca).

Kuchenka mikrofalowa

•

Na następnym diagramie widać model maszyny stanowej prostej
kuchenki mikrofalowej, mającej przyciski do ustawiania mocy i zegara
oraz do włączania systemu. Kuchenki mikrofalowe są znacznie bardziej
złożone niż opisany tu system. Ten model zawiera jednak zasadnicze
elementy tego systemu. Założono, że kolejność czynności w trakcie
używania kuchenki jest następująca:

–

Wybierz poziom mocy (połowa albo pełna).

–

Wybierz poziom mocy (połowa albo pełna).

–

Ustal czas gotowania.

–

Naciśnij przycisk „Początek”; potrawa będzie gotowana przez ustalony
czas.

•

Ze względów bezpieczeństwa kuchenka nie powinna działać przy
otwartych drzwiczkach. Po zakończeniu gotowania odzywa się
brzęczyk. Kuchenka ma bardzo prosty wyświetlacz alfanumeryczny,
który pokazuje rozmaite komunikaty alarmowe i ostrzegawcze.

Kuchenka mikrofalowa - stany

•

Oczekiwanie Kuchenka czeka na dane wejściowe. Wyświetlacz pokazuje aktualną
godzinę

•

Połowa mocy Moc kuchenki ustawiono na 300 watów. Wyświetlacz pokazuje napis

•

Połowa mocy

•

Pełna moc Moc kuchenki ustawiono na 600 watów. Wyświetlacz pokazuje napis

•

Pełna moc”

•

Ustawianie czasu Czas trwania gotowania jest ustawiany na wartość wprowadzoną

•

przez użytkownika. Wyświetlacz pokazuje wybrany czas gotowania i jest aktualizowany

•

przez użytkownika. Wyświetlacz pokazuje wybrany czas gotowania i jest aktualizowany
w miarę wprowadzania danych

•

Niegotowy Kuchenka nie może działać ze względów bezpieczeństwa. Wewnętrzne
światło kuchenki jest włączone. Wyświetlacz pokazuje napis „Niegotowy”

•

Gotowy Kuchenka jest gotowa do działania. Wewnętrzne światło jest wyłączone.
Wyświetlacz pokazuje napis „Gotowy”

•

Działanie Kuchenka działa. Wewnętrzne światło jest włączone. Wyświetlacz odlicza
zmniejszający się czas pozostały do zakończenia gotowania. Po zakończeniu brzęczyk
włącza się na n sekund. Światło kuchenki jest wtedy włączone. Wyświetlacz pokazuje
napis „Gotowanie zakończone” w czasie działania brzęczyka

Kuchenka mikrofalowa - bodźce

•

Połowa mocy Użytkownik nacisnął przycisk „Połowa mocy”

•

Pełna moc Użytkownik nacisnął przycisk „Pełna moc”

•

Stoper Użytkownik nacisnął przycisk „Stoper”

•

Liczba Użytkownik nacisnął przycisk z liczbą

•

Otworzono drzwiczki Przełącznik drzwiowy jest niezamknięty

•

Zamknięto drzwiczki Przełącznik drzwiowy jest zamknięty

•

Zamknięto drzwiczki Przełącznik drzwiowy jest zamknięty

•

Początek Użytkownik nacisnął przycisk „Początek”

•

Zatrzymaj Użytkownik nacisnął przycisk Zatrzymaj”

Model maszyny stanowej

Działanie kuchenki mikrofalowej

Modele danych

•

Większość dużych systemów oprogramowania
korzysta z wielkiej bazy danych. W niektórych
wypadkach istnienie tej bazy danych jest
niezależne od tego systemu oprogramowania.

niezależne od tego systemu oprogramowania.
W pozostałych jest ona specjalnie tworzona na
użytek budowanego systemu. Definiowanie
logicznego formatu przetwarzanych danych
jest ważną częścią modelowania systemów.

Modele danych - projekty

•

Projekty są grafami skierowanymi. Składają się ze zbioru węzłów różnych
rodzajów połączonych krawędziami oznaczającymi związki między węzłami
projektu. Istnieje reprezentacja ekranowa tego grafu, która jest
diagramem projektowym, oraz odpowiadająca jej reprezentacja w bazie
danych.

•

System edycyjny dokonuje przekształcenia reprezentacji w bazie danych
na reprezentację ekranową za każdym razem, gdy wyświetla diagram.

na reprezentację ekranową za każdym razem, gdy wyświetla diagram.
Informacja przekazywana z edytora do innych narzędzi projektowych
powinna zawierać logiczną reprezentację grafn projektu. Takie narzędzia
analityczne nie zajmują się bowiem szczegółową fizyczną reprezentacją
ekranową, ale przetwarzają encje, ich logiczne atrybuty (np. ich nazwy) i
ich związki.

Modele danych - projekty

Słownik danych

•

W uproszczeniu, słownik danych jest
alfabetyczną listą nazw, które pojawiły się w
różnych modelach systemu. Oprócz nazwy
słownik danych powinien zawierać także opisy

słownik danych powinien zawierać także opisy
nazwanych bytów i opis ich składowych w
wypadku bytów złożonych. Może zawierać
także inne informacje, np. datę utworzenia,
autora i reprezentację bytu, zależnie od typu
budowanego modelu.

Słownik danych

•

Jest mechanizmem zarządzania nazwami. W trakcie
opracowywania modelu wielkiego systemu wiele różnych osób
musi wymyślać nazwy encji i związków. Te nazwy muszą być
używane konsekwentnie i nie mogą się pokrywać.
Oprogramowanie słownika danych może sprawdzać unikatowość
danych i informować analityków wymagań o powtórzeniach.

danych i informować analityków wymagań o powtórzeniach.

•

Służy za składnicę informacji o przedsiębiorstwie, która
umożliwia scalenie analizy, projektu, implementacji i ewolucji. W
miarę budowy systemu ta informacja inspiruje wytwarzanie.
Dodawane są nowe informacje. Wszystkie dane o każdym bycie
są w jednym miejscu.

Modele obiektowe

•

Podejście obiektowe do całego procesu tworzenia oprogramowania są
obecnie powszechnie stosowane, zwłaszcza w wypadku systemów
interaktywnych. Przy takim podejściu wymagania systemowe są
zapisywane w modelu obiektowym, projektowanie odbywa się za pomocą
obiektów, a programuje się w jednym z języków programowania
obiektowego, np. Jayie lub C++.

•

Modele obiektowe opracowywane w czasie analizy wymagań mogą być

•

Modele obiektowe opracowywane w czasie analizy wymagań mogą być
użyte zarówno do przedstawienia samego systemu, jak i jego działania.
Pod tym względem łączą w sobie zalety modeli przepływu danych i
znaczeniowych modeli danych. Są również przydatne do pokazywania, jak
encje systemu są klasyfikowane i budowane z innych encji.

Modele obiektowe

•

W wypadku niektórych klas systemów modele obiektowe są
naturalnym sposobem odzwierciedlania encji pochodzących ze
świata rzeczywistego, które są przetwarzane przez system. Jest
to szczególnie widoczne, gdy system przetwarza informacje o
konkretnych encjach, które mają łatwe do zidentyfikowania
atrybuty.

•

Takimi encjami są np. samochody, samoloty i książki. Bardziej

•

Takimi encjami są np. samochody, samoloty i książki. Bardziej
abstrakcyjne encje, takie jak pojęcie biblioteki, system
gromadzenia informacji o leczeniu albo procesory tekstów, są
trudniejsze do modelowania w postaci klas obiektów.
Niekoniecznie mają one prosty interfejs złożony z niezależnych
atrybutów i operacji.

Modele dziedziczenia

•

Modelowanie obiektowe obejmuje identyfikację klas obiektów
istotnych w badanej dziedzinie. Znalezione obiekty są następnie
systematyzowane. Systematyka jest schematem klasyfikacji, w
której widać, jak klasy obiektów są powiązane między sobą przez
wspólne atrybuty i usługi.

•

Ta systematyka jest obrazowana w postaci hierarchii
dziedziczenia, w której wyżej stoją bardziej ogólne klasy
obiektów. Bardziej szczegółowe obiekty dziedziczą ich atrybuty i
usługi. Te specjalizowane obiekty mają też własne atrybuty i
usługi.

Modele dziedziczenia – system biblioteki

Modele dziedziczenia – hierarchia klasy

użytkownika

Agregacja obiektów

•

Obiekty nie tylko mogą otrzymywać atrybuty i usługi dzięki
hierarchii -dziedziczenia. Niektóre obiekty są utworzone z innych
obiektów, tzn obiekt jest agregacją zbioru innych obiektów. Klasy
tych obiektów mogą być modelowane za pomocą agregacji.

•

Przykład: składnik biblioteki, który jest pakietem do nauki

•

Przykład: składnik biblioteki, który jest pakietem do nauki
przedmiotu wykładanego na uniwersytecie. Zawiera on notatki z
wykładów, ćwiczenia, przykładowe ich rozwiązania, kopie
slajdów z wykładów i kasety wideo.

Prototypowanie

oprogramowania

oprogramowania

Prototypowanie oprogramowania

•

Klienci kupujący oprogramowanie i użytkownicy mają zwykle trudności z
określeniem swoich prawdziwych wymagań. Przewidzenie, jak system wpłynie na
codzienną pracę, jak będzie współpracował z innymi systemami i które operacje
użytkowników należy zautomatyzować, jest niemal niemożliwe. Staranna analiza
wymagań i systematyczne przeglądy wymagań pomagają w zmniejszeniu
niepewności co do tego, co system powinien robić. W praktyce nie ma jednak nic
lepszego niż wypróbowywanie wymagań przed ich zatwierdzeniem. Jest to
możliwe, jeśli dostępny jest prototyp systemu.

•

Prototyp jest początkową wersją systemu oprogramowania, która służy do

•

Prototyp jest początkową wersją systemu oprogramowania, która służy do
prezentacji założeń, do wypróbowania wariantów projektu, a bardziej ogólnie do
coraz lepszego poznawania problemu i jego możliwych rozwiązań. Bardzo ważne
jest szybkie stworzenie prototypu, ponieważ umożliwia panowanie nad kosztami i
umożliwia eksperymentowanie użytkownikom we wczesnej fazie procesu
tworzenia oprogramowania.

Prototyp oprogramowania

•

Określanie wymagań. Prototypy systemu umożliwiają użytkownikom
eksperymentowanie w celu sprawdzenia, czy system pomaga im w pracy.
Dzięki temu użytkownicy wpadają na nowe pomysły i mogą znaleźć silne i
słabe punkty oprogramowania. Mogą następnie zasugerować nowe
wymagania systemowe.

•

Zatwierdzanie wymagań. Prototyp może ujawnić błędy i pominięcia w
zaproponowanych wymaganiach. Funkcja opisana w specyfikacji może

zaproponowanych wymaganiach. Funkcja opisana w specyfikacji może
wyglądać na przydatną i dobrze zdefiniowaną. Gdy jednak użyje się jej
razem z innymi funkcjami, użytkownicy mogą stwierdzić, że ich wstępny
pogląd był niepoprawny i niepełny. Specyfikacja systemu może być
wówczas zmodyfikowana tak, aby odzwierciedlała to nowe rozumienie
wymagań.

Prototyp oprogramowania

•

Prototypowanie może być również metodą analizy i eliminacji zagrożeń.
Ważnym zagrożeniem występującym w procesie tworzenia
oprogramowania są błędy i pominięcia w wymaganiach. Koszt
poprawienia błędów w wymaganiach w późnych fazach procesu może być
bardzo wysoki. Koszt tworzenia może być niższy dzięki opracowaniu
prototypu.

•

Prototypowanie jest zatem częścią procesu inżynierii wymagań. Wiele

•

Prototypowanie jest zatem częścią procesu inżynierii wymagań. Wiele
systemów tworzy się obecnie za pomocą podejścia ewolucyjnego, w
którym szybko tworzy się początkową wersję i później modyfikuje ją tak,
aby stała się gotowym systemem. Metody używane do tworzenia
prototypu w celu zatwierdzenia wymagań mogą być zatem użyte również
do tworzenia samego systemu.

Korzyści z prototypowania

•

Nieporozumienia między wytwórcami systemu a użytkownikami
mogą być rozpoznane już w chwili prezentacji usług systemu.

•

W trakcie budowy prototypu personel tworzący
oprogramowanie może znaleźć sprzeczne łub niekompletne
wymagania.

•

Działający, choć niepełny, system jest szybko dostępny i można

•

Działający, choć niepełny, system jest szybko dostępny i można
go wykorzystać do wykazania kierownictwu, że ten program
użytkowy jest wykonalny i przydatny.

•

Prototyp może być podstawą specyfikacji systemu o jakości
przemysłowej.

Korzyści z prototypowania

•

Szkolenia użytkowników. Prototypowy system może być użyty w
trakcie szkoleń, zanim będzie gotowy ostateczny system.

•

Testowanie systemu. Prototypy mogą służyć do testów „ramię w
ramię”. Tym samym testom poddaje się prototyp i system. Jeśli
w obu wypadkach otrzymamy ten sam wynik, to test nie

w obu wypadkach otrzymamy ten sam wynik, to test nie
doprowadził do wykrycia błędu. Jeśli wyniki różnią się, może to
oznaczać, że w systemie jest usterka i należy znaleźć przyczynę
tej różnicy.

Korzyści z prototypowania

•

Zwiększoną użyteczność systemu.

•

Lepsze dopasowanie systemu do potrzeb
użytkowników.

•

Zwiększoną jakość projektu.

•

Zwiększoną jakość projektu.

•

Większą zdatność do pielęgnacji.

•

Zmniejszony wysiłek twórczy.

Cele prototypowania

•

Cele prototypowania powinny być jasno określone już na
początku procesu. Może to być opracowanie systemu będącego
prototypem interfejsu użytkownika, budowa systemu w celu
zatwierdzenia wymagań funkcjonalnych lub tworzenie systemu,
aby wykazać kierownictwu, że jest to wykonalne. Ten sam
prototyp nie może realizować wszystkich tych celów. Jeśli nie

prototyp nie może realizować wszystkich tych celów. Jeśli nie
postawiono jasnych celów, to kierownictwo lub użytkownicy
mogą nie zrozumieć funkcji prototypu. W rezultacie nie
skorzystają z pożytków wynikających z budowania prototypów.

Proces budowy prototypu

Prototypowanie w procesie tworzenia

oprogramowania

•

Jednym ze sposobów radzenia sobie procesem prototypowania
jest zastosowanie podejścia ewolucyjnego do budowania
oprogramowania. Oznacza to dawanie użytkownikowi
niekompletnego systemu, a następnie modyfikowanie i
uzupełnianie go w miarę, jak wymagania użytkowników stają się
jasne.

jasne.

•

Inna możliwość polega na podjęciu świadomej decyzji o
budowie prototypu porzucanego, który pomoże analizować i
weryfikować wymagania. Po ocenieniu prototyp jest porzucany i
od zera buduje się system o jakości przemysłowej.

Prototypowanie w procesie tworzenia

oprogramowania

Cele prototypowania ewolucyjnego i

prototypowania z porzuceniem

•

Celem prototypowania ewolucyjnego jest dostarczenie
użytkownikom działającego systemu. Oznacza to, że powinno się
rozpocząć od tych wymagań użytkownika, które są najlepiej
rozpoznane i mają najwyższy priorytet. Wymagania mniej jasne
lub o mniejszym priorytecie są implementowane jedynie
wówczas, gdy (i pod warunkiem, że) zażądają tego użytkownicy.

•

Celem prototypowania z porzuceniem jest zatwierdzenie łub

•

Celem prototypowania z porzuceniem jest zatwierdzenie łub
dostarczenie wymagań systemowych. Powinieneś zacząć do tych
wymagań, które nie są dobrze rozpoznane, ponieważ
potrzebujesz dowiedzieć się o nich więcej. Wymagania, które są
oczywiste, nie muszą podlegać prototypowaniu.

Cele prototypowania ewolucyjnego i

prototypowania z porzuceniem

•

Inne ważne rozróżnienie między tymi podejściami leży w zarządzaniu
jakością systemów. Czas życia prototypów porzucanych jest z definicji
krótki. W czasie jego budowania musi być możliwość wprowadzania
bardzo szybkich zmian, nie jest natomiast wymagana zdatność do
długoterminowej pielęgnacji. Mała efektywność i niezawodność są
akceptowane w wypadku prototypu po rzucanego, jeśli spełnia on swą
podstawową funkcję pomocy w rozpoznawaniu wymagań.

podstawową funkcję pomocy w rozpoznawaniu wymagań.

•

Prototypy, które ewoluują w kierunku gotowych systemów, powinny być
budowane zgodnie z takimi samymi standardami firmowymi jak inne
oprogramowanie. Powinny mieć prężną architekturę, która umożliwi ich
wieloletnią pielęgnację. Powinny być efektywne i niezawodne. Muszą też
spełniać ważne standardy firmowe.

Prototypowanie ewolucyjne

Zalety prototypowania ewolucyjne

•

Przyspieszone dostarczenie systemu. Tempo zmian
gospodarczych oznacza, że korzyści z programowania muszą
pojawiać się szybko. W niektórych wypadkach błyskawiczne
dostarczenie i użyteczność są znacznie ważniejsze niż
funkcjonalność lub zdatność do pielęgnacji w długim okresie.

•

Włączenie użytkownika w budowę systemu. Udział
użytkowników w procesie budowania powoduje nie tylko to, że
system ma więcej szans spełnienia ich wymagań. Oznacza także
akceptację systemu przez użytkowników, którzy będą chcieli,
żeby dobrze działał.

Prototypowanie a budowanie systemu

•

Procesy specyfikowania, projektowania i implementowania
przeplatają się. Nie ma szczegółowej specyfikacji systemu, a
dokumentacja projektowa zwykle zależy od narzędzi użytych do
implementacji systemu. Dokumentacja wymagań użytkownika
definiuje jedynie najważniejsze właściwości systemu.

•

System jest budowany w postaci ciągu przyrostów. Użytkownicy i
udziałowcy systemu są włączeni w projektowanie i ocenę każdego

udziałowcy systemu są włączeni w projektowanie i ocenę każdego
przyrostu. Mogą proponować zmiany oprogramowania i nowe
wymagania, które mają być zaimplementowane w późniejszej wersji
systemu.

•

Stosuje się metody błyskawicznego tworzenia systemów. Mogą to być
narzędzia CASE.

•

Systemowe interfejsy użytkownika są zwykle budowane za pomocą
interakcyjnego systemu wytwórczego, który umożliwia szybkie
tworzenie projektu interfejsu przez rysowanie i rozmieszczanie ikon.

Problemy

•

Kłopoty z zarządzaniem. Struktury do zarządzania oprogramowaniem wielkich
systemów są przystosowane do pracy z modelem procesu tworzenia
oprogramowania, w którym regularnie powstają produkty umożliwiające ocenę
postępu. Prototypy ewoluują tak szybko, że opracowywanie dużej ilości
dokumentacji jest zbyt kosztowne. Co więcej, błyskawiczne tworzenie prototypów
może wymagać użycia nowych nieznanych technologii. Menedżerowie mogą mieć
trudności z wykorzystaniem dostępnego personelu z powodu braku takich
umiejętności.

•

Kłopoty z pielęgnacją. Ustawiczne zmiany powodują uszkodzenia struktury

•

Kłopoty z pielęgnacją. Ustawiczne zmiany powodują uszkodzenia struktury
prototypowego systemu. Oznacza to, że nikt oprócz jego twórców nie będzie w
stanie łatwo go zrozumieć. Co więcej, użyte specjalistyczne technologie
błyskawicznego tworzenia mogą stać się przestarzałe. Znalezienie osób, które mają
wiedzę niezbędną do pielęgnacji systemu, może być zatem trudne.

Problemy

•

Kłopoty z umową. Zwykły model umowy między klientem a wytwórcą
oprogramowania jest oparty na specyfikacji systemu. Gdy nie ma takiej
specyfikacji, opracowanie umowy na budowę systemu może być trudne. Klienci
nie będą zadowoleni z umowy, która określa stawkę godzinową programisty za
pracę nad przedsięwzięciem, ponieważ prowadzi to do pełzania funkcjonalności i
przekroczenia budżetu. Wytwórcy nie zaakceptują za to umowy na ustaloną kwotę,
ponieważ nie pozwoli to na panowanie nad zmianami żądanymi przez

ponieważ nie pozwoli to na panowanie nad zmianami żądanymi przez
użytkowników.

Przyrostowy proces tworzenia

•

Tworzenie przyrostowe jest łatwiejsze w zarządzaniu niż
prototypowanie ewolucyjne, ponieważ przestrzega się w nim
zwykłych standardów procesu budowania oprogramowania. Dla
każdego przyrostu musi powstać plan i dokumentacja. Dzięki
takiemu podejściu można wsłuchać się w opinie użytkowników
już we wczesnych fazach procesu; ograniczano błędy
systemowe, ponieważ zespół programistów nie musi zajmować

systemowe, ponieważ zespół programistów nie musi zajmować
się interakcjami między całkiem różnymi częściami systemu
oprogramowania. Po dostarczeniu komponentu zamraża się jego
interfejsy. Późniejsze przyrosty muszą dostosować się do tych
interfejsów i są względem nich testowane.

Przyrostowy proces tworzenia

Prototypowanie z porzuceniem

•

W tym podejściu rozszerzono proces analizy
wymagań, aby zmniejszyć całkowity koszt
cyklu życia. Podstawową funkcją prototypu
jest wyjaśnienie wymagań i dostarczenie

jest wyjaśnienie wymagań i dostarczenie
menedżerom dodatkowych informacji, które
umożliwią ocenę ryzyka procesu. Po
oszacowaniu prototyp jest porzucany; nie
używa się go jako podstawy dalszych prac
twórczych.

Prototypowanie z porzuceniem

Prototypowanie z porzuceniem

•

To podejście do prototypowania systemu jest
często używane w wypadku systemów
sprzętowych. Prototyp służy do sprawdzenia
projektu przed podjęciem kosztownej decyzji
o przystąpieniu do produkcji systemu.

o przystąpieniu do produkcji systemu.
Prototyp systemu elektronicznego można
zbudować z komponentów z półki, zanim
zainwestuje się w budowę specjalistycznych
układów scalonych służących do
implementacji wersji produkcyjnej systemu.

Prototypowanie z porzuceniem

•

Prototyp porzucany oprogramowania najczęściej nie służy
jednak do oceny projektu, ale powaga w opracowaniu wymagań
systemu. Projekt prototypu jest zwykle całkowicie odmienny od
końcowej wersji gotowego systemu. System musi być
opracowany tak szybko, jak to tylko jest możliwe, aby
użytkownicy mogli przyczynić się swoimi doświadczeniami z
użytkowania prototypu do opracowania specyfikacji systemu. W

użytkowania prototypu do opracowania specyfikacji systemu. W
prototypie porzucanym można pominąć dobrze rozpoznaną
funkcjonalność, rozluźnić standardy jakościowe i pominąć
kryteria efektywnościowe. Język programowania użyty do
budowy takiego prototypu jest zwykle inny niż język
implementacji gotowego systemu.

Prototypowanie z porzuceniem - problemy

•

Ważne cechy mogły być w prototypie pominięte, co uprościło
jego implementację. W rzeczywistości nie da się prototypować
niektórych najważniejszych części systemu, na przykład funkcje
krytyczne dla bezpieczeństwa.

•

Implementacja nie ma umocowania prawnego jako forma

•

Implementacja nie ma umocowania prawnego jako forma
umowy między klientem i zleceniobiorcą.

•

Na prototypowej implementacji nie da się odpowiednio
przetestować wymagań niefunkcjonalnych dotyczących m.in.
niezawodności, solidności i bezpieczeństwa.

Prototypowanie z porzuceniem - problemy

•

Menedżerowie czasem zmuszają programistów do przedstawienia
prototypu porzucanego jako gotowego programu. Jest tak wówczas,
gdy powstają opóźnienia w dostarczeniu ostatecznej wersji
oprogramowania.

•

Dostrojenie prototypu tak, aby spełniał wymagania niefunkcjonalne
dotyczące efektywności, zabezpieczenia, solidności i niezawodności.
może być niemożliwe, ponieważ te wymagania pomija się przy

może być niemożliwe, ponieważ te wymagania pomija się przy
tworzeniu prototypu.

•

Gwałtowne zmiany zachodzące w czasie budowania nieuchronnie
powodują, że prototyp nie jest udokumentowany. Jedyną specyfikacją
projektową jest kod prototypu. Nie wystarczy to do pielęgnacji w
długim okresie.

•

Zmiany dokonane w czasie tworzenia prototypu prawdopodobnie
doprowadziły do uszkodzeń struktury systemu. Pielęgnacja systemu
będzie trudna i kosztowna.

•

Firmowe standardy jakości zwykle nie są rygorystycznie przestrzegane
w czasie budowania prototypu.

Metody błyskawicznego prototypowania

•

Metody błyskawicznego prototypowania to metody tworzenia,
których przeznaczeniem jest skrócenie czasu dostarczenia, a nie
poprawa właściwości systemu, na przykład efektywności,
zdatności do pielęgnacji i niezawodności. Istnieją trzy metody
błyskawicznego tworzenia, które nadają się do budowania
przemysłowych prototypów.

przemysłowych prototypów.

–

Tworzenie za pomocą dynamicznych języków wysokiego poziomu.

–

Programowanie bazy danych.

–

Scalanie komponentów i programów użytkowych.

Tworzenie za pomocą dynamicznych języków

wysokiego poziomu

•

Dynamiczne języki wysokiego poziomu to języki programowania,
które obejmują mocne udogodnienia do zarządzania danymi w
czasie wykonania. Upraszczają budowanie programu, ponieważ
zmniejszają wiele kłopotów z przydziałem i zarządzaniem
pamięcią.

•

System takiego języka zawiera udogodnienia, które zwykle

•

System takiego języka zawiera udogodnienia, które zwykle
należy napisać samemu, korzystając z prostszych konstrukcji
językowych, np. w Adzie lub C.

•

Przykładami języków bardzo wysokiego poziomu są Lisp (oparty
na strukturach listowych), Prolog (oparty na logice) i Smalltaik
(oparty na obiektach).

Tworzenie za pomocą dynamicznych języków

wysokiego poziomu - problem

•

Nigdy nie będzie idealnego języka do prototypowania wielkiego
systemu, ponieważ różne jego części są bardzo odmienne. Zaleta
podejścia mieszanego z użyciem kilku języków polega na
możliwości wyboru najbardziej odpowiedniego języka do każdej
logicznej części programu użytkowego. Przyspiesza to tworzenie
prototypu.

•

Wadą są trudności z ustaleniem zrębu komunikacyjnego, który

•

Wadą są trudności z ustaleniem zrębu komunikacyjnego, który
umożliwi porozumiewanie się programów napisanych w różnych
językach. Byty użyte w poszczególnych językach bardzo się od
siebie różnią. Długie segmenty kodu mogą być zatem potrzebne
wszędzie tam, gdzie tłumaczy się byty z jednego języka na inny.

Programowanie bazy danych

•

Tworzenie ewolucyjne jest obecnie standardową metodą implementacji
małych i średnich programów użytkowych w dziedzinie systemów
gospodarczych. Większość gospodarczych programów użytkowych
obejmuje przetwarzanie danych z bazy danych i generowanie wyników,
które polega na organizowaniu i formatowaniu danych.

•

Tworzenie takich programów użytkowych jest obecnie wspomagane przez
komercyjne systemy zarządzania bazami danych; wszystkie obejmują język
programowania bazy danych. Programowanie bazy danych jest

programowania bazy danych. Programowanie bazy danych jest
wykonywane w specjalizowanym języku, który ma wbudowaną wiedzę o
bazie danych i zawiera operacje służące do pracy z bazą danych.
Środowisko wspomagające pracę z tym językiem składa się z narzędzi do
definiowania interfejsu użytkownika, obliczeń numerycznych i
generowania raportów.

Programowanie bazy danych

•

Język zapytań do bazy danych, którym obecnie najczęściej jest
SQL. Zapytania mogą być wprowadzane bezpośrednio lub
automatycznie generowane na podstawie formularzy
wypełnionych przez użytkownika.

•

Generator interfejsów, który służy do tworzenia formularzy do
wprowadzania i wyświetlania danych.

wprowadzania i wyświetlania danych.

•

Arkusz kalkulacyjny do analizowania i przetwarzania informacji
numerycznych.

•

Generator raportów, który służy do definiowania i tworzenia
raportów na podstawie informacji z bazy danych.

Scalanie komponentów i programów

użytkowych

•

Czas konieczny do zbudowania systemu może być krótszy, jeśli
wiele jego części będzie ponownie wykorzystanych, a nie
zaprojektowanych i zaimplementowanych od nowa.

•

Prototypy mogą powstawać bardzo szybko, jeśli jest do
dyspozycji zbiór komponentów użycia wielokrotnego i jakiś

dyspozycji zbiór komponentów użycia wielokrotnego i jakiś
mechanizm scalania komponentów w system. Ten mechanizm
musi obejmować sterowanie i komunikację komponentów.

Scalanie komponentów i programów

użytkowych

Scalanie komponentów i programów

użytkowych

•

Prototypowanie z komponentami użycia wielokrotnego
obejmuje opracowanie specyfikacji systemu z uwzględnieniem
dostępności takich komponentów. Może to oznaczać
konieczność akceptacji pewnych kompromisów dotyczących
wymagań. Funkcjonalność dostępnych komponentów nie musi
precyzyjnie odpowiadać wymaganiom użytkownika. Wymagania

precyzyjnie odpowiadać wymaganiom użytkownika. Wymagania
te są jednak często dość elastyczne, a zatem w większości
wypadków takie podejście do prototypowania może być
zastosowane.

Prototypowanie interfejsu użytkownika

•

Graficzne interfejsy użytkownika są obecnie normą w wypadku
systemów interakcyjnych. Wysiłek włożony w wyspecyfikowanie,
zaprojektowanie i zaimplementowanie interfejsu użytkownika
jest istotną częścią kosztu zbudowania programu użytkowego.

•

Zgodnie z zaleceniami projektanci nie powinni nakłaniać
użytkowników do swojej wizji akceptowalnego interfejsu.
Użytkownik musi brać udział w procesie projektowania

Użytkownik musi brać udział w procesie projektowania
interfejsu. To spostrzeżenie doprowadziło do opracowania
podejścia zwanego projektowaniem koncentrującym się na
użytkowniku, które polega na prototypowaniu interfejsu i
udziale użytkownika przez cały proces projektowania interfejsu.

Prototypowanie interfejsu użytkownika

WWW

•

Miliony ludzi posługują się obecnie przeglądarkami WWW. Rozumieją one
język definicji stron (HTML), który z prostego języka tekstowych
znaczników rozwinął się od zwartej notacji do specyfikacji interfejsów
użytkownika. W witrynie WWW można umieścić zarówno przyciski, pola,
formularze oraz tabele, jak i obiekty multimedialne dające dostęp do
dźwięków, nagrań, filmów i ekranów rzeczywistości wirtualnej.

•

Z obiektami interfejsu użytkownika można skojarzyć skrypty

•

Z obiektami interfejsu użytkownika można skojarzyć skrypty
przetwarzające, które działają u klienta WWW albo centralnie na serwerze
WWW. Ze względu na powszechną dostępność przeglądarek WWW oraz
siłę HTML i związane z nim możliwości przetwarzania, coraz więcej
interfejsów użytkownika ma postać interfejsów WWW.

Projektowanie interfejsu

użytkownika

użytkownika

Projektowanie interfejsu

użytkownika

•

Projektowanie systemów komputerowych obejmuje szeroki zakres
czynności, od projektowania sprzętu do projektowania interfejsu
użytkownika. Podczas gdy specjalistów zatrudnia się zwykle przy
projektowaniu sprzętu, bardzo mało firm angażuje specjalistów od
projektowania interfejsów.

•

Dobry projekt interfejsu użytkownika jest niezbędnym warunkiem
powodzenia systemu. Interfejs trudny w użyciu w najlepszym wypadku

powodzenia systemu. Interfejs trudny w użyciu w najlepszym wypadku
doprowadzi do wielu pomyłek użytkowników. W najgorszym wypadku
użytkownicy po prostu odmówią używania systemu oprogramowania
niezależnie od jego funkcjonalności. Jeśli informacja jest przedstawiana w
sposób zagmatwany i mylący, użytkownicy mogą źle zrozumieć znaczenie
systemu. Mogą wykonać ciągi poleceń. które uszkodzą dane lub
doprowadzą do awarii systemu.

Właściwości interfejsu graficznego

użytkownika

•

Okna - wiele okien umożliwia jednoczesne wyświetlanie różnych
informacji na ekranie użytkownika

•

Ikony - reprezentują różne rodzaje informacji. W niektórych
systemach odpowiadają plikom, a w innych — procesom

•

Menu - polecenie wybiera się z menu, a nie wpisuje w postaci
instrukcji języka poleceń

instrukcji języka poleceń

•

Wskazywanie - urządzenia do wskazywania, takie jak mysz, służą
do wyboru z menu i wskazywania potrzebnych elementów w
oknie

•

Grafika - elementy graficzne można połączyć z tekstowymi na
tym samym ekranie

Zalety GUI

•

Są dość łatwe do nauczenia się i do użytkowania. Użytkownicy
bez doświadczeń z komputerami mogą nauczyć się używania
interfejsu w ciągu krótkiego szkolenia.

•

Użytkownik ma kilka ekranów (okien) do interakcji z systemem.
Można przejść od jednego zadania do innego bez utraty oglądu

Można przejść od jednego zadania do innego bez utraty oglądu
informacji przygotowanej w trakcie pierwszego zadania.

•

Szybka interakcja za pomocą pełnego ekranu daje dostęp do
każdego miejsca na ekranie.

Proces projektowania interfejsu użytkownika

Zasady projektowania interfejsu użytkownika

•

Projektanci interfejsu użytkownika muszą brać
pod uwagę psychiczne i umysłowe zdolności
osób używających oprogramowania. Ludzie
mają ograniczoną pamięć krótką i robią błędy

mają ograniczoną pamięć krótką i robią błędy
zwłaszcza wówczas, gdy muszą obsłużyć dużą
ilość informacji lub są pod presją. Mają różne
możliwości psychiczne. Projektując interfejsy
użytkownika, trzeba to wszystko wziąć pod
uwagę.

Zasady projektowania interfejsu użytkownika

•

Zbliżenie do użytkownika - Interfejs powinien posługiwać się pojęciami
kategoriami wziętymi z doświadczeń osób, któro najczęściej będą korzystać z
systemu

•

Spójność - Interfejs powinien być spójny, tzn. tam, gdzie to jest możliwe, podobne
operacje powinny być wykonywane w ten sam sposób

•

Minimum niespodzianek - Użytkownicy nie powfnni być zaskakiwani
zachowaniem systemu

•

Możliwość wycofania - Interfejs powinien obejmować mechanizmy, które

•

Możliwość wycofania - Interfejs powinien obejmować mechanizmy, które
umożliwią użytkownikom wycofywanie się z błędów

•

Porady dla użytkownika - Interfejs powinien przekazywać znaczące informacje
zwrotne, gdy dochodzi do błędów. Powinien też oferować pomoc, której treść
zależy od kontekstu

•

Rozróżnianie użytkowników - Interfejs powinien oferować udogodnienia do
interakcji dostosowanie do różnych rodzajów użytkowników systemu

Interakcja z użytkownikiem

•

Projektant komputerowego interfejsu
użytkownika ma do czynienia z dwoma
zasadniczymi zagadnieniami:

–

Jak systemowi komputerowemu dostarczyć
informacje od użytkownika?

informacje od użytkownika?

–

Jak przedstawić użytkownikowi informacje od
systemu komputerowego?

•

Spójny interfejs użytkownika musi integrować
interakcję użytkownika i prezentację
informacji.

Podział interakcji

•

Działanie bezpośrednie. Polega na tym, że użytkownik bezpośrednio
porozumiewa się z obiektami na ekranie. Usunięcie pliku może na przykład
polegać na przeciągnięciu go do kosza na śmiecie.

•

Wybór z menu. Polega na tym, że użytkownik wybiera polecenie z listy
możliwości (menu). Często zdana się, że inny obiekt ekranowy jest wówczas
wybrany i polecenie działa właśnie na tym obiekcie. Przy tym podejściu, żeby
usunąć plik, użytkownik musi go wybrać i wskazać polecenie usunięcia.

•

Wypełnianie formularza. Polega na tym, że użytkownik wypełnia rubryki

•

Wypełnianie formularza. Polega na tym, że użytkownik wypełnia rubryki
formularza. Z pewnymi polami mogą być związane menu. Formularz może
mieć przyciski, których naciśnięcie powoduje wykonanie pewnej akcji.
Usuwanie pliku przez interfejs formularzowy byłoby sztuczne. Polegałoby na
wypełnieniu rubryki z nazwą pliku i naciśnięciu przycisku usuń.

•

Język poleceń, w którym użytkownik wydaje specjalne polecenia i podaje
parametry pouczające system, co ma zrobić. Aby usunąć plik, użytkownik
wydaje polecenie usunięcia z nazwą pliku jako parametrem.

•

Język naturalny, w którym użytkownik wydaje polecenia. Aby usunąć plik,
użytkownik mógłby na przykład napisać „usuń plik o nazwie abc”.

Wady i zalety sposobów interakcji

Prezentacja informacji

•

Czy użytkownik potrzebuje dokładnej informacji, czy tylko
związków między różnymi wartościami danych?

•

Jak szybko zmienia się ta informacja? Czy użytkownik musi
natychmiast widzieć te zmiany?

•

Czy użytkownik musi wykonywać pewne działania w odpowiedzi

•

Czy użytkownik musi wykonywać pewne działania w odpowiedzi
na zmianę informacji?

•

Czy użytkownik ma oddziaływać na wyświetlaną informację
przez interfejs bezpośredniego działania?

•

Czy wyświetlana informacja jest tekstowa, czy numeryczna? Czy
wartości względne są ważne?

Różne prezentacje informacji

Przykłady prezentacji

•

Informacje meteorologiczne zebrane z kilku źródeł
przedstawione na mapie pogody za pomocą izobar i frontów
atmosferycznych.

•

Stan sieci telefonicznej przedstawiony graficznie jako zbiór
połączonych węzłów na tablicy w centrum sterowania siecią.

•

Stan reaktora chemicznego przedstawionego graficznie

•

Stan reaktora chemicznego przedstawionego graficznie
uwidoczniony jako ciśnienia i temperatury w zbiorze
połączonych zbiorników i rur.

•

Model cząsteczki uwidoczniony i zmieniany w trzech wymiarach
za pomocą systemu rzeczywistości wirtualnej.

Kolor w projekcie interfejsu

•

Ogranicz liczbę stosowanych kolorów i używaj ich ostrożnie. Nie
powinieneś korzystać z więcej niż czterech lub pięciu kolorów w jednym
oknie i siedmiu w całym interfejsie. Kolory należy starannie wybrać i
stosować je spójnie. Nie powinieneś ich używać tak po prostu, żeby
rozjaśnić interfejs.

•

Zmiany kolorów używaj do oznaczenia zmiany stanu systemu. Zmiana
koloru wyświetlania powinna oznaczać wystąpienie ważnego zdarzenia.
Zmiana koloru wskaźnika poziomu paliwa powinna oznaczać jego niski

Zmiana koloru wskaźnika poziomu paliwa powinna oznaczać jego niski
poziom. Uwydatnianie za pomocą kolorów jest szczególnie ważne w
wypadku złożonych wyświetlaczy, na których może być widać setki różnych
bytów.

•

Skorzystaj z kodu kolorów, który pomoże użytkownikowi w realizacji zadań.
Jeśli kolory mają odróżniać egzemplarze anomalne, używaj ich w tym celu.
Jeśli należy uwidocznić także podobieństwa, zaznacz je innym kolorem.

Kolor w projekcie interfejsu

•

Korzystaj z kodu kolorów spójnie i rozsądnie. Jeśli w jednej części systemu
czerwony służy na przykład do wyświetlania komunikatów o błędach, w
innych częściach powinno być podobnie. Kolor czerwony nie powinien być
używany do czegokolwiek innego. W przeciwnym wypadku użytkownik
zinterpretuje czerwoną informację jako komunikat o błędzie. Powinieneś
być także świadom, że niektóre Masy użytkowników wiążą konkretne
znaczenia z pewnymi kolorami.

znaczenia z pewnymi kolorami.

•

Uważaj na związki między kolorami. Budowa oka uniemożliwia
jednoczesne skupienie uwagi na kolorach czerwonym i niebieskim.
Niebiesko-czerwony ekran powoduje zmęczenie oczu. Inne kombinacje
kolorów również mogą być męczące i trudne do odczytywania.

Kolor w projekcie interfejsu

•

Kolory nie powinny służyć do przedstawiania znaczeń z dwóch powodów.
Około 10% ludzkości to daltoniści, którzy źle interpretują kolory. Percepcja
kolorów u różnych osób jest inna, a różne profesje mają inne konwencje
kojarzenia znaczeń z kolorami. Użytkownicy z różnych środowisk mogą
nieświadomie odczytywać ten sam kolor na różne sposoby. Dla kierowcy
czerwony oznacza niebezpieczeństwo, a dla chemika — wysoką
temperaturę.

•

Jeśli użyje się zbyt wielu kolorów lub gdy są one zbyt jaskrawe, to

•

Jeśli użyje się zbyt wielu kolorów lub gdy są one zbyt jaskrawe, to
wyświetlane treści mogą być mylące. Liczność kolorów może przeszkadzać
użytkownikowi (tak samo, jak nie można przez dłuższy czas przypatrywać
się malarstwu abstrakcyjnemu) i powodować zwiększony wysiłek oka.
Niespójne użycie kolorów może wprawić użytkownika w zakłopotanie.

Pomoc dla użytkownika

•

komunikaty generowane przez system w
odpowiedzi na działania użytkownika,

•

system pomocy natychmiastowej,

•

dokumentacja dostępna w systemie.

•

dokumentacja dostępna w systemie.

Zagadnienia projektowe związane z redakcją

komunikatów

Dokumentacja użytkownika

•

Opis funkcjonalny, w którym należy bardzo krótko opisać usługi
oferowane przez system. Użytkownicy powinni móc na
podstawie tego dokumentu i przewodnika podstawowego
zdecydować, czy ten system jest im potrzebny.

•

Podręcznik instalatora powinien obejmować szczegółowe
informacje o instalacji systemu. Trzeba w nim opisać dyski, na

informacje o instalacji systemu. Trzeba w nim opisać dyski, na
których dostarczono system, pliki na tych dyskach oraz
minimalną wymaganą konfigurację sprzętową. Powinien
zawierać także instrukcje dla instalatora i precyzyjne informacje
o uzupełnianiu plików zależnych od konfiguracji.

Dokumentacja użytkownika

•

Przewodnik podstawowy powinien obejmować nieformalne wprowadzenie do
systemu, w którym należy przedstawić jego „normalne” użycie. Trzeba w nim
opisać, jak zacząć pracę z systemem i jak użytkownicy mogą korzystać z
uniwersalnych udogodnień systemu. Powinien zawierać wiele przykładów.
Powinien zawierać informacje o wycofywaniu się z pomyłek i rozpoczęciu od nowa
użytecznych działań.

•

Podręcznik powinien zawierać opis udogodnień systemu oraz ich
wykorzystywania, listę komunikatów o błędach i ich przypuszczalnych przyczyn
oraz sposobów wycofywania się z wykrytych błędów.

wykorzystywania, listę komunikatów o błędach i ich przypuszczalnych przyczyn
oraz sposobów wycofywania się z wykrytych błędów.

•

Podręcznik administratora powinien być dostarczony w wypadku niektórych
rodzajów systemów. Może opisywać komunikaty systemu w trakcie interakcji z
innymi systemami oraz wyjaśnienie, jak reagować na te błędy. Jeśli system składa
się również ze sprzętu, to można przedstawić sposób rozpoznawania i naprawiania
problemów sprzętowych, sposób łączenia z urządzeniami zewnętrznymi itd.

Atrybuty użyteczności

•

W jakim stopniu sprawność systemu
odpowiada praktyce pracy użytkowników?

•

Jak system znosi błędy użytkownika?

•

Jak dobrze system radzi sobie z wycofywaniem

•

Jak dobrze system radzi sobie z wycofywaniem
wyników błędów

•

Jak bardzo system jest związany z jednym
modelem pracy?

•

Po jakim czasie nowy użytkownik efektywnie
korzysta z systemu?

Projektowanie interfejsu użytkownika

•

Proces projektowania interfejsu użytkownika powinien koncentrować się na
użytkowniku. Interfejs powinien porozumiewać się z użytkownikami za pomocą ich
pojęć. Powinien być logiczny i spójny. Powinien zawierać też udogodnienia
pomagające użytkownikom w pracy z systemem i w wycofywaniu się z pomyłek.

•

Sposoby interakcji z systemem oprogramowanym to m.in. bezpośrednie działanie,
wybór z menu, wypełnianie formularza, języki poleceń i język naturalny.

•

Informacje należy wyświetlać graficznie, gdy chce się przedstawić trendy i wartości
przybliżone. Wyświetlacze cyfrowe powinny być stosowane jedynie wówczas, gdy

przybliżone. Wyświetlacze cyfrowe powinny być stosowane jedynie wówczas, gdy
jest wymagana precyzja.

•

W interfejsie użytkownika kolory należy używać oszczędnie i spójnie. Projektanci
powinni brać pod uwagę, że znacząca liczba osób to daltoniści.

Projektowanie interfejsu użytkownika

•

Systemy pomocy powinny oferować dwa rodzaje pomocy: Pomóżcie!, to
znaczy Pomóżcie! Jestem w kłopotach!” i Pomożecie?”, to znaczy
Pomożecie? Potrzebuję informacji.”

•

Komunikaty o błędach nie powinny sugerować, że użytkownik jest winny.
Powinny za to sugerować, jak naprawić błąd, i dawać odsyłacz do systemu
pomocy.

•

Dokumentacja użytkownika powinna obejmować przewodniki dla

•

Dokumentacja użytkownika powinna obejmować przewodniki dla
początkujących i podręczniki. Należy dostarczyć oddzielne dokumenty dla
administratora systemu.

•

Specyfikacja systemu powinna zawierać (tam gdzie to jest możliwe)
ilościowe wartości atrybutów użyteczności. Proces oceny powinien
polegać na weryfikacji systemu względem tych wymagań.

Systemy krytyczne

Pewność

•

Systemy komputerowe czasem się psują bez wyraźnego powodu i nie wykonują zleconych
usług. Programy działające na tych komputerach mogą nie wykonywać się tak jak należy, a
czasem niszczą dane przechowywane w systemie.

•

Pewność systemu komputerowego jest właściwością systemu odpowiadającą zaufaniu,
którym jest obdarzany. Zaufanie oznacza stopień przekonania użytkownika, że system
będzie działał tak jak należy i nie będzie się „psuł” przy normalnym użytkowaniu. Ta
właściwość nie może być wyrażona liczbowo, ale da się ją zapisać nieformalnie. Określenia,
takie jak „niepewny”, „bardzo pewny” i „ultrapewny”, odpowiadają różnym poziomom
zaufania, którym obdarzamy system.

zaufania, którym obdarzamy system.

•

Zasługiwanie na zaufanie nie jest oczywiście tym samym co użyteczność. Procesor tekstów
zbyt godny zaufania, ale bardzo użyteczny. Brak zaufania powoduje częste zapisywanie pracy
na dysk i przechowywanie wielu kopii zapasowych. Za pomocą działań ograniczających
szkody, które mogłyby być wynikiem awarii systemu, zrekompensowałem więc brak
pewności systemu.

Wymiary pewności

Cztery wymiary pewności

•

Dostępność systemu określamy nieformalnie jako prawdopodobieństwo,
że w ustalonej chwili będzie on włączony, będzie działał i będzie w stanie
realizować użyteczne usługi.

•

Niezawodność systemu określamy nieformalnie jako
prawdopodobieństwo, że w ustalonym okresie system będzie poprawnie
realizował usługi zlecone przez użytkownika.

•

Bezpieczeństwo systemu określamy nieformalnie jako opinię o możliwości

•

Bezpieczeństwo systemu określamy nieformalnie jako opinię o możliwości
wyrządzenia szkód ludziom i środowisku przez system.

•

Zabezpieczenie systemu określamy nieformalnie jako opinię o odporności
systemu na przypadkowe lub celowe wtargnięcie intruza.

Koszt a pewność

Pewność a efektywność

•

Systemy niepewne, niebezpieczne lub niezabezpieczone zwykle pozostają
nieużywane. Jeśli użytkownicy nie ufają systemowi, to najczęściej rezygnują z
używania go. Co więcej, mogą również nie chcieć korzystać z innych produktów tej
samej firmy, ponieważ mogą one być tak samo niegodne zaufania jak system, z
którego zrezygnowali.

•

Koszt awarii systemu może być olbrzymi. W wypadku niektórych zastosowań,
takich jak system sterowania reaktorem lub system nawigacji samolotu, koszt
awarii systemu jest o wiele rzędów wielkości wyższy niż koszt samego systemu.

awarii systemu jest o wiele rzędów wielkości wyższy niż koszt samego systemu.

•

Trudno jest odzyskać pewność. Zwykle można dostroić nieefektywny system,
ponieważ większość czasu wykonania odpowiada małym fragmentom programów.
System niegodny zaufania nie da się tak łatwo poprawić, ponieważ fragmenty
niegodne zaufania są zwykle rozproszone po całym systemie.

Pewność a efektywność

•

Zwykle można zrekompensować brak efektywności systemu. Użytkownicy
mogą czasem dostosować swoją pracę tak, aby radzić sobie z wolno
działającym systemem. Najczęściej brak pewności jest natomiast
zaskoczeniem dla użytkownika. Oprogramowanie niegodne zaufania może
bez ostrzeżenia zniszczyć system i dane użytkownika lub ulec awarii o
poważnych konwencjach, które będą widoczne z opóźnieniem

•

Systemy niegodne zaufania mogą spowodować utratę informacji.

•

Systemy niegodne zaufania mogą spowodować utratę informacji.
Gromadzenie i przechowywanie danych jest bardzo kosztowne. Często
dane są warte więcej niż przetwarzający je system komputerowy.
Powielenie danych w celu zabezpieczenia przed uszkodzeniem może
wymagać wiele wysiłku i wiązać się z dużymi kosztami.

Systemy krytyczne

•

Systemy krytyczne dla bezpieczeństwa to systemy, których awaria może
powodować obrażenia i utratę życia lub poważne zniszczenie środowiska.
Przykładem systemu krytycznego dla bezpieczeństwa jest system
sterowania reaktorem chemicznym.

•

Systemy krytyczne dla zadania to systemy, których awaria może
powodować niepowodzenie pewnej czynności mającej jakiś cel.
Przykładem systemu krytycznego dla zadania jest system nawigacji statku

Przykładem systemu krytycznego dla zadania jest system nawigacji statku
kosmicznego.

•

Systemy krytyczne dla przedsiębiorstwa to systemy, których awaria może
powodować kłopoty korzystających z nich przedsiębiorstw. Przykładem
systemu krytycznego dla przedsiębiorstwa jest system kont klientów w
banku.

Typy komponentów systemu najbardziej

podatnych na awarie

•

Sprzęt systemu, który może się popsuć z
powodu błędów projektowych, błędów przy
ich produkcji lub z powodu naturalnego
zmęczenia materiału.

•

Oprogramowanie systemu, które może ulec
awarii z powodu błędów w specyfikacji,
projekcie lub implementacji.

•

Operatorzy systemu, którzy mogą
niewłaściwie go obsługiwać.

Przykład systemu krytycznego - Struktura

pompy insulinowej

Pewność sytemu

•

Dostępność. System powinien być gotowy do wstrzyknięcia
insuliny, gdy jest ona potrzebna.

•

Niezawodność. System powinien działać niezawodnie i
dostarczać właściwą ilość insuliny w celu zrównoważenia
aktualnego poziomu cukru we krwi.

aktualnego poziomu cukru we krwi.

•

Bezpieczeństwo. Awaria systemu może w zasadzie spowodować
wstrzykiwanie nadmiernych dawek insuliny, które mogą być
zagrożeniem życia użytkownika. Ten rodzaj awarii systemu nie
powinien się zdarzać.

Model przepływu danych

Dostępność i niezawodność

•

Niezawodność. Prawdopodobieństwo
bezawaryjnego działania w ciągu ustalonego
czasu w zadanym środowisku w określonym
celu.

celu.

•

Dostępność. Prawdopodobieństwo, że w
ustalonej chwili system będzie działał i będzie
zdolny do realizacji żądanych usług.

Niezawodność

Poprawienie niezawodności

•

Unikanie usterek. Stosuje się metody tworzenia, które zmniejszają
możliwość pomyłek lub umożliwiają wychwytywanie ich, zanim
doprowadzą do awarii systemu. Przykładami takich metod są: unikanie
podatnych na błędy konstrukcji języka programowania, takich jak
wskaźniki.

•

Wykrywanie i usuwanie usterek. Stosuje się metody weryfikacji i
zatwierdzania, które zwiększają szansę wykrycia i usunięcia usterek przed
przystąpieniem do użytkowania systemu. Przykładem takiej metody jest

przystąpieniem do użytkowania systemu. Przykładem takiej metody jest
systematyczne testowanie i usuwanie błędów przez śledzenie
wykonywania kodu.

•

Tolerowanie usterek. Stosuje się metody, które zapewniają, że usterki w
systemie nie powodują błędów, a błędy systemu nie powodują awarii.
Przykładami takich metod są wprowadzanie do systemu udogodnień
wewnętrznej kontroli i użycie nadmiarowych modułów systemu.

Bezpieczeństwo

•

Podstawowe oprogramowanie krytyczne dla bezpieczeństwa jest
oprogramowaniem w postaci sterownika wbudowanego w system. Niewłaściwe
działanie takiego oprogramowania może powodować niewłaściwe działanie
sprzętu, które powoduje szkody lub zniszczenia środowiska.

•

Pomocnicze oprogramowanie krytyczne dla bezpieczeństwa jest
oprogramowaniem, które może pośrednio powodować szkody. Przykładami takich
systemów są systemy komputerowego wspomagania projektowania, których
niewłaściwe działanie może doprowadzić do usterek w projektowanym obiekcie.
Taka usterka może być zagrożeniem dla ludzi, gdy zaprojektowany system działa

niewłaściwe działanie może doprowadzić do usterek w projektowanym obiekcie.
Taka usterka może być zagrożeniem dla ludzi, gdy zaprojektowany system działa
źle. Innym przykładem pomocniczego systemu krytycznego dla bezpieczeństwa
jest baza danych medycznych ze szczegółowymi informacjami o lekach zapisanych
pacjentom. Błędy w tym systemie mogą doprowadzić do niewłaściwego
dawkowania leku.

Niezawodne systemy oprogramowania

•

Nigdy nie możemy być w stu procentach pewni, że system nie ma usterek lub że
zawsze toleruje usterki, istnieje kilka przyczyn, dla których niezawodne systemy
oprogramowania nie muszą być bezpieczne:

–

Specyfikacja może być niekompletna, ponieważ nie określono w niej wymaganego
zachowania systemu w pewnych krytycznych sytuacjach. Wiele wypadków
niewłaściwego działania systemów jest wynikiem błędów w specyfikacji, a nie w
projekcie.

–

Niewłaściwe działanie sprzętu może spowodować nieprzewidywalne zachowanie
systemu i prowadzić do powstania niespodziewanego środowiska dla oprogramowania.

systemu i prowadzić do powstania niespodziewanego środowiska dla oprogramowania.
Gdy komponenty są bliskie awarii, mogą działać błędnie i generować sygnały spoza
dopuszczalnego zakresu, który może być obsłużony przez oprogramowanie.

–

Operator systemu może podać dane wejściowe, które pojedynczo nie są błędne, ale ich
zestaw w pewnych sytuacjach może spowodować niewłaściwe działanie systemu.
Anegdotycznym przykładem takiej sytuacji było żądanie mechanika, żeby
oprogramowanie obsługi spowodowało schowanie podwozia samolotu.
Oprogramowanie posłusznie spełniło tę prośbę, mimo że samolot stał na płycie lotniska.

Zapewnienie bezpieczeństwa

•

Unikanie zagrożeń.

–

System jest zaprojektowany tak, aby uniknąć zagrożeń.

–

System tnący, którego zadziałanie wymaga od operatora naciśnięcia dwóch przycisków
w tej samej chwili, wystrzega się na przykład ryzyka umieszczenia rąk operatora w
zasięgu noża.

•

Wykrywanie i eliminowanie zagrożeń.

–

System jest zaprojektowany tak, aby wykrywać i eliminować zagrożenia, zanim
doprowadzą do wypadku.

doprowadzą do wypadku.

–

System reaktora chemicznego może na przykład wykrywać nadmierne ciśnienie i
otwierać zawór bezpieczeństwa w celu zmniejszenia ciśnienia, zanim dojdzie do
eksplozji.

•

Ograniczanie szkód.

–

System może obejmować udogodnienia zabezpieczające, które ograniczają szkody
będące konsekwencją wypadku.

–

Silnik lotniczy zawiera na przykład automatyczne gaśnice. Gdy pojawi się ogień, zwykle
można go ugasić, zanim stanie się zagrożeniem dla pasażerów i załogi.

Pojęcia związane z bezpieczeństwem

•

Pewność systemu komputerowego jest jego właściwością, która odzwierciedla
stopień zaufania użytkownika do systemu. Najważniejszymi wymiarami pewności
są: dostępność, niezawodność, bezpieczeństwo i zabezpieczenie.

•

System krytyczny to system, którego awarie mogą powodować znaczne straty
gospodarcze, fizyczne zniszczenia lub śmierć ludzi. Trzema ważnymi rodzajami
systemów krytycznych są systemy krytyczne dla bezpieczeństwa, systemy
krytyczne dla zadania i systemy krytyczne dla przedsiębiorstwa.

•

Dostępność systemu to prawdopodobieństwo, że będzie on realizował usługi dla

•

Dostępność systemu to prawdopodobieństwo, że będzie on realizował usługi dla
użytkowników, gdy o to poproszą. Niezawodność to prawdopodobieństwo, że
usługi systemu będą wykonywane zgodnie ze specyfikacją.

•

Niezawodność i dostępność są czasem uważane za najważniejsze wymiary
pewności. Jeśli system jest zawodny, to trudno jest zapewnić jego bezpieczeństwo
lub zabezpieczenie, ponieważ niweczą je awarie systemu.

•

Niezawodność jest związana z prawdopodobieństwem wystąpienia błędu
w czasie użytkowania systemu. Program może zawierać usterki, a mimo
tego użytkownicy mogą uważać go za niezawodny, ponieważ nie korzystają
z udogodnień systemu niepełnowartościowych wskutek tych usterek.

•

Bezpieczeństwo systemu to jego atrybut, który odzwierciedla zdolność
systemu do poprawnego lub niepoprawnego działania bez powodowania
zagrożeń dla ludzi i środowiska. Jeśli bezpieczeństwo jest główną cechą
systemu krytycznego, to nazywamy go systemem krytycznym dla

systemu krytycznego, to nazywamy go systemem krytycznym dla
bezpieczeństwa.

•

Zabezpieczenie jest ważne we wszystkich systemach krytycznych. Bez
rozsądnego poziomu zabezpieczeń dostępność, niezawodność i
bezpieczeństwo systemu mogą być zniweczone przez zewnętrzne ataki!
które wywołały szkody w systemie.

Zagadnienia na egzamin:

•

Co to jest inżynieria oprogramowania?

•

Co to jest model procesu tworzenia oprogramowania?

•

Jakie są modele tworzenia oprogramowania – charakterystyka.

•

Jakie właściwości ma dobre oprogramowanie?

•

Kodeks etyki + dylematy etyczne

•

Co to jest system? Czynniki wpływające na proces projektowania systemu. Omówić
przykładowy system.

•

Definicja wymagań systemowych- podział i charakterystyka

•

Definicja wymagań systemowych- podział i charakterystyka

•

Zarządzanie projektem (inżynierski a programistyczny), plan projektu, etapy,.

•

Zarządzanie – harmonogram (wykresy paskowe, sieci działań – przykład)

•

Zagrożenia – zarządzanie, identyfikacja, analiza, przeciwdziałanie

•

Wymagania stawiane oprogramowaniu (funkcjonalne – niefunkcjonalne)

•

Inżynieria wymagań- określanie i analizowanie, Metoda VORD – przykład, scenariusze –
przykład.

•

Modele systemu – przykład analizy systemu

•

Prototypowanie oprogramowania – podział, cele, funkcjonalność

•

Projektowanie interfejsu

•

//Systemy krytyczne.

Zagadnienia na egzamin: