SDLC - szybki przewodnik

Cykl życia oprogramowania (SDLC) to proces używany przez branżę oprogramowania do projektowania, rozwijania i testowania oprogramowania wysokiej jakości. SDLC ma na celu stworzenie wysokiej jakości oprogramowania, które spełnia lub przewyższa oczekiwania klientów, osiąga termin realizacji i szacuje koszty.

SDLC to akronim cyklu życia oprogramowania.
Nazywa się to również procesem tworzenia oprogramowania.
SDLC to struktura definiująca zadania wykonywane na każdym etapie procesu tworzenia oprogramowania.
ISO / IEC 12207 to międzynarodowy standard dotyczący procesów cyklu życia oprogramowania. Ma to być standard definiujący wszystkie zadania wymagane do tworzenia i utrzymywania oprogramowania.

Co to jest SDLC?

SDLC to proces stosowany w przypadku projektu oprogramowania w organizacji oprogramowania. Składa się ze szczegółowego planu opisującego, jak rozwijać, utrzymywać, zastępować, zmieniać lub ulepszać określone oprogramowanie. Cykl życia określa metodologię poprawy jakości oprogramowania i całego procesu rozwoju.

Poniższy rysunek jest graficznym przedstawieniem różnych etapów typowego SDLC.

Typowy cykl życia oprogramowania składa się z następujących etapów -

Etap 1: Planowanie i analiza wymagań

Analiza wymagań jest najważniejszym i podstawowym etapem w SDLC. Wykonywany jest przez starszych członków zespołu przy współudziale klienta, działu sprzedaży, badań rynkowych i ekspertów dziedzinowych w branży. Informacje te są następnie wykorzystywane do planowania podstawowego podejścia do projektu oraz do przeprowadzenia studium wykonalności produktu w obszarach ekonomicznych, operacyjnych i technicznych.

Planowanie wymagań dotyczących zapewnienia jakości i identyfikacja ryzyk związanych z projektem odbywa się również na etapie planowania. Wynikiem technicznego studium wykonalności jest zdefiniowanie różnych podejść technicznych, które można zastosować w celu pomyślnej realizacji projektu przy minimalnym ryzyku.

Etap 2: Definiowanie wymagań

Po przeprowadzeniu analizy wymagań następnym krokiem jest jasne zdefiniowanie i udokumentowanie wymagań dotyczących produktu oraz uzyskanie ich akceptacji od klienta lub analityków rynku. Odbywa się to za pośrednictwem plikuSRS (Software Requirement Specification) dokument zawierający wszystkie wymagania dotyczące produktu, które mają być zaprojektowane i opracowane w trakcie cyklu życia projektu.

Etap 3: Projektowanie architektury produktu

SRS jest punktem odniesienia dla architektów produktów, którzy przedstawiają najlepszą architekturę produktu, który ma być opracowany. W oparciu o wymagania określone w SRS, zwykle proponuje się więcej niż jedno podejście projektowe do architektury produktu i dokumentuje je w DDS - specyfikacji dokumentu projektowego.

Ten DDS jest przeglądany przez wszystkich ważnych interesariuszy i na podstawie różnych parametrów, takich jak ocena ryzyka, wytrzymałość produktu, modułowość projektu, budżet i ograniczenia czasowe, wybierane jest najlepsze podejście projektowe dla produktu.

Podejście projektowe jasno definiuje wszystkie moduły architektoniczne produktu wraz z jego komunikacją i reprezentacją przepływu danych z modułami zewnętrznymi i zewnętrznymi (jeśli istnieją). Wewnętrzny projekt wszystkich modułów proponowanej architektury powinien być jasno określony z najdrobniejszymi szczegółami w DDS.

Etap 4: Tworzenie lub rozwijanie produktu

Na tym etapie SDLC rozpoczyna się właściwy rozwój i powstaje produkt. Na tym etapie kod programowania jest generowany zgodnie z DDS. Jeśli projekt jest wykonywany w sposób szczegółowy i zorganizowany, generowanie kodu można przeprowadzić bez większych kłopotów.

Programiści muszą przestrzegać wytycznych kodowania zdefiniowanych przez ich organizację, a narzędzia programistyczne, takie jak kompilatory, interpretery, debugery itp., Są używane do generowania kodu. Do kodowania używane są różne języki programowania wysokiego poziomu, takie jak C, C ++, Pascal, Java i PHP. Język programowania jest wybierany ze względu na rodzaj tworzonego oprogramowania.

Etap 5: Testowanie produktu

Ten etap jest zwykle podzbiorem wszystkich etapów, ponieważ we współczesnych modelach SDLC czynności testowe są przeważnie zaangażowane na wszystkich etapach SDLC. Jednak ten etap odnosi się tylko do etapu testowania produktu, w którym wady produktu są zgłaszane, śledzone, naprawiane i ponownie testowane, aż do osiągnięcia przez produkt standardów jakości określonych w SRS.

Etap 6: Wdrożenie na rynku i utrzymanie

Gdy produkt jest przetestowany i gotowy do wdrożenia, zostaje oficjalnie wypuszczony na odpowiedni rynek. Czasami wdrażanie produktu odbywa się etapami, zgodnie ze strategią biznesową tej organizacji. Produkt może najpierw zostać wydany w ograniczonym segmencie i przetestowany w rzeczywistym środowisku biznesowym (UAT - testy akceptacyjne użytkowników).

Następnie, na podstawie opinii, produkt może zostać wydany w takim stanie, w jakim jest lub z sugerowanymi ulepszeniami w docelowym segmencie rynku. Po wprowadzeniu produktu na rynek, jego utrzymanie odbywa się dla istniejącej bazy klientów.

Modele SDLC

Istnieją różne zdefiniowane i zaprojektowane modele cyklu życia oprogramowania, które są przestrzegane podczas procesu tworzenia oprogramowania. Modele te są również nazywane modelami procesu tworzenia oprogramowania. ”Każdy model procesu obejmuje szereg kroków unikalnych dla jego typu, aby zapewnić sukces w procesie tworzenia oprogramowania.

Poniżej znajdują się najważniejsze i najpopularniejsze modele SDLC stosowane w branży -

Model wodospadu
Model iteracyjny
Model spiralny
V-Model
Model Wielkiego Wybuchu

Inne powiązane metodologie to Agile Model, RAD Model, Rapid Application Development i Prototyping Models.

Model wodospadu był pierwszym wprowadzonym modelem procesu. Jest również określany jako pliklinear-sequential life cycle model. Jest bardzo łatwy do zrozumienia i użycia. W modelu kaskadowym każda faza musi zostać zakończona, zanim będzie można rozpocząć kolejną fazę, a fazy nie pokrywają się.

Model Waterfall jest najwcześniejszym podejściem SDLC, które zostało użyte do tworzenia oprogramowania.

Model wodospadu ilustruje proces tworzenia oprogramowania w liniowym, sekwencyjnym przepływie. Oznacza to, że jakikolwiek etap w procesie rozwoju rozpoczyna się dopiero po zakończeniu poprzedniej fazy. W tym modelu wodospadu fazy nie nakładają się.

