1. Wpływ różnych modeli cyklu życia oprogramowania na jego proces walidacji i weryfikacji.

Wyróżniamy kilka modeli:

model kaskadowy - kolejne etapy rozwoju oprogramowania następują po sobie w ściśle określonym porządku: określenie wymagań, analiza, projektowanie, implementacja, testowanie i konserwacja. Walidacja i weryfikacja następuje w późnym etapie stąd też jeżeli zostały popełnione jakieś błędy w fazach wcześniejszych, w fazie określenia wymagań lub projektowania koszt i czas ich usunięcia okazuje się bardzo duży. Aby je usunąć trzeba się cofnąć do początku, ponadto klient ma mało kontaktu z tworzonym oprogramowaniem

model ewolucyjny - posiada takie same etapy jak model kaskadowy jednak po każdym z nich powstaje prototyp, zbiór najważniejszych funkcji, co jest dość drogie jednak ma dobry wpływ na walidację, ponadto daje możliwość powrotu do wcześniejszej fazy i szybsze korygowanie popełnionych błędów

model przyrostowy - odmiana ewolucyjnego; stosuje się tak zwane przyrosty, po określeniu wymagań system jest dzielony na części, podzbiory funkcji. Klient dostaje każdorazowo rozrastające się wersje systemu, każdą z nich się testuje, co pozwala na każdym przyroście wyszukać błędy walidacji oraz weryfikować błędy systemu, kodu.

model spiralny - odmiana ewolucyjnego; ma postać spirali gdzie każda faza to jedna pętla. Każda dzieli się na 4 sektory: koncepcja, modyfikacja koncepcji (analiza ryzyka), wdrożenie i ocena. Ocena następuje po każdej iteracji tworzonego rozwiązania dzięki czemu jest wysoki poziom weryfikacji i walidacji oprogramowania. Klient ściśle współpracuje przy projekcie. Walidacja i weryfikacja są czynnościami, które powinno się przeprowadzać we wszystkich fazach wytwarzania oprogramowania. Walidacja i weryfikacja realizowane są na dwa uzupełniające się sposoby: poprzez inspekcję wymagań, projektu i kodu, poprzez testowanie programu. Jest to trudny model do realizowania, bierze się w nim pod uwagę analizę ryzyka. Jest to czasochłonny model.

model komponentowy - po określeniu wymagań następuje analiza czy można wykorzystać istniejące już, gotowe komponenty. Następnie modyfikowane są wymagania w konsekwencji zastosowania tychże komponentów. W fazie projektowania uwzględnia się gotowe komponenty i ewentualne nowe, które kiedyś znów mogą być wykorzystane. W stosunku do walidacji model komponentowy nie jest dobry, bo gotowe komponenty mogą być niezgodne z wymaganiami, oczekiwaniami klienta. Modyfikacje kodu, i weryfikacja także jest utrudniona.

model V - zaczyna się od pozyskania wymagań. Stworzone wymagania są podstawą do rozpoczęcia definiowania weryfikacji. Wymagania podlegają analizie, w której zespół już zastanawia się nad testami. Następnie tworzona jest architektura projektu, projekt jest dzielony na poszczególne komponenty i każdy z nich jest poddawany testom. Na końcu jest implementacja. Model V precyzyjnie pokazuje zależności, jakie powinny łączyć kolejne etapy projektu. Każdy etap projektowania kończy się stworzeniem danych wejściowych dla następnej fazy oraz do korespondującej z nim fazy weryfikacji. Zachęca do jak najwcześniejszego rozpoczęcia procesu tworzenia planów testów, specyfikacji

testowej i samego testowania. Fazy: projektowanie i weryfikacja/walidacja, nie następują po sobie ale są wykonywane równolegle.

programowanie ekstremalne - Cykl życia w XP wygląda następująco: mamy wydania podzielone na przyrosty. Każde wydanie ma wartość użytkową i trafia do użytkowników końcowych, dzięki czemu programiści dostają sprzężenie zwrotne. Przyrosty mają jedynie charakter wewnętrzny. Pośrednie przyrosty niekoniecznie stanowią produkt, z którego klient byłby w stanie skorzystać. Każdy przyrost powinien trwać 2-3 tygodnie, oraz zawierać kilka opowieści użytkownika.

