# Opracowanie - Inżynieria oprogramowania

**nagrania**
https://www.youtube.com/playlist?list=PLqR_CU_UhSIq-T9fl_a6v8e4vt6_3VPQ2

**nagrania wykładów od Aplikacji:**
https://www.youtube.com/playlist?list=PLfY-fIShcxt5SJtAA7icQ5irupgJwji86

wykład 1 - kwiaciu 6.10
wykład 2 - kwiaciu 13.10
wykład 3 - BOBKOWSKA 20.10
wykład 4 - BOBKOWSKA 27.10
wykład 5 - Ola (03.11.2020)
wykład 6 - Ola (10.11.2020)
wykład 7 - kuba 17.11
wykład 8 - Kuba 24.11
wykład 9 - 1.12
wykład 10 - kwiaciu 8.12
wykład 11 - kwiaciu 22.12
wykład 12 - Maciej 5.01
wykład 13 - Maciej 12.01
wykład 14 & 15 - olga 19.01

# Wykład 1 ##

**W 2 pierwszych wykładach gada o czym będzie wykład, rzuca definicjami na prawo i lewo i daje mase anegdotek, ale ogólnie raczej useless info. Dałem najważniesjze informacje, ale ich poziom szczegółów jest tak niski, że raczej potrzebne będzie wiedza z następnych wykładów, żeby miały sens**

**Iżynieria** - działania kreatywne polegające planowaniu i bazujące na znanych schematach, ukierunkowane na cel praktyczny

**oprogramowanie** - jest niematerialne, główny nakład idzie na projektowanie(kopiowanie to znikomy wysiłek), nie zużywa sie(kłóciłbym sie, zmieni się biblioteka która wykorzystujemy i możemy mieć problem), duża złożoność, dowolna struktura, zależność pomiędzy elementami, łatwość zmian.

Błedy popełnione na wstępie mają poważniejsze konsekwencje w przyszłości. Po każdym etapie rośnie 10-krotnie

Jednym z głównych problemów jest porozumienie się z klientem o co mu chodzi. Zdefiniowanie niunsów branżowych itd.

jednym z głównych zajęć programistów jest utrzymanie systemu.

Kryteria porażki to przekroczony budżet, czas, brakujące funkcjonalności lub nie zadowalająca jakość oprogramowania(bugi, glitche, niezawodność, wydajność).


Omawia jak powinna wyglądać "Wizja systemu", nie będe tego tu przepisywał, każdy to robił

# Wykład 2 ##

Inżynieria oprogramowania posiada 5 głównych obszarów działalności:
* Analiza
* Implementacja
* Projektowanie
* Testowanie
* Wdrażanie

**Ważne!** Utrzymanie nie jest obszarem działalności, ponieważ na utrzymanie składa sie każdy z tych obszarów

Pierwszym obszarem działalności w tworzeniu oprogramowania jest analiza. Składa się na nią zrozumienie co potrzebuje klient, w jakich celach on będzie stosowany oraz na czym polega branża klienta.
ważnym etapem jest uzyskanie od klienta wymagań dotyczących systemu. Powinno się również zdefiniować wymagania za pomocą abstrakcyjnych modeli. Wymagania mogą sie zmieniać w czasie i trzeba być na to przygotowanym. Innym problemem jest wydzielenie obszaru, w którym działamy, otoczenia w które ingerujemy oraz granice przepływu inforamcji.

**Wymaganie**
1. Warunek lub zdolność jaką musi spełniać system, aby być zaakceptowany.
2. Warunek lub zdolność systemu potrzebny interesariuszom do rozwiązania problemu
3. Udukomentowana reprezentacja warunku 1 lub 2

Interesariusz to każdy podmiot, który ma wpływa na nasz system.

Inżynieria wymagań zajmuje sie przygotowaniem wymagań dla klienta. Główne zajęcia to:
1. Wydobycie wymagań - o co klientowi chodzi
2. analiza i zrozumienie wymagań - czego klient potrzebuje
3. specyfikowanie wymagań - przekładnia z klientowego na programistyczny
4. walidacja wymagań - sprzawdzenie czy nie ma błędów
6. zarządzanie wymaganiami - modyfikacja w czasie(klientowi coś sie przypomniało)

**Pytanie: Po co modelować?**
**Odp** - Klient składa wymagania w postaci wymagań w języku pisanym, a rezultat jest w postaci implementacji. Niezbędne są etapy pośrednie by niwelować ryzyko błędów i umożliwić walidacje na wcześniejszym, łątwiejszym do modyfikacji etapie

On definiuje wszystko co będzie omawiane typu testowanie itp, ze względu na to że to będzie omawiane nie będe przepisywał tego tutaj, a będzie kiedy to zostanie omówione

**Wdrażanie** - wdrażanie to wszsytkie operacje niezbędne do umożliwienia systemowi działania. Za wdrażanie przyjmuje sie wszystkie czynności od momentu odbioru systemu przez klienta, aż do umożlienia klientowi używania go.


**Utrzymanie** - czyli ciągłe ulepszanie i poprawianie działającego systemu

Każda zmiana sprawia, że kod jest mniej czytelny. W pewnym momencie może być potrzebna jego refaktoryzacja, w celu zmniejszenia czasu potencjalnych problemów. Z tym często wiążą się nowe problemy i bugi

Jako inżynierowie musimy zapewnić jakość programu bo tak xd

Za zapewnianie jakości uznaje sie procesy w postaci testowania, weryfikacji, tworzonych produktów oraz weryfikacja danych wejściowych(szczególnie ważne w sieciach neuronowych albo specyfikacji ze strony klienta). Również w niektórych systemach krytycznych można używać tylko wybranych, certyfokowanych komponentów i kompilatorów.

W celu zapewnienia jakości powinno się prowadzić stosownych wytycznych jak metoda SOLID lub innych kanonów programowania lub metod wytwarzania. Kod powinien być przetestowany, a cały projekt odpowiednio zarządzany. Ważne jest ciągła kontrola jakości jak testy automatyczne czy audyty.

Projekt można uznać za sukces wtedy gdy spełni przede wszystkim wymagania funkcjonalności, ale także czasowe, budżetowe oraz jakościowe.

# Wykład 5 & 6 - Analiza biznesowa i systemowa (slajdy 1-68) Ola ##
Aby zrobić dobry projekt trzeba wiedzieć coś o tej dziedzinie, żeby móc przewidzieć ewentualne problemy, rozumieć całość tego co tworzymy, wymagania, ograniczenia oraz interesariuszy, bo to oni Nam ostatecznie płacą.

Analiza biznesowa oraz systemowa bardzo często się przenikają, ciężko rozdzielić. Często Analiza biznesowa określa już z góry analizę biznesową + systemową + inżynierię wymagań.

## INŻYNIERIA WYMAGAŃ
* dziedzina zajmująca się identyfikowaniem, dokumentowaniem, analizowaniem, walidacją oraz utrzymaniem zbioru wymagań dla systemu IT
* Kategorie wymagań:
* Cele biznesowe - Jaki jest powód i uzasadnienie całego projektu i jego kosztów?, Jakich korzyści oczekuje odbiorca systemu po jego wdrożeniu?, cele formułowane wgl podejścia SMART (Specific, Measurable, Achievable, Relevant, Time-bound), czyli dokładnie określony cel jaki chcemy osiągnać
* Wymagania użytkowników - opisują co początkowo użytkownicy chcą robić z użyciem systemu
* Reguły biznesowe - często spisywane osobno; Reguły wynikające z przepisów prawnych, polityki/regulaminów organizacji, wiedzy dziedzinowej. Docelowo będą implementowane jako warunki systemu i będą sprawdzane (np. darmowa wysyłka powyżej 200 zł)
* Wymagania funkcjonalne - co system ma robić, jego usługi, zadania, jakie dane (IN, OUT?), przepływ informacji
* Wymagania pozafunkcjonalne (powinny się nazywać jakościowe) - np. chodzi tutaj o secuirity funkcjonalości systemu, o wyspecyfikowany i konkretny zakres jak coś ma być zrobione ("„System powinien działać szybko i mieć ładny interfejs" nie jest jasnym stwierdzeniem).
* Przypomnienie głównych kategorii wymagań jakościowych: wydajność, niezawodność, dostępność, ochrona, bezpieczeństwo, przenośność, elastyczność, konfigurowalność, interfejs użytkownika
* Ograniczenia związane z produktem - specyficzne: warunki pracy, wymagania użykowników; okreslony: sprzęt, technologia, format danych; wymagana: dokumentacja, szkolenia; sposób wdrożenia; zgodność ze standardami;
* Ograniczenia związane z procesem wytwarzania systemu - czas, budżet, ludzie, organizacja, sprzęt, oprogramowanie, inne
* OBSZARY DZIAŁANIA INŻYNIERII WYMAGAŃ: (jest ich 5, a po drodze tysiąc innych podpunktów, więc mam nadzieję, że się nie pogubicie w tej hierarchii :p)
* Wydobywanie wymagań – identyfikowanie wymagań i pozyskiwanie ich od interesariuszy.

Techniki:
* Wywiady
* Warsztaty
* Burze mózgów
* Kwestionariusze
* Studia dziedzinowe
* Analiza istniejącego systemu
* Obserwacje
* Terminowanie
* Analizowanie wymagań – przetworzenie wydobytych wymagań w spójną i kompletną całość. Wykrycie luk, dopytanie o jakieś rzeczy później.

Problemy:
* niejednoznaczność języka
* Spójność wymagań
* Kompletność wymagań
* Ustalenie priorytetów
* Potrzeba ponownego kontaktu

Wybrane techniki analizowania wymagań:
* Przeglądy (spójność, kompletność)
* Listy kontrolne (kompletność)
* Modelowanie (spójność, kompletność)
* Macierze śladowości 
* CRUD 
* Priorytezacja - MoSCoW(Must, Should, Could, Won’t); Inna zdefiniowana skala (0-5, 1-10 etc.); Timeboxing/budgeting; Negocjacje interesariuszy
* Specyfikowanie wymagań – zapis wymagań w jednoznacznej i zrozumiałej postaci.

Atrybuty opisu wymagań:
* Jednoznaczny identyfikator
* Źródło wymagania (kto je zgłosił)
* Odpowiedzialny (do którego analityka przypisane jest wymagania)
* Priorytet (wg przyjętej skali)
* Złożoność (trudność, koszt realizacji lub inne oszacowanie)
* Ryzyka (związane z implementacją tego wymagania)
* Status (np. nowe, sprawdzone, zatwierdzone, zaimplementowane, ...)
* Wersja
* Wymagania powiązane

Techniki specyfikowania
* Uproszczona reprezentacja (np. user stories, feature list, user case briefs)
* Tekst naturalny (opis słowny)
* Tekst ustrukturalizowany (struktura/hierarchia dokumentu, wyróżnienia, itd)
* Notacje modelujące (UML)
* Specyfikacje formalne
* Prototypy
* Inne techniki (np. diagramy przepływu, ERD)

Dokument wymagań (Specyfikacja Wymagań Systemowych – SWS, ang. System Requirements Specification – SRS):
* ustrukturalizowany zbiór informacji obejmujących całokształt wymagań względem systemu
* Wymaganie te mogą mieć różne formy (tekst, diagramy itp.)

* Walidacja wymagań – potwierdzenie u interesariuszy poprawności i kompletności wymagań. WERYFIKACJA != WALIDACJA.
* Weryfikacja - czy robimy system DOBRZE względem jakichś kryteriów lub punktu odniesienia
* Walidacja - czy robimy DOBRY system, czyli taki, który odpowiada potrzebom interesariuszy

Techniki walidacji:
* Przeglądy i inspekcje
* Praca z prototypami
* Specyfikowanie testów akceptacyjnych
* Definiowanie kryteriów akceptacji systemu
* Testy akceptacyjne

* Zarządzanie wymaganiami – utrzymywanie wymagań w trakcie całego projektu i wprowadzanie do nich zmian
* Wymagania nie istnieją każde osobno, lecz występują między nimi zależności (pole: wymagania powiązane)
* Wymagania są pewną wczesną reprezentacją systemu, elementy kolejnych reprezentacji (projektu, kodu, testów) będą wynikały z wymagań (istotna jest więc tzw. śladowość wymagań – ang. traceability)
* Dobra inżynieria wymagań ograniczy liczbę błędów w wymaganiach, ale raczej nie zmniejszy jej do zera – trzeba się liczyć z koniecznością poprawek
* Wymagania mogą podlegać zmianom w dalszych fazach trwania przedsięwzięcia np. z uwagi na zmianę sytuacji rynkowej, oferty, procedur itp.