Model wodospadu - projekt

Podejście kaskadowe było pierwszym modelem SDLC, który był szeroko stosowany w inżynierii oprogramowania, aby zapewnić sukces projektu. W podejściu „The Waterfall” cały proces tworzenia oprogramowania jest podzielony na oddzielne fazy. W tym modelu wodospadu zazwyczaj wynik jednej fazy działa sekwencyjnie jako dane wejściowe dla następnej fazy.

Poniższa ilustracja przedstawia różne fazy modelu wodospadu.

Sekwencyjne fazy w modelu wodospadu to -

Requirement Gathering and analysis - Wszystkie możliwe wymagania systemu, który ma zostać opracowany, są wychwytywane na tym etapie i dokumentowane w dokumencie specyfikacji wymagań.
System Design- W tej fazie analizowane są specyfikacje wymagań z pierwszej fazy i przygotowywany jest projekt systemu. Ten projekt systemu pomaga w określeniu wymagań sprzętowych i systemowych oraz pomaga w zdefiniowaniu ogólnej architektury systemu.
Implementation- Na podstawie danych wejściowych z projektu systemu, system jest najpierw rozwijany w małych programach zwanych jednostkami, które są integrowane w następnej fazie. Każda jednostka jest opracowywana i testowana pod kątem jej funkcjonalności, która jest nazywana testowaniem jednostkowym.
Integration and Testing- Wszystkie jednostki opracowane w fazie wdrożenia są integrowane w system po przetestowaniu każdej jednostki. Po integracji cały system jest testowany pod kątem wszelkich błędów i awarii.
Deployment of system- Po wykonaniu testów funkcjonalnych i niefunkcjonalnych; produkt jest wdrażany w środowisku klienta lub wprowadzany na rynek.
Maintenance- Jest kilka problemów, które pojawiają się w środowisku klienta. Aby rozwiązać te problemy, wydawane są poprawki. Aby ulepszyć produkt, wydano kilka lepszych wersji. Konserwacja ma na celu wprowadzenie tych zmian w środowisku klienta.

Wszystkie te fazy są kaskadowo połączone ze sobą, w których postęp jest postrzegany jako ciągły przepływ w dół (jak wodospad) przez kolejne fazy. Następna faza rozpoczyna się dopiero po osiągnięciu zdefiniowanego zestawu celów dla poprzedniej fazy i jest podpisana, stąd nazwa „Waterfall Model”. W tym modelu fazy nie zachodzą na siebie.

Model wodospadu - zastosowanie

Każde opracowane oprogramowanie jest inne i wymaga odpowiedniego podejścia SDLC w oparciu o czynniki wewnętrzne i zewnętrzne. Niektóre sytuacje, w których zastosowanie modelu Waterfall jest najbardziej odpowiednie, to:

Wymagania są bardzo dobrze udokumentowane, jasne i ustalone.
Definicja produktu jest stabilna.
Technologia jest rozumiana i nie jest dynamiczna.
Nie ma niejednoznacznych wymagań.
Do obsługi produktu dostępne są liczne zasoby z wymaganą wiedzą.
Projekt jest krótki.

Model wodospadu - zalety

Zaletą rozwoju wodospadu jest to, że pozwala on na wydziałów i kontrolę. Można ustawić harmonogram z terminami dla każdego etapu rozwoju, a produkt może przejść przez kolejne fazy modelu procesu rozwoju.

Rozwój przechodzi od koncepcji, przez projektowanie, wdrażanie, testowanie, instalację, rozwiązywanie problemów, a kończy na eksploatacji i konserwacji. Każda faza rozwoju przebiega w ściśle określonej kolejności.

Niektóre z głównych zalet modelu wodospadu są następujące:

Prosty i łatwy do zrozumienia i użytkowania
Łatwy w zarządzaniu dzięki sztywności modelu. Każda faza ma określone rezultaty i proces przeglądu.
Fazy są przetwarzane i kończone pojedynczo.
Działa dobrze w przypadku mniejszych projektów, w których wymagania są bardzo dobrze zrozumiane.
Jasno określone etapy.
Dobrze zrozumiane kamienie milowe.
Łatwe do zorganizowania zadania.
Proces i wyniki są dobrze udokumentowane.

Model wodospadu - wady

Wadą rozwoju wodospadu jest to, że nie pozwala na wiele refleksji lub rewizji. Gdy aplikacja jest na etapie testowania, bardzo trudno jest wrócić i zmienić coś, co nie zostało dobrze udokumentowane lub przemyślane na etapie koncepcji.

Główne wady modelu wodospadu są następujące -

Żadne działające oprogramowanie nie jest produkowane do późnych godzin cyklu życia.
Wysokie ryzyko i niepewność.
Nie jest to dobry model dla złożonych i zorientowanych obiektowo projektów.
Kiepski model dla długich i trwających projektów.
Nie nadaje się do projektów, w których wymagania są obarczone umiarkowanym lub wysokim ryzykiem zmiany. Tak więc w tym modelu procesu ryzyko i niepewność są wysokie.
Trudno jest zmierzyć postęp na poszczególnych etapach.
Nie może sprostać zmieniającym się wymaganiom.
Dostosowywanie zakresu w trakcie cyklu życia może zakończyć projekt.
Integracja odbywa się na samym końcu jako „wielki wybuch”, co nie pozwala na wczesne zidentyfikowanie jakichkolwiek technologicznych lub biznesowych wąskich gardeł lub wyzwań.

W modelu iteracyjnym proces iteracyjny rozpoczyna się od prostej implementacji małego zestawu wymagań oprogramowania i iteracyjnie ulepsza ewoluujące wersje, aż cały system zostanie zaimplementowany i gotowy do wdrożenia.

Iteracyjny model cyklu życia nie rozpoczyna się od pełnej specyfikacji wymagań. Zamiast tego rozwój rozpoczyna się od określenia i wdrożenia tylko części oprogramowania, które jest następnie przeglądane w celu zidentyfikowania dalszych wymagań. Ten proces jest następnie powtarzany, tworząc nową wersję oprogramowania na końcu każdej iteracji modelu.

Model iteracyjny - projekt

Proces iteracyjny rozpoczyna się od prostej implementacji podzbioru wymagań oprogramowania i iteracyjnie ulepsza ewoluujące wersje aż do wdrożenia pełnego systemu. W każdej iteracji wprowadzane są modyfikacje projektu i dodawane są nowe możliwości funkcjonalne. Podstawową ideą tej metody jest opracowanie systemu poprzez powtarzane cykle (iteracyjne) i w mniejszych porcjach naraz (przyrostowo).

Poniższa ilustracja przedstawia model iteracyjny i przyrostowy -

Rozwój iteracyjny i przyrostowy to połączenie projektowania iteracyjnego lub metody iteracyjnej oraz przyrostowego modelu kompilacji na potrzeby programowania. „Podczas tworzenia oprogramowania w tym samym czasie może trwać więcej niż jedna iteracja cyklu tworzenia oprogramowania”. Proces ten można opisać jako podejście „ewolucyjnego pozyskiwania” lub „budowania przyrostowego”.