2. Dobór metodyki pozyskiwania wymagań i analizy uwarunkowań procesu specyfikacji wymagań.

Pozyskiwanie wymagań to praca z klientem od którego powinniśmy się dowiedzieć co system, który projektujemy powinien robić. Od klienta pozyskuje się wymagania funkcjonalne systemu czyli te widziane od strony użytkownika. Lista tradycyjnych metod zbierania wymagań:

wywiady - w ramach wywiadów wyróżniamy wywiady z pytaniami otwartymi oraz zamkniętymi; zalety: efektywny sposób komunikacji; wady: wysokie koszty, czasochłonne, ograniczona liczba zadanych pytań i rozmówców, ktoś może coś źle wyrażać;

kwestionariusze – przygotowywane są ankiety do wypełnienia; zalety: niskie koszty, pozyskiwanie informacji od wielu osób w krótkim czasie; wady: metoda pasywna, niższy poziom zrozumienia, brak możliwości zadania dodatkowych pytań

obserwacja użytkowników w miejscu pracy – zalety: dokładniejszy obraz rzeczywistości, obiektywne miary interakcji użytkownika z systemem; wady: użytkownik obserwowany może zachowywać się inaczej, ograniczenia czasu i liczby osób, które mogą być obserwowane;

analiza dokumentów biznesowych – przeprowadzana w celu ustalenia szczegółów dotyczących organizacji i obecnie działającego systemu; zalety: sformalizowane odzwierciedlenie przepływu informacji.

burza mózgów - zespół zgłasza pomysły na temat funkcjonowania systemu

Nowoczesne metody zbierania wymagań:

Sesje JRP (sesje wspólnego planowania wymagań) Podstawą sesji JRP jest zebranie w jednym miejscu i czasie użytkowników, kierowników i analityków zaangażowanych w analizę systemu, podobnie jak przy wywiadzie grupowym. Jednakże sesja JRP ma specyficzną strukturę ról i agendy, która umożliwia zbieranie wymagań dla systemu od wszystkich zainteresowanych osób jednocześnie.

Prototypowanie Prototypowanie pozwala na szybkie przekształcenie podstawowych wymagań (uzyskanych podczas np. wywiadów) w działającą, aczkolwiek ograniczoną, wersję przyszłego systemu.

Analiza - pozyskane wymagania muszą być poddane analizie a następnie negocjacji wymagań, jest to związane z tym, że wymagania mogą być wzajemnie sprzeczne, niejednoznaczne itp. – im wcześniej się takie wady wykryje tym lepiej dla całego przedsięwzięcia. Wykryte defekty, takie jak np. sprzeczności między wymaganiami, należy usunąć. Zazwyczaj wymaga to negocjacji z wieloma zainteresowanymi osobami i może być bardzo trudne.

3. Sposoby oceny wykonalności projektu programistycznego w zakresie założeń oraz analizy zależności wymagań funkcjonalnych oraz niefunkcjonalnych.

Ocenę wykonalności projektu programistycznego można ustosunkować do :

- zakresu funkcjonalności - jak bardzo jest złożony projekt pod względem wymagań funkcjonalnych i niefunkcjonalnych, ile udało się go zrealizować

- terminy - jaki jest potrzebny czas na realizację projektu, czy projekt zostanie zrealizowany do terminu końcowego, czy jest dobrze rozplanowany harmonogram

- budżet - jakie są koszty realizacji projektu, koszt wytworzenia oprogramowania, utrzymania i konserwacji

- skalowalność sytemu i możliwość jego rozwoju, przenośność na inne platformy. Jako ocenę wykonalności projektu można również przyjąć kryteria o charakterze: ekonomicznym, moralnym, estetycznym, socjalno-politycznym, religijnym. Te wszystkie aspekty tworzą jakość oprogramowania.

