Testowanie zstępujące

Jest integralną częścią zstępującego procesu budowania, który rozpoczyna się od komponentów
wysokiego poziomu i polega na przejściu w dół hierarchii komponentów.
Program jest reprezentowany przez pojedynczy abstrakcyjny komponent z komponentami podrzędnymi w
postaci namiastek. Namiastka ma taki sam interfejs jak komponent, ale jej
funkcjonalność jest bardo ograniczona. Po zaprogramowaniu i przetestowaniu komponentu
najwyższego poziomu w ten sam sposób implementuje i testuje się jego komponenty podrzędne.
Ten proces jest kontynuowany do chwili zaimplementowania komponentów najniższego poziomu.
Wówczas cały system jest już w pełni przetestowany.

Testowanie wstępujące

Polega natomiast na integrowaniu i testowaniu modułów niższego poziomu hierarchii, następnie przejściu
w górę hierarchii modułów i przetestowaniu ostatecznego modułu.Przy tym podejściu do rozpoczęcia prac
nie jest konieczne ukończenie projektu architektonicznego systemu.Do procesu testowania można więc
przystąpić już we wczesnej fazie tworzenia. To podejście może być zastosowane tam, gdzie w systemie
ponownie wykorzystuje się i modyfikuje komponenty innych systemów.
Testowanie czarnej skrzynki

Testowanie funkcjonalne lub inaczej testowanie czarnej skrzynki to podejście do testowania, przy
którym testy wprowadza się ze specyfikacji programu lub komponentu. System jest „czarną skrzynką”,
której zachowanie można ustalić jedynie na podstawie jego danych wejściowych związanych z nimi
danych wyjściowych. Inną nazwą tego podejścia jest testowanie funkcjonalne, ponieważ osoba testująca
zajmuje się jedynie funkcjonalnością, a nie implementacją oprogramowania.Inżynieria


Testowanie strukturalne to podejście do testowania, przy którym testy opracowuje się na
podstawie wiedzy o strukturze i implementacji oprogramowania. To podejście jest czasem nazywane
testowaniem “białej skrzynki”, “szklanej skrzynki” lub “przezroczystej skrzynki” w odróżnieniu od
testowania czarnej skrzynki. Testowanie strukturalne stosuje się zwykle do stosunkowo niewielkich
jednostek programów, takich jak podprogramy i operacje związane z obiektem. Jak wskazuje nazwa,
osoba testująca może analizować kod i korzystać z wiedzy o strukturze komponentu przy opracowywaniu
danych testowych.

Typy Zagrożeń:
Zagrozenia technologiczne:
– Zbyt wolny silnik DB
– Problem z komponentami wielokrotnego uzytku
Zagrozenia ze strony ludzi:
– Brak personelu o odpowiednich umiejetnosciach
– ChorobyG
Zagrozenia organizacyjne:
– Reorganizacje w firmie (zmiana zarzadu/menedzeró/G)

Zagrozenia narzedziowe:
– CASE, generacja kodu,G
Zagrozenia wymagan:
– Zmiana wymaganG
Zagrozenia szacowania:
– Niedoszacowanie czasu, zasobów, czestosci napraw usterek, rozmiaruG

Koszt oprogramowania stanowi w wielu przypadkach dominujący
czynniki kosztu całego systemu informatycznego, często znacznie
większy niż np. koszt sprzętu
Koszt utrzymania i zarządzania oprogramowaniem jest znacznie
większy niż koszt jego wytworzenia - fazy specyfikacji i
testowania mają ogromny wpływ na koszt utrzymania systemu

Model kaskadowy
Zalety
Prosta koncepcja odzwierciedlająca praktyki stosowane w innych
procesach produkcji
Duża czytelność całości procesu – zakończenie poszczególnych etapów
ułatwia raportowanie stanu projektu
Wady
Brak jawnej weryfikacji pomiędzy poszczególnymi etapami
Przyjęcie założenie, że można stworzyć poprawną specyfikację już na
samym początku projektu
Długi okres upływający od momentu stworzenia spececyfikacji do
momentu dostarczenia/wdrożenia systemu
Brak zarządzania ryzkiem

