1. Wpływ różnych modeli cyklu życia oprogramowania na jego proces walidacji i weryfikacji.
Są to czynności tradycyjnie określane mianem testowania, stanowią tylko część istotnego elementu procesu wytwarzania oprogramowania, jakim jest walidacja i weryfikacja (validation and verification, V&V) Wyróżnia się modele t.j.:
Model kaskadowy – polega na wykonywaniu podstawowych i koniecznychczynnościprzy wytwarzaniu oprogramowania, jako odrębnych faz projektowych kolejnojedno po drugim. Jeśli któraś z faz zwróci niesatysfakcjonujący produkt cofamy się wykonując kolejne iteracje. Każda czynność to kolejny schodek:planowaniesystemu, analiza systemu, projekt systemu, implementacja, testowanie, wdrożenie.
• Modele ewolucyjne
Celem modelu ewolucyjnego jest poprawienie modelu kaskadowego poprzez rezygnację ze ścisłego, liniowego następstwa faz, dzięki czemu pozostawia się te same czynności, ale pozwala na powroty, z pewnych faz do innych faz poprzedzających tym samym umożliwia się adaptowanie do zmian w wymaganiach i korygowanie popełnionych błędów. Do modeli ewolucyjnych zaliczamy:
Model przyrostowy – stosowany w przypadkach, w których dopuszczalna jest okrojona funkcjonalność systemu. Posiada fazy: określanie całości wymagań, wybór pewnego podzbioru funkcji systemu, szczegółowy projekt oraz implementacja części systemu realizującej wybrane funkcje, testowanie zrealizowanego fragmentu i dostarczenie klientowi, powtarzanie kolejnych etapów do zakończenia całego systemu.
Model spiralny – proces ma postać spirali, której każda pętla reprezentuje jedną fazę procesu. Najbardziej wewnętrzna pętla przedstawia początkowe etapy projektowania. Każda pętla podzielona jest na 4 sektory: ustalanie celów, rozpoznanie i redukcja zagrożeń, tworzenie i zatwierdzanie, ocena i planowanie.
Model komponentowy- w nim idee ponownego użycia kodu posunięte są najdalej.
Po fazie określania wymagań specyfikacji następuje faza analizy możliwości wykorzystania istniejących, gotowych komponentów i ewentualna faza modyfikacji wymagań, w konsekwencji zastosowania komponentów.
W fazie projektowania uwzględnia się już znalezione komponenty oraz ewentualnie nowe, związane z techniczną realizacją (implementacją)
Projekt oprogramowania wykonywany jest tak, aby te spośród wytwarzanych elementów, które się do tego nadają, mogły być ponownie wykorzystane, jako komponenty
W fazie wytwarzania(Implementacji) kodu zwraca się szczególną uwagę na interfejsy pomiędzy modułami-komponentami
Testowanie jest w dużej mierze testowaniem integracji poszczególnych komponentów
Weryfikacja – stwierdza czy system działa prawidłowo (spełnia wymagania funkcjonalne i niefunkcjonalne), czy jest on wbudowany w odpowiedni produkt. Dzięki weryfikacji projektant uzyskuje informacje o zgodności systemu symulacyjnego z jego założeniami.
Walidacja–określa czy system realizuje oczekiwania klienta.Walidacja weryfikuje zgodność wizji projektanta z realnym światem.
2. Dobór metodyki pozyskiwania wymagań i analizy uwarunkowań procesu specyfikacji wymagań.
Specyfikacja oprogramowania ma na celu określenie, jakich usług wymaga się od systemu, jakim ograniczeniom podlega tworzenie i działanie oprogramowania. Obecnie ta czynność nazywana jest inżynierią wymagań. Jest to istotna faza procesu tworzenia oprogramowania, ponieważ błędy w tej fazie prowadzą do problemów w trakcie projektowania i implementacji.
W inżynierii wymagań mamy 4 główne fazy:
Studium wykonalności - ocenia czy rozpoznane potrzeby użytkownika mogą być spełnione przy obecnej technologii sprzętowej i oprogramowania.
Określenie i analiza wymagań to proces stawiania wymagań systemowi na podstawie informacji o istniejących systemach;rozmowa z potencjalnymi użytkownikami
Specyfikowanie wymagań jest to czynność polegająca na zapisywaniu informacji zebranych w czasie analizy w dokumencie definiującym zbiór wymagań
Zatwierdzenie wymagań- sprawdzenie realizmu, spójności i kompletności wymagań, następuje wykrywanie błędów.Metodyka nie jest wykonywana ściśle w tej kolejności.
Analiza wymagań trwa w czasie definicji i specyfikacji. W trakcie całego procesu ciągle pojawiają się nowe wymagania, dla tej czynności.
Metodyki pozyskiwania wymagań:
Wywiad – luźniejsza rozmowa z klientem lub przygotowany zestaw pytań.
Burza mózgów – zespół zgłasza pomysły na temat funkcjonowania systemu.
Scenariusze – jak użytkownik ma korzystać z systemu – od początku do otrzymania szukanej informacji, wykonania działania.
Prototypowanie – przygotowanie szkieletu, makiety i rozmowa z klientem o jego zdaniu na ten temat.
Obserwowanie – przyglądanie się użytkownikom podczas wykonywania ich zadań w codziennej pracy.
Kwestionariusze – przygotowane do uzupełnienia ankiety.
Specyfikacja– jest to proces, którego celem jest określenie, jakie usługi musi dostarczać projektowany system oraz jakie są ograniczenia na działanie systemu oraz procesu jego produkcji.
3. Sposoby oceny wykonalności projektu programistycznego w zakresie założeń oraz analizy zależności wymagań funkcjonalnych oraz niefunkcjonalnych.
Właściwości systemu są atrybutami systemu, jako całości. Nie można przewidzieć wartości tych własności, ale można je zmierzyć dopiero po zintegrowaniu podsystemów.
Typy właściwości:
Analiza kosztów – koszt wytworzenia oprogramowania, utrzymania i konserwacji – często jest większy niż koszt jego wytworzenia.
Termin – określenie czasu realizacji wytworzenia oprogramowania.
Zakres – jakie funkcjonalności ma posiadać produkt końcowy.
Jako ocenę wykonalności projektu można również przyjąć kryteria o charakterze: ekonomicznym, moralnym, estetycznym, socjalno-politycznym, religijnym.
Wymagania funkcjonalne – dotyczątego, co ma realizować system, jakie ma spełniać funkcja, jakich dostarczać usług oraz jak zachowywać się w określonych sytuacjach. Powinny być: kompletne – opisywać usługi żądane od systemu, spójne – nie zawierać stwierdzeń sprzecznych.
Wymagania niefunkcjonalne – dotyczą tego jak system powinien realizować swoje zadania np. wymagania dotyczące zasobów, ograniczeń czasowych, niezawodności, bezpieczeństwa. Mogą dotyczyć nie tylko końcowego produktu (oprogramowania), ale także samego procesu wytwarzania oprogramowania.
4. Oprogramowanie rozwojowe oraz efektywne metody jego projektowania i implementacji.
Tworzenie ewolucyjne
Pierwsza wersja systemu powstaje bardzo szybko, na podstawie abstrakcyjnych specyfikacji. W dalszej fazie jest udoskonalanaaż do powstania odpowiedniego systemu zgodnie z informacjami pobranymi od klienta. Nie ma tu oddzielnych czynności specyfikacji, tworzenia i zatwierdzania. Są one prowadzone raczej równolegle, z szybkim rozpoznaniem na informacje zwrotne.
Zaletąewolucyjnego tworzenie oprogramowaniajest przyrostowe opracowanie specyfikacji, wypracowanie coraz lepszego zrozumienia użytkownika
Istnieją dwa typy tworzenia ewolucyjnego:
1. Tworzenie badawcze, w którym celem procesu jest praca z klientem, polega na badaniu wymagań i dostarczaniu ostatecznego systemu. Tworzenie rozpoczyna się od tych części systemu, które są dobrze rozpoznane. System ewoluuje przez dodawanie nowych cech, które proponuje klient.
2. Prototypowanie z porzuceniem, w którym celem procesu tworzenia ewolucyjnego jest zrozumienie wymagań klienta i wypracowanie lepszej definicji wymagań stawianych systemowi.
Budowanie prototypu ma głównie na celu eksperymentowanie z tymi wymaganiami użytkownika, które są niejasne. Podejście ewolucyjne do tworzenia oprogramowania jak zwykle bardziej efektowne niż podejście kaskadowe. Umożliwia produkowanie systemów, które najdokładniej odpowiadają potrzebom użytkownika.
Faza implementowania w tworzeniu oprogramowania to proces przekształcania specyfikacji systemu w działający system obejmuje zawsze projektowanie i programowanie, ale jeśli zastosowano podejście ewolucyjne, to może również zawierać udoskonalenie specyfikacji oprogramowania.
5. Typy i modele produktów oprogramowania oraz obszary ich zastosowania, a także związane z nimi metodyki zarządzania procesem wytwórczym.
6. Kontrola, jakości, testy oprogramowania i ich rodzaje.
Testowanie oprogramowania jest to proces związany z wytwarzaniem oprogramowania. Jest on jednym z procesów kontroli, jakości oprogramowania.Testowanie systemu jest możliwe, jeśli istnieje działająca wersja oprogramowania: (prototyp; kolejne wydanie w ramach przyrostowego tworzenia oprogramowania; ostateczny program)
Testowanie dzieli się na różne kategorie, w zależności od różnych kryteriów:
Testy ze względu na cel:
Weryfikacja oprogramowania – sprawdzenie, czy wytwarzane oprogramowanie jest zgodne ze specyfikacją.
Walidację oprogramowania – sprawdzenie, czy oprogramowanie jest zgodne z oczekiwaniami użytkownika.
Testy ze względu na zakres aplikacji:
Jednostkowe – testują aplikacją na poziomie działania pojedynczych funkcji.
Integracyjne – sprawdzają jak współpracują ze sobą różne komponenty oprogramowania.
Systemowe – dotyczą działania aplikacji, jako całości.
Testy ze względu na przeznaczenie:
Akceptacyjne – sprawdzają na ile oprogramowanie działa zgodnie z wymaganiami klienta.
Funkcjonalne – sprawdzają działanie oprogramowania zgodnie ze specyfikacją
Regresyjne – sprawdzenie czy dodana funkcjonalność, poprawione błędy nie naruszają niespodziewanie innej funkcjonalności.
Testy wydajnościowe i obciążeniowe:
Instalacyjne – sprawdzają jak oprogramowanie zachowuje się na różnych platformach sprzętowych.
Wersji alfa i beta – zdobycie informacji (opinie i komentarze) od użytkowników testujących działanie produktu.
Używalności – sprawdzają jak szybko użytkownicy mogą opanować działanie aplikacji.
Post-awaryjne – sprawdzają, czy aplikacja zachowuje się poprawnie po wystąpieniu sytuacji awaryjnej.
Testowanie pozwala na znalezienie błędów natomiast nie pozwala na wykazanie poprawności oprogramowania
W przypadku testów losowych dane generowane są spośród zbioru możliwych przypadków zgodnie z pewnym rozkładem prawdopodobieństwa:
•pozwala to na oszacowanie niezawodności systemu
•w miarę przeprowadzania testów i usuwania błędów następuje nasycenie – nowe testy coraz rzadziej wykrywają błędy
7. Budżet, ryzyko i koszty związane ze zmianami w trakcie realizacji projektu programistycznego.
Ze względu na złożoność realizacji projektów informatycznych szacowanie budżetu, ryzyka i kosztuwytwarzania oprogramowania jest trudne.
Analiza ryzyka obejmuje wykrywanie potencjalnych zagrożeń dla planowanej realizacji przedsięwzięcia, szacowanie prawdopodobieństwa ich wystąpienia, określanie sposobów radzenia sobie z nimi. Ryzyko wystąpienia w trakcie realizacji projektu może wystąpić z powodu:
Błędnego harmonogramowania – projekt jest opóźniony już od pierwszego dnia.
Problemu ze specyfikacją – uzgodnienie zakresu tworzonego oprogramowania.
„Pełzającego” zakresu – dodatkowe wymagania pojawiające się w trakcie projektu
Czynniku ludzkiego – ludzie opuszczają zespół przed zakończeniem projektu.
Wydajności – różnice pomiędzy zakładaną, a rzeczywistą wydajnością.
Budżet i koszt – harmonogram jest podstawą do wyznaczenia kosztu przedsięwzięcia i przyrównania go z dostępnym budżetem. W przypadku niedopasowania kosztów do budżetu może okazać się, że do projektu należy wprowadzić stosowne zmiany. Zmiany mogą mieć miejsce w trakcie realizacji projektu: w wyniku zmiany specyfikacji wymagań, odstępstwa realizacji projektu od planu.
Koszty realizacji projektu informatycznego składa się głównie z:
kosztów osobowych (wynagrodzenie wykonawców i personelu wspomagającego)
kosztów sprzętu i oprogramowania usługowego
kosztów realizacji:
wyjazdy, szkolenia
utrzymanie pomieszczeń, materiały biurowe, itp.
8. Zasady skutecznego zarządzania zespołem programistycznym.
W każdym zespole kierownik projektu odgrywa znaczącą rolę. W ramach zarządzania personelem konieczne jest umiejętne realizowanie następujących zadań:
• dobór zespołu realizującego projekt (personelu)
• podział na grupy i ustalenie struktury zależności
• motywowanie ludzi
• utrzymanie spójności zespołu
• zapewnienie komunikacji w zespole,
W kategoriach socjologicznych:
Usuwanie przeszkód – najczęściej występują problemy organizacyjne, problemy związane z przepływem informacji między członkami zespołu, decyzje związane ze zmianą architektury systemu.
Czynny udział w tworzeniu architektury systemu – wykluczenie nierozważnych rozwiązań, przedstawienie ograniczeń stosowanej technologii.
Utrzymanie spójności architektury – pilnowanie architektury w fazie projektowania oraz realizacji.
Regularne przeglądy kodu – prowadzi do podniesienia poziomu inżynierii w zespole, pozwala pilnować spójności architektury rozwiązania.
Rozdzielenie zadań w zespole uwzględniając kompetencje programistów
Realizacja zadań zgodnie z harmonogramem
Podejmowanie ostatecznych decyzji–kierownik powinien podejmować ostateczne decyzje, jednak powinien przedyskutować swoje propozycje z zespołem podnosząc w ten sposób ogólny poziom inżynierii.
9. Sposoby zachowania deklarowanego czasu, budżetu i zakresu wymagań tworzonego produktu programistycznego.
Zarządzanie projektem dotyczy zarządzania procesami związanymi z osiąganiem określanego celu przy wykorzystaniu skończonych zasobów w przeciągu skończonego okresu czasu. Podejmowanie decyzji odnośnie zastosowania odpowiednich umiejętności, metod, technik i narzędzi, by osiągnąć cel w określonym terminie i czasie, w ramach dysponowanego budżetu.
Skuteczne zarządzanie projektem wymaga: planowania, organizacji zespołu, nabywania i przechowywania zasobów, harmonogramowania działań, sterowania realizacją.
Skuteczne zarządzanie projektem mogą wspomagać aplikacje specjalnie ku temu zaprojektowane. MS Project, w którym można zdefiniować zadania, przydzielić zasoby oraz określić koszty i na ich podstawie wygenerować wykres Gantta i Perta.
TFS, Trello – implementacjatablic Kanban.
10. Uwarunkowania i sposoby zapewnienia, jakości oprogramowania.
Jakość oprogramowania to dokładność określenia wymagań, do których chcemy porównywać końcowy efekt. To również przydatność produktu do określonego celu, a także satysfakcja klienta.
Sposoby zapewnienia, jakości:
Poprawność - zgodność z wymaganiami użytkowników
Łatwość pielęgnacji (konserwacji), dokonywania zmian
Niezawodność – zdolność do wykonywania funkcji w określonych warunkach, w określonym przedziale czasowym, dla określonej ilości operacji
Wydajność, efektywne wykorzystanie zasobów
Testowanie – próba znalezienia błędu w oprogramowaniu w trakcie jego działania w danym środowisku.
Certyfikacja – potwierdzenie, jakości, poprawności działania oprogramowania.
Aby uzyskać oprogramowanie wysokiej, jakości przydatne jest:
• wprowadzenie w przedsiębiorstwie procedur pomagających uzyskać wysoką, jakość
• planowanie uzyskania wysokiej, jakości w konkretnym projekcie
• nadzorowanie realizacji projektu zgodnie z wymaganiami wysokiej, jakości
11. Dokumentacja fazy pozyskiwania wymagań, projektowania, implementacji i testowania w projekcie programistycznym.
Dokumentację można i powinno się prowadzić na wszystkich etapach wytwarzania.
Jest dokument przedstawiający szczegółowy opis systemu to specyfikacja wymagań oprogramowania (SRS). Nie jest dokumentem technicznym, stanowi jedynie materiał wejściowy dla analityków i projektantów systemu. Powinien być zrozumiały dla obu stron kontraktu.
Metody pisania dokumentacji wymagań:
Opis języku szablonów – stosowanie odpowiednio zdefiniowanych formularzy, tabel lub szablonów, w których opisujemy wymagania według określonych standardów.
Specyfikacja wykorzystująca elementy projektu systemu – używa się języka podobnego do programowania, ale z bardziej abstrakcyjnymi elementami do specyfikowania wymagań (patrzenie na funkcje od strony interfejsów).
Notacja graficzna – metody z zastosowaniem diagramów blokowych oraz przypadków użycia, które przedstawiają powiązania aktorów i funkcji systemu.
Dokumentacja fazy projektowania musi zawierać dane szczegółowe projektu stosowanych struktur danych oraz funkcji oprogramowania. Dokumentacja musi opierać się na możliwościach, jakich dostarcza stosowany system implementacyjny oraz stosowane mechanizmy bazodanowe.
Dokumentacja fazy implementacji polega na komentowaniu przez programistę algorytmów. Opisuje on zasadę działania funkcji, procedur. Podaje, jakie wartości metoda przyjmuje na wejściu oraz jakie zwraca. Następnie na podstawie wprowadzonych komentarzy może wygenerować dokument html przy pomocy programu np. doxygen.
Scenariusze testowe są narzędziem do weryfikacji, czy oprogramowanie działa prawidłowo i zgodnie ze specyfikacją. Przypominają swoją formą scenariusze przypadków użycia. Mogą powstawać na etapie analitycznym lub przy samym końcu wdrożenia. W scenariuszu powinny zawierać się elementy: nazwa testowanej funkcji, cel testu, akcje użytkownika, odpowiedzi systemu.
Zaletą dobrej dokumentacji jest posiadanie szczegółowego spisu treści, słownika pojęć i bogatego indeksu. Coraz częściej dokumentacja dostarczana jest wyłącznie w formie elektronicznej wraz z systemem. Alternatywnie dokumentacja dostępna jest przez sieć.
12. Definiowanie, formalizacja i specyfikacja wymagań w projektach informatycznych.
Jedno wymaganie, to opis pojedynczej funkcji, którą system powinien udostępniać swoim użytkownikom. Wymagania funkcjonalne to funkcje systemu widziane od strony użytkownika, np wprowadzenie nowej faktury, lub wygenerowanie raportu miesięcznego. Natomiast wymagania pozafunkcjonalne to wszystkie inne wymagania, zwłaszcza takie związane z bezpieczeństwem, wydajnością, awaryjnością, np: system ma umożliwiać wprowadzenie co najmniej 20 faktur w ciągu godziny, lub średni czas pomiędzy awariami (ang. MTBF) powinien wynosić 200000h.
Definiowanie:
Zlecając wykonanie systemu informatycznego lub przystępując do jego realizacji we własnym zakresie, trzeba zdefiniować wymagania, jakie ten system ma spełniać. Wymagania muszą być zdefiniowane precyzyjnie, a przede wszystkim muszą być kompletne. Przekroczenie ram czasowych i budżetowych projektu jest najczęściej spowodowane właśnie nieprecyzyjnymi lub niekompletnymi wymaganiami, które w fazie wdrożenia stanowią uciążliwy balast. Do profesjonalnego definiowania wymagań potrzebna jest specjalistyczna wiedza biznesowa z dziedziny, którą będzie wspierał system. Nie mniej potrzebna jest intuicja i doświadczenie informatyczne, podpowiadające, że sprawy traktowane przez specjalistę biznesowego jako "oczywiste" mogą mieć kluczowe znaczenie dla przyszłego systemu.
formalizacja - nie moge nic znalezc
specyfikacja - dokumentacja wymagań; jest zbiorem wymagań, czyli zakresem funkcjonalności zamawianego systemu
13. Wady i zalety stosowanych obecnie podejść w procesie tworzenia specyfikacji wymagań do realizowanego przedsięwzięcia informatycznego.
Dokumentacja (specyfikacja) wymagań funkcjonalnych jest jednym z kluczowych produktów projektu IT, od którego jakości w dużej mierze zależy jakość produktu powstałego podczas implementacji oraz testowalność tego produktu. Nieprecyzyjna, niespójna, niekompletna czy wręcz błędna specyfikacja funkcjonalna w dalszej kolejności skutkuje błędami w kodzie aplikacji, wynikającymi z luk w analizie, niezrozumieniu wymagań przez programistów, nadinterpretacji, etc.
Wymagania funkcjonalne- pozyskiwanie:
Wymagania w stylu „System powinien…” Niestety obecne systemy stają się coraz bardziej złożone, a wymagania średniej wielkości systemu w tej postaci zajęłyby kilkaset stron. Tak wielka liczba luźnych zdań, niepowiązanych ze sobą sprawia trudności podczas sprawdzania jakości takiej specyfikacji.
Innym podejściem jest opisywanie poszczególnych funkcji systemu. Analogicznie do funkcji matematycznych, każda funkcja systemu informatycznego ma swoje wejście, wyjście, efekty uboczne. Podobnie jak w przypadku wymagań typu „System powinien”, taka specyfikacja wymagań zawiera bardzo dużą liczbę małych funkcji, więc nadal są problemy ze zrozumieniem idei systemu i czytelnością. Trzecie podejście to przypadki użycia. Przypadki użycia skupiają się na interakcji pomiędzy użytkownikiem, a systemem. Dzięki takiemu podejściu zyskujemy na czytelności - przypadki użycia nie pokazują zbędnych szczegółów. Dużo łatwiej też jest klientowi wyobrazić sobie jak system będzie funkcjonował. Nie czyta opisu matematycznego, lecz pewną opowieść, która mówi o tym, w jaki sposób np. wystawić fakturę.
14. Mechanizmy modelowania zachowań i struktury realizowanej aplikacji informatycznej.
Strukturę aplikacji można przedstawić przy pomocy diagramu klas. Diagram klas to graficzne przedstawienie statycznych, deklaratywnych elementów dziedziny przedmiotowej oraz związków między nimi. Obrazuje pewien zbiór klas, interfejsów. Zestaw działań, który określa zachowania obiektów i związki między nimi.
Diagram klas określa 4 rzeczy (CDU):
1. Strukturę - zbiór nazw klas
2. Mechanizmy obiektowości i typy relacji
3. zdefiniowane liczności
4. Atrybuty i właściwości
Zachowania aplikacji można przedstawić przy pomocy diagramu przypadków użycia. Jest to graficzne przedstawienie przypadków użycia, aktorów oraz związków między nimi, występujących w danej dziedzinie przedmiotowej. Stosuje się je dla identyfikacji oraz dokumentacji wymagań, a także umożliwiają analizę obszaru zastosowań, dziedziny przedmiotowej; pozwalają na opracowanie projektu przyszłego systemu; stanowią przystępną i zrozumiałą platformę komunikacji i współpracy aktorów, twórców systemu, inwestorów i właścicieli; są rodzajem umowy pomiędzy udziałowcami co do zakresu funkcjonalności przyszłego systemu; stanowią podstawę testowania funkcji systemu na dalszych etapach jego cyklu życia.
15. Walidacja i zarządzanie wymaganiami w odniesieniu do zwykłych aplikacji użytkowych i systemów krytycznych.
Walidacja to sprawdzenie czy produkt jest zgodny z oczekiwaniami klienta. To samo oprogramowanie może mieć różne oczekiwania co do odbiorcy.
Proces określania wymagań dla systemu informatycznego można podzielić na następujące fazy:
faza ustalania wymagań (odkrywania wymagań)
faza specyfikacji wymagań (tworzenia opisu wymagań)
faza atestacji (walidacji, validation) wymagań
Fazy powyższe mogą być powtarzane wielokrotnie na różnych etapach określania wymagań, wraz z rosnącym zakresem i poziomem szczegółowości wymagań i proponowanych modeli dla systemu. Za każdym razem zakładać będziemy, że w określaniu wymagań uczestniczy klient (znający dziedzinę zastosowań) i wykonawca (odpowiedzialny za aspekty informatyczne, choć nie musi to być ostateczny wykonawca projektu)
Klient musi ustalić swoje wymagania w kontekście możliwości i ograniczeń charakterystycznych dla systemów informatycznych. Wykonawca musi dostosować funkcjonowanie programów do standardów i konwencji dziedziny zastosowań.
Z punktu widzenia rodzaju wymagań można je podzielić na:
wymagania funkcjonalne – dotyczące tego co ma realizować system; jakie ma spełniać funkcje, jakich dostarczać usług, jak zachowywać się w określonych sytuacjach
wymagania niefunkcjonalne – dotyczące tego jak system powinien realizować swoje zadania; np. wymagania dotyczące koniecznych zasobów, ograniczeń czasowych, niezawodności, bezpieczeństwa, przenośności, współpracy z określonymi narzędziami i środowiskami, zgodności z normami i standardami, a także przepisami prawnymi, w tym dotyczącymi tajności i prywatności, itp.
Wymagania funkcjonalne powinny być:
kompletne – opisywać wszystkie usługi żądane od systemu
spójne – nie zawierać stwierdzeń sprzecznych
Wymagania niefunkcjonalne dla wielu systemów są co najmniej równie ważne jak wymagania funkcjonalne (np. szybkość działania wyszukiwarki może być równie ważna jak precyzja wyszukiwania)
Niekiedy wymagania niefunkcjonalne na pewnym poziomie szczegółowości stają się wymaganiami funkcjonalnymi na innym poziomie (np. wymagania dotyczące bezpieczeństwa – stopień bezpieczeństwa może przekształcić się w konieczność realizowania pewnych funkcji związanych z bezpieczeństwem). Wymagania niefunkcjonalne mogą dotyczyć nie tylko końcowego produktu jakim jest oprogramowanie, ale także samego procesu wytwarzania oprogramowania
Zarządzanie wymaganiami oznacza proces kontroli zmian wymagań i ich konsekwencji dla systemu w ciągu całego cyklu życia systemu.
Zarządzanie wymaganiami jest konieczne, gdyż w praktyce wymagania zawsze się zmieniają z powodu zmian technologicznych, organizacyjnych i czysto ludzkich. Istotnym elementem zarządzania wymaganiami jest znalezienie ich wzajemnych powiązań co umożliwia później śledzenie koniecznych zmian w jednych wymaganiach na skutek zmian w innych. Powiązania są pomiędzy:
wymaganiami a motywacjami do ich uwzględnienia (ważne przy rozważaniu możliwych zmian wymagań)
wymaganiami między sobą
wymaganiami a elementami projektu i implementacji będącymi konsekwencjami tych wymagań
Dwa ostatnie typy powiązań umożliwiają późniejsze śledzenie koniecznych zmian w innych wymaganiach oraz architekturze i projekcie systemu w przypadku zmiany konkretnych wymagań. Istnieją narzędzia CASE służące specjalnie do śledzenia powyższych zależności związanych z wymaganiami.
16. Wady i zalety procesu automatyzacji testowania realizowanego oprogramowania oraz sposób oceny jego efektywności.
ZALETY
Automatyzacja testowania umożliwia wykonanie wielu czynności znacznie wydajniej niż w przypadku gdyby były przeprowadzane ręcznie. Najbardziej oczywistą korzyścią płynącą z automatycznego testowania jest wykonanie testów regresyjnych dla nowej wersji programu. Wysiłek konieczny na ten typ testowania jest minimalny, pod warunkiem, że testy zostały zautomatyzowane dla wcześniejszej wersji aplikacji. W zaledwie kilka minut można wtedy wybrać odpowiednie warianty testów i je wykonać.
Jako zaletę można zaliczyć także uruchamianie więcej testów częściej. Dzięki temu, że testy wykonują się szybciej można je wykonywać częściej. To prowadzi do większej pewności, że tworzony system działa zgodnie z oczekiwaniami klienta.
Niektóre testy bardzo trudno wykonać ręcznie lub jest to wręcz niemożliwe. Do tego typu testów należą m.in. testy wydajnościowe. Próba wykonania testu, w którym 500 osób próbuje w tym samym czasie wstawić pewną informację do bazy może być dość kosztowna i trudna do zsynchronizowana w przypadku gdyby miała być przeprowadzona przez testerów.
Odciążając testerów od konieczności wykonywania testów i porównywania uzyskanego wyjścia z oczekiwanym, które są dość nudnymi zajęciami umożliwia im skupienie się na projektowaniu lepszych testów.
Na automatyzacji zyskują także same testy. Poprawia się ich spójność i powtarzalność. Testy, które są powtarzane automatycznie będą powtarzane dokładnie tak samo (przynajmniej wejście, gdyż wyjście może się różnić w zależności od np. czasu). To daje poziom regularności, który jest trudno uzyskać przez testowanie ręczne. Te same testy mogą być wykonywane w różnych konfiguracjach sprzętowych, na różnych systemach operacyjnych z wykorzystaniem różnych baz danych. To daje spójność pomiędzy platformami dla produktów wieloplatformowych, która jest niemożliwa do osiągnięcia w przypadku ręcznego testowania. Narzucenie dobrego reżimu automatyzacji testów może zapewnić spójne standardy zarówno dla testowania jak i programowania. Przykładowo narzędzie może sprawdzić, że ten sam typ cechy został zaimplementowany w ten sam sposób we wszystkich aplikacjach.
Dzięki temu, że automatyczne testy można wykonywać szybciej czas potrzebny na testowanie może zostać skrócony, co oznacza, że produkt może zostać szybciej wypuszczony na rynek.
Testowanie może także odbywać się w nocy. Testy uruchamiane są gdy testerzy kończą pracę. Nie trzeba czekać na wyniki. Będą dostępne następnego dnia rano.
WADY
Z automatyzacją testowania wiąże się wiele problemów i ograniczeń. James Bach na podstawie swojego wieloletniego doświadczenia podaje, że większość błędów wykrywana jest podczas ręcznego wykonywania testowania, bo aż 85% z nich. Tylko 15% błędów znajdywanych jest przez automatyczne przypadki testowe. By móc zautomatyzować dany wariantu testu trzeba najpierw upewnić się, że jest prawidłowy. Nie ma sensu tworzyć automatu dla niepoprawnych przypadków testowych. Testowanie wariantu testu polega najczęściej na wykonaniu go najpierw ręcznie, a następnie przeanalizowaniu uzyskanych wyników. Dopiero tak sprawdzony wariant jest automatyzowany. Największa szansa na znalezienie błędu jest podczas pierwszego wykonania testu. Raz wykryty i poprawiony błąd na ogół nie powtarza się, za wyjątkiem sytuacji, w których testowany fragment programu podlega modyfikacjom. Wtedy istnieje szansa na wprowadzenie błędu podczas zmian w kodzie aplikacji.
Testy poddawane automatyzacji muszą być dobrej jakości. Narzędzie wykonujące testy może tylko określić czy oczekiwane wyjście pasuje do faktycznie zaobserwowanego. Nie poda czy wariant testu jest prawidłowy. Jeśli przypadek testowy jest mało efektywny to prawdopodobieństwo znalezienia błędu dla takiego wariantu po jego automatyzacji będzie również niewielkie. Automat może najwyżej zwiększyć wydajność takiego testu tzn. zmniejszyć koszt i czas potrzebny do wykonania wariantu testu.
zautomatyzowane testy są mniej podatne na zmiany niż testy wykonywane ręcznie. Wymagają więcej wysiłku na etapie wytworzenia oraz w ich późniejszej pielęgnacji. Modyfikacje programu wymagają także dostosowania zautomatyzowanych testów. Mogą one nie być wprowadzone ze względów ekonomicznych. Może okazać się, że zmiana wariantów testów jest nieopłacalna jeśli nie pomyślano o ich pielęgnacji podczas ich automatyzacji.
Koszt wytworzenia automatycznych testów też nie jest bez znaczenia. Średnio wynosi on 2 do 10 razy wysiłku związanego z ręcznym wykonywaniem testów. W niektórych przypadkach koszt ten nawet wzrastał do 30 razy. W związku z tym ważne jest by automatyzować tylko te testy, dla których ma to ekonomiczny sens, czyli takie, które będą wiele razy uruchamiane. Dzięki temu koszt związany z ich wytworzeniem się zwróci.
Automatyczne testy to tylko program posłusznie wykonujący instrukcje. Niestety tylko tester jest w stanie stwierdzić, czy wykonywany przypadek testowy zawiera błąd. Także tylko on jest w stanie poprawić wariant testu by sprawdzał dodatkowe rzeczy jeśli uzna, że ów wariant nie jest dostatecznie szczegółowy.
17. Asercje i weryfikacja uzyskanych wyników z przyjętymi założeniami perspektywy logicznej realizowanej aplikacji.
Perspektywą logiki zajmują się analitycy i projektanci oprogramowania. W niej rozważa się jaki będzie model matematyczny danej funkcjonalności. W celu wykrycia nieprawidłowości stosuje się testowanie.
Wykonywane są Testy jednostkowe przez programistę w środowisku laboratoryjnym. Celem tych testów jest sprawdzenie pojedynczej jednostki oprogramowania jaką jest klasa, metoda, czy też zbiór współpracujących ze sobą klas.
Asercje to wywołania metody, która sprawdza czy jest spełniony określony warunek. Asercje składają się z następujących grup metod:
assertEquals – sprawdza czy obiekty są tożsame (lub wartości liczbowe są równe). W przypadku liczb zmiennoprzecinkowych wymagane jest jeszcze podanie przedziału, dla którego liczba uznawana jest za tożsamą. Dla liczb porównanie odbywa się z wykorzystaniem operatora ==, natomiast obiekty porównywane są przez wywołanie metody equals .
assertSame – sprawdza identyczność obu parametrów, czyli dla każdego przypadku stosuje operator ==.
assertNotSame – analogicznie co dla assertSame, z tymże odwrotnie – sprawdza czy podane obiekty to różne instancje (wykorzystuje operator !=).
assertTrue – bada prawdziwość podanego warunku
assertFalse – bada fałszywość podanego warunku
assertNull – sprawdza czy argument jest wartością null
assertNotNull – weryfikuje czy argument jest obiektem różnym od null
fail – powoduje bezwarunkowe zgłoszenie nieprawdziwości asercji.
18. Automatyzacja zadań inżynierii oprogramowania.
Automatyzacja zadań przydaje się do zaoszczędzenia czasu podczas wykonywania często powtarzanych czynności nie wymagających myślenia. Można zautomatyzować np. uruchamianie aplikacji, sprawdzenie poczty, przenoszenie czy usuwanie plików. W inżynierii automatyzacja niektórych czynności może wpłynąć na skrócenie czasu modyfikacji kodu. Jednym ze stosowanych narzędzi jest ANT. Tworzy sie w nim skrypty w postaci plików xml, pozwalające kompilować nawet złożone aplikacje. Skrypty działają niezależnie od systemu, środowisk programistycznych. Jeden skrypt można używać do wielu aplikacji.
Każdy skrypt składa się z zestawu nazwanych celów (ang. ˙ target). Każdy cel powinien posiadać unikalną nazwę, która jednocześnie definiuje jego przeznaczenie.
build - cel kompilujący pliki źródłowe i inną dokumentację
19. Czynniki wpływające na wzrost złożoności wdrażanego obecnie oprogramowania.
Lehman stworzy kilka praw związanych z oprogramowaniem. Jednym z nich jest Prawo wzrostu złożoności. W miarę rozwoju programu wzrasta jego złożoność, sama technologia dąży do wzrostu złożoności. Istnieje punkt nasycenia, poza którym dalszy rozwój jest bardzo trudny lub nawet niemożliwy, o ile nie wcześniej stosowano technik zarządzania złożonością. Wprowadzanie zmian do oprogramowania (nazywanych często progresywnymi) zwykle narusza pierwotną strukturę programu, a kumulacja zmian tylko ten proces nasila. Liczba powiązań i interakcji pomiędzy różnymi modułami w systemie zwiększa się, co utrudnia zrozumienie go, a także jego dalsze modyfikacje. Alternatywą jest poniesienie dodatkowych nakładów w trakcie pielęgnacji, poświęconych na czynności antyregresywne: upraszczanie struktury i lepsze wkomponowanie wprowadzanych zmian w istniejące oprogramowanie. Równowaga pomiędzy czynnościami progresywnymi a regresywnymi zależy od ilości i rodzaju informacji zwrotnej płynącej ze środowiska: inaczej są obsługiwane żądania związane z naprawą błędów, a inaczej z rozszerzeniami funkcjonalnymi.