Zakres materiału obowiązujący na egzaminie z przedmiotu Inżynieria oprogramowania:

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

Cykl życia oprogramowania - w skrócie: określenie wymagań, zaprojektowanie, wykonanie.

Walidacja - Czy budujemy prawidłowy produkt?

Właściwy, czyli odpowiadający oczekiwaniom i potrzebom użytkowników.

Oczekiwania użytkownika są subiektywne np. potrzebne są inne formatki.

Weryfikacja - Czy budujemy prawidłowo produkt?

We właściwy sposób, to znaczy zgodnie z wytycznymi (specyfikacją)
i z zachowaniem odpowiednich standardów.

Walidacja i weryfikacja realizowane są na dwa uzupełniające się sposoby:
poprzez inspekcję wymagań, projektu i kodu, poprzez testowanie programu.

Modele życia oprogramowania określają czynności wykonywane w poszczególnych fazach oraz
ustalają kolejność ich realizacji; pozwalają uporządkować przebieg prac, ułatwiają planowanie zadań oraz monitorowanie przebiegu ich realizacji.

• Kaskadowy

Kolejne etapy są wykonywane ściśle według porządku, fazy występują sekwencyjnie po kolei (następna faza zaczyna się dopiero jak się zakończy faza wcześniejsza).
Zalety modelu kaskadowego wiążą się przede wszystkim z łatwością zarządzania przedsięwzięciem ­- planowanie, harmonogramowanie oraz monitorowanie przedsięwzięcia jest łatwiejsze.

Wady: narzucenie twórcom oprogramowania kolejności wykonywania prac;
długa przerwa w kontaktach klientem, mały wpływ użytkownika (nie bierze on bezpośredniego udziału w realizacji projekt) - walidacja na późniejszym etapie, z tego powodu wynika większość błędów (brak zgodności z oczekiwaniami użytkownika). Znalezienie błędu skutkuje tym, że trzeba robić wszystko od początku! (ponowne przejście przez pierwsze etapy pracy, strata czasu i pieniędzy). Walidacja przebiega dopiero w ostatniej fazie (użytkowania
i konserwacji).
Z weryfikacją jest w sumie podobnie, chociaż to czy program jest zgodny ze specyfikacją, normami i poprawny kod łatwiej jest przypilnować (nie jest potrzebny do tego użytkownik).
Wysoki koszt usunięcia błędów popełnionych w fazie określania wymagań lub projektowania,
a wykrytych w fazie testowania lub użytkowania.

Dlatego model kaskadowy powinien być używany jedynie wtedy,
gdy wymagania są jasne i zrozumiałe.

Model kaskadowy cyklu życia oprogramowania wprowadza fazy:

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

• fazę analizy: analiza wymagań oraz studium wykonalności

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

• fazę implementacji, w której projekt zostaje zaimplementowany w konkretnym środowisku programistycznym,

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

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

• Ewolucyjny

Ulepszona wersja modelu kaskadowego poprzez rezygnację ze ścisłego, liniowego następstwa faz.

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. Wstępnie opracowana implementacja pokazywana jest użytkownikowi z prośbą o opinię (walidacja).

• Prototypowanie

jest modelem, którego celem jest minimalizacja ryzyka związanego z niewłaściwym określeniem wymagań; za każdym razem powstaje prototyp, np. zbiór najważniejszych funkcji do przetestowania przez klienta (walidacja).

Tworzy się prototypy, co daje możliwość powrotu do wcześniejszej fazy, dopracowywanie oprogramowania; użytkownik dostaje prototyp, przez co łatwo sprawdzić czy wszystko ok. (walidacja), częstszy kontakt z klientem = lepsze zrozumienie, szybciej się wyjaśniają problemy, rozwiązywane są na bieżąco, szybsze wykrycie nieporozumień, brakujących funkcji, trudnych usług, braków w specyfikacji wymagań; walidacja i weryfikacja funkcjonalności jest wykonywana częściej niż w przypadku modelu kaskadowego;

Wykorzystywane w fazie uzgadniania wymagań prototypy służą do wykrystalizowania i ostatecznego ustalenia wymagań klienta. Umożliwia adaptowanie się do zmian
w wymaganiach i korygowanie popełnionych błędów.
Mniejsze koszty za korekcję błędów, ale dochodzi koszt tworzenia prototypu (+wysiłek)

• Przyrostowy

Najpierw następuje określenie wymagań (wydzielenie najważniejszych dla klienta funkcji od tych mniej ważnych), po czym całość systemu dzielona jest na kolejne przyrosty, każdorazowo tworzące dające się testować, rozrastające się wersje systemu.

Podobny do prototypowania, (odmiana ewolucyjnego); klient dostaje pewien produkt (którego funkcjonalność w danej chwili go zadowala), może się uczyć obsługi systemu, wyszukiwać błędy walidacji (np. inne formatki), które można poprawić w następnym „przyroście”, podobnie z błędami kodu (weryfikacja).

Zalety: mniejsze przerwy w kontaktach z klientem, możliwość wykorzystania przez klienta fragmentów systemu, wstępne przyrosty pełnią rolę prototypu, elastyczne reagowanie na opóźnienia (opóźnienie etapu nie musi wpływać na termin oddania projektu).
Wadą tego modelu jest pewien dodatkowy koszt związany niezależną realizacją fragmentów systemu. Z reguły nie jest możliwe proste wycięcie podzbioru funkcji w pełni niezależnych od pozostałych.

• Spiralny

