Przewodnik założyciela po cyklu życia produktu programistycznego

Za wszystkimi udogodnieniami, z których korzystamy na co dzień, stoi złożone oprogramowanie. Weźmy choćby samochody autonomiczne, inteligentne domy czy funkcje rzeczywistości rozszerzonej wbudowane w okulary. Wszystkim tym zarządza skomplikowane oprogramowanie działające w tle.

Jednak niezależnie od tego, jak złożone jest oprogramowanie, musi być elastyczne, łatwe w utrzymaniu i rozszerzalne. Jak programiści to osiągają? Odpowiedź leży w starannym zaplanowaniu każdego kroku cyklu życia produktu programistycznego.

Zarys procesu wytwarzania oprogramowania to doskonały punkt wyjścia przy budowie produktu. W tym artykule omówimy pojęcie cyklu życia produktu programistycznego, jego fazy i stosowane w nim ogólne metodyki.

Czym jest cykl życia produktu programistycznego?

Cykl życia wytwarzania oprogramowania (SDLC) to seria kroków, które zespół programistyczny musi wykonać, by stworzyć i utrzymywać oprogramowanie.

Cykl życia produktu programistycznego zaczyna się od decyzji o stworzeniu oprogramowania, a kończy jego wycofaniem. Proces wytwarzania obejmuje 6 kluczowych kroków. Każdy z nich składa się z kilku etapów. W istocie SDLC to mapa drogowa tworzenia produktów cyfrowych.

Skąd wziął się cykl życia produktu programistycznego

SDLC zaczął się w latach 60. jako „cykl życia rozwoju systemów”. Jak wyjaśnia Jeffrey Elliott w swojej książce Global Information Technology for Business. Stratedzy biznesowi z dużych korporacji opracowali ten model, by pomóc zarządzać złożonymi systemami biznesowymi wymagającymi przetwarzania i analizy dużych ilości danych.

Z czasem warianty tego podejścia zaczęto stosować do tworzenia produktów sprzętowych i programowych oraz innych złożonych projektów.

Dlaczego SDLC jest ważny?

Od przekroczonych terminów po pochopne decyzje i daremne próby opanowania projektu - źle zaplanowane projekty programistyczne mają skłonność do wymykania się spod kontroli. Z drugiej strony, mając zamierzony cykl dostarczania oprogramowania, firmy mogą liczyć na przewidywalne wytwarzanie produktu. Dla programistów oznacza to rozumienie, co robią teraz i co wydarzy się dalej. 

Oto najważniejsze korzyści z cyklu życia produktu w oprogramowaniu:

• zapewnia przejrzystość stronom zaangażowanym w wytwarzanie oprogramowania;
• pozwala właścicielom firm zachować kontrolę nad projektem;
• daje przewidywalność wyników przez cały proces wytwarzania oprogramowania;
• minimalizuje ryzyko, na przykład przekroczenia budżetu lub terminów;
• gwarantuje, że proces wytwarzania trwa aż do spełnienia wszystkich oczekiwań.

Dlatego każdy projekt musi mieć zaplanowany cykl życia produktu programistycznego - tylko tak można zapewnić, że powstałe oprogramowanie spełni wymagania zarówno właścicieli biznesu, jak i użytkowników końcowych.

Jak działa SDLC

SDLC obniża koszt wytwarzania oprogramowania, jednocześnie podnosząc jakość i skracając czas produkcji. Osiąga te pozornie rozbieżne cele, trzymając się planu, który eliminuje typowe pułapki projektów programistycznych. Plan ten zaczyna się od oceny istniejących systemów pod kątem braków.

Następnie określa wymagania nowego systemu. Potem buduje oprogramowanie przez fazy analizy, planowania, projektowania, wytwarzania, testowania i wdrożenia. Przewidując kosztowne błędy, takie jak brak informacji zwrotnej od użytkownika końcowego lub klienta, SLDC pozwala uniknąć zbędnych przeróbek i poprawek po fakcie.