Model V wytwarzanie z zapewnieniem jakości. Przejście od jednej fazy do następnej odbywa się po
zaakceptowaniu zbioru dokumentów
Zalety: Wysoka jakość obniżenie kosztów utrzymania, mniejsze ryzyko „niepowodzenia”
Wady, Narzuty pracy, czasu i kosztu realizacji systemu, Silno rozbudowana dokumentacja, Problem z
zespołem, motywacja

Mode Spiralny
Zalety
Jawne zarządzanie ryzykiem
Możliwość wczesnej eliminacji błędów
Koncentracja na zarządzaniu jakością tworzonego systemu
Poszczególne fazy projektu mogą być realizowane z wykorzystaniem różnych,
najbardziej odpowiednich modeli
Dobra czytelność
Wady
Skomplikowany w porównaniu do np. modelu kaskadowego

Stosowany raczej do realizacji dużych systemów
Wymaga znajmości problematyki szacowania i zarządzania ryzykiem

Model przyrostowy Jest wariantem modelu ewolucyjnego W wytwarzaniu przyrostowym najpierw
następuje określenie wymagań, po czym całość systemu dzielona jest na kolejne „przyrosty” (increments),
każdorazowo tworzące dające się testować, rozrastające się wersje sytemu. Problemem jest
określenie „przyrostów”, tak aby były one istotnymi fragmentami oprog., do testów i oceniania.

Model ewolucyjny (klasyczny z nawrotami) rezygnacja ze ścisłego, liniowego następstwa faz.
Pozostawia się te same czynności, ale pozwala na powroty. Tym samym umożliwia się adaptowanie
do zmian w wymaganiach i korygowanie popełnionych błędów. Wymaga dodatkowych strategii dla
uporządkowania procesu wytwarzania oprog.
Słaba czytelność spowodowana szybkimi iteracjami;
ekonomicznie nieuzasadnione tworzenie dokumentacji w
trakcie szybko zmieniających się iteracji

Model komponentowy

W modelu komponentowym idee ponownego użycia kodu posunięte są najdalej
Po fazie określania wymagań następuje faza analizy możliwości wykorzystania istniejących, gotowych
komponentów i ewentualna faza modyfikacji wymagań, w konsekwencji zastosowania komponentów
W fazie projektowania uwzględnia się już znalezione komponenty oraz ewentualnie nowe, związane z
techniczną realizacją (implementacją)
Projekt oprogramowania wykonywany jest tak, aby te spośród wytwarzanych elementów, które się do tego
nadają, mogły być ponownie wykorzystane jako komponenty
W fazie wytwarzania kodu zwraca się szczególną uwagę na interfejsy pomiędzy modułami-komponentami
Testowanie jest w dużej mierze testowaniem integracji poszczególnych komponentów

Wady i zalety

Mimo zalet związanych z wykorzystaniem gotowych, przetestowanych modułów, wytwarzanie
oprogramowania w oparciu o komponenty (component based software development) stwarza specyficzne
trudności:

●

wymagania narzucane przez gotowe komponenty mogą być niezgodne z wymaganiami klientów

●

modyfikacje kodu mogą być utrudnione przez brak kontroli nad pochodzącymi z zewnątrz
komponentami

Techniki software reuse: Kompozycja (składanie) oprog. z wcześniej przygotowanych zasobów.
Generowanie aplikacji (generative reuse) poprzez transformacje opisów systemu (high-level) w
wykonywalny kod

Fazy określania wymagań *faza ustalania wymagań (odkrywania wymagań)*faza specyfikacji wymagań
(tworzenia opisu wymagań)* faza atestacji (walidacji, validation) wymagań. Fazy powyższe mogą
być powtarzane wielokrotnie na różnych etapach określania wymagań, wraz z rosnącym zakresem i
poziomem szczegółowości wymagań i proponowanych modeli dla systemu Za każdym razem zakładać

będziemy, że w określaniu wymagań uczestniczy klient (znający dziedzinę zastosowań) i wykonawca
(odpowiedzialny za aspekty informatyczne, choć nie musi to być ostateczny wykonawca projektu)