Wykonalność projektu podlega także ocenie przez klienta oraz przez prowadzone na nim testy.

4. Oprogramowanie rozwojowe oraz efektywne metody jego projektowania i implementacji.

Coraz więcej projektów jest przeznaczonych do rozwijania. Obecnie rozwój nowego oprogramowania wymaga znacznie mniejszych nakładów, niż pielęgnacja już istniejącego. Ewolucja oprogramowania jest procesem jego rozwoju sterowanym zmianami wymagań, poprawą błędów czy też rozwojem sprzętu. Ewolucja jest nieunikniona: oprogramowanie ewoluuje, ponieważ to leży w jego naturze. Natomiast pielęgnacja to zaplanowany proces, który służy do kontrolowania ewolucji i czynników, które na nią wpływają. Pielęgnacja ma na celu wykrywanie i usuwanie błędów, poprawę atrybutów jakościowych działania programu oraz adaptację do zmian w nim zachodzących. Pojęcia te czasem stosuje się zamiennie.

Oprogramowanie rozwojowe realizowane jest na podstawie modelu ewolucyjnego - przede wszystkim przyrostowy. Przyrosty umożliwiają udoskonalanie oprogramowania zgodnie z informacjami pobranymi od klienta. Tworzenie ewolucyjne polega na opracowaniu wstępnej implementacji, pokazaniu jej użytkownikowi z prośbą o komentarze i udoskonaleniu jej w wielu wersjach, aż do powstania odpowiedniego systemu. Nie ma tu oddzielnych czynności specyfikacji, tworzenia i zatwierdzania. Są one prowadzone raczej równolegle, z szybkim rozpoznaniem na informacje zwrotne.

5. Typy i modele produktów oprogramowania oraz obszary ich zastosowania, a także związane z nimi metodyki zarządzania procesem wytwórczym.

W kontekście pielęgnacji oprogramowania, Lehman wprowadził prosty podział programów na trzy kategorie:

programy typu S, które są oparte w całości na formalnej specyfikacji i dlatego nie podlegają ewolucji. Programy typu S reprezentują teoretyczną gałąź rozwoju inżynierii oprogramowania. Wobec nich zakłada się, że powstały na podstawie pełnej i kompletnej specyfikacji, w której zawarto wszystkie niezbędne informacje w sposób jednoznaczny i niesprzeczny. Przyjmuje się założenie, że specyfikacja odpowiada niezmiennym potrzebom użytkownika, a zatem jego udział w pracach nad systemem nie jest konieczny. Jedyną podstawą do tworzenia programu, a następnie jego weryfikacji jest właśnie specyfikacja. Wszelkie cechy, które oprogramowanie posiada, a które nie zostały uwzględnione w specyfikacji, są ignorowane, ponieważ z punktu widzenia specyfikacji nie istnieją. W takim modelu proces ewolucyjny w zasadzie nie występuje, ponieważ wszelkie żądania zmian w oprogramowaniu, niezależnie od ich natury i źródła, powodują stworzenie nowej specyfikacji, której implementacją jest zupełnie nowy program.

programy typu P, które reagują na zmiany w środowisku i w akceptowalny sposób dostarczają środków do interakcji z nim. Model budowany na podstawie obrazu środowiska (świata rzeczywistego) naśladuje pewne cechy tego środowiska, ale z natury jest niekompletny. Niepełność modelu jednak jest pożądaną cechą, ponieważ pozwala pomijać nieistotne elementy środowiska, a co za tym idzie – stosować to podejście do większych i bardziej złożonych zadań niż w przypadku programów typu S. Na podstawie modelu powstaje specyfikacja (również niepełna, z możliwymi sprzecznościami), a następnie program. Jeżeli w środowisku zachodzi zmiana, która wymaga odzwierciedlenia w programie, wówczas program podlega modyfikacji.