Warto też wiedzieć, że dużo uwagi poświęca się fazie testów. Ponieważ SDLC jest metodyką iteracyjną, w każdym cyklu trzeba zadbać o jakość kodu. Wiele organizacji wkłada w testy niewiele wysiłku, choć mocniejszy nacisk na testy potrafi oszczędzić im mnóstwo przeróbek, czasu i pieniędzy. Bądź sprytny i pisz właściwe rodzaje testów.

Założyciele produktu powinni upewnić się, że ich kadra C-level ma świadomość tych elementów. Jeśli nie, zadbaj o to, jak znaleźć i zatrudnić najlepszego CTO dla swojego startupu.

Fazy cyklu życia produktu programistycznego

Powstało kilka wersji cyklu życia wytwarzania oprogramowania. Guru99 na przykład stosuje siedmioetapową strukturę SDLC , która rozdziela zbieranie wymagań i studium wykonalności na dwa osobne etapy. Inne organizacje, jak Software Testing Help, łączą te dwa kroki w jedną fazę: „zbieranie i analiza wymagań”.

Przeanalizowaliśmy wiele wariantów modeli cyklu życia wytwarzania oprogramowania. Poniższa sześcioetapowa struktura wydaje się najbardziej płynna i efektywna.

I. Badania i planowanie

Cel: zebranie i udokumentowanie wymagań biznesowych

Na tym etapie zbierane są od klienta wszystkie niezbędne informacje, by rozwijać produkt zgodnie z jego oczekiwaniami. Wszelkie niejasności powinny zostać rozstrzygnięte właśnie tutaj.

Analitycy biznesowi i kierownik projektu umawiają spotkanie z założycielem, by zebrać wszystkie informacje: co klient chce zbudować, kto będzie użytkownikiem końcowym, jaki jest cel produktu. Zanim powstanie produkt, bardzo ważne jest zdobycie podstawowego zrozumienia lub wiedzy o nim.

Na przykład założyciel chce mieć aplikację obsługującą transakcje pieniężne. W takim przypadku wymagania powinny być jasne: jakie transakcje będą realizowane, w jaki sposób, w jakiej walucie itd.

Po zebraniu wymagań przeprowadza się analizę, która weryfikuje wykonalność produktu. W razie niejasności umawiana jest rozmowa w celu dalszej dyskusji.

Inne kwestie, które warto omówić, to:

• 3 najważniejsze problemy, które może rozwiązać Twój nowy pomysł na produkt
• Wielkość i dostępność możliwych rynków
• Konkurenci bezpośredni i pośredni
• Wstępny model cenowy (przetestuj go)
• Wstępna mapa drogowa produktu i podstawowy budżet na budowę MVP

Gdy wymagania są jasno zrozumiane, powstaje dokument SRS (specyfikacja wymagań oprogramowania). Musi być w pełni zrozumiały dla programistów, a także przejrzany przez założyciela lub kadrę C-level do dalszego wykorzystania.

Zajrzyj do naszego artykułu Digital Product Development: Step-By-Step Guide , jeśli chcesz dowiedzieć się więcej.

II. Projektowanie i prototypowanie

Cel: projektanci UX-UI przekładają wymagania na projekt

Faza projektowania jest niezbędnym wstępem do głównej fazy wytwarzania.

Programiści najpierw szkicują szczegóły całej aplikacji, a także konkretne elementy, takie jak:

• Interfejsy użytkownika
• Interfejsy systemowe
• Sieć i wymagania sieciowe
• Baza danych

Zwykle przekształcają tworzony dokument SRS w bardziej logiczną strukturę, którą można następnie zaimplementować w języku programowania. Powstają plany utrzymania, szkoleń i eksploatacji, by programiści wiedzieli, co mają robić na każdym kolejnym etapie cyklu.

Po zakończeniu menedżerowie przygotowują dokument projektowy, do którego będzie się sięgać w kolejnych fazach SDLC.

Dzięki prototypowi lub minimalnemu produktowi (MVP) możesz przełożyć wstępne badania na praktykę i sprawdzić, czy Twoje pomysły działają w realnym świecie. Obie opcje służą testowaniu, dzięki czemu możesz elastycznie dostosowywać projekt i oszczędnie gospodarować zasobami.