Najtrudniejszy, tylko wtedy kiedy dysponuje się doświadczony zespół programistów. W modelu tym bierze się pod uwagę analizę ryzyka. Pozwala na częste inspekcje i wprowadzanie poprawek. Za każdą iteracją następuje ocena wytworzonego rozwiązania (walidacja+weryfikacja), klient ściśle współpracuje przy projekcie. W pierwszej fazie określane są wymagania klienta (tworzenie specyfikacji), zaś w 4tej następuje walidacja, ocena wytworzonego rozwiązania. Weryfikacja także jest wykonywana cyklicznie.

Walidacja i weryfikacja są czynnościami, które powinno się przeprowadzać jak najczęściej (najlepiej we wszystkich fazach wytwarzania oprogramowania), dlatego model spiralny wydaje się być pod tym względem najlepszy spośród wcześniej wymienionych. Model ten dobrze opisuje też pracę firmy wytwarzającej kolejne rynkowe wersje oprogramowania - w tym wypadku faza walidacji odpowiada eksploatacji oprogramowania przez jego użytkowników.

• Model V

Model tworzenia oprogramowania, gdzie fazy: projektowanie i weryfikacja, nie następują po sobie,
ale są wykonywane równolegle.

Polega na wytwarzaniu równolegle oprogramowania i prowadzenia testów. Poszczególne elementy systemu są badane od razu po wytworzeniu; system dzielony jest na podsystemy, zaś te na zadania. Najpierw testujemy zadania (metody), potem podsystemy a na końcu cały system. Udoskonalenie modelu kaskadowego - fazy wykonywane są sekwencyjnie; każda faza zostaje zakończona po pozytywnej ocenie.

Testy jednostkowe dotyczą podstawowych jednostek programu (klasy, metody, podprogramy) - celem testowania jest sprawdzenie zgodności działania wszystkich opracowanych jednostek z ich specyfikacją oraz wykrycie i usunięcie jak największej liczby błędów. (Na tym poziomie jest najwięcej błędów) - weryfikacja.

Testy integracyjne - jednostki programu łączy się w coraz większe komponenty i sprawdza się zgodność ich działania ze specyfikacją (weryfikacja).

Testy akceptacyjne - sprawdzenie zgodności działania z wymaganiami i potrzebami użytkownika (walidacja).

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

slajd 26 z pierwszego pdf (schemat blokowy problem i koncepcja rozwiązania) - to i inne metodyki, np. Lehmana – i tu w zależności od klasy (E, P czy S) przeanalizować odpowiednią metodyke () ze względu na walidację i weryfikację (bardziej ze względu na klienta)

Na początku należy zebrać wymagania dotyczące systemu, który ma być zbudowany (wywiad, rozmowa z klientem). Metody pozyskiwania wymagań: prototypy (dobre bo klient może wyrazić co chce, albo czego nie chce, co mu się podoba, z czym ma problem), wywiad (słabe, bo język naturalny jest problematyczny, część wymagań może być przedstawiona innymi słowami sprawiając wrażenie że to różne funkcjonalności, lub trudno zauważyć że wymagania są rozbieżne; dużo użytkowników = różne opinie, ciężko wyrobić kompromis), burza mózgów (specjalistów - też źle, bo specjalista nie jest użytkownikiem, ma większą wiedzę)… symulowanie punktów widzenia (projektant jako użytkownik), spotkania grupowe, obserwacja…

Analiza - np. diagramy przypadków użycia (są ok., nie idealne, należy je dopełnić językiem naturalnym, scenariusze przypadków użycia)

Proces zbierania i opracowywania wymagań ma najczęściej charakter cykliczny.

Zbiór wymagań: ustalenie co budowany system ma robić; jaki jest zakres funkcjonalności zamawianego systemu; w dużym uproszczeniu: zaproponowanie jego struktury. Wymagania powinny być zrozumiałe dla obu stron.

Specyfikowanie wymagań jest to czynność polegająca na zapisywaniu informacji zebranych w czasie analizy w dokumencie definiującym zbiór wymagań; proces, którego celem jest określenie jakich usług wymaga się od systemu, jakim ograniczeniom podlega tworzenie i działanie oprogramowania; Główna część kontraktu klient-producent.

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.

Pomocnymi technikami w odkrywaniu wymagań są:

poznanie całości otoczenia systemu (poprzez obserwacje, zaznajomienie z odpowiednimi dokumentami, itp)

wykorzystanie istniejących systemów realizujących podobne funkcje

obserwacje i wywiady z przyszłymi użytkownikami systemu

stosowanie scenariuszy wykorzystania systemu (przypadków użycia, uses cases)

modelowanie systemu

tworzenie prototypów systemu

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

Wymagania funkcjonalne – dotyczą tego co ma realizować system, jakie ma spełniać funkcje, jakich dostarczać usług oraz jak zachowywać się w określonych sytuacjach; oczekiwania użytkownika - operacje wykonywane przez system. 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, wydajności, bezpieczeństwa;
ograniczenia, przy zachowaniu których system powinien realizować swoje funkcje.
Mogą dotyczyć nie tylko końcowego produktu (oprogramowania), ale także samego procesu wytwarzania oprogramowania.

Można zweryfikować wymagania funkcjonalne - zero-jedynkowa, coś jest albo tego nie ma,
np. testy jednostkowe pozwalają sprawdzić, czy dana funkcjonalność jest zrealizowana czy nie.

W przypadku wymagań niefunkcjonalnych można zweryfikować część - jeśli są dobrze opisane w specyfikacji i istnieje możliwość sprawdzenia czy zrealizowany system rzeczywiście je spełnia.

Wymagania stwierdzające, że system powinien być łatwy w obsłudze, niezawodny, wydajny nie mogą być obiektywnie zweryfikowane.