programy typu E, które są osadzone w środowisku i nieustannie z nim oddziałują, co powoduje potrzebę ciągłych zmian. odpowiadają dużej grupie rzeczywistych programów, osadzonych i pracujących przez długi czas w środowisku, dla którego powstały. Są to zwykle duże systemy, tworzone na zamówienie przez duże organizacje wytwarzające oprogramowanie. Specyfikacja i model są – podobnie jak w przypadku programów typu P – z natury niepełne i mogą posiadać błędy lub luki. Jednak największa różnica polega na integracji programu ze środowiskiem, co oznacza, że oba elementy na siebie nieustannie oddziałują. W ten sposób zmiana w środowisku natychmiast oddziałuje na program, wywierając potrzebę zmiany także w nim. Powoduje to niemal nieustanny napływ informacji zwrotnej od użytkowników systemu, co pozwala na wprowadzanie zmian najistotniejszych z ich punktu widzenia.

6. Kontrola jakości, testy oprogramowania i ich rodzaje.

Jakość jest to zgodność z wymaganiami. Potrzeba dbania o jakość, w tym dokonywanie przeglądów i testowanie oprogramowania, wynika także z drugiej zasady Covey’ego. Zasada ta każe zaczynać mając koniec na względzie. W przypadku przedsięwzięcia programistycznego tym końcem jest oddanie oprogramowania i opinia klienta o produkcie. Aby mieć uzasadnione nadzieje na akceptację i zadowolenie klienta trzeba już zawczasu dbać o jakość i ją kontrolować dokonując najpierw przeglądów, a później – gdy dostępny będzie już kod – przeglądów oraz testowania. Osiem wymiarów jakości:

• wydajności. np. szybkość przetwarzania danych.

• niezawodność. Można ją rozumieć np. jako częstotliwość pojawiających się błędów

• Trzecim wymiarem jest wytrzymałość, jak długo system będzie mógł pracować bez istotnych modyfikacji funkcjonalnych.

• łatwość naprawy. Jeśli oprogramowanie zostało zaprojektowane modularnie z użyciem odpowiednich wzorców, to jego naprawa będzie pewnie dużo łatwiejsza niż oprogramowania o strukturze monolitycznej.

• Estetyka w przypadku oprogramowania chyba najbardziej odnosi się do interfejsu użytkownika.

• Cechy funkcjonalne mogą odgrywać pierwszoplanową rolę przy wyborze systemu.

• reputacja wytwórcy.

• zgodność ze standardami i innymi wymaganiami.

Testy oprogramowania także kontrolują jakość oprogramowania. Testy wykonuje się w celu wykrycia błędów. Rodzaje testów:

Testy jednostkowe wykonuje programista 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 (tzw. klaster klas).

Przetestowane jednostki kodu są następnie łączone w większą całość. Podczas integracji przeprowadzane są testy integracyjne. Ich zadaniem jest sprawdzenie łączonych fragmentów kodu. Weryfikowana jest współpraca integrowanych jednostek między sobą. Celem jest określenie czy po zintegrowaniu otrzymany podsystem nadaje się do dalszego testowania. Proces łączenia i testowania jest powtarzany aż do powstania całego systemu.

Testy systemowe wykonywane są po pomyślnej integracji jednostek wchodzących w skład systemu będącego przedmiotem testowania. Wykonywane są przez programistów lub niezależny zespół w kontrolowanym środowisku laboratoryjnym. Sprawdzają one czy system jako całość spełnia wymagania funkcjonalne i jakościowe postawione przez klienta. Testy akceptacyjne Tym razem to użytkownik lub reprezentant klienta sprawdza system. Testy przeprowadzane są w środowisku docelowym lub jak najbardziej zbliżonym do niego. Testy regresyjne. Jest to ponowne wykonanie opracowanych wcześniej testów by sprawdzić czy wprowadzone modyfikacje w programie nie spowodowały powstania błędu.

Wykonywane są przeglądy - proces w trakcie którego np. kod jest prezentowany różnym osobom w celu skomentowania bądź jego zatwierdzenia. Jest to ocena artefaktu

Inspekcja jest to wizualne sprawdzenie artefaktu celem wykrycia lub zidentyfikowania anomalii dotyczących oprogramowania.