W tym modelu przyrostowym całe wymaganie jest podzielone na różne kompilacje. Podczas każdej iteracji moduł programistyczny przechodzi przez fazę wymagań, projektowania, wdrażania i testowania. Każda kolejna wersja modułu dodaje funkcję do wersji poprzedniej. Proces jest kontynuowany, aż cały system będzie gotowy zgodnie z wymaganiami.

Kluczem do pomyślnego wykorzystania iteracyjnego cyklu życia oprogramowania jest rygorystyczna walidacja wymagań oraz weryfikacja i testowanie każdej wersji oprogramowania pod kątem tych wymagań w każdym cyklu modelu. Ponieważ oprogramowanie ewoluuje w kolejnych cyklach, testy należy powtarzać i rozszerzać, aby zweryfikować każdą wersję oprogramowania.

Model iteracyjny - aplikacja

Podobnie jak inne modele SDLC, programowanie iteracyjne i przyrostowe ma określone zastosowania w branży oprogramowania. Ten model jest najczęściej używany w następujących scenariuszach -

Wymagania całego systemu są jasno zdefiniowane i zrozumiane.
Należy zdefiniować główne wymagania; Jednak niektóre funkcje lub wymagane ulepszenia mogą ewoluować z czasem.
Nadszedł czas na ograniczenia rynkowe.
Nowa technologia jest używana i uczy się jej zespół programistów podczas pracy nad projektem.
Zasoby z niezbędnymi zestawami umiejętności nie są dostępne i planuje się ich użycie na podstawie umowy w określonych iteracjach.
Istnieją pewne cechy i cele wysokiego ryzyka, które mogą ulec zmianie w przyszłości.

Model iteracyjny - wady i zalety

Zaletą tego modelu jest to, że istnieje działający model systemu na bardzo wczesnym etapie rozwoju, co ułatwia znalezienie wad funkcjonalnych czy projektowych. Znajdowanie problemów na wczesnym etapie rozwoju umożliwia podjęcie działań naprawczych przy ograniczonym budżecie.

Wadą tego modelu SDLC jest to, że ma on zastosowanie tylko do dużych i nieporęcznych projektów tworzenia oprogramowania. Dzieje się tak, ponieważ trudno jest rozbić mały system oprogramowania na kolejne małe, nadające się do użytku przyrosty / moduły.

Zalety Iteracyjnego i Przyrostowego Modelu SDLC są następujące:

Niektóre działające funkcje można opracować szybko i na wczesnym etapie cyklu życia.
Wyniki uzyskuje się wcześnie i okresowo.
Można zaplanować rozwój równoległy.
Postęp można zmierzyć.
Mniej kosztowna zmiana zakresu / wymagań.
Testowanie i debugowanie podczas mniejszych iteracji jest łatwe.
Ryzyka są identyfikowane i usuwane podczas iteracji; a każda iteracja jest łatwym do zarządzania kamieniem milowym.
Łatwiejsze zarządzanie ryzykiem - najpierw wykonuje się część o wysokim ryzyku.
Z każdym przyrostem dostarczany jest produkt operacyjny.
Problemy, wyzwania i ryzyka zidentyfikowane z każdego przyrostu mogą być wykorzystane / zastosowane do następnego przyrostu.
Analiza ryzyka jest lepsza.
Obsługuje zmieniające się wymagania.
Początkowy czas pracy jest krótszy.
Lepiej nadaje się do dużych i krytycznych projektów.
W trakcie cyklu życia oprogramowanie jest produkowane wcześnie, co ułatwia ocenę i opinie klientów.

Wady Iteracyjnego i Przyrostowego Modelu SDLC są następujące:

Może być wymagane więcej zasobów.
Chociaż koszt zmiany jest mniejszy, ale nie jest odpowiedni do zmieniających się wymagań.
Wymagana jest większa uwaga kierownictwa.
Mogą pojawić się problemy z architekturą lub projektem systemu, ponieważ nie wszystkie wymagania są zbierane na początku całego cyklu życia.
Definiowanie przyrostów może wymagać zdefiniowania całego systemu.
Nie nadaje się do mniejszych projektów.
Złożoność zarządzania to więcej.
Koniec projektu może nie być znany, co jest ryzykiem.
Do analizy ryzyka potrzebne są wysoko wykwalifikowane zasoby.
Postęp projektów w dużym stopniu zależy od fazy analizy ryzyka.

Model spiralny łączy ideę iteracyjnego rozwoju z systematycznymi, kontrolowanymi aspektami modelu wodospadu. Ten model spiralny jest połączeniem iteracyjnego modelu procesu rozwoju i sekwencyjnego liniowego modelu rozwoju, tj. Modelu kaskadowego z bardzo dużym naciskiem na analizę ryzyka. Pozwala na stopniowe udostępnianie produktu lub stopniowe udoskonalanie w każdej iteracji wokół spirali.

Model spiralny - projekt

Model spiralny ma cztery fazy. Projekt oprogramowania wielokrotnie przechodzi przez te fazy w iteracjach zwanych spiralami.

Identyfikacja

Ta faza rozpoczyna się od zebrania wymagań biznesowych w spirali linii bazowej. W kolejnych spiralach, w miarę dojrzewania produktu, identyfikacja wymagań systemowych, wymagań dotyczących podsystemu i wymagań dotyczących jednostki odbywa się na tym etapie.

Ta faza obejmuje również zrozumienie wymagań systemowych poprzez ciągłą komunikację między klientem a analitykiem systemu. Na końcu spirali produkt trafia na zidentyfikowany rynek.

Projekt

Faza projektowania rozpoczyna się od projektu koncepcyjnego w linii bazowej i obejmuje projekt architektoniczny, projekt logiczny modułów, projekt fizyczny produktu i ostateczny projekt w kolejnych spiralach.

Konstruuj lub buduj

Faza konstruowania odnosi się do produkcji rzeczywistego oprogramowania na każdej spirali. W fazie bazowej, kiedy produkt jest właśnie przemyślany i projekt jest opracowywany, w tej fazie opracowywany jest POC (Proof of Concept) w celu uzyskania opinii klientów.

Następnie w kolejnych spiralach, przy większej przejrzystości wymagań i szczegółów projektu, tworzony jest działający model oprogramowania o nazwie build z numerem wersji. Te kompilacje są wysyłane do klienta w celu uzyskania opinii.

Ocena i analiza ryzyka

Analiza ryzyka obejmuje identyfikację, szacowanie i monitorowanie technicznej wykonalności i ryzyka związanego z zarządzaniem, takich jak przesunięcia harmonogramu i przekroczenie kosztów. Po przetestowaniu kompilacji, pod koniec pierwszej iteracji, klient ocenia oprogramowanie i przekazuje informacje zwrotne.

Poniższa ilustracja przedstawia model spiralny, przedstawiając czynności w każdej fazie.