Wymagnia funkcjonalne - określają funkcjonalność systemu.
Przykładowo mogą określać:
sposób reakcji systemu na żądania użytkowników
wygląd interfejsów
Specyfikacja wymagań :
Jednoznaczne wskazanie wszystkich użytkowników korzystających z
systemu,
Jednoznaczne wskazanie wszystkich użytkowników, niezbędnych do
działania systemu (obsługa, wprowadzanie danych, administracja).
Określenie funkcji systemu udostępnianych użytkownikowi oraz
sposobów korzystania z planowanego systemu.
Określenie systemów zewnętrznych (obcych baz danych, sieci,
Internetu), wykorzystywanych w czasie pracy systemu.
Ustalenie struktur organizacyjnych, przepisów prawnych, statutów,
zarządzeń, instrukcji, itd., które pośrednio lub bezpośrednio określają
funkcje wykonywane przez planowany system.

Wymagania niefunkcjonalne - wszelkie wymagania które nie
zaliczają się do kategorii wymagań funkcjonalnych, które mogą mieć
wpływ zarówno na końcowy system (produkt) jak i na proces jego
wytworzenia. Wymagania niefunkcjonalne dzielimy na:
ograniczenia - wszelkie ograniczenia jakie powinien spełniać system (np..
wydajność, niezawodność itp.)
założenia - dotyczące procesu produkcji systemu jak również jego pracy po
wdrożeniu (np. wydajnośc zespołu projektowego, przewidywany czas życia
wdrożonego systemu, znajomość obsługi komputerów przez użytkowników itp.)
cele biznesowe - wszelkie wymagania (np. usprawnienia, oszczędności, wzrost
prestiżu itp.) jakich spełnienia oczekuje klient zamawiający system w obrębie
działalności z jaką związany będzie system

Przykłady wymagań niefunkcjonalnych
Wymaganie dot. produktu
4.C.8 Komunikacja użytkownika z systemem powinna być
wyrażona za pomocą standardowego zestawu znaków ASCII z
standardem kodowania polskich liter ISO 8859-2.
Wymaganie organizacyjne
9.3.2 Proces tworzenia systemu oraz dostarczane dokumenty
powinny być zgodne ze standardami dot. procesu oraz
dokumentacji określonymi w XYZCo-SP-STAN-95.
Wymaganie zewnętrzne
7.6.5 System ma umożliwić dowolnemu użytkownikowi

weryfikację danych osobowych przechowywanych w systemie.
Oprogramowanie powinno dostarczyć odpowiednie procedury
pozwalające na przegląd tych danych i weryfikację błędów.

Walidacja wymagań
Określenie czy zebrane wymagania i stworzony dokument
wymagań definiują system zgodny z oczekiwaniami klienta

Weryfikacja stwierdza czy system działa prawidłowo (spełnia wymagania funkcjonalne i niefunkcjonalne)
Walidacja i weryfikacja są czynnościami, które powinno się przeprowadzać we wszystkich fazach
wytwarzania oprog.. realizowane są na dwa uzupełniające się sposoby: poprzez inspekcję wymagań,
projektu i kodu poprzez test. programu
Weryfikacja (podejście statyczne):
„Czy tworzymy system we właściwy sposób"
Odpowiada na pytanie czy oprogramowanie
odpowiada swojej specyfikacji
Walidacja (podejście dynamiczne):
„Czy tworzymy właściwy system"
Odpowiada na pytanie czy tworzony przez nas
system działa tak jak tego oczekuje użytkownik

Podejście dynamiczne Skupia się na uruchamianiu
i obserwacji zachowania systemu
Stosuje się do elementów wykonywalnych systemu, tj.
samego programu względnie prototypu (ów)

Podejście statyczne Skupia się na analizie
statycznej reprezentacji elementów systemu. Celem
jest identyfikacja możliwych problemów
Ma zastosowanie do wszystkich produktów (artefaktów)
powstających w obrębie systemu
Np. dokumenty projektowe, kod, projekty testów (!)

Zalety projektowania obiektowego
Łatwe zarządzanie
Możliwość powtórnego użycia klas obiektów –
projektowanie/programowanie komponentowe
W wielu przypadkach występuje stosunkowo proste
mapowanie pomiędzy elementami rzeczywistego
środowiska systemu a obiektami
Wsparcie ze strony narzędzi programistycznych oraz
istnienie standardu notacji obiektowej (UML)