7. Budżet, ryzyko i koszty związane ze zmianami w trakcie realizacji projektu programistycznego.

Każdy projekt informatyczny jest związany z pewnym ryzykiem. Rozpoczynając go określamy budżet, czyli pieniądze na realizację projektu. Niestety większość projektów kończy się przekroczeniem budżetu lub terminów. Aby zapobiegać takim sytuacjom próbuje się oszacować ryzyko projektu. Najpierw ryzyko należy zidentyfikować - wskazać jakie czynniki ryzyka mogą wystąpić (czynniki projektowe, harmonogram - wywieranie presji czasu przez klientów, koszty - minimalizowanie ich, wymagania i oczekiwania użytkowników są wyzwaniem dla kierowników, jakość produktu, czynniki losowe, czynniki techniczne itp). Planowanie projektu i odpowiednie zarządzanie ma ogromny wpływ na otrzymany wynik. Przez źle rozplanowany czas jest najwięcej błędów, pisany pośpiesznie kod nie ma czasu na testowanie i poprawianie. Gdy Projekt ma duży zakres i za mało czasu wyznaczymy na niego to nie uda się go zrealizować co będzie się wiązało z dużymi kosztami odszkodowania dla klienta. za łatwy projekt + dużo czasu = źle (zwiększone ryzyko błędów). Za mało ludzi + za duży zakres + mało czasu = źle.

Wybrany model życia oprogramowania ma wpływ na to jak zmiany wpływają na projekt, najmniej elastyczny model kaskadowy - zmiana w późniejszym etapie wiążę się z większymi kosztami i wydłużaniem się czasu realizacji (projekt może zostać nie ukończony). np. Model przyrostowy - możliwość elastycznego reagowania na powstałe opóźnienia. Jeżeli realizacja fragmentu systemu opóźni się, nie musi to oznaczać opóźnienia całego przedsięwzięcia. Istnieje wtedy możliwość przyspieszenia prac nad dalszymi częściami. – Im później zostanie wykryty błąd, tym większy jest koszt jego usunięcia. Dlatego Szacowanie budżetu jest trudne, wymaga określenia różnego rodzaju ryzyka (choroba specjalisty, całego zespołu, brak prądu), mogą być wydatki nie przewidziane (wykup nowego sprzętu) Im bardziej przedłuża się projekt, tym więcej pieniędzy pochłania (potrzebny większy budżet: pensje pracowników, nowe błędy, prąd, szkolenia nowych ludzi, materiały biurowe) Dzisiaj, kryzys branży oprogramowania jest związany właśnie z przekraczaniem terminów, budżetu, koniecznością nadgodzin i kiepską jakością (zmieszenie funkcjonalności).

8. Zasady skutecznego zarządzania zespołem programistycznym.

Aby skutecznie realizować projekt musi być dobre zarządzanie zespołem. Kierownik projektu odgrywa znaczącą rolę - zarządza personelem i zadaniami (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). Aby odnieść sukces stosuje się 7 zasad Covey’ego:

pierwsze trzy dotyczą zwycięstw indywidualnych:

1. Bądź proaktywny- proaktywność to odpowiedzialność za podejmowane działania. Ludzie proaktywni kierują się wartościami, szukają różnych rozwiązań problemów i potrafią je rozróżniać.

2. Zaczynając miej na względzie koniec - Tylko myśląc o końcu przedsięwzięcia i jego konsekwencjach (zarówno pozytywnych, jak i negatywnych) jesteśmy w stanie podjąć racjonalną decyzję. Jest to ważna cecha kierownika, przywódcy innych programistów

3.Aby rzeczy pierwsze były pierwsze - ta zasada dotyczy zarządzania czasem, nie tylko swoim ale też innych. Przydzielane zadania muszą mieć odzwierciedlenie w czasie. Jeżeli mamy same pilne i ważne zadania to cały czas robimy „rzeczy na wczoraj” - uporczywa walka z czasem prowadząca do wypalenia się. Najlepiej planować zadania tak by były w grupie ważne i nie pilne - robimy ważne rzeczy ale bez presji czasu.

