Rozdział 5. Rozwój i rodzaje programów turystycznych Początkową funkcją biur podróży jest planowanie wycieczek. W procesie pełnienia tej funkcji powstaje konkurencyjny i atrakcyjny produkt turystyczny, aby go stworzyć

Jednym z podejść do tworzenia oprogramowania w ramach spiralnego modelu cyklu życia jest szeroko stosowana metodologia (technologia) szybkiego tworzenia aplikacji RAD (ang. Rapid Application Development). Ten model jest bardzo odpowiedni do rozwoju programy nauczania, ponieważ zawiera trzy komponenty:

Ø mały zespół programistów (od 2 do 10 osób);

Ø krótki, ale starannie opracowany harmonogram produkcji (od 2 do 6 miesięcy);

Ø cykl iteracyjny, w którym programiści, gdy aplikacja zaczyna nabierać kształtu, żądają i wdrażają do produktu wymagania otrzymane w wyniku interakcji z klientem.

Rozważmy ten model w szczegółach. Zespół programistów powinien stanowić grupa profesjonalistów doświadczonych w analizie, projektowaniu, generowaniu kodu i testowaniu oprogramowania przy użyciu narzędzi CASE, potrafiących dobrze współpracować z użytkownikami końcowymi i przekształcać ich sugestie w działające prototypy. Cykl życia oprogramowania według metodologii RAD składa się z cztery fazy(Rysunek 21):

1. Analiza i planowanie wymagań;

2. Projekt;

3. Konstrukcje;

4. Wdrożenia.

NA pierwsza faza analiza i planowanie wymagań użytkownicy systemu określają funkcje, jakie powinien on realizować, wyróżniają te o najwyższym priorytecie, które wymagają opracowania w pierwszej kolejności oraz opisują potrzeby informacyjne (połączenia). Formułowanie wymagań systemowych odbywa się głównie przez użytkowników pod okiem wyspecjalizowanych programistów. Zakres projektu jest ograniczony, a dla każdej kolejnej fazy określone są ramy czasowe. Dodatkowo sama możliwość realizacji projektu w podane rozmiary finansowania, na istniejącym sprzęcie itp.

Wynikiem tej fazy powinno być: listę priorytetowych funkcji przyszłego PS; wstępny model funkcjonalny PS; wstępny model informacyjny PS.

NA druga faza projekt Część użytkowników bierze udział w projektowaniu technicznym systemu pod okiem wyspecjalizowanych programistów i wchodząc z nimi w interakcję wyjaśnia i uzupełnia wymagania dla systemu, które nie zostały zidentyfikowane w poprzedniej fazie. Omówiono bardziej szczegółowo procesy systemowe. W razie potrzeby dopasowuje się model funkcjonalny, powstają częściowe prototypy: screeny, raporty, eliminując niejasności czy niejasności. Wymagania są ustalone ograniczenia dostępu do danych. Na tym samym etapie ustalana jest niezbędna dokumentacja. Po szczegółowym ustaleniu składu procesów, liczba elementy funkcjonalne tworzonego systemu i podjęta zostaje decyzja o podziale systemu na podsystemy.

Rezultatami tej fazy powinny być: ogólny model informacyjny systemu; modele funkcjonalne systemy jako całość i podsystemy; precyzyjnie zdefiniowane interfejsy pomiędzy autonomicznie rozwijanymi podsystemami; zbudowano prototypy ekranów, raportów, okien dialogowych.

W przeciwieństwie do tradycyjnego podejścia, które wykorzystywało określone narzędzia do prototypowania, nieprzeznaczone do tworzenia aplikacji w świecie rzeczywistym, i odrzucało prototypy, gdy służyły wyjaśnieniu niejasności projektowych, W podejściu RAD każdy prototyp jest rozwijany jako część przyszłego systemu. W ten sposób pełniejsze i przydatne informacje są przekazywane do następnej fazy.