Na podstawie oceny klienta proces tworzenia oprogramowania przechodzi do kolejnej iteracji, a następnie stosuje podejście liniowe, aby wdrożyć informację zwrotną sugerowaną przez klienta. Proces iteracji wzdłuż spirali trwa przez cały okres użytkowania oprogramowania.

Zastosowanie modelu spiralnego

Model spiralny jest szeroko stosowany w branży oprogramowania, ponieważ jest zsynchronizowany z naturalnym procesem rozwoju każdego produktu, tj. Uczeniem się z dojrzałością, która wiąże się z minimalnym ryzykiem zarówno dla klienta, jak i dla firm programistycznych.

Poniższe wskazówki wyjaśniają typowe zastosowania modelu spiralnego -

Kiedy istnieją ograniczenia budżetowe i ocena ryzyka jest ważna.
Do projektów o średnim i wysokim ryzyku.
Długoterminowe zaangażowanie w projekt ze względu na potencjalne zmiany priorytetów gospodarczych, ponieważ wymagania zmieniają się w czasie.
Klient nie jest pewien swoich wymagań, co zwykle ma miejsce.
Wymagania są złożone i wymagają oceny, aby uzyskać jasność.
Nowa linia produktów, która powinna być wprowadzana etapami, aby uzyskać wystarczającą liczbę opinii klientów.
Spodziewane są znaczące zmiany w produkcie w trakcie cyklu rozwojowego.

Model spiralny - wady i zalety

Zaletą spiralnego modelu cyklu życia jest to, że umożliwia on dodawanie elementów produktu, gdy staną się dostępne lub znane. Gwarantuje to, że nie ma konfliktu z wcześniejszymi wymaganiami i projektem.

Ta metoda jest spójna z podejściami, które obejmują wiele kompilacji i wydań oprogramowania, co pozwala na uporządkowane przejście do czynności konserwacyjnych. Innym pozytywnym aspektem tej metody jest to, że model spiralny wymusza zaangażowanie wczesnych użytkowników w prace nad rozwojem systemu.

Z drugiej strony, ukończenie takich produktów wymaga bardzo ścisłego zarządzania i istnieje ryzyko, że spirala zatoczy się w nieokreślonej pętli. Tak więc dyscyplina zmian i zakres przyjmowania wniosków o zmianę są bardzo ważne dla pomyślnego opracowania i wdrożenia produktu.

Zalety modelu Spiral SDLC są następujące -

Można dostosować się do zmieniających się wymagań.
Pozwala na szerokie wykorzystanie prototypów.
Wymagania można rejestrować dokładniej.
Użytkownicy wcześnie widzą system.
Rozwój można podzielić na mniejsze części, a części ryzykowne opracować wcześniej, co pomaga w lepszym zarządzaniu ryzykiem.

Wady modelu Spiral SDLC są następujące -

Zarządzanie jest bardziej złożone.
Zakończenie projektu może nie być znane wcześniej.
Nie nadaje się do projektów o małym lub niskim ryzyku i może być kosztowny w przypadku małych projektów.
Proces jest złożony
Spirala może trwać w nieskończoność.
Duża liczba etapów pośrednich wymaga nadmiernej dokumentacji.

Model V to model SDLC, w którym wykonywanie procesów odbywa się w sposób sekwencyjny w kształcie litery V. Jest również znany jakoVerification and Validation model.

Model V jest rozszerzeniem modelu kaskadowego i opiera się na powiązaniu fazy testowej dla każdego odpowiedniego etapu rozwoju. Oznacza to, że każda pojedyncza faza cyklu rozwoju ma bezpośredni związek z fazą testowania. Jest to model wysoce zdyscyplinowany, a kolejna faza rozpoczyna się dopiero po zakończeniu poprzedniej.

V-Model - Design

W modelu V odpowiednia faza testowania fazy rozwojowej jest planowana równolegle. Tak więc po jednej stronie fazy „V” znajdują się fazy weryfikacji, a po drugiej stronie fazy walidacji. Faza kodowania łączy dwie strony V-Modelu.

Poniższa ilustracja przedstawia różne fazy w modelu V SDLC.

Model V - Fazy weryfikacji

W modelu V istnieje kilka faz weryfikacji, a każda z nich została szczegółowo wyjaśniona poniżej.

Analiza wymagań biznesowych

To pierwsza faza cyklu rozwoju, w której wymagania produktu są rozumiane z perspektywy klienta. Ta faza obejmuje szczegółową komunikację z klientem, aby zrozumieć jego oczekiwania i dokładne wymagania. Jest to bardzo ważna czynność i należy nią dobrze zarządzać, ponieważ większość klientów nie jest pewna, czego dokładnie potrzebują. Plikacceptance test design planning odbywa się na tym etapie, ponieważ wymagania biznesowe mogą być wykorzystywane jako dane wejściowe do testów akceptacyjnych.

Projekt systemu

Gdy już masz jasne i szczegółowe wymagania dotyczące produktu, nadszedł czas na zaprojektowanie całego systemu. Projekt systemu będzie zawierał zrozumienie i wyszczególnienie pełnej konfiguracji sprzętu i komunikacji dla opracowywanego produktu. Plan testów systemu jest opracowywany na podstawie projektu systemu. Wykonanie tego na wcześniejszym etapie pozostawia więcej czasu na wykonanie testu później.

Styl architektoniczny

Specyfikacje architektoniczne są rozumiane i projektowane na tym etapie. Zazwyczaj proponuje się więcej niż jedno podejście techniczne, a na podstawie technicznej i finansowej wykonalności podejmowana jest ostateczna decyzja. Projekt systemu jest dalej podzielony na moduły o różnej funkcjonalności. Nazywa się to równieżHigh Level Design (HLD).

Transfer danych i komunikacja między modułami wewnętrznymi i ze światem zewnętrznym (innymi systemami) jest na tym etapie jasno zrozumiała i zdefiniowana. Dzięki tym informacjom na tym etapie można zaprojektować i udokumentować testy integracyjne.

Projekt modułu

Na tym etapie określany jest szczegółowy projekt wewnętrzny wszystkich modułów systemu, zwany dalej Low Level Design (LLD). Ważne jest, aby projekt był kompatybilny z innymi modułami w architekturze systemu oraz z innymi systemami zewnętrznymi. Testy jednostkowe są istotną częścią każdego procesu programowania i pomagają wyeliminować maksymalne błędy i błędy na bardzo wczesnym etapie. Te testy jednostkowe można zaprojektować na tym etapie w oparciu o projekty modułów wewnętrznych.

Faza kodowania

Właściwe kodowanie modułów systemu zaprojektowanych w fazie projektowania jest podejmowane w fazie kodowania. Wybór najlepszego odpowiedniego języka programowania opiera się na systemie i wymaganiach architektonicznych.

Kodowanie odbywa się w oparciu o wytyczne i standardy kodowania. Kod przechodzi przez liczne przeglądy kodu i jest optymalizowany pod kątem najlepszej wydajności, zanim ostateczna kompilacja zostanie wprowadzona do repozytorium.

