1 Wybrane definicje Projektu
" Zarządzany zbiór zadań zmierzających do jednego celu, wykonywany przy określo-
nych ograniczeniach
" Rozdzielanie zasobów w ustalonych ramach czasowych oraz koordynowanie powiąza-
nych wzajemnie zdarzeń w celu osiągnięcia wyznaczonego celu, przy jednoczesnym
podejmowaniu zarówno przewidywalnych, jak i zupełnie wyjątkowych wyzwań
" Działalność, w której zasoby ludzkie, materialne i finansowe są organizowane w
sposób odpowiadający zakresowi pracy zadanemu w danej specyfikacji, z uwzględ-
nieniem ograniczeń czasowych i kosztowych tak, aby uzyskać produkt lub zmianę
przez cele jakościowe i ilościowe.
2 Projekt a Produkt
3 Modele Projektów
3.1 Kaskadowy
Określenie wymagań Projektowanie Implementacja Testowanie Konserwacja
Stosowany w projekcie o dobrze zdefiniowanych wymaganiach dla dobrze rozumianych
zastosowań
Zalety:
" łatwość zarządzania przedsięwzięciem
" ułatwia planowanie, harmonogramowanie oraz monitorowanie przedsięwzięcia
Wady:
" brak weryfikacji
" brak elastyczności
" wysoki koszt błędów popełnianych we wstępnych fazach
" długa przerwa w kontaktach z klientem, co może zmniejszyć zainteresowanie klien-
ta produktem lub spowodować wytworzenie produktu nie spełniającego wymagań
(walidacja!)
" nie sprzyja wprowadzaniu modyfikacji
" nie sprzyja tworzeniu systemów wspomagających decyzje
" zbytni formalizm i narzucenie ścisłej kolejności wykonywania prac
Rzadko stosuje siÄ™ ten model w czystej postaci, ale stanowi on bazÄ™ dla innych modeli
powstałych jako jego udoskonalenia.
3.2 Model typu V
Modyfikacja modelu kaskadowego, podkreślająca wagę weryfikacji i walidacji systemu
3.3 Model Spiralny
Projekt jako kolejne kroki projektowe z uwzględnieniem ryzyka realizacji
3.4 Prototypowanie
Określenie ogólnych wymagań Budowa prototypu Weryfikacja prototypu przez
klienta Pełne określenie wymagań Realizacja pełnego systemu zgodnie z modelem
kaskadowym
Model zalecany przy realizacji nowatorskich rozwiązań, które dotychczas nie były w fir-
mie zamawiajÄ…cej produkt stosowane. W takich warunkach klientowi jest bardzo trudno
ściśle zdefiniować wymagania wobec funkcji dotąd nie realizowanych w przedsiębiorstwie.
Cel:
" wykrycie nieporozumień pomiędzy klientem a twórcami systemu
" wykrycie brakujÄ…cych funkcji
" wykrycie trudnych usług
" wykrycie braków w specyfikacji wymagań
Zalety:
" minimalizacja ryzyka związanego z niewłaściwym określeniem wymagań
" możliwość szybkiej demonstracji pracującej wersji systemu
" możliwość szkoleń zanim zbudowany zostanie pełen system
Wady:
" dodatkowy koszt budowy prototypu
" potencjalne zdziwienie klienta, który musi długo czekać i sporo płacić za końcowy
system, który został  prawie całkowicie wykonany w tak krótkim czasie
3.5 Programowanie Odkrywcze
Określ ogólne wymagania Zbuduj system Przetestuj system System działa po-
prawnie? (jak nie to powrót do  Zbuduj system ) Testowanie
Zalety:
" możliwość stosowania nawet w wypadkach dużych trudności z określeniem wymagań
klienta
Wady:
" brak struktury projektu ze względu na ciągłe zmiany
" nie jest możliwe osiągnięcie większej niezawodności przy realizacji dużych systemów
" testowanie modelu może odbywać się tylko w obecności klienta, gdyż twórcy pro-
gramu nie mają wiedzy na temat pełnych wymagań wobec systemu
3.6 Realizacja Przyrostowa
OkreÅ›lanie wymagaÅ„ Ogólny projekt «POCZ
TEK P
TLI Wybór podzbioru
funkcji Szczegółowy projekt, implementacja, testy Dostarczenie zrealizowanej czę-
Å›ci systemu «KONIEC P
TLI
Zalety:
" skrócenie przerw w kontaktach z klientem
" możliwość wczesnego wykorzystania przez klienta dostarczonych fragmentów syste-
mu
" możliwość elastycznego reagowania na powstałe opóz
nienia
Wady:
" dodatkowy koszt towarzyszący niezależnej realizacji fragmentów systemu
4 ERD - Entity Relationship Diagram
Konstruktory:
" encja
" atrybut
" zwiÄ…zek
Encja (ang. entity)
" reprezentuje obiekty materialne i koncepcyjne
" każda encja musi być jednoznacznie identyfikowalna (nazwa)
" wszystkie encje wzajemnie siÄ™ wykluczajÄ…
Atrybuty (modelują własności encji)
Zadania atrybutu: identyfikować, opisywać, klasyfikować, określać ilość lub wyrażać stan
encji
" jedno/wielo wartościowe
" wyprowadzane
" kluczowe
" niekluczowe (obce)
" obowiÄ…zkowe/opcjonalne
" puste/niepuste
5 DFD - Data Flow Diagrams
Cel stosowania DFD
" Przedstawiają graficzny modelu procesów w systemie  bez odniesienie kiedy i jak
zostały wykonane
" Zespół DFD wraz z kompletnym opisem elementów składowych zawartych w słow-
niku danych stanowi model procesów w systemie
" OdzwierciedlajÄ… ruch danych w systemie rzeczywistym
" Pozwalają patrzeć na system na rożnych poziomach szczegółowości
DFD jest głównym modelem dla programu nieinteraktywnych (np. kompilatory), których
głównym zadaniem jest obliczanie wartości funkcji. Dla systemu służących do składowa-
nia danych (np. bazy danych) model DFD jest często trywialny, gdyż celem ich jest
składowanie danych, a nie ich transformacja.
Składniki DFD
" Obiekty zewnętrzne (terminatory)
 ReprezentujÄ… z