NA trzecia faza budowa Szybki rozwój samej aplikacji (wdrażanie podsystemów) odbywa się bezpośrednio. Na tym etapie programiści przeprowadzają konstrukcję iteracyjną prawdziwy system w oparciu o modele uzyskane w poprzedniej fazie, a także wymagania pozafunkcjonalne. Na tym etapie użytkownicy końcowi oceniają uzyskane wyniki i wprowadzają korekty, jeśli w trakcie procesu rozwoju system nie spełnia już wcześniej zdefiniowanych wymagań. Testowanie systemu odbywa się w procesie rozwoju.

Po zakończeniu opracowywania podsystemów ta część systemu jest stopniowo integrowana z resztą, generowany jest kompletny kod programu i testowany jest system jako całość. Fizyczny projekt systemu jest gotowy: określa się potrzebę dystrybucji danych; przeprowadzana jest analiza wykorzystania danych; przeprowadzany jest fizyczny projekt bazy danych; określane są wymagania dotyczące zasobów sprzętowych; określa się sposoby zwiększenia produktywności; Zakończono opracowywanie dokumentacji projektowej.

Wynik fazy to kompletny system spełniający wszystkie ustalone wymagania.

NA czwarta faza realizacja przeprowadzane są szkolenia użytkowników, zmiany organizacyjne i równolegle z wdrożeniem nowy system praca jest wykonywana z istniejący system(do czasu pełnego wdrożenia nowego). Ponieważ faza budowy jest dość krótka, planowanie i przygotowanie do wdrożenia należy rozpocząć wcześnie, zwykle na etapie projektowania systemu.

Technologia RAD (jak każda inna) nie może pretendować do miana uniwersalności, sprawdza się przede wszystkim w przypadku stosunkowo niewielkich projektów realizowanych pod konkretnego klienta. Nie ma zastosowania do rozwoju system operacyjny; złożone programy obliczeniowe o dużej objętości kod programu i złożone unikalne algorytmy sterowania; aplikacje, w których brakuje wyraźnego część interfejsu, co jasno definiuje logikę systemu (aplikacja w czasie rzeczywistym), gdyż podejście iteracyjne zakłada, że ​​kilka pierwszych wersji nie będzie w pełni spełniać wymagań.

Podsumowując, wymieniamy podstawowe zasady technologii RAD:

Ø rozwój aplikacji w iteracjach;

Ø opcjonalne zakończenie prac na każdym etapie cyklu życia;

Ø obowiązkowe zaangażowanie użytkowników na etapie rozwoju;

Ø wykorzystanie prototypowania w celu wyjaśnienia i spełnienia wszystkich wymagań użytkownik końcowy;

Ø testowanie i rozwój projektu jednocześnie z rozwojem;

Ø kompetentne zarządzanie rozwojem, jasne planowanie i kontrola wykonania pracy.

Pytania kontrolne do rozdziału 3:

1. Czym jest standaryzacja i certyfikacja Produkt oprogramowania?

2. Jakie rodzaje standardów istnieją?

3. Wymień najbardziej znane standardy koło życia które zostały użyte do opracowania oprogramowania?

4. Jaki jest cykl życia oprogramowania?

5. Wymień główne etapy cyklu życia oprogramowania. Czym jest proces, działanie, zadanie?

6. Jakie rodzaje procesów i konkretne procesy pamiętasz?

7. Wyjaśniać podstawowe procesy inżynieryjne cyklu życia oprogramowania.

8. Co to jest model cyklu życia oprogramowania? Podaj definicje podstawowych pojęć związanych z pojęciem „modelu”.

9. Jakie znasz typy modeli? Jakie są ich zalety, wady, zakres zastosowania?

10.Co możesz powiedzieć o cechach modelu cyklu życia wodospadu?

11. Jaka jest różnica pomiędzy uogólnionym modelem kaskadowym a podstawowym?

12.Co możesz powiedzieć o cechach modelu spiralnego cyklu życia?

13.Wymień elementy technologii RAD. Do tworzenia jakiego rodzaju oprogramowania można wykorzystać technologię RAD?

14.Opisać główne fazy cyklu życia technologii RAD.

15.Wymień podstawowe zasady technologii RAD.

BIBLIOGRAFIA

1. Aptekar M.D., Ramazanov S.K., Freger G.E. Historia działalności inżynieryjnej. – Kijów, 2003. – 204 s. : chory.