Kolejne dotyczą pracy zespołowej:

4. Myśl o obopólnej korzyści - mentalność Win/Win: jest to dążenie do wzajemnej korzyści. Mój sukces nie wyklucza Twojego. Jest to nastawienie na poszukiwanie rozwiązania, które będzie pożyteczne dla obu stron.

5. Najpierw staraj się zrozumieć - a dopiero potem oczekuj, że będziesz zrozumiany. Chodzi o dobrą komunikację i umiejętność słuchania drugiej osoby.

6. Dbaj o synergię - W odniesieniu do zespołów można powiedzieć, że synergia jest to budowanie na silnych cechach członków zespołu i kompensowanie słabości członków zespołu. Na przykład ktoś jest świetnym programistą, ale jak to często z programistami bywa, jest introwertykiem i podświadomie unika kontaktów z innymi ludźmi. Jeśli taka osoba miałaby zbudować system informatyczny spełniający specyficzne wymagania jakiegoś klienta, to będzie miała ogromne problemy, żeby te wymagania od klienta pozyskać (klienci zazwyczaj nie wiedzą, jak ma wyglądać budowany dla nich system i ciągle plączą się w swoich zeznaniach). Z kolei osoba bardzo przedsiębiorcza i komunikatywna, ale nie znająca się na wyrafinowanych technologiach informatycznych też takiego systemu w sensownym czasie nie zbuduje. Ale jeśli te 2 osoby działałyby jako zespół, to prawdopodobnie dałyby sobie radę, żeby pozyskać od klienta wymagania i zbudować system, który będzie je spełniał.

7. Ostrz piłę - polega na ciągłym doskonaleniu się. Zarówno kierownik jak i pozostałe osoby w zespole muszą sie doskonalić, podnosić kwalifikację aby projekt zakończył się sukcesem.

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ą.

Na ostateczny wygląd projektu (jakość) ma tzw. trójkąt (zakres, czas, budżet);

1. harmonogramowanie (przestawienie dokładnego planu realizacji poszczególnych zadań, praca systematyczna i uporządkowana, prawidłowa organizacja pracy projektantów)

2. Właściwa dokumentacja (pozwala na dopilnowanie zakresu prac),

3. Pilnowanie czasu i zakresu ma wpływ na budżet (po części; nie ma poślizgu -> nie ma dodatkowych kosztów, zakres zgodny z wymaganym -> nie ma potrzeby ponownego projektowania systemu ; nie zawsze bo części wydatków się nie przewidzi).

4. Wypracowanie standardów; korzystanie z gotowej części kodu.

5. Określenie priorytetów.

10. Uwarunkowania i sposoby zapewnienia jakości oprogramowania.

Jak dla mnie to samo co pytanie 6.

Aby zapewnić jakość oprogramowania należy mieć na względzie:

- częsty kontakt z klientem pozwala na lepszą walidację wymagań i weryfikację rozwiązań

-zgodność z wymaganiami użytkowników

-właściwe nadzorowanie zespołem - zasady Covey z pytania 8

- testowanie produktów na różnych etapach w celu wykrycia błędów

-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

-certyfikacja - potwierdzenie jakości, poprawności działania oprogramowania

-przejrzysta, dobrze opracowana dokumentacja i specyfikacja wymagań

-wybór właściwego cyklu życia

-dobrze skomponowany zespół projektowy

- projektowanie mające na uwadze łatwość pielęgnacji

Zasady SOLID

Single responsibility principle - klasa powinna mieć tylko jeden powód do zmiany, Jeśli jest więcej takich powodów powinniśmy przenieść funkcjonalności do kolejnych klas.

Open Close Principle - refaktoryzacja kodu, podnoszenie jakości

Liskov Substitution Principle - dziedziczenie nie powinno przesłaniać metod

