Jak tworzyć oprogramowanie? Jakie są specjaliści w swoich działaniach? Ważne metody opracowywania oprogramowania są ważne w tej dziedzinie. Omówimy niektóre z nich w tym artykule, koncentrując się szczegółowo na zadaniach, etapach, ważnych zasadach i różnicach tych metodologii.

Co to jest?

Zacznijmy od artykułu definicji. Metodologia tworzenia oprogramowania to zestaw zasad, system pomysłów, koncepcji, metod, metod i narzędzi, które ostatecznie określają styl tworzenia oprogramowania. Innymi słowy, metodologia jest tutaj implementacją określonego standardu. Co ważne, standardy tutaj są zalecane, a nie uporządkowane, tak jak być powinno. Dlatego przed twórcą zachowana jest wolność wyboru, adaptacja teorii. Konkretne produkty są wdrażane za pomocą metodologii opracowywania oprogramowania. Ona określi, w jaki sposób specjalista wykona swoją pracę. Dzisiaj istnieje wiele takich metodologii - główne z nich rozważymy w trakcie materiału. Co wpływa na ich wybór tylko jeden? Rozróżnia się wielkość zespołu, złożoność i specyfikę danego projektu, dojrzałość i stabilność procesów w firmie-pracodawcy, osobiste preferencje twórcy.


Tak więc metodologia jest rdzeniem teorii zarządzania rozwojem dowolnego oprogramowania. W przeszłości stosowali klasyfikację, która dzieliła wszystkie metodologie na dwa typy: iteracyjny i wodospad (oparty nazastosowane modele cyklu życia). Obecnie stosowana jest nowoczesna klasyfikacja ogólna, która jest również podzielona na dwie grupy: przewidywalną i adaptacyjną. Zapoznaj się z nimi bardziej szczegółowo.

Metodyka prognoz

Jakie są dane metodologii opracowywania oprogramowania? Są to odmiany, które koncentrują się na szczegółowym planowaniu przyszłości. Zadania i zasoby są znane przez cały czas trwania projektu. Dlatego zespół roboczy będzie trudny w reagowaniu na nieoczekiwane zmiany.


Plan składa się ze składu niezbędnej pracy, wymagań dla nich. W związku z tym zmiana wymagań prowadzi do zmiany całego planu, projektu. W przypadku przewidywanych metodologii zwykle jest to utworzenie specjalnej komisji zarządzającej zmianami, tak aby projekt uwzględniał tylko najważniejsze wymagania.

Metodyki adaptacyjne

Jaka jest szczególna cecha tych metodologii opracowywania oprogramowania komputerowego? Mają już na celu przezwyciężenie oczekiwanej niedoskonałości, niekompletności wymagań i ciągłej zmiany tych ostatnich. W związku z tym zmiana wymagań zostanie zastąpiona przez zespół twórców projektów. Dokładny plan metodologii adaptacyjnej opracowywany jest tylko w bliskiej przyszłości. Plany, które są bardziej odległe od rzeczywistości wydarzeń, istnieją w postaci deklaracji o celu pracy, jej wynikach i przewidywanych kosztach.

Elastyczne metodologie