2. Archibald R. Modele cyklu życia projektów high-tech. http://www.pmprofy.ru/content/rus/107/1073-article.html

3. Brooks F. Mityczny człowiek-miesiąc, czyli jak powstają systemy oprogramowania. – Petersburgu. : Symbol-plus, 1999. – 321 s. : chory.

4. Butch G. Projektowanie obiektowe z przykładami zastosowań. – M.: Concord, 1992. – 586 s. : chory.

5. Butch G. Analiza obiektowa i projektowanie obiektowe w C++. – M.: Binom, – 2001. – 558 s. : chory.

6. Technologie Vendrov A. M. CASE. Nowoczesne metody i narzędzia do projektowania systemów informatycznych. – M.: Finanse i Statystyka, – 1999 r. – 256 s. : chory.

7. Wirth N. Algorytmy + struktury danych = programy: Tłum. z angielskiego – M.: Mir, 1985. – 406 s.: il.

8. Dahl O., Dijkstra E., Hoor K. Programowanie strukturalne: Tłum. z angielskiego – M.: Mir, 1975. – 247 s. : chory.

9. Dzierżyński F.Ya., Kalinichenko I.M. Dyscyplina programistyczna: koncepcja i doświadczenie we wdrażaniu narzędzi metodologicznych inżynierii oprogramowania. – M.: Centralny Instytut Informatyki i Badań Techniczno-Ekonomicznych w Naukach i Technikach Jądrowych, 1988. – 245 s. : chory.

10. Zhogolev E. A. Technologie programistyczne. – M.: Świat naukowy, 2004. – 216 s. : chory.

11. Ustawa Federacji Rosyjskiej nr 149-FZ z dnia 29 lipca 2006 r. „O informacji technologia informacyjna i ochrona informacji”//Rossijskaja Gazeta, nr 165 z 27 lipca 2006 r.

12. Ivanova G. S. Technologia programowania: Podręcznik dla uniwersytetów. – wyd. 2, stereotyp. – M.: Wydawnictwo MSTU im. N.E. Bauman, 2003. – 320 s.: il.

13. Kalyanov G. N. PRZYKŁAD: Analiza systemów strukturalnych (automatyzacja i zastosowanie). – M.: „Lori”, 1996. – 356 s. : chory.

14. M. Korablin. Programowanie obiektowe: Instruktaż. – Samara: wydawnictwo SSAU, 1994. – 94 s.

15. Samouczek Leonenkov A.V. UML. – St.Petersburg: VHV St.Petersburg, – 2001. – 304 s. : chory.

16. Lipaev V.V. Jakość oprogramowania. – M.: Finanse i statystyka, 1983. – 263 s. : chory.

17. Lipaev V.V. Debugowanie złożonych programów: metody, narzędzia, technologia. -M. : Energoatomizdat, 1993. – 384 s. : chory.

18. Lipaev V.V., Filippov E.N. Mobilność programów i danych w środowisku otwartym systemy informacyjne. – M.: Książka naukowa, 1997. – 297 s. : chory.

20. Ozhegov S.I. Słownik języka rosyjskiego. – M.: Pokój i edukacja, 2006. – 1328 s.

21. Technologia projektowania kompleksów programów zautomatyzowanych systemów sterowania / V. V. Lipaev, L. A. Serebrovsky, P. G. Gaganov i inni; wyd. Yu. V. Afanasyeva, V. V. Lipaeva. – M.: Radio i Łączność, 1983. – 256 s. : chory.

22. Hyvenen E., Seppanen J. Świat LISP-a: Tłum. z fińskiego W 2 tomach T.1: Wprowadzenie do języka Lisp i programowanie funkcjonalne.– M.: Mir, 1990. – 447 s. : chory.

23. Hyvenen E., Seppanen J. Świat LISP-a: Tłum. z fińskiego W 2 tomach T.2: Metody i systemy programowania – M.: Mir, 1990. – 319 s. : chory.

24. Boehm B. „Spiralny model rozwoju i ulepszania oprogramowania”, IEEE Computer, tom. 21, Nie. 5, s. 61–72, 1988.