III. Wytwarzanie oprogramowania

Cel: stworzenie właściwego oprogramowania

Wytwarzanie oprogramowania to najbardziej czasochłonna faza cyklu życia produktu, ale jest bardziej przewidywalna niż faza projektowania. 

Korzystając z dokumentacji projektowej, programiści piszą kod komponentów. Zadania rozdziela się między członków zespołu zgodnie z ich obszarem ​​specjalizacji. Programiści oprogramowania klienckiego odpowiadają za interfejs i jego komunikację z serwerem. Administratorzy baz danych dodają do bazy potrzebne dane. 

Teoretycznie całe wcześniejsze planowanie i szkicowanie powinno sprawić, że sama faza wytwarzania będzie stosunkowo łatwa.

Programiści trzymają się wytycznych kodowania przyjętych w organizacji i korzystają z różnych narzędzi, takich jak kompilatory, debuggery i interpretery.

W zależności od wybranego języka programowania Twoi Ruby on Rails/

React Native/programiści React dobierają właściwy kod na podstawie specyfikacji i wymagań projektu.

Efektem tego etapu jest działający produkt i dokumentacja kodu źródłowego.

IV. Testowanie

Cel: upewnienie się, że oprogramowanie spełnia wymagania

Gdy zespół programistyczny skończy pisać oprogramowanie, do gry wchodzi zespół zapewnienia jakości (QA). Testuje on oprogramowanie, by zmierzyć jego jakość. Na tym etapie produkt przechodzi różne rodzaje testów:

• Testy funkcjonalne: sprawdzenie, czy oprogramowanie spełnia wymagania opisane w specyfikacji wymagań;
• Testy wydajnościowe: mają określić, jak oprogramowanie zachowuje się pod obciążeniem (szybkość, responsywność i stabilność);
• Testy jednostkowe: testowanie każdego komponentu z osobna. Jeśli któryś ma wadę, odpowiedzialni za niego programiści muszą wrócić i ją naprawić.
• Testy bezpieczeństwa: jak sama nazwa wskazuje, ten rodzaj testów ma zweryfikować bezpieczeństwo systemu;
• Testy użyteczności: ten rodzaj testów polega na sprawdzeniu elementów, z którymi styka się użytkownik, by ustalić, czy oprogramowanie jest intuicyjne, łatwe w użyciu i zrozumiałe.

Programiści naprawiają błędy wykryte w tej fazie, a zespół QA ponownie testuje oprogramowanie lub jego komponenty. Zapewnienie jakości to proces ciągły, który trwa, aż oprogramowanie będzie całkowicie wolne od błędów i spełni wymagania.

V. Wdrożenie

Cel: dostarczenie gotowego oprogramowania użytkownikom

Gdy testy wstępne pokażą, że oprogramowanie jest gotowe do dalszej pracy, trafia na produkcję. Ten krok obejmuje koordynację wydania produktu, by dostarczyć rozwiązanie użytkownikom końcowym w uporządkowany sposób.

Zobacz, co obejmuje orkiestracja wydania:

Konfiguracja serwera

Pierwsze, co trzeba zrobić, by oprogramowanie zadziałało, to przygotować miejsce, w którym będzie hostowane. Czy wybierzesz serwery lokalne, czy platformę chmurową - decyzję zostawiasz swojemu zespołowi. 

Budowa pipeline’u CI/CD

Cokolwiek tworzysz, warto podłączyć oprogramowanie do pipeline’u ciągłej integracji (CI) i ciągłego dostarczania (CD). Po wdrożeniu przyspiesza on wydawanie kolejnych buildów i ułatwia przyjmowanie zmian po starcie. Dodatkowo dobre praktyki CI/CD poprawiają utrzymywalność produktu, zamykając go w jednym pakiecie.

Ochrona oprogramowania przed awariami stron trzecich