Elastyczne metodologie opracowywania oprogramowania - język angielski. Zwinne tworzenie oprogramowania. Stąd też drugie imię: zwinne metody. Elastyczne metodyki opracowywania oprogramowania sąkompleks podejść do rozwoju oprogramowania, ukierunkowany na wykorzystanie iteracyjnego rozwoju, dynamiczne formowanie wymagań dla projektu, zapewnienie wdrożenia końca ciągłej interakcji w pracującym samoorganizującym się zespole, złożonym ze specjalistów o różnych profilach.
Jest to przede wszystkim skuteczna praktyka pracy małych zespołów zaangażowanych w ten sam rodzaj twórczości. W połączeniu z połączoną (demokratyczną i liberalną) metodą zarządzania. Elastyczne metody opracowywania oprogramowania mają na celu zminimalizowanie ryzyka poprzez połączenie wspólnego projektu z kompleksem krótkich cykli (tzw. Iteracji), z których każda trwa tak długo, jak 2-3 tygodnie. Ta iteracja to mały projekt programu, który zawiera wszystkie zadania zapewniające funkcjonalny mini-wzrost. Jako takie: planowanie, analiza wymagań, projektowanie, programowanie, testowanie rozwoju, dokumentacja. Oczywiście oddzielna iteracja tutaj nie wystarcza do wydania końcowego produktu. Oto inne znaczenie. Pod koniec każdej iteracji elastyczny program jest gotowy. Pod koniec tego okresu zespół musi dokonać ponownej oceny priorytetów rozwojowych. Podczas każdej iteracji (etapy tworzenia oprogramowania) nacisk kładziony jest na bezpośrednią komunikację specjalistów "twarzą w twarz". Większość zespołów znajduje się w jednym biurze. Pamiętaj, aby mieć "klienta" - przedstawiciela pełnomocnika, który stawia wymagania dotyczące rozwoju. Ta rola jest zarządzana przez menedżeraprojekt, klient-klient, analityk biznesowy. Biuro może również obejmować testerów, twórców technicznych, projektantów interfejsu itp.
Głównym wskaźnikiem jest tutaj produkt końcowy. Dodatkowo bezpośrednia komunikacja specjalistów polega na tym, że istnieje stosunkowo niewielka ilość towarzyszącej dokumentacji pisemnej.

Zwinny Manifest

Spójrzmy na podstawowe standardy tworzenia oprogramowania. Pierwszy to zestaw procesów rozwojowych zwanych Agile. Jest on określony w Manifeście zwinnym. Ważne jest, aby powiedzieć, że Agile nie zawiera praktycznych wskazówek, ale zawiera wartości i zasady, którymi powinien kierować się zespół programistów w swojej pracy. Manifest Agile został opracowany i przyjęty w dniach 1-13 lutego 2001 roku w ośrodku narciarskim w górach Utah. Zawiera 4 główne idee i 12 zasad pracy zespołowej bez jednej praktycznej tablicy. Wyobraź sobie podstawowe idee tej nowoczesnej metodyki tworzenia oprogramowania:

Interakcja i ludzie to najważniejsze narzędzia i procesy.

Działający produkt znajduje się powyżej obszernej dokumentacji.

Współpraca z klientem jest najważniejszą harmonizacją poszczególnych postanowień umownych.

Gotowość zespołu do zmiany jest ważniejsza niż realizacja wstępnych planów.

Również w Manifeście zwinnym wskazano następujące zasady działalności programisty:

Zaspokojenie żądań klientów ze względu na nieprzerwane dostarczanie wartościowej wartości.

Gratulujemy zmian wymagań nawet po zakończeniu projektu. W końcu może to zwiększyć jego konkurencyjność.

Częste dostawyoprogramowanie do pracy - co tydzień-miesiąc.

W projekcie zatrudniono osoby zmotywowane, zapewniające komfortowe warunki pracy, zaufanie i wsparcie.

Codzienne bliskie interakcje między klientem a zespołem programistów.

Oprogramowanie będzie najlepszą miarą postępu.

Użytkownicy, sponsorzy i deweloperzy muszą utrzymywać wybrane tempo przez czas nieokreślony.

Ciągłe zwracanie uwagi na ulepszanie projektu produktu, wymagań technicznych.

Prostota to sztuka nie angażowania się w zbyteczną pracę.

Stałe dostosowywanie się do zmieniających się warunków działania. Deweloperzy powinni stale znajdować sposoby na poprawę swojej wydajności, a następnie ich przestrzegać.

Model wodospadu

Z elastycznego manifestu metodologii tworzenia oprogramowania przenosimy się do nowego typu. Model wodospadu - "wodospad" lub model kaskadowy. Jedna z najstarszych metodologii. Obejmuje sekwencyjne przejście etapów tworzenia oprogramowania, z których każdy powinien zakończyć się przed rozpoczęciem kolejnego.