Kryteria stosowane do oceny rozwiązań mogą być różne w zależności od kontekstu danego przedsięwzięcia. Np. firma, zamawiając produkt, oprócz wymaganiami funkcjonalnymi, może kierować się kryteriami tj.: koszt, czas realizacji, niezawodność, stopień możliwości ponownego wykorzystania fragmentów systemu, przenośność na inne platformy, wydajność, i również te elementy mogą być istotne dla późniejszej oceny wykonalności projektu.

Kontrola wykonalności powinna być prowadzona we wszystkich fazach projektu. Na efekt końcowy mają wpływ 3 czynniki:

• budżet – analiza kosztów; koszt wytworzenia oprogramowania, utrzymania i konserwacji; jeżeli przekroczono budżet to źle;

• termin – określenie czasu realizacji wytworzenia oprogramowania; jeżeli nie dotrzymano harmonogramu, realizacja zadań nie przebiega zgodnie z planem to źle;

• zakres – jakie funkcjonalności ma posiadać produkt końcowy; należy sprawdzić czy zrealizowano wymagania funkcjonalne i niefunkcjonalne;
  można przedstawić użytkownikowi prototyp (walidacja); zmiana punktu widzenia (pracownik udaje końcowego użytkownika, wykonując czynności zgodnie z pewnym scenariuszem, sprawdza czy system funkcjonuje prawidłowo); można przeprowadzić odpowiednie testy (testy jednostkowe - weryfikacja podstawowych komponentów programu).

Jako ocenę wykonalności projektu można również przyjąć kryteria o charakterze: ekonomicznym, moralnym, estetycznym, socjalno-politycznym, religijnym.

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

Oprogramowanie rozwojowe realizowane jest na podstawie modelu ewolucyjnego lub spiralnego.
Rozwój: przyjmuje się, że systemy operacyjne - 10 lat, aplikacje użytkowe - 7.

Przyrosty (m. ewolucyjny) 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.

W przypadku modelu spiralnego, po stworzeniu pierwszej wersji oprogramowania i oddaniu jej do użytku użytkownikom, ostatnia faza modelu spiralnego - faza walidacji odpowiada eksploatacji oprogramowania przez jego użytkowników. Rozpoczynając kolejny cykl rozwijania wytworzonego rozwiązania, również brane są pod uwagę opinie i komentarze użytkowników na temat tego co powinno zostać poprawione lub zmienione.

+ jak należy projektować by nie ponosić kosztów na rozwój. Złoty trójkąt (zakres, czas, koszt).

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

Metodyki zarządzania procesem wytwórczym = cykl życia oprogramowania.

Klasyfikacja systemów Lehmana

• programy typu E, oparte na rzeczywistości; są osadzone w środowisku i nieustannie z nim oddziałują, co powoduje potrzebę ciągłych zmian;

• programy typu P, rozwiązujące problemy; reagują na zmiany w środowisku i w akceptowalny sposób dostarczają środków do interakcji z nim (oparte o model matematyczne, są bliskie rzeczywistości);

• programy typu S, które są oparte w całości na formalnej specyfikacji i dlatego nie podlegają ewolucji (zmiana specyfikacj nie jest ewolucją).

E, P - typy ewolucyjne, co powinno być wzięte pod uwagę w trakcie procesu wytwarzania.
Mogą być pielęgnowane (nawet powinny) -> model ewolucyjny lub spiralny (prototypowanie jest dobre dla bardziej nowatorskich zastosowań).

S - model kaskadowy. Powinien być używany jedynie wtedy gdy wymagania są wyraźno zdefiniowane, jasne i zrozumiałe (dobra specyfikacja).

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 pozwala na znalezienie błędów natomiast nie pozwala na wykazanie poprawności oprogramowania

Warto przeprowadzać testy na każdym etapie tworzenia oprogramowania; należy testować jak najwcześniej, ponieważ podstawowymi źródłami błędów są specyfikacja i projekt.

Wydziela się 2 nurty, w zależności od punktu widzenia testera:

• testy funkcjonalne – testy czarnej skrzynki; wiemy co można wprowadzić na wejście i co powinniśmy wtedy uzyskać na wyjściu, porównujemy uzyskany wynik z oczekiwanym, nie wnikamy w ogóle w techniczne działania programu.

• testy strukturalne – testy białej skrzynki; mamy wgląd do kodu źródłowego, można obserwować jak zachowują się różne części aplikacji, jakie moduły oraz biblioteki są wykorzystywane w trakcie testu.

Testowanie można też podzielić na inne kategorie:

Testy ze względu na sposób przeprowadzania:

• wykonywane manualnie: ręcznie przez testera, który przechodzi przez interfejs użytkownika zgodnie z określoną sekwencją kroków;

• wykonywane automatycznie: ich wykonane nie wymaga udziału testera.

Testy ze względu na zakres aplikacji:

• jednostkowe – testują oprogramowanie na najniższym poziomie - na poziomie działania pojedynczych funkcji (metod);

• integracyjne – sprawdzają jak współpracują ze sobą różne komponenty oprogramowania;

• systemowe – sprawdzanie działania całej aplikacji; szybkości działania, bezpieczeństwa, niezawodności, kompatybilność z innym oprogramowaniem i sprzętem.

Testy ze względu na przeznaczenie:

• akceptacyjne – sprawdzają na ile oprogramowanie działa zgodnie z wymaganiami i potrzebami klienta - walidacja oprogramowania – przeprowadza się ją na gotowym programie. Walidacja systemu jest możliwe, jeśli istnieje działająca wersja oprogramowania: (prototyp; kolejne wydanie w ramach przyrostowego tworzenia oprogramowania; ostateczny program);

• funkcjonalne – sprawdzają działanie oprogramowania zgodnie ze specyfikacją - weryfikacja oprogramowania – ma zastosowanie do wszystkich produktów powstających w obrębie systemu: dokumenty projektowe, kod, projekty testów;

