Software Development Life Cycle – fazy i modele SDLC

Tworzenie i rozwój oprogramowania przebiega zawsze w określonym porządku. Systematyczny proces jego tworzenia, czy inaczej cykl życia oprogramowania (SDLC), zapewnia przejrzystość każdej fazy cyklu i projektu jako całości. Ramy czasowe szczegółowego planu umożliwiają płynność, analizę, kontrolę i ulepszania procesu rozwoju.

Software Development Life Cycle – co to jest?

Cykl życia oprogramowania, czyli Software Development Life Cycle to proces stosowany w branży IT do projektowania oprogramowania wysokiej jakości. Ilustruje, jak planować, budować, testować i utrzymywać dane oprogramowanie. Daje skalowalną widoczność projektu dla wszystkich zaangażowanych w proces jego rozwoju. Zwykle dzieli się na 5–8 etapów. Zdarza się je łączyć, dzielić lub pomijać, w zależności od zakresu projektu.

Etapy dzielą proces rozwoju na zadania, które można przypisać, ukończyć i zmierzyć. W niniejszym artykule zdecydowaliśmy się opisać cykl siedmioetapowy.

Software Development Life Cycle w 7 etapach:

1. Planowanie i analiza wymagań

Etap ten ma określić ogólne warunki projektu i wymagania dotyczące zamówienia. Prowadzą go liderzy i seniorzy zespołu przy udziale interesariuszy i ekspertów branżowych. Planowanie można podzielić na badania technologiczne, marketingowe i analizę korzyści. Obejmuje szacunek kosztów, tworzenie harmonogramu i zespołu projektowego.

Zespół otrzymuje zadanie zdefiniowania czasu realizacji poszczególnych zadań i potrzebnych zasobów. Analiza wymagań na tym etapie ma zapewnić jakość i rozpoznanie ewentualnego ryzyka. Etap ten może zawierać informacje zwrotne od potencjalnych klientów, programistów czy ekspertów dziedziny. 

2. Studium wykonalności

Po zebraniu wymagań przeprowadza się analizę wykonalności rozwoju produktu w różnych jego obszarach. Na tym etapie definiuje się i dokumentuje potrzeby oprogramowania. Dokument „Specyfikacja wymagań oprogramowania” (SRS) ma dowieść, że wymagania projektowe odpowiadają użytkownikowi końcowemu w obszarach ekonomicznym, prawnym, operacyjnym, technicznym i czasowym. 

3. Projektowanie (ew. prototypowanie)

W oparciu o wymagania określone w SRS, proponuje się więcej niż jedno podejście projektowe i zapisuje w DDS – specyfikacji dokumentu projektowego. Zawiera on też parametry, jak ocena ryzyka, wytrzymałość produktu, modułowość projektu, budżet i ramy czasowe, a także architekturę systemu i projekt interfejsu użytkownika oraz kwestie bezpieczeństwa. Na ich podstawie wybiera się najlepsze podejście projektowe.

Pomocne może być opracowywanie dokumentów: HLD – projekt wysokiego poziomu oraz LLD – projekt niskiego poziomu. Jedną z wczesnych wersji projektu jest prototypowanie. Daje ono podstawowe pojęcie o tym, jak aplikacja wygląda i działa. Pozwala na weryfikację niektórych pomysłów i założeń przed faktyczną implementacją. Dobrze wykonana faza prototypowania przynosi korzyści, które pomagają w podejmowaniu dalszych decyzji. 

4. Kodowanie

Etap ten rozpoczyna właściwy rozwój i powstanie produktu. To najdłuższa faza cyklu, podczas której zadania są dzielone na jednostki lub moduły. Zadania są przydzielane członkom zespołu zgodnie z ich specjalizacją.

Programiści piszą kod zgodnie ze zdefiniowanymi wcześniej wytycznymi dotyczącymi kodowania i jego implementacji. Korzystają przy tym z zestawu przydatnych programów scalonych w jeden interfejs graficzny (IDE – Integrated Development Environment, czyli Zintegrowane Środowisko Programistyczne), dostarczających szereg  narzędzi ułatwiających zarówno integrację komponentów w bardziej złożonych aplikacjach, jak i samo pisanie poprawnego kodu.