Ze względu na taką sztywność zarządzanie projektem w ramach tej metodologii jest łatwe. Koszt i harmonogram rozwoju są z góry określone, dlaczego praca jest szybka. Ważne jest jednak również zapamiętanie tego aspektu: model kaskadowy daje doskonały wynik tylko w projektach z wcześniej zdefiniowanymi jasno określonymi wymaganiami, metodami ich realizacji. Tutaj specjaliści nie mają szansy "oddać", ponieważ testowanie rozpoczyna się dopiero po zakończeniu fazy. Jeśli wybór takiego modelu nie jest uzasadnionyw przypadku produktu, to wyjście można zauważyć ze znacznymi wadami. Wszakże ich obecność będzie znana po zakończeniu pracy ze względu na ścisły ciąg czynności. Naprawianie błędów tutaj jest dość drogie. Aby rozpocząć łatkę, musisz poczekać na koniec rozwoju.
Eksperci zalecają stosowanie metody "wodospadowej" w następujących przypadkach:

Wymagania dotyczące projektu są znane, zrozumiałe i poprawione. Nie ma między nimi sprzeczności.

Nie ma problemu z uzyskaniem programistów o wymaganych kwalifikacjach.

Projekt jest stosunkowo niewielki.

V-Model

Etapy rozwoju oprogramowania są również spójne. Ta cecha V-Model "odziedziczyła" po "wodospadzie". Szczególnie dobry w tych systemach, w których wymagana jest płynna praca. Dobrym przykładem jest tworzenie oprogramowania aplikacyjnego dla klinik wykorzystywanych do ciągłego nadzoru pacjentów. Lub oprogramowanie kontrolujące mechanizmy poduszek powietrznych w pojazdach. Lub aplikacja dla operatora telefonii komórkowej, zaprojektowana w celu zaoszczędzenia na kosztach użytkownika za roaming w podróżach zagranicznych. Projekt jest realizowany w tym samym czasie w jasnych punktach zadania twórczego. Jednak ważną rolę odgrywa również terminowe testowanie: funkcjonalność, integracja, ładowanie, przyjazny interfejs użytkownika. Kiedy konieczne jest zastosowanie tej metodologii do opracowania:

W przypadkach, w których wymagane jest staranne badanie produktu.

W przypadku małych i średnich projektów o ściśle określonych wymaganiach.

Vwarunki, w których są dostępni inżynierowie, testerzy konkretnych kwalifikacji.

Model przyrostowy

W tej technologii tworzenia oprogramowania złożone wymagania systemu są podzielone na kompilację. Innymi słowy, jest to opis etapowej kompilacji. Kilka cykli rozwoju projektu znajduje się w kompleksie o nazwie "multi-waterfall". Cykl z kolei dzieli się na osobne, łatwe do utworzenia moduły. Każdy z nich przechodzi przez etapy definiowania wymagań, projektowania, implementacji, testowania, kodowania. Osobliwością jest tutaj to, że na pierwszym dużym etapie wydaje się podstawowy model rozwoju. Do tego dodawane są kolejne przyrosty - nowe funkcje. Taki proces trwa do momentu utworzenia pełnego kompleksu. Dodatkowy model jest dobry, gdy poszczególne wnioski o zmianę są jasne, można je po prostu sformalizować i wdrożyć. Opiszmy przypadki, w których zastosowanie modelu przyrostowego jest uzasadnione:

Jasno zdefiniowane i zrozumiałe wymagania dla produktu końcowego.

Dopuszczalne jest doprecyzowanie niektórych szczegółów w czasie.

Istnieje kilka ryzykownych celów.

Konieczny jest wczesny wniosek na rynku.

Model RAD

