1) Opisz cykl życia oprogramowania

Cykl życia oprogramowania (ang. software lifecycle) — ciąg działań projektowo-programowych, obejmujący zakres od powstania zapotrzebowania na oprogramowanie aż do jego wycofania z eksploatacji. Obejmuje wiele etapów składających się na projektowanie, programowanie (kodowanie), testowanie i wdrażanie oprogramowania oraz czas jego użytkowania. Nowa wersja oprogramowania na ogół wymaga zmiany lub rozszerzenia wyposażenia sprzętowego.

Zasadniczo cykl życia kolejnych wersji programu można podzielić na następujące etapy:

• wersja niestabilna (testowa) - seria wydań, podczas której dodawane są przede wszystkim nowe możliwości:

• wersja robocza (pre-alpha) , dostępna zazwyczaj tylko dla twórców programu w postaci repozytorium kodu źródłowego (np. CVS), kiedy implementowany jest algorytm programu, tworzony jest interfejs i dodawane są nowe funkcje

• wersja alfa (pre-beta), podczas której autorzy doprowadzają do rzeczywistego działania programu, nawet w ograniczonym zakresie

• wersja beta, kiedy program ma już pierwszych użytkowników, zwanych często beta-testerami, i wyłapywane są błędy związane z różnymi środowiskami i warunkami pracy programu

• RC (ang. Release Candidate, czyli Kandydat do wydania) - wydanie kandydujące, których może być nawet kilka, ale jeżeli nie zostanie w nim znalezione żadne istotne odstępstwo od planu wersji, zmienia się jedynie numer wersji na wyższy i uznaje wersję za stabilną

• RTM (ang. Release to manufacture lub Ready to market czyli Gotowy do wydania) - produkt gotowy do wypuszczenia na rynek. Nie jest dostępny publicznie do czasu premiery.

• wersja stabilna (wersja produkcyjna) - wersja nadająca się do użytkowania zgodnie z założeniami autorów

• wersje stabilne z poprawkami bezpieczeństwa lub innych błędów

ostatnim etapem jest zwykle starzenie moralne programu i porzucenie przez autorów, co zwykle kończy jego życie

2) Model kaskadowy (klasyczny): wymień fazy
Wymień zalety i wady modelu kaskadowego.

- fazę określania wymagań w której określane są cele oraz szczegółowe wymagania wobec tworzonego systemu

- fazę projektowania, w której powstaje szczegółowy projekt systemu spełniającego ustalone wcześniej wymagania

- fazę implementacji/kodowania oraz testowania modułów, w której projekt zostaje zaimplementowany w konkretnym środowisku programistycznym oraz wykonywane są testy poszczególnych modułów

- fazę testowania, w której następuje integracja poszczególnych modułów połączona z testowaniem poszczególnych podsystemów oraz całego oprogramowania

- fazę konserwacji, w której oprogramowanie jest wykorzystywane przez użytkowników, a producent dokonuje konserwacji oprogramowania - wykonuje modyfikacje polegające na usuwaniu błędów, zmianach i rozszerzaniu funkcji systemu

W modelu kaskadowym często wyróżnia się pewne dodatkowe fazy, które często nakładają się na fazy przedstawione powyżej:

• - faza strategiczna wykonywana przed formalnym podjęciem decyzji o realizacji przedsięwzięcia. W tej fazie podejmowane są pewne strategiczne decyzje dotyczące dalszych etapów prac. Faza ta wymaga oczywiście przynajmniej ogólnego określenia wymagań

• - faza analizy, w której budowany jest logiczny model systemu

• - faza dokumentacji, w której wytwarzana jest dokumentacja użytkownika. Opracowywanie dokumentacji przebiega równolegle z produkcją oprogramowania. Rozpoczyna się w trakcie określania wymagań, natomiast ostatnie zmiany dokonywane są w fazie instalacji

• - faza instalacji, w której następuje przekazanie systemu użytkownikowi

Podstawowe zalety tego modelu wiążą się przede wszystkim z łatwością zarządzania przedsięwzięciem. Model ten ułatwia planowanie, harmonogramowanie oraz monitorowanie przedsięwzięcia.

Wady:

- Narzucanie twórcom oprogramowania scisłej kolejności wykonywania prac

- Wysoki koszt błędów popełnianych we wstępnych fazach. Błędy popełnione w fazie określania wymagań zastaną najprawdopodobniej wykryte dopiero w fazie testowania lub konserwacji

- Długa przerwa w kontaktach z klientem

3) Wymień modele cyklu życia oprogramowania.

• - Model kaskadowy - zakłada stabilny ze-staw potrzeb i ich niezmienność w trakcie budowy SI, (po każdym etapie powstaje dokument, sprawdzenie po pozytywnej weryfikacji następny etap)

• - Realizacja kierowana dokumentami

• - Prototypowanie - Prototyp - model SI działający lub demonstrujący działanie przyszłego systemu. Obszary działania (szybkie sprawdzenie koncepcji systemu; projektowanie przez prototypowa-nie; budowa przez prototypowanie)

• - Programowanie odkrywcze

• - Realizacja przyrostowa - (brak wydzielonej jawnej fazy ryzyka)

• - Montaż z gotowych elementów - (projekt; zakup elementów od dostawców; integracja, łączenie ich w SI) Zalety: wysoka niezawodność, zmniejszenie ryzyka, efektywne wykorzystanie specjalistów
  Wady: dodatkowy koszt przygotowania elementów ponownego użycia, ryzyko uzależnienia się od dostawcy

• - Model Spiralny - Fazy: - planowanie - analiza ryzyka - konstruowanie - weryfikacja

• - Formalne transformacje

4) (Jr2)Narysuj diagramy: model kaskadowy z powtórzeniami; model kierowany dokumentami (document driven); model prototypowania, model realizacji przyrostowej, model spiralny. Krótko scharakteryzuj każdy z modeli (wymień zalety i wady).

a) Model Kierowany dokumentami

Metoda stosowana w armii amerykańskiej realizującej wiele złożonych przedsięwzięć informatycznych. W modelu tym jako podstawę działań przyjmuje się model kaskadowy, wzbogacając go o elementy szcze­gółowej dokumentacji prac, składa się więc z szeregu następujących po sobie faz. Każda faza kończy się opracowaniem szeregu dokumentów, w pełni opisujących wyniki tej fazy.Dokumenty te powinny być wystarczającą podstawą do realizacji dalszych faz. Dokumenty te są udostępniane klientów i dopiero po zaakceptowaniu dokumentacji przez klienta rozpoczynana jest kolejna faza.

+ Zalety

możliwość realizacji dalszych faz przez inną firmę,

łatwe planowanie, harmonogramowanie oraz monitorowanie przedsięwzięcia

aktywnie włączenie użytkownika w proces realizacji projektu

- Wady

duży nakład pracy na opracowanie dokumentów zgodnych ze standardem

przerwy w realizacji niezbędne dla weryfikacji dokumentów przez klienta

b) model kaskadowy

Zalety:

• - ułatwia organizację: planowanie, harmonogramowanie, monitorowanie przedsięwzięcia

• - zmusza do zdyscyplinowanego podejścia

• - wymusza kończenie dokumentacji po każdej fazie

• - wymusza sprawdzenie każdej fazy przez SQA

Wady:

• - narzuca twórcom oprogramowania ścisłą kolejność wykonywania prac

• - występują trudności w sformułowaniu wymagań od samego początku

• - powoduje wysokie koszty błędów popełnionych we wczesnych fazach,

• - powoduje długie przerwy w kontaktach z klientem.

• - brak jest weryfikacji i elastyczności

• - możliwa jest niezgodność z faktycznymi potrzebami klienta

• - niedopasowanie - rzeczywiste przedsięwzięcia rzadko są sekwencyjne

• - realizatorzy kolejnych faz muszą czekać na zakończenie wcześniejszych

Stosowany w projekcie o dobrze zdefiniowanych wymaganiach dla dobrze rozumianych zastosowań. Rzadko stosuje się ten model w czystej postaci, ale stanowi on bazę dla innych modeli powstałych

jako jego udoskonalenia.

c) model kaskadowy z iteracjami

Model kaskadowy z iteracjami (z nawrotami) Jest to odmiana modelu kaskadowego

W czystym modelu kaskadowym:

• - zaplanowane fazy pracy powinny być w zasadzie realizowane po kolei;

• - konieczność powrotu do wcześniejszej fazy traktuje się jako nieprawidłowość, czyli sytuację awaryjną.

W iteracyjnym modelu kaskadowym:

• - Takie powroty z góry się przewiduje, daje to większą elastyczność, ale wydłuża czas przedsięwzięcia

• - Każda faza kończy się sporządzeniem szeregu dokumentów w których opisuje się wyniki danej fazy.

• - Łatwe planowanie, harmonogramowanie oraz monitorowanie przedsięwzięcia.

• - Dodatkowa zaleta: (teoretyczna) możliwość realizacji dalszych faz przez inną firmę.

Wady:

- Duży nakład pracy na opracowanie dokumentów zgodnych ze standardem

- Przerwy w realizacji niezbędne dla weryfikacji dokumentów przez klienta.

d) model spiralny

Proces tworzenia ma postać spirali, której każda pętla reprezentuje jedną fazę procesu. Najbardziej wewnętrzna pętla przedstawia początkowe etapy projektowania, np. studium wykonalności, kolejna definicji wymagań systemowych, itd.

Zalety:

• - Do dużych systemów - szybka reakcja na pojawiające się czynniki ryzyka

• - Połączenie iteracji z klasycznym modelem kaskadowym

Wady:

• - Trudno do niego przekonać klienta

• - Konieczność umiejętności szacowania ryzyka, problemy, gdy źle oszacujemy ryzyko

e) model prototypowania

Prototypowanie - sposób na uniknięcie zbyt wysokich kosztów błędów popełnionych w fazie określania wymagań. Zalecany w przypadku, gdy określenie początkowych wymagań jest stosunkowo łatwe.

Model kaskadowy wymaga określenia wymagań na samym początku pracy. Możemy to ułatwić przez zbudowanie prototypu. Występują wówczas dodatkowe fazy projektu poprzedzające wykonanie zadań zgodnych ze zwykłym modelem kaskadowym:

- wstępne określenie wymagań,

- budowa prototypu

- weryfikacja prototypu przez klienta

- pełne określenie wymagań

- realizacja pełnego systemu zgodnie z modelem kaskadowym

Cele:

- wykrycie nieporozumień pomiędzy klientem, a twórcami systemu

- wykrycie brakujących funkcji

- wykrycie trudnych usług

- wykrycie braków w specyfikacji wymagań

Takie podejście zwiększa koszt przedsięwzięcia, ale:

- prototyp nie musi być wykonany w pełni,

