Ten artykuł to krótki wpis o tak zwanym V‑modelu. Jest to model wytwarzania oparty na pętli analizy, projektowania, testowania i przekazania do użytku. Oparty jest połączeniu dwóch cykli życia: projektowania i wytwarzania. jest stosowany w szeroko pojętej inżynierii systemów, nie koniecznie oprogramowania.
W branży IT znana jego postać wygląda np. tak:
V‑Model is also referred to as the Verification and Validation Model. In this, each phase of SDLC must complete before the next phase starts. It follows a sequential design process the same as the waterfall model. The testing of the device is planned in parallel with a corresponding stage of development. (źr.: V‑model (Software Engineering) – javatpoint).
Niedawno w innej wersji v‑model publikowałem, pisząc o tym czym jest mechatronika :
Bardzo często autorzy piszą, że jest to skompromitowany, tak zwany wodospadowy (waterfall), system wytwarzania oprogramowania. Była by to prawda, gdy zawsze chodziło o hipotetyczny „cały system”. Jednak V‑model, jako metoda, nie precyzuje skali projektu. W przypadku większości dawnych konstrukcji mechanicznych była by to prawda, jednak modułowość to od lat cecha każdej konstrukcji inżynierskiej. Model ten więc nie koniecznie musi być tym „złym wodospadem”. Pojawiają się od czasu do porównania między wodospadem, v‑modelem a agile, jako metodami, jednak ich autorzy nie precyzują tego, czy w danym przypadku chodzi o moduł czy o cały system . Model ten jest stale przedmiotem poszukiwań poprawy jakości i większej „zwinności” .
Myślę, że klasyczny wodospad, jako metoda prowadzenia powoli odchodzi w niepamięć (powinien). Nie zapominajmy jednak, że rozpoczynanie tworzenia oprogramowania od projektowania wspólnego (relacyjnego) modelu danych to taki właśnie klasyczny strukturalny wodospad. Więc jak?
Modułowe systemy to w zasadzie zagnieżdżone dwa v‑modele. Najpierw projektujemy architekturę całości: powstaje model komponentowy. Kolejne etapy to iteracyjne dostarczanie poszczególnych komponentów. W konstrukcjach elektromechanicznych i tak musimy czekać na ukończenie całości (samochód czy pralka albo jest w całości, albo nie mamy czego używać). W przypadku oprogramowania możemy skupić sie na pojedynczych komponentach.
Poprawnie zaprojektowane oprogramowanie to samodzielne usługi aplikacyjne. Złożone nie raz, aplikacje powstają jako zbiory takich usług, na rynku widzimy je jako gotowe wielomodułowe systemy. Jednak dedykowane projekty nie mają rygoru „oddania w całości”. Usługi aplikacyjne mogą być oddawane jedna po drugiej. Wtedy opisywany tu v‑model to najpierw lewa strona: tak zwana „architektura wysokiego poziomu”, a następnie iteracyjno-przyrostowe realizacje kolejnych komponentów i usług. Każda kolejna usługa (komponent) to projektowanie, implementacja, testy i oddanie do użytku.
Podejścia znane jako Use Case 2.0 czy Microservice, to właśnie takie modułowe
Jednak nadal na etapie analiz i projektowania autorzy tych projektów bardzo często nadal poprzestają na opisu idei, czyli procesu biznesowego i nazwanych usług, nie jest to jednak projektowanie systemu a co najwyżej biznesowe wymagania . V‑model opiera się na tym, że implementacja jest poprzedzana projektowaniem, czyli swoistym studium wykonalności. Jest to sprawdzona metoda z każdej innej inżynierii:
zanim zaczniesz budować, upewnij się, że wiesz co powinno powstać.
Tak więc v‑model wygląda na dobrą metodę-proces. To czy jest to wodospad czy nie, zależy od architektury całości (monolit czy nie mikroserwisy) a nie od faktu poprzedzania implementacji projektowaniem.
Balaji, S., & Murugaiyan, M. S. (2012). Waterfall vs. V‑Model vs. Agile: A comparative study on SDLC. International Journal of Information Technology and Business Management, 2(1), 26 – 30.
Mathur, S., & Malik, S. (2010). Advancements in the V‑Model. International Journal of Computer Applications, 1(12), 29 – 34.
Friman, E. (2020). BUILDING AND ADAPTING SYSML BASED SYSTEM ARCHITECTURE FRAMEWORK FOR MECHATRTONIC SYSTEMS. 75.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Jest dość liczna grupa ludzi uważająca, że w Internecie nie obowiązują ani prawa fizyki, ani prawa ekonomii ani nawet zdrowy rozsądek. W kwestii inżynierii oprogramowania ludzie Ci straszą świat projektów „mitycznym wodospadem” jak kiedyś dzieci straszone były Babą Jagą.
[dzień po napisaniu: po dyskusji – patrz treść pod tym wpisem – a autorem cytowanego tu artykułu, doszliśmy do wniosku, że nie różnimy się zbytnio w poglądach, jednak zbytnie uproszczenie treści miało prawo wprowadzić mnie w błąd, jednak mój artykuł pozostanie w pierwotnej treści bo polemizuje głównie z pewnym mitem a nie tym autorem].
Poniżej kolejny tego typu „starszak” o znamiennym tytule „Dlaczego tradycyjne metody zarządzania nie działają w projektach internetowych?” Szczerze mówiąc jak to czytam, natychmiast przypomina mi się stare i wykpiwane w czasach stalinowskich, obowiązkowe wypracowanie w szkole na temat „Dlaczego kochamy Lenina” (bo, że go nie kochamy wtedy nie wchodziło w grę).
Tu mamy dość ciekawy przykład zastraszenia, autor cytowanego artykułu uważa, że projekty internetowe rządzą się innymi prawami:
Mamy pomysł, ustalmy zakres oraz harmonogram na najbliższe 7 miesięcy, realizujemy projekt i na końcu wprowadźmy produkt na rynek. Oczywiście za niemałe pieniądze. Czy warto tak szczegółowa planować swoje nowe przedsięwzięcia? Czy warto tak długo dopieszczać swój pomysł?
Jaką skuteczność w przewidywaniu przyszłości mają specjaliści? Takie pytanie zadał sobie przed 10 laty Philip Tetlock, znany amerykański psycholog. Przez dobrych kilka lat zbierał wśród międzynarodowej śmietanki analityków opinie na temat przyszłych wydarzeń ekonomicznych i politycznych. Udało mu się uzyskać ponad 82 tys. eksperckich przepowiedni. (Dlaczego tradycyjne metody zarządzania nie działają w projektach internetowych?).
Drobne ironie w stylu „za niemałe pieniądze” to próby manipulacji, które pomijam. Po pierwsze autor powołuje się wyniki badania, które potwierdza, że metody heurystyczne się nie sprawdzają jako metoda prognozowania, fakt znany od dawna w kręgach nauki (pisałem o tym w Mucha…) i faktem jest, że takie (na bazie wiedzy z okresów minionych) prognozowanie nie ma sensu. Tu z autorem pełna zgoda. Ale jak się to ma do projektów programistycznych? Nijak się nie ma, bo takich prognoz nikt rozsądny nie robi w projekcie.
W inżynierii oprogramowania nie prognozuje się , bo to domena biznesowa, w inżynierii oprogramowania dąży się do zrozumienia istoty problemu implementacji. Czy analiza i projektowanie to długie, szczegółowe i zbędne planowanie? Nie. Analiza ma za cel zrozumienie i podjęcie decyzji o sposobie implementacji. Jeżeli można tu mówić o planowaniu to raczej w kategoriach „jak planujemy zaimplementować” to rozwiązanie (którym jest spełnienie wymagań biznesu).
Owszem, można prowadzić implementacje metodą prototypów, błądząc, z nadzieją, że szybko (przypadkiem) stworzymy dobre rozwiązanie. Ale to w szczególności trudno zaplanować (a nawet start-upy maja budżety). Czy to jest tańsze? Nie sądzę. Nazywam to syndromem LOTTO: szybka decyzja bez planowanie daje pewne szanse na odkrycie poprawnego rozwiązania, jednak to to samo co uznanie, że można grając w LOTTO zarobić na bieżące życie aż do śmierci. Owszem, jest to możliwe, ale udaje się nielicznym (i wiemy dlaczego).
Start-upy niewątpliwie mają swoje prawa, i tu autor ma racje, twierdząc, że „nie ma czasu”, jednak nie prawdą jest, że:
Problem jest tylko taki, że wszystko, co na początku ustaliliśmy to zwykłe przewidywania naszych ?internetowych ekonomistów?. Całe nasze uzasadnienie biznesowe (model biznesowy) jest przewidywaniem, cały nasz złoty trójką projektu (czas, zakres, budżet) jest przewidywaniem. A jak dobrze wiemy, dzięki badaniom Tetlocka, ludzie przewidywać dobrze nie potrafią. Szczególnie w nowych warunkach.
Łączenie „trójkąta projektowego” z prognozami biznesowymi jest albo nieporozumieniem, albo niewiedzą, albo cynizmem: model biznesowy nie jest prognozą, model biznesowy to opis sposobu generowania wartości dodanej. Prognozą może być co najwyżej plan przychodów z tej działalności.
Bo po pierwsze w tworzeniu modelu biznesowego, nie ma mowy o przewidywaniu przyszłości a o analizie grupy docelowej. Wskazany zaś trójkąt projektowy (zakres, termin, budżet) to plan wytworzenia konkretnego oprogramowania (wspierającego ten model biznesowy). Owszem, tu – model biznesowy – można się pomylić, ale to nie pomyłka prognozowania tylko np. zła decyzja marketingowa. Teza, że np. „moje kapelusze będą miały duży zbyt w gronie snobów”, to nie prognozowanie a plan marketingowy. Prognozowaniem było by stwierdzenie, że „sprzedaż kapeluszy dla snobów osiągnie 10 tys. szt. w ciągu najbliższego roku” i tu faktycznie można się nieźle pomylić. Nie zmienia to faktu, że kapelusz to kapelusz i należy go zaprojektować i wytworzyć, oprogramowanie wspomagające sprzedaż kapeluszy przez internet (jego funkcjonalność) nie zależy od ilości sprzedaży (poza wydajnością całości) tylko od tego co i jak chcemy sprzedawać.
Jednak nie zmienia to faktu, że program wspierający sprzedaż tych kapeluszy wymaga pewnej analizy by zaprojektować model dziedziny tego oprogramowania, tu błąd kosztuje czasem tyle, że wymagany refaktoring (bez którego nie zrealizujemy np. kolejnej nowej potrzebnej funkcjonalności) ad-hoc pisanego oprogramowania zabije budżet całego projektu. To wygląda mniej więcej tak (źr. Znaczenie ma nie wielkość projektu…):
Powyżej wykres pokazujący koszty chwilowe (linia ciągła) i narastające (linia przerywana) projektu tworzenia i utrzymania oprogramowania. Linia zielona to proces z dobrze opracowanym projektem na początku, czerwona to projekt „na żywioł”.
Racje ma autor pisząc, że w przypadku start-upów może być dużym ryzykiem inwestowanie w projektowanie czegoś co może okazać się niewypałem, jednak trzeba pamiętać, że jeżeli projekt wypali, prawie na pewno będzie wymagał wtedy refaktoringu, by krzywa utrzymania była jednak bliższa tej zielonej (niskie koszty stałe to większa marża).
Wodospad, którym się „starszy dzieci” to przede wszystkim nie „liniowy” projekt na lata (czy jak u autora cytatów: 7 miesięcy start-up). Wodospad dzisiaj to jedynie uznanie, że trzy fazy: analiza, projektowanie, implementacja, są nierozłączne z czystego rozsądku. Prawda jest, że każda prognoza wiąże się z ryzykiem, jeżeli uznamy że jest ono duże (a z reguły jest), to nie planujemy jak kiedyś:
(typowy strukturalny proces), tylko dzielimy projekt na etapy (kolejne funkcjonalności) o długości na tyle krótkiej, by błędy prognozy były akceptowalne i nie niszczyły projektu. Wtedy projekt charakteryzuje się takim cyklem:
U autora cytatów znajdziemy bardzo podobny wykres, z jedną różnicą: tam jest to szukanie rozwiązania metodą prototypów, czyli każda dotychczasowa praca idzie do kosza. W tym przypadku, jest to przemyślany proces, powstały już kod nie jest wyrzucany, ale to wymaga dobrego projektu (szkieletu architektury), obiektowych metod i zastosowania wzorców analitycznych.
Autor artykułu pisze:
Mamy określonycel biznesowy. Nie wiemy, nie znamy i nie mamy łatwego dostępu do najważniejszego udziałowca ? użytkownika, nie wiemy, co zrobić, żeby spełnić cel biznesowy (zakres), tym samym nie wiemy, ile to będzie kosztować (budżet) i na kiedy się uda go osiągnąć (czas).
Wiemy natomiast, że na pewno będą zmiany i trzeba jak najszybciej z produktem projektu wejść na rynek.
Współczuję każdemu, kto w tak ekstremalnych warunkach, przy tak wielkim stopniu niepewności musi tradycyjnymi metodami realizować projekt.
Od razu przypomnę, że da się nowoczesnymi metodami tworzyć oprogramowanie odpowiadające powyższym wymaganiom: to ma już nawet nawet ładną nazwę: SOLID gdzie kluczową cechą jest to, że tak projektowane i wykonywane oprogramowanie jest „zamknięte na zmiany i otwarte na rozszerzenia” (nie mylić zmian kodu ze zmianą strategii sprzedaży), oznacza to, że kod nie wymaga zmian (refaktoring, odrzucanie prototypów) a pozwala na rozszerzenia (nowe wymagania). Metody obiektowe to nic innego jak odpowiedź na powyższe potrzeby. Jeżeli autor miał na myśli tradycyjne metodyw rodzaju „baza danych i funkcje” to jestem po jego stronie, też współczuję.
Paradoksalnie to co opisałem jest tańsze, bo niemalże nic nie idzie do kosza. Każdy etap jest krótki więc „prawie pewny”, niemalże żadna praca nie idzie na marne, system nie wymaga permanentnej refaktoryzacji. Co tu jest ważne: zachowujemy cykl: analiza, projektowanie, implementacja. Są to wtedy krótkie iteracje, ale zawsze kodowanie poprzedzamy analizą dziedziny. Druga ważna rzecz: nie da się tak prowadzić projektu metodami strukturalnymi (najpierw baza danych, potem funkcje) bo model bazy danych z zasady obejmuje całą dziedzinę problemu, a tej, jak słusznie zauważa autor, nie znamy (długoterminowa prognoza).
Druga wersja (opisana powyżej) jest relatywnie tania, można przerwać w dowolnym momencie i nie przeinwestować. Jednak rezygnacja z analizy, której celem jest zrozumienie problemu i zdecydowanie o sposobie implementacji to szukanie kłopotów takich jak ten:
Jak wygląda takie «wzorcowe” projektowanie opisałem w artykule Plansza do gry w szachy…
Na koniec co nieco o ryzyku:
(Karl Popper)
Tak więc nie ma metod jedynie słusznych (zwinne i niezwinne, itp.) , są tylko adekwatne do sytuacji projektowej.
Nie ma sensu straszenie ludzie problemami inżynierii oprogramowania z przed 30 lat (metody strukturalne analizy i projektowania, kosztowny waterfall)!. Mamy dziś rok 2013, dobrze rozwinięte metody obiektowe analizy, projektowania, modelowania, implementacji. Aplikacje biznesowe można wręcz liniowo tworzyć i rozwijać, wystarczy chcieć przejść na inne metody pracy niż te, których (niestety) nadal uczą na studiach: „funkcje + struktury danych = oprogramowanie” bo to prehistoria.
Tak zwane projekty internetowe to także oprogramowanie, tu także obowiązują „prawa fizyki i ekonomii oraz rozsądek”. Jeżeli coś je odróżnia o innych to użyta technologia „internetowa” a i to coraz mniej, bo obecne oprogramowanie biznesowe to coraz częściej„system dostępny przez internet”…
Na pewno wszelkie start-up’y to projekty „inne”, ale to wynika z ich natury biznesowej (ryzyko powodzenia) a nie technologicznej. Mylenie tych pojęć prowadzi do wniosku, że np. nowy samochód prototypowy konstruuje się inaczej niż „standardowy”.…nie, inaczej planuje się finansowanie ale deska kreślarska pozostaje ta sama…
A na tytułowe pytanie odpowiedź brzmi: nie istnieje taki problem.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Strona używa plików cookie, aby zapewnić Ci wygodę przeglądania poprzez zapamiętywanie Twoich preferencji i powtarzających się wizyt. Klikając "Akceptuj wszystko", wyrażasz zgodę na użycie WSZYSTKICH plików cookie. Jednakże, możesz odwiedzić "Ustawienia plików cookie", aby zapewnić kontrolowaną zgodę.
Ta strona korzysta z plików cookie, aby poprawić wygodę podczas podczas przeglądania witryny. Pliko cookie, które są sklasyfikowane jako niezbędne, są przechowywane w przeglądarce, ponieważ są niezbędne do działania podstawowych funkcji witryny. Używamy również plików cookie stron trzecich, które pomagają nam analizować i zrozumieć, w jaki sposób korzystasz z tej witryny. Te pliki cookie będą przechowywane w przeglądarce tylko za Twoją zgodą. Możesz również zrezygnować z tych plików cookie. Ale rezygnacja z niektórych z tych plików cookie może mieć wpływ na wygodę przeglądania.
Niezbędne pliki cookie są absolutnie niezbędne do prawidłowego funkcjonowania witryny. Ta kategoria obejmuje tylko pliki cookie, które zapewniają podstawowe funkcje i zabezpieczenia strony. Te pliki cookie nie przechowują żadnych danych osobowych.
Wszelkie pliki cookie, które mogą nie być szczególnie potrzebne do działania witryny i są wykorzystywane w szczególności do gromadzenia danych osobowych użytkowników za pośrednictwem analiz, reklam i innych treści osadzonych, są określane jako niepotrzebne pliki cookie. Wymagane jest uzyskanie zgody użytkownika przed uruchomieniem tych plików cookie w witrynie.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Cookie
Duration
Description
__atuvc
1 year 1 month
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
__atuvs
30 minutes
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
bcookie
2 years
LinkedIn sets this cookie from LinkedIn share buttons and ad tags to recognize browser ID.
bscookie
2 years
LinkedIn sets this cookie to store performed actions on the website.
language
session
This cookie is used to store the language preference of the user.
lidc
1 day
LinkedIn sets the lidc cookie to facilitate data center selection.
na_id
1 year 24 days
The na_id is set by AddThis to enable sharing of links on social media platforms like Facebook and Twitter.
ouid
1 year 24 days
Associated with the AddThis widget, this cookie helps users to share content across various networking and sharing forums.
vc
1 year 24 days
The vc cookie is set by addthis.com on sites that allow sharing on social media.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Cookie
Duration
Description
at-rand
never
AddThis sets this cookie to track page visits, sources of traffic and share counts.
browser_id
5 years
This cookie is used for identifying the visitor browser on re-visit to the website.
CONSENT
2 years
YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data.
uid
1 year 24 days
This is a Google UserID cookie that tracks users across various website segments.
uvc
1 year 1 month
Set by addthis.com to determine the usage of addthis.com service.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Cookie
Duration
Description
di2
1 year 24 days
AddThis sets this cookie on sites that allow sharing on social media. It is used to track user behaviour anonymously, to create usage trends that will improve relevance to their services and advertising.
loc
1 year 1 month
AddThis sets this geolocation cookie to help understand the location of users who share the information.
um
1 year 24 days
Set by AddThis for registering the user's sharing of content through social media.
VISITOR_INFO1_LIVE
5 months 27 days
A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface.
YSC
session
YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages.
yt-remote-connected-devices
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt-remote-device-id
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt.innertube::nextId
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.
yt.innertube::requests
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.