Natychmiast zauważ, że Model RAD jest jedną z odmian modelu przyrostowego. Składniki lub funkcje programu są opracowywane jednocześnie przez kilka zespołów profesjonalistów. Rezultatem jest kilka mini-projektów. Czas tworzenia każdego z nich jest ściśle ograniczony. Wszystkie moduły znajdują się w ogólnym działającym prototypie. System jest dobry, ponieważ pomaga szybko przedstawić klientowiPrzejrzyj działający produkt, a następnie dokonaj serii zmian. Proces tworzenia oprogramowania obejmuje kilka etapów:

Symulacja biznesowa. Jest to definicja przepływów informacji pomiędzy spektrum jednostek.

Symulacja informacji. Dane zebrane w pierwszym etapie służą do identyfikacji podmiotów niezbędnych do obiegu informacji.

Modelowanie procesów. Podczas tej fazy przepływy informacji łączą określone obiekty, aby osiągnąć cel rozwoju.

Przygotowanie programu. Tutaj używamy zespołów motoryzacyjnych do konwersji wzorców projektowych na kod.

Testowanie. Sprawdzanie nowych komponentów i interfejsów.

Stosuj tę metodę tworzenia oprogramowania tylko wtedy, gdy w zespole są wysoko wykwalifikowani i "wąscy" specjaliści. Budżet projektu jest z pewnością duży: konieczne jest opłacenie pracy profesjonalistów, koszt gotowych narzędzi automatycznego montażu. Model jest wybierany z pewną znajomością docelowego biznesu w przypadkach, gdy konieczne jest przedstawienie gotowych produktów krótkich terminów - w ciągu 2-3 miesięcy.

Model iteracyjny

Następujący przykład organizacji rozwoju oprogramowania jest iteracyjnym (lub iteracyjnym modelem). Specyfika projektu polega na tym, że nie wymaga on pełnej specyfikacji wymagań, aby rozpocząć jego wdrażanie. Tworzenie rozpoczyna się od zaprojektowania bazy danych, która powinna być podstawą do określenia dalszych wymagań. Wersja w tym przypadku może być zupełnie nieodpowiednia. Głównym wymogiem jest to, że działa.Deweloper rozumie i widzi ostateczny cel pracy. Musi dążyć do tego, aby każdy etap jego działalności był produktywny, a każda stworzona wersja była wykonalna. Z jakiegoś powodu tworzenie tutaj przypomina tworzenie obrazu: najpierw rysuje się szkic, potem jest wypełniony kwiatami, dodawane są szczegóły, nasycenie, odcienie przejścia, ostatnie dotknięcia - i proces się kończy. Coś przypomina model przyrostowy? Spójrzmy na różnicę. Zgodnie z metodologią przyrostową, produkt składa się z części i składa się z oprogramowania funkcjonalnego, zwanego w bitach. Ale w tym samym czasie każda część jest już integralnym elementem. A "kawałki" w modelu iteracyjnym nie mają autonomii. Kolejnym jaskrawym przykładem rozwoju oprogramowania z tej metodologii jest urządzenie do rozpoznawania głosu. Wszystko zaczęło się od przygotowania bazy naukowej. Następnie zebrano niezbędną dokumentację. Wraz z każdym nowym rozwojem wzrosła jakość sprzętu. Ale nie osiągnął jeszcze idealnego poziomu. Tak więc projekt nie został jeszcze ukończony. Zastosowanie modelu iteracyjnego jest uzasadnione w następujących przypadkach:

Wymagania dotyczące ostatecznej wersji opracowania są jasne i jasno określone.

Projekt jest bardzo duży.

Główne zadanie jest z góry określone. Ale poprawmy jej szczegóły, zmieńmy proces pracy.

Model spiralny

Model spiralny w dużej mierze przypomina poprzedni. Koncentruje się jednak na jeszcze jednym zadaniu tworzenia oprogramowania - ocenie ryzyka. Większość tej metodologii można wykorzystać do rozwiązywania krytycznych problemówzadania biznesowe, gdy awaria projektu może poważnie zaszkodzić działalności firmy. Model spiralny jest szeroko stosowany do wydawania nowych linii oprogramowania, jeśli to konieczne, do prowadzenia badań naukowych, testów praktycznych. Każdy z "zwojów spirali" przechodzi przez cztery fazy:

Planowanie.

Analiza ryzyka.

Konstrukcja.

Oszacowanie wyników. Jeśli jest pozytywna, programista przenosi się do nowego "wątku" projektu.

Modelu spiralnego nie należy stosować w przypadku niewielkich projektów budżetowych. Wręcz przeciwnie, jest bardziej odpowiedni na dużą skalę i drogi. Doskonały przykład zastosowania metodologii do opracowania systemu obiegu dokumentów bankowych. Tutaj wiele uwagi poświęca się nie tylko samemu programowaniu, ale analizie każdego już wyprodukowanego "zwrotu".

LD

Tak zwany zaawansowany rozwój oprogramowania. Jest to jedna z gałęzi elastycznej metodologii, którą zdemontowaliśmy powyżej. Główną zaletą LD: utrzymanie wysokiego stanu moralnego i funkcjonalnego specjalistów. W szczególności jest to następujące:

Zachęcanie każdego pracownika do szczególnie udanego działania.

Obecne cele projektu zmieniają się tylko w przypadku wyjątkowej konieczności lub na wniosek klienta.

Ścisła realizacja planu. Super-praca jest uważana za oznakę utraty czasu i zasobów.

Wdrażanie ogólnej koncepcji działania: "Szerokie myślenie, szybki błąd, mała praca, szybka nauka".

XP

Bardzo interesującym przykładem jest metodologia tzw. Ekstremumprogramowanie Co tu jest ukryte? Jest to rozwój w warunkach ciągle zmieniających się wymagań dla produktu. Kierunek metodologii ma następujące charakterystyczne cechy:

"Gra planszowa". Na początku pracy przedstawiono jedynie przybliżony plan. Na każdym kroku rozwoju jego ostrość rośnie.

Wysoka częstotliwość uwolnień. Oznacza to, że nowa wersja będzie miała tylko niewielką różnicę od poprzedniej, ale jej wydanie zajmie minimalnie czas.

Kontakt z klientem. W przypadku następującej metodologii ważne jest, aby szybko spełnić wszystkie wymagania klienta, aby szybko reagować na wszystkie jego uwagi i życzenia.

Refaktoryzacja. Jakość kodu poprawia się bez zmniejszania jego funkcjonalności.

Standardowe wykonanie kodu. W twarz lub zgodnie z ogólnymi zasadami lub brak rozbieżności w procesie rozwoju.

Zbiorowa odpowiedzialność. Tak więc każdy członek zespołu jest zajęty określonym obszarem pracy. Ale dla ogólnego wyniku cały zespół jest już odpowiedzialny.

FDD

I ostatnia metodologia w naszym artykule. Zapewnia skalowalność i powtarzalność. Ale jednocześnie zachęca do twórczego podejścia, zastosowania w dziele innowacji. Główne zasady metodologii są następujące:

Rozwój każdego dużego projektu jest systematyczną działalnością.

Wszystkie procesy powinny być proste i dobrze zaprojektowane.

Logikę i wartość każdego procesu powinien rozumieć każdy członek zespołu.

Zalety to krótkie cykle tworzenia oprogramowania. Pozwala to zmniejszyć ilośćbłędy, przy jednoczesnym zwiększeniu funkcjonalności.

Wartość metodologii i fakt, że wyraźnie reguluje ona długość procesów. W takim przypadku problemy organizacyjne w każdym cyklu nie powinny być wydawane więcej niż 25% czasu. Pozostałe 75% to wyłącznie opracowanie, kompilacja i testowanie funkcjonalności. Zakończymy podstawowym rozwojem oprogramowania. Jak widzieliście, cechy każdego z nich pozwalają wybrać odpowiednią metodologię dla pomyślnej realizacji najbardziej zróżnicowanych projektów.