Fazy walidacji

Różne fazy walidacji w modelu V są szczegółowo wyjaśnione poniżej.

Testów jednostkowych

Testy jednostkowe zaprojektowane w fazie projektowania modułu są wykonywane na kodzie w tej fazie walidacji. Testowanie jednostkowe to testowanie na poziomie kodu i pomaga eliminować błędy na wczesnym etapie, chociaż wszystkich defektów nie można wykryć za pomocą testów jednostkowych.

Testy integracyjne

Testowanie integracyjne jest związane z fazą projektowania architektonicznego. Testy integracyjne są przeprowadzane w celu sprawdzenia współistnienia i komunikacji wewnętrznych modułów w systemie.

Testowanie systemu

Testowanie systemu jest bezpośrednio związane z fazą projektowania systemu. Testy systemowe sprawdzają całą funkcjonalność systemu oraz komunikację rozwijanego systemu z systemami zewnętrznymi. Większość problemów ze zgodnością oprogramowania i sprzętu można wykryć podczas wykonywania tego testu systemu.

Testy akceptacyjne

Testy akceptacyjne są związane z fazą analizy wymagań biznesowych i polegają na testowaniu produktu w środowisku użytkownika. Testy akceptacyjne ujawniają problemy ze zgodnością z innymi systemami dostępnymi w środowisku użytkownika. Wykrywa również niefunkcjonalne problemy, takie jak wady obciążenia i wydajności w rzeczywistym środowisku użytkownika.

V- Model ─ Zastosowanie

Aplikacja V-Model jest prawie taka sama jak model kaskadowy, ponieważ oba modele są typu sekwencyjnego. Wymagania muszą być bardzo jasne przed rozpoczęciem projektu, ponieważ powrót i wprowadzenie zmian jest zwykle kosztowne. Model ten jest używany w dziedzinie rozwoju medycyny, ponieważ jest to dziedzina ściśle zdyscyplinowana.

Poniższe wskazówki to niektóre z najbardziej odpowiednich scenariuszy korzystania z aplikacji V-Model.

Wymagania są dobrze zdefiniowane, jasno udokumentowane i naprawione.
Definicja produktu jest stabilna.
Technologia nie jest dynamiczna i jest dobrze rozumiana przez zespół projektowy.
Nie ma żadnych niejednoznacznych ani nieokreślonych wymagań.
Projekt jest krótki.

V-Model - wady i zalety

Zaletą metody V-Model jest to, że jest bardzo łatwa do zrozumienia i zastosowania. Prostota tego modelu ułatwia również zarządzanie. Wadą jest to, że model nie jest elastyczny w stosunku do zmian i na wypadek zmiany wymagań, co jest bardzo powszechne w dzisiejszym dynamicznym świecie, wprowadzenie zmiany staje się bardzo kosztowne.

Zalety metody V-Model są następujące -

Jest to wysoce zdyscyplinowany model, a fazy są kończone pojedynczo.
Działa dobrze w przypadku mniejszych projektów, w których wymagania są bardzo dobrze zrozumiane.
Prosty i łatwy do zrozumienia i użytkowania.
Łatwy w zarządzaniu dzięki sztywności modelu. Każda faza ma określone rezultaty i proces przeglądu.

Wady metody V-Model są następujące -

Wysokie ryzyko i niepewność.
Nie jest to dobry model dla złożonych i zorientowanych obiektowo projektów.
Kiepski model dla długich i trwających projektów.
Nie nadaje się do projektów, w których wymagania są obarczone umiarkowanym lub wysokim ryzykiem zmiany.
Gdy aplikacja jest na etapie testowania, trudno jest wrócić i zmienić funkcjonalność.
Żadne działające oprogramowanie nie jest produkowane do późnych godzin cyklu życia.

Model Big Bang to model SDLC, w którym nie stosujemy żadnego określonego procesu. Rozwój po prostu zaczyna się od wymaganych pieniędzy i wysiłku jako wkładu, a wynikiem jest opracowane oprogramowanie, które może, ale nie musi być zgodne z wymaganiami klienta. Ten model Wielkiego Wybuchu nie jest zgodny z procesem / procedurą i wymaga bardzo niewielkiego planowania. Nawet klient nie jest pewien, czego dokładnie chce, a wymagania są wdrażane w locie bez przeprowadzania wielu analiz.

Zwykle ten model jest stosowany w przypadku małych projektów, w których zespoły programistyczne są bardzo małe.

Model Wielkiego Wybuchu ─ Projekt i zastosowanie

Model Wielkiego Wybuchu obejmuje skupienie wszystkich możliwych zasobów w tworzeniu oprogramowania i kodowaniu, przy bardzo niewielkim lub zerowym planowaniu. Wymagania są rozumiane i wdrażane na bieżąco. Wszelkie wymagane zmiany mogą, ale nie muszą, wymagać przebudowy całego oprogramowania.

Ten model jest idealny do małych projektów, w których pracuje jeden lub dwóch programistów, a także jest przydatny w projektach akademickich lub praktycznych. Jest to idealny model dla produktu, w którym wymagania nie są dobrze zrozumiane i nie podano ostatecznej daty wydania.

Model wielkiego podrywu - wady i zalety

Zaletą tego modelu Wielkiego Wybuchu jest to, że jest bardzo prosty i nie wymaga planowania. Łatwość zarządzania i brak formalnych procedur.

Jednak model Wielkiego Wybuchu jest modelem bardzo wysokiego ryzyka i zmiany w wymaganiach lub niezrozumiane wymagania mogą nawet doprowadzić do całkowitego odwrócenia lub odrzucenia projektu. Idealnie nadaje się do powtarzalnych lub małych projektów przy minimalnym ryzyku.

Zalety modelu Wielkiego Wybuchu są następujące -

To bardzo prosty model
Planowanie jest niewielkie lub nie jest wymagane
Łatwe w zarządzaniu
Wymagane bardzo mało zasobów
Daje elastyczność programistom
Jest to dobra pomoc w nauce dla nowo przybyłych lub studentów.

Wady modelu Wielkiego Wybuchu są następujące -

Bardzo wysokie ryzyko i niepewność.
Nie jest to dobry model dla złożonych i zorientowanych obiektowo projektów.
Kiepski model dla długich i trwających projektów.
Może się okazać bardzo kosztowna, jeśli wymagania zostaną źle zrozumiane.

Zwinny model SDLC to połączenie iteracyjnych i przyrostowych modeli procesów z naciskiem na zdolność adaptacji procesu i satysfakcję klienta dzięki szybkiemu dostarczaniu działającego oprogramowania. Metody zwinne dzielą produkt na małe przyrostowe kompilacje. Te kompilacje są dostarczane w iteracjach. Każda iteracja trwa zwykle od około jednego do trzech tygodni. Każda iteracja obejmuje międzyfunkcyjne zespoły pracujące jednocześnie w różnych obszarach, takich jak -

Planning
Analiza wymagań
Design
Coding
Testowanie jednostkowe i
Testy akceptacyjne.