• regresyjne – sprawdzenie czy dodana funkcjonalność, poprawione błędy nie naruszają niespodziewanie innej funkcjonalności.

Testy wydajnościowe i obciążeniowe:

• instalacyjne/konfiguracji – sprawdzają jak oprogramowanie zachowuje się na różnych platformach sprzętowych; systemach operacyjnych, przy różnym dodatkowym oprogramowaniu.

• 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;

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

Budżet – środki finansowe, które możemy wykorzystać do realizacji projektu (materiał, wyposażenie, sprzęt i ludzie oraz skojarzone z nimi koszty).

Ryzyko – możliwość wystąpienia niebezpieczeństwa, sytuacja przypadkowa, w której są określone prawdopodobieństwa wystąpienia przypadków pozytywnych i negatywnych. Występuje zawsze.
Jeśli w początkowej fazie projektu uda się je określić, to później można ich uniknąć lub zmniejszyć ryzyko wystąpienia.

Złoty trójkąt oprogramowania - 3 czynniki wpływające na końcową jakość projektu: zakres (jak skomplikowane), budżet (ile pieniędzy), czas (ile czasu na realizacje). Z tym wszystkim związane jest pewne ryzyko. Czas oczywiście ma wpływ, 90% błędów powstaje w ostatnich dniach przed deadline, ponieważ kod pisany jest pośpiesznie, i nie ma czasu na jego testowanie.

Za skomplikowany projekt + mało czasu = źle, 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. ….

Im później zostanie wykryty błąd, tym większy jest koszt jego usunięcia.

Wybrany model życia oprogramowania ma wpływ na to jak zmiany wpływają na projekt, najmniej elastyczny model kaskadowy - zmiana wymagań/znalezienie błędów na późniejszym etapie wiąże się z większymi kosztami i wydłużaniem się czasu realizacji (może wymagać rozpoczęcia pracy od początku, projekt może nie zostać ukończony). Model kaskadowy powinien być używany jedynie wtedy, gdy wymagania są jasne i zrozumiałe.

Model ewolucyjny jest bardziej elastyczny na zmiany, mniejsze koszty zmian.
Przyrostowy - elastyczne reagowanie na opóźnienia (opóźnienie etapu nie musi wpływać na termin oddania projektu). 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.
Spiralny też bardziej elastyczny na zmiany.

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ą (zmniejszenie funkcjonalności). Tylko nieco ponad 1/4 projektów powstaje w założonym czasie, budżecie i funkcjonalności.

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

• prace powinny zostać dokładnie rozdzielone pomiędzy członków zespołu, zgodnie z ich wiedzą
  i umiejętnościami;

• zespół ma mieć dostęp do harmonogramu (mogą sobie sprawdzić kto co kiedy robi, na jakim etapie znajduje się projekt, wszystko jawne i dokładnie sprecyzowane);

• zapewnienie komunikacji w zespole: komunikatywny kierownik projektu (tak, by umiał się porozumieć zarówno z podwładnymi jak i klientami);

• ważny jest kierownik - pilnuje terminów, odpowiada za realizację prac, rozwiązuje poważniejsze problemy wewnątrz zespołu, motywuje zespół (kiedy spada motywacja zespołu projekt może być zagrożony). Kierownik wykwalifikowany, doświadczony, obeznany w temacie i metodyce realizowanego projektu; posiada odpowiednie umiejętności techniczne (platformy, języki programowania).
  Cechy osobowości, np.: kreatywność, umiejętność rozwiązywania problemów, rzetelność, uczciwość, umiejętność dostosowania się, nastawiony na współpracę, zrozumienie innych.

• Zespół powinien respektować kierownika.

9. Sposoby zachowania deklarowanego czasu, budżetu i zakresu wymagań tworzonego produktu programistycznego.

Na efekt końcowy jakość wytworzonego produktu ma złoty trójkąt oprogramowania:

• zakres funkcjonalności (jak bardzo złożony projekt, jaki cel końcowy ma być osiągnięty);

• czas realizacji (terminy, ile czasu poświęcono na realizację projektu);

• koszt realizacji (budżet, jakie są koszty realizacji).

1. Harmonogramowanie (przestawienie dokładnego planu realizacji poszczególnych zadań, praca systematyczna i uporządkowana, prawidłowa organizacja pracy projektantów);
2. Systematyczna kontrola; 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 można przewidzieć);
3. Właściwa dokumentacja (pozwala na dopilnowanie zakresu prac);
4. Wypracowanie standardów; korzystanie z gotowej części kodu;
5. Automatyzacja zadań (ANT, testy automatyczne…);
6. Określenie priorytetów (jeśli zabraknie czasu - wiadomo co zostawić).

10. Uwarunkowania i sposoby zapewnienia jakości oprogramowania.

Rozumiejąc co to jest jakość oprogramowania napisać jakie są sposoby jej osiągnięcia ( stworzyć dobry zespół ...., w tym tez 7 zasad sukcesu Stephen Covey i model 4+1), solid, to też chyba może tu być.

• Rozwiązywać problem zarówno z perspektywy klienta jak i specjalistów:
  Perspektywy 4+1 (modelowanie eksperckie : logiki, implementacji, procesowa, wdrożenia, modelowanie w zakresie weryfikacji wymagań (dokumentacja); z punktu widzenia klienta: przypadki użycia). Dbałość o to, żeby system odpowiadał potrzebom klienta;

• Częsty kontakt z klientem, walidacja wymagań i weryfikacja rozwiązań;

• Poprawne zbieranie wymagań i definiowanie zakresu projektu – głównie pod kątem weryfikacji czy zdefiniowane wymagania będą możliwe do weryfikacji, tj. przetestowania;

