LabVIEW - Modele Rozwoju

Transkrypt

1 Kurantowicz Agnieszka Jedut Barbara LabVIEW - Modele Rozwoju Projekt ten dostarcza przykładów niektórych powszechnych pułapek rozwoju i opisuje grupę modeli związanych z technologią cyklu życia oprogramowania. LabVIEW czyni łatwiejszym dopasowywanie składników związanych z dostępem do danych., testowaniem i kontrolą systemu. Ze względu na to, że programowanie w LabVIEW jest tak łatwe możesz zostać zachęcony do niezwłocznego zaangażowania swoich sił w tworzenie relatywnie małych projektów. Dla zwykłych aplikacji takich jak szybkie testy, monitorowanie aplikacji to podejście mogłoby być odpowiednie. Jednakże dla większych rozwojowych projektów dobrej jakości projektowanie staje się konieczne. Powszechne pułapki rozwoju Jeśli miałeś dotychczas rozwiniętą dużą aplikację to prawdopodobnie słyszałeś kilka następujących stwierdzeń.większość tych rozwiązań miało dobre intencje i wyglądało na dość rozsądne Jakkolwiek rozwiązania te są często nierealistyczne i mogą prowadzić do opóźnień, problemów jakościowych i niskich niewłaściwych postaw wśród członków zespołu, Naprawdę tego nie przemyślałem ale przypuszczam, że projekt o który prosisz może być ukończony w... Off-the-cuff szacunki są rzadko poprawne ponieważ zazwyczaj są oparte na niepełnym zrozumieniu problemu. Kiedy tworzysz dla kogoś jeszcze, każdy z was może mieć różne pomysły odnośnie wymagań.

2 Aby szacować odpowiednio obaj musicie dokładnie rozumieć wymagania i przejść przynajmniej przygotowawczy kurs programowania na wysokim poziomie aby zrozumieć specyfikę komponentów które będziecie wykorzystywać. Myślę, że rozumiem problem, który konsument chce rozwiązać dlatego jestem gotowy zająć się nim Dwa problemy cechują to stwierdzenie. Po pierwsze brak pomiędzy celami i wynikami projektu zawartych w wykazie opóźnień. Twój pomysł na to czego potrzebuje konsument mógłby być oparty na nieodpowiedniej komunikacji. Rozwijanie wymagań dokumentu oraz tworzenie prototypu systemu, obie kwestie opisane w Cykl Życia Modeli w dalszej części rozdziału mogą być użyte narzędzia do uściślenia celów. Drugi problem związany z tym stwierdzeniem wiąże zajęcie się rozwiązaniem problemu może oznaczać napisanie kodu bez uszczegółowionego projektu. Podobnie jak budowniczy nie buduje domu bez projektu budowlanego. Programiści nie powinni rozpoczynać budowania aplikacji bez uszczegółowionego projektu. Aby uzyskać więcej informacji o rozwojowych modelach należy odnieść się do następnego podrozdziału-. MODEL KODOWANIA I USTALANIA My nie mamy czasu pisać uszczegółowionych planów. Gonią nas terminy więc musimy rozpocząć tworzenie programu już w tej chwili Ta sytuacja jest podobna do poprzedniego przykładu i cechuje ją ten sam powszechny błąd, że nie warto się o tym rozwodzić. Programiści często pomijają tak ważne planowanie ponieważ wydaje się im, że nie jest to tak produktywne jak tworzenie kodu. Rezultatem jest to, że tworzysz bez sensownego pomysłu jak one wszystkie współgrają ze sobą i będziesz musiał ponownie pracować nad tą częścią kiedy znajdziesz błędy. Zabranie czasu na przygotowanie planu pozwoli uniknąć ponownej, kosztownej pracy w trakcie tworzenia programu.