25. Courtois P. Czerwiec 1985. Dł Czas i Przestrzenna dekompozycja złożonych struktur. Komunikaty ACM tom 28(6), s. 596.

26. Kryteria oceny oprogramowania. ISO TC97/SC7 #383.

27. Dijktra E. 1979. Programowanie traktowane jako działalność człowieka. Klasyka inżynierii oprogramowania. Nowy Jork, Nowy Jork: Yourdon Press.

28. http://www.pmi.ru/glossary/.

29. http://www.staratel.com/iso/InfTech/DesignPO/ISO12207/ISO12207-99/ISO12207.htm.

30. Korporacja Microsoft. Zasady projektowania i tworzenia oprogramowania. Kurs treningowy MCSD: Tłum. z angielskiego – M.: Dom Wydawniczo-Handlowy „Wydanie Rosyjskie”, 2000. –608 s. : chory.

31. Parnas D., Clements P., Weiss D. 1983. Zwiększanie możliwości ponownego wykorzystania poprzez ukrywanie informacji. Materiały z warsztatów na temat ponownego użycia w programowaniu. Stratford, Connecticut: Programowanie ITT. s. 241.

32. Rechtin E. Październik 1992. Sztuka architektury systemów. IEEE Spectrum, tom 29(10), s.66.

33. Royce W.W. Zarządzanie rozwojem dużych systemów oprogramowania. http://facweb.cti.depaul.edu/jhuang/is553/Royce.pdf.

34. Shaw M. Październik 1984. Techniki abstrakcji we współczesnych językach programowania. Oprogramowanie IEEE, tom 1 (4).

35. Simon H. 1982. Nauki o sztuczności. Cambridge, MA: MIT Press. – s.218.

36. Sommerville I. Inżynieria oprogramowania. – Addison-Wesley Publishing Company, 1992. s. 87.

37. Tesler L. sierpień 1981. Środowisko Smalltalk. Bajt tom 6(8), s.142.

38. Yonezawa A., Tokoro M. 1987. Programowanie współbieżne zorientowane obiektowo. Cambridge, MA: MIT Press.

lista terminów

Pod koniec 2002 roku moskiewskie wydawnictwo „Lori” opublikowało książkę „Rapid Software Development” Alistaira Cockburna. Rosyjski tytuł książki jest nieco zaskakujący, gdyż w oryginale nazywa się ona „Agile Software Development”, a w bardziej poprawnym tłumaczeniu brzmiałaby jak „Agile Software Development”. Nie będziemy jednak mieć pretensji do tłumacza, gdyż takich książek nie wydano jeszcze w języku rosyjskim.

Branża tworzenia oprogramowania jest dość młoda i aktywnie się rozwija. Podstawowe zasady tworzenia programów wciąż się kształtują, stale pojawiają się nowe metodyki, praktyki, języki programowania, nowe technologie i narzędzia. Wszystko zmienia się bardzo dynamicznie, więc stworzenie jednej poprawnej metodyki tworzenia oprogramowania jest prawie niemożliwe. Jednak wciąż trwają próby wynalezienia „srebrnego środka”, który mógłby rozwiązać wszystkie problemy programistów. Być może wynika to z obecności podobnych procesów w innych obszarach.

Weźmy na przykład budowę budynku. W dzisiejszych czasach budowa domu to zupełnie proste zadanie. Każdy wie, jakie działania należy podjąć, aby otrzymać wymarzony dom. Proces jest przewidywalny. Role są jasno określone. Technologie są dobrze znane. Tworzenie oprogramowania stwarza zupełnie wyjątkowe problemy: użytkownicy często po prostu nie mogą powiedzieć, czego naprawdę potrzebują, dopóki nie wypróbują produktu w działaniu; wymagania ciągle się zmieniają, więc tworzenie solidnego planu dla całego projektu nie ma sensu; nie ma wystarczającej liczby wykwalifikowanego personelu; Stosowane technologie są często prymitywne, a narzędzia niedoskonałe. W takich warunkach tradycyjne podejście do zarządzania projektami bardzo często zawodzi.