ródła lub miejsca przeznaczenia informacji, które są zewnętrzne
w stosunku do sytemu (np. osoba, dział urzędu, firma, inny system komputero-
wy, maszyna i inne obiekty znajdujÄ…ce siÄ™ na zewnÄ…trz systemu)
 Obiekt generujÄ…cy lub przyjmujÄ…cy strumienie danych
 Leżą poza obszarem zmiany związanej z wdrażanym projektem
" Składnice (magazyny) danych
 Reprezentują miejsca, gdzie dane są przechowywane między operującymi na
nich procesami
 Magazyny są dostępne tylko dla procesów co oznacza, że magazyn danych nie
może się łączyć bezpośrednio z terminatorem
 Przepływ wychodzący ze składu interpretowany jest jako czytanie lub dostęp
do informacji w składzie
 Jeśli przepływ nie ma etykiety, oznacza to, że pełen pakiet informacji jest wy-
szukiwany i pobrany (np. wszystkie rekordy magazynu). Jeśli etykieta na prze-
pływie jest taka sama jak na składzie ale w liczbie pojedynczej oznacza to, że
jest pobrane jedno wystÄ…pienie pakietu
 Przepływ do składu interpretowany jest jako zapis, modyfikacja lub usunięcie
danych
" Procesy
 Odpowiadają tym składnikom systemu, które operują na danych
 Procesy otrzymują i przesyłają dane za pośrednictwem przepływów danych
 Dokonują transformacji przepływów wejściowych w przepływy wyjściowe
" Przepływy danych
 Opisują strumienie danych o określonej zawartości przepływające pomiędzy