Interface Segregation Principle - interfejsy mają być niezależne od siebie Programista powinien tworzyć interfejsy dedykowane do poszczególnych funkcjonalności i zawierające funkcje rzeczywiście wymagane przez zakres odpowiedzialności reprezentowany przez budowany interfejs.

Dependency Inversion Principle- jeżeli projektujemy warstwę abstrakcyjną i implementacyjną to są one niezależne. Jeżeli coś znajduje się w abstrakcyjnej, nie musi być od razu implementowane. ALE implementacja opiera się na warstwie abstrakcyjnej

PERSPEKTYWY 4+1

Modelowanie złożonych systemów jest zadaniem trudnym i angażuje wiele osób o różnym sposobie postrzegania systemu. Aby uwzględnić te punktu widzenia, UML jest często określany jako język modelowania z 4+1 perspektywą. Cztery pierwsze opisują wewnętrzną strukturę programu na różnych poziomach abstrakcji i szczegółowości. Ostatnia perspektywa opisuje funkcjonalność systemu widzianą przez jego użytkowników. Każda perspektywa korzysta z własnego zestawu diagramów pozwalających czytelnie przedstawić modelowane zagadnienie. Są to:

Perspektywa przypadków użycia – opisuje funkcjonalność, jaką powinien dostarczać system, widzianą przez jego użytkowników.

Perspektywa logiczna – zawiera sposób realizacji funkcjonalności, strukturę systemu widzianą przez projektanta

Perspektywa implementacyjna – opisuje poszczególne moduły i ich interfejsy wraz z zależnościami; perspektywa ta jest przeznaczona dla programisty

Perspektywa procesowa – zawiera podział systemu na procesy (czynności) i procesory (jednostki wykonawcze); opisuje właściwości pozafunkcjonalne systemu i służy przede także programistom i integratorom

Perspektywa wdrożenia – definiuje fizyczny podział elementów systemu i ich rozmieszczenie w infrastrukturze; perspektywa taka służy integratorom i instalatorom systemu

11. Dokumentacja fazy pozyskiwania wymagań, projektowania, implementacji i testowania w projekcie programistycznym.

Dokumentację można i powinno się (wymagają tego np. normy ISO9000) prowadzić na wszystkich etapach wytwarzania. Dokumentacja jest najczęściej tworzona zgodnie z pewnymi standardami (także udokumentowanymi). W fazie realizacji procesu wytwarzania oprogramowania dokumentacja może obejmować:

• plany, harmonogramy, szacunki

• wszelkiego typu projekty i modele systemu oraz jego elementów (różnorodne diagramy, schematy, algorytmy) związane z wszystkimi fazami procesu wytwarzania oprogramowania

• raporty

• kod źródłowy

• korespondencja, wymiana informacji na temat projektu między członkami zespołu realizującego

W skład dokumentacji końcowej (dostarczanej odbiorcom) najczęściej wchodzą:

• ogólny funkcjonalny opis systemu