### ANALITYK - POŻĄDANE KOMPETENCJE:
– Myślenie analityczne
– Ukierunkowanie na rozwiązywanie problemów
– Decyzyjność
– Odpowiedzialność i zorganizowanie
– Umiejętność nauki i adaptacji do zmian
– Znajomość aspektów biznesowych
– Umiejętności komunikacyjne (komunikacja werbalna, pozawerbalna, pisemna)
– Umiejętność pracy z ludźmi
– Znajomość technologii (niekoniecznie szczegółowa, ale orientacja co do możliwości)

### CERTYFIKACJA:
* International Institute of Business Analysis (IIBA)
* Certification of Competency in Business Analysis (CCBA)
* Certified Business Analysis Professional (CBAP)
* International Requirements Engineering Board (IREB)
* Certified Professional for Requirements Engineering (Foundation level, Advanced level)
* Requirements Engineering Qualifications Board (REQB)
* Certified Professional for Requirements Engineering (Foundation level, Advanced level)
* Project Management Institute (PMI)
* PMI Professional in Business Analysis

### ANALIZA BIZNESOWA OGÓLNIE
* działania związane ze zrozumieniem obszaru problemowego (np. organizacji klienta), sformułowaniem celów, definicją procesów biznesowych i aspektami ekonomicznymi przedsięwzięcia.
### ANALIZA BIZNESOWA SZERZEJ
* Identyfikacja celów biznesowych, strategii, stanu aktualnego oraz docelowego ogranizacji, aspektów ekonomicznych oraz spodziewanych rezultatów
* W ramach analizy biznesowej wprowadza się następujące techniki:
* Analiza finansowa - nie tylko koszta, ale również wartość korzyści, spodziewanych zysków, analiza opłacalności/zysku
* Modelowanie organizacji - kto kogo nadzoruje, relacje w firmie, wpływy, decyzyjność
* Modelowanie procesów biznesowych - Modele procesów obejmujące zdarzenia, czynności, decyzje, wykonawców czynności; w skrócie: jakie kroki przynoszą jakie rezultaty i jakie mamy dzięki tym krokom możliwości;
* Analiza przyczyn źródłowych - Próba dojścia do przyczyn obecnych problemów czy niepowodzeń, aby usunąć źródło, a nie tylko symptomy
* Fishbone diagram
* Five Whys (pytamy o przyczynę problemu, potem przyczynę przyczyny itd.)
### ANALIZA SYSTEMOWA OGÓLNIE
* działania skoncentrowane na zrozumieniu wymagań względem tworzonego systemu (inżynieria wymagań plus modele analityczne będące punktem wyjścia do modeli projektowych).

# Wykład 7 - 17.11.2020 - slajdy Projektowanie (1 - 53)

## Pojęcie projektu
W języku polskim projekt może oznaczać zarówno model architektury i kształtu systemu oraz projekt w sensie przedsięwzięcia. Omówione na tym wykładzie będzie to pierwsze pojęcie.

**projekt (ang. design)** - proces definiowania architektury systemu oraz jej
elementów takich jak moduły, komponenty, interfejsy,
dane w taki sposób, aby spełnione zostały cele i
wymagania postawione przed tym systemem

## Projekt i analiza
Odzielnymi etapami są **projekt** i **analiza**.
**Analiza** odpowiada na pytanie - co mamy zrobić?
**Projekt** odpowiada na pytanie - jak mamy to zrobić?

Analiza określa wymagania, które mogą determinować etap projektowania (np. architekturę, używane narzędzia).

Nie ma jednoznacznej granicy między tymi fazami bo ciężko by ją było postawić dla przypadku ogólnego, ale wiadomo o co z grubsza chodzi.

### Architektura korporacyjna
W korporacjach istnieje **architektura korporacyjna (ang. Enterprise Architecture)**, która oznacza formalny opis struktury i funkcji komponentów korporacji, wzajemnych powiązań pomiędzy tymi komponentami oraz wytycznych zarządzających ich tworzeniem i rozwojem w czasie. Przy czym komponent korporacji definiowany jest jako dowolny element korporacji, który służy do jej konstruowania; mogą to być ludzie, procesy, fizyczne struktury jak również systemy informatyczne.
Ma to ujednolicać proces analizy i projektowania, co jest wymagane w organizacjach wielopodmiotowych
Architektura korporacyjna określa procesy na kilku warstwach (m.in. biznesowej, aplikacji i technologicznej), ale nie będziemy się tym tematem bardzo zajmować.

## Elementy projektu

Prowadzący uznaje następujący podział projektu (nie jest to podział uniwersalny, obecny we wszystkich źródłach!):
* **projekt systemu (p.architektury / p. wysokiego poziomu)** - opisuje system w kategoriach jego części składowych (modułów)
* **projekt klas (p. szczegółowy / p. niskiego poziomu)** – opisuje wewnętrzne zależności i funkcjonowanie poszczególnych części składowych (modułów) - zbliżone do implementacji

### Projekt systemu
Zakres czynności:
* Określenie architektury - wewnętrznej organizacji systemu na bazie jego składowych
* Określenie podsystemów i ich interfejsów
* Decyzje o fizycznym rozmieszczeniu podsystemów (topologia systemu)
* Identyfikacja i obsługa dostępu do zasobów globalnych
* Obsługa stanów przejściowych i awaryjnych
* Wybranie podejścia dla zarządzania pojemnikami danych
* Decyzje co do stylu projektowania i wypracowanie rozwiązań kompromisowych

Ogólnie projekt systemu obejmuje decyzje globalne, które są podejmowane w kontekście całego systemu.

#### Architektura

**Acrhitektura** - opisanie systemu w kategoriach jego części jego składowych - podsystemów. Określenie interfejsów komkunikacji między tymi cześciami.
Projektanci architektury są w swoich decycjach ograniczeni uprzednio przeprowadzoną analizą i postawionymi **wymaganiami**.

Wymagania projektowe dzielą się też na kolejne podklasy:
* **funkcjonalne** - np. "System ma umożliwiać klientom przeglądanie produktów i składanie zamówień" - takie wymaganie sugeruje, że musi zostać wykorzystana aplikacja webowa
* **pozafunkcjonalne** - np. wydajność, dostępność, elastyczność - takie wymagania, sugerują na jakie czynniki ma kłaść nacisk architektura (można napisać system niezawodny ale wolniejszy, albo można napisać coś ekstremalnie szybkiego, ale sypiącego się w przypadku najdrobniejszej awarii wewnątrz systemu - wszystko zależy od zastosowań) - często tu spotyka się wymagania sprzeczne i należy wybrać te ważniejsze, bądź próbować implementować jakieś rozwiązania hybrydowe
* **dodatkowe elementy wbudowane w architekturę** - wymagania, których nie przypasowujemy do żadnej z dwóch powyższych klas, a które mogą na przykład wymagać z innych wymagań

Z tego co rozumiem, główna różnica między wymaganiami funkcjonalnymi i pozafunkcjonalnymi jest taka, że te pierwsze opisują jakby wymagania technologiczne, a te drugie opisują wymagania dotyczące oczekiwanych cech pracy systemu (i z systemem).

#### Podział na warstwy

Modelowanie architektury rozpoczyna się od stworzenia **modelu warstw** aplikacji. Podsystemy (komponenty) aplikacji, nie powinny się komunikować każdy z każdym, gdyż przy każdej kolejnej modyfikacji będziemy coraz bardziej zwiększać ryzyko wystąpienia błędu.

Wpsółcześnie korzysta się więc z architektur warstwowych, aby ujednolicić komunikację i umożliwić rozszerzalność. Komunikacja jest możliwa tylko pomiędzy obiektami tej samej warstwy, bądź między obiektami sąsiadujących warstw.

Warstwy są często wytwarzane jako kompletnie oddzielne moduły, co daje możliwość łatwiejszego podziału pracy i umożliwia używanie różnych technologi, w zalezności od wymagań w takim module.

**Najczęściej spotykane architektury warstwowe:**
* **model trójwarstwowy** - model który dzieli logikę aplikacji na 3 główne warstwy; od dołu są to:
- warstwa bazy danych
- warstwa warstwa logiki biznesowej
- warstwa prezentacji

Nie trzeba chyba tłumaczyć zakresu obowiązków tych trzech warstw.
**Wtrącenie: gdzie na modelu UML pojawia się model warstwowy, skoro nigdzie nie jest on reprezentowany?**
**Odp.** Nie ma prostej odpowiedzi na to pytanie. Przeważnie jest tak, że dane przechowywane w systemie na stałe znajdą się w warstwie bazy danych, dane związane z bieżącym przetwarzaniem zostaną umieszczone w warstwie logiki biznesowej, a dane związane bezpośrednio z wizualizacją będą w warstwie prezentacji. Ten podział powinien być w pewien sposób naturalny.
Czasem jest tak, że jedna klasa z modelu klas zostanie podzielona w procesie implementacji na 3 elementy, z których każdy będzie należał do innej warstwy. Jest to rozwiązanie całkiem powszechne.
* **różne rozszerzenia modelu trójwarstowego** - w modulu trójwarstwowym mogą pojawiać się, w zależności od scenariusza, warstwy dodatkowe; poniżej jakiś przykład z architektury Microsoftowej


* **modele wykorzystujące frameworki** - często jest tak, że korzystamy z architektury warstwowej nieświadomie - używając frameworków / bibliotek, które operują na pewnym poziomie abstrakcji i same definiują jedną (lub więcej) warstw

Podobno często myli się MVC (Model View Controller) z architekturą trójwarstwową, ale to nie to samo (w mvc wszystkie komponenty komunikują się wzajemnie ze sobą).

#### Podział na podystemy

Oprócz opisanego wyżej podziału na warstwy, system można podzielić wg **podsystemów**. Główna różnica jest taka, że zakres podystemu obejmuje zbliżone do siebie funkcjonalności, albo funkcjonalności realizowane w ramach jednego sprzętu (umiejscowione w jednym miejscu), więc jest to podział bardziej intuicyjny z perspektywy logiki systemu.

#### Oczywistość architektury

Czasem architektura jest oczywista, w szczególności dla małych systemów, bądź wykorzystując określone frameworki.

Częściej przy bardziej skomplikowanych projektach będzie ona jednak skomplikowana. Największe problemy wynikają z róźnorodności technologii, bądź ze ścisłych wymagań niefunkjonalnych.