Żadne oprogramowanie nie jest wolne od ryzyka. Integracje zewnętrzne - a nawet Twój dostawca chmury - mogą czasem mieć kłopoty, wystawiając system na awarie. Dlatego zespół powinien skonfigurować kopie zapasowe serwera już na etapie wdrożenia. 

Przygotowanie i wdrożenie planu wdrożenia

Orkiestracja wydania kręci się także wokół planu wdrożenia. Powstaje on na końcu procesu wytwórczego i określa, jak oprogramowanie ma być uruchamiane, kto odpowiada za jego wydanie i jak ma być później utrzymywane. 

VI. Utrzymanie i eksploatacja

Twój produkt został wydany. To początek eksploatacji i rutynowego utrzymania.

Choć następuje na końcu, utrzymanie jest jedną z najważniejszych faz wytwarzania oprogramowania. Musisz utrzymywać - albo zatrudnić kogoś do utrzymywania - swój produkt, by go ulepszać, aktualizować i utrzymywać w ruchu bez przestojów.

To zwykle moment, w którym podpisujesz umowę utrzymaniową ze swoim zespołem lub firmą zewnętrzną. Określasz w niej, które części produktu mają być wspierane, jakie są czynności utrzymaniowe, obowiązki i tak dalej.

Zgodnie ze standardem IEEE/ISO/IEC 14764-2006 wyróżnia się cztery rodzaje prac utrzymaniowych:

• Utrzymanie korekcyjne oprogramowania. Jeśli ktoś zauważy błąd w Twoim produkcie, jego naprawa należy do utrzymania korekcyjnego. Chodzi o działania podejmowane w odpowiedzi na wykryte wady oprogramowania.
• Utrzymanie prewencyjne oprogramowania. Tak jak wymieniasz olej w silniku, by zapobiec kłopotom, tak ten rodzaj usług obejmuje regularne przeglądy i poprawki, które pozwalają uniknąć błędów.
• Utrzymanie doskonalące oprogramowania. Po wdrożeniu oprogramowanie musi się rozwijać. Doskonalenie oznacza optymalizowanie, dopracowywanie i dodawanie nowych funkcji, by dawać użytkownikom najlepszą wersję produktu.
• Utrzymanie adaptacyjne oprogramowania. Przenosisz się do chmury? Reagujesz na zmienione zasady w zewnętrznych dodatkach, z których korzysta Twoje oprogramowanie? Ten rodzaj usług obejmuje wszystko, co trzeba zrobić, by dostosować produkt do zmian bez utraty jego wartości dla odbiorców.

Modele i metodyki

Model cyklu życia produktu programistycznego to opisowe przedstawienie cyklu wytwarzania oprogramowania. 

Uwaga! Modele SDLC mogą stosować różne podejścia, ale podstawowe kroki i czynności pozostają takie same we wszystkich.

Model kaskadowy

Model kaskadowy jest najstarszą z metodyk SDLC. Jest liniowy i prosty, a od zespołów wymaga pełnego zakończenia jednej fazy projektu przed przejściem do kolejnej.

Każdy etap ma osobny plan i korzysta z informacji z etapu poprzedniego, by uniknąć podobnych problemów (jeśli się pojawią). Model jest jednak wrażliwy na wczesne opóźnienia i może później sprawiać zespołom duże kłopoty.

Zalety modelu kaskadowego

• Model kaskadowy jest prosty, łatwy do zrozumienia, a wszystkie kroki wykonuje się po kolei.
• Wyniki każdego etapu są jasno określone, co nie prowadzi do złożoności i sprawia, że projekt łatwo się prowadzi.

Wady modelu kaskadowego

• Model kaskadowy jest czasochłonny i nie nadaje się do projektów krótkoterminowych, bo nowego etapu nie można zacząć przed zakończeniem bieżącego.
• Modelu kaskadowego nie da się zastosować w projektach o niejasnych lub stale zmieniających się wymaganiach, bo zakłada on, że wymagania będą jasne już na etapie ich zbierania i analizy, a każda późniejsza zmiana podniesie koszty, ponieważ zmiany będą potrzebne na wszystkich etapach.