Pod koniec iteracji działający produkt jest wyświetlany klientowi i ważnym interesariuszom.

Co to jest Agile?

Model Agile zakłada, że każdy projekt musi być traktowany inaczej, a istniejące metody muszą być dostosowane tak, aby jak najlepiej odpowiadały wymaganiom projektu. W Agile zadania są podzielone na przedziały czasowe (małe ramy czasowe), aby zapewnić określone funkcje dla wydania.

Przyjmowane jest podejście iteracyjne, a kompilacja działającego oprogramowania jest dostarczana po każdej iteracji. Każda kompilacja jest przyrostowa pod względem funkcji; ostateczna wersja zawiera wszystkie funkcje wymagane przez klienta.

Oto graficzna ilustracja modelu Agile -

Proces myślowy Agile rozpoczął się na wczesnym etapie tworzenia oprogramowania i z czasem stał się popularny ze względu na jego elastyczność i zdolność adaptacji.

Najpopularniejsze metody Agile to Rational Unified Process (1994), Scrum (1995), Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven Development i Dynamic Systems Development Method (DSDM) (1995). Są one teraz łącznie określane jakoAgile Methodologies, po opublikowaniu Manifestu Agile w 2001 roku.

Oto zasady Manifestu Agile -

Individuals and interactions - W rozwoju Agile ważna jest samoorganizacja i motywacja, podobnie jak interakcje, takie jak kolokacja i programowanie w parach.
Working software - Działające oprogramowanie demonstracyjne jest uważane za najlepszy sposób komunikacji z klientami w celu zrozumienia ich wymagań, a nie tylko polegania na dokumentacji.
Customer collaboration - Ponieważ wymagań nie można w całości zebrać na początku projektu z powodu różnych czynników, ciągła interakcja z klientem jest bardzo ważna, aby uzyskać odpowiednie wymagania dotyczące produktu.
Responding to change - Agile Development jest nastawiony na szybkie reagowanie na zmiany i ciągły rozwój.

Zwinne i tradycyjne modele SDLC

Agile jest oparty na adaptive software development methodspodczas gdy tradycyjne modele SDLC, takie jak model kaskadowy, są oparte na podejściu predykcyjnym. Zespoły predykcyjne w tradycyjnych modelach SDLC zwykle pracują nad szczegółowym planowaniem i mają pełną prognozę dokładnych zadań i funkcji, które mają być dostarczone w ciągu najbliższych kilku miesięcy lub w trakcie cyklu życia produktu.

Metody predykcyjne całkowicie zależą od requirement analysis and planningzrobione na początku cyklu. Wszelkie zmiany, które mają zostać wprowadzone, przechodzą przez ścisłą kontrolę zmian i ustalanie priorytetów.

Agile używa adaptive approachgdzie nie ma szczegółowego planowania i istnieje jasność co do przyszłych zadań tylko w odniesieniu do tego, jakie funkcje należy opracować. Istnieje rozwój oparty na funkcjach, a zespół dynamicznie dostosowuje się do zmieniających się wymagań produktu. Produkt jest bardzo często testowany w kolejnych wersjach, co minimalizuje ryzyko poważnych awarii w przyszłości.

Customer Interactionjest podstawą tej metodologii Agile, a otwarta komunikacja z minimalną dokumentacją to typowe cechy środowiska programistycznego Agile. Zespoły zwinne ściśle ze sobą współpracują i najczęściej znajdują się w tym samym położeniu geograficznym.

Model Agile - wady i zalety

Metody zwinne są ostatnio szeroko akceptowane w świecie oprogramowania. Jednak ta metoda może nie zawsze być odpowiednia dla wszystkich produktów. Oto kilka zalet i wad modelu Agile.

Zalety modelu Agile są następujące -

To bardzo realistyczne podejście do tworzenia oprogramowania.
Promuje pracę zespołową i trening krzyżowy.
Funkcjonalność można szybko rozwinąć i zademonstrować.
Wymagania dotyczące zasobów są minimalne.
Nadaje się do stałych lub zmiennych wymagań
Dostarcza wczesne rozwiązania do częściowej pracy.
Dobry model dla środowisk, które stale się zmieniają.
Minimalne zasady, łatwa dokumentacja.
Umożliwia jednoczesny rozwój i dostarczanie w ramach ogólnego zaplanowanego kontekstu.
Planowanie jest niewielkie lub nie jest wymagane.
Łatwe w zarządzaniu.
Daje elastyczność programistom.

Wady modelu Agile są następujące -

Nie nadaje się do obsługi złożonych zależności.
Większe ryzyko trwałości, łatwości konserwacji i rozszerzalności.
Ogólny plan, zwinny lider i zwinna praktyka PM to konieczność, bez której to nie zadziała.
Ścisłe zarządzanie dostawami określa zakres, funkcjonalność, która ma być dostarczona, i dostosowania w celu dotrzymania terminów.
W dużym stopniu zależy od interakcji z klientem, więc jeśli klient nie jest jasny, zespół może pójść w złym kierunku.
Istnieje bardzo duża zależność indywidualna, ponieważ generowana jest minimalna dokumentacja.
Transfer technologii do nowych członków zespołu może być sporym wyzwaniem ze względu na brak dokumentacji.

Plik RAD (Rapid Application Development)model oparty jest na prototypowaniu i iteracyjnym rozwoju bez żadnego konkretnego planowania. Sam proces pisania oprogramowania obejmuje planowanie niezbędne do opracowania produktu.

Rapid Application Development koncentruje się na zbieraniu wymagań klienta poprzez warsztaty lub grupy fokusowe, wczesne testowanie prototypów przez klienta z wykorzystaniem koncepcji iteracyjnej, ponowne wykorzystanie istniejących prototypów (komponentów), ciągła integracja i szybka dostawa.

Co to jest RAD?

Szybki rozwój aplikacji to metodologia tworzenia oprogramowania, która wykorzystuje minimalne planowanie na rzecz szybkiego prototypowania. Prototyp to działający model, który jest funkcjonalnym odpowiednikiem komponentu produktu.

W modelu RAD moduły funkcjonalne są opracowywane równolegle jako prototypy i są zintegrowane, aby stworzyć kompletny produkt w celu szybszej dostawy produktu. Ponieważ nie ma szczegółowego planowania wstępnego, ułatwia to uwzględnienie zmian w procesie rozwoju.

Projekty RAD są oparte na modelu iteracyjnym i przyrostowym i składają się z małych zespołów składających się z programistów, ekspertów dziedzinowych, przedstawicieli klientów i innych zasobów IT, którzy stopniowo pracują nad swoim komponentem lub prototypem.

Najważniejszym aspektem sukcesu tego modelu jest upewnienie się, że opracowane prototypy nadają się do ponownego wykorzystania.

Projektowanie modelu RAD

Model RAD rozdziela fazy analizy, projektowania, budowania i testowania na serię krótkich, iteracyjnych cykli rozwojowych.

Poniżej przedstawiono różne fazy modelu RAD -

Modelowanie biznesowe