Dla skompikowanych architektur korzysta się z gotowych rozwiązań, pozwalających na weryfikację poprawności architektury względem konkretnych wymagań. Jednym z takich rozwiązań jest **ATAM ((Architecture Tradeoff Analysis Method)**, która pozwala na wybranie odpowiedniej architektury, dokonując najbardziej korzystnych kompromisów na bazie określonych wymagań, które też mogą czasem zmieniać się podczas wczesnego procesu tworzenia nowego projektu.
Takiego wyboru dokonuje się na podstawie określenia kluczowych **atrybutów jakościowych**, które rozbija się na podatrybuty i nadaje się im poziom trudności realizacji. Z tak określonych cech, można wybrać najkorzystniejszy model architektury, przy założeniu że w fazie oceny poziomów trudności nie został popełniony błąd.

#### Fizyczne rozmieszczenie warstw/podsystemów

Stworzony model warstw/podsystemów, można jeszcze dodatkowo podzielić na komponenty fizyczne, które przecież muszą być obecne w systemie. Na skutek takiego zaprojektowania, otrzymujemy **architekturę fizyczną**.

#### Zasoby globalne

W systemie będą istniały zawsze jakieś **zasoby globalne**, do których dostęp będzie miało często wiele modułów (urządzenia, dane globalne, identyfikatory zasobów itd). Ważne jest, aby odpowiednio te obiekty **zidentyfikować**, a następnie użyć odopowiednich **metod synchronizacji**, aby kontrolować dostęp i rodzielać go odpowiednio między modułami.

#### Warunki graniczne

Kolejną rzeczą, o której trzeba pamiętać przy projekcie systemu, jest stworzenie projektu **warunków granicznych** i określenie działania systemu w przypadku ich wystąpienie. Na przykład w przypadku inicjalizacji, należy utworzyć jakieś zasoby i sprawdzić sprawność systemu. Albo w przypadku błędu krytycznego, należy usunąć po sobie śmieci i utworzyć odpowiednie logi błędu.

#### Pojemniki danych

Kolejną decyzją, które musi być podjęta globalnie, jest decyzja o **pojemnikach danych**. Mimo, że może istnieć jedna warstwa danych, nie musi to oznaczać wykorzystania tylko jednej bazy. Mogą być wykorzystywane pliki (xml/json/inne), bazy dodatkowe itd. Taki wybór jest także uzależniony od wymagań - szybkość dostępu, platfroma, zabezpieczenia, łatwość dostępi, koszty licencji - to wszystko może wpływać na końcową decyzję o sposobie przechowywania danych.

#### Wybór priorytetów

Ostatnią decyzją, którą należy podjąć w tej części pierwszej (w projekcie systemu), jest **wybór priorytetów w oparciu o wymagania**. Często prowadzą one do sprzeczności i konieczne jest, aby wykształcić odpowiednie kompromisy i zidentyfikować główne cele, aby móć lepiej kontrolować dalszy rozwó projektu.

### Projekt klas

Inaczej nazywany projekt szczegółowy / niskiego poziomu.

Dalszym etapem po zakończeniu projektu systemu jest projekt klas (tak jak wspomniałem w podziale na początku). **Niektórzy mogą go już traktować jako fazę pracy na implementacją, ze względu na problemy na jakich skupia się ten etap.**

Projekt klas - zakres:
* Wprowadzenie dodatkowych klas ukierunkowanych na implementację (np. kontrolery, obsługa urządzeń we/wy, dostęp do danych)
* Optymalizacja struktury (scalanie klas w większe lub rozbijanie na osobne, dodatkowe związki, atrybuty wywiedzione)
* Integracja modeli: klas i dynamicznego
* Projekt algorytmów (oraz struktur danych do nich)
* Projekt realizacji związków
* Projekt danych
* Uwzględnienie dobrych praktyk projektowania np. SOLID

Model analityczny wytworzony w trakcie pierwszej części procesu projektowania, może bardzo zmienić się w fazie projektu klas. Często wprowadzone są nowe klasy, które są wymagane ze względu na szczegóły implementacyjne. Dodatkowo klasy bywają redukowane w celu optymalizacji działania tworzonej aplikacji.

#### Optymalizacja struktury

Optymalizacja struktury sprowadza się do jej modyfikacji w celu zwiększenia szybkości działania, bądź w celu poprawy elastyczności pracy z modelem. Korzysta się często z wzorców projektowych, które zapewniają jakieś porządane cechy. Generalnie ten temat będzie poruszony na kolejnym wykładzie.

Podczas optymalizacji wykorzystuje się narzędzia do analizy kodu, które sprawdzają ilość klas i metod, ich długości oraz zastosowania. Takie wyniki mogą pomóc wskazać, czy dana klasa powinna być rozbita na mniejsze, lub scalona w z jakąś inną.

#### Projektowanie algorytmów

W ramach projektu klas, projektowane są też algorytmy wykorzystawane w modułach.
Na podstawie wymagań, wybierane są odpowiednie algorytmy i struktury danych, oraz planowane są podklasy potrzebne do ich realizacji.

**Ważne!
Studenci często używają pojęć *operacja* i *metoda* zamiennie, co z perspektywy inżynierii oprogramowania jest niepoprawne.**

**operacja** - opis co ma zostać wykonane - jest zawsze z perspektywy analizy
**metoda** - implementacja / opis sposobu przeprowadzenia operacji - zawsze z perspektywy realizacji

#### Projektowanie związków

W projekcie systemu, związki między podsystemami / warstwami były opisywane zwyczajnie kreską. W projekcie klas, konieczne jest dokładniejsze opisanie i zaprojektowanie tych połączeń.
Będą to czasem wskaźniki / tablice wskaźników (w połączeniach jednokierunkowych), ale czasami mogą być to specjalne struktury w stylu słownika dwukierunkowego zrealizowanenego jako oddzielna klasa.

#### Projektowanie danych

Ważnym elementem etapu modelowania klas jest projektowanie danych. Dane w bazie (/plikach) są przechowywane w określonym formacie. Najczęsciej jest on związany z modelem klas, ale czasami należy dokonać pewnych zmian. Istnieje oprogramowanie do transformacji modelu klas na model bazy danych, ale i tak przeważnie będzie to wymagać ingerencji osób trzecich w celu sprawdzenia poprawności.

#### Dobre praktyki programowania

W wytwarzaniu tego etapu nieskiego poziomu, ważne jest stosowanie się dobrych praktyk programowania. Jedną z takich prkatyk jest SOLID s Roberta C. Martina.
SOLID:
* S – Single-responsiblity principle
* O – Open-closed principle
* L – Liskov substitution principle
* I – Interface segregation principle
* D – Dependency Inversion Principle

**Single-responsiblity principle** - zasada pojedyńczej odpowiedzialności - "Nigdy nie powinno być więcej niż jednego powodu
do modyfikacji klasy" - klasa ma jeden powód istnienia, jeden cel; w przeciwnym wypadku musi zostać rozdzielona na dwie lub więcej

**Open-closed principle** - zasada otwarte-zamknięte - "Klasa powinna być otwarta na rozszerzenia, ale
zamknięta na modyfikacje" - jeżeli chcemy zaimplementować dodatkowe wymagania, najlepiej żeby nie zmieniać już istniejących właściwości klasy (atrybutów, metod), lecz móc od razu dodać nowe

**Liskov substitution principle** - zasada podstawienia Liskov - „Funkcje które używają wskaźników lub referencji do klas bazowych, muszą być w stanie używać również obiektów klas dziedziczących po klasach bazowych, bez dokładnej znajomości tych obiektów” - to jest zasada mówiąca o tym, że nie można świata zewnętrznego modelować 1:1 do modelu klas, bo jest to zwyczajnie czasami niepraktyczne, tak jak na obrazku poniżej

**Interface segregation principle** - zasada segregacji interfejsów - "Klasy nie powinny być zmuszane do zależności od metod, których nie używają" - chodzi o to, że definiując interfejs, należy jego zawartość ograniczyć do komponentów używanych przez klasę z niego korzystającą (błędem będzie implementacja interfejsu, z którego użyjemy tylko jedną metodę)

**Dependency Inversion Principle** - zasada odwrócenia zależności - "Wysokopoziomowe moduły nie powinny zależeć od modułów niskopoziomowych – zależności między nimi powinny wynikać z abstrakcji" - główne elementy naszego kodu obiektowego nie powinny zależeć od swoich składowych (to nie brzmi jakoś zrozumiale, ale musicie spojrzeć na obrazek - raczej intuicyjne)

Te zasady są w ostatnich latach ważne w procesie kształcenia nowych inżynierów.

# Wykład 8 - 24.11.2020 - slajdy Software Reuse (1 - 48)

**Software reuse** - proces budowy lub rozwoju
systemów informatycznych przez
wykorzystanie już istniejących zasobów
ponownego użycia (reuse assets)

**Reuse assets** - zasoby przygotowane do wielokrotnego wykorzystania np. wiedza dziedzinowa, wymagania, modele biznesowe/analityczne, architektury systemów (w tym wzorce architektoniczne), rozwiązania projektowe (w tym wzorce projektowe), kod źródłowy, kod wykonywalny, scenariusze/przypadki/skrypty testowe, dokumentacja, dane, narzędzia, itd.

Można wyróżnić **dwie główne działki software reuse**:
* tworzenie projektu na bazie reuse assets (kodu, dokumentacji)
* tworzenie zasobów to późniejszego wykrzostania (tworzenie reuse assets)
Na tym wykładzie skupimy się na tym pierwszym.

Reuse assets są dzielone też na kilka kategorii:
* Code reuse
* Component reuse
* Framework reuse
* Software Product Lines
* Pattern reuse

Teraz omówimy te kategorie.

### Code reuse

Współcześnie przybiera głównie postać bibliotek implementujących jakieś rozwiązania graficzne, bądź uniwersalne i często używane algorytmy. Są to biblioteki standardowe, oraz biblioteki poza standardem.

### Component reuse

Podobny do code reuse, ale bardziej polega na wykorzystaniu komponentów dostarczających zestawy funkcjonalności, a nie na importowaniu zestawu funkcji dostępnych do użycia, jeśli komuś będą potrzebne (nie wiem właściwie jaka jest różnica za bardzo w tych definicjach, ale wardziński taką właśnie podał xD).

Komponent może być dostępny jako skompilowana binarka i nie musi ujawniać kodu źródłowego (ale biblioteka w sumie też XD).

**Komponent** – niezależnie wytworzony element programowy, udostępniający swą funkcjonalność za pomocą jednoznacznie zdefiniowanego interfejsu, przy niekoniecznie jawnych szczegółach implementacyjnych, zdolny do współdziałania z większą całością oraz innymi komponentami.

### Framework reuse

Framework jest praktycznie nietłumaczalny na język polski.

Framework zapewnia podstawowe, wspólne mechanizmy oraz określa ogólny przepływ sterowania. Programista rozszerza istniejący szkielet o konkretną specyficzną funkcjonalność. Bardzo praktyczne, polecam.
Można powiedzieć, że framework dostarcza gotowy model bazowy architektury.

Często może być ciężko odróżnić te trzy powyższe elementy, framework, bibliotekę i komponent. Granica jest płynna, ale poniższe opisy mogą pomóc w zdecydowaniu:
* komponent oferuje raczej zestaw funkcjonalności niż zbiór funkcji, ponadto nie musi mieć jawnych źródeł
* generalnie biblioteka oferuje pewne funkcje, które są wywoływane z kodu tam gdzie określi to programista
* framework natomiast narzuca przepływ sterowania; upraszczając można powiedzieć, że programista tworzy specyficzny kod, który jest wywoływany przez framework
* framework może również zawierać zestaw bibliotek do wykorzystania przez programistę

Tak zdefiniowane nazewnictwo nie zawsze jest oczywiście przestrzegane.

### Software Product Lines

SPL są już związane z firmami, w których są wprowadzane. Wytwarzany jest zbiór w pewnym sensie „podobnych” produktów (np. systemy księgowe dla różnych firm), które używają pewnych modułów (cech) razem. Oprócz tego, mają one podobny proces produkcji.

Różnice w cechach obrazują *feature diagrams*.

### Pattern reuse

Ta część będzie omawiana najszerzej.
Na początku rys historyczny - pomijam bo useless.

Zaobserwowano, że istnieje pewna pula problemów, które da się rozwiązać konkretnymi rozwiązaniami architekturalnymi. Takie rozwiązania nie są reprezentowane w postaci kodu, a pomysłu, jak taki problem rozwiązać.
Powstała więc pierwsza książka „Design Patterns” autorstwa Gang of Four, która zawierała opisy powtarzających najczęściej 20 problemów, oraz ich rozwiązań.

Takie opisy nazywa się **wzorcami projektowymi**.
Wzorzec w systematyczny sposób nazywa, uzasadnia i wyjaśnia pewne ogólne rozwiązanie powtarzającego się w systemach problemu. Wzorzec opisuje problem, jego rozwiązanie, kiedy zastosować rozwiązanie (problem i kontekst) i jakie będą tego konsekwencje. Rozwiązaniem jest ogólny model elementów, klas i obiektów, ich związki, odpowiedzialności i współpracę.
Rozwiązanie to powinno następnie zostać przystosowane i zaimplementowane tak, aby rozwiązywało problem w jego szczególnym kontekście (klasy/obiekty we wzorcu będą odpowiadać klasom/obiektom danego systemu).
**Wzorzec nie jest więc algorytmem!**

Na wzorzec składa się:
* nazwa
* problem
* rozwiązanie
* konsekwencje zastosowania

Wzorce dzielą się też na różne kategorie (wstawiam część informacji jak zdjęcia, bo brakuje znaków xDD):
* **Konstrukcyjne** (ang. creational) – dotyczą procesu tworzenia nowych obiektów
- Abstract Factory - dostarcza interfejs do tworzenia grup („rodzin”) powiązanych ze sobą obiektów, ale bez specyfikowania ich konkretnych klas

- Builder - separuje proces tworzenia złożonej struktury od jej konkretnej reprezentacji, w taki sposób, że ten sam proces tworzenia pozwala tworzyć różne reprezentacje

* **Strukturalne** (ang. structural) – opisują określone kompozycje, struktury powiązanych ze sobą obiektów
- Adapter - przekształca interfejs danej klasy w inny interfejs (taki jakiego oczekuje klient)

- Composite - grupuje obiekty w struktury drzewiaste obrazujące zależność część-całość i umożliwia klientowi traktowanie zarówno pojedynczych obiektów, jak i całych struktur w ten sam sposób

* **Zachowań** (ang. behavioral) – opisują dynamiczne zachowanie i odpowiedzialność współpracujących ze sobą obiektów
- Observer - ustanawia między obiektami zależność jedendo-wiele, w której kiedy jeden kluczowy obiekt zmieni swój stan, wszystkie zależne od niego są automatycznie powiadamiane i aktualizowane

Współcześnie wzorce projektowe opisują różne problemy:
* Wzorce logiki dziedziny
* Wzorce odwzorowania O-R
* Wzorce prezentacji internetowych
* Wzorce dystrybucji
* Wzorce współbieżności
* Wzorce stanu sesji

Lazy load:

Serialized LOB:

Współcześnie pojawiają się też wzorce inne niż projektowe:
* wzorce analityczne
* wzorce architektoniczne
* wzorce dzidzinowe
* AOM

# Wykład 9 - interfejs użytkownika(tylko slajdy)

**zależności**
* Dobry interfejs nie poprawi słabego systemu
* Słaby interfejs zepsuje dobry system

**Użyteczność interfejsu**
* Produktywność
* łatwość nauki i samodzielnej pracy z systemem
* atrakcyjność/przejżystość
Metryki te są dekomponowane do danych liczbowych takich jak:
* Czas na dokonywanie danej czynności
* średnia wartośc odczuć użytkowników co do interfejsu

**Wymagania co do interfejsu są subiektywne, ale muszą być konkretne**

**Interfejs a cykl życia programu**
* **Analiza (wydobywanie wymagań)** – pozyskanie wymagań jakościowych (pozafunkcjonalnych) dot. użyteczności
* **Analiza (specyfikacja i konstrukcja modelu logicznego)** – uwzględnienie elementów interfejsu np. w diagramach sekwencji
* **Projektowanie (systemu)** – decyzje co do interfejsu (możliwości, technologia) wpływające na architekturę systemu
* **Projektowanie (klas)** – opracowanie poszczególnych elementów interfejsu i wyglądu ekranów, zastosowanie wzorców
* **Implementacja** – elementy interfejsu do zakodowania, wykorzystanie bibliotek i gotowych elementów GUI
* **Testowanie** – testy systemowe i akceptacyjne obejmują cały system w tym interfejs, dodatkowo możliwe dedykowane testy dot. charakterystyk użyteczności
* **Wdrażanie i utrzymanie** – optymalizacja interfejsu, zmiany w interfejsie wraz z rozszerzeniami systemu np. o nową funkcjonalność

**Interfejs wymaga uwzględnienia cech użytkowników takich jak**
* znajomość IT
* wiedza i dziedzina
* nastawienie i motywacja
* ograniczenia(niepełnosprawności)
* różnice językowo-kulturowe
* stan fiz. i psych.

Analiza użytkowników pod tym kątem to AKU(Analiza kontekstu użytkowania)
**Techniki analizy pod kątem interfejsu**
* Tasowanie kart
* luźne kartki zawierające poszczególne elementy systemu
* użytkownicy grupują kartki według ich powiązania
* Projektowanie treści na podstawie wyników grupowania
* Projektowanie
* określenie profilu użytkownika i stworzenie wyimaginowej presony, zawierające konkretne cechy
* wykaz typowych zadań, jakieo n sprawuje
* wymyślanie czasem życiorysu w celi lepszej empatii
* technika ta pozwala bardziej wczuć sie w użytkownika
* Testy użyteczności
* oceny eksperckie w odniesieniu do standardów ISO 9241, ISO/IEC 25010
* na podstawie zasad projektowych i heurestyk(np nielsena)
* Ukierunkowane na common mistakes
* Obserwacja pracy używkonika
* zdefiniowanie zadań
* pomiary osiągnięć
* zbieranie opinii

Często powstaja scenariusze użycia systemu zawierające poszczególne kroki. Użytkownik-tester jest nagrywany w celu obserwacji problemów

Stosuje sie trackery, w celu obserwacji, które elementy są wykorzystywane
* clicktracking
* mousetracking
* eyetracking

**Testy A/B**
* docelowa grupa użytkowników jest dzielona na podgrupy
* każda podgrupa ma inną wersje interfejsu
* mierzony jest współczynnik konwersji, czyli jaki % użytkowników zroibłto co chciał autor systemu(np kupił produkt)

zasadyu projektowania systemu określają heurystyki

**Heurystyka nielsena**(powtórka Daciuka jeśli ktoś coś pamięta XD)
* Widoczny status systemu
* system powinien informować użytkownika co sie dzieje
* komunikaty
* progressbar
* jawne pokazanie kroków dla wizardów i operacji wieloetapowych(np koszy, adres, płatność, potwierzenie)
* breadcrumbs - czyli informacja gdzie użytkownik jest i dokąd może przejść
* Zgodność systemu ze światem rzeczywistym
* stosowanie metafor i słów związanych ze światem rzecz.
* używanie języka użytkownika
* używanie zrozumiałych słów, nazw i skrótów
* unikanie terminów tchniczych
* Kontrola i wybór po stronie użytkownika
* możliwość dokonania wyboru łącznie z błędnym
* w przypadku pomyłki system proponuje rozwiązanie(np to nei jest prawidłowy numer tel itp)
* Możliwość szybkiego wycofania sie
* wsparcie dla undo i redo
* Spójność i zgodność ze standardami
* Spójność wewnętrzna(nazwy, polecenia)
* zgodność ze standardami/konwekcjami
* spójność pod względem wizualnym
* Zapobieganie błędom
* blokowanie niedostępnych opcji
* ostrzeżenia
* kontrola treści(np czy hasło jest poprawne)
* Wybór zamiast pamiętania informacji
* Ograniczenie do minimum ilości informacji, które user ma pamiętać
* wysoka widoczność opcji, poleceń, menów
* stały dostęp do helpa
* Elastyczność i możliwość optymalizacji
* rozróżnienie eksperta i basic usera
* zapewnienie skrótów dla experta
* możliwość dostosowania do własnych potrzeb
* Estetyka i umiar
* brak nadmiarowych informacji
* czytelność komunikatów
* Wsparcie w razie błędów
* komunikaty o błędach opisowe
* sugestia rozwiązania
* Pomoc i dokumentacja
* najlpeszy system nie potrzebuje dokumentacji
* łatwy dostęp, treść zrozumiałą dla usera
* krótkość dokumentacji

**User Expierience(UX)**
interfejs powinien wzbudzać pozytywne emocje, nastawienie. Jest ot dziedzina mocno interdyscyplinarna.

**UXD – User Experience Design**
Różne techniki uwzględnainia emocji i odczuć, ale też użyteczność interfejsu
* Double Diamond - przykłądowa technika UXD

# Wykład 10 - testowanie
Testowanie to analiza zachowań danego produktu i służy wykrywaniu błędów, ale nigdy nie dowodzi jego poprawności.

Według prowadzącego bug jest zawsze wynikiem błedu programisty, co nie jest prawda xd(wada po stronie komponetnów takich jak os, biblioteki lub wada po stronie użytkownika(illigal use itp))

defekt to niepoprawny krok, proces lub definicja danych
błąd to nieoczekiwane działanie programu
awaria to niemożność wykonania funkcji w programie

Celem testowania jest wykrycie błędów i na ich podstawie znalezenie usterki

środowisko testowe powinno umożliwiać działąnie, rejestracje i weryfikacje wyników. Wyniki testów powinny być zgodne z oczekiwanymi.

Testowanie ma wykryć błędy, a debugowanie ma na celu na podstawie błędu znaleść defekt.

Poziom abstrakcji w tesotwaniu:
* testy jednostkowe dotyczące pojedyńczych metod czy klas
* testy te są przeprowadzane przez autorów lub w ramach "testowania koleżeńskiego"
* często testy jednostkowe nie są sformalizowane i mają niski priorytet, często są robione na kolanie itp
* no i napisać do wszystkiego testy jednostkowe to mordęga
* testy integracyjne sprawdzają czy poszczególne moduły działają poprawnie
* integracja powinna występować przyrostowo, czyli dodajemy kolejne moduły kodu
* niezintegrowane moduły powinny być atrapowane
* testy systemowe sprawdzają czy system spełnia jakieś wymaganie funkcjonalne
* środowisko testowe powinno być zbliżone do docelowego
* powinny być prowadzone przez niezależnych testerów
* powinny obejmować:
* testy interfejsu
* testy funkcjonalności
* testy dostosowania do środowwisak i przenośności jeśli to wymagane
* testy cech jakościowych jak wydajność, bezpieczeństwo
* testy cech użytkowych jak łątwość użytkowania itp
* testy akceptacyjne sprawdzają czy system jest gotowy, działa itp
* powinny być w okolicznościach zbliżonych do docelowych(symulacja, beta testy itp)
* alfa testy są w środowisku wytwórczym a beta w docelowym lub jego symulatorze, jeśli nie jest to możliwe
* ich wynikiem jest przyjęcie, odrzucenie lub przyjęcie warunkowe produktu

Poziomy testowania:

## Proces testowania
* Co będziemy testować
* Przyotowaniae planu testu
* na czym testujemy
* na jakich poziomach abstrakcji
* jak często
* Przygotowanie testów, scenariuszów testowych
* Zebranie wyników, jeśli istnieje domniemanie błędu, to jego udokumentowanie. Błąd nie zawsze leży po stronie oprogramowania, a czasem leży po stronie testu

Cykl życia testó według normy iso

**Scenariusz testowy** to grupa większej ilosci przypadków testowych sprawdzających jakąś funkcjonalność. Naprzykład sorawdzamy dokonanie zakupów w sklepie internetowym, a test casy to jest wyszukiwanie, dodanie do koszyka czy potwierdzenie zamówienia. Ważne jest to że scaenariusz powinien posiadaćsekwencje przypadków testowych oraz jeden przypadek testowy może być w **Wielu** scenariuszach. Przypadki testowe sprawdzający bardziej pierwotną funkcja nie są wystarczające, bo program może róznie sie zachować w różnych stanach.

**Przypadek testowy** Sprawdzenie pojedyńczej rzeczy, funkcjonalności jak dodanie do koszyka czy zapłata karta. Przypadek testowy powinien mieć warunki początkowe.

Prowadzący mówi, żę przypadek testowy powinien być oparty na assercjach(umarłem xd, chodzi o assert). Sprawdzają one czy jakiś warunek jest psełniony i jeśli nie to stopują program w tym miejscu.

## Strategie testowania ###
**Strategia czarnej skrzynki** - Testowanie następuje na podstawie specyfikacji. System na konkretne wejścia powinien dawać konkretne wyjścia. Zęby testowanie było skuteczne musi nastąpić:
* Pokryciue danych wejściowych
* Pokrycie danych wyjściowych
* Pokrycie funkcjonalności

Prowdzący daje wskazówki jak testować typu przeciągając max int, dawać nieprawidłowe znaki itp

**Strategia białej skrzynki** - Mamy wgląd w wewnętrzną sktrukturę programu i na jej podstawie staramy się dobrać przypadki testowe. Np. W danej funkcjonalności powinny objąć wszystkie ścieżki i zbiory danych.
**Niezależna ścieżka** - różni się od każdej innej o co najmniej jedną instrukcje
**Liczba cyklometryczna programu** - ilość ścieżek w programie

Testując da sie jedynie udowodnić, że produkt nie działa, natomiast jego poprawność jest nie do udowodnienia(dowody formalnych nawet dla bardziej skomplikowanych algorytmów nie ma).

**Kończenie testowania**
* koniec zasobów
* wykonanie planu testowego
* pokrycie przypadkami testowymi
* szacowanie przez analogie
* dynamika zgłoszeń błędów(jak częstotliwość spada to skończyć)

**Paradoks pestycydów** - Programista naprawiając defekty nauczy sie ich nie popełniać, natomiast jeśli testerzy nie zmienia metod w czasie przestaną cokolwiek wykrywać

**Test Driven Development** - pisanie kodu spełniający testy, które powstały przed kodem.

**Testowanie mutacyjne** - testowanie testów

# Wykład 11 - Wdrażanie i utrzymanie

## **Wdrożenie** - ogół działań których celem jest doprowadzenie do rzeczywistego użytkownia programu. Dla początkujących programistów ten proces jest pomijalny, natomiast w praktyce jest ona bardzo złożony i wymaga sporo pracy dla zaawansowanych systemów.

**Klasy systemu**
W zależności od zastosowania wymagane są różne działania w ramach wdrożenia, czasem wystarczy wrzucić na gPlay i zapewnić support, a czasem te akcje mogą zajmować lata
* Systemy klasy ERP( Enterprise Resource Planning)
* wszystkie działy i procesy są wspomagane przez system
* wysoki koszt niedziałania systemu
* konieczność wprowadzania poprawek w sposób niezauważalny
* System kontroli ruchu pociągowego
* przygotowanie sprzętu, instalacja i przygotowanei do użytku, testowanie w warunkach polowych itd
* konieczność bycia bezpiecznym i niezawodnym
* spełnienie norm, audyty i certyfikaty
* System bankowości internetowej
* dostosowanie do już istniejących systemów
* Wysokie wymagania security, potrzeba przeprowadzenia wielu testów
* test wydajności, użytkowania itd

**aspekty wdrażania**
* informatyczny - dostarczyć, zainstalować, uperwnić się że działa itp
* zarządzające - przejście na nowy system, wyszkolenie przyszłych użytkowników, synchronizacja danych. Np po zainstalowaniu kasy samoobsługowej kasierzy zmieniają się w helpdesk, trzeba ich do tego przygotować
* biznesowe - sprawdzenie osiągnięcie danych korzyści np redukcja personelu
* zagwarantowania użycia danych nowych funkcjonalności

Prowadzący fajnie mówi, że wdrożenie to moment prawdy, bo jak wiadomo w labie wszystkie testy są fajne, łatwe i przyjemne, ale w praktyce...
Ujawniane są wady, typu brak dobrze zdefiniowanych wymagań, typu ładnie i szybko, które może dla klienta nie okazać się ładne i szybkie.

**Etapy Wdrażania**
* Odbiór systemu - początek
* testy akceptacyjne
* testy alfa/beta
* odniesienie do specyfikacji lub planów
* formalna akceptacja klienta(git nei git)
* szkolenia
* instalacja
* migracja danych
* reorganizacje klienta
* audyty
* certyfikacja
* poprawki błędów
* dodanie brakujących funkcjonalności
* dopasowanie do środowiska i optymalizacja w nim
* kastomizacja - implementacja ogólnego systemu do konkretnego środowiska
* Start produktywny (go live) - koniec
* System jest stabilny, działą, nie wywala sie itp(w polsce nie ma systemu, który spełnia ten wymóg xD)
* kończy etap wdrażania
* System jest zintegrowany
* użytkownicy potrafią z niego korzystać(dla zamkniętych systemów)
* gotowe rozwiązania na wypadek problemów
* wprowadzono odpowiednie dane

W przypadku istnienia starego systemu istnieją strategie wdrażania.
* **Strategia bezpośrednia** - zakłada zmiane nagłą z jednego systemu na 2(31.12 działą stary a od 1.01 nowy)
* **strategia równoległa** - zakłada używanie nowego systemu, przy istniejącym starym. Wówczas na wypadek błędu możliwe jest używanie starego systemu. Np rok 2019 jest przejsciowy i obydwa systemy działają i sie synchronizują(np baza danych) lub jeśli to jest niemożliwe, to duplikuje sie na pewnien czas prace pracowników. Powinno to być możliwie zminimalizowane(np do papierowej dokumentacji idą wydruki z systemu). Stary system nie musi być elektroniczny, mógł być np papierowy.
* **strategia pilotowa** - część pracowników przesiada sie na nowy system, a część korzsta ze starego. Dzięki temu możliwe są zastoje, ale są onne minimalizowane. Po zażegnaniu problemów na części pilotażowej, reszta pracowaników przesiada sie na nowy
* **strategia fazowa** - zmienia sie system modułami. Jest to możliwe tylko dla specyficznych systemów, które da się tak podzielić. Po wprowadzaniu i przetestowaniu modułu A, wprowadza sie moduł B itd. Często spotykane w systemach korporacyjnych.

## **Utrzymanie(maitenance)** - to co następuje po etapie wdrażenia
Wszystkie zabiegi w czasie użytkowania. Systemy często istnieją kilkanaście lat(patrz COBOEL). Utrzymanie pochłania większość pracy informatyków.

na utrzymanie składa sie
* licencja - kto może użytkować, robić zmiany itp
* częstotliwość updatów
* czas oczekiwania na zmiany
* hotfixy
* jak długo ma być utrzymywany
* **Obszary działąnia**

Dalej mówi cośo jakimś nor-sta editor, gdzie wprowadzanie go do różnych firm niosło za sobą jakieś zmiany, ale mam nadzieje że nie będzie o to pytał, bo gada o konkretnym przypadku chyba jako sample, coś o adaptacjach, updatach i to że potrafiia one wykrzaczyć, coś jak replay boingowego gadania xd

**Prawo lehmana**
* Ustawiczna zmiana - Program użytkowany w rzeczywistym środowisku nieuchronnie musi podlegać zmianom albo stawać się mniej przydatnym w tym środowisku
* Rosnąca złożoność - W miarę jak ewoluujący program zmienia się, jego struktura staje się coraz bardziej złożona. Na zachowanie i uproszczenie struktury trzeba przeznaczyć dodatkowe zasoby

redukcja entropii, czyli spadku użyteczności
* Dobrze przeprowadzona faza projektowania
* Poprawki w trakcie działania systemu
* refaktoryzacja - zmiana wewnętrzej struktury kodu, który czyni go łatwiejszym i czytelniejszym, bez wpływu na działanie
* restrukturyzacja - to samo tylko na wyższym poziomie abstrakcji(zmiana np modelu klas)

**Utrzymanie - problemy**
* modyfikacje kodu bez patrzenia na jego czytelność
* poprawki wprowadzane przez różne osoby mają różny styl i robi to burdel
* dezaktualizacja dokumentacji czyni to trudniejszy(Ja tam najwększe problemy mam z nową dokumentacją pełną bzdur, a że castuje dokumentacje na kod to wiem co mówie xd)
* Rosnące koszty utrzymania, coraz większa liczba poprawek
* spadek dostępu do personelu tworzącego kod

**Utrzymanie - czynniki wpływu**
* Wiedza developera- stary developer danego projektu dużo łątwiej sobie radzi z zadaniami, w przeciwieństwie do nowo wprowadzanej osoby
* wykształcone cechy oprogramowania(styl, komentarze, dokuemntacja)
* Dokumentacja - cechy programu, analiza funkcji itp
* narzędzia ułatwiające prace

**Dług technologiczny** - odsunięty w czsie koszt oprogramoawniamniej, który po kolejnych zmianach może powodować znacznie większe nakłady, który często powoduje . Może być zaciągniety świadomie kiedy chcemy cos klientowi pokazać, a potem dopracować. Niestety czasem jest zaciągany nieświadomie, co powoduje dodatkowe koszty projektu. Przykładem częstego długu jest duplikacja kodu(NIGDY NIE DUPLIKUJCIE KODU). Dług technologiczny wpływa na entropie oprogramowania.

**Cykl życia programu**
Wytwaarzane, utrzymanie, wycofanie

nie wszystkie systemy są wycofywane, patrz banki i cobol(btw programiści cobola umierają, a to najlepiej płatny język xd)

**Wycofanie systemu**
po wycofaniu system rozwojowy staje sie systemem spadkowym
* system rozwojowy to taki w któy inwestujemy, poprawiamy bugi
* system spadkowy wprowadza sie tylko niezbędne poprawki(np w windowsie 7 było kilka critical issue fix po zaprzestaniu wspierania)

Często taka decyzja jest podejmowana kiedy koszty przewyższają zysk

## elementy zarządzania
* zarządzanie konfiguracja
* nadzór nad wszystkimi elementami systemu IT, szczególnie istotne jest wspomaganie pracy wielu osób. W skład wchodzą takie rzeczy jak dokumentacja, testy scenariuszu itp.  zakres tego zarządzania obejmuje wszystko, począwszy od gita, zgłoszeń błędów, procesu testowania, dokuemnty formalne, konfiguracja środowiska oraz **relacjami między elementami**
* ciągła integracja - wrzucanie swoich zmian i ich integracja co najmniej raz dziennie, jest to praktyka historyczna, wynikająca ze złych praktyk. Każda integracja powinna zostać skompilowana oraz przetestowana. Może być rozszerzona o ciągłe wdrażanie i ciągłe dostarczanie. Np poprzez udostepnianie updatów użytkownikom w sposób zautomatyzowany. CI używaliśmy na PT, puszczanie automatycznych testów, analizy statycznej i kompilacji. W większych prjektach ten proces moze być olbrzymich rozmiarów, ale dzięki temu upraszcza to wykrywanie błędów itp.
* zarządzanie zmianami i problemami
* zgłąszanie błędów
* przydział pilności i priorytetów
* niektóre błędy są ignorowane ze względu na niskie skutki lub problemy z reprodukcja
* propozycje nowych featerów
* zabiegi adaptacyjne i zapobiegawcze
* proces wprowadzania zmian, analiza wpływu, zasobów danej zmiany itp
* uaktualnianie
* sposoby na dostarczanie użytkownikom, decydowanie które zmiany są pilne, a które mogą poczekać na większą paczke(microsoft nie czeka xd)
* problemy związane z uaktualnianiem
* kompatobilność wsteczna
* ciągłość pracy
* sposób dystrybucji
* automatyczna(poprzez sieć)
* manualna(fizyczne dostarczenia nośników)
* poprzez specjalne systemy

# Wykład 12 - Modele cyklu życia oprogramowania
Modele cyklu życia oprogramowania opisują proces wytwarzania oprogramowania.


Jak złożyć działania z poszczególnych obszarów IO w sensowną całość?

## Podejście "na żywioł" (cowboy coding, code & fix)
* praca nad projektem bez reguł, żadnego zdefiniowanego procesu,
* powoduje problemy w pracy zespołowej,
* problemy z współpracą z udziałowcami,
* trudności w zapewnieniu jakości projektu i kodu,
* popularna metoda w początkowym stadium rozwoju informatyki, była źródłem kryzysu oprogramowania (Software Crisis) i impulsem do rozwoju inżynierii oprogramowania (definiowania procesów, metod wytwarzania, dobrych praktyk).

## Pojęcia

**Cykl życia oprogramowania / model cyklu życia / model wytwarzania** - ogólna metoda oganizacji procesu wytwarzania systemu, zawierająca podział na etapy i kryteraia przechodzenia między etapami, może równierz sugerować produkty i praktyki. Jest to pojęcie na wysokim poziomie abstrakcji.

**Metodyka** - konkretna metoda, baująca na jedynm lub kilku modelach wytwarzania, definiująca szczegółowo etapy, praktyki wytwórcze/zarządcze, produkty, role członków zespołu, zwykle firmowana przez okreśłonego autora/gremium/konsorcjum zajmujących się ich rozwojem i popularyzacją.

## Propozycje modeli wytwarzania

### Klasyczny (kaskadowy, waterfall) model cyklu życia


Charakterystyka modelu klasycznego:

* Wyróżnione i odseparowane etapy odpowiadające poszczególnym podstawowym obszarom IO
* Na każdym etapie przedmiotem zainteresowania jest cały wytwarzany system np.
* podczas analizy przetwarzamy i identyfikujemy wszystkie wymagania, przygotowujemy wszystkie modele analityczne
* tworzymy projekt architektoniczny i szczegółowy całego systemu,
* implementujemy całość, nie dzieląc implementacji na żadne etapy,
* testujemy i wdrażamy cały system, nie ma tutaj wdrożenia pilotażowego albo fazowego.
* Etapy ustawione są sekwencyjnie, każdy kolejny może się zacząć dopiero gdy w całości zostanie skończony poprzedni.
* Jeśli we wcześniejszym etapie popełniono jakiś błąd lub ujawni się problem z wymaganiami to należy wrócić do tego miejsca, dokonać korekty i ponownie przejść przez etapy poprzednie (przerywane strzałki na diagramie).
* w ten sposób np. wykryty przy testowaniu błąd wynikający z niezrozumienia wymagań klienta wymaga powrotu do etapu analizy
* w praktyce trudno o przebieg bezbłędny, prawdopodobnie trzeba będzie wracać i to więcej niż raz.

#### Zalety modelu klasycznego

* Pierwsza propozycja reakcji na Software Crisis
* Łatwy do zrozumienia / wytłumaczenia
* Obejmuje wszystkie obszary IO i wprowadza systematykę
* Narzuca dobre praktyki - dobre zrozumienie problemu (analiza) i zdefiniowanie architektury (projekt) przed implementacją
* Pozwala na wyraźne zdefiniowanie etapów (np. możliwe punkty kontrolne – milestones i śledzenie postępów)
* Pozwala na dekompozycję pracy dla różnych ról (np. projektant, programista, tester) oraz rozłożenie ich zaangażowania w czasie
* Powstały oparte na nim standardy z konkretnymi metodykami

#### Wady modelu klasycznego

* Zakłada, że od razu będzie możliwe zidentyfikowanie i uchwycenie całego problemu i wymagań, co zwykle jest trudne – w trakcie całego projektu „odkrywane” są kolejne szczegóły
* Zakłada, że pozyskane na początku projektu wymagania będą stabilne i nie będą podlegały zmianom – w praktyce rzadko kiedy jest to możliwe
* Działające oprogramowanie powstaje późno, pod koniec projektu, wcześniej nie ma co pokazać użytkownikom
* Wytwarzanie jest oderwanie od udziałowców, walidacja produktu następuje dopiero w końcowych krokach (testowanie, wdrożenie)
* Błąd lub żądanie zmiany powoduje konieczność powrotu do odpowiedniego etapu i przejścia procesu jeszcze raz

---

### Model V

Idea modelu V jest wyeliminowanie lub mocne ograniczenie prawdopodobieństwa popełnienia błędu powodującego konieczność powrotu do poprzedniego etapu. Po każdym etapie stosowane są sformalizowane liczne zabiegi jakościowe, np. sformalizowane przeglądy, inspekcje, audyty, formalne zatwierdzenia przez pewien komitet sterujący wyników danego etapu. Kładziony jest mocny nacisk na testowanie. Dodatkowo realizując dany etap wytwarzania można już próbować specyfikować scenariusze testowania(których jeszcze nie wykonujemy, ponieważ testowanie odbywa się na działającym kodzie).

Model V cały czas znajduje zastosowanie, jest chociażby podstawą standardów do wytwarzania oprogramowania systemów wbudowanych w branży samochodowej. Jest podstawą pewnych metodyk i standardów do obszarów aplikacyjnych gdzie kładzie się duży nacisk na jakość i brak poważnych błędów.

#### Zalety modelu V

* Model przenosi wszystkie zalety modelu klasycznego
* Jest ukierunkowany na wysoką jakość wytwarzanego produktu (liczne zabiegi projakościowe, testy prowadzone na wielu poziomach)
* Obniża ryzyko popełnienia dużego błędu

#### Wady modelu V

* Przejmuje też większość wad modelu klasycznego – założenie o dobrze zidentyfikowanych i stabilnych wymagań, małą elastyczność, oderwanie od udziałowców
* Znaczne narzuty pracy, czasu i kosztów poświęcane na testy i jakość
* Silne rozbudowanie dokumentacji
* W razie zmian też trzeba się cofać, a w dodatku modyfikować testy (ponowny powrót jest jeszcze kosztowniejszy niż w modelu klasycznym)

### Podejście iteracyjne


Idea: zamiast jednego „przebiegu” jak w modelu kaskadowym, wykonywanych jest kilka iteracji
* W ramach każdej iteracji powstaje jakaś (tymczasowa, nie ostateczna) wersja produktu
* W każdej iteracji system jest rozbudowywany lub/i udoskonalany
* Umożliwia to:
* uczenie się deweloperów w trakcie przedsięwzięcia (zrozumienie potrzeb),
* sprzężenie zwrotne od użytkowników/udziałowców,
* dostosowanie produktu do potrzeb(również tych zmieniających się w trakcie przedsięwzięcia),
* poprawianie błędów w kolejnej iteracji.

Ideą podejścia iteracyjnego jest to, że zamiast jednego przebiegu jak w modelu kaskadowym czy modelu V, wykonujemy kilka iteracji, czyli w celowo kilka razy realizowana będzie część działań wytwórczych dla produktu. W ramach każdej iteracji powstaje jakaś nieostateczna wersja wytwarzanego produktu. Każda kolejna iteracja powoduje, że produkt jest w jakiś sposób rozbudowywany lub udoskonalany. Umożliwia to uczenie się członków zespołu w trakcie realizacji projektu. Nie zakładamy, że na początku całościowo przeanalizujemy wszystkie wymagania tak jak w poprzednich modelach. Kolejna rzecz to możliwość uzyskiwania sprzężenia zwrotnego od użytkowników czy interesariuszy. Model ten umożliwia również dostosowanie produktu do zmieniających się potrzeb oraz poprawianie błędów wprowadzonych w poprzedniej. Jest to planowe, przewidywane działanie w przeciwieństwie do modelu klasycznego, w którym jest to powód powrotu do poprzednich etapów.

#### Możliwości podejścia iteracyjnego

* Zgodnie z nazwą projekt podzielony jest na iteracje
* Jednak w zależności od tego, co będzie wykonywane w tych iteracjach, można wyróżnić konkretniejsze modele wytwarzania:
* dodanie kolejnej porcji funkcjonalności -> model przyrostowy
* wizualizacja wymagań i ich lepsze zrozumienie -> model prototypowy
* zaadresowanie największego ryzyka -> model spiralny

---

### Model przyrostowy


Model przyrostowy to rodzaj podejścia literacyjnego, w którym w każdej iteracji dodajemy nową porcję funkcjonalności, np. osobny podsystem. Na początku trzeba poczynić ustalenia ogólnych wymagań i podjąć decyzję odnośnie architektury. Działanie rozwiązania pod kątem szczegółowych wymagań doprecyzowujemy w kolejnych iteracjach dodając kolejny podsystem. Czyli na podstawie szczegółowych wymagań implementowane są nowe elementy, które są następnie testowane i integrowane z elementami, które powstały do tej pory. Na końcu nowy podsystem jest walidowany(pokazywany interesariuszom) i opcjonalnie wdrażany(nie trzeba wdrażać wszystkiego co zrobiono). Po ostatniej porcji funkcjonalności system jest gotowy.

**Przyrost** - porcja funkcjonalności będąca przedmiotem pojedynczej iteracji, dla której specyfikujemy szczegółowe wymagania.

#### Odwzorowanie na model klasyczny

#### Przyrostowa budowa systemu


Pionowe linie oznaczają osobne funkcjonalności/podsystemy/moduły. W modelu kaskadowym wszystkie funkcjonalności implementowane są we wspólnej fazie. W modelu przyrostowym każda funcjonalność implementowana jest w czasie swojej iteracji.

#### Zalety modelu przyrostowego

* uniknięcie wielu problemów występujących w podejściu kaskadowym poprzez:
* redukcję kosztu zmian w wymaganiach kolejnych modułów/podsystemów
* uniknięcie jednorazowej integracji wszystkich modułów(„big bang problem”)
* równomierny rozkład nakładów na testowanie(testy po ukończeniu każdego przyrostu)
* możliwość poprawy procesu w ramach projektu
* lepsze szacowanie projektu(lepsze szacowanie kolejnych przyrostów na podstawie poprzednich)
* stabilizacja wymagań na poziomie realizacji danego przyrostu
* nie ma konieczności pełnej specyfikacji wymagań na samym początku, wystarczy zarys, konkretniej specyfikowany jest tylko najbliższy przyrost
* każdy przyrost:
* dodaje nowe funkcje
* może być realizowany oddzielnie
* może być oddzielnie testowany
* może być zrealizowany w krótszym okresie (np. kilku miesięcy)
* intensywność prac można regulować
* namacalny produkt (część systemu) powstaje szybciej
* użytkownicy są mocniej wciągnięci w proces (komunikacja z interesariuszami przed rozpoczęciem i ukończeniem każdego przyrostu)

#### Wady modelu przyrostowego

* Przydatny raczej tylko dla systemów, w których dopuszcza się podzbiory funkcji (możliwość dekompozycji na podsystemy)
* Dojście do rozwiązania docelowego bardziej długotrwałe i kosztowne (wiele iteracji) niż dla „bezbłędnego przebiegu” modelu klasycznego (jednak bezbłędny przebieg modelu klasycznego jest bardzo mało prawdopodobny)
* Przy szczegółowej analizie danego przyrostu może się jednak okazać, że inicjalnie określony zakres systemu i jego projekt architektury są jednak niewystarczające

---

### Model prototypowy


Kolejny model oparty na podejściu iteracyjnym. Celem pojedynczej iteracji jest wytworzenie prototypu systemu doskonalszego niż poprzedni. Stosujemy inżynierię wymagań(analiza), żeby zebrać wymagania będące podstawą do zaprojektowania i zbudowania pierwszego prototypu. Prototyp jest poddawany ocenie przez udziałowców. Po uwzględniuniu uwag przygotowywany jest kolejny prototyp lub jeśli nie ma uwag to na podstawie tego prototypu jest wytwarzany docelowy system.

#### Odwzorowanie na model klasyczny


Kolejne iteracje odbywają się w ramach analizy.

#### Prototypowanie

**Prototyp** - uproszczona reprezentacja docelowego systemu.
Podstawowym celem prototypowania jest identyfikacja wymagań
poprzez budowę kolejnych przybliżeń systemu.

Prototypować można na różne sposoby:
* Model „papierowy” - bazuje na rysunkach interfejsów systemu (np. rysunki ekranów pokazywane użytkownikowi)
* Model „symulowany” - analityk odgrywa rolę systemu i informuje o jego kolejnych reakcjach na działania użytkownika, może również wspomagać się rysunkami
* Model „programowy” – oprogramowanie napisane specjalnie w celu demonstracji użytkownikowi określonych cech docelowego systemu. Najczęściej interfejs użytkownika i uproszczone funkcjonalności np. wyświetlanie ustawionych na stałe danych, bez logiki biznesowej, bez wydobywania danych z bazy. Jeśli prototyp osiągnie wystarczające przybliżenie, jest on porzucany. Od zera implementowany jest docelowy system biorąc pod uwagę informacje o wymaganiach zdobyte na podstawie prototypu.
* Model „ewolucyjny” - częściowo wykonany system docelowy, posiadający najpilniejsze (z punktu użytkownika) cechy systemu docelowego, który będzie podlegał kolejnym rozszerzeniom zmierzającym do uzyskania pełnej wersji systemu docelowego – ale to już bardziej inne podejście (ewolucyjne)

Poza prototypowaniem wymagań możliwe jest również prototypowanie konstrukcji (proof of concept)

#### Zalety modelu prototypowego

* wspomaganie identyfikacji wymagań
* zwiększenie zaangażowania udziałowców w procesie wytwarzania(poprzez pokazywanie im kolejnych prototypów i odnotowywaniu uwag)
* lepsza walidacja systemu(sprawdzenie czy wykonywany jest właściwy system, który będzie przydatny i będą z niego potrafili korzystać użytkownicy), możliwość odniesienia się udziałowców do przedstawianego prototypu
* możliwość oceny i doboru alternatywnych rozwiązań
* poprawa cech jakościowych:
* łatwości użycia, ergonomii, dopasowania do potrzeb
* jakości konstrukcji, utrzymywalności

#### Wady modelu prototypowego

* Budowa i wprowadzanie zmian do prototypu pochłaniają czas i koszty, co może budzić opór, zwłaszcza jeśli prototyp jest „do wyrzucenia”
* Projektant może „przyzwyczaić się” do rozwiązań, które zastosował w prototypie i użyć ich w docelowym systemie, podczas gdy niekoniecznie będą one adekwatne do wszystkich wymagań (np. jakościowych typu wydajność, bezpieczeństwo).
* Klient widzi coś, co w jego przeświadczeniu jest działającym systemem i ma problemy w zrozumieniu dlaczego ma on być zarzucony i budowany od nowa

---

### Model spiralny


Kolejna wersja podejścia iteracyjnego to model spiralny. Kształt modelu ma pokazywać, że coraz bardziej zwiększa się zakres systemu. Zostały wyróżnione 4 fazy. Planowanie kolejnej iteracji, analiza ryzyka, faza wytwarzania i ocena ze strony użytkowników i innych interesariuszy. Słowem kluczowym związanym z modelem spiralnym jest ryzyko. Model jest ukierunkowany na zmniejszanie ryzyka związanego z projektem w każdej iteracji.

* Strategia zmniejszająca ryzyko
* Cykliczność faz wytwarzania, uwzględniająca oceny użytkownika i walidację
* Najogólniejszy model wytwarzania, wg autora (Barry’ego Boehma) mieści w sobie pozostałe modele jako specjalne przypadki

Przydatny dla przedsięwzięć obarczonych dużym ryzykiem przeznaczonych na szeroki rynek(nie dla pojedynczego klienta), gdzie konieczna jest ocena stanu, analiza zagrożeń i dostosowanie na tej podstawie dalszych działań

Przykład: Oprogramowanie opracowywane na szeroki rynek, w warunkach dużej konkurencji może wymagać działań wg modelu spiralnego. W kolejnych obrotach spirali przedmiot zainteresowania mogłyby stanowić np. dodanie kluczowej funkcjonalności, która jest już w konkurencyjnym produkcie(ryzyko - przewaga konkurencyjna) albo udoskonalenie części systemu postrzeganej przez użytkowników jako bardzo „denerwująca”(ryzyko - szukanie podobnego rozwiązania u konkurencji, negatywne opinie użytkowników).

#### Zalety modelu spiralnego

* Jawne wskazanie ryzyka i jego oceny
* Działania adresujące ryzyko obejmujące jawne rozważanie alternatyw np. tworzymy/pozyskujemy komponent
* Mocne ukierunkowanie na zmiany – kolejna iteracja może obejmować ich wprowadzenie albo wręcz być temu poświęcona
* Szybciej wykrywane i rozwiązywane są trudne problemy i wyzwania napotykane w ramach projektu

#### Wady modelu spiralnego
* Model trudny do zrozumienia/wyjaśnienia
* Koszt zarządzania ryzykiem
* Długotrwałość dojścia do rozwiązania docelowego
* Model uznawany za przydatny tylko dla dużych projektów i organizacji

## Użycie modeli w praktyce

Czyste kaskadowe podejście nie jest używane na szeroką skalę. Podstawą współczesnych procesów wytwarzania oprogramowania i projektów realizowanych w warunkach przemysłowych jest głównie podejście iteracyjne w modelu przyrostowym w połączniu z ewolucyjnym modelem prototypowym. To znaczy, że oprócz dodawania nowych funkcjonalności/podsystemów uwzględniamy również ewentualne modyfikacje tych stworzonych wcześniej.

## Modele uzupełniające

Modele uzupełniające mają zastosowanie w projektach korzystających ze specyficznych zasobów i praktyk, np. projektów bazujących w wysokim stopniu na wykorzystaniu gotowych komponentów, bazujących na systemie już istniejącym wykonanym w przestarzałej technologii. Nie są to podejścia zupełnie rózne od przedstawionych wcześniej, ale ze względu na ich specyfikę zasługują na odrębne omówienie

### Komponentowy model wytwarzania


* Model wytwarzania dla systemów opartych głównie o gotowe komponenty (COTS - Commercial of the Shelf)
* Zamiast projektowania i implementacji "od nowa" zawiera dużo więcej analizy istniejących komponentów, ich wyboru, dostosowywania do potrzeb i integracji

Występuje tu faza Requirements modification, ponieważ nie zawsze jesteśmy w stanie z gotowych komponentów wytworzyć produkt spełniający wszystkie wymaganie klienta. Należy więc dojść do kompromisu między wymaganiami a tym co można zapewnić przez użycie gotowych komponentów.

System design with reuse to projektowanie systemu polegające na wplataniu w niego dostępnych komponentów.

Development and integration to implementacja tego co jest potrzebne do integracji komponentów lub pokrycia brakującej funkcjonalności.

Model jest podobny do kaskadowego.

---

### Model ponownej inżynierii oprogramowania (re-engineering)


Model ponownej inżynierii oprogramowania polega na tym, że istnieje już jakiś system, który ma być zastąpiony nowym. Najpierw trzeba przeprowadzić inżynierię odwrotną starego systemu. Określić jak został zaimplementowany, zaprojektowany, spróbować odtworzyć wymagania a następnie koncepty na podstawie jakich został zaimplementowany. Następnie odtworzone etapy są przekształcane na nowe według potrzeb, z kierunkiem zgodnym z modelem klasycznym.

* Model wytwarzania dla sytuacji gdzie istnieje już jakiś system, który ma być zastąpiony nowym
* Dla starego systemu może nie być dokumentacji (którą trzeba wówczas odtworzyć na podstawie kodu i działania), a nawet może nie być kodu źródłowego (konieczna dekompilacja)
* W inżynierii odwrotnej wchodzi się na wyższe poziomy abstrakcji (np. odtworzenie projektu architektury na podstawie kodu), w inżynierii „do przodu” na poziomy niższe (tak jak zwykle przy wytwarzaniu)

#### Schemat procesu inżynierii odwrotnej (reverse engineering)

(Tylko pokazał i pominął)


* Analiza oprogramowania w celu odtworzenia jego projektu i specyfikacji
* Może być częścią restrukturyzacji, a może być podstawą ponownej implementacji systemu

---

### Model oparty o przekształcenia formalne (transformational development)


Zastosowanie metod formalnych w inżynierii oprogramowania. System zostaje rozpisany w oparciu o sformalizowane konstrukcje matematyczne(użycie teorii zbiorów, algebry relacji) a następnie w sposób jak najbardziej zautomatyzowany będzie przekształcany do kolejnych, bardziej szczegółowych reprezentacji i finalnie do postaci kodu źródłowego. Jest to rozwiązanie niszowe, które znajduje zastosowanie w niektórych wąskich dziedzinach, w szczególności w systemach krytycznych ze względu na nacisk na bezpieczeństwo.

* Budowa najpierw innej reprezentacji systemu np. opartej o formalną notację matematyczną i potem przekształcanie tego do kolejnych reprezentacji i finalnie do postaci kodu
* Stosowane w wąskich dziedzinach zastosowań np. dla systemów krytycznych (ang. safety-critical systems)

---

### Przekształcenia modeli (MMD Model-Driven Development)

Model podobny do poprzedniego, nie aż tak sformalizowany. Podejście MMD polega na tym, żeby również w sposób jak najbardziej zautomatyzowany. Generować kolejne, bardziej szczegółowe reprezentacje systemu na podstawie poprzednich, bardziej abstrakcyjnych.

Przykładem jest podejście MDA zaproponowanie przez Object Management Group. Sugeruje ono najpierw zamodelowanie produktu w samych terminach biznesowych. Następnie z użyciem terminów informatycznych, ale w sposób niezależny od technologii i platformy. Na końcu w sposób uwzględniający specyfikację technologii i platformy, na jego podstawie zostaje generowany kod.


## Podsumowanie

Istnieje wiele modeli wytwarzania ponieważ przydatność danego modelu jest uzależniona od specyfiki danego projektu. Przykładowo model kaskadowy może okazać się przydatny jeśli wymagania będą stabilne. Jeśli świadomość interesariuszy jest niska, trudno jest się z nimi dogadać to przydatny może sie okazać model prototypowy. Możliwość dekompozycji systemu na podsystemy może determinizować przydatność podejścia przyrostowego. Modele dobieramy w zależności od specyfiki danego przedsięwzięcia informatycznego. Modele wytwarzania stanowią abstrakcję rzeczywistych procesów wytwarzania. Rzeczywiste procesy wytwarzania muszą skonkretyzować idee modelów, przełożyć je na praktyki deweloperskie, na konkretne produkty, na przydział ludzi do ról itd.

* Przydatność modelu wytwarzania jest uzależniona od specyfiki danego przedsięwzięcia
* np. stabilność wymagań, świadomość udziałowców, możliwość dekompozycji systemu na porcje funkcjonalności, możliwość użytkowania niedoskonałego systemu, poziom wymagań jakościowych...
* Należy dobierać model, organizację przedsięwzięcia i techniki wytwarzania w zależności od specyfiki danego problemu!
* Modele wytwarzania stanowią pewnego rodzaju abstrakcję, rzeczywiste procesy wytwarzania w konkretnych projektach często łączą elementy różnych modeli

Jak najbardziej możliwe i warte rozważenia jest świadome łączenie elementów różnych modeli wytwarzania. Nic ma żadnego przeciwwskazania, żeby zastosować prototypowanie do lepszego określenia wymagań, a potem na przykład wytwarzać ten system według modelu przyrostowego. Konkretne metodyki wytwarzania czy procesy wytwórcze w firmach, zespołach często czerpią z kilku modeli cyklu życia i w jakiś sposób łączą ich zalety. Np połączenie przyrostowości z uprzednim prototypowaniem lub modelem ewolucyjnym.

# Wykład 13 - Metodyki wytwarzania i zarządzania projektem
(Nie mówi za dużo oprócz tego co na slajdach, więc głównie slajdy + troche dopowiedzeń)

**Metodyka** - konkretna metoda, bazująca na jedynm lub kilku modelach wytwarzania, definiująca szczegółowo etapy, praktyki wytwórcze/zarządcze, produkty, role członków zespołu, zwykle firmowana przez okreśłonego autora/gremium/konsorcjum zajmujących się ich rozwojem i popularyzacją.

## Metodyki i procesy programowe

* Przedstawione do tej pory modele wytwarzania (np. kaskadowy, przyrostowy) miały ogólniejszy charakter
* Istnieją jednak bardziej szczegółowe wskazówki co do realizacji projektu lub/i zarządzania nim - metodyki
* Metodyki na ogół dokładnie precyzują zadania/czynności, praktyki, produkty i role ludzi
* Powyższe elementy wchodzą w skład opisu całego procesu realizacji projektu informatycznego

W metodykach stosuje się też czasem pojęcie procesu programowego, czyli procesu, w którym poza poszczególnymi fazami zdefiniowane są jego podstawowe składowe takie jak konkretne czynności do wykonania, dobre praktyki związane z tymi czynnościami np. sposób zapewniania jakości, jakie powinny powstać produkty(artefakty, dokumentacja kodu źródłowego, pliki konfiguracyjne, przypadki testowe, kod źródłowy), role członków zespołu i związane z nimi zakresy obowiązków.

## Działania w projekcie informatycznym, elementy procesu w metodyce

* Zadania techniczne, m.in.
* inżynieria wymagań
* projektowanie
* implementacja
* testowanie
* wprowadzanie zmian / utrzymanie
* wybór narzędzi i środowiska wytwórczego
* Zadania zarządcze, np.
* planowanie
* zarządzanie wymaganiami
* zarządzanie budżetem/finansami
* komunikacja w projekcie
* zarządzanie ludźmi (doborem, motywowaniem, przydziałem zadań, ...)
* zapewnianie jakości
* ocena (postępów projektu i zgodności z planem, zaawansowania, testowania, zarządzania,...)
* współpraca z otoczeniem projektu: klientami, własną firmą, związkami zawodowymi,...


Proces określa Co jest wykonywane, przez Kogo, Kiedy i Jak, oraz jakie są tego Produkty

* Co – czynności (activities)
* Kto – role w projekcie (roles)
* Kiedy – wskazania kolejności, następstw przyczynowo skutkowych dla czynności
* Jak - towarzyszące im praktyki (practices, guidelines)
* Produkty - artefakty (artefacts)

## Kategorie metodyk

* Wytwórcze (Software Development Methodology)
* Zwykle bazują na określonym modelu wytwarzania lub kombinacji modeli
* Konkretyzują zadania, produkty, role, praktyki
* Koncentrują się na działaniach deweloperskich (programowanie, testowanie, analiza etc.)…
* … Siłą rzeczy zawierają jednak również zagadnienia zarządcze, menedżerskie (planowanie, kontrola jakości, zarządzanie ryzykiem etc.) – w mniejszym lub większym zakresie
* Zarządzania (Project Management Methodology)
* Punkt widzenia menedżerski, zarządzanie przedsięwzięciem
* W znacznej mierze w oderwaniu od konkretnych praktyk deweloperskich
* Często metodyka uniwersalna tzn. dotycząca nie tylko do projektów informatycznych albo adaptowana do dziedziny oprogramowania

Jak metodyki wytwórcze mają się do modeli cyklu życia? Ich użycia na ogół bazują na jakimś modelu albo ich kombinacji. Kkonkretyzują zadania, produkty, rolę czy dobre praktyki. Opisują głównie proces z punktu widzenia deweloperów, uczestników projektu, testerów, analityków. Natomiast z uwagi na to, że w projekcie informatycznym należy uwzględniać elementy zarządcze czy zapewniania jakości, dodano również zagadnienia zarządcze i managerskie.

Analogicznie w metodykach zarządzania, które opisują realizację projektu z punktu menedżerskiego, dodano zagadnienia techniczne związane z wytwarzaniem oprogramowania. Dlatego kategorie te czasami trudno rozgraniczyć.

## Metodyki wytwarzania

* Występuje powszechnie stosowany podział na:
* Metodyki sterowane planem / zdyscyplinowane
* Metodyki zwinne / lekkie
* Metodyki sterowane planem
* Oparte na planowaniu i zarządzaniu
* Przeznaczone dla dużych projektów realizowanych przez większe zespoły
* Precyzyjnie zdefiniowane procesy, z możliwością adaptacji („przykrajania”)
* Zwiększone gwarancje jakościowe
* Nie oznacza to użycia tylko modelu kaskadowego
* Metodyki zwinne
* Nastawione na zmiany i adaptację do zmian
* Przeznaczone dla mniejszych projektów i zespołów
* Procesy „lekkie”, relatywnie mniejsza liczba działań i produktów
* Dla projektów, które nie wiążą się z zastosowaniami krytycznymi (safety-critical, mission-critical), za to mogą znacznie ewoluować

## Rational Unified Process (RUP)

* Przykład metodyki zdyscyplinowanej
* Opracowany przez firmę Rational (obecnie część IBM) znaną z różnych osiągnięć w IO (UML, pakiety narzędzi)
* Rozbudowana metodyka (szerokie pokrycie zadań, praktyk, ról) udostępniona do „przykrajania” (ang. tailoring)
* Wytwarzanie iteracyjne, oparte na analizie ryzyka
* Wykorzystanie modeli wizualnych, narzędzi, architektur i komponentów


Po lewej stronie są wypisane dyscypliny. Można powiedzieć, że są to pewne obszary inżynierii oprogramowania, aczkolwiek są tam też obszary “tła”, np. zarządzanie konfiguracją i zmianą, utrzymanie środowiska, zarządzanie całym projektem. Kolorowe wykresy pokazują jaka jest intensywność działań w ramach poszczególnych faz projektu. Celem fazy inception jest zrozumienie i uchwycenie kluczowych wymagań. Elaboration to upewnienie się, że architektura i technologie wybrane do realizacji tego projektu spełnią swoje zadanie. Construction to zaimplementowanie produktu. Transition to wdrożenie.

Metodyka czerpie z modelu kaskadowego, jednak poszczególne etapy wykorzystują podejście iteracyjne w tym model spiralny, przyrostowy i ewolucyjny. Celem poszczególnych faz jest minimalizacja danego ryzyka.


* Z czasem powstały liczne „odmiany” RUP ukierunkowane na różne typy projektów / obszary zastosowań np.
* Enterprise Unified Process
* Open Unified Process
* Agile Unified Process
* RUP for Service Oriented Modeling and Architecture
* Dostępność narzędzi do definiowania nowych „odmian” oraz do „przykrajania” do własnych potrzeb
* Rational Method Composer
* Eclipse Process Framework

### Inne metodyki zdyscyplinowane

* Microsoft Solution Framework (MSF)
* Microsoft, nastawienie na wykorzystanie narzędzi MS (Visual Studio Team Server)
* Podejście iteracyjne z elementami cyklu spiralnego, choć wyróżnione pewne fazy (analogicznie jak w RUP)
* Personal Software Process (PSP)
* Software Engineering Institute
* Sformalizowany, mocno oparty na metrykach
* Rejestrowanie czasu, zadań, defektów itp.
* Samodoskonalenie
* Team Software Process (TSP)
* Część „zespołowa” oparta na podstawie indywidualnej (PSP)
* Organizacja zespołu i projektu
* Planowanie i koordynacja prac

## Podejście zwinne (agile development)

* Podejście będące pewnego rodzaju reakcją na mocno sformalizowane, sterowane planem metodyki IO (które z kolei wynikały z potrzeby uporządkowania procesu i uzyskania jego powtarzalności)
* Agile Manifesto (2001):
* Individuals and interactions over processes and tools
* Working software over comprehensive documentation
* Customer collaboration over contract negotiation
* Responding to change over following a plan

### Cechy podejścia agile

* Wiele konkretnych metodyk definiujących zadania, produkty, dobre praktyki m.in.:
* Scrum
* eXtreme Programming
* Kanban
* Feature Driven Development

* Wspólne mianowniki:
* wytwarzanie iteracyjne, w bardzo małych przyrostach
* praca zespołowa z intensywną współpracą
* nastawienie na bliska współpracę z klientem i uwzględnianie na bieżąco jego postulatów
* dostosowywanie procesu i produktu do potrzeb (agility, adaptability)
* „agile mindset”

* Nie oznacza działania bez planu i celu czy bałaganu (typu cowboy coding)
* ...choć bywa, że bałaganiarze chętnie „podczepiają się” pod szyld Agile
* konieczne jest stosowanie wielu praktyk deweloperskich i intensywnej komunikacji, żeby osiągnąć sensowny rezultat przy braku dokumentacji i ciągłych zmianach
* „Coś za coś” np.
* Nie dokumentujemy szczegółowo wymagań, polegamy na komunikacji z klientem i demonstrowaniu mu kolejnych wersji -> trzeba się nastawić na liczne zmiany w kodzie
* Nie robimy formalnego projektu systemu -> trudniejsze będzie utrzymanie, prawdopodobna potrzeba restrukturyzacji
* Nie ma kierownika, który rozdziela zadania -> członkowie zespołu muszą mieć większą samomotywację i odpowiedzialność
* Obserwowalne zjawisko - łączenie elementów agile i elementów z innych metodyk (np. development w oparciu o agile, ale dodatkowe mechanizmy zarządzania „wyżej” plus rozbudowana inżynieria wymagań)

## Scrum

* Najpopularniejsza obecnie metodyka zwinna
* Definiuje proces wytwarzania w krótkich iteracjach (tzw. Sprintach) oraz role zespołu i sposoby komunikacji
* Względnie mało mówi o praktykach wytwarzania i zapewniania jakości, technice pracy, produktach
* Wymagania reprezentowane w formie bardzo ogólnej i zgrupowane w rejestrach
* Product Backlog
* Sprint Backlog


Product Backlog (rejestr produktu) - reprezentowane w uproszczonej postaci wymagania opatrzone priorytetami.

Sprint Backlog (rejestr sprintu) - wymagania przydzielone do danego sprintu, są rozbijane na mniejsze funkcjonalności.

Sprint - podczas sprintu zespół zajmuje się implementacją funckjonalności z rejestru sprintu

Codziennie organizowane jest krótkie spotkanie, podczas którego każdy uczestnik mówi o tym co zrobił od ostatniego spotkania, czy miał jakieś problemy i co planuje zrobić do następnego spotkania.

Wykres pracochłonności w metodyce Scrum

## Extreme programming

* Pierwsza metodyka zwinna szerzej spopularyzowana
* W mniejszym stopniu definiuje proces wytwarzania – postuluje krótkie iteracje
* Zawiera za to szereg praktyk dotyczących różnych obszarów inżynierskich np.
* Ciągła integracja
* Test-driven development
* Gra planistyczna – „negocjacje” z klientem
* Nacisk na prostotę projektu
* Nacisk na refaktoryzację

# Wykład 14 Metodyki wytwarzania - Zarządzanie projektem 19.01.

Metodyki zarządcze - zarządzanie projektami
- zarządzanie to ogół działań skierowanych na to, żeby projekt osiągnął sukces (czyli osiągnął założony cel - zakres, wymagania; zmieścił się w budżecie i w czasie; jest dobrej jakości - określone funkcjonalności oczekiwane przez klienta)
- planowanie, nadzór, koordynacja, komunikacja, zasoby, rozwiązywaine problemów

### Zarządzanie (opracowanie na podstawie metodyki PMBOK + adaptacje):
- zakresem / udziałowcami (ANALIZA wykład 6-7, inżynierowie wymagań)
- identyfikacja udziałowców i wydobycie wymagań;
- utrzymywanie zaangażowania udziałowców i komunikacja z nimi;
- ustalenie i weryfikacja zakresu (systemu, usług);
- reagowanie na zmiany zakresu;
- zapobieganie "rozpełzaniu zakresu" (scope creep) (jak klient sobie wyobrazi nie wiadomo co i co chwilę będzie przychodził, żeby coś dodać do zadań i poprawić)

zakres musi być przełożony na podzadania
- czasem
- identyfikacja zadań i wzajemnych powiązań (coś się kończy, żeby zacząć mogło się coś);
- oszacowanie czasu dla poszczególnych zadań, przygotowanie harmonogramu (żeby nie było, że się nie wyrobimy w czasie albo że na prostsze zadania jest więcej czasu) - tutaj fajnie zrobić sobie diagramy (Gantta, PERT) z uwzględnieniem powiązań i ustalić punkty kontrolne (Milestones);
- nadzór nad realizacja harmonogramu, reakcja na zmiany / problemy (zmiany w zadaniach, opóźnienia)
- kosztami
- identyfikacja zasobów (ludzie, narzędzia - licencje itp., materiały);
- koszty zasobów (również pośrednich - ZUS, szkolenia);
- odwzorowanie kosztów na zadania, etapy projektu, harmonogram (bo klient może płacić ratami - transzami albo za zrobioną pracę, a nie całą sumę od razu);
- nadzorowanie budżetu, kontrola wydatków (reagowanie na sytuacje - spalanie kompa itp.)
- ludźmi / zespołem
- organizacja zespołu (struktura zeapołu, podział ról i odpowiedzialności, sposoby komunikacji - ustna, czy gdzieś indziej);
- dobór ludzi do zespołu (kompetencje, profil osobowościowy - czy będzie pasować do zespołu, umiejętności miękkie) - rekrutacja, polecenie;
- budowa zespołu (zasady współpracy - komunikacja, rozliczanie z pracy; wartości - czy się wywiązują z zadań, czy tylko bajerują klienta - i praktyki;
- atmosfera - czy się czują dobrze ludzie);
- motywowanie - stymulowanie kreatywności, zależy od osoby (pieniądze, pochwałą);
- ocena - jak osoba się sprawuje
- komunikacją
- przygotowanie kanałów komunikacyjnych (narzędzia i technologie - repozytoria;
- procedury - kto co robi); zapewnienie dostępu do informacji, dystrybucja;
- raportowanie - postęp prac; zgłaszanie problemów
- konfiguracją (nadzór nad zasobami i produktami) - UTRZYMANIE OPROGRAMOWANIA wykład 12
- kod źródłowy;
- przypadki testowe;
- wymagania;
- umowy;
- narzędzia
(wszystko się musi zgadzać, że konkretną wersję kodu źródłowego testuje się dedykowanym testem; kod odpowiada wymaganiom)
- zmianą (zgłaszanie, rozpatrywanie i śledzenie zmian w trakcie trwania projektu)
- nowe wymagania;
- defekty (kierownik powinien zarządzić, kto ma wprowadzać zmiany, kto mm o tym decydować i zatwierdzać )
- jakością
- planowanie jakości (standardy- jakość kodu, interfejs; cele i miary ich osiągnięcia);
- zapewnienie jakości (plan i realizacja - testowanie; audyty);
- kontrola jakości (przeglądy i inspekcje; próbkowanie; analiza przyczyn; zmiany w procesie) - błędy programisty, komunikacja (wtedy zmiany w kolejnej iteracji projektu)
- ryzykiem
- Ryzyko - szansa wystąpnienia niepożądanego zdarzenia o negatywnych konsekwencjach
- Zarządzanie ryzykiem - proaktywne przewidywanie, zapobieganie lub ograniczanie konsekwencji
- Proces (identyfikacja ryzyk - co może pójść źle - technologie nie wystarczają, tracimy pracowników - prototypy; oszacowanie ryzyka - prawdopodobieństwo i konsekwencje; przeciwdziałanie)

Ryzyko może też być pozytywne (jakaś szansa, luka u innych osób)

Metodyki zwinne często nie analizują budżetu ani doboru ludzi do zespołu i ich oceny

Manager nie robi tego wszystkiego sam, ale podejmuje za to odpowiedzialność

### Metodyki zarządcze:

#### PMBOK

* Project Management Body of Knowledge (obecnie 6 ed.)
* Standard / metodyka zarządzania firmowana przez Project Management Institute
* Certyfikacja (np. Project Management Professional)
* Przedstawia procesy zarządcze z 10 obszarów wiedzy (w większości zgodnych z przedstawianymi na poprzednich slajdach)
* Każdy proces opisuje w kategoriach:
* artefaktów wejściowych
* stosowanych w ramach procesu metod i narzędzi
* produktów procesu

#### PRINCE 2
* PRojects IN Controlled Environments 2
* Metodyka opracowana jako „standard” dla projektów informatycznych realizowanych na zlecenia rządowe w W. Brytanii
* Definiuje strukturę zarządzania projektem (komitet sterujący z reprezentantami klienta i dostawcy, kierownik projektu, kierownicy zespołów) i relacje między nimi
* Duże znaczenie przykłada do inicjacji projektu obejmującej wizję biznesową, planowanie projektu, planowanie jakości, mechanizmy kontroli
* Projekt dzielony na etapy (formalnie rozliczane)
* Znaczna ilość działań kontrolnych i projakościowych oraz związanej z tym dokumentacji

#### ITIL Information Technology Infrastructure Library

* Dotyczy gwarancji świadczenia usług IT dla biznesu (a więc niekoniecznie tworzenia nowych systemów - utrzymanie, hostowanie)
* Obejmuje 5 głównych obszarów:
1. ITIL Service Strategy - strategia
2. ITIL Service Design - projekt usług
3. ITIL Service Transition - wdrożenie
4. ITIL Service Operation - dostarczanie
5. ITIL Continual Service Improvement - ciągłe poprawianie jakości

* Dla poszczególnych obszarów definiuje procesy (jak będzie wyglądało zarządzanie dostępnością (uptime); czy musi być dostępny proces zarządzania incydentami), które organizacja powinna opracować i realizować dla sensownego świadczenia usług np.
* Service Design: AvailabilityManagement, Service Level Management, ISMS, ...
* Service Transition: Transitionplanningand support, Service assetand configurationmanagement, ...
* Service Operation: IncidentManagement, RequestFulfillment, ...

Mamy dowolność co do sposobu realizacji, ale ITIL narzuca, że proces ma być wdrożony.

### Podsumowanie - Metodyki

•Metodyki stanowią zwykle już całkiem precyzyjne opisy (kto, co, kiedy, jak...) niż modele i cykle wytwarzania
•Oczywiście można ściśle przestrzegać tych zaleceń, ale nie są one żadną świętością, ALE należy to robić świadomie!
–Choć oczywiście można zmienić tyle, że stosowanie metodyki traci sens;
•W ramach określonej metodyki nadal mamy pole manewru co do definicji zadań, produktów, harmonogramu, przypisania ról itp. i możemy uwzględnić specyfikę naszego projektu
–np. zamiast use-case’ow robimy szkice poszczególnych ekranów, łączymy testowanie integracyjne z systemowym, nie ma dedykowanej roli związanej z zapewnianiem jakości, lecz jest to częścią obowiązków kierownika projektu
•Często metodyki są od razu opracowane w takiej formie, żeby móc je „przykroić” do własnych potrzeb (np. RUP - wiele procesów i artefaktów, SCRUM - tylko kilka założeń)