• Właściwe zarządzanie zespołem (nadzór), dobra komunikacja wewnątrz zespołu, członkowie potrafią się porozumieć i współpracować (dążą do synergii - współdziałanie różnych czynników, którego efekt jest większy niż suma poszczególnych oddzielnych działań);

• Doświadczenie - doświadczone zespoły wiedzą co jest ryzykowne (co może mieć wpływ na realizacje projektu), potrafią określać priorytety (jak zabraknie czasu, to nie wykona się mniej ważnych funkcji), zdolność do dokształcania się;

• Dużo testowania żeby znaleźć jak najwięcej istniejących błędów. (odpowiednia dokumentacja)
  Błędy mają wpływ na jakość (błędy wpływają na zakres, budżet, czas, to wszystko zaś na ostateczny wygląd oprogramowania), rejestracja defektów i ich sukcesywne rozwiązywanie;

• Dobra dokumentacja procesu projektowania i oprogramowania (właściwie określone i opisane wymagania niefunkcjonalne mogą być zweryfikowane -> mniej problemów; podręcznik użytkownika + );

• Wybór właściwego cyklu życia (np. model kaskadowy wyłącznie wtedy kiedy wymagania są dokładnie znane);

• Jeśli przedsiębiorstwo przestrzega odpowiednie procedury jest ok. (zewnętrzne lub własne, standardy IEEE lub ACM). ISO 9000 oznacza, że firma działa w oparciu o procedury (buduje zbiór procedur świadczących o najlepszej jakości produktu czy usług), ma system administracji, zarządzania pracownikami, obiegu dokumentów, dokładne zasady.

Elementem uzyskiwania wysokiej jakości oprogramowania jest prawidłowa dokumentacja procesu wytwarzania i samego oprogramowania.

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

Prowadzenie dokumentacji jest ważne. Dokumentację powinno się (zgodnie z normą ISO9000) prowadzić na wszystkich etapach wytwarzania. Jest tworzona zgodnie z pewnymi standardami.
Zaletą dobrej dokumentacji jest posiadanie szczegółowego spisu treści, słownika pojęć i bogatego indeksu.

W pierwszej fazie, na dokumentację mogą się składać takie rzeczy jak:
harmonogram (rozkład prac), analiza ryzyka (SWOT), kosztorys, raporty, dodatkowe informacje w innej formie - obecnie wykorzystuje się do tego : opis w języku naturalnym, notacje matematyczne czy graficzne (dopełniają się: diagramy UML, algorytmy w schemacie blokowym …) - modele systemu, kod, schematy.

Pozyskiwanie wymagań - dobra jest notacja graficzna diagram UML przypadków użycia + przypadki użycia (scenariusz użycia systemu spisany w formie tabeli); przejrzyste, proste, zrozumiałe dla klienta; różnego rodzaju wykaz funkcjonalności wymagań oczekiwanych przez klienta + specyfikacje, które muszą zostać spełnione (ISO).

Projektowanie - też diagramy (stanów, aktywności), ułatwiają komunikację między inżynierami.

Implementacji - diagramy klas i pseudokod (między programistami), kod źródłowy,
gotowy projekt powinien mieć dokumentacje API.

Testowania - zapis testów jakim został poddany system.

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

to są chyba fazy powstawania produktu informatycznego np., co się dzieje w każdej fazie (dokumentacja prz. użycia, np. faza implementacji – związana z testami, że idą równolegle).
bardziej o tym z czym one są powiązane, czyli np., początkowa faza, to się wiąże z tym by określić przypadki użycia, implementacja związana z testami...coś takiego

??

Definiowanie - proces stawiania wymagań systemowi na podstawie informacji o istniejących systemach; rozmowa z potencjalnymi użytkownikami; podczas definiowania wymagań potrzebna jest specjalistyczna wiedza biznesowa z dziedziny, którą będzie wspierał system. Potrzebna jest również intuicja i doświadczenie informatyczne, podpowiadające, że sprawy traktowane przez specjalistę biznesowego jako oczywiste mogą mieć kluczowe znaczenie dla przyszłego systemu.

Formalizacja - sprawdzenie realizmu, spójności i kompletności wymagań, następuje wykrywanie błędów; określenie w formie pisemnej zakresu zadań i odpowiedzialności poszczególnych elementów oraz organizacji jako całości. Formalna specyfikacja wymagań następuje zazwyczaj po stworzeniu wstępnego projektu systemu.

Zalety:

sprecyzowanie określeń i usunięcie sprzeczności w wymaganiach,

zagwarantowanie poprawności oprogramowania tworzonego na ich podstawie (ważne dla systemów o zakładanych wysokich: niezawodności i bezpieczeństwie).

Wady:

trudność uzyskania (zwłaszcza dla dużych i złożonych systemów oraz wszelkich systemów gdzie wymagania są słabo określone lub mogą się zmieniać),

znaczny czas konieczny do wypracowania (wada istotna w czasach silnej konkurencji),

nieprzydatność dla pewnych elementów systemów (np. graficzne interfejsy użytkownika).

Specyfikacja – jest to zbiór wymagań (opisów funkcji), czyli zakres funkcjonalności zamawianego systemu.

Istotne jest używanie przy określaniu wymagań konkretnych, precyzyjnych, jednoznacznych i dających się następnie zweryfikować stwierdzeń:

dla szybkości działania - liczba transakcji na sekundę,

dla łatwości użycia - czas konieczny na przeszkolenie obsługi.

Wymagania funkcjonalne - funkcje systemu widziane od strony użytkownika, np. wprowadzenie nowej faktury, wygenerowanie raportu miesięcznego.

oczekiwania klienta/użytkownika

funkcje (czynności, operacje) wykonywane przez system.