- nie musi być niezawodny, ani starannie przetestowany,

- nie musi działać szybko ani mieć dobrego interfejsu użytkownika,

- może być realizowany w nieoptymalnych językach bardzo wysokiego poziomu, można nie instalować go u klienta.

Zalety prototypowania:

• - lepsze poznanie potrzeb i wymagań klienta

• - możliwość szybkiej demonstracji pracującej wersji systemu

• - możliwość szkoleń zanim zbudowany zostanie pełny system

Wady:

• - niezadowolenie klienta, który po obejrzeniu działającego prototypu musi następnie długo czekać na dostawę gotowego systemu

• - (pozorna) koszt budowy prototypu

Metody prototypowania

• - Niepełna realizacja: objęcie tylko części funkcji

• - Języki wysokiego poziomu: Smalltalk, Lisp, Prolog, 4GL, ...

• - Wykorzystanie gotowych komponentów

• - Generatory interfejsu użytkownika: wykonywany jest wyłącznie interfejs, wnętrze systemu jest “podróbką”.

• - Szybkie programowanie: normalne programowanie, ale bez zwracania uwagi na niektóre jego elementy, np. zaniechanie testowania

f) model realizacji przyrostowej

Jest to odmiana modelu spiralnego. Wybierany jest i realizowany podstawowy zestaw funkcji. Po realizacji pewnych funkcji następuje zrealizowanie i dostarczenie kolejnych funkcji.

Zalety:

• - skrócenie przerw w kontaktach z klientem

• - możliwość wczesnego wykorzystania przez klienta dostarczonych fragmentów systemu

• - możliwość elastycznego reagowania na powstałe opóźnienia

Wady:

- dodatkowy koszt towarzyszący niezależnej realizacji fragmentów systemu

5) Wymień zagadnienia, jakie obejmuje inżynieria oprogramowania (J12)

- sposoby prowadzenia przedsięwzięć informatycznych

- techniki planowania, szacowania kosztów, harmonogramowania i monitorowania przedsięwzięć programistycznych

- metody analizy i programowania systemów

- techniki zwiększania niezawodności oprogramowania

- sposoby przygotowania dokumentacji technicznej i użytkowej

- procedury kontroli jakości

- metody redukcji kosztów konserwacji (usuwania błędów, modyfikacji i rozszerzeń)

- techniki pracy zespołowej i czynniki psychologiczne wpływające na efektywność pracy

6) Scharakteryzuj w jednym-dwóch zadaniach każdą z faz cyklu życia oprogramowania

• - f.strat.: podjęcie decyzji dotyczących dalszych etapów przedsięwzięcia, określenie ogólnych wymagań,

• - f. okr. wymag.: określane są cele oraz szczegółowe wymagania wobec tworzonego systemu,

• - f. analizy: budowany jest logiczny model systemu,

• - f. projektow.: powstaje szczegółowy projekt systemu z projektem klas,

• - f. implem.: pisana jest implementacja zaprojektowanego systmeu,

• - f. testowania: testowanie,

• - f. dokumentowania: tworzona jest dokumentacja,

• - f. instalacji: instalowanie i szkolenie użytkowników,

• - f. konserwacji: pielęgnacja, modyfikacja, usuwanie zgłoszonych usterek.

7) (Jr3) Wymień czynności wykonywane w czasie fazy strategicznej.

- dokonanie serii rozmów/wywiadów z przedstawicielami klienta,

- określenie celów przedsięwzięcia z punktu widzenia klienta,

- określenie zakresu oraz kontekstu przedsięwzięcia,

- ogólne określenie wymagań, wykonanie zgrubnej analizy i projektu systemu,

- propozycja kilku możliwych rozwiązań (sposobu realizacji) systemu,

- oszacowanie kosztów oprogramowania,

- analiza rozwiązań,

- prezentacja wyników fazy strategicznej klientowi oraz korekcja wyników na podstawie uzyskanych uwag,

- określenie wstępnego harmonogramu oraz struktury zespołu realizującego przedsięwzięcie,

- określenie standardów, zgodnie, z którymi realizowane będzie przedsięwzięcie.

8) (Jw35) Wymień kryteria oceny rozwiązań. Sposoby oceny rozwiązań (Js35 i nast.)

W zależności od kontekstu przedsięwzięcia kryteria oceny rozwiązań mogą być różne:

• koszt

• czas realizacji

• niezawodność

• stopień możliwości ponownego wykorzystania fragmentu systemu.

• przenośność na inne platformy.

Rozwiązanie	A	B	C
Koszt [tyś zł.]	120	80	175
Czas [m-ce]	33	30	36
Niezawodność [liczba błędów/ tydz.]	5	9	13
Ponowne wykorzystanie [%]	40	40	30
Przenośność [%]	90	75	30
Wydajność [transakcji/s ]	0,35	0,75	1

Sposoby oceny rozwiązań:

• Pierwszym krokiem powinno być usunięcie rozwiązań zdominowanych,
  (rozwiązanie zdominowanie - gdzie inne rozwiązanie jest nie gorsze od żadnego kryterium i lepsze, o co najmniej jedno kryterium) Gdyby wydajność „C” była równa 0,75 [trans/s] to „C” byłoby zdominowane.

• Poszczególne kryteria oceny, różnią się z reguły swoim znaczeniem, dlatego można nadać im pewne wagi, a także znormalizować wartości kryteriów, aby były z podobnego zakresu (np. [0,1]), gdzie 0 - to najgorsza wartość, a 1 - najlepsza wartość kryterium.

Rozwiązanie	A	B	C	Waga
Koszt [tyś zł.]	0,58	1	0	3
Czas [m-ce]	0,5	1	0	2
Niezawodność [liczba błędów/ tydz.]	1	0,5	0	3
Ponowne wykorzystanie [%]	1	1	0	1
Przenośność [%]	1	0,75	0	1
Wydajność [transakcji/s ]	0	0,62	1	1,5
Łączna ocena	7,74	9,17	1,5

Wartości znormalizowane, po przemnożeniu przez wagi kryteriów, mogą być zsumowane w celu otrzymania łącznej oceny rozwiązań.


• Niepewność jest czynnikiem utrudniającym wybór najlepszego rozwiązania, przy braku dodatkowych informacji można wybrać strategię:

• Konserwatywną (pesymistyczną) (Rozwiązanie B)

• Optymistyczną (Rozwiązanie A)

Rozwiązanie	A	B
Pesymistyczny koszt [tyś zł]	100	80
Optymistyczny koszt [tyś zł]	40	65

Rozwiązanie	A	B
Prawdopodobieństwo pesymistycznego rozwiązania	0,5	0,2
Prawdopodobieństwo optymistycznego rozwiązania	0,5	0,8

• Powyższe informacje pozwalają obliczyć tzw. Spodziewany koszt dla poszczególnych opcji: Spodziewany koszt rozwiązania = koszt pesymistyczny * prawdopodobieństwo zajścia tego zdarzenia + koszt optymistyczny * prawdopodobieństwo zajścia tego zdarzenia,
  Spodziewany koszt rozwiązania A = 0,5 * 100 + 0,5 * 40 = 70 tyś zł..
  Spodziewany koszt rozwiązania B = 0,2 * 80 + 0,8 * 65 = 68 tyś. zł.
  

9) Wymień techniki szacowania kosztów oprogramowania (Js39 i nast.)

• Modele algorytmiczne. Techniki te wymagają opisu danego przedsięwzięcia za pomocą szeregu atrybutów liczbowych i/lub opisowych. Odpowiedni algorytm (często zwykła formuła matematyczna) daje następnie w wyniku spodziewany nakład pracy.

• Ocena przez eksperta(ów). Doświadczone osoby często z dużą precyzją potrafią oszacować koszt realizacji nowego systemu.

• Ocena przez analogią. Metoda ta wymaga dostępu do informacji o poprzednio realizowanych przedsięwzięciach. Mogą to być przedsięwzięcia wykonywane w firmie, która wykonuje szacowanie kosztów lub w innych firmach o podob­nym profilu. Komercyjnie sprzedawane są np. bazy danych zawierających informacje o różnorodnych przedsięwzięciach realizowanych przez rozmaite firmy. Ogólnie rzecz biorąc metoda ta polega na wyszukaniu przedsięwzięcia (przed­sięwzięć) podobnych do aktualnie rozważanego i wykorzystaniu informacji o na­kładach poniesionych na ich realizację. Do tej grupy technik należy tez zaliczyć stosowanie systemów automatycznego uczenia się (sieci neuronowych, syste­mów regułowych). System taki uczy się na podstawie pewnego zbioru przed­sięwzięć, a następnie jest wykorzystywany do oceny nowych przedsięwzięć.

• Prawo Parkinsona. Jest to prawo, które stwierdza, że przedsięwzięcia, w tym także przedsięwzięcia programistyczne, praktycznie zawsze są wykonywane przy założonych nakładach.

• Wycena dla wygranej (ang. pricing to win). Koszt oprogramowania szacowany jest na podstawie oceny możliwości klienta(ów) oraz przewidywanych działań konkurentów. Prawo Parkinsona pozwala wierzyć, że przedsięwzięcie i tak zmieści się w założonych nakładach. Moje doświadczenie wskazuje, że jest to technika często stosowana przez firmy biorące udział w przetargach na opracowanie oprogramowania.

• Szacowanie wstępujące. Realizację przedsięwzięcia dzieli się mniejsze zadania, których koszt jest łatwiejszy do oszacowania. Następnie oblicza się koszt całego przedsięwzięcia. Przykładem szacowania wstępującego są techniki harmonogramowania omawiane w sekcji 13.8.

10) Opisz metodę COCOMO I i COCOMO II

COCOMO (ang. constructive cost model) - model szacowania liczby osobogodzin w procesie tworzenia oprogramowania.

Opracował go Barry Boehm w 1981 roku pracując w Boeing Company na podstawie około 60 projektów informatycznych o różnej złożoności (od 2 KDSI do 100 KDSI) i napisanych w różnych językach programowania.

Postępowanie

ustalenie metryki

Aby oszacować liczbę osobogodzin należy najpierw oszacować, z ilu linijek kodu lub function points będzie się składać gotowy projekt. Liczba linijek kodu jest przedstawiana w KDSI [1 KDSI = 1000 linijek].

Ustalenie złożoności

Następnie należy wybrać, do której z trzech poniższych grup pasuje analizowany projekt.

„basic COCOMO”

• Łatwy ("organic mode"), to projekt, w którym mały zespół posługuje się znanymi narzędziami pracy. Zna on sprzęt i oprogramowanie, z którymi rozwijany projekt będzie redagować. Presja czasu jest mała. Łatwe projekty są wielkości do max. 50 KDSI.