dwoma składnikami DFD:
" terminatorami a procesami
" procesami a procesami
" procesami a składnicami danych
Zasady:
" Każdy diagram ma nazwę (tytuł)
" Każdy obiekt ma nazwę
" Nazwa każdego obiektu powinna dokładnie odzwierciedlać jego cechy
" Nazwy obiektów nie odwołują się zwykle do konkretnych wystąpień obiektów
" Proces nie może tworzyć nowych danych  może je pobierać z terminatorów a na-
stępnie przekształcać (konserwacja danych)
" Proces oraz magazyn musi mieć przynajmniej jeden przepływ wchodzący i przynaj-
mniej jeden wychodzÄ…cy
" Przepływ danych nie jest reprezentacją przepływu sterowania  nie może opisywać
czynności tylko migrujące dane
" Numery obiektów są do celów porządkowych  nie informują o kolejności czy waż-
ności
" Przepływy połączone z danym procesem nie powinny mieć jednakowej nazwy (nie
zostały przetworzone?)
" Diagramy zwykle nie mają początku ani końca
" Przepływy dochodzą do procesu, który bezpośrednio korzysta z danych  nie ma
tranzytów
" Przepływ zawsze łączy się z procesem
" Dane mogą być czytane z magazynów, zapisywane do magazynu lub jednocześnie
czytane i zapisywane
" Magazyn nie może tworzyć nowych danych  to co z niego wychodzi musi zostać
uprzednio wprowadzone (konserwacja danych)
" Terminator leży poza granicami systemu  ułatwia pokazanie jakie są granice
6 STD - State-Transition Diagram
Pokazuje zachowanie się systemu w czasie (co jest szczególnie istotne dla systemów czasu
rzeczywistego); ze względu na swoją elastyczność mogą też służyć do prezentowania
sposobu realizacji funkcji systemu
" Zdarzenie (event)
Informuje o tym co wydarzyło się w pewnej chwili; ma zerowy czas trwania; pewne
klasa zjawisk, na które system reaguje w podobny sposób
Zdarzenia zachodzące poza systemem to zdarzenia zewnętrzne
Zdarzenie wewnętrzne mają swoje z
ródło w ramach systemu
" Stan (state)
Okres czasu między zdarzeniami; system w różnych stanach reaguje w sposób jako-
ściowo różny na zachodzące zdarzenia
" Przejście (transition)
Zmiana stanu wywoływana przez zdarzenie; przejście może być uwarunkowane speł-
nieniem dodatkowego warunku
" Akcja (action)
Czynność wykonywana w momencie zajścia zdarzenia
" Operacja (activity)
Związana z konkretnym stanem i oznacza czynność ciągłą, wykonywaną podczas
trwania stanu; operację może przerwać zdarzenie, które powoduje przejście do no-
wego stanu lub operacja kończy się samoczynnie i generuje w momencie swego za-
kończenia zdarzenie, które powoduje przejście do innego stanu
7 Jakość
" zgodność z wymaganiami (czyli koncentracja na weryfikacji testowanie końcowe)
" przydatność użytkowa (czyli koncentracja na walidacji zarządzanie wymagania-
mi)
" stopień w jakim użytkownik wierzy, że produkt/usługa spełnia jego potrzeby i ocze-
kiwania
" ogół cech i właściwości wyrobu/usługi decydujących o zdolności wyrobu/usługi do
zaspokojenia stwierdzonych lub przewidywanych potrzeb (ISO 9000)
Uwagi:
" funkcjonalność jest tylko jedną z wielu licznych cech jakościowych (użytkownik wy-
biera raczej produkt sprawdzony, stabilny i niezawodny niż z wieloma funkcjami)
" normy jakości jako potwierdzenie jakości produktów dla firm o krótkiej historii na
rynku
" wytwarzanie jakości w miejsce jej testowania ( zrób dobrze za pierwszym razem
Philip Crosby)
Model McCalla
Działanie programu
Przyjazność Efektywność użytkowania programu i przyjazność jego interfejsu
Bezpieczeństwo Bezpieczeństwo użytkowania programu pod kątem kontroli
uprawnień do korzystania z niego oraz odporności na
skutki nieprawidłowej obsługi
Wydajność Ocena wydajności systemu i sposobów zarządzania zasobami
Poprawność Stopień realizacji wymagań, kompletność i logiczność wdrożenia,
zgodność działania programu ze specyfikacją
Niezawodność Stopień odporności programu na błędy, jego poprawność formalna
oraz sposoby reakcji na błędne sytuacje
Przystosowanie do modyfikacji
Pielęgnowalność Stopień przystosowania programu do poprawy, modyfikacji,
rozszerzania, adaptowania
Elastyczność Możliwości rozbudowania programu o nowe funkcje oraz
uniwersalność wdrożonych rozwiązań
Testowalność Przystosowanie do testowania oraz instrumentacja tego procesu
Mobilność oprogramowania
Przenośność Zdolność do łatwego uruchomienia na innych maszynach lub
systemach oprogramowania
Uniwersalność Możliwość wykorzystania istniejącego oprogramowania lub jego
fragmentów do konstrukcji innych programów
Otwartość Przystosowanie programu do współpracy lub wymiany informacji
z innymi systemami komp.
8 Weryfikacja i Walidacja
Walidacja  proces oceny oprogramowania na zakończenie procesu produkcyjnego (lub
fazy), w celu sprawdzenia czy jest wolne od błędów i niezgodności
Weryfikacja - proces określenia, czy produkt danej fazy produkcyjnej spełnia wymaga-
nia postawione w fazie poprzedniej
Metody:
" PrzeglÄ…dy techniczne oprogramowania (testowanie na sucho):
 walkthroughs
 inspekcje
 audyty
" Testowanie oprogramowania (przeglÄ…d techniczny wykonywalnej specyfikacji pro-
gramu)
" Dowodzenie poprawności
" Symulacje i prototypowanie
" Śledzenie wymagań
9 Rodzaje testowania
Z punktu widzenia głównego celu:
" wykrywanie błędów
" testy statystyczne - wykrywanie przyczyn najczęstszych błędnych wykonań oraz
ocena niezawodności systemu
Z punktu widzenia techniki wykonywania testów:
" testy dynamiczne - wykonanie fragmentu programu i porównywanie uzyskanych
wyników z wynikami poprawnymi (wykrywają jedynie błędne wykonania)
" testy funkcjonalne  system traktowany jako czarna skrzynka, która w nieznany
sposób realizuje wymagane funkcje; dane wejściowe dzielone są na klasy, w których
działanie powinno być podobne
" testy strukturalne  zakładają znajomość sposobu implementacji testowanych funk-
cji
" testy statyczne  analiza kodu
10 Błędy, bezpieczeństwo, konserwacja
10.1 Ocena liczby błędów
" liczba błędów a nie musi mieć związku z niezawodnością oprogramowania
" liczba błędów ma bezpośredni wpływ na konserwację oprogramowania (szacunkowa
liczba błędów * średni procent błędów zgłaszanych przez użytkownika * średni koszt
usunięcia błędu)
Technika posiewania błędów
N  liczba wprowadzonych błędów
M  liczba wszystkich wykrytych błędów
X- liczba wprowadzonych błędów, które zostały wykryte
szacunkowa liczba bÅ‚Ä™dów przed wykonaniem testów: (M - X) · N/X
liczba bÅ‚Ä™dów po usuniÄ™ciu wykrytych: (M - X) · (N/X - 1)
efektywność technik testowania: X/N
10.2 Bezpieczeństwo
" systemy krytyczne z punktu widzenia bezpieczeństwa to takie, w których błędne
wykonania mogą prowadzić do zagrożenia życia i zdrowia ludzkiego oraz mogą spo-
wodować duże straty materialne lub złamanie przepisów prawnych
" bezpieczeństwo nie jest tożsame z niezawodnością:
 system zawodny może być bezpieczny, jeżeli skutki błędnych wykonań nigdy nie
sÄ… groz
ne
 niezawodność nie opisuje sytuacji wyjątkowych
 niebezpieczeństwo może wynikać z awarii sprzętowych
10.3 Konserwacja
Z punktu widzenia klienta jest to faza eksploatacji, a z punktu widzenia producenta faza
konserwacji (ang. maintanance; pielęgnacji, utrzymania)
Klasy modyfikacji:
" modyfikacje poprawiające  usuwają błędy z oprogramowania (poprawa błędów po-
pełnionych w każdej fazie tworzenia oprogramowania)
" modyfikacje ulepszające  poprawiają jakość oprogramowania
 poprawa wydajności funkcji
 poprawa ergonomii interfejsu użytkownika
 poprawa przejrzystości raportów
" modyfikacje dostosowujÄ…ce  dostosowujÄ… oprogramowanie do zmian zachodzÄ…cych
w środowisku jego pracy
 zmiany wymagań użytkownika
 zmiany przepisów prawnych dotyczących dziedziny problemu
 zmiany organizacyjne po stronie klienta
 zmiany sprzętu i oprogramowania systemowego