Model biznesowy opracowywanego produktu jest zaprojektowany pod kątem przepływu informacji i dystrybucji informacji pomiędzy różnymi kanałami biznesowymi. Przeprowadzana jest pełna analiza biznesowa w celu znalezienia kluczowych informacji dla biznesu, sposobu ich uzyskania, sposobu i czasu przetwarzania informacji oraz czynników wpływających na pomyślny przepływ informacji.

Modelowanie danych

Informacje zebrane w fazie modelowania biznesowego są przeglądane i analizowane w celu utworzenia zestawów obiektów danych niezbędnych do prowadzenia działalności. Atrybuty wszystkich zbiorów danych są identyfikowane i definiowane. Relacje między tymi obiektami danych są ustanawiane i szczegółowo definiowane w odniesieniu do modelu biznesowego.

Modelowanie procesów

Zestawy obiektów danych zdefiniowane w fazie modelowania danych są konwertowane w celu ustalenia przepływu informacji biznesowych potrzebnych do osiągnięcia określonych celów biznesowych zgodnie z modelem biznesowym. Model procesu dla wszelkich zmian lub ulepszeń w zestawach obiektów danych jest definiowany na tym etapie. Podano opisy procesów dodawania, usuwania, pobierania lub modyfikowania obiektu danych.

Generowanie aplikacji

Rzeczywisty system jest budowany, a kodowanie odbywa się za pomocą narzędzi do automatyzacji w celu przekształcenia modeli procesów i danych w rzeczywiste prototypy.

Testowanie i rotacja

Całkowity czas testowania w modelu RAD jest skrócony, ponieważ prototypy są niezależnie testowane podczas każdej iteracji. Jednak przepływ danych i interfejsy między wszystkimi komponentami muszą zostać dokładnie przetestowane przy pełnym pokryciu testami. Ponieważ większość komponentów programistycznych została już przetestowana, zmniejsza to ryzyko wystąpienia poważnych problemów.

Poniższa ilustracja szczegółowo opisuje model RAD.

Model RAD Vs Tradycyjne SDLC

Tradycyjny SDLC opiera się na sztywnych modelach procesu, kładąc duży nacisk na analizę wymagań i gromadzenie danych przed rozpoczęciem kodowania. Wywiera presję na klienta, aby podpisał wymagania przed rozpoczęciem projektu, a klient nie ma poczucia produktu, ponieważ przez długi czas nie jest dostępna działająca wersja.

Klient może potrzebować pewnych zmian po obejrzeniu oprogramowania. Jednak proces zmiany jest dość sztywny i może nie być możliwe wprowadzenie większych zmian w produkcie do tradycyjnego SDLC.

Model RAD koncentruje się na iteracyjnym i przyrostowym dostarczaniu modeli roboczych do klienta. Skutkuje to szybką dostawą do klienta i zaangażowaniem klienta podczas całego cyklu rozwoju produktu, zmniejszając ryzyko niezgodności z rzeczywistymi wymaganiami użytkownika.

Model RAD - aplikacja

Model RAD można z powodzeniem zastosować w projektach, w których możliwa jest wyraźna modularyzacja. Jeśli projektu nie można podzielić na moduły, RAD może się nie powieść.

Poniższe wskaźniki opisują typowe scenariusze, w których można użyć RAD -

RAD należy stosować tylko wtedy, gdy system może zostać zmodularyzowany w celu dostarczenia go w sposób przyrostowy.
Powinien być używany, jeśli istnieje duża dostępność projektantów do modelowania.
Powinien być używany tylko wtedy, gdy budżet pozwala na użycie narzędzi do automatycznego generowania kodu.
Model RAD SDLC należy wybrać tylko wtedy, gdy dostępni są eksperci dziedzinowi posiadający odpowiednią wiedzę biznesową.
Powinien być stosowany tam, gdzie wymagania zmieniają się w trakcie projektu, a działające prototypy mają być przedstawiane klientowi w małych iteracjach trwających 2-3 miesiące.

Model RAD - wady i zalety

Model RAD umożliwia szybką dostawę, ponieważ skraca całkowity czas rozwoju dzięki możliwości ponownego wykorzystania komponentów i równoległemu rozwojowi. RAD działa dobrze tylko wtedy, gdy dostępni są wysoko wykwalifikowani inżynierowie, a klient jest również zaangażowany w osiągnięcie docelowego prototypu w określonym czasie. Jeśli brakuje zaangażowania po którejkolwiek stronie, model może zawieść.

Zalety modelu RAD są następujące -

Można dostosować się do zmieniających się wymagań.
Postęp można zmierzyć.
Czas iteracji może być krótki przy użyciu potężnych narzędzi RAD.
Produktywność przy mniejszej liczbie pracowników w krótkim czasie.
Skrócony czas rozwoju.
Zwiększa możliwość ponownego wykorzystania komponentów.
Pojawiają się szybkie wstępne przeglądy.
Zachęca do przekazywania opinii klientów.
Integracja od samego początku rozwiązuje wiele problemów integracyjnych.

Wady modelu RAD są następujące -

Zależność od silnych technicznie członków zespołu w zakresie identyfikacji wymagań biznesowych.
Tylko system, który można zmodularyzować, można zbudować za pomocą RAD.
Wymaga wysoko wykwalifikowanych programistów / projektantów.
Duża zależność od umiejętności modelowania.
Nie ma zastosowania do tańszych projektów, ponieważ koszt modelowania i automatycznego generowania kodu jest bardzo wysoki.
Złożoność zarządzania to więcej.
Nadaje się do systemów opartych na komponentach i skalowalnych.
Wymaga zaangażowania użytkownika przez cały cykl życia.
Nadaje się do projektów wymagających krótszych czasów rozwoju.

Prototypowanie oprogramowania odnosi się do tworzenia prototypów aplikacji, które wyświetlają funkcjonalność opracowywanego produktu, ale mogą w rzeczywistości nie odzwierciedlać dokładnej logiki oryginalnego oprogramowania.

Prototypowanie oprogramowania staje się bardzo popularne jako model wytwarzania oprogramowania, ponieważ pozwala zrozumieć wymagania klientów na wczesnym etapie rozwoju. Pomaga uzyskać cenne informacje zwrotne od klienta i pomaga projektantom oprogramowania i programistom zrozumieć, czego dokładnie oczekuje się od opracowywanego produktu.

Co to jest prototypowanie oprogramowania?

Prototyp to działający model oprogramowania o ograniczonej funkcjonalności. Prototyp nie zawsze jest zgodny z logiką używaną w rzeczywistej aplikacji i stanowi dodatkowy wysiłek, który należy uwzględnić podczas szacowania nakładu pracy.

Prototypowanie służy użytkownikom do oceny propozycji programistów i wypróbowania ich przed wdrożeniem. Pomaga również zrozumieć wymagania, które są specyficzne dla użytkownika i mogły nie zostać uwzględnione przez programistę podczas projektowania produktu.

Poniżej przedstawiono etapowe podejście do projektowania prototypu oprogramowania.

Podstawowa identyfikacja wymagań