• Pośredni projekt ("semi-detached"), to projekt, w którym jeden z czynników z projektu prostego nie jest znany, np. zespół nie zna sprzętu, który przyjdzie mu programować itp. Takie projekty są zwykle wielkości do 300 KDSI.

• Trudny ("embedded mode"), to bardzo złożony projekt, wiele czynników jest nieznanych lub należy uwzględnić szczególne procedury,np. w branży bankowej.

„Intermediate COCOMO” - dodatkowe wymagania

• Produktu (wymagana czytelność stworzonego oprogramowania,wielkość bazy danych, skomplikowanie)

• Sprzętu (ograniczenia związane z wydajnością, czy tworzony system jest systemem czasu rzeczywistego, ograniczenia pamięci)

• Personelu (analiza możliwości, Doświadczenie w tworzeniu oprogramowania, doświadczenie w tworzeniu oprogramowania danego typu, doświadczenie w tworzeniu oprogramowania wykorzystującego dane środowisko, sprzęt czy język programowania)

• Projektu (jakie narzędzia są potrzebne?, jakie metody tworzenia oprogramowania będą wykorzystywane?, jaki jest harmonogram projektu?, jaka jest presja czasu?)

Wzory:

E=ab(KDSI)bb

D=cb(E)db

P=E/D

E - nakładem pracy w osobomiesiącach, D - potrzebny do rozwoju projektu P - liczba osób, przy której projekt będzie najefektywniej zrealizowany.

Software project	ab	bb	cb	db
Organic	2.4	1.05	2.5	0.38
Semi-detached	3.0	1.12	2.5	0.35
Embedded	3.6	1.20	2.5	0.32

11) Wymień podstawowe rezultaty f. strategicznej (Js45)

- udostępniony klientowi raport obejmujący (tu wyszczególnić: definicję celów, opis zakresu przedsięwzięcia, opis systemów zewnętrznych z jakimi system będzie współpracować, ogólny opis wymagań, opis proponowanego rozwiązania, oszacowanie kosztów, wstępny harmonogram prac),

- raport oceny rozwiązań,

- opis wymaganych zasobów,

- definicje standardów,

12) Wymagania funkcjonalne i niefunkcjonalne, opisz je, podaj przykłady.

Wymagania funkcjonalne

Stwierdzenia opisujące, jakie usługi ma oferować system, jak ma reagować na określone dane wejściowe oraz jak ma reagować w określonych sytuacjach.

• Opisują funkcjonalność lub usługi, które system powinien oferować

• Zależą od rodzaju tworzonego oprogramowania, spodziewanych użytkowników oprogramowania i rodzaju wytwarzanego systemu

• Wymagania użytkownika mają zazwyczaj postać ogólną, natomiast systemowe szczegółowo definiują funkcje systemu, wejścia wyjścia wyjątki itd..

• Kiedy wymagania nie są precyzyjnie wyrażone powstają problemy

• Nieprecyzyjne wymagania są różnie interpretowane przez użytkowników i programistów

Przykłady

• Użytkownik będzie mógł przeszukać zbiór wszystkich danych lub wybrany podzbiór.

• System dostarczy narzędzi do przeglądania dokumentów ze magazynu dokumentów.

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

Wymagania niefunkcjonalne

Ograniczenia usług i funkcji systemu obejmujące: ograniczenia czasowe, ograniczenia dotyczące procesu tworzenia, standardy itd.

• Opisują właściwości i ograniczenia systemu np. niezawodność, czas odpowiedzi, ilość miejsca na dysku.

• Wymagania stawiane procesowi mogą specyfikować użycie określonego narzędzia, języka programowania lub metodologii projektowej.

• Wymagania niefunkcjonalne mogą być istotniejsze od funkcjonalnych. Jeśli nie będą spełnione system będzie bezużyteczny.




Przykłady

Wymaganie produktowe

4.C.8 Wszelka niezbędna komunikacja między APSE i użytkownikiem powinna dać się wyrazić za pomocą standardowego zestawu symboli Ady

Wymagania organizacyjne

9.3.2 Proces tworzenia systemu i końcowe dokumenty powinny być zgodne z procesem i produktami zdefiniowanymi w XYZCo-SP-STAN-95

Wymagania zewnętrzne

7.6.5 System nie powinien ujawniać operatorom żadnych danych osobowych klientów oprócz nazwisk i numerów identyfikacyjnych

13) Wymień co powinien zawierać dokument opisujący wymagania (Js49).

- wprowadzenie (opisać jego zawartość)

- opis ewolucji systemu,

- opis wymagań funkcjonalnych i specyfikacja wymagań funkcjonalnych, ,

- opis wymagań niefunkcjonalnych i specyfikacja wymagań niefunkcjonalnych,

- model systemu,

- słownik,

14) Napisz podstawowe rezultaty fazy określania wymagań (Js60)

- dokument opisujący wymagania składający się z:

* wprowadzenia opisującego cele, zakres i kontekst systemu,

* opisu ewolucji systemu, to jest opis przewidywalnych zmian wymagań wobec systemu,

* opisu wymagań funkcjonalnych,

* opisu wymagań niefunkcjonalnych,

* modelu systemu,

* słownika,

oraz następujących opcjonalnych dodatków:

* specyfikacji wymagań funkcjonalnych,

* specyfikacji wymagań niefunkcjonalnych,

* opisu wymagań sprzętowych,

* opisu wymagań dotyczących bazy danych,

* indeksu,

- plan testów

15) Podaj cel fazy analizy (Jr5,1-2)

Celem fazy analizy jest udzielenie odpowiedzi na pytanie: jak system ma działać? Wynikiem jest logiczny model systemu, opisujący sposób realizacji przez system postawionych wymagań, lecz abstrahujący od szczegółów implementacyjnych. Ponieważ celem fazy analizy jest budowa logicznego modelu systemu jest ona także nazywaną fazą modelowania.

16) Opisz techniki programistyczne, które zwiększają możliwości popełnienia błędów (Jr7.1.1).

Pewne techniki programistyczne zwiększają możliwość popełnienia błędów. Są to:

-Instrukcja goto lub inne o podobnym działaniu. Instrukcje te zaburzają naturalną strukturę algorytmu.

-Liczby zmiennoprzecinkowe. Obliczenia z wykorzystaniem liczb zmiennoprzecinkowych wykonywane są ze skończoną dokładnością. Błędy zaokrągleń mogą być stosunkowo duże nawet w przypadku pojedynczych operacji, zwłaszcza wtedy, gdy poszczególne liczby zdecydowanie różnią się wielkością. Błędy zaokrągleń pojedynczych operacji mogą się kumulować prowadząc do bardzo poważnych błędów obliczeń. Wiele błędów wiąże się także z porównaniem liczb zmiennopozycyjnych. Dwa wyrażenia , które z matematycznego punktu widzenia dają dokładnie ten sam wynik, mogą dać nieznacznie różniące się rezultaty w przypadku realizacji komputerowej.

-Wskaźnik. Posługiwanie się wskaźnikami prowadzi do wielu błędów dostępu do pamięci. Wskaźniki mogą prowadzić także do sytuacji, w których te same zmienne maja rożne etykiety.

-Obliczenia równoległe. Stosowanie obliczeń równoległych prowadzi do złożonych zależności czasowych, które mocno utrudniają uruchamianie oprogramowania. Wiele błędów nie ujawnia się w momencie śledzenia programu. Możliwe jest także równoczesne operowanie na tych samych danych przez różne procesy.

-Przerwania. Technika ta wprowadza rodzaj równoległości, wiążą się wiec z nią te same problemy jak z obliczeniami równoległymi. Dodatkowo istnieje ryzyko przerwania procesów krytycznych czasowo.

-Rekursja. Stosowanie tej techniki utrudnia śledzenie programu. Często jest także przyczyną zapętlenia się programu.

-Tryby pracy procedur (funkcji, metod), które realizują wyraźnie odmienne zadania w zależności od informacji kontrolnej przekazanej jako parametr wejściowy.

-Złożone wyrażenia wymagające uwzględniania priorytetów operatorów. Wielu błędów unika się rozbijając złożone wyrażenia na kilka krótszych lub zawsze ujmując podwyrażenia w nawiasy nawet wtedy, gdy (jak się programiście wydaje) nie jest to konieczne ze względu na priorytety operatorów.

17) Napisz, jakie dokumenty składają się na "standardy firmy programistycznej"

Standardy programistyczne firmy (wg. AK)

-Spis ograniczeń stosowanych w używanym w firmie języku programowania i/lub spis zaleceń w edycji pliku oraz ograniczeń stosowanych w używanych w firmie językach programowania.

Standardy programistyczne powinny uwzględniać kilka pod standardów:

- sposobu edycji instrukcji, sposobu komentowania

- nakazy umieszczania w nagłówku pliku informacji o treści pliku oraz autorach pliku oraz autorach zmian dokonywanych treści pliku

-wykaz instrukcji jakich nie należy używać

-wykaz ograniczeń w stosowaniu instrukcji

Standard powinien zawierać:

-nazwa, autorzy, data przyjęcia do stosowania , spis update'ów (data, autor), postępowanie w przypadku odstępstwa,

-standard dla języka… (np. C++)

*zawartość komentarzy na początku pliku zarówno dla pliku headera jak i pliku z implementacją

*zalecenia edycji (5-10 zaleceń)

*ograniczenia standardu (5-10 ograniczeń)

18) Wymień czynniki, jakie wpływają na jakość dokumentacji.

Na jakość dokumentacji wpływają następujące czynniki:

-Struktura. Poszczególne podręczniki powinny być w czytelny i zrozumiały sposób podzielone na rozdziały, podrozdziały i sekcje.

-Zachowanie standardów. Poszczególne podręczniki oraz fragmenty tego samego podręcznika powinny mieć spójną strukturę, formę i sposób pisania.

-Sposób pisania.

19) Na czym polega atestowanie (validation) a na czym weryfikacja (verification)?

-atestowanie (validation), czyli testowanie zgodności systemu z rzeczywistymi potrzebami użytkownika,

-weryfikacja(verification), czyli testowanie zgodności systemu z wymaganiami zdefiniowanymi w fazie określenia wymagań.

20) Z jakich "dokumentów" składa się dokumentacja przedsięwzięcia programistycznego.

- Opis funkcjonalny: wstępna część dokumentacji, która opisuje przeznaczenie i główne możliwości systemu.

- Podręcznik użytkownika: opis systemu przeznaczony gównie dla początkujących użytkowników. Powinien zawierać informacje o:

- sposobach uruchamiania oraz kończenia systemu

- realizacja najczęściej wykonywanych funkcjach systemu

- metody obsługi błędów

- sposoby korzystania z pomocy

- Kompletny opis: część przeznaczona dla doświadczonych użytkowników: powinna zawierać:

- szczegółowy opis wszystkich funkcji

- informacje o sposobach wywołania funkcji

- opisy formatów danych

- opisy błędów, które mogą się pojawić podczas pracy z systemem

- informacje o ograniczeniach

- Opis instalacji

- Podręcznik administratora systemu: możliwości zmian konfiguracji systemu i sposoby udostępniania systemu użytkownikom końcowym.

21) Podaj zadania osoby odpowiedzialnej za QA.

Zadania kontrolera jakości w "naszym" przedsięwzięciu (czyli obowiązki osoby zatrudnionej jako QA):

• sprawdza zgodność kodu ze standardami firmy,

• [otrzymuje od projektantów]/[sam sporządza] dokument "Usta klas" , odpowiada za uaktualnianie tego dokumentu,

• wypełnia dla każdej klasy dokument pt. "QA class document" zawierający jedną klasę i potwierdzający jej zgodność ze standardem .



-wypełnia odpowiednie rubryki w dokumencie "Progress Report" czyli "Tablica
postępów",

-sprawuje pieczę nad dokumentacją testowania.

22) Wymień rodzaje testów.

Z punktu widzenie głównego celu:

- wykrywanie błędów, czyli testy, których głównym celem jest wykrycie jak największej ilości błędów w programie (masło maślane, kurwa!)

- testy statystyczne, których celem jest wykrycie przyczyn najczęstszych błędnych wykonań oraz ocena niezawodności systemu

Z punktu widzenia podstawowej techniki wykonywanie testów:

- testy dynamiczne, które polegają na wykonaniu (fragmentu) programu i porównaniu uzyskanych wyników z wynikami poprawnymi

- testy statystyczne, oparte na analizie kodu

Testowanie systemu przebiega przez następujące fazy:

- Testy modułów (już w fazie implementacji)

- Testy systemu (integrowane są poszczególne moduły i testowane są poszczególne podsystemy jak i również jako całość).

- Testy akceptacji (testy alfa):

- w przypadku programu na zamówienie: program wysyłany do klienta i sprawdzany przez niego.

- w przypadku programu sprzedawanego rynkowo: nieodpłatne przekazanie pewnej ilości kopii programu pewnej grupie użytkowników.

23) Opisz testowanie statystyczne.

Testy statystyczne przebiegają wg następującego schematu:

- losowa konstrukcja danych wejściowych zgodnie z rozkładem prawdopodobieństwa tych danych

- określanie wyników poprawnego działanie systemu na tych danych

- uruchomienie systemu oraz porównanie wyników jego działanie z poprawnymi wynikami

Powyższe czynności wykonywane są cyklicznie.

Stosowanie testów statystycznych wymaga określenie rozkładu prawdopodobieństwa danych wejściowych możliwie bliskiego rozkładowi, który pojawi się podczas rzeczywistego korzystania z systemu. Założeniem testów statystycznych jest położenie nacisku na przetestowanie działania systemu w typowych sytuacjach (typowe dane wejściowe są częściej generowane niż nietypowe).

Wikipedia:

Testy statystyczne są formą testowania oprogramowania bez uruchamiania programu podczas testów. Test najczęściej wykonywany jest przez twórców kodu jako pierwsze i podstawowe sprawdzenie każdego programu. Testowanie statyczne sprawdza podstawową poprawność kodu i pozwala ocenić, czy program jest gotowy na bardziej szczegółowe testowanie.

W testowaniu statystycznym można wyróżnić podstawową analizę kodu (czytanie i wyszukiwanie w składni błędów takich jak nie zakończone pętle, złe odwołania do pamięci czy też niezainicjowane zmienne) i precyzyjne wyszukiwanie typowych błędów (najczęściej dokonywane przez programistów poprzez dokładne czytanie ze zrozumieniem całego kodu programu w celu wykrycia typowych błędów które nie są wykrywane przez narzędzia programistyczne, natomiast mogą doprowadzić do błędnych wykonań w programie).

24) W jaki sposób zależy niezawodność od liczby testów (podaj także wzór).

Po wykryciu błędnych wykonań poszukiwane są ich przyczyny, tj. błędy, które są następnie usuwane z programu. Jeżeli nie wprowadza się przy tym równej lub większej ilości błędów, to w trakcie testowania wzrasta niezawodność oprogramowania. Jeżeli wykonywane są testy czystko statyczne, wzrost niezawodności powinien przebiegać zgodnie z nast. modelem:

wzór:

Niezawodność = niezawodność początkowa * exp *( C x liczba testów )

Jest to tzw. logarytmiczny model wzrostu niezawodności oprogramowania, w powyższym wyrażeniu zakłada się, że miarą niezawodności systemu jest częstotliwość występowania błędnych wykonań. Stała C zależy od konkretnego systemu, można ją określić na podstawie niezawodności systemu systemu w trakcie testowania metodą regresji nieliniowej, np. metodą najmniejszych kwadratów.

25) Opisz, na czym polegają testy statystyczne.

- patrz punkt 23

26) Opisz testy strukturalne.

Testy strukturalne:

Przypadku testów strukturalnych, dane wejściowe dobiera się na podstawie analizy struktury programu realizującego testowane funkcje. Proponuje się w tym wypadku kilka kryteriów doboru danych testowych.

- Kryterium pokrycia wszystkich instrukcji

- Kryterium pokrycia instrukcji warunkowych

Wikipedia:
Testy strukturalne znane są także jako testy białej lub szklanej skrzynki. Polegają na testowaniu programu poprzez podawanie na wejściu takich danych, aby program przeszedł przez każdą zaimplementowaną ścieżkę. Zasady te są definiowane przez kryteria pokrycia wszystkich pętli oraz wszystkich warunków. Testy białej skrzynki nie są w stanie wykazać braku implementacji funkcji, którą powinien posiadać system docelowy. Sprawdzają jednak dokładnie operacje wykonywane w zaimplementowanych metodach.

Nierzadko w trakcie testowania programu techniką szklanej skrzynki wprowadzane są do wnętrza programu sztucznie specjalnie spreparowane dane w celu dokładniejszego przetestowania reakcji. Ten sposób nazywamy metodą „Słonia w Kairze”.

27) Jakie elementy składają się na fazę instalacji (Jr10)

- szkolenia użytkowników końcowych i administratorów systemu,

- instalacja sprzętu i przeniesienie oprogramowania,

- wypełnienie koniecznych baz danych,

- nadzorowanie korzystania z systemu, często równoległe z tradycyjnym sposobem pracy,

- usuwanie błędów w oprogramowaniu i dokumentacji użytkowej,

- przekazanie systemu klientowi.

28) Na czym polega inżynieria odwrotna (reverse engineering) (Jr11.2)

Inżynieria odwrotna jest procesem polegającym na odtworzeniu dokumentacji technicznej na podstawie istniejącego kodu,( czasami na podstawie struktur baz danych). Nazywa się e ten sposób, ponieważ jest on odwróceniem kolejności czynności wykonywanych w trakcie budowy oprogramowania. W fazie implementacji wykonywana jest transformacja projektu do kodu. Należy przy tym pamiętać, że opis projektu po zakończeniu implementacji staje się dokumentacją techniczną. Inżynieria odwrotna jest więc próbą odtworzenia projektu, na bazie którego mogłoby powstać istniejące oprogramowanie. Inżynieria odwrotna jest procesem, który da się automatyzować. Moduły Inż. Odwrot. są więc częstymi składowymi narzędzi CASE

29) Wymień (i opisz) trzy główne klasy modyfikacji wprowadzanych w oprogramowanie

30) Wymień czynniki wpływające na redukcję kosztów konserwacji.

Na redukcję kosztów konserwacji wpływają następujące czynniki:

• Znajomość dziedziny problemu. Jeżeli analitycy pracujący nad systemem dobrze znają daną

dziedzinę problemu, mają mniej trudności z właściwym zebraniem wymagań oraz budową

oddającego rzeczywistość modelu.

• Wysoka jakość modelu i projektu. W szczególności:

◦ spójność,

◦ stopień powiązań składowych,

◦ przejrzystość.

• Wysoka jakość dokumentacji technicznej. Dokumentacja techniczna powinna:

◦ w pełni odpowiadać systemowi,

◦ być wystarczająco szczegółowa,

◦ być zgodna z przyjętymi w firmie standardami.

• Stabilność personelu. Wysoka jakość projektu oraz dokumentacji technicznej nie zmienia

faktu, że pewne aspekty systemu zawsze są najlepiej znane osobom bezpośrednio

uczestniczącym w jego realizacji. Nie oznacza to automatycznie, że modyfikacje powinny

być zawsze wykonywane przez te same osoby, które opracowywały system. Jeżeli jednak

osoby te nadal pracują u producenta oprogramowania, to istnieje możliwość konsultacji w

przypadku pojawienia się innych wątpliwości i trudności.

• Środowisko implementacji. Zaawansowane środowiska implementacji, obejmujące języki

wysokiego poziomu i możliwości dialogowego projektowania i wytwarzania fragmentów

oprogramowania, wpływają na skrócenie czasu niezbędnego na wprowadzenie modyfikacji.

• Niezawodność oprogramowania. Wysoka niezawodność oprogramowania w momencie

przekazania do użytkownika zmniejsza liczbę modyfikacji, w szczególności o charakterze

poprawiającym.

• Inżynieria odwrotna. Pod tym pojęciem rozumie się odtwarzanie dokumentacji technicznej

na podstawie istniejącego oprogramowania.

• Zarządzanie wersjami.

31) Wymień stanowiska w firmie programistycznej.

- Konsultant - omawia z klientem funkcjonalność programu, ustala cenę itp.

- Programista to osoba zajmująca się tworzeniem i rozwojem oprogramowania. W dzisiejszych czasach określa często zawód nie związany z pisaniem kodu źródłowego programu, lecz wszystkie poboczne aspekty inżynierii oprogramowania. Z komercyjnego punktu widzenia, osoby tylko tworzące kod źródłowy nazywa się koderami. Z akademickiego punktu widzenia programiści to grupa naukowa doskonaląca metody optymalnego pisania kodu i osiągania coraz lepszych efektów w coraz krótszym czasie.

- Koder (implementator) - osoba, która dostaje gotowy projekt (klasy, funkcje itp.) i implementuje kod programu.

- Kierownik (Manager) Projektu - osoba odpowiedzialna i koordynująca rozwój programu.

- QA (Quality Assurance - Zapewnienie jakości) - planowe i systematyczne działania niezbędne do zapewnienia spełnienia wymagań jakości końcowego produktu w procesie jego tworzenia.

- Testerzy - Sprawdzają końcowy produkt.

- Inni: Zarząd firmy - Dyrektor, zastępcy; Księgowi itp.