3 Jeśli dostałbym wszystkie cechy do przyszłego miesiąca, powinienem rozwiązać wszystkie problemy zanim program zostanie udostępniony. Udostępnić wysokiej jakości produkty na czas, uzyskując standardy jakości podczas tworzenia produktu. Nie buduj nowych cech na niestabilnym fundamencie polegając na tym, że skorygujesz błędy później. To zaostrza problemy i zwiększa koszty. Chociaż mógłbyś ukończyć wszystkie cechy na czas, jednakże czas niezbędny do usunięcia problemów w istniejącym i nowym kodzie może przesunąć w czasie udostępnienie produktu. Utworzenie priorytetów cech i wprowadzenie najważniejszych jako pierwszych. Pierwsze najważniejsze cechy są przetestowane, później można wybrać i pracować nad pozostałymi cechami bądź odłożyć ich udostępnianie na przyszłość. Odnosząc się do rozdziału 2 WŁĄCZENIE JAKOŚCI W PROCES ROZWOJU aby uzyskać więcej informacji o technikach produkcji wysokiej jakości oprogramowania. Jesteśmy spóźnieni w realizacji naszego projektu. Ściągnijmy więcej programistów. W wielu przypadkach, w rzeczywistości zrobienie tego może opóźnić projekt jeszcze bardziej. Dołączenie nowych programistów do projektu wymaga czasu na ich przeszkolenie co może znacznie ograniczyć pierwotnie zaplanowany czas na przygotowanie projektu. Lepiej jest zwiększyć zasoby kadrowe wcześniej niż zrobić to w ostatniej chwili. Należy pamiętać, że zawsze jest limit liczby członków zespołu, którzy mogą efektywnie pracować nad projektem. Gdy jest kilku ludzi nie ma wówczas zbędnego tłoku. Możesz rozdzielić zadania związane z projektem pomiędzy każdą osobą tak, że otrzymuje odrębną część. Im więcej ludzi zaangażujesz tym trudniej będzie uniknąć tłoku. Jesteśmy spóźnieni w realizacji naszego projektu, ale wciąż myślimy, że możemy wprowadzić wszystkie cechy przed wyznaczonym terminem.

4 Kiedy jesteście spóźnieni z projektem jest ważne aby uświadomić sobie ten fakt i dalej działać. Na przykład jeśli zdaliśmy sobie sprawę w pierwszy miesiącu sześciomiesięcznego projektu, że jesteśmy spóźnieni możecie zrezygnować z niektórych planowanych wymogów albo zwiększyć czas całkowitego harmonogramu. Kiedy zdacie sobie sprawę, ze jesteście spóźnieni, dopasujcie harmonogram albo rozważcie, które wymogi można pominąć albo odłożyć je do późniejszego udostępnienia. Liczba innych problemów może wzrosnąć w trakcie programowania. Następująca lista zawiera niektóre z fundamentalnych elementów tworzenia jakościowych programów na czas: - poświęć wystarczająco czasu na planowanie, - upewnij się, że cały zespół dokładnie rozumie problemy, które muszą być rozwiązane, - utwórz elastyczną strategię rozwoju aby zminimalizować ryzyko i przystosować się do zmian. Tworzenie projektów oprogramowań jest złożone. Aby zrozumieć te złożoności programiści utworzyli zasadniczy zestaw reguł rozwojowych. Reguły te definiują zakres budowy oprogramowań. Główny składnik tego zakresu to cykl życia modelu. Cykl życia modelu opisuje etapy jakimi należy podążać aby wytworzyć oprogramowanie od początku koncepcji aż do udostępnienia, utrzymania i późniejszego podnoszenia standardu oprogramowania. Obecnie mamy do czynienia z wieloma różnymi cyklami życia modeli. Każdy ma zalety i wady w kategoriach czasu udostępnienia, jakości i ryzyka zarządzania. Ta część tekstu opisuje niektóre z najbardziej powszechnych modeli używanych przy tworzeniu programów. Wiele krzyżówek tych modeli istnieje, a więc używaj tych części, które uważasz, że się sprawdzą w twoim projekcie. Chociaż ta część rozdziału jest teoretyczną w swej dyskusji, w praktyce rozważa wszystkie kroki obejmujące te modele.

5 MODEL KODOWANIA I USTALANIA Model kodowania i ustalania jest najczęściej używaną metodologią w tworzeniu programu. Rozpoczyna się od niewielkiego bądź przesuniętego na później planowania. Natychmiastowo zaczyna się tworzenie, ustalanie problemów, które będą pojawiać się aż do momentu ukończenia projektu. Ten typ modelu jest kuszący kiedy masz do czynienia z następnym harmonogramem ponieważ rozpoczynasz tworzenie kody od razu i widzisz natychmiastowe wyniki. Model ten jest odpowiedni tylko dla małych projektów, których nie ma się zamiaru udostępnić jako podstawy do dalszego ich rozwoju. MODEL WODOSPADU Model wodospadu jest klasycznym modelem budowania oprogramowania. Ma on braki ale stanowi bazę dla wielu innych modeli. Czysty cykl życia modelu wodospadu zawiera kilka faz, których nie można pominąć jak pokazano na rysunku. Rozpoczyna się od koncepcji programu poprzez analizę wymagań, architektoniczny projekt, uszczegółowiony projekt, kodowanie, testowanie i utrzymanie.