Wymagania niefunkcjonalne - wszystkie inne wymagania, głównie związane z bezpieczeństwem, wydajnością, awaryjnością, np: system ma umożliwiać wprowadzenie co najmniej 20 faktur w ciągu godziny, średni czas pomiędzy awariami (ang. MTBF) powinien wynosić 200000h; ograniczenia, przy zachowaniu których system powinien realizować swoje funkcje.

13. Wady i zalety stosowanych obecnie podejść w procesie tworzenia specyfikacji wymagań do realizowanego przedsięwzięcia informatycznego.

Rozumiejąc co to jest specyfikacja wymagań opisać jakie problemy możemy napotkać (np. ma być zawlekanie innych ludzi (ekspertów) – magą mieć inne spójżenie, włączenie klienta) no i jakie są wady stosowanych podejść.

Zbiór wymagań: ustalenie co budowany system ma robić; jaki jest zakres funkcjonalności zamawianego systemu. W dużym uproszczeniu: zaproponowanie jego struktury. Główna część kontraktu klient-producent. Wymagania powinny być zrozumiałe dla obu stron.

Język naturalny jest często stosowanym sposobem opisu wymagań. Stosowanie języka naturalnego ma jednak następujące wady:

• niejednoznaczność języka naturalnego, która utrudnia precyzyjny zapis wymagań: może to prowadzić do różnej interpretacji tego samego tekstu przez różne osoby.

• elastyczność języka naturalnego, która pozwala te same treści wyrazić na różne sposoby. Utrudnia to wykrycie powiązanych wymagań. Może też prowadzić do przeoczenia sprzeczności wymagań sformułowanych w różny sposób lecz dotyczących tych samych funkcji.

Powyższych wad pozbawione są notacje formalne (matematyczne), które gwarantują matematyczną poprawność, jednak są w zdecydowanej większości przypadków niezrozumiałe dla klienta. Mogą one więc być jedynie uzupełnieniem zapisu słownego. Notacje formalne są dobrym rozwiązaniem do projektowania systemów krytycznych.

Dochodzą też notacje graficzne tj. diagramy UML, które również powinny być rozwinięte o zapis słowny (np. opis przypadków użycia - scenariusz w postaci tabeli).

Diagramy graficzne ułatwiają szybkie przekazywanie podstawowych informacji, nie pozwalają jednak na ukazanie wszystkich szczegółów. (proste przejrzyste, ale nie można zbyt wielu szczegółów, trzeba opisać dodatkowo tekstem), zbyt dużo elementów - tracimy przejrzystość. Niektóre funkcje na diagramie przypadków można przedstawić w różne sposoby.

Nadmierne nagromadzenie szczegółów na diagramie graficznym może zresztą skutecznie zniweczyć jego czytelność. W związku z tym notacje graficzne uzupełniane są o dodatkowe informacje, tak zwane specyfikacje.

14. Mechanizmy modelowania zachowań i struktury realizowanej aplikacji informatycznej.

UML jest notacją graficzną, określa sposób zapisu modeli. Język pozwalający tworzyć modele systemów; pozwala obrazować, specyfikować, tworzyć i dokumentować elementy systemu.

UML jest jedynie językiem modelowania używanym w procesie analizy i projektowania systemów komputerowych. Ułatwia wymianę informacji pomiędzy przyszłymi użytkownikami systemu, menadżerami, analitykami, projektantami, programistami, testerami. Ułatwia wykorzystanie zalet programowania obiektowego.

Wyróżniamy 2 rodzaje diagramów UML:

• behawioralne– opisują zachowanie, działanie, sposób interakcji między obiektami – dynamiczne części systemu, np. stanów, przypadków użycia.
  

• strukturalne– opisują sposób konstrukcji struktur obiektowych – statyczne części systemu,
  np. klas, obiektów, pakietów.

15. Walidacja i zarządzanie wymaganiami w odniesieniu do zwykłych aplikacji użytkowych
i systemów krytycznych.

Walidacja prowadzona jest w docelowym środowisku programu i dotyczy jego całościowej oceny
pod kątem spełnienia oczekiwań użytkownika. Stosuje się do elementów wykonywalnych systemu.
W procesie walidacji wykorzystywany jest utworzony system oraz zaprojektowane procedury testowe. Walidacja przeprowadza się na podstawie gotowego programu.

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)

Sposoby walidacji:

przegląd wymagań pod kątem zgodności z oczekiwaniami klienta a także zupełności, niesprzeczności, sprawdzalności realizacji itp.,

tworzenie prototypów na podstawie wymagań,

tworzenie planów testów na podstawie wymagań.

Zarządzanie wymaganiami:

Sposoby zapisu wymagań systemowych:

w języku naturalnym, lecz przy użyciu formalizmów i konwencji – np. z zastosowaniem odpowiednio zaprojektowanych tabel lub formularzy,

w postaci elementów projektu systemu – np. zestawu interfejsów systemowych,

za pomocą notacji graficznej – np. z zastosowaniem diagramów przypadków użycia lub przebiegu,

za pomocą notacji matematycznej – bardzo precyzyjny opis wymagań, w wielu wypadkach trudny do uzyskania i często niezrozumiały dla klienta (dlatego rzadko stosowany w praktyce).

Dobrą praktyką w przypadku systemów krytycznych jest używanie metod formalnych, które posiadają notację, której składnia i semantyka jest formalnie zdefiniowana. Dzięki temu modele, które powstają są dużo bardziej jednoznaczne.

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

Automatyzacja testowania jest z pewnością pozytywną cechą testowania. Dzięki automatyzacji testowania uzyskujemy szereg pozytywnych wartości, które wpływają na całokształt tworzonego projektu.

Zalety:

• przyśpiesza proces testowania;

• możliwe do ponownego wykonania w przyszłości, możliwość używania gotowych skryptów (kodu testującego);