1) Opisz cykl życia oprogramowania

Cykl życia oprogramowania (ang. software lifecycle) — ciąg działań projektowo-programowych, obejmujący zakres od powstania zapotrzebowania na oprogramowanie aż do jego wycofania z eksploatacji. Obejmuje wiele etapów składających się na projektowanie, programowanie (kodowanie), testowanie i wdrażanie oprogramowania oraz czas jego użytkowania. Nowa wersja oprogramowania na ogół wymaga zmiany lub rozszerzenia wyposażenia sprzętowego.

Zasadniczo cykl życia kolejnych wersji programu można podzielić na następujące etapy:

• wersja niestabilna (testowa) - seria wydań, podczas której dodawane są przede wszystkim nowe możliwości:

• wersja robocza (pre-alpha) , dostępna zazwyczaj tylko dla twórców programu w postaci repozytorium kodu źródłowego (np. CVS), kiedy implementowany jest algorytm programu, tworzony jest interfejs i dodawane są nowe funkcje

• wersja alfa (pre-beta), podczas której autorzy doprowadzają do rzeczywistego działania programu, nawet w ograniczonym zakresie

• wersja beta, kiedy program ma już pierwszych użytkowników, zwanych często beta-testerami, i wyłapywane są błędy związane z różnymi środowiskami i warunkami pracy programu

• RC (ang. Release Candidate, czyli Kandydat do wydania) - wydanie kandydujące, których może być nawet kilka, ale jeżeli nie zostanie w nim znalezione żadne istotne odstępstwo od planu wersji, zmienia się jedynie numer wersji na wyższy i uznaje wersję za stabilną

• RTM (ang. Release to manufacture lub Ready to market czyli Gotowy do wydania) - produkt gotowy do wypuszczenia na rynek. Nie jest dostępny publicznie do czasu premiery.

• wersja stabilna (wersja produkcyjna) - wersja nadająca się do użytkowania zgodnie z założeniami autorów

• wersje stabilne z poprawkami bezpieczeństwa lub innych błędów

ostatnim etapem jest zwykle starzenie moralne programu i porzucenie przez autorów, co zwykle kończy jego życie

2) Model kaskadowy (klasyczny): wymień fazy
Wymień zalety i wady modelu kaskadowego.

- fazę określania wymagań w której określane są cele oraz szczegółowe wymagania wobec tworzonego systemu

- fazę projektowania, w której powstaje szczegółowy projekt systemu spełniającego ustalone wcześniej wymagania

- fazę implementacji/kodowania oraz testowania modułów, w której projekt zostaje zaimplementowany w konkretnym środowisku programistycznym oraz wykonywane są testy poszczególnych modułów

- fazę testowania, w której następuje integracja poszczególnych modułów połączona z testowaniem poszczególnych podsystemów oraz całego oprogramowania

- fazę konserwacji, w której oprogramowanie jest wykorzystywane przez użytkowników, a producent dokonuje konserwacji oprogramowania - wykonuje modyfikacje polegające na usuwaniu błędów, zmianach i rozszerzaniu funkcji systemu

W modelu kaskadowym często wyróżnia się pewne dodatkowe fazy, które często nakładają się na fazy przedstawione powyżej:

• - faza strategiczna wykonywana przed formalnym podjęciem decyzji o realizacji przedsięwzięcia. W tej fazie podejmowane są pewne strategiczne decyzje dotyczące dalszych etapów prac. Faza ta wymaga oczywiście przynajmniej ogólnego określenia wymagań

• - faza analizy, w której budowany jest logiczny model systemu

• - faza dokumentacji, w której wytwarzana jest dokumentacja użytkownika. Opracowywanie dokumentacji przebiega równolegle z produkcją oprogramowania. Rozpoczyna się w trakcie określania wymagań, natomiast ostatnie zmiany dokonywane są w fazie instalacji

• - faza instalacji, w której następuje przekazanie systemu użytkownikowi

Podstawowe zalety tego modelu wiążą się przede wszystkim z łatwością zarządzania przedsięwzięciem. Model ten ułatwia planowanie, harmonogramowanie oraz monitorowanie przedsięwzięcia.

Wady:

- Narzucanie twórcom oprogramowania scisłej kolejności wykonywania prac

- Wysoki koszt błędów popełnianych we wstępnych fazach. Błędy popełnione w fazie określania wymagań zastaną najprawdopodobniej wykryte dopiero w fazie testowania lub konserwacji

- Długa przerwa w kontaktach z klientem

3) Wymień modele cyklu życia oprogramowania.

• - Model kaskadowy - zakłada stabilny ze-staw potrzeb i ich niezmienność w trakcie budowy SI, (po każdym etapie powstaje dokument, sprawdzenie po pozytywnej weryfikacji następny etap)

• - Realizacja kierowana dokumentami

• - Prototypowanie - Prototyp - model SI działający lub demonstrujący działanie przyszłego systemu. Obszary działania (szybkie sprawdzenie koncepcji systemu; projektowanie przez prototypowa-nie; budowa przez prototypowanie)

• - Programowanie odkrywcze

• - Realizacja przyrostowa - (brak wydzielonej jawnej fazy ryzyka)

• - Montaż z gotowych elementów - (projekt; zakup elementów od dostawców; integracja, łączenie ich w SI) Zalety: wysoka niezawodność, zmniejszenie ryzyka, efektywne wykorzystanie specjalistów
  Wady: dodatkowy koszt przygotowania elementów ponownego użycia, ryzyko uzależnienia się od dostawcy

• - Model Spiralny - Fazy: - planowanie - analiza ryzyka - konstruowanie - weryfikacja

• - Formalne transformacje

4) (Jr2)Narysuj diagramy: model kaskadowy z powtórzeniami; model kierowany dokumentami (document driven); model prototypowania, model realizacji przyrostowej, model spiralny. Krótko scharakteryzuj każdy z modeli (wymień zalety i wady).

a) Model Kierowany dokumentami

Metoda stosowana w armii amerykańskiej realizującej wiele złożonych przedsięwzięć informatycznych. W modelu tym jako podstawę działań przyjmuje się model kaskadowy, wzbogacając go o elementy szcze­gółowej dokumentacji prac, składa się więc z szeregu następujących po sobie faz. Każda faza kończy się opracowaniem szeregu dokumentów, w pełni opisujących wyniki tej fazy.Dokumenty te powinny być wystarczającą podstawą do realizacji dalszych faz. Dokumenty te są udostępniane klientów i dopiero po zaakceptowaniu dokumentacji przez klienta rozpoczynana jest kolejna faza.

+ Zalety

możliwość realizacji dalszych faz przez inną firmę,

łatwe planowanie, harmonogramowanie oraz monitorowanie przedsięwzięcia

aktywnie włączenie użytkownika w proces realizacji projektu

- Wady

duży nakład pracy na opracowanie dokumentów zgodnych ze standardem

przerwy w realizacji niezbędne dla weryfikacji dokumentów przez klienta

b) model kaskadowy

Zalety:

• - ułatwia organizację: planowanie, harmonogramowanie, monitorowanie przedsięwzięcia

• - zmusza do zdyscyplinowanego podejścia

• - wymusza kończenie dokumentacji po każdej fazie

• - wymusza sprawdzenie każdej fazy przez SQA

Wady:

• - narzuca twórcom oprogramowania ścisłą kolejność wykonywania prac

• - występują trudności w sformułowaniu wymagań od samego początku

• - powoduje wysokie koszty błędów popełnionych we wczesnych fazach,

• - powoduje długie przerwy w kontaktach z klientem.

• - brak jest weryfikacji i elastyczności

• - możliwa jest niezgodność z faktycznymi potrzebami klienta

• - niedopasowanie - rzeczywiste przedsięwzięcia rzadko są sekwencyjne

• - realizatorzy kolejnych faz muszą czekać na zakończenie wcześniejszych

Stosowany w projekcie o dobrze zdefiniowanych wymaganiach dla dobrze rozumianych zastosowań. Rzadko stosuje się ten model w czystej postaci, ale stanowi on bazę dla innych modeli powstałych

jako jego udoskonalenia.

c) model kaskadowy z iteracjami

Model kaskadowy z iteracjami (z nawrotami) Jest to odmiana modelu kaskadowego

W czystym modelu kaskadowym:

• - zaplanowane fazy pracy powinny być w zasadzie realizowane po kolei;

• - konieczność powrotu do wcześniejszej fazy traktuje się jako nieprawidłowość, czyli sytuację awaryjną.

W iteracyjnym modelu kaskadowym:

• - Takie powroty z góry się przewiduje, daje to większą elastyczność, ale wydłuża czas przedsięwzięcia

• - Każda faza kończy się sporządzeniem szeregu dokumentów w których opisuje się wyniki danej fazy.

• - Łatwe planowanie, harmonogramowanie oraz monitorowanie przedsięwzięcia.

• - Dodatkowa zaleta: (teoretyczna) możliwość realizacji dalszych faz przez inną firmę.

Wady:

- Duży nakład pracy na opracowanie dokumentów zgodnych ze standardem

- Przerwy w realizacji niezbędne dla weryfikacji dokumentów przez klienta.

d) model spiralny

Proces tworzenia ma postać spirali, której każda pętla reprezentuje jedną fazę procesu. Najbardziej wewnętrzna pętla przedstawia początkowe etapy projektowania, np. studium wykonalności, kolejna definicji wymagań systemowych, itd.

Zalety:

• - Do dużych systemów - szybka reakcja na pojawiające się czynniki ryzyka

• - Połączenie iteracji z klasycznym modelem kaskadowym

Wady:

• - Trudno do niego przekonać klienta

• - Konieczność umiejętności szacowania ryzyka, problemy, gdy źle oszacujemy ryzyko

e) model prototypowania

Prototypowanie - sposób na uniknięcie zbyt wysokich kosztów błędów popełnionych w fazie określania wymagań. Zalecany w przypadku, gdy określenie początkowych wymagań jest stosunkowo łatwe.

Model kaskadowy wymaga określenia wymagań na samym początku pracy. Możemy to ułatwić przez zbudowanie prototypu. Występują wówczas dodatkowe fazy projektu poprzedzające wykonanie zadań zgodnych ze zwykłym modelem kaskadowym:

- wstępne określenie wymagań,

- budowa prototypu

- weryfikacja prototypu przez klienta

- pełne określenie wymagań

- realizacja pełnego systemu zgodnie z modelem kaskadowym

Cele:

- wykrycie nieporozumień pomiędzy klientem, a twórcami systemu

- wykrycie brakujących funkcji

- wykrycie trudnych usług

- wykrycie braków w specyfikacji wymagań

Takie podejście zwiększa koszt przedsięwzięcia, ale:

- prototyp nie musi być wykonany w pełni,