Od czasu do czasu pojawiali się ludzie, którzy zaczęli rozumieć problemy tworzenia oprogramowania, ale prawdziwy przełom nastąpił teraz, po pojawieniu się programowania ekstremalnego (eXtreme Programming, www.extremeprogramming.com) i utworzeniu sojuszu zwinnego rozwoju oprogramowania (Agile Alliance, www.agilealliance.org). Metodologie zwinne przełamują stereotypy i całkowicie zmieniają proces tworzenia oprogramowania. Zmieniają same zasady organizacji procesu.

Czym elastyczne metodyki różnią się od tradycyjnych? Istnieje kilka głównych różnic:

• Częste dostawy działającego oprogramowania (w odstępach od dwóch tygodni do dwóch miesięcy).
• Możliwość dostosowania do zmian wymagań, co jest szczególnie trudne w przypadku tradycyjnych metod rozwoju.
• Ścisła interakcja z przedstawicielami klientów przez cały cykl rozwoju.
• Zrozumienie wagi dobrej komunikacji w zespole, podczas gdy tradycyjne metodyki rzadko przywiązują do komunikacji poważne znaczenie.
• Zrozumienie i wykorzystanie indywidualnych cech członków zespołu, podczas gdy tradycyjne metodyki w ogóle nie uwzględniają jednostek.
• Stale poprawiaj wydajność zespołu w oparciu o regularne oceny.
• Przywiązanie do prostoty, które rzadko można znaleźć w tradycyjnych metodologiach.

Wiele zwinnych metodologii pozwala wykorzystać mocne strony indywidualnego zespołu programistów, ponieważ można je dostosować do zespołu. Tradycyjne metodologie zmuszają zespół do dostosowania się do siebie.

Alistair Coburn jest świetnym programistą i świetnym pisarzem. Wie, jak jasno i konsekwentnie wyrażać swoje myśli i zniewalać ludzi. O czym zatem jest książka? Opowiada o tym, jak wyjątkowa jest każda osoba i jak wykorzystać indywidualność, aby przynieść korzyści projektowi. Tworzenie oprogramowania to gra oparta na współpracy, oparta na inwencji i komunikacji. Ta komunikacja w zespole jest niezwykle ważna i często decyduje o sukcesie lub porażce projektu.

Jakie są różne metodologie, jak wpływają na proces tworzenia oprogramowania i dlaczego w ogóle są potrzebne? Książka zawiera niezwykle ciekawe zastosowania: programowanie jako budowanie teorii, zastosowanie gier językowych Wittgensteina do tworzenia oprogramowania, zastosowanie metod Musashiego (samuraja żyjącego w XVII w., który napisał książkę „Księga pięciu kręgów”). do rozwoju oprogramowania.

Ponadto książka zawiera wiele przykładów i dialogów z życia wziętych, które pomagają lepiej zrozumieć istotę problemów związanych z tworzeniem oprogramowania. Istnieje wiele opinii na temat zagrożeń i korzyści stosowania metodologii. Książka „Szybkie Tworzenie Oprogramowania” pomoże Ci znaleźć odpowiedzi na wiele pytań.

To, co naprawdę urzeka, to niezwykła roztropność autora. Nigdy nie twierdzi, że jego opinia jest jedyną słuszną, zawsze argumentuje swój punkt widzenia i robi to przekonująco. Jeśli wcześniej nie interesowałeś się szczególnie metodologiami wytwarzania oprogramowania, to po przeczytaniu książki na pewno się tym zainteresujesz. Jeśli byłeś tym aktywnie zainteresowany, ale tak naprawdę go nie zastosowałeś, zaczniesz go używać.

Dla kierowników projektów (Project Manager) i liderów zespołów (Team Leader) książka z kategorii obowiązkowej. Twoja skuteczność jako lidera znacznie wzrośnie.

Jeśli mówimy o jakości publikacji, to tłumaczenie jest całkiem dobre, za wyjątkiem terminu agile. Jedynym minusem książki jest kiepski druk, co nie jest rzadkością w literaturze komputerowej. Co zaskakujące, cena książki o takiej jakości również nie jest mała.

Książkę Alistaira Coburna „Rapid Software Development” można kupić w sklepie internetowym www.rodina.by (www.rodina.by/book/info/go/6047.html).

Michaił DUBAKOW