Model Repozytorium danych

-Podsystemy muszą mieć możliwosć wymiany danych.
-Współdzielone dane są przechowywane w centralnej bazie danych, udostępnionej dla wszystkich
podsystemów lub każdy z podsystemów posiada własną bazę danych. Dane są jawnie przekazywane do
innych podsystemów.
-W przypadku projektowania systemu który zawiera duże ilości współdzielonych danych, najczęściej
używa się modelu z repozytorium danych.
Zalety: Wydajny sposób współdzielenia dużej ilości danych
Podsystemy nie muszą nic wiedzieć o tym w jaki sposób dane są wytwarzane
Centralna polityka bezpieczeństwa kopii zapasowych
Pielegnacja (tworzenie kopii zapasowej, sterowanie zabezpieczeniami i
dostepem oraz odtwarzanie po awarii=) – scentralizowane czynnosci
Wady: Podsystemy muszą uzgodnić model danych w repozytorium -kompromis
Zmiana modelu danych - Uciążliwa i kosztowna
Trudności z efektywną dystrybucją - spójność i redundantność danych
- Moze byc jednak trudno rozproszyc repozytorium na kilku maszynach.

Architektura klient-serwer
-Model rozproszonego systemu; demonstruje rozproszenie danych oraz przetwarzania w obrębie sieci
-Zespół serwerów dostarczających określone usługi takie jak drukowanie, zarządzanie danymi itp
-Zbiór klientów żądających poszczególnych usług
-Sieć umożliwiająca klientom dostęp do usług oferowanych przez serwery
Zalety: Rozproszenie danych w naturalny sposób
Efektywne wykorzystanie systemów sieciowych. Może umożliwić użycie tańszego sprzętu.
Prostota i łatwość dodawania nowych serwerów bądź rozbudowy istniejących.
Wady: Brak współdzielonego modelu danych; podsystemy stosują różne reprezentacje danych. Wymiana
danych (a więc i konwersja) może obniżać wydajność
Nadmiarowe zarządzanie każdym z serwerów z osobna
Brak centralnego rejestru nazw i usług - mogą się pojawić trudności z identyfikacją dostępnych usług.

Model Warstwowy
-Funkcjonalność podzielona pomiędzy warstwy. Każda z warstw zbudowana w oparciu o serwisy
oferowany przez niższą warstwę.
- Wysoki poziom abstrakcji ( niska współzależność). Warstwa wyższa nie zna szczegółów budowy
warstwy niższej, Warstwa niższa może w ogóle nie wiedzieć o istnieniu warstw wyższych
- Przykład, model OSI dla prot. sieciowych.
Zalety: Wielokrotne użycie: ta sama niższa warstwa może być wykorzystywana przez różne wyższe
warstwy.
-Przenośność: możliwość alternatywnych implementacji warstw niższych
-Rozbudowywalność: możliwość rozbudowy/modyfikacji funkcjonalności warstw wyższych
– dekompozycja systemu na niezalezne komponenty, mozliwe do oddzielnej
analizy,
– łatwosc podmiany komponentu z dowolnej warstwy na inny (protokół!),
– mozliwosc scalenia kolejnych warstw w jedna (protokół!)
– mozliwosc rozdzielenia jednej warstwy w wiele (protokół!),

– rozdzielenie systemów do zadan dedykowanych,
– rozdzielenie mocy obliczeniowej miedzy warstwy,
– mozliwosc równowazenia obciazen,
– zapewnienie rozwiazan redundantnych (nadmiarowych, zapasowych).
Wady: Narzut na wydajność: przekazywanie parametrów poprzez kolejne warstwy. Szczególnie
uwidacznia się to w przypadku częściowego duplikowania funkcjonalności poszczególnych warstw- np
konstrukcja pakietu
- trudny do implementacji w istniejacych juz systemach nie projektowanych z
uwzglednieniem modelu warstwowego,
-potrzeba obudowania funkcjonalnosci w dodatkowy interfejs,
utrudnienia zwiazane z zapewnieniem zgodnosci wstecznej podczas
rozbudowy interfejsu.