- nie musi być niezawodny, ani starannie przetestowany,

- nie musi działać szybko ani mieć dobrego interfejsu użytkownika,

- może być realizowany w nieoptymalnych językach bardzo wysokiego poziomu, można nie instalować go u klienta.

Zalety prototypowania:

• - lepsze poznanie potrzeb i wymagań klienta

• - możliwość szybkiej demonstracji pracującej wersji systemu

• - możliwość szkoleń zanim zbudowany zostanie pełny system

Wady:

• - niezadowolenie klienta, który po obejrzeniu działającego prototypu musi następnie długo czekać na dostawę gotowego systemu

• - (pozorna) koszt budowy prototypu

Metody prototypowania

• - Niepełna realizacja: objęcie tylko części funkcji

• - Języki wysokiego poziomu: Smalltalk, Lisp, Prolog, 4GL, ...

• - Wykorzystanie gotowych komponentów

• - Generatory interfejsu użytkownika: wykonywany jest wyłącznie interfejs, wnętrze systemu jest “podróbką”.

• - Szybkie programowanie: normalne programowanie, ale bez zwracania uwagi na niektóre jego elementy, np. zaniechanie testowania

f) model realizacji przyrostowej

Jest to odmiana modelu spiralnego. Wybierany jest i realizowany podstawowy zestaw funkcji. Po realizacji pewnych funkcji następuje zrealizowanie i dostarczenie kolejnych funkcji.

Zalety:

• - skrócenie przerw w kontaktach z klientem

• - możliwość wczesnego wykorzystania przez klienta dostarczonych fragmentów systemu

• - możliwość elastycznego reagowania na powstałe opóźnienia

Wady:

- dodatkowy koszt towarzyszący niezależnej realizacji fragmentów systemu

5) Wymień zagadnienia, jakie obejmuje inżynieria oprogramowania (J12)

- sposoby prowadzenia przedsięwzięć informatycznych

- techniki planowania, szacowania kosztów, harmonogramowania i monitorowania przedsięwzięć programistycznych

- metody analizy i programowania systemów

- techniki zwiększania niezawodności oprogramowania

- sposoby przygotowania dokumentacji technicznej i użytkowej

- procedury kontroli jakości

- metody redukcji kosztów konserwacji (usuwania błędów, modyfikacji i rozszerzeń)

- techniki pracy zespołowej i czynniki psychologiczne wpływające na efektywność pracy

6) Scharakteryzuj w jednym-dwóch zadaniach każdą z faz cyklu życia oprogramowania

• - f.strat.: podjęcie decyzji dotyczących dalszych etapów przedsięwzięcia, określenie ogólnych wymagań,

• - f. okr. wymag.: określane są cele oraz szczegółowe wymagania wobec tworzonego systemu,

• - f. analizy: budowany jest logiczny model systemu,

• - f. projektow.: powstaje szczegółowy projekt systemu z projektem klas,

• - f. implem.: pisana jest implementacja zaprojektowanego systmeu,

• - f. testowania: testowanie,

• - f. dokumentowania: tworzona jest dokumentacja,

• - f. instalacji: instalowanie i szkolenie użytkowników,

• - f. konserwacji: pielęgnacja, modyfikacja, usuwanie zgłoszonych usterek.

7) (Jr3) Wymień czynności wykonywane w czasie fazy strategicznej.

- dokonanie serii rozmów/wywiadów z przedstawicielami klienta,

- określenie celów przedsięwzięcia z punktu widzenia klienta,

- określenie zakresu oraz kontekstu przedsięwzięcia,

- ogólne określenie wymagań, wykonanie zgrubnej analizy i projektu systemu,

- propozycja kilku możliwych rozwiązań (sposobu realizacji) systemu,

- oszacowanie kosztów oprogramowania,

- analiza rozwiązań,

- prezentacja wyników fazy strategicznej klientowi oraz korekcja wyników na podstawie uzyskanych uwag,

- określenie wstępnego harmonogramu oraz struktury zespołu realizującego przedsięwzięcie,

- określenie standardów, zgodnie, z którymi realizowane będzie przedsięwzięcie.

8) (Jw35) Wymień kryteria oceny rozwiązań. Sposoby oceny rozwiązań (Js35 i nast.)

W zależności od kontekstu przedsięwzięcia kryteria oceny rozwiązań mogą być różne:

• koszt

• czas realizacji

• niezawodność

• stopień możliwości ponownego wykorzystania fragmentu systemu.

• przenośność na inne platformy.

Rozwiązanie	A	B	C
Koszt [tyś zł.]	120	80	175
Czas [m-ce]	33	30	36
Niezawodność [liczba błędów/ tydz.]	5	9	13
Ponowne wykorzystanie [%]	40	40	30
Przenośność [%]	90	75	30
Wydajność [transakcji/s ]	0,35	0,75	1

Sposoby oceny rozwiązań:

• Pierwszym krokiem powinno być usunięcie rozwiązań zdominowanych,
  (rozwiązanie zdominowanie - gdzie inne rozwiązanie jest nie gorsze od żadnego kryterium i lepsze, o co najmniej jedno kryterium) Gdyby wydajność „C” była równa 0,75 [trans/s] to „C” byłoby zdominowane.

• Poszczególne kryteria oceny, różnią się z reguły swoim znaczeniem, dlatego można nadać im pewne wagi, a także znormalizować wartości kryteriów, aby były z podobnego zakresu (np. [0,1]), gdzie 0 - to najgorsza wartość, a 1 - najlepsza wartość kryterium.

Rozwiązanie	A	B	C	Waga
Koszt [tyś zł.]	0,58	1	0	3
Czas [m-ce]	0,5	1	0	2
Niezawodność [liczba błędów/ tydz.]	1	0,5	0	3
Ponowne wykorzystanie [%]	1	1	0	1
Przenośność [%]	1	0,75	0	1
Wydajność [transakcji/s ]	0	0,62	1	1,5
Łączna ocena	7,74	9,17	1,5

Wartości znormalizowane, po przemnożeniu przez wagi kryteriów, mogą być zsumowane w celu otrzymania łącznej oceny rozwiązań.


• Niepewność jest czynnikiem utrudniającym wybór najlepszego rozwiązania, przy braku dodatkowych informacji można wybrać strategię:

• Konserwatywną (pesymistyczną) (Rozwiązanie B)

• Optymistyczną (Rozwiązanie A)

Rozwiązanie	A	B
Pesymistyczny koszt [tyś zł]	100	80
Optymistyczny koszt [tyś zł]	40	65

Rozwiązanie	A	B
Prawdopodobieństwo pesymistycznego rozwiązania	0,5	0,2
Prawdopodobieństwo optymistycznego rozwiązania	0,5	0,8

• Powyższe informacje pozwalają obliczyć tzw. Spodziewany koszt dla poszczególnych opcji: Spodziewany koszt rozwiązania = koszt pesymistyczny * prawdopodobieństwo zajścia tego zdarzenia + koszt optymistyczny * prawdopodobieństwo zajścia tego zdarzenia,
  Spodziewany koszt rozwiązania A = 0,5 * 100 + 0,5 * 40 = 70 tyś zł..
  Spodziewany koszt rozwiązania B = 0,2 * 80 + 0,8 * 65 = 68 tyś. zł.

9) Wymień techniki szacowania kosztów oprogramowania (Js39 i nast.)

• Modele algorytmiczne. Techniki te wymagają opisu danego przedsięwzięcia za pomocą szeregu atrybutów liczbowych i/lub opisowych. Odpowiedni algorytm (często zwykła formuła matematyczna) daje następnie w wyniku spodziewany nakład pracy.

• Ocena przez eksperta(ów). Doświadczone osoby często z dużą precyzją potrafią oszacować koszt realizacji nowego systemu.

• Ocena przez analogią. Metoda ta wymaga dostępu do informacji o poprzednio realizowanych przedsięwzięciach. Mogą to być przedsięwzięcia wykonywane w firmie, która wykonuje szacowanie kosztów lub w innych firmach o podob­nym profilu. Komercyjnie sprzedawane są np. bazy danych zawierających informacje o różnorodnych przedsięwzięciach realizowanych przez rozmaite firmy. Ogólnie rzecz biorąc metoda ta polega na wyszukaniu przedsięwzięcia (przed­sięwzięć) podobnych do aktualnie rozważanego i wykorzystaniu informacji o na­kładach poniesionych na ich realizację. Do tej grupy technik należy tez zaliczyć stosowanie systemów automatycznego uczenia się (sieci neuronowych, syste­mów regułowych). System taki uczy się na podstawie pewnego zbioru przed­sięwzięć, a następnie jest wykorzystywany do oceny nowych przedsięwzięć.

• Prawo Parkinsona. Jest to prawo, które stwierdza, że przedsięwzięcia, w tym także przedsięwzięcia programistyczne, praktycznie zawsze są wykonywane przy założonych nakładach.

• Wycena dla wygranej (ang. pricing to win). Koszt oprogramowania szacowany jest na podstawie oceny możliwości klienta(ów) oraz przewidywanych działań konkurentów. Prawo Parkinsona pozwala wierzyć, że przedsięwzięcie i tak zmieści się w założonych nakładach. Moje doświadczenie wskazuje, że jest to technika często stosowana przez firmy biorące udział w przetargach na opracowanie oprogramowania.

• Szacowanie wstępujące. Realizację przedsięwzięcia dzieli się mniejsze zadania, których koszt jest łatwiejszy do oszacowania. Następnie oblicza się koszt całego przedsięwzięcia. Przykładem szacowania wstępującego są techniki harmonogramowania omawiane w sekcji 13.8.

10) Opisz metodę COCOMO I i COCOMO II

COCOMO (ang. constructive cost model) - model szacowania liczby osobogodzin w procesie tworzenia oprogramowania.

Opracował go Barry Boehm w 1981 roku pracując w Boeing Company na podstawie około 60 projektów informatycznych o różnej złożoności (od 2 KDSI do 100 KDSI) i napisanych w różnych językach programowania.

Postępowanie

ustalenie metryki

Aby oszacować liczbę osobogodzin należy najpierw oszacować, z ilu linijek kodu lub function points będzie się składać gotowy projekt. Liczba linijek kodu jest przedstawiana w KDSI [1 KDSI = 1000 linijek].

Ustalenie złożoności

Następnie należy wybrać, do której z trzech poniższych grup pasuje analizowany projekt.

„basic COCOMO”

• Łatwy ("organic mode"), to projekt, w którym mały zespół posługuje się znanymi narzędziami pracy. Zna on sprzęt i oprogramowanie, z którymi rozwijany projekt będzie redagować. Presja czasu jest mała. Łatwe projekty są wielkości do max. 50 KDSI.

• Pośredni projekt ("semi-detached"), to projekt, w którym jeden z czynników z projektu prostego nie jest znany, np. zespół nie zna sprzętu, który przyjdzie mu programować itp. Takie projekty są zwykle wielkości do 300 KDSI.

• Trudny ("embedded mode"), to bardzo złożony projekt, wiele czynników jest nieznanych lub należy uwzględnić szczególne procedury,np. w branży bankowej.

„Intermediate COCOMO” - dodatkowe wymagania

• Produktu (wymagana czytelność stworzonego oprogramowania,wielkość bazy danych, skomplikowanie)

• Sprzętu (ograniczenia związane z wydajnością, czy tworzony system jest systemem czasu rzeczywistego, ograniczenia pamięci)

• Personelu (analiza możliwości, Doświadczenie w tworzeniu oprogramowania, doświadczenie w tworzeniu oprogramowania danego typu, doświadczenie w tworzeniu oprogramowania wykorzystującego dane środowisko, sprzęt czy język programowania)

• Projektu (jakie narzędzia są potrzebne?, jakie metody tworzenia oprogramowania będą wykorzystywane?, jaki jest harmonogram projektu?, jaka jest presja czasu?)

Wzory:

E=ab(KDSI)bb

D=cb(E)db

P=E/D

E - nakładem pracy w osobomiesiącach, D - potrzebny do rozwoju projektu P - liczba osób, przy której projekt będzie najefektywniej zrealizowany.

Software project	ab	bb	cb	db
Organic	2.4	1.05	2.5	0.38
Semi-detached	3.0	1.12	2.5	0.35
Embedded	3.6	1.20	2.5	0.32

11) Wymień podstawowe rezultaty f. strategicznej (Js45)

- udostępniony klientowi raport obejmujący (tu wyszczególnić: definicję celów, opis zakresu przedsięwzięcia, opis systemów zewnętrznych z jakimi system będzie współpracować, ogólny opis wymagań, opis proponowanego rozwiązania, oszacowanie kosztów, wstępny harmonogram prac),

- raport oceny rozwiązań,

- opis wymaganych zasobów,

- definicje standardów,

12) Wymagania funkcjonalne i niefunkcjonalne, opisz je, podaj przykłady.

Wymagania funkcjonalne

Stwierdzenia opisujące, jakie usługi ma oferować system, jak ma reagować na określone dane wejściowe oraz jak ma reagować w określonych sytuacjach.

• Opisują funkcjonalność lub usługi, które system powinien oferować

• Zależą od rodzaju tworzonego oprogramowania, spodziewanych użytkowników oprogramowania i rodzaju wytwarzanego systemu

• Wymagania użytkownika mają zazwyczaj postać ogólną, natomiast systemowe szczegółowo definiują funkcje systemu, wejścia wyjścia wyjątki itd..

• Kiedy wymagania nie są precyzyjnie wyrażone powstają problemy

• Nieprecyzyjne wymagania są różnie interpretowane przez użytkowników i programistów

Przykłady

• Użytkownik będzie mógł przeszukać zbiór wszystkich danych lub wybrany podzbiór.

• System dostarczy narzędzi do przeglądania dokumentów ze magazynu dokumentów.

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

Wymagania niefunkcjonalne

Ograniczenia usług i funkcji systemu obejmujące: ograniczenia czasowe, ograniczenia dotyczące procesu tworzenia, standardy itd.

• Opisują właściwości i ograniczenia systemu np. niezawodność, czas odpowiedzi, ilość miejsca na dysku.

• Wymagania stawiane procesowi mogą specyfikować użycie określonego narzędzia, języka programowania lub metodologii projektowej.

• Wymagania niefunkcjonalne mogą być istotniejsze od funkcjonalnych. Jeśli nie będą spełnione system będzie bezużyteczny.

Przykłady

Wymaganie produktowe

4.C.8 Wszelka niezbędna komunikacja między APSE i użytkownikiem powinna dać się wyrazić za pomocą standardowego zestawu symboli Ady

Wymagania organizacyjne

9.3.2 Proces tworzenia systemu i końcowe dokumenty powinny być zgodne z procesem i produktami zdefiniowanymi w XYZCo-SP-STAN-95

Wymagania zewnętrzne

7.6.5 System nie powinien ujawniać operatorom żadnych danych osobowych klientów oprócz nazwisk i numerów identyfikacyjnych

13) Wymień co powinien zawierać dokument opisujący wymagania (Js49).

- wprowadzenie (opisać jego zawartość)

- opis ewolucji systemu,

- opis wymagań funkcjonalnych i specyfikacja wymagań funkcjonalnych, ,

- opis wymagań niefunkcjonalnych i specyfikacja wymagań niefunkcjonalnych,

- model systemu,

- słownik,

14) Napisz podstawowe rezultaty fazy określania wymagań (Js60)

- dokument opisujący wymagania składający się z:

* wprowadzenia opisującego cele, zakres i kontekst systemu,

* opisu ewolucji systemu, to jest opis przewidywalnych zmian wymagań wobec systemu,

* opisu wymagań funkcjonalnych,

* opisu wymagań niefunkcjonalnych,

* modelu systemu,

* słownika,

oraz następujących opcjonalnych dodatków:

* specyfikacji wymagań funkcjonalnych,

* specyfikacji wymagań niefunkcjonalnych,

* opisu wymagań sprzętowych,

* opisu wymagań dotyczących bazy danych,

* indeksu,

- plan testów

15) Podaj cel fazy analizy (Jr5,1-2)

Celem fazy analizy jest udzielenie odpowiedzi na pytanie: jak system ma działać? Wynikiem jest logiczny model systemu, opisujący sposób realizacji przez system postawionych wymagań, lecz abstrahujący od szczegółów implementacyjnych. Ponieważ celem fazy analizy jest budowa logicznego modelu systemu jest ona także nazywaną fazą modelowania.

16) Opisz techniki programistyczne, które zwiększają możliwości popełnienia błędów (Jr7.1.1).

Pewne techniki programistyczne zwiększają możliwość popełnienia błędów. Są to:

-Instrukcja goto lub inne o podobnym działaniu. Instrukcje te zaburzają naturalną strukturę algorytmu.

-Liczby zmiennoprzecinkowe. Obliczenia z wykorzystaniem liczb zmiennoprzecinkowych wykonywane są ze skończoną dokładnością. Błędy zaokrągleń mogą być stosunkowo duże nawet w przypadku pojedynczych operacji, zwłaszcza wtedy, gdy poszczególne liczby zdecydowanie różnią się wielkością. Błędy zaokrągleń pojedynczych operacji mogą się kumulować prowadząc do bardzo poważnych błędów obliczeń. Wiele błędów wiąże się także z porównaniem liczb zmiennopozycyjnych. Dwa wyrażenia , które z matematycznego punktu widzenia dają dokładnie ten sam wynik, mogą dać nieznacznie różniące się rezultaty w przypadku realizacji komputerowej.

-Wskaźnik. Posługiwanie się wskaźnikami prowadzi do wielu błędów dostępu do pamięci. Wskaźniki mogą prowadzić także do sytuacji, w których te same zmienne maja rożne etykiety.

-Obliczenia równoległe. Stosowanie obliczeń równoległych prowadzi do złożonych zależności czasowych, które mocno utrudniają uruchamianie oprogramowania. Wiele błędów nie ujawnia się w momencie śledzenia programu. Możliwe jest także równoczesne operowanie na tych samych danych przez różne procesy.

-Przerwania. Technika ta wprowadza rodzaj równoległości, wiążą się wiec z nią te same problemy jak z obliczeniami równoległymi. Dodatkowo istnieje ryzyko przerwania procesów krytycznych czasowo.

-Rekursja. Stosowanie tej techniki utrudnia śledzenie programu. Często jest także przyczyną zapętlenia się programu.

-Tryby pracy procedur (funkcji, metod), które realizują wyraźnie odmienne zadania w zależności od informacji kontrolnej przekazanej jako parametr wejściowy.

-Złożone wyrażenia wymagające uwzględniania priorytetów operatorów. Wielu błędów unika się rozbijając złożone wyrażenia na kilka krótszych lub zawsze ujmując podwyrażenia w nawiasy nawet wtedy, gdy (jak się programiście wydaje) nie jest to konieczne ze względu na priorytety operatorów.

17) Napisz, jakie dokumenty składają się na "standardy firmy programistycznej"

Standardy programistyczne firmy (wg. AK)

-Spis ograniczeń stosowanych w używanym w firmie języku programowania i/lub spis zaleceń w edycji pliku oraz ograniczeń stosowanych w używanych w firmie językach programowania.

Standardy programistyczne powinny uwzględniać kilka pod standardów:

- sposobu edycji instrukcji, sposobu komentowania

- nakazy umieszczania w nagłówku pliku informacji o treści pliku oraz autorach pliku oraz autorach zmian dokonywanych treści pliku

-wykaz instrukcji jakich nie należy używać

-wykaz ograniczeń w stosowaniu instrukcji

Standard powinien zawierać:

-nazwa, autorzy, data przyjęcia do stosowania , spis update'ów (data, autor), postępowanie w przypadku odstępstwa,

-standard dla języka… (np. C++)

*zawartość komentarzy na początku pliku zarówno dla pliku headera jak i pliku z implementacją

*zalecenia edycji (5-10 zaleceń)

*ograniczenia standardu (5-10 ograniczeń)

18) Wymień czynniki, jakie wpływają na jakość dokumentacji.

Na jakość dokumentacji wpływają następujące czynniki:

-Struktura. Poszczególne podręczniki powinny być w czytelny i zrozumiały sposób podzielone na rozdziały, podrozdziały i sekcje.

-Zachowanie standardów. Poszczególne podręczniki oraz fragmenty tego samego podręcznika powinny mieć spójną strukturę, formę i sposób pisania.

-Sposób pisania.

19) Na czym polega atestowanie (validation) a na czym weryfikacja (verification)?

-atestowanie (validation), czyli testowanie zgodności systemu z rzeczywistymi potrzebami użytkownika,

-weryfikacja(verification), czyli testowanie zgodności systemu z wymaganiami zdefiniowanymi w fazie określenia wymagań.

20) Z jakich "dokumentów" składa się dokumentacja przedsięwzięcia programistycznego.

- Opis funkcjonalny: wstępna część dokumentacji, która opisuje przeznaczenie i główne możliwości systemu.

- Podręcznik użytkownika: opis systemu przeznaczony gównie dla początkujących użytkowników. Powinien zawierać informacje o:

- sposobach uruchamiania oraz kończenia systemu

- realizacja najczęściej wykonywanych funkcjach systemu

- metody obsługi błędów

- sposoby korzystania z pomocy

- Kompletny opis: część przeznaczona dla doświadczonych użytkowników: powinna zawierać:

- szczegółowy opis wszystkich funkcji

- informacje o sposobach wywołania funkcji

- opisy formatów danych

- opisy błędów, które mogą się pojawić podczas pracy z systemem

- informacje o ograniczeniach

- Opis instalacji

- Podręcznik administratora systemu: możliwości zmian konfiguracji systemu i sposoby udostępniania systemu użytkownikom końcowym.

21) Podaj zadania osoby odpowiedzialnej za QA.

Zadania kontrolera jakości w "naszym" przedsięwzięciu (czyli obowiązki osoby zatrudnionej jako QA):

• sprawdza zgodność kodu ze standardami firmy,

• [otrzymuje od projektantów]/[sam sporządza] dokument "Usta klas" , odpowiada za uaktualnianie tego dokumentu,

• wypełnia dla każdej klasy dokument pt. "QA class document" zawierający jedną klasę i potwierdzający jej zgodność ze standardem .



-wypełnia odpowiednie rubryki w dokumencie "Progress Report" czyli "Tablica
postępów",

-sprawuje pieczę nad dokumentacją testowania.

22) Wymień rodzaje testów.

Z punktu widzenie głównego celu:

- wykrywanie błędów, czyli testy, których głównym celem jest wykrycie jak największej ilości błędów w programie (masło maślane, kurwa!)

- testy statystyczne, których celem jest wykrycie przyczyn najczęstszych błędnych wykonań oraz ocena niezawodności systemu

Z punktu widzenia podstawowej techniki wykonywanie testów:

- testy dynamiczne, które polegają na wykonaniu (fragmentu) programu i porównaniu uzyskanych wyników z wynikami poprawnymi

- testy statystyczne, oparte na analizie kodu

Testowanie systemu przebiega przez następujące fazy:

- Testy modułów (już w fazie implementacji)

- Testy systemu (integrowane są poszczególne moduły i testowane są poszczególne podsystemy jak i również jako całość).

- Testy akceptacji (testy alfa):

- w przypadku programu na zamówienie: program wysyłany do klienta i sprawdzany przez niego.

- w przypadku programu sprzedawanego rynkowo: nieodpłatne przekazanie pewnej ilości kopii programu pewnej grupie użytkowników.

23) Opisz testowanie statystyczne.

Testy statystyczne przebiegają wg następującego schematu:

- losowa konstrukcja danych wejściowych zgodnie z rozkładem prawdopodobieństwa tych danych

- określanie wyników poprawnego działanie systemu na tych danych

- uruchomienie systemu oraz porównanie wyników jego działanie z poprawnymi wynikami

Powyższe czynności wykonywane są cyklicznie.

Stosowanie testów statystycznych wymaga określenie rozkładu prawdopodobieństwa danych wejściowych możliwie bliskiego rozkładowi, który pojawi się podczas rzeczywistego korzystania z systemu. Założeniem testów statystycznych jest położenie nacisku na przetestowanie działania systemu w typowych sytuacjach (typowe dane wejściowe są częściej generowane niż nietypowe).

Wikipedia:

Testy statystyczne są formą testowania oprogramowania bez uruchamiania programu podczas testów. Test najczęściej wykonywany jest przez twórców kodu jako pierwsze i podstawowe sprawdzenie każdego programu. Testowanie statyczne sprawdza podstawową poprawność kodu i pozwala ocenić, czy program jest gotowy na bardziej szczegółowe testowanie.

W testowaniu statystycznym można wyróżnić podstawową analizę kodu (czytanie i wyszukiwanie w składni błędów takich jak nie zakończone pętle, złe odwołania do pamięci czy też niezainicjowane zmienne) i precyzyjne wyszukiwanie typowych błędów (najczęściej dokonywane przez programistów poprzez dokładne czytanie ze zrozumieniem całego kodu programu w celu wykrycia typowych błędów które nie są wykrywane przez narzędzia programistyczne, natomiast mogą doprowadzić do błędnych wykonań w programie).

24) W jaki sposób zależy niezawodność od liczby testów (podaj także wzór).

Po wykryciu błędnych wykonań poszukiwane są ich przyczyny, tj. błędy, które są następnie usuwane z programu. Jeżeli nie wprowadza się przy tym równej lub większej ilości błędów, to w trakcie testowania wzrasta niezawodność oprogramowania. Jeżeli wykonywane są testy czystko statyczne, wzrost niezawodności powinien przebiegać zgodnie z nast. modelem:

wzór:

Niezawodność = niezawodność początkowa * exp *( C x liczba testów )

Jest to tzw. logarytmiczny model wzrostu niezawodności oprogramowania, w powyższym wyrażeniu zakłada się, że miarą niezawodności systemu jest częstotliwość występowania błędnych wykonań. Stała C zależy od konkretnego systemu, można ją określić na podstawie niezawodności systemu systemu w trakcie testowania metodą regresji nieliniowej, np. metodą najmniejszych kwadratów.

25) Opisz, na czym polegają testy statystyczne.

- patrz punkt 23

26) Opisz testy strukturalne.

Testy strukturalne:

Przypadku testów strukturalnych, dane wejściowe dobiera się na podstawie analizy struktury programu realizującego testowane funkcje. Proponuje się w tym wypadku kilka kryteriów doboru danych testowych.

- Kryterium pokrycia wszystkich instrukcji

- Kryterium pokrycia instrukcji warunkowych

Wikipedia:
Testy strukturalne znane są także jako testy białej lub szklanej skrzynki. Polegają na testowaniu programu poprzez podawanie na wejściu takich danych, aby program przeszedł przez każdą zaimplementowaną ścieżkę. Zasady te są definiowane przez kryteria pokrycia wszystkich pętli oraz wszystkich warunków. Testy białej skrzynki nie są w stanie wykazać braku implementacji funkcji, którą powinien posiadać system docelowy. Sprawdzają jednak dokładnie operacje wykonywane w zaimplementowanych metodach.

Nierzadko w trakcie testowania programu techniką szklanej skrzynki wprowadzane są do wnętrza programu sztucznie specjalnie spreparowane dane w celu dokładniejszego przetestowania reakcji. Ten sposób nazywamy metodą „Słonia w Kairze”.

27) Jakie elementy składają się na fazę instalacji (Jr10)

- szkolenia użytkowników końcowych i administratorów systemu,

- instalacja sprzętu i przeniesienie oprogramowania,

- wypełnienie koniecznych baz danych,

- nadzorowanie korzystania z systemu, często równoległe z tradycyjnym sposobem pracy,

- usuwanie błędów w oprogramowaniu i dokumentacji użytkowej,

- przekazanie systemu klientowi.

28) Na czym polega inżynieria odwrotna (reverse engineering) (Jr11.2)

Inżynieria odwrotna jest procesem polegającym na odtworzeniu dokumentacji technicznej na podstawie istniejącego kodu,( czasami na podstawie struktur baz danych). Nazywa się e ten sposób, ponieważ jest on odwróceniem kolejności czynności wykonywanych w trakcie budowy oprogramowania. W fazie implementacji wykonywana jest transformacja projektu do kodu. Należy przy tym pamiętać, że opis projektu po zakończeniu implementacji staje się dokumentacją techniczną. Inżynieria odwrotna jest więc próbą odtworzenia projektu, na bazie którego mogłoby powstać istniejące oprogramowanie. Inżynieria odwrotna jest procesem, który da się automatyzować. Moduły Inż. Odwrot. są więc częstymi składowymi narzędzi CASE

29) Wymień (i opisz) trzy główne klasy modyfikacji wprowadzanych w oprogramowanie

30) Wymień czynniki wpływające na redukcję kosztów konserwacji.

Na redukcję kosztów konserwacji wpływają następujące czynniki:

• Znajomość dziedziny problemu. Jeżeli analitycy pracujący nad systemem dobrze znają daną

dziedzinę problemu, mają mniej trudności z właściwym zebraniem wymagań oraz budową

oddającego rzeczywistość modelu.

• Wysoka jakość modelu i projektu. W szczególności:

◦ spójność,

◦ stopień powiązań składowych,

◦ przejrzystość.

• Wysoka jakość dokumentacji technicznej. Dokumentacja techniczna powinna:

◦ w pełni odpowiadać systemowi,

◦ być wystarczająco szczegółowa,

◦ być zgodna z przyjętymi w firmie standardami.

• Stabilność personelu. Wysoka jakość projektu oraz dokumentacji technicznej nie zmienia

faktu, że pewne aspekty systemu zawsze są najlepiej znane osobom bezpośrednio

uczestniczącym w jego realizacji. Nie oznacza to automatycznie, że modyfikacje powinny

być zawsze wykonywane przez te same osoby, które opracowywały system. Jeżeli jednak

osoby te nadal pracują u producenta oprogramowania, to istnieje możliwość konsultacji w

przypadku pojawienia się innych wątpliwości i trudności.

• Środowisko implementacji. Zaawansowane środowiska implementacji, obejmujące języki

wysokiego poziomu i możliwości dialogowego projektowania i wytwarzania fragmentów

oprogramowania, wpływają na skrócenie czasu niezbędnego na wprowadzenie modyfikacji.

• Niezawodność oprogramowania. Wysoka niezawodność oprogramowania w momencie

przekazania do użytkownika zmniejsza liczbę modyfikacji, w szczególności o charakterze

poprawiającym.

• Inżynieria odwrotna. Pod tym pojęciem rozumie się odtwarzanie dokumentacji technicznej

na podstawie istniejącego oprogramowania.

• Zarządzanie wersjami.

31) Wymień stanowiska w firmie programistycznej.

- Konsultant - omawia z klientem funkcjonalność programu, ustala cenę itp.

- Programista to osoba zajmująca się tworzeniem i rozwojem oprogramowania. W dzisiejszych czasach określa często zawód nie związany z pisaniem kodu źródłowego programu, lecz wszystkie poboczne aspekty inżynierii oprogramowania. Z komercyjnego punktu widzenia, osoby tylko tworzące kod źródłowy nazywa się koderami. Z akademickiego punktu widzenia programiści to grupa naukowa doskonaląca metody optymalnego pisania kodu i osiągania coraz lepszych efektów w coraz krótszym czasie.

- Koder (implementator) - osoba, która dostaje gotowy projekt (klasy, funkcje itp.) i implementuje kod programu.

- Kierownik (Manager) Projektu - osoba odpowiedzialna i koordynująca rozwój programu.

- QA (Quality Assurance - Zapewnienie jakości) - planowe i systematyczne działania niezbędne do zapewnienia spełnienia wymagań jakości końcowego produktu w procesie jego tworzenia.

- Testerzy - Sprawdzają końcowy produkt.

- Inni: Zarząd firmy - Dyrektor, zastępcy; Księgowi itp.

---