Model V

Model V (od Verification and Validation) jest bardzo podobny do kaskadowego. Faza testów jest tu wpleciona w każdy etap wytwarzania, by wychwycić potencjalne błędy i wady.

Jest niezwykle zdyscyplinowany i wymaga ścisłych ram czasowych. W teorii jednak łata słabości podstawowego modelu kaskadowego, nie pozwalając większym błędom wymknąć się spod kontroli.

Zalety modelu V

• To model prosty i przejrzysty.
• Podejście V sprawdza się w mniejszych projektach, w których wymagania są wcześnie określone i zamrożone.
• To model systematyczny i zdyscyplinowany, który daje produkt wysokiej jakości.

Wady modelu V

• Model V nie nadaje się do projektów prowadzonych na bieżąco.
• Zmiana wymagań na późniejszym etapie byłaby zbyt kosztowna.

Model prototypowy

Model prototypowy to taki, w którym prototyp powstaje przed właściwym oprogramowaniem.

Prototypy mają ograniczoną funkcjonalność i słabszą wydajność niż prawdziwe oprogramowanie. Do ich budowy używa się funkcji zastępczych. To cenny mechanizm rozumienia potrzeb klienta.

Prototypy powstają przed właściwym oprogramowaniem, by uzyskać wartościową informację zwrotną od klienta. Uwagi są wdrażane, a klient ponownie sprawdza prototyp pod kątem zmian. Proces trwa, aż klient zaakceptuje model.

Po zebraniu wymagań powstaje szybki projekt i prototyp, który przedstawia się klientowi do oceny.

Uwagi klienta i zmienione wymagania służą do modyfikacji prototypu, który znów trafia do klienta do oceny. Gdy klient zaakceptuje prototyp, staje się on wymaganiem do zbudowania właściwego oprogramowania. Właściwe oprogramowanie powstaje w podejściu kaskadowym.

Zalety modelu prototypowego

• Model prototypowy obniża koszt i czas wytwarzania, bo wady wykrywa się znacznie wcześniej.
• Brakującą funkcję albo zmianę wymagań można wskazać już w fazie oceny i wdrożyć w ulepszonym prototypie.
• Zaangażowanie klienta od początku ogranicza nieporozumienia co do wymagań i rozumienia funkcjonalności.

Wady modelu prototypowego

• Ponieważ klient jest zaangażowany w każdą fazę, może zmieniać wymagania wobec produktu końcowego, co skomplikuje zadanie i może wydłużyć czas dostarczenia.

Model spiralny

Model spiralny łączy podejście iteracyjne z prototypowaniem.

W iteracjach przechodzi się przez fazy modelu spiralnego. Cykle w modelu odpowiadają krokom procesu SDLC: najbardziej wewnętrzny to zbieranie i analiza wymagań, potem planowanie, analiza ryzyka, wytwarzanie i ocena. Kolejny cykl to projektowanie, następnie implementacja i testy.

Model spiralny składa się z czterech faz:

1. Planowanie
2. Analiza ryzyka
3. Inżynieria
4. Ocena

Zalety modelu spiralnego

• Analizę ryzyka prowadzi się szeroko z użyciem prototypów.
• Każde ulepszenie lub zmianę funkcjonalności można wprowadzić w kolejnej iteracji.

Wady modelu spiralnego

• Konsultanci finansowania sugerują stosowanie go tylko w dużych projektach.
• Koszt może być wysoki, bo potrzebnych bywa wiele iteracji, co wydłuża czas do uzyskania produktu końcowego.

Model iteracyjny

Model iteracyjny dzieli produkt na małe części.

Na przykład funkcja, która ma powstać w danej iteracji, zostaje rozwiązana i wdrożona. Każda iteracja przechodzi przez fazy: analizę wymagań, projektowanie, kodowanie i testy. Szczegółowe planowanie w iteracjach nie jest wymagane.