Ten krok obejmuje zrozumienie podstawowych wymagań produktu, zwłaszcza w zakresie interfejsu użytkownika. Na tym etapie można zignorować bardziej skomplikowane szczegóły projektu wewnętrznego i aspekty zewnętrzne, takie jak wydajność i bezpieczeństwo.

Opracowanie pierwszego prototypu

Na tym etapie opracowywany jest początkowy prototyp, w którym przedstawione są bardzo podstawowe wymagania i udostępniane są interfejsy użytkownika. Te funkcje mogą nie działać dokładnie w ten sam sposób wewnętrznie w faktycznie opracowanym oprogramowaniu. Podczas gdy obejścia są stosowane, aby nadać klientowi ten sam wygląd i wrażenia w opracowanym prototypie.

Przegląd prototypu

Opracowany prototyp jest następnie prezentowany klientowi i innym ważnym interesariuszom projektu. Informacje zwrotne są gromadzone w zorganizowany sposób i wykorzystywane do dalszych ulepszeń w opracowywanym produkcie.

Popraw i ulepsz prototyp

Informacje zwrotne i komentarze do przeglądu są omawiane na tym etapie, a niektóre negocjacje odbywają się z klientem w oparciu o takie czynniki, jak - ograniczenia czasowe i budżetowe oraz techniczna wykonalność rzeczywistego wdrożenia. Zaakceptowane zmiany są ponownie włączane do opracowanego nowego Prototypu, a cykl powtarza się do momentu spełnienia oczekiwań klienta.

Prototypy mogą mieć wymiary poziome lub pionowe. Prototyp poziomy wyświetla interfejs użytkownika produktu i zapewnia szerszy wgląd w cały system, bez koncentrowania się na funkcjach wewnętrznych. Pionowy prototyp po drugiej stronie to szczegółowe opracowanie określonej funkcji lub podsystemu w produkcie.

Cel prototypu poziomego i pionowego jest inny. Prototypy poziome służą do uzyskania dodatkowych informacji na temat poziomu interfejsu użytkownika i wymagań biznesowych. Można go nawet zaprezentować w pokazach sprzedażowych, aby wprowadzić biznes na rynek. Pionowe prototypy mają charakter techniczny i służą do uzyskania szczegółowych informacji na temat dokładnego funkcjonowania podsystemów. Na przykład wymagania dotyczące bazy danych, interakcje i przetwarzanie danych obciążają dany podsystem.

Prototypowanie oprogramowania - rodzaje

W przemyśle stosowane są różne typy prototypów oprogramowania. Poniżej przedstawiono główne powszechnie stosowane typy prototypowania oprogramowania -

Wyrzucenie / szybkie prototypowanie

Wyrzucanie prototypów jest również nazywane prototypowaniem szybkim lub zamkniętym. Ten typ prototypowania wymaga bardzo niewielkiego wysiłku przy minimalnej analizie wymagań, aby zbudować prototyp. Po zrozumieniu rzeczywistych wymagań prototyp jest odrzucany, a rzeczywisty system jest opracowywany z bardzo jasnym zrozumieniem wymagań użytkownika.

Ewolucyjne prototypowanie

Ewolucyjne prototypowanie, zwane także prototypowaniem makiet, polega na budowaniu rzeczywistych funkcjonalnych prototypów z minimalną funkcjonalnością na początku. Opracowany prototyp stanowi serce przyszłych prototypów, na których zbudowany zostanie cały system. Dzięki zastosowaniu prototypowania ewolucyjnego dobrze zrozumiane wymagania są uwzględniane w prototypie, a wymagania są dodawane w miarę ich rozumienia.

Przyrostowe prototypowanie

Przyrostowe prototypowanie odnosi się do budowania wielu funkcjonalnych prototypów różnych podsystemów, a następnie integracji wszystkich dostępnych prototypów w celu utworzenia kompletnego systemu.

Ekstremalne prototypowanie

Ekstremalne prototypowanie jest używane w dziedzinie tworzenia stron internetowych. Składa się z trzech kolejnych faz. Po pierwsze, podstawowy prototyp ze wszystkimi istniejącymi stronami jest prezentowany w formacie HTML. Następnie symulowane jest przetwarzanie danych przy użyciu prototypowej warstwy usług. Wreszcie usługi są wdrażane i integrowane z ostatecznym prototypem. Ten proces nazywa się Extreme Prototyping i służy do zwrócenia uwagi na drugą fazę procesu, w której w pełni funkcjonalny interfejs użytkownika jest opracowywany z niewielkim uwzględnieniem rzeczywistych usług.

Prototypowanie oprogramowania - aplikacja

Prototypowanie oprogramowania jest najbardziej przydatne w tworzeniu systemów charakteryzujących się wysokim poziomem interakcji użytkownika, takich jak systemy online. Systemy, które wymagają od użytkowników wypełniania formularzy lub przechodzenia przez różne ekrany przed przetworzeniem danych, mogą bardzo efektywnie wykorzystywać prototypowanie, aby zapewnić dokładny wygląd i styl jeszcze przed opracowaniem właściwego oprogramowania.

Oprogramowanie, które wymaga zbyt dużej ilości przetwarzania danych, a większość funkcji ma charakter wewnętrzny i ma bardzo mały interfejs użytkownika, zwykle nie przynosi korzyści z prototypowania. Tworzenie prototypów może być dodatkowym narzutem w takich projektach i może wymagać wielu dodatkowych wysiłków.

Prototypowanie oprogramowania - wady i zalety

Prototypowanie oprogramowania jest stosowane w typowych przypadkach i decyzję należy podjąć bardzo ostrożnie, aby wysiłek włożony w budowę prototypu stanowił znaczną wartość dodaną do końcowego opracowanego oprogramowania. Model ma swoje zalety i wady, które omówiono poniżej.

Zalety modelu prototypowania są następujące -

Zwiększone zaangażowanie użytkownika w produkt jeszcze przed jego wdrożeniem.
Odkąd wyświetlany jest działający model systemu, użytkownicy lepiej rozumieją rozwijany system.
Zmniejsza czas i koszty, ponieważ wady można wykryć znacznie wcześniej.
Szybsze opinie użytkowników są dostępne, co prowadzi do lepszych rozwiązań.
Brakującą funkcjonalność można łatwo zidentyfikować.
Można zidentyfikować mylące lub trudne funkcje.

Wady modelu prototypowania są następujące -

Ryzyko niewystarczającej analizy wymagań ze względu na zbyt dużą zależność od prototypu.
Użytkownicy mogą być zdezorientowani w przypadku prototypów i rzeczywistych systemów.
W praktyce ta metodologia może zwiększyć złożoność systemu, ponieważ zakres systemu może wykraczać poza pierwotne plany.
Programiści mogą próbować ponownie wykorzystać istniejące prototypy do zbudowania rzeczywistego systemu, nawet jeśli nie jest to technicznie wykonalne.
Wysiłek włożony w tworzenie prototypów może być zbyt duży, jeśli nie jest odpowiednio monitorowany.