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); mode 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 szczegół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.)
9) Wymień techniki szacowania kosztów oprogramowania (Js39 i nast.)
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 podstandardó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 statyczne, 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 statyczne, 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 statyczne 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 statycznych 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 statycznych 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 statyczne 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 statycznym 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 statyczne.
- 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.
Wyszukiwarka