Dziś nie można sobie wyobrazić procesu tworzenia złożonych aplikacji bez podziału na etapy cyklu życia. Przez cykl życia programu rozumiemy zbiór etapów:

• Analiza obszaru tematycznego i tworzenie specyfikacji technicznych (interakcja z klientem)
• Projektowanie struktury programu
• Kodowanie (zestaw kodu programu zgodnie z dokumentacją projektową)
• Testowanie i debugowanie
• Realizacja programu
• Wsparcie programu
• Sprzedaż

Przyjrzyjmy się bliżej procesowi projektowania. W procesie projektowania architekt lub doświadczony programista tworzy dokumentację projektową zawierającą opisy tekstowe, schematy i modele przyszłego programu. W tym trudnym zadaniu pomoże nam język UML.

UML to graficzny język służący do wizualizacji, opisu parametrów, projektowania i dokumentowania różnych systemów (w szczególności programów). Diagramy tworzone są przy użyciu specjalnych narzędzi CASE, takich jak Rational Rose (http://www-01.ibm.com/software/rational/) i Enterprise Architect (http://www.sparxsystems.com.au/). Oparty na technologii UML, ujednolicony model informacyjny. Powyższe narzędzia CASE potrafią generować kod w różnych językach obiektowych, a także mają bardzo przydatna funkcja inżynieria odwrotna. (Inżynieria odwrotna umożliwia utworzenie modelu graficznego na podstawie istniejącego kodu programu i komentarzy do niego.)

Przyjrzyjmy się rodzajom diagramów do wizualizacji modelu (jest to pozycja obowiązkowa, chociaż typów jest znacznie więcej):

Diagram przypadków użycia

Zaprojektowany system reprezentowany jest jako zbiór podmiotów lub aktorów wchodzących w interakcję z systemem za pomocą tzw. precedensów. W tym przypadku aktorem lub aktorem jest dowolny podmiot, który wchodzi w interakcję z systemem z zewnątrz. Innymi słowy, każdy przypadek użycia definiuje pewien zestaw akcji wykonywanych przez system podczas dialogu z aktorem. Nie mówi się jednak nic o tym, w jaki sposób będzie realizowana interakcja aktorów z systemem.

diagram klas

Diagram klas służy do przedstawienia statycznej struktury modelu systemu w terminologii klas programowania obiektowego. Diagram klas może odzwierciedlać w szczególności różne relacje pomiędzy poszczególnymi jednostkami domeny, takimi jak obiekty i podsystemy, a także opisuje ich wewnętrzną strukturę (pola, metody...) i typy relacji (dziedziczenie, implementacja interfejsów... ). Diagram ten nie dostarcza informacji na temat aspektów czasowych działania systemu. Z tego punktu widzenia diagram klas jest dalszym rozwinięciem modelu koncepcyjnego projektowanego systemu. Na tym etapie niezbędna jest znajomość podejścia OOP i wzorców projektowych.

diagram stanu

Głównym celem tego diagramu jest opisanie możliwych sekwencji stanów i przejść, które łącznie charakteryzują zachowanie elementu modelu podczas jego cyklu życia. Diagram stanu przedstawia dynamiczne zachowanie podmiotów w oparciu o specyfikację ich reakcji na postrzeganie określonych zdarzeń.

Diagram sekwencyjny

Do modelowania interakcji obiektów w języku UML wykorzystuje się odpowiednie diagramy interakcji. Interakcje obiektów można przeglądać w czasie, a następnie stosuje się diagram sekwencji do przedstawienia czasu transmisji i odbioru wiadomości między obiektami. Oddziałujące na siebie obiekty wymieniają między sobą pewne informacje. W tym przypadku informacja ma postać wypełnionych wiadomości. Innymi słowy, choć przekaz ma treść informacyjną, zyskuje dodatkową właściwość wywierania ukierunkowanego wpływu na odbiorcę.

Schemat współpracy

Na schemacie współpracy obiekty biorące udział w interakcji są przedstawione w formie prostokątów, zawierających nazwę obiektu, jego klasę i ewentualnie wartości atrybutów. Podobnie jak diagram klas, powiązania między obiektami są wskazywane w postaci różnych linii łączących. W tym przypadku można jawnie określić nazwy powiązań i role, jakie pełnią obiekty w tym powiązaniu.
W przeciwieństwie do diagramu sekwencji, diagram współpracy przedstawia jedynie relacje pomiędzy obiektami, które pełnią określone role w interakcji.

Schemat komponentów

Diagram składowy, w odróżnieniu od wcześniej omawianych diagramów, opisuje cechy fizycznej reprezentacji układu. Diagram komponentów pozwala na zdefiniowanie architektury tworzonego systemu poprzez ustalenie zależności pomiędzy komponentami oprogramowania, którymi może być kod źródłowy, binarny i wykonywalny. W wielu środowiskach programistycznych moduł lub komponent odpowiada plikowi. Kropkowane strzałki łączące moduły pokazują zależności współzależności podobne do tych, które występują podczas kompilacji kodu źródłowego programu. Głównymi elementami graficznymi diagramu komponentów są komponenty, interfejsy i zależności między nimi.

Schemat wdrożenia

Diagram wdrażania ma na celu wizualizację elementów i komponentów programu, które istnieją tylko na etapie wykonywania. W tym przypadku reprezentowane są tylko komponenty instancji programu, które są plikami wykonywalnymi lub bibliotekami dynamicznymi. Te komponenty, które nie są używane w czasie wykonywania, nie są pokazane na diagramie wdrażania.
Diagram wdrożenia zawiera obrazy graficzne procesory, urządzenia, procesy i połączenia między nimi. W przeciwieństwie do logicznych diagramów reprezentacji, diagram wdrożenia jest jednolity dla systemu jako całości, ponieważ musi w pełni odzwierciedlać cechy jego implementacji. Ten diagram zasadniczo kończy proces OOAP dla konkretnego systemu oprogramowania a jego opracowanie jest zwykle ostatnim etapem specyfikacji modelu.

Na tym kończy się nasz przegląd diagramów w szczególności i projektowania w ogóle. Warto zaznaczyć, że proces projektowania już dawno stał się standardem przy tworzeniu oprogramowania, jednak często trzeba mieć do czynienia ze znakomicie napisanym programem, który z powodu braku normalnej dokumentacji zostaje zarośnięty niepotrzebnymi funkcjonalnościami pobocznymi, kulami, staje się uciążliwy i traci swoją dawną jakość. =(

Jestem przekonany, że programista to przede wszystkim koder – NIE powinien komunikować się z klientem, NIE powinien myśleć o architekturze systemu, nie powinien wymyślać interfejsu do programu, powinien jedynie kodować – wdrażać algorytmy, funkcjonalność, wygląd, użyteczność, ale nic więcej... Projektant musi, zaczynając od abstrakcyjnych diagramów (opisujących obszar tematyczny) aż po diagramy przedstawiające strukturę danych, klas i procesów ich interakcji, wszystko szczegółowo opisać krok po kroku. Oznacza to, że złożoność pracy i wynagrodzenie projektanta powinny być o rząd wielkości wyższe niż programisty == kodera. Przepraszam za bunt....

Rozwój oprogramowania zna wiele godnych uwagi metodologii - innymi słowy, ustalonych najlepszych praktyk. Wybór zależy od specyfiki projektu, systemu budżetowania, subiektywnych preferencji, a nawet temperamentu menadżera. W artykule opisano metodologie, z którymi regularnie spotykamy się w Edison.

1. „Model wodospadu” (model kaskadowy lub „wodospad”)

Jedna z najstarszych polega na sekwencyjnym przechodzeniu etapów, z których każdy musi zostać całkowicie ukończony, zanim rozpocznie się następny. Model Waterfall ułatwia zarządzanie projektem. Dzięki swojej sztywności rozwój przebiega szybko, koszt i termin realizacji są z góry określone. Ale to jest miecz obosieczny. Model kaskadowy da doskonałe rezultaty tylko w projektach z jasno i z góry określonymi wymaganiami oraz sposobami ich realizacji. Nie ma możliwości cofnięcia się o krok; testowanie rozpoczyna się dopiero po zakończeniu lub prawie zakończeniu prac rozwojowych. Produkty opracowane według tego modelu bez uzasadnionego wyboru mogą posiadać wady (listy wymagań nie można w żadnym momencie modyfikować), które wychodzą na jaw dopiero na końcu ze względu na ścisłą kolejność działań. Koszt wprowadzenia zmian jest wysoki, gdyż z ich rozpoczęciem trzeba poczekać do zakończenia całego projektu. Jednak koszty stałe często przewyższają wady tego podejścia. Korygowanie braków powstałych w procesie produkcyjnym jest możliwe i z naszego doświadczenia wynika, że ​​wymaga od jednego do trzech dodatkowych uzgodnień do zamówienia z niewielką specyfikacją techniczną.

Wykorzystując model wodospadu stworzyliśmy od podstaw wiele projektów łącznie z opracowaniem specyfikacji technicznych. Projekty o których pisano na Habré: średni - , mały - .

Kiedy stosować metodologię wodospadu?

• Tylko wtedy, gdy wymagania są znane, rozumiane i zarejestrowane. Nie ma sprzecznych wymagań.
• Nie ma problemów z dostępnością programistów o wymaganych kwalifikacjach.
• W stosunkowo małych projektach.

2. „Model V”

Odziedziczyłem strukturę „krok po kroku” z modelu kaskadowego. Model w kształcie litery V ma zastosowanie w układach, dla których szczególnie ważna jest nieprzerwana praca. Na przykład, programy użytkowe w klinikach do monitorowania pacjentów, zintegrowane oprogramowanie do mechanizmów sterujących awaryjnymi poduszkami powietrznymi w pojazdach i tak dalej. Cechą szczególną modelu jest to, że ma on na celu dokładne sprawdzenie i przetestowanie produktu, który jest już w początkowej fazie projektowania. Etap testowania odbywa się jednocześnie z odpowiadającym mu etapem rozwoju, na przykład testy jednostkowe są pisane podczas kodowania.

Przykład naszej pracy w oparciu o metodologię V - Aplikacja mobilna dla Europejczyków operator mobilny, co pozwala zaoszczędzić koszty roamingu podczas podróży. Projekt realizowany jest według jasnej specyfikacji, ale obejmuje istotny etap testów: wygody interfejsu, funkcjonalności, obciążenia, łącznie z integracją, co powinno potwierdzić, że kilka podzespołów różnych producentów ze sobą stabilnie współpracuje, kradzież pieniędzy i pożyczek jest wykluczona. niemożliwe.

Kiedy stosować model V?

• Jeśli wymagane jest dokładne przetestowanie produktu, model V uzasadni swoją nieodłączną ideę: walidację i weryfikację.
• Dla małych i średnich projektów, w których wymagania są jasno określone i stałe.
• W warunkach dostępności inżynierów posiadających niezbędne kwalifikacje, zwłaszcza testerów.

3. „Model przyrostowy” (model przyrostowy)

W modelu przyrostowym kompletne wymagania systemowe są podzielone na różne zespoły. Terminologia jest często używana do opisania montażu oprogramowania krok po kroku. Ma miejsce kilka cykli rozwojowych, które razem tworzą cykl życia wielu wodospadów. Cykl podzielony jest na mniejsze, łatwe w tworzeniu moduły. Każdy moduł przechodzi przez fazy definiowania wymagań, projektowania, kodowania, wdrażania i testowania. Procedura rozwoju według modelu przyrostowego polega na wypuszczeniu produktu z podstawową funkcjonalnością na pierwszym dużym etapie, a następnie sukcesywnie dodawaniu nowych funkcji, tzw. „przyrostów”. Proces trwa aż do stworzenia kompletnego systemu.

Modele przyrostowe stosuje się tam, gdzie indywidualne żądania zmian są jasne i można je łatwo sformalizować i wdrożyć. W naszych projektach wykorzystaliśmy go do stworzenia czytnika DefView, a następnie sieci bibliotek elektronicznych Vivaldi.

Jako przykład opiszemy istotę jednego przyrostu. zastąpił DefView. DefView podłączony do jednego serwera dokumentów i może teraz łączyć się z wieloma. Serwer magazynujący instalowany jest w siedzibie instytucji, która chce udostępnić swoje treści określonej grupie odbiorców, która bezpośrednio uzyskuje dostęp do dokumentów i konwertuje je do wymaganego formatu. Pojawił się główny element architektury – centralny serwer Vivaldi, działający jako pojedynczy wyszukiwarka na wszystkich serwerach pamięci masowej zainstalowanych w różnych instytucjach.

Kiedy stosować model przyrostowy?

• Kiedy podstawowe wymagania dotyczące systemu są jasno określone i zrozumiałe. Jednocześnie z czasem niektóre szczegóły mogą zostać doprecyzowane.
• Wymagane jest wcześniejsze wprowadzenie produktu na rynek.
• Istnieje kilka ryzykownych cech lub celów.

4. „Model RAD” (model szybkiego tworzenia aplikacji lub szybkiego tworzenia aplikacji)

Model RAD jest rodzajem modelu przyrostowego. W modelu RAD komponenty lub funkcje są opracowywane równolegle przez kilka wysoko wykwalifikowanych zespołów, niczym kilka miniprojektów. Ramy czasowe jednego cyklu są ściśle ograniczone. Powstałe moduły są następnie łączone w jeden działający prototyp. Synergy pozwala bardzo szybko przedstawić klientowi coś działającego do sprawdzenia w celu uzyskania informacji zwrotnej i wprowadzenia zmian.

Model szybkiego tworzenia aplikacji obejmuje następujące fazy:

• Modelowanie biznesowe: zdefiniowanie listy przepływów informacji pomiędzy różnymi działami.
• Modelowanie danych: informacje zebrane w poprzednim etapie służą do określenia obiektów i innych podmiotów niezbędnych do obiegu informacji.
• Modelowanie procesów: przepływy informacji łączą obiekty w celu osiągnięcia celów programistycznych.
• Zbuduj aplikację: wykorzystuje zautomatyzowane narzędzia do montażu w celu konwersji modeli CAD na kod.
• Testowanie: testowane są nowe komponenty i interfejsy.

Kiedy stosuje się model RAD?

Może być stosowany wyłącznie przez wysoko wykwalifikowanych i wysoce wyspecjalizowanych architektów. Budżet projektu jest duży, aby opłacić tych specjalistów wraz z kosztem gotowych narzędzi do automatycznego montażu. Model RAD można wybrać mając pewność, że znamy docelowy biznes i potrzebę pilnej produkcji systemu w ciągu 2-3 miesięcy.

5. „Model Agile” (elastyczna metodyka rozwoju)

W „zwinnej” metodyce rozwoju, po każdej iteracji klient może obserwować wynik i rozumieć, czy go satysfakcjonuje, czy nie. To jedna z zalet modelu elastycznego. Do jego wad można zaliczyć fakt, że ze względu na brak konkretnych sformułowań wyników trudno jest oszacować koszty pracy i koszty niezbędne do rozwoju. Extreme Programming (XP) to jedno z najbardziej znanych zastosowań modelu zwinnego w praktyce.

Ten typ opiera się na krótkich codziennych spotkaniach – „Scrum” oraz regularnie powtarzających się spotkaniach (raz w tygodniu, raz na dwa tygodnie lub raz w miesiącu), zwanych „Sprintem”. Podczas codziennych spotkań członkowie zespołu omawiają:

• raport z pracy wykonanej od ostatniego Scruma;
• lista zadań, które pracownik musi wykonać przed kolejnym spotkaniem;
• trudności napotkane w trakcie pracy.

Metodologia jest odpowiednia dla dużych projektów lub tych, które mają długi cykl życia, stale dostosowując się do warunków rynkowych. W związku z tym wymagania zmieniają się w trakcie procesu wdrażania. Warto pamiętać o klasie ludzi kreatywnych, którzy mają tendencję do generowania, wymyślania i wypróbowywania nowych pomysłów raz w tygodniu, a nawet codziennie. Zwinny rozwój najlepiej nadaje się dla tego typu menedżerów. Rozwijamy wewnętrzne start-upy firmy w oparciu o Agile. Przykładowym projektem klienta jest Elektroniczny System Badań Lekarskich, stworzony z myślą o przeprowadzaniu masowych badań lekarskich w ciągu kilku minut. W drugim akapicie tej recenzji nasi amerykańscy partnerzy opisali bardzo ważną rzecz, która jest podstawą sukcesu w Agile.

Kiedy stosować Agile?

• Gdy potrzeby użytkowników stale się zmieniają w dynamicznym biznesie.
• Zwinne zmiany są wdrażane niższym kosztem ze względu na częste przyrosty.
• W przeciwieństwie do modelu kaskadowego, model zwinny wymaga jedynie niewielkiego planowania, aby rozpocząć projekt.

6. „Model iteracyjny” (model iteracyjny lub iteracyjny)

Iteracyjny model cyklu życia nie wymaga na początku pełnej specyfikacji wymagań. Zamiast tego tworzenie rozpoczyna się od wdrożenia fragmentu funkcjonalności, który staje się podstawą do zdefiniowania dalszych wymagań. Ten proces się powtarza. Wersja może nie jest idealna, najważniejsze, że działa. Rozumiejąc ostateczny cel, dążymy do niego, aby każdy krok był skuteczny, a każda wersja wykonalna.

Diagram przedstawia iteracyjny „rozwój” Mony Lisy. Jak widać, w pierwszej iteracji jest tylko szkic Mony Lisy, w drugiej pojawiają się kolory, a trzecia iteracja dodaje szczegóły, nasycenie i kończy proces. W modelu przyrostowym funkcjonalność produktu budowana jest kawałek po kawałku, produkt składa się z części. W przeciwieństwie do modelu iteracyjnego, każdy element reprezentuje kompletny element.

Przykładem rozwoju iteracyjnego jest rozpoznawanie głosu. Pierwsze badania i przygotowanie aparatu naukowego rozpoczęły się dawno temu, najpierw w myślach, potem na papierze. Z każdą nową iteracją jakość rozpoznawania poprawiała się. Jednak nie osiągnięto jeszcze doskonałego rozpoznania, dlatego problem nie został jeszcze całkowicie rozwiązany.

Kiedy najlepiej zastosować model iteracyjny?

• Wymagania dotyczące ostatecznego systemu są z góry jasno określone i zrozumiałe.
• Projekt jest duży lub bardzo duży.
• Należy określić główny cel, ale szczegóły realizacji mogą z czasem ulec zmianie.

7. „Model spiralny” (model spiralny)

„Model spiralny” jest podobny do modelu przyrostowego, ale z naciskiem na analizę ryzyka. Dobrze sprawdza się przy rozwiązywaniu krytycznych problemów biznesowych, gdy porażka jest nie do pogodzenia z działalnością firmy, w kontekście wypuszczenia na rynek nowych linii produktowych, gdy konieczne są badania naukowe i testy praktyczne.

Model spiralny obejmuje 4 etapy na każdą turę:

1. planowanie;
2. ocena ryzyka;
3. projekt;
4. ocena wyniku i, jeśli jakość jest zadowalająca, przejście do nowego etapu.

Model ten nie sprawdza się w przypadku małych projektów, sprawdza się w przypadku skomplikowanych i kosztownych, np. opracowania systemu obiegu dokumentów dla banku, gdzie każdy kolejny krok wymaga więcej analiz w celu oceny skutków niż programowania. W przypadku projektu opracowania EDMS dla ODU Syberii SO UES dwa spotkania dotyczące zmiany kodyfikacji sekcji archiwum elektronicznego zajmują 10 razy więcej czasu niż połączenie dwóch folderów przez programistę. Projekty rządowe, w których braliśmy udział, zaczynały się od przygotowania przez środowisko eksperckie kosztownej koncepcji, która nie zawsze jest bezużyteczna, bo opłaca się w skali kraju.

Podsumujmy

Slajd pokazuje różnice pomiędzy dwiema najpopularniejszymi metodologiami.

We współczesnej praktyce modele wytwarzania oprogramowania są wielowymiarowe. Nie ma jednego, odpowiedniego modelu dla wszystkich projektów, warunków początkowych i modeli płatności. Nawet tak ukochany przez nas wszystkich Agile nie da się zastosować wszędzie ze względu na nieprzygotowanie części klientów lub brak możliwości elastycznego finansowania. Metodyki częściowo pokrywają się pod względem środków, a częściowo są do siebie podobne. Niektóre inne koncepcje zostały wykorzystane jedynie w celu promowania własnych kompilatorów i nie wniosły niczego nowego do praktyki.

O technologiach deweloperskich:
.
.
.
.

Z jakich metodologii korzystasz?