6 Wymagania systemu Wymagania oprogramowania Projekt architektury Projekt uszczegółowiony kodowanie testowanie utrzymanie - wymagania systemu ustalenie składników do budowy systemu. Zawiera to wymagania sprzętowe, narzędzia programowe i inne niezbędne komponenty, - wymagania programowe koncentrują się na oczekiwaniach związanych z funkcjonalnością oprogramowania. Identyfikujesz, na które wymagania systemu oprogramowanie ma wpływ. Analiza wymagań mogłaby zawierać określenie współdziałania z innymi aplikacjami i bazami danych, przedstawienie wymagań itd. - Projekt architektoniczny określa normy oprogramowania systemu, które mają sprostać specyficznym wymaganiom. Projekt definiuje główne składniki i współdziałanie tych składników ale nie definiuje on struktury każdego z nich. Określasz również zewnętrzny obszar używanego oddziaływania i narzędzia użyte w projekcie. Przykłady zawierają decyzje dotyczące sprzętu, zewnętrznych części oprogramowania takich jak bazy danych albo inne biblioteki. uszczegółowiony projekt sprawdza składniki oprogramowania zdefiniowane w architektonicznym projekcie i specyfikuje wprowadzenie każdego składnika

7 kodowanie- wprowadza uszczegółowiony specyfikację projektu testowanie określa czy oprogramowanie spełnia określone wymogi i odnajduje błędy w kodzie utrzymanie-pokazuje jak należy rozwiązać problemy i uwydatnia wymagania po udostępnieniu programu. W każdym stadium tworzenia dokumentu wyjaśniasz swoje cele i opisujesz wymagania dla tej fazy. Na koniec każdego etapu stwierdzasz czy projekt może przejść do następnego stadium. Również możesz współdziałać w tworzeniu prototypów w różnych etapach od architektonicznego projektu po kolejne stadia. Cykl życia Modelu Wodospadu jest jednym z najstarszych i często używany w projektach rządowych i wielu głównych przedsiębiorstwach. Wynika to z tego, że kładzie nacisk na planowanie we wczesnych stadiach, pomaga wyłapać usterki zanim zostaną umieszczone w oprogramowaniu. Metoda Wodospadu nie zabrania powracania do wcześniejszych faz na przykład, z fazy projektowania do fazy wymagań. Jakkolwiek jest to kosztowny powrót. Każda ukończona faza wymaga formalnego przeglądu i obszernej dokumentacji. Przeoczenia dokonane w fazie wymagań są kosztowne gdy się je koryguje w terminie późniejszym. Chociaż Model Wodospadu ma swoje słabe strony, to jest jednak pouczający ponieważ na ważne stadia rozwoju projektu. Nawet jeśli nie będziesz stosował tego modelu, rozważ każdy z jego etapów i związek z twoim własnym projektem. Zmodyfikowany Model Wodospadu Wielu inżynierów poleca zmodyfikowane wersje modelu wodospadu. Te modyfikacje zamierzają się skupić na pominięciu niektórych faz w celu redukcji wymogów dokumentacji i redukcji kosztów związanych z powrotem do wcześniejszych

8 etapów. Inną powszechną modyfikacją jest współudział tworzenia prototypów i faz wymagań co jest opisane w następnej części rozdziału. Tworzenie Prototypów Jednym z głównych problemów związanych z modelem wodospadu jest to, że wymagania często nie są całkowicie zrozumiane we wczesnych stadiach rozwoju projektu. Kiedy dochodzisz do etapu projektowania albo kodowania widzisz jak wszystko współgra i wówczas możesz odkryć, że musisz lepiej dopasować wymagania. Tworzenie prototypów może być efektywnym narzędziem aby zademonstrować jak projekt może poradzić sobie z zestawem różnych wymagań. Możesz tworzyć prototyp, dopasowując wymagania i rewidować go kilka razy aż uzyskasz pełny obraz wszystkich celów. Należy wspomnieć wyjaśniając kwestię wymagań, że prototyp również definiuje wiele obszarów symulujących projekt. Podsumowanie Modele i cykle życia są opisywane jako różne wybory, których musisz dokonać. W praktyce, jakkolwiek, możesz zastosować więcej niż jeden model do pojedynczego projektu. Możesz rozpocząć projekt od spiralnego modelu, który pomoże ci sprecyzować wymagania i specyfikacje stosując prototypy. Redukując ryzyko niezbyt dokładnie ustalonych wymagań możesz zastosować model wodospadu do projektowania, kodowania, testowania i utrzymania. Opracowano na podstawie Development Guidelines