• szybka i wydajna weryfikacja poprawek błędów- test, który wykrył błąd, można w kilka sekund wykonać ponownie na poprawionym kodzie, mając pewność, że te same dane zostaną podane na wejściu i ocenione,;

• większa precyzja – narzędziem można zmierzyć dokładnie czas, porównywać obiekty graficzne, także bitmapy, rejestrować pojawienie się obiektów niewidzialnych (np. obiekt graficzny ukryty pod innym obiektem graficznym na monitorze;

• równomierna jakość testowania – narzędzie każdorazowo wykonuje testy identyczne
  w przeciwieństwie do testerów, których staranność może być zróżnicowana;

• możliwość generowania raportów z testów;

• nie wymaga udziału testera (można testować poza godzinami pracy).

Wady:

• jest to trudne, wymagane jest specjalistyczne oprogramowania na uruchomienie wcześniej napisanego przez testera skryptu;

• duża liczba przypadków testowych - duża liczba zgłoszeń do przeanalizowania i zbadania;

• dobór odpowiednich narzędzi – dla środowiska (SO), kompatybilnych ze wszystkimi technologiami projektu;

• dobór kadry potrafiącej napisać odpowiednie skrypty testowe w niektórych przypadkach,

testy automatyczne nie mają wyobraźni – nie jest w stanie stwierdzić, czy wykonywany test faktycznie zawiera błąd;

• często jest droższa.

Jeżeli wynajdzie błędy to znaczy że efektywne. Odpowiednie oprogramowanie (framework np. JUnit) pomoże w zachowaniu porządku i ułatwi raportowanie nt. przeprowadzonych testów i ich wyników.

Np. w przypadku testów jednostkowych, efektywne testy (dobrze zaprojektowane) dotyczą przypadków granicznych.

17. Asercje i weryfikacja uzyskanych wyników z przyjętymi założeniami perspektywy logicznej realizowanej aplikacji.

Asercja jest wyrażeniem sprawdzającym pewien warunek logiczny (stan zmiennych). Jeżeli warunek nie jest spełniony następuje przerwanie pracy programu. Z asercji powinniśmy korzystać zawsze wtedy, kiedy chcemy mieć pewność, że stan zmiennych programu jest zgodny z naszymi oczekiwaniami, a w szczególności:

na początku procedury w celu sprawdzania poprawności parametrów wejściowych

na końcu procedury, aby sprawdzić poprawność generowanego wyniku

na początku pętli w celu sprawdzenia niezmienników pętli

na końcu pętli, aby sprawdzić wynik jej działania

przed użyciem zmiennej, aby stwierdzić czy została ona zainicjowana

Asercje - testy jednostkowe, testy czarnej skrzynki (znamy oczekiwaną wartość na wyjściu, porównujemy ją z faktyczną) - najlepiej sprawdzać przypadki graniczne.

Asercje nie pokazują jak współpracują komponenty (czarna skrzynka).

Perspektywa logiki - dotyczy tego jak będzie wyglądać przekazywanie i przetwarzanie danych
(przebieg współpracy między częściami systemu).

Weryfikacja (czy tworzymy system we właściwy sposób) – jest procesem sprawdzającym, czy program jest zgodny ze specyfikacją. Skupia się na statycznej reprezentacji elementów systemu, celem jest identyfikacja możliwych problemów. Ma zastosowanie do wszystkich produktów (artefaktów) powstających w obrębie systemu jak: dokumenty projektowe, kod, projekty testów. Artefaktem na podstawie którego dokonywana jest weryfikacja są dokumenty projektowe, kod programu.

18. Automatyzacja zadań inżynierii oprogramowania.

To najczęściej utworzenie skryptu, który automatyzuje zadania, które wytwórcy oprogramowania wykonują, w ramach swojej pracy, w sposób powtarzalny, a których celem jest zbudowanie oprogramowania, np.:

• kompilacja kodu źródłowego do postaci wykonywalnej (binarnej),

• uruchamianie testów (automatyzacja testów jednostkowych),

• wdrażanie w środowisku docelowym (testowym, akceptacyjnym, produkcyjnym),

• kasowanie, kopiowanie zmiana nazwy plików/archiwum

• tworzenie dokumentacji i informacji nt. wydania.

Narzędziem wykorzystywanym do tego może być Apache Ant (dla Javy) – używa plików skryptowych w formacie XML. Nie ma potrzeby pisania skryptów do każdej aplikacji (można raz napisać a potem uzywać), co daje możliwość uwolnienia się od zintegrowanych środowisk programisycznych IDE.

Przykład: odtwarzanie działań użytkownika – automatyzacja (symulowanie) wykorzystania graficznego interfejsu użytkownika:

• przechwycenie i zapamiętywanie działań operatora (kliknięcia przycisków, ruch myszy, wypełnianie pól formularza).

• pierwszy przebieg testów (obsługiwany interaktywnie przez użytkownika);

• później można odtwarzać wszystkie zapamiętane działania (i porównywać zgodność wyników).

Przykład: testowanie wydajności; analiza dziennika systemu;użycie procesora, zajętości pamięci.

Automatyzacja generowania kodu (np. na podstawie diagramu klas UML tworzony może być szkielet poszczególnych klas - skraca czas pisania kodu).

Automatyzacja tworzenia dokumentacji API - np. JavaDoc, wpisywanie komentarzy na poziomie kodu, generuje dokument HTML.

Automatyzacja testów (ANT, skrypty) - zwykle przeprowadzanie testów jednostkowych jest zautomatyzowane, co przyśpiesza cały proces (możliwe też do wykonania w przyszłości). Automatyzacja testów w schemacie czarnej skrzynki jest trudna, potrzebne do tego jest specjalistyczne oprogramowanie pozwalające na uruchomienie wcześniej napisanego lub nagranego przez testera skryptu.

19. Czynniki wpływające na wzrost złożoności wdrażanego obecnie oprogramowania.

„Prawa” Lehmana (dotyczą programów typu E - dużych, wielokrotnie modyfikowanych systemów, które ewoluują przez dłuższy okres czasu)

1. Prawo nieustannej zmiany
wszystko dąży do nieustannej zmiany, musi być adaptowane do zmian (uwarunkowania technologiczne, zmiany użytkowników, poprawianie błędów); Rozwój programu - liczba powiązań i interakcji pomiędzy różnymi modułami w oprogramowaniu zwiększa się, co utrudnia zrozumienie go i dalsze modyfikacje,

2. Prawo samoregulacji
rozkład normalny (wykres Gauss’a - wartość cechy rośnie aż do osiągnięcia stanu nasycenia, potem spada np. więcej osób w projekcie - więcej problemów, czas trwania;
dłuższy czas trwania/pielęgnacji - większa złożoność);

3. Prawo wzrostu złożoności
Prawo Moore’a - rozwój sprzętu - wzrasta złożoność;
wraz z ewolucją oprogramowania, jego struktura staje się coraz bardziej złożona: Wprowadzanie zmian do oprogramowania 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ę.

4. Prawo organizacyjnej stabilności
firma powinna być stabilnie zarządzana (aby lepsza była praca zespołowa etc.):
tempo rozwoju oprogramowania jest stałe.

5. Prawo przyzwyczajeń
klient ma swoje przyzwyczajenia, na które trzeba uważać - stopniowe, nierewolucyjne zmiany.

6. Prawo ciągłego wzrostu
wzrost funkcjonalności, musi rosnąć, by satysfakcja odbiorców pozostała na tym samym poziomie;

7. Prawo pogarszania jakości
jakość oprogramowania spada, o ile nie jest ono dostosowywane do zmian zachodzących w swoim środowisku operacyjnym - Lehman wskazuje, że jedynie rygorystyczna pielęgnacja jest w stanie zapobiec spadkowi jakości oprogramowania w miarę upływu czasu.
Brak pielęgnacji, refaktoryzacji kodu – brak upraszczania struktury i lepszego wkomponowania wprowadzanych zmian w istniejące oprogramowanie. Pielęgnacja i upraszczanie struktury wymagają dodatkowych nakładów.

8. Prawo przyrostowego rozwoju
podsumowanie punktów wcześniejszych - ewolucja oprogramowania jest złożonym, wielopoziomowym i uwzględniającym wiele punktów widzenia systemem z informacją zwrotną.

----

Gr. 1
1. posługując się praktycznymi odwołaniami wyjaśnij jakie procesy wytwarzania oprogramownia mają ścisły wpływ na zarządzanie przedsięwzięcem i jego końcowy rezultat.

Albo zarządzanie zespołem alboooo trójkąt (ale chyba nie skoro tego dotyczy pyt 2).

2. wyjaśnij w jaki sposób możemy zachować deklarowany czas, budżet…

Gdzieś tam u góry.

3. wyjaśnij od jakiś atrybutów zależy jakość tworzonego op. I jaki sposób są one ze sobą związane.

… było

Gr.2

scharakteryzuj wszystkie znane ci sytuacje, w których główne fazy procesu wytwórczego oprogramowania na znajdują zastosowania

??

Ewolucja i pielęgnacja istniejącego oprogramowania?

Przyrosty?

Konserwacja -- modyfikacje producenta, usunięcie błędów, zmiany i rozszerzenie.

Może jakaś refaktoryzacja ale o tym nie było na wykładzie.

2.wyjaśnij czym jest udany test i jakie są możliwe podejścia do procesu twstowania oprogramowania (nie dotyczy do podziału testów).

Znajduje błędy, wiadomo gdzie, walidacja lub weryfikacja.

wyjaśnij w jaki sposób koszty związane ze zmianami w trakcie realizacji projektu programistycznego wpływają na jego budżet.

Pyt.1

Gr.3

posługując się praktycznymi odwołaniami wyjaśnij w jaki sposób zmiana wymagań funkcjonalnych może wpłynąć na wymagania niefunkcjonalne tworzonego oprogramowania.

Np. nie ma funkcji „drukuj” - nie ma potrzeby wymagania „min. 20str/5min”

Dodanie funkcji „wprowadzanie faktury” - „20f/h”

. nie wiem co jes

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.

wyjaśnij w jaki sposób jakość tworzonego oprogramowania zależy od przyjętej metodyki oraz jak możemy zagwarantować zgodność z wymaganiami (od jakich czynników jest to ściśle zależne?)

Tam gdzie częściej walidacja i weryfikacja lepsze.

wyjaśnij czym różni się podejście w zakresie doboru właściwej metodyki zarządzania oprogramowania zarządzania oprogramowania związanym z projektem rozwojowym i tym związanym z oprogramowaniem, które nie będzie w przyszłości pielęgnowane.

Gdzieś u góry było.

Gr.4

Posługując się przykładami wyjaśnij jakie najważniejsze czynniki decydują o skutecznym zarządzaniu zespołem programistycznym.

UP

Scharakteryzuj wszystkie znane Ci metodyki wytwarzania oprogramowania, a także dla każdej z nich wskaż sposób zapewnienia sukcesu procesu weryfikacji i walidacji produktu programistycznego.

Pyt.1

Wyjaśnij czym się różni ewolucja oprogramowania od procesu klasyfikacji i jaki to ma związek z klasyfikacją typu tworzonego oprogramowania.

typy E, P, S ?
ale jak porównywać proces klasyfikacji i ewolucję WTFFFF.