Skrócony opis cyklu tworzenia oprogramowania w firmie UKT.

I. Wizja:
Do czego służy:
W tej fazie zbierane są podstawowe informacje dotyczące mającego powstać produktu. Staramy się zebrać możliwie dużą ilość informacji od klienta, pomagamy klientowi skrystalizować pomysły i ustalić wstępne zagrożenia. Gromadzimy ogólne informacje dotyczące środowiska pracy oprogramowania i w przybliżeniu szacujemy czas konieczny do jego wytworzenia. Faza wizji służy również zapoznaniu się klienta z nami, naszą firmą i naszym sposobem pracy.

Rezultat:
Faza wizji powinna być zamknięta dokumentem wizji (VIS), w którym w mniej lub bardziej uporządkowany sposób opisane będą podstawowe wymagania i oczekiwania dotyczące produktu. VIS powinien stanowić podstawę dla następnej fazy tworzenia, dla analizy. W tej fazie należy również ustalić orientacyjny koszt tworzonego oprogramowania oraz przybliżone terminy ukończenia poszczególnych modułów aplikacji.

II. Analiza
Do czego służy:
Analiza jest fazą, w której zbieramy wszystkie informacje konieczne do zbudowania produktu. Analitycy budują model, który jest czytelny zarówno dla klienta jak i dla architektów/programistów tworzących oprogramowanie.

Analiza składa się z kilku etapów:

1) Stworzenie słownika - budowana jest spójna i czytelna baza pojęć wykorzystywanych w systemie. Etap ten musi być wykonany ze szczególną uwagą ze względu na niejednoznaczność występującą w języku naturalnym. W skrócie chodzi o to, żeby osoby biorące udział w projekcie mówiły o tych samych rzeczach tymi samymi słowami. (np. Administrator może znaczyć tak informatyka zatrudnionego na stanowisku administratora w firmie X jak i osobę mającą najwyższe uprawnienia w budowanej aplikacji)

2) Modelowanie środowiska - ustalenie punktów łączących produkt ze środowiskiem w którym jest zanurzony. W etapie tym należy wyróżnić aktorów (np. Użytkownik, Firma Zewnętrzna, System SAP) oraz granice działania aplikacji (Z aplikacji mogą korzystać tylko pracownicy firmy X i kierownicy firmy Y itp.)

3) Wyodrębnienie przypadków użycia - w przypadku średnich i dużych systemów należy zastanowić się nad koniecznością zastosowania diagramów przypadków użycia, które będą stanowić "mapę" funkcjonalności implementowanych w oprogramowaniu

4) Wyodrębnienie wymagań niefunkcjonalnych - ustalenie i opisanie wymagań klienta co do tworzonego oprogramowania, ale niezwiązanych z konkretnymi funkcjonalnościami. Do takich wymagań należy np. maksymalne obciążenie systemu, dzienny przyrost ilości rekordów bazy danych, kompatybilność z systemem Windows czy też współpraca z już istniejącym oprogramowaniem.

5) Wyodrębnienie wymagań funkcjonalnych - ustalenie i opisanie poszczególnych funkcjonalności jakie mają być zaimplementowane w tworzonym oprogramowaniu. (Np. opis dokładny opis bazy klientów, sposób logowania do systemu, itp.) Zarówno wymagania funkcjonalne jak i niefunkcjonalne powinny zawierać informacje o ryzyku niepowodzenia implementacji jak i o ważności danego wymagania.

Równolegle z tworzeniem specyfikacji powstają prototypy, które stanowią przykłady "ekranów" tworzonego oprogramowania. Pod koniec tej fazy można dokładnie już określić koszt aplikacji oraz czas jej tworzenia.

Rezultat:
W wyniku fazy analizy otrzymujemy dokument specyfikacji (SPEC) i prototypy (PROTO) które stanowić bazę dla dalszych prac nad oprogramowaniem. Dokument SPEC powinien być jak najpełniejszy. Wszelkie zmiany w specyfikacji w momencie rozpoczęcia kodowania znacznie zwiększają ryzyko niepowodzenia projektu. Warto również przygotować terminarz zawierający daty rozpoczęcia i zakończenia kodowania poszczególnych modułów aplikacji.

III. Kodowanie/Testowanie
Do czego służy:
Służy zamianie wymagań opisanych w fazie analizy na język programowania.
Kodowanie jest najbardziej czasochłonną i ryzykowną częścią procesu tworzenia oprogramowania, jednakże ryzyko to można zminimalizować poprzez rzetelne i dokładne przeprowadzenie pozostałych faz. Kodowanie powinno być przeprowadzane równolegle z testami nowo utworzonych modułów, po to by jak najwcześniej wykryć i poprawić pojawiające się błędy. Bazą do określania bezbłędności działania oprogramowania jest specyfikacja, prototypy i zdrowy rozsądek.

Rezultat:
Efektem działania tej fazy powinno być oprogramowanie działające tak jak opisano to w SPEC.

IV. Instalacja
Do czego służy:
Jest to zanurzenie aplikacji w jej docelowym środowisku

Rezultat:
Uzyskanie oprogramowania spełniającego wymagania zamówione przez klienta.