Po zakończeniu iteracji produkt jest testowany i przekazywany klientowi do oceny i uwag. Uwagi klienta trafiają do kolejnej iteracji razem z nowo dodaną funkcją.

Dzięki temu produkt rośnie o kolejne funkcje, a po zakończeniu iteracji finalna wersja zawiera je wszystkie.

Fazy modelu iteracyjnego:

1. Faza rozpoczęcia
2. Faza opracowania
3. Faza budowy
4. Faza przejścia

Zalety modelu iteracyjnego

• Każdą zmianę wymagania da się łatwo wdrożyć i bez dodatkowych kosztów, bo nowe wymaganie może trafić do kolejnej iteracji.
• Ryzyko analizuje się i identyfikuje w iteracjach.
• Wady wykrywa się na wczesnym etapie.
• Ponieważ produkt jest podzielony na mniejsze części, łatwo nim zarządzać.

Wady modelu iteracyjnego

• Pełne wymagania i zrozumienie produktu są konieczne, by stopniowo go rozkładać i budować.

Model big bang

Model Big Bang nie ma zdefiniowanego procesu. Pieniądze i wysiłek spotykają się w jednym miejscu, a wejściem i wyjściem są zaprojektowane produkty, które mogą - ale nie muszą - odpowiadać temu, czego potrzebuje klient.

Model Big Bang nie wymaga wiele planowania. Programista sam przeprowadza analizę wymagań i kodowanie, a produkt rozwija zgodnie z własnym rozumieniem. Model stosuje się wyłącznie w małych projektach. Nie ma zespołu testowego ani formalnych testów, co może doprowadzić projekt do porażki.

Zalety modelu big bang

• To bardzo prosty model.
• Wymaga mniej planowania.
• Programista może tworzyć oprogramowanie po swojemu.

Wady modelu big bang

• Modelu big bang nie da się stosować w dużych, prowadzonych na bieżąco i złożonych projektach.
• Wysokie ryzyko i niepewność.

Model Agile

Model Agile skupia się bardziej na elastyczności wytwarzania produktu niż na wymaganiach.

W Agile produkt dzieli się na małe, przyrostowe buildy. Nie powstaje jako gotowy produkt za jednym razem. Każdy build zyskuje kolejne funkcje i opiera się na funkcjonalności poprzedniego.

Iteracje nazywa się tu sprintami. Każdy sprint trwa 2-4 tygodnie. Na jego końcu product owner przegląda produkt, a po akceptacji trafia on do klienta.

Uwagi klienta służą doskonaleniu produktu. Sugestie i usprawnienia trafiają do kolejnego sprintu. Testy prowadzi się w każdym sprincie, by ograniczyć ryzyko awarii.

Zalety modelu Agile

• Ten cykl życia oprogramowania daje większą elastyczność w dostosowywaniu się do zmian.
• Nową funkcję łatwo dodać.
• Zadowolenie klienta, bo uwagi i sugestie są przyjmowane na każdym etapie.

Wady modelu Agile

• Brak dokumentacji.
• Agile wymaga doświadczonych i wysoko wykwalifikowanych ludzi.
• Jeśli klient nie wie dokładnie, jak ma wyglądać produkt, projekt kończy się porażką.

Podsumowanie

Cykl życia produktu programistycznego to rozległy, wieloetapowy proces, który zaczyna się w chwili narodzin pomysłu i trwa, aż dojrzeje on do kompletnego rozwiązania. Przejście wszystkich tych kroków wymaga sporo wysiłku. Jest jednak łatwiejsze, gdy są wyryte w kamieniu - tak jak w tym przewodniku. 

Sześć etapów wytwarzania oprogramowania prowadzi Twój produkt od wstępnych badań po wdrożenie i utrzymanie. Trzymaj się ich, żeby nie zabłądzić - niezależnie od tego, czy budujesz aplikację webową, czy mobilną.

W Ideamotive zapewniamy uporządkowany proces wytwarzania produktu, który upraszcza zarówno wdrożenie, jak i migrację. 

Skorzystaj z najwyższej jakości nearshore’owego wytwarzania oprogramowania.