Cykl życia rozwoju oprogramowania zapewnia organizacjom systematyczne, krok po kroku podejście do opracowywania udanego oprogramowania poprzez zbieranie początkowych wymagań dla nowych produktów. Jest to systematyczny proces budowy oprogramowania, aby zapewnić jakość i poprawność skonstruowanego oprogramowania oraz spełnić oczekiwania klientów.
Główne modele rozwoju obejmują model kaskadowy, model inkrementalny, model spiralny, model fontanny, model inteligentny, model V, model RAD, model CBSD, metodę prototypową, metodę XP, metodę RUP itp.
Model kaskadowy
Model kaskadowy, znany również jako metoda cyklu życia, jest najczęściej stosowanym modelem rozwoju w metodzie cyklu życia. Dzieli proces rozwoju oprogramowania na sześć etapów: planowanie oprogramowania, analiza wymagań, projektowanie oprogramowania, kodowanie programu, testowanie oprogramowania oraz eksploatacja i konserwacja. Aby osiągnąć ustaloną kolejność od góry do dołu, jak wodospad, spadają one krok po kroku.
- Plan oprogramowania: Głównie określa cele rozwoju i wykonalność oprogramowania.
- Analiza wymagań: Po potwierdzeniu, że rozwój oprogramowania jest wykonalny, przeprowadza się szczegółową analizę różnych funkcji, które oprogramowanie musi osiągnąć. Etap analizy wymagań jest bardzo ważnym etapem. Dobrze wykonana praca na tym etapie położy dobrą podstawę dla sukcesu całego projektu rozwoju oprogramowania.
- Projektowanie oprogramowania: Zaprojektuj cały system oprogramowania, taki jak projektowanie ram systemu, projektowanie bazy danych itp., na podstawie wyników analizy wymagań. Projektowanie oprogramowania jest zazwyczaj podzielone na projektowanie ogólne (projektowanie zarysu) i projektowanie szczegółowe.
- Kod programu: Przekształć wynik projektowania oprogramowania w kod programu, który może być uruchamiany przez komputer. W procesie programowania należy sformułować jednolitą i zgodną z normami specyfikację programowania, aby zapewnić czytelność programu, łatwość konserwacji i poprawić efektywność działania programu.
- Testowanie oprogramowania: Po zakończeniu projektowania oprogramowania musi ono przejść rygorystyczne testy, aby znaleźć i poprawić problemy w oprogramowaniu w całym procesie projektowania. W procesie testowania konieczne jest opracowanie szczegółowego planu testów i przeprowadzenie testów ściśle zgodnie z planem testów, aby zredukować dowolność testu. Konserwacja oprogramowania:
- Konserwacja oprogramowania jest najdłuższym okresem w cyklu życia oprogramowania. Po opracowaniu oprogramowania i wprowadzeniu go do użytku, z różnych powodów, oprogramowanie nie może nadal spełniać wymagań użytkowników. Aby wydłużyć żywotność oprogramowania, musi być ono konserwowane.
Model transformacji
Model transformacji (model ewolucyjny) oparty jest na szybkim rozwoju prototypu. Na podstawie opinii i sugestii przedstawionych przez użytkowników w procesie korzystania z prototypu, prototyp jest ulepszany, aby uzyskać nową wersję prototypu, a proces ten powtarza się, aż ewoluuje w końcowy produkt oprogramowania.
Model spiralny
Model spiralny łączy model kaskadowy i model transformacji. Łączy zalety obu i dodaje analizę ryzyka. Opiera się na prototypie i obraca się od wewnątrz na zewnątrz wzdłuż spirali. Każda rotacja wymaga planowania, analizy ryzyka, inżynierii wdrożeniowej, oceny klienta i innych działań, a nowa wersja prototypu jest opracowywana. Po kilku spiralach uzyskuje się ostateczny system.
Model fontanny
Model fontanny zapewnia wsparcie dla ponownego wykorzystania oprogramowania i integracji wielu działań rozwojowych w cyklu życia, a głównie wspiera metody rozwoju obiektowego. Termin „fontanna” sam w sobie ucieleśnia cechy iteracji i braku luk. Pewna część systemu często powtarza pracę wiele razy, a związane funkcje są dodawane do ewoluowanego systemu w każdej iteracji. Tak zwany brak luk oznacza, że nie ma wyraźnej granicy między analizą, projektowaniem a kodowaniem w działaniach rozwojowych.
Model V
W modelu rozwoju testowanie często jest traktowane jako myśl wtórna w celu naprawienia sytuacji, ale istnieje także model rozwoju skoncentrowany na testowaniu, czyli model V. Model V był tylko niejasno uznawany w branży oprogramowania. Model V twierdzi, że testowanie nie jest myślą wtórną, ale procesem tak samo ważnym jak proces rozwoju.
Model V opisuje różne poziomy testów i wyjaśnia różne etapy w cyklu życia odpowiadające tym poziomom. Na rysunku zstąpienie po lewej stronie to różne etapy procesu rozwoju, a odpowiadające im to wznoszące się części po prawej stronie, czyli różne etapy procesu testowania.
Należy zauważyć, że nazewnictwo fazy testowej może się różnić w różnych organizacjach. Wartość modelu V polega na tym, że wyraźnie pokazuje różne poziomy, które istnieją w procesie testowania, i wyraźnie opisuje związek między tymi fazami testowymi a różnymi fazami w procesie rozwoju:
- Głównym celem testowania jednostkowego jest radzenie sobie z różnymi błędami, które mogą występować w procesie kodowania. Na przykład: użytkownik wprowadza błąd w wartości granicznej podczas procesu weryfikacji.
- Głównym celem testowania integracyjnego jest rozwiązanie możliwych problemów w szczegółowym projekcie, szczególnie sprawdzenie możliwych błędów w interfejsie między każdą jednostką a innymi częściami programu.
- Testowanie systemu jest głównie dla projektu ogólnego, sprawdzając, czy system jako całość działa efektywnie. Na przykład: Czy oczekiwana wysoka wydajność jest osiągana w ustawieniach produktu.
- Testy akceptacyjne są zazwyczaj przeprowadzane przez ekspertów biznesowych lub użytkowników, aby potwierdzić, że produkt może rzeczywiście spełniać potrzeby biznesowe użytkownika.
Model inkrementalny
Modele inkrementalne, podobnie jak modele wdrażania prototypów i inne metody ewolucyjne, są zasadniczo iteracyjne. Ale w przeciwieństwie do wdrażania prototypów, model inkrementalny podkreśla, że każdy przyrost wydaje operacyjny produkt. Wczesne przyrosty to „odłączalna” wersja finalnego produktu, ale zapewniają funkcje obsługi użytkownika i stanowią platformę do oceny przez użytkowników.
Cechą modelu inkrementalnego jest wprowadzenie koncepcji pakietów inkrementalnych. Nie musisz czekać, aż wszystkie wymagania się pojawią, wystarczy, że pojawią się pakiety inkrementalne dla określonego wymagania, możesz rozpocząć rozwój. Chociaż pewien pakiet inkrementalny może wymagać dalszego dostosowania do potrzeb klientów i może wymagać zmian, tak długo jak pakiet inkrementalny jest wystarczająco mały, jego wpływ może być znośny dla całego projektu.
Model RAD Model szybkiego rozwoju aplikacji (RAD) jest inkrementalnym modelem procesu rozwoju oprogramowania, który podkreśla bardzo krótki cykl rozwoju.
Model RAD jest „szybkim” wariantem modelu kaskadowego, który osiąga szybki rozwój dzięki szerokiemu wykorzystaniu komponentów wielokrotnego użytku i metody budowy opartej na komponentach. Jeśli wymagania są dobrze zrozumiane, a zakres projektu jest ograniczony, ten model może być użyty do szybkiego stworzenia w pełni funkcjonalnego „systemu informacyjnego”.
Proces zaczyna się od modelowania biznesowego, następnie modelowania danych, modelowania procesów, generowania aplikacji, testowania i iteracji. Proces oprogramowania wykorzystujący model RAD przedstawiono na poniższym rysunku.
Zadania do wykonania w każdym okresie aktywności modelu RAD są następujące.
Modelowanie biznesowe: Jakie informacje napędzają działanie procesu biznesowego? Jakie informacje mają być generowane? Kto je wygenerował? Dokąd płynie informacja? Kto się tym zajmie? Można uzupełnić diagramami przepływu danych.
Modelowanie danych: Aby wspierać przepływ danych w procesie biznesowym, znajdź zbiór obiektów danych, zdefiniuj atrybuty obiektów danych i utwórz model danych z relacją z innymi obiektami danych, co można uzupełnić diagramami ER.
Modelowanie procesów: umożliwia obiektom danych realizację różnych funkcji biznesowych w przepływie informacji. Proces tworzenia opisuje dodawanie, modyfikację, usuwanie i wyszukiwanie obiektów danych, czyli udoskonalenie pudełka przetwarzania w diagramie przepływu danych.
Generowanie programów aplikacyjnych: Użyj języka czwartej generacji (4GL) do napisania programu przetwarzającego, ponownie wykorzystaj istniejące komponenty lub stwórz nowe komponenty wielokrotnego użytku, a także użyj narzędzi dostarczonych przez środowisko do automatycznego generowania i budowania całego systemu aplikacyjnego.
Testowanie i dostarczanie, z powodu dużej ilości ponownego wykorzystania, zazwyczaj wykonuje się tylko testy ogólne, ale nowo utworzone komponenty nadal muszą być testowane.
Model oparty na komponentach
Komponent (Component) to jednostka oprogramowania o wartości wielokrotnego użytku i stosunkowo niezależnych funkcjach. Model rozwoju oprogramowania opartego na komponentach (CBSD) polega na zastosowaniu podejścia modułowego do modularizacji całego systemu, a przy wsparciu określonego modelu komponentów, ponownym wykorzystaniu jednego lub więcej komponentów oprogramowania w bibliotece komponentów, poprzez połączenie procesu budowy systemów oprogramowania aplikacyjnego o wysokiej wydajności i wysokiej jakości.
Model rozwoju oparty na komponentach włącza wiele cech modelu spiralnego i jest zasadniczo ewolucyjny, a proces rozwoju jest iteracyjny. Model rozwoju oparty na komponentach składa się z pięciu etapów: analiza i definicja wymagań oprogramowania, projekt architektury, ustanowienie biblioteki komponentów, budowa oprogramowania aplikacyjnego, testowanie i wydanie.
Metoda prototypowa
Prototyp oprogramowania to częściowa realizacja proponowanego nowego produktu. Głównym celem ustanowienia prototypu jest rozwiązanie problemu niepewnego popytu we wczesnym etapie rozwoju produktu. Jego celem jest wyjaśnienie i poprawa wymagań, zbadanie opcji projektowych oraz rozwój w kierunku finalnego produktu.
Istnieje wiele sposobów klasyfikacji prototypów. Z perspektywy tego, czy prototyp realizuje swoje funkcje, prototypy oprogramowania można podzielić na dwa typy: prototypy poziome i prototypy pionowe.
Prototypy poziome nazywane są również prototypami behawioralnymi, które służą do badania niektórych specyficznych zachowań oczekiwanego systemu i osiągnięcia celu udoskonalenia wymagań. Prototypy poziome zazwyczaj są tylko nawigacją funkcji, ale nie realizują faktycznie funkcji. Prototyp poziomy jest głównie używany na interfejsie.
Prototypy wertykalne nazywane są również prototypami strukturalnymi, które implementują część swoich funkcji. Prototypy wertykalne są głównie wykorzystywane w realizacji złożonych algorytmów.
Metoda XP
XP to lekka (zwinna), efektywna, niskiego ryzyka, elastyczna, przewidywalna, naukowa i zabawna metoda rozwoju oprogramowania. W porównaniu z innymi metodologiami, największa różnica polega na:
- Zapewnij konkretne i ciągłe informacje zwrotne wcześniej w krótszym okresie.
- Planowanie iteracyjne, najpierw szybkie stworzenie głównego planu na samym początku, a następnie ciągłe rozwijanie go w trakcie procesu rozwoju projektu.
- Polegaj na zautomatyzowanych procedurach testowych, aby monitorować postęp rozwoju i wcześnie wychwytywać wady.
- Polegaj na komunikacji werbalnej, testowaniu i komunikacji programu źródłowego.
- Popieraj ciągły ewolucyjny projekt.
- Polegaj na bliskiej współpracy w zespole deweloperskim.
- Staraj się jak najlepiej zrównoważyć krótkoterminowe interesy programisty i długoterminowe interesy projektu.
Metoda Unified Process (UP)
Unified Process to ogólny framework procesów, który może radzić sobie z szerokim zakresem systemów oprogramowania, różnych dziedzin aplikacji, różnych typów organizacji, różnych poziomów wydajności i różnych skal projektów. UP jest oparty na komponentach, co oznacza, że system oprogramowania opracowany przez niego składa się z komponentów, a komponenty są ze sobą połączone przez dobrze zdefiniowane interfejsy. Przy przygotowywaniu wszystkich planów systemu oprogramowania, UP wykorzystuje zunifikowany język modelowania UML.
W porównaniu z innymi procesami oprogramowania, UP ma trzy zauważalne cechy: napędzany przypadkami użycia, skoncentrowany na podstawowej architekturze, iteracja i inkrementacja. Proces oprogramowania w Rational Unified Process dzieli się na cztery sekwencyjne fazy w czasie, a mianowicie fazę początkową, fazę udoskonalenia, fazę budowy i fazę dostawy. Na końcu każdej fazy należy zorganizować przegląd techniczny, aby określić, czy cele tej fazy zostały osiągnięte. Jeśli wyniki przeglądu są satysfakcjonujące, projekt może przejść do następnej fazy.
Dowiedz się więcej
- Czym jest model procesu oprogramowania?
- Planowanie adaptacyjne vs przewidywalne: Kiedy zwinne? Kiedy kaskadowe?
- Czym jest cykl życia rozwoju oprogramowania?
- Przewodniki do nauki Scrum
- Przewodniki do nauki zarządzania projektami
- Czym jest UML?
- Czym jest zwinny rozwój oprogramowania?
- Historia użytkownika vs przypadek użycia w zwinnej produkcji oprogramowania
Ten post dostępny jest również w Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文