Strona poświęcona mojej pracy naukowej i usługom jakie świadczę polskim podmiotom. Zapraszam tych którzy szukają wiedzy i tych którzy szukają wsparcia w swoich projektach informatyzacji.
Cyfrowa Transformacja Organizacji: analizy systemowe przedsiębiorstw, projektowanie rozwiązań i przygotowanie do wdrożeń systemów standardowych i dedykowanych.
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.
Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi 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. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).
Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione. Ewentualne użycie treści wymaga indywidualnej zgody autora.
Nie wykryto skryptu Javascript. Javascript wymagany do działania tej strony. Proszę włączyć go w ustawieniach przeglądarki i odświeżyć tę stronę.
Zarządzaj zgodami plików cookie
Aby zapewnić jak najlepsze wrażenia, korzystamy z technologii, takich jak pliki cookie, do przechowywania i/lub uzyskiwania dostępu do informacji o urządzeniu. Zgoda na te technologie pozwoli nam przetwarzać dane, takie jak zachowanie podczas przeglądania lub unikalne identyfikatory na tej stronie. Brak wyrażenia zgody lub wycofanie zgody może niekorzystnie wpłynąć na niektóre cechy i funkcje.
Funkcjonalne
Zawsze aktywne
Przechowywanie lub dostęp do danych technicznych jest ściśle konieczny do uzasadnionego celu umożliwienia korzystania z konkretnej usługi wyraźnie żądanej przez subskrybenta lub użytkownika, lub wyłącznie w celu przeprowadzenia transmisji komunikatu przez sieć łączności elektronicznej.
Preferencje
Przechowywanie lub dostęp techniczny jest niezbędny do uzasadnionego celu przechowywania preferencji, o które nie prosi subskrybent lub użytkownik.
Statystyka
Przechowywanie techniczne lub dostęp, który jest używany wyłącznie do celów statystycznych.Przechowywanie techniczne lub dostęp, który jest używany wyłącznie do anonimowych celów statystycznych. Bez wezwania do sądu, dobrowolnego podporządkowania się dostawcy usług internetowych lub dodatkowych zapisów od strony trzeciej, informacje przechowywane lub pobierane wyłącznie w tym celu zwykle nie mogą być wykorzystywane do identyfikacji użytkownika.
Marketing
Przechowywanie lub dostęp techniczny jest wymagany do tworzenia profili użytkowników w celu wysyłania reklam lub śledzenia użytkownika na stronie internetowej lub na kilku stronach internetowych w podobnych celach marketingowych.