Testowanie Statyczne:
Testowanie oprogramowania pod kątem
niezawodności, nie wykrywania błędów w
funkcjonalności
Wybór danych do testów powinien być zgodny z
przewidywanym sposobem używania
oprogramowania
Pomiar liczby błędów pozwala na przewidywanie
niezawodności
Ustala się żądany poziom niezawodności a następnie
system jest testowany i poprawiany dopóki nie
zostanie osiągnięty zadany poziom

Etapy procesu testowania:
Testowanie modułów (ang. unit testing)
Testowanie poszczególnych komponentów systemu w izolacji od
pozostałych
Testowanie integracyjne (ang. integration testing)
Testowanie interfejsów współpracujących ze sobą modułów lub
podsystemów
Testowanie systemowe (ang. system testing)
Szczegółowe testowanie funkcjonalności całego, kompletnego
systemu
Testowanie akceptacyjne (ang. acceptance testing)
Wykonywane przez/w obecności klienta/użytkownika w celu
stwierdzenia czy system spełnia wymagania. Zwykle podzbiór
testów systemowych
Testowanie regresyjne (ang. regression testing)
Ma na celu identyfikację błędów wprowadzonych do istniejącej już i
testowanej wcześniej funkcjonalności, np. przy okazji nanoszenia
poprawek

Testowanie Typu White-box:
Technika testowania w ktrórej do wyboru danych
testowych wykorzystuje się wiedzę na temat budowy
testowanego komponentu stąd nazwa
Znajomość kodu komponentu jest również niezbędna
do interpretacji wyników danego testu
Aby test był miarodajny, tester musi znać
zaplanowaną funkcjonalność danego komponetu
Strategie testowania typu white box w swoim
założeniu mają na celu
Conajmniej jednokrotne wykonanie każdej instrukcji kodu
źródłowego systemu
Indywidualne przetestowanie każdej procedury/funkcji
wchodzącej w skład systemu
Strategie te nie są w stanie wykryć błędów
spowodowanych pominięciem funkcjonalności
Testują tylko istniejący kod !
Najpowszechniej używane w nast. typach testów
unit testy, testy integracyjne

Metody testowania white-box:
Pokrycie wyrażeń (ang. statement coverage)
Pokrycie rozgałęzień (ang. branch coverage)
Dane testowe mają zapewnić przejście wszystkich
rozgałęzień w instrukcjach warunkowych
Pokrycie warunków (ang. branch condition coverage)
Dane testowe mają zapewnić że wszystkie elementarne
warunki w złożonych instrukcjach warunkowych dadzą w
wyniku dwie możliwe wartości: T, F
Testowanie mutacyjne (ang. mutation testing)
Sposób weryfikacji jakości samych testów
Dla danych testowych wprowadzenie mutacji + test

Metody testowania black-box:
Podział na klasy równoważności (ang. equivalence
partitioning)
Analiza wartości brzegowych (ang. boundary value analysis)
Finite-state testing
Testowanie systemów wyspecyfikowanych bądź modelowanych
jako maszyna stanów
Kontrola składni (ang. syntax checking)
Przydatne przy testowaniu parserów, itp.

Testy czarnej skrzynki - są to testy, w których nie mamy wglądu w szczegóły kodu programu.
Testowanie polega na kontrolowanym wykonywaniu programu lub na badaniu zachowania
pracującego programu.
Testowanie białej skrzynki - Weryfikujemy zgodność działania względem
specyfikacji używając kodu diagnostycznego oraz debuggera. Badamy kod. Testowanie instrukcji
oraz gałęzi kodu.

Tak na chlopski rozum:
czarna skrzynka: bierzemy goscia z ulicy, mówimy mu co program powinien potrafić i niech się
bawi, powinien wykryć brak zaimplementowanych funkcji
biała skrzynka: preparujemy dane tak, żeby test wykonał wszystko co program ma
zaimplementowane, powinien wykryć błedy w implementacj

Testowanie metodą „top-down” Zstępującą
Początek – komponenty najwyższych rzędów
Kierunek – komponenty coraz niższych rzędów
Używane w połączeniu z programowaniem „topdown”
Kodujemy najpierw komponenty najwyższych rzędów
Zamiast komponentów niższych rzędów – zaślepki (ang.
stubs)
Pozwala na wczesną lokalizację błędów architektury
Trudności
Może się pojawić konieczność dostępu do docelowej
infrastruktury systemu – nie wszystko da się zastąpić
zaślepkami
Implementacja zaślepek – uniwersalność vs. wysiłek
potrzebny na utworzenie