Na tym etapie warto tworzyć dokumentację kodu z instrukcjami dla innych programistów, a także przewodnik po funkcjach aplikacji dla użytkowników końcowych. Wyjaśniają one, dlaczego zastosowano daną procedurę. Może to być krótki przewodnik po funkcjach aplikacji wyświetlanych przy pierwszym uruchomieniu. Końcowym efektem tej fazy jest działające oprogramowanie i udokumentowany kod źródłowy.

5. Testowanie 

Etap ten następuje po udostępnieniu modułów do testowania. Na poziomie podstawowym oznacza to testowanie systemu lub oprogramowania w systemie operacyjnym, który będzie go obsługiwał, na przykład Linux lub Windows.

Testowanie ma na celu sprawdzenie, czy oprogramowanie działa zgodnie z wymaganiami opisanymi w SRS (funkcjonalność), jak działa pod obciążeniem – szybkość, responsywność i stabilność (wydajność), czy każdy moduł działa osobno (jednostkowe), a poszczególne współpracują ze sobą (integracyjne), czy jest intuicyjne, proste w użyciu i jasne dla użytkownika (użyteczności) oraz bezpieczeństwa systemu.

Błędy znalezione przez zespół testujący przekazuje się programistom do naprawy, po czym odsyła się do kontroli jakości do ponownego przetestowania produktu. Proces trwa tak długo, aż będzie on wolny od błędów, stabilny i działał zgodnie z potrzebami biznesowymi. Następnie programiści testują zdolność nowego systemu do komunikowania się z innym oprogramowaniem, z którego może korzystać klient. Testy integracyjne przeprowadzane są najpierw w systemie wewnętrznym, a następnie w systemach klienta w rundach testów alfa i beta.

6. Wdrażanie (instalacja)

Na tym etapie celem jest wdrożenie oprogramowania w środowisku produkcyjnym, aby użytkownik mógł rozpocząć korzystanie z produktu. Wiele organizacji decyduje się na przenoszenie produktu przez różne środowiska wdrożeniowe, jak środowisko testowe lub tymczasowe, zanim produkt zostanie ostatecznie zweryfikowany i zaakceptowany przez klienta.

Na podstawie informacji zwrotnych od kierownika projektu ostateczna wersja oprogramowania jest wydawana i sprawdzana pod kątem ewentualnych problemów z wdrożeniem.

W przypadku dużych projektów twórca może oferować programy szkoleniowe lub pomoc integracyjną, aby klienci mogli rozpocząć korzystanie z nowego systemu. Sam kod nie jest korygowany podczas wdrażania, chyba że zostanie wykryty poważny problem z oprogramowaniem.

7. Utrzymanie (eksploatacja)

Celem tej fazy jest upewnienie się, że system działa zgodnie ze specyfikacją opracowaną w pierwszej fazie. Użytkownicy końcowi powiadamiają o błędach, niewychwyconych podczas testowania. Może to generować nowe etapy rozwoju.

Cykl życia w rzeczywistości się nie kończy, bo oprogramowanie musi być stale monitorowane, konserwowane, regularnie aktualizowane wraz ze zmieniającymi się w czasie wymaganiami i potrzebami biznesowymi.

Popularne metody i metodologie SDLC:

Waterfall

Waterfall to jedna ze starszych metodologii SDLC. Jest jasna i prosta w zarządzaniu. Proces tworzenia oprogramowania jest dzielony na fazy, a wynik jednej stanowi dane wejściowe dla następnej. Fazy mogą się też lekko zazębiać, np. testowanie może się rozpocząć, gdy kod jeszcze nie jest dokończony.

Zaletą Waterfall jest to, że każdą fazę można ocenić pod kątem ciągłości i wykonalności przed krokiem dalej, wadą zaś – brak odwrotu. Wymaga obszernej dokumentacji, ale dzięki temu fazy jasno dokumentują, co należy wykonać w kolejnych.

Iteracyjny

Metoda ta przebiega zgodnie z etapami modelu kaskadowego, ale z powtarzalnymi iteracjami. Znana jest też jako model przyrostowy z uwagi na to, że produkt końcowy testuje się na mniejszych modułach podczas każdej iteracji.