• przewodnik użytkownika (user's guide)

• pełny opis systemu (reference manual)

• przewodnik instalacji i podręcznik administratora

• dokumentację wersji (wydania, release notes)

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

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. Zapis testów jakim został poddany system

12. Definiowanie, formalizacja i specyfikacja wymagań w projektach informatycznych.

Fazy powstawania projektu informatycznego:

1. Pozyskiwanie wymagań - to praca z klientem od którego powinniśmy się dowiedzieć co system, który projektujemy powinien robić. Od klienta pozyskuje się wymagania funkcjonalne systemu czyli te widziane od strony użytkownika.

2. Analiza i negocjacja wymagań - pozyskane wymagania muszą być poddane analizie a następnie negocjacji wymagań, jest to związane z tym, że wymagania mogą być wzajemnie sprzeczne, niejednoznaczne itp. – im wcześniej się takie wady wykryje tym lepiej dla całego przedsięwzięcia. Wykryte defekty, takie jak np. sprzeczności między wymaganiami, należy usunąć. Zazwyczaj wymaga to negocjacji z wieloma zainteresowanymi osobami i może być bardzo trudne.

3. Stworzenie dokumentu specyfikacji wymagań na podstawie wcześniej uzyskanych informacji - zakres funkcjonalności zamawianego systemu; przedstawienie ich przy pomocy przypadków użycia klientowi

4. Faza implementacji - wybór języka programowania, pisanie kodu, jest związana z testami które powinny być pisane równolegle z kodem, pisanie dokumentacji Opis procedur, funkcji, danych we/wy

5. Scalanie systemu i testy końcowe, tworzenie dokumentacji użytkowej

6. W fazie eksploatacji oprogramowanie jest wykorzystywane przez użytkownika(ów), a producent dokonuje konserwacji oprogramowania - modyfikacje polegające na usuwaniu błędów, zmiany i rozszerzenia funkcji systemu (pielęgnacja 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.

Diagram stanów służy do pokazania zmiany zachowania obiektu. Obiekt, reagując na nadchodzące zdarzenia, jeżeli spełnione są określone warunki, zmienia swój stan i położenie na diagramie stanu.

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.

Aplikacje użytkowe użytkownik może testować w trakcie użytkowania.

System krytyczny - system, którego awaria lub niewłaściwe funkcjonowanie może spowodować:

• stratę życia, lub poważny uszczerbek na zdrowiu;

• duże straty materialne;

• zanieczyszczenie środowiska;

Systemy krytyczne wymagają niezawodnego oprogramowania, dlatego konieczne jest aby zostały jak najdokładniej przetestowane, a zwłaszcza w przypadku sytuacji nietypowych/niespodziewanych. Proces analizy i implementacji systemów krytycznych powinien być tak zaprojektowany, aby zapobiegać wprowadzaniu wszelkich błędów - powinno się wyraźnie sprecyzować wymagania dotyczące bezpieczeństwa. Do procesu walidacji powinni zostać włączeni eksperci w danej dziedzinie.

* systemy podtrzymywania życia - sztuczne serca;

* poduszka powietrzna (Producenci muszą również zapewnić, że nie nastąpi samoczynne uruchomienie mechanizmu, gdyż wtedy można stracić życie właśnie w wyniku uderzenia poduszką. Jest to szczególnie istotne po wypadku, który nie spowodował wystrzału poduszki. Strażacy, którzy ratują ofiary używają czasem narzędzi, które wprowadzają samochód w wibracje. Wibracje te mogłyby wywołać wystrzał poduszki, co byłoby dla nich szczególnie niebezpieczne.);

* błąd oprogramowania spowodował brak prądu na pewnym dość sporym terenie USA i Kanady - 2003);

* zagłodzenie łazika na marsie,

* błędy systemów wojskowych (wystrzelenie rakiet w cele cywilne)

16. Wady i zalety procesu automatyzacji testowania realizowanego oprogramowania oraz sposób oceny jego efektywności.

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.

1. Prawo nieustannej zmiany żądania zmian funkcjonalnych powodują konieczność modyfikacji (poprawy błędu, rozszerzenia funkcjonalnego etc.) oprogramowania.

2. Prawo wzrastającej 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

3. Prawo samoregulacji system sterowany informacją zwrotną płynącą ze środowiska ma właściwości samoregulujące.

4. Prawo organizacyjnej stabilności tempo rozwoju każdego systemu na pewnym etapie stabilizuje się na stałym poziomie

5. Prawo zachowania przyzwyczajeń nawyki związane z obsługą oprogramowania stanowią bardzo wyrazisty i intuicyjny przykład czynnika ograniczającego tempo rozwoju oprogramowania.

6. Prawo ciągłego wzrostu funkcjonalność oprogramowania musi rosnąć aby satysfakcja użytkowników była na tym samym poziomie

7. Prawo spadku jakości jakość oprogramowania spada o ile nie jest ono dostosowywane do zmian zachodzących w swoim środowisku operacyjnym

8. Prawo przyrostowego rozwoju ewolucja oprogramowania jest złożonym, wielopoziomowym i uwzględniającym wiele punktów widzenia systemem z informacją zwrotną. - powinno oddawać się klientowi prototypy