Testowanie metodą „bottom-up” Wstępującą
Użyteczne przy testowaniu kluczowych komponentów
architektury
Początek – komponenty najniższych rzędów
Kierunek – komponenty wyższych rzędów
Implementacja tzw. „test drivers”
Możliwość identyfikacji błędów projektu (design)
systemu dopiero w późnych fazach procesu
Szeroko stosowane dla systemów obiektowych

Programowanie ekstremalne – XP wydajne tworzenie małych i średnich projektów „wysokiego ryzyka”,
czyli takich, w których nie wiadomo do końca, co sie tak naprawdę się robi i jak to prawidłowo zrobić.
Charakterystyka:, „Nasz Klient nasz Pan”, Co dwie głowy to nie jedna”, Czytelność i prostota (!), Korzyści
stosowania. zasady oprogramowanie jest rozwijane w krótkich cyklach i w ciągłej interakcji z klientem
*coding standards, *programowanie w parach , *dokumentacja oprog. składa się z: komentarzy w
kodzie, opisu testów, niewiele więcejXP, a podejście klasyczne W XP specyfikacja jest rozwijana na

bieżąco, w trakcie iteracyjnego tworzenia kodu i we współpracy z klientem (a nie jest tworzona przed
implementacją i opisywana w rozległej dokumentacji). Podobnie zapewnienie jakości odbywa się poprzez
test. dokonywane na bieżąco, a nie poprzez sprawdzenie zgodności ze specyfikacją

Miary produktywności:
Miary wielkościowe, oparte na części wyników powstających podczas tworzenia
oprogramowani(ilość linii kodu itd)
Im niższy poziom języka tym produktywność wyższa, Im bardziej rozwlekły programista tym
wyższa jego produktywność
Miary funkcyjne związane z funkcjonalnością dostarczonego oprogramowania
Nagradzanie za funkcjonalność kodu, nie za jego ilość. Jest niezależne od języka, nie ma znaczenia
czy ktoś pisze niskopoziomowo czy obiektowo.Oparta na tzw. punktach funkcyjnych.

Czynniki wpływające na
produktywność
Znajomość domeny systemu
Wymagana jakość produktu (większa produktyw. vs jakość)
Narzut komunikacji przy dużych projektach
Wsparcie (lub jego brak) ze strony technologii i narzędzi
Środowisko pracy i jego zmiany w przypadku realizacji dużych
projektów (duże zespoły projektowe)
Wszystkie wymienione powyżej czynniki mogą mieć znaczny wpływ
na wartości wynikające z przeprowadzonych analiz i oszacowań.
Jak pokazują doświadczenia i badania (Sackman 1968) nie
uwzględnienie tych czynników w estymacjach może powodować
nawet 10-krotne różnice w wynikach oszacowań

Modele CoCoMo
CoCoMo (ang. Constructive Cost Model) - algorytmiczna
metoda powstała na podstawie analizy historycznych danych
ponad 60 różnych projektów (Boehm 1981)
Pierwszą wersję nazwano CoCoMo-81; obecnie funkcjonuje
wersja oznaczona jako CoCoMo 2.0
Metody CoCoMo oparte zostały na założeniu, że estymację
kosztów projektów można określić w postaci matematyczej
funkcji opracowanej na podstawie analizy ukończonych
projektów. Opracowany wzór stanowi funkcję atrybutów
związanych z produktem oraz wykorzystanym do jego produkcji
procesem w ramach projektu (z którym również powiązane
mogą być wartości pewnych atrybutów)

Agile Programming oparta jest na zdyscyplinowanym zarządzaniu projektem. Dla zgranych małych
zespoły, bezpośrednia komunikacja (mało dokumentacji). Kolejne etapy wytwarzania oprog. zamknięte są
w iteracjach, w których za każdym razem przeprowadza się test. wytworzonego kodu, zebranie wymagań,

planowanie rozwiązań itd. Metoda nastawiona jest na szybkie wytwarzanie oprog. wysokiej jakości.

Punkty funkcyjne: Najczęściej jest podstawą do oszacowania m.in. pracochłonności wytworzenia
Dang oprog.. Oparte na polaczeniu następujących elementów programu: Zewnętrzne wejścia i wyjścia,
Interakcje z użytkownikiem, Interfejsy zewnętrzne, Pliki używane przez system. Z każdym elementem
jest skojarzona waga (3-15). Liczba punktów funkcyjnych jest wyznaczana na podstawie sumy wag
elementów systemu. PF SA miara subiektywna, mogą służyć do szacowania liczby linii kodu

Metody szacowania kosztów *Algorytmiczne modelowanie kosztowna podstawie historycznej informacji
o kosztach opracowuje się model, który wiąże pewną miarę oprog. (zwykle jego wielkość) z kosztem
przedsięwzięcia Szacuje się wartość tej miary i na podstawie modelu ustala się wymaganą pracę
cena ekspertów , * Prawo Parkinsona: praca rozciąga się tak, że wypełnia wyznaczony czas. Koszt
jest determinowany przez dostępne zespoły, a nie przez obiektywną ocenę. Jeśli oprog. musi być
dostarczone w ciągu 12 miesięcy i mamy do dyspozycji pięć osób, to niezbędną pracę ocenia się na 60
osobomiesięcy. *Ustalanie ceny pod zwycięstwo Koszt oprog. jest szacowany na tyle, ile klient może
wydać na to przedsięwzięcie. Przybliżona praca zależy od budżetu klienta, a nie od funkcjonalności
oprog..

Model COCOMO jest dobrze dopracowany. Przy ustaleniu oszacowania kosztu bierze się w nim pod
uwagę atrybuty przedsięwzięcia, produktu, sprzętu i personelu. Obejmuje także sposoby szacowania
harmonogramu tworzenia.

Cykl życia oprog. – powtarzająca sie w czasie całość działań prowadzonych od ujawnienia potrzeby
budowy systemu do zakończenia jego wykorzystania.

Klasyczny cykl życia oprog.: Planowanie: analizuje sie celowość i potrzeba wprowadzenia nowego
systemu: Zamierzone cele biznesowe, podstawowe wymagania i ograniczenia oraz podstawowa wizja
systemu Analiza wymagań: cele biznesowe systemu, funkcjonalność, cechy i ograniczenia użytkowe,
i parametry jakościowe, Określenie co system będzie robił, by spełnić zidentyfikowane wymagania
Projektowanie: Odwzorowanie wymagań w strukturę oprog. i jego podstawowe komponenty, Faza
projektowania szczegółowego: definiowana fizyczna reprezentacja danych (struktura relacyjnej DB,
konstruowany interfejsy, projektowanie jednostek programowych (moduły, klasy obiektów i ich składowe)
Implementacja: Tworzenie kodu źródłowego, kompilacje i uruchamianie. Test. i integracja: Scalanie
gotowych bloków, ulokowanie we właściwym środowisku i sprawdzanie cech Produkty etapu: wytworzone
i udokumentowane oprog. wraz z opisem wniesionych zmian, dokumentacje przeprowadzonych testów i
ich wyników, User Manual i instalacji aplikacji Wdrozenie: Np. wymiana całkowita, utrzymanie równoległej
pracy starego i nowego systemu Utrzymanie: Zasadnicze czynności tworzenia oprog.:*Specyfikowanie
oprog.: funkcjonalność oprog. i ograniczenia jego działania, musza być zdefiniowane. *Projektowanie
i implementowanie oprog.: Oprogramowanie, które spełnia specyfikacje, musi być stworzone *
Zatwierdzenie oprog.: programowanie musi spełniać oczekiwania klienta *Ewolucja oprog.: Oprog. musi
ewoluować, aby spełniać zmieniające się potrzeby użytkowników


Kategorie zagrozen

zagrozenia projektu maja wpływ na zasoby i
harmonogram przedsiewziecia,
zagrozenia produktu maja wpływ na jakosc i
efektywnosc budowanego oprogramowania
zagrozenia przedsiebiorstwa maja wpływ na
przedsiebiorstwo budujace badz zaopatrujace sie
w oprogramowanie.