Wszystkie te kroki podlegają etapom SDLC w powtarzalnych cyklach, a każda wersja dodaje więcej funkcji, aż wszystkie wymagania zostaną spełnione. Pozwala to na bieżąco identyfikować błędy, w efekcie daje wydajny produkt końcowy.

Agile

Metoda zwinna zakłada, że projekt jest traktowany indywidualnie i dostosowany do wymagań użytkownika. Stawia na jego wrażenia i satysfakcję, przy czym ważne jest angażowanie interesariuszy i ich opinie w trakcie procesu.

Podczas cyklu SDLC podejście iteracyjne umożliwia ciągłą interakcję między programowaniem a testowaniem. Dzięki temu drobne problemy rozwiązuje na bieżąco, zanim przekształcą się w znaczące. Kompilacje działającego produktu dostarcza się po każdej iteracji. Metoda ta wymaga silnego zespołu z doskonałą komunikacją. W jej ramach stosuje się także Scruma – na ogół w bardziej złożonych projektach programistycznych.

V-model

W tej metodzie rozwoju produktu bazuje się na zasadach LEAN, dla których priorytetem jest eliminacja marnotrawstwa jako sposób tworzenia większej wartości dla klienta. V wskazuje na proces podobny do wodospadu –  przebiega sekwencyjnie w kształcie tej litery.

Metodę tę cechuje faza testowania każdego etapu cyklu. Jest też znany jako model weryfikacji (ocena fazy rozwoju produktu pod katem wymagań klienta) i walidacji (ocena oprogramowania po zakończeniu fazy rozwoju). Faza weryfikacji stoi po jednej stronie V, a walidacji po drugiej. Obie łączy faza kodowania. Ten model jest przydatny, pod warunkiem, że projekt nie ma nieznanych wymagań.

Spiralny

Model spiralny czerpie wskazówkę z modelu iteracyjnego i jego powtórzeń. Projekt przechodzi przez cztery fazy (planowanie, analiza ryzyka, inżynieria i ocena) w kółko „po spirali”, aż do zakończenia. W ten sposób umożliwia programistom wiele rund doskonalenia i tworzenie spersonalizowanych produktów z uwzględnieniem opinii użytkowników na wczesnym etapie projektu.

Jego zaletą jest zarządzanie ryzykiem. Każda iteracja zaczyna się od przyjrzenia się potencjalnym zagrożeniom i ustalenie, jak ich unikać lub ograniczać. Rozwój spiralny może wybierać różne modele dla każdego etapu rozwoju. Spirala jest zwykle stosowana w dużych projektach.

DevOps

Jest nowością na scenie SDLC. Wyłonił się on z dwóch trendów: praktyk zwinnych oraz nowego modelu biznesowego. Polega na ścisłej współpracy zespołu programistów z użytkownikami na wszystkich etapach procesu – z czasem jako jeden zespół.

Celem tej metody jest przyspieszenie procesu i wdrażanie niezawodnych produktów wyższej jakości. Dyscyplina, częste informacje zwrotne w procesie projektowania i wdrażania, doskonalenie oraz automatyzacja ręcznych procesów rozwoju to istotne cechy tej metody. Stawia na szybką komunikację na wysokim poziomie. DevOps to nie tylko model pracy, a filozofia wymagająca znaczących zmian w sposobie myślenia i kulturze organizacji.

Podsumowanie

Nie ma jednej uniwersalnej metody ani lepszej od innych. Każdy z modeli SDLC może odpowiadać różnym projektom, środowiskom i wymaganiom. Ważne, czy projekt jest prosty, z określonymi wymaganiami, których nie trzeba zmieniać, czy jest rozbudowany i będzie się składał z wielu komponentów, ale też szerszego zespołu. Aby wybrać właściwy, należy znać je wszystkie, by ocenić wymagania klientów i dostosować do potrzeb własnej organizacji.

Jeśli interesują Was metody zarządzania projektami IT – więcej szczegółowych informacji znajdziecie w naszych artykułach na temat metod tradycyjnych (jak Waterfall) i zwinnych (jak Agile).