Obecnie w inżynierii oprogramowania istnieją dwa główne podejścia do opracowywania oprogramowania EIS, przy czym podstawowa różnica między nimi wynika z różnych sposobów rozkładania systemów. Pierwsze podejście nazywa się funkcjonalno-modułowym lub strukturalnym. Opiera się na zasadzie rozkładu funkcjonalnego, w którym struktura systemu jest opisywana w kategoriach hierarchii jego funkcji i przekazywania informacji między poszczególnymi elementami funkcjonalnymi. Drugie podejście obiektowe wykorzystuje rozkład obiektów. Strukturę systemu opisano w kategoriach obiektów i relacji między nimi, a zachowanie systemu opisano w kategoriach wymiany komunikatów między obiektami.
Zatem istotą strukturalnego podejścia do rozwoju oprogramowania EIS jest jego rozkład (podział) na funkcje automatyczne: system jest podzielony na podsystemy funkcjonalne, które z kolei są podzielone na podfunkcje, te na zadania i tak dalej na określone procedury. Jednocześnie zautomatyzowany system utrzymuje całościowy widok, w którym wszystkie elementy są ze sobą połączone. Podczas opracowywania systemu od podstaw, od pojedynczych zadań do całego systemu, integralność jest tracona, pojawiają się problemy przy opisywaniu interakcji informacyjnej poszczególnych komponentów.
Wszystkie najpopularniejsze metody podejścia strukturalnego opierają się na szeregu ogólnych zasad. Podstawowe zasady to:
zasada „dziel i rządź” (patrz podrozdział 2.1.1);
zasada hierarchicznego porządkowania - zasada organizowania komponentów systemu w hierarchiczne struktury drzewiaste z dodawaniem nowych szczegółów na każdym poziomie.
Podkreślenie dwóch podstawowych zasad nie oznacza, że \u200b\u200bpozostałe zasady są drugorzędne, ponieważ zignorowanie którejkolwiek z nich może prowadzić do nieprzewidzianych konsekwencji (w tym niepowodzenia całego projektu). Główne z tych zasad to:
zasada abstrakcji - przydział zasadniczych aspektów systemu i odwrócenie uwagi od nieistotnych;
zasada spójności - ważność i spójność elementów systemu;
zasada struktury danych - dane muszą być uporządkowane i hierarchicznie zorganizowane.
Podejście strukturalne wykorzystuje głównie dwie grupy narzędzi, które opisują funkcjonalną strukturę systemu i związek między danymi. Każda grupa narzędzi odpowiada niektórym typom modeli (diagramom), z których najczęstsze to:
DFD (Data Flow Diagrams) - diagramy przepływu danych;
SADT (Structured Analysis and Design Technique - metoda analizy i projektowania strukturalnego) - modele i odpowiednie schematy funkcjonalne;
ERD (diagramy relacji encja) - diagramy relacji encja.
Diagramy przepływu danych i diagramy relacji między jednostkami są najczęściej używanymi typami modeli w narzędziach CASE.
Konkretna forma tych diagramów i interpretacja ich projektów zależą od etapu oprogramowania LC.
Na etapie formułowania wymagań dotyczących oprogramowania modele SADT i DFD są wykorzystywane do budowy modelu AS-IS i modelu TO-BE, odzwierciedlając tym samym istniejącą i proponowaną strukturę procesów biznesowych organizacji oraz interakcję między nimi (przy użyciu modeli SADT z reguły ogranicza się tylko do tego etapu, ponieważ pierwotnie nie były przeznaczone do projektowania oprogramowania). Za pomocą ERD opis danych wykorzystywanych w organizacji jest przeprowadzany na poziomie koncepcyjnym, niezależnie od narzędzi wdrażania baz danych (DBMS).
Na etapie projektowania DFD są używane do opisania struktury projektowanego systemu oprogramowania, podczas gdy można je udoskonalić, rozszerzyć i uzupełnić o nowe projekty. Podobnie, ERD są udoskonalane i uzupełniane o nowe konstrukcje, które opisują prezentację danych na poziomie logicznym odpowiednim do późniejszej generacji schematu bazy danych. Modele te można uzupełnić o schematy odzwierciedlające architekturę systemu oprogramowania, schematy strukturalne programów, hierarchię form i menu ekranów itp.
Powyższe modele razem dają pełny opis oprogramowania EIS, niezależnie od tego, czy system istnieje, czy jest nowo opracowany. Skład diagramów w każdym przypadku zależy od złożoności systemu i niezbędnej kompletności jego opisu.
Tematem większości przykładów diagramów podanych w tym rozdziale jest system podatkowy Federacji Rosyjskiej, którego najbardziej kompletny opis znajduje się w Kodeksie podatkowym Federacji Rosyjskiej. Technologie informacyjne stosowane w systemie podatkowym Federacji Rosyjskiej mają pewne cechy.
Tak więc istotą strukturalnego podejścia do rozwoju oprogramowania EIS jest jego rozkład (dekompozycja) na funkcje automatyczne: system jest podzielony na podsystemy funkcjonalne, które z kolei są podzielone na podfunkcje, te na zadania i tak dalej, aż do określonych procedur. Jednocześnie system zachowuje holistyczny obraz, w którym wszystkie elementy składowe są ze sobą połączone. Podczas opracowywania systemu od podstaw, od pojedynczych zadań do całego systemu, integralność jest tracona, pojawiają się problemy przy opisywaniu interakcji informacyjnej poszczególnych komponentów.
Wszystkie najczęstsze metody podejścia strukturalnego opierają się na szeregu ogólnych zasad:
1. Zasada „dziel i rządź”;
2. Zasada hierarchicznego uporządkowania jest zasadą organizowania komponentów systemu w hierarchiczne struktury drzewiaste z dodawaniem nowych szczegółów na każdym poziomie.
Przydział dwóch podstawowych zasad nie oznacza, że \u200b\u200bpozostałe zasady są wtórne, ponieważ zignorowanie któregokolwiek z nich może prowadzić do nieprzewidzianych konsekwencji (w tym niepowodzenia całego projektu ”). Główne z tych zasad to:
1. Zasada abstrakcji to alokacja istotnych aspektów systemu i odwrócenie uwagi od nieistotnych.
2. Zasada spójności, ważności i spójności elementów systemu.
3. Zasada strukturyzacji danych - dane powinny być uporządkowane i hierarchicznie zorganizowane.
Podejście strukturalne to głównie dwie grupy narzędzi, które opisują strukturę funkcjonalną systemu i związek między danymi. Każda grupa narzędzi odpowiada niektórym typom modeli (diagramom), najczęściej wśród nich są:
DFD (Data Flow Diagrams) - diagramy przepływu danych;
· SADT (Structured Analysis and Design Technique - metodologia analizy strukturalnej i projektowania) - modele i odpowiadające im diagramy funkcjonalne: notacje IDEF0 (modelowanie funkcjonalne systemów), IDEF1x (modelowanie koncepcyjne baz danych), IDEF3x (konstrukcja systemów do oceny jakości obiektu; graficzny opis przepływu procesy, interakcje procesów i obiektów zmienianych przez te procesy);
· ERD (Entity - Diagrams Relation) - diagramy „związek encja”.
W prawie wszystkich metodach podejścia strukturalnego (analiza strukturalna) na etapie formułowania wymagań oprogramowania stosuje się dwie grupy narzędzi do modelowania:
1. Diagramy ilustrujące funkcje, które musi wykonywać system, oraz relacje między tymi funkcjami to DFD lub SADT (IDEF0).
2. Dane modelujące wykresy i ich relacje (ERD).
Konkretna forma tych diagramów i interpretacja ich projektów zależą od etapu oprogramowania LC.
Na etapie formułowania wymagań dotyczących oprogramowania modele SADT i DFD są wykorzystywane do budowy modelu „AS-IS” i modelu „TO-BE”, odzwierciedlając w ten sposób istniejącą i proponowaną strukturę procesów biznesowych organizacji oraz interakcję między nimi (przy użyciu modeli SADT jako z reguły ogranicza się tylko do tego etapu, ponieważ pierwotnie nie były przeznaczone do projektowania oprogramowania). Za pomocą ERD dokonuje się opisu danych wykorzystywanych w organizacji na poziomie koncepcyjnym, niezależnie od sposobu wdrożenia bazy danych (DBMS).
1. kodowanie
Na etapie opracowywania oprogramowania wykonywane są następujące podstawowe działania: kodowanie; testowanie; opracowywanie oprogramowania systemu pomocy; tworzenie dokumentacji użytkownika; tworzenie wersji i instalacja oprogramowania,
Kodowanie to proces przekształcania wyników projektowania wysokiego i niskiego poziomu w gotowy produkt. Innymi słowy, podczas kodowania skompilowany model PP jest opisywany przy użyciu wybranego języka programowania, którym może być dowolny z istniejących języków. Wybór języka odbywa się na życzenie klienta lub z uwzględnieniem rozwiązanego problemu i osobistych doświadczeń programistów.
Podczas kodowania należy przestrzegać standardu dla wybranego języka, na przykład dla języka C jest to ANSI C, a dla C ++ jest to ISO / IEC 14882 „Standartforthe C ++ Programming Language”.
Oprócz ogólnie przyjętego standardu dla języka programowania firma może również stosować własne dodatkowe wymagania dotyczące zasad pisania programów. Zasadniczo dotyczą one zasad formatowania tekstu programu.
Przestrzeganie standardów i zasad firmy pozwala stworzyć poprawnie działający, łatwy do odczytania, zrozumiały program dla innych programistów, zawierający informacje o deweloperze, datę utworzenia, nazwę i przeznaczenie, a także dane niezbędne do zarządzania konfiguracją.
Na etapie kodowania programista pisze programy i sam je testuje. Takie testowanie nazywa się testowaniem jednostkowym. Wszystkie kwestie związane z testowaniem oprogramowania omówiono w rozdz. 10, tutaj opisano również technologię testowania stosowaną na etapie opracowywania oprogramowania. Ta technologia nazywa się testowaniem. „Szklany pojemnik” (szklany pojemnik);czasami nazywany testowaniem „Białe pudełko” (whitebox)w przeciwieństwie do klasycznej koncepcji czarnej skrzynki.
Podczas testowania „czarnej skrzynki” program jest uważany za obiekt, którego struktura wewnętrzna jest nieznana. Tester wprowadza dane i analizuje wynik, ale nie wie, jak działa program. Wybierając testy, specjalista szuka danych wejściowych i warunków, które są interesujące z jego punktu widzenia, co może prowadzić do niestandardowych wyników. Przede wszystkim interesują go przedstawiciele każdej klasy danych wejściowych, w których najbardziej prawdopodobne są błędy testowanego programu.
Podczas testowania „szklanego pudełka” sytuacja jest zupełnie inna. Tester (w tym przypadku sam programista) opracowuje testy na podstawie wiedzy o kodzie źródłowym, do którego ma pełny dostęp. W rezultacie otrzymuje następujące korzyści.
1. Przedmiot badań. Programista może przetestować program w częściach, opracować specjalne procedury testowe, które wywołują testowany moduł i przekazują interesujące go dane. Pojedynczy moduł jest znacznie łatwiej dokładnie przetestować jako „szklana skrzynia”.
2. Pełny zakres kodu. Programista zawsze może określić, które fragmenty kodu działają w każdym teście. Widzi, jakie inne gałęzie kodu pozostają nieprzetestowane, i może wybrać warunki, w których będą testowane. Poniżej opisano, jak śledzić zakres pokrycia kodu testami.
3. Zdolność kontrolowania przepływu poleceń. Programista zawsze wie, jaką funkcję należy wykonać w programie i jaki powinien być jej obecny stan. Aby dowiedzieć się, czy program działa tak, jak myśli, programista może dołączyć do niego polecenia debugowania, które wyświetlają informacje o postępie jego wykonania, lub użyć specjalnego narzędzia programowego o nazwie debugger. Debuger może wykonywać wiele przydatnych rzeczy: śledzić i zmieniać sekwencję wykonywania poleceń programu, wyświetlać zawartość swoich zmiennych i ich adresy w pamięci itp.
4. Możliwość śledzenia integralności danych. Programista wie, która część programu powinna modyfikować każdy element danych. Monitorując stan danych (używając tego samego debuggera), może wykryć błędy, takie jak zmiany danych przez niewłaściwe moduły, ich niepoprawna interpretacja lub nieudana organizacja. Programista może sam zautomatyzować testowanie.
5.Wizja wewnętrznych punktów granicznych. W kodzie źródłowym widoczne są te punkty graniczne programu, które są ukryte przed widokiem z zewnątrz. Na przykład do wykonania określonej akcji można zastosować kilka zupełnie różnych algorytmów i bez zaglądania do kodu nie można ustalić, który programista wybrał. Innym typowym przykładem byłby problem przepełnienia bufora używanego do tymczasowego przechowywania danych wejściowych. Programista może od razu powiedzieć, ile danych jest zapełniony bufor, i nie musi przeprowadzać tysięcy testów.
6. Zdolność do testowania, określona przez wybrany algorytm. Do testowania przetwarzania danych przy użyciu bardzo złożonych algorytmów obliczeniowych mogą być potrzebne specjalne technologie. Klasyczne przykłady obejmują transformację macierzy i sortowanie danych. Tester, w przeciwieństwie do programisty, musi dokładnie wiedzieć, jakie algorytmy są używane, dlatego musisz sięgnąć do specjalnej literatury.
Testowanie szklanych skrzynek jest częścią procesu programowania. Programiści wykonują tę pracę przez cały czas, testują każdy moduł po napisaniu go, a następnie ponownie po zintegrowaniu z systemem.
Podczas przeprowadzania testów jednostkowych możesz użyć technologii testów strukturalnych lub funkcjonalnych albo obu.
Strukturalnetestowanie jest rodzajem testu szklanej skrzynki. Jego główną ideą jest właściwy wybór testowanej ścieżki oprogramowania. W przeciwieństwie do niego funkcjonalnytestowanie należy do kategorii testów czarnej skrzynki. Każdą funkcję programu testuje się, wprowadzając dane wejściowe i analizując dane wyjściowe. Ponadto bardzo rzadko brana jest pod uwagę wewnętrzna struktura programu.
Chociaż testy strukturalne mają znacznie silniejsze podstawy teoretyczne, większość testerów woli testy funkcjonalne. Testy strukturalne lepiej nadają się do modelowania matematycznego, ale nie oznacza to wcale, że jest bardziej wydajne. Każda z technologii umożliwia identyfikację błędów, które są pomijane podczas korzystania z drugiej. Z tego punktu widzenia można je nazwać równie skutecznymi.
Obiektem testowym może być nie tylko pełna ścieżka programu (sekwencja poleceń, które wykonuje od początku do końca), ale także jego poszczególne sekcje. Testowanie wszystkich możliwych sposobów uruchomienia programu jest absolutnie nierealne. Dlatego eksperci ds. Testów wyodrębniają ze wszystkich możliwych ścieżek grupy, które należy koniecznie przetestować. Do wyboru używają specjalnych kryteriów zwanych kryteria pokrycia (kryteria pokrycia),które określają bardzo rzeczywistą (choć dość dużą) liczbę testów. Te kryteria są czasami nazywane logiczne kryteria zasięgulub kryteria kompletności.
3. Opracowanie systemu pomocy dla oprogramowania. Tworzenie dokumentacji użytkownika
Wskazane jest wyznaczenie jednego z pracowników projektu jako redaktora technicznego dokumentacji. Ten pracownik może wykonywać inną pracę, ale jego głównym zadaniem powinna być analiza dokumentacji, nawet jeśli inni pracownicy ją opracowują.
Często zdarza się, że kilka osób pracuje nad tworzeniem oprogramowania, ale żadna z nich nie ponosi pełnej odpowiedzialności za jego jakość. W rezultacie PP nie tylko nie korzysta z faktu, że więcej ludzi go rozwija, ale także traci, ponieważ podświadomie przenosi odpowiedzialność na drugiego i oczekuje, że ta lub inna część pracy zostanie wykonana przez jego kolegów. Problem ten został rozwiązany przez powołanie redaktora, który ponosi pełną odpowiedzialność za jakość i dokładność dokumentacji technicznej.
System pomocy PP jest tworzony na podstawie materiałów opracowanych dla wskazówek użytkownika. Tworzy i tworzy ją odpowiedzialną za realizację tej pracy. Może to być redaktor techniczny lub jeden z programistów wraz z edytorem technicznym.
Dobrze udokumentowany PP ma następujące zalety.
1. Łatwość użycia. Jeśli oprogramowanie jest dobrze udokumentowane, łatwiej jest je zastosować. Użytkownicy uczą się tego szybciej, popełniają mniej błędów, dzięki czemu wykonują swoją pracę szybciej i wydajniej.
2. Niższy koszt pomocy technicznej. Gdy użytkownik nie może dowiedzieć się, jak wykonać niezbędne czynności, wzywa producenta oprogramowania do działu pomocy technicznej. Treść takiej usługi jest bardzo droga. Dobry przewodnik pomaga użytkownikom samodzielnie rozwiązywać problemy i mniej kontaktować się z grupą wsparcia technicznego.
3. Wysoka niezawodność. Niezrozumiała lub niedokładna dokumentacja powoduje, że oprogramowanie jest mniej niezawodne, ponieważ użytkownicy częściej popełniają błędy, trudno jest im zrozumieć, co jest ich przyczyną i jak sobie z nimi poradzić.
Łatwość konserwacji. Ogromna ilość pieniędzy i czasu poświęcana jest na analizę problemów spowodowanych błędami użytkownika. Zmiany wprowadzone w nowych wersjach oprogramowania są często tylko zmianą interfejsu starych funkcji. Są wprowadzane, aby użytkownicy w końcu mogli dowiedzieć się, jak korzystać z oprogramowania i przestać dzwonić do pomocy technicznej. Właściwie dobre przywództwo
Rozważając technologię opracowywania oprogramowania, konieczne jest zastosowanie podejścia systematycznego, które obejmuje uwzględnienie nie niektórych konkretnych aspektów problemu tworzenia oprogramowania, ale problemu jako całości. Systematyczne podejście jest wdrażane w przestrzeni i czasie.
Podejście systemowe oparte na czasie uwzględnia sekwencję etapów tworzenia oprogramowania od momentu powstania niezaspokojonego zapotrzebowania na oprogramowanie do czasu jego rozwiązania oraz utrzymanie w działaniu otrzymanego oprogramowania.
Systematyczne podejście w „kosmosie” przewiduje uwzględnienie opracowanego oprogramowania jako części systemu.Jednocześnie, w oparciu o badanie potrzeb informacyjnych systemu, które obejmie opracowywane oprogramowanie, formułowane są cele i zestaw funkcji oprogramowania, analizowane są prototypy oprogramowania. Wymagania dotyczące oprogramowania są generowane i dokumentowane.
Współczesna technologia tworzenia oprogramowania uważa programowanie za jeden z etapów rozwoju w łańcuchu kolejnych etapów cyklu programowania. Wszystkie te etapy łączy koncepcja cyklu życia oprogramowania i powinny być wspierane przez odpowiednie oprogramowanie instrumentalne i sprzęt.
Zgodnie z międzynarodową normą ISO / IEC 12207 „Technologia informacyjna - procesy cyklu życia oprogramowania”, proces tworzenia oprogramowania obejmuje następujące etapy cyklu życia oprogramowania:
1) analiza wymagań i zakresu systemowego;
2) projekt architektury systemu;
3) analiza wymagań oprogramowania (specyfikacje, interfejsy zewnętrzne);
4) projektowanie architektury oprogramowania;
5) szczegółowy projekt każdej jednostki oprogramowania;
6) kodowanie oprogramowania (programowanie)
7) testowanie jednostek oprogramowania;
8) integracja (łączenie oprogramowania) i testowanie zestawu jednostek oprogramowania;
9) testy kwalifikacyjne oprogramowania (kompleksowe testy);
10) jednostki integracji systemu struktury oprogramowania powinny być łączone z jednostkami sprzętowymi;
11) testy kwalifikacyjne systemu;
12) instalacja oprogramowania.
Tak więc proces tworzenia oprogramowania ma swój początek w systemie, w którym to oprogramowanie będzie używane, i kończy się ponownie w systemie.
Po etapach rozwoju w cyklu życia oprogramowania następuje faza działania oprogramowania i konserwacji podczas pracy. Czasami lista etapów cyklu życia oprogramowania jest podawana z pewnymi uogólnieniami (powiększeniami) 12 etapów. Na przykład etapy projektowania systemu i określania wymagań dotyczących oprogramowania, projektowanie pakietu oprogramowania, projektowanie algorytmów oprogramowania, programowanie (kodowanie), debugowanie oprogramowania offline, kompleksowe debugowanie oprogramowania i oprogramowanie operacyjne.
Pomijając etapy projektowania oprogramowania, chęć natychmiastowego rozpoczęcia programowania bez dostatecznie rozwiniętych algorytmów i problemów interakcji między jednostkami strukturalnymi oprogramowania często prowadzi do chaotycznego procesu tworzenia oprogramowania z niewielkimi szansami na sukces.
Spiralny model cyklu życia oprogramowania. „Ciężkie i lekkie” (szybkie) technologie opracowywania oprogramowania
Rozważany model cyklu życia (LC) odnosi się do modelu typu kaskadowego. Ten typ modelu LC jest dobry dla oprogramowania, dla którego na samym początku rozwoju można w pełni i dokładnie sformułować wszystkie wymagania dotyczące oprogramowania.
Schemat spiralnego oprogramowania cyklu życia. Jednak prawdziwy proces tworzenia oprogramowania nie zawsze pasuje do tak sztywnego schematu i często istnieje potrzeba powrotu do poprzednich etapów z wyjaśnieniem lub zmianą podjętych decyzji.
W przypadku oprogramowania, a także innych złożonych systemów, których początkowe wymagania nie są kompletne, charakterystyczny jest iteracyjny proces rozwoju. Jednocześnie w przypadku niektórych rodzajów oprogramowania wskazane jest nawet przejście do następnego etapu tak szybko, jak to możliwe. W tym przypadku nieuniknione niedociągnięcia w tak pochopnej pracy zostaną wyeliminowane przy następnej iteracji lub pozostaną na zawsze.
Głównym zadaniem jest jak najszybsze uzyskanie wydajnego oprogramowania, aktywując w ten sposób proces wyjaśniania i uzupełniania wymagań. Jest to tak zwany spiralny model oprogramowania LC.
Na każdej cewce spirali tworzona jest wersja produktu, wymagania programowe są określone, a praca następnej cewki jest planowana. Spiralny model oprogramowania LC odzwierciedla obiektywnie istniejący proces iteracyjnego tworzenia oprogramowania (ryc. 8.2).
Uważa się, że obwód spiralny oprogramowania LC jest przeznaczony nie tyle dla pospiesznych programistów, co dla oprogramowania, którego pierwsze wersje niskiej jakości są dopuszczalne do celów funkcjonalnych oprogramowania.
Istnieje kierunek „Szybkich technologii” rozwoju oprogramowania (Agile Software Development), który daje ideologiczne uzasadnienie poglądów związanych ze spiralnym modelem cyklu życia. Technologie te oparte są na czterech pomysłach:
Interaktywna interakcja osób jest ważniejsza niż formalne procedury i narzędzia,
Uruchamianie oprogramowania jest ważniejsze niż posiadanie dokumentacji,
Współpraca z klientem jest ważniejsza niż formalne umowy,
Szybka reakcja na zmiany zewnętrzne jest ważniejsza niż ścisłe przestrzeganie planów.
Ryc. 8.2 - Schemat oprogramowania spiralnego cyklu życia
Innymi słowy, szybkie technologie mają na celu zastąpienie formalnych i czasochłonnych udokumentowanych procedur interakcji podczas opracowywania interaktywnymi, co jest możliwe przy małych projektach, wybranych cechach pracowników, umiejscowieniu programistów i klientów „w jednym pokoju” oraz do opracowywania oprogramowania niekrytycznych systemów.
Prawidłowość tych zasad do pewnego stopnia, gdy rozwój oprogramowania jest przeprowadzany przez niewielką liczbę wykwalifikowanych i oddanych „fanów”) do rozwoju niektórych rodzajów oprogramowania, jest trudny do zakwestionowania. Jednak zwinne technologie, które są uznawane przez ich ideologów, mają zastosowanie w projektach oprogramowania określonej klasy i skali, a także ogólnie w modelu spiralnym LC, a mianowicie tam, gdzie błędy oprogramowania prowadzą do pewnych niedogodności lub utraty środków do odzyskania.
W przypadku gdy wadliwe oprogramowanie prowadzi do zagrożenia życia lub dużych strat materialnych, należy zastosować solidne, przemyślane technologie w celu zapewnienia niezawodności oprogramowania.
Wraz ze wzrostem skali projektu oprogramowania, wzrostem liczby osób biorących w nim udział rośnie zapotrzebowanie na technologię twardego rozwoju, która składa się na kaskadowe oprogramowanie LC. Dokumentacja jest tutaj potrzebna, ponieważ w dowolnym momencie może zostać utracony dowolny programista, konieczna jest formalizacja relacji między programami, zarządzanie zmianami oprogramowania itp. Nie jest bez wątpienia wprowadzanie kaskadowego modelu cyklu życia do standardów rozwoju oprogramowania. Jednocześnie pozwala również wdrożyć iteracyjny proces programowania ze względu na przewidziane etapy projektowania STS i oprogramowania dla nich.
W przypadku bardzo dużych projektów oprogramowania (zespół ponad 100 programistów) technologia programistyczna jest kluczowym czynnikiem wpływającym nie tylko na jakość oprogramowania, ale także na samą możliwość jego tworzenia.
Ciężkie i lekkie technologie rozwoju oprogramowania . Twórcy wielu rodzajów oprogramowania uważają kaskadowy model cyklu życia za zbyt regulowany, zbyt udokumentowany i trudny, a zatem irracjonalny. Istnieje kierunek „Szybkich technologii” (lekkich technologii) rozwoju oprogramowania (Agile Software Development), który zapewnia ideologiczne uzasadnienie tych poglądów. Technologie te oparte są na czterech pomysłach:
1. interakcja między osobami jest ważniejsza niż formalne procedury i narzędzia,
2. działające oprogramowanie jest ważniejsze niż posiadanie dokumentacji,
3. ważniejsza jest współpraca z klientem niż formalne umowy z nim,
4. szybka reakcja na zmiany zewnętrzne jest ważniejsza niż ścisłe przestrzeganie planów.
Prawidłowość tych zasad, oprócz trzeciego, do pewnego stopnia (tworzenie oprogramowania jest prowadzone przez niewielką liczbę wykwalifikowanych programistów - „fanów”, którzy nie potrzebują kontroli i dodatkowej motywacji) jest trudnym wyzwaniem dla rozwoju oprogramowania. Jednak zwinne technologie, co uznają ich ideolodzy, mają zastosowanie w projektach oprogramowania o określonej klasie i skali, a także ogólnie w modelu spiralnym LC, a mianowicie tam, gdzie błędy oprogramowania prowadzą do pewnych niedogodności lub utraty środków do odzyskania, a wymagania oprogramowania ciągle się zmieniają , ponieważ zostały one źle zdefiniowane z wyprzedzeniem i wymagana jest szybka adaptacja do tych zmian.
Szybka technologia -próbuje osiągnąć kompromis między ścisłą dyscypliną rozwoju a jego całkowitym brakiem w imię ograniczenia przepływu dokumentów towarzyszących rozwojowi Szybkie technologie nie mogą zapewnić wysokiej niezawodności oprogramowania dokładnie ze względu na minimalizację dokumentów potwierdzających prawnie odpowiedzialność dewelopera.
Przykładem technologii Agile jest Extreme Programming (XP). Iteracje w XP są bardzo krótkie i składają się z czterech operacji: kodowania, testowania, słuchania klienta, projektowania. Zasady XP - minimum, prostota, zaangażowanie klienta, krótki cykl, bliskie interakcje deweloperów - powinny być w tym samym pokoju, codzienne spotkania operacyjne z klientem wydają się rozsądne i od dawna stosowane nie tylko w szybkich technologiach, ale w XP zostały doprowadzone do ekstremalnych wartości.
Analiza wielu projektów oprogramowania wykazała, że \u200b\u200blekkie technologie, które głoszą zasady samoorganizacji, kładąc nacisk na wykorzystanie indywidualnych umiejętności programistów, krótkie iteracje rozwoju w modelu spiralnym, XP, SCRUM są powszechne i często również prowadzą do sukcesu, maksymalnie wykorzystując cechy pracy w małych zespołach.
Tam, gdzie niepoprawnie działające oprogramowanie prowadzi do zagrożenia życia lub dużych strat materialnych, należy stosować uporządkowane, w pełni przemyślane i przewidywalne sformalizowane „ciężkie” technologie, aby zapewnić niezawodność oprogramowania nawet w przypadku średnio wykwalifikowanych programistów. Wraz ze wzrostem skali projektu oprogramowania liczba uczestników w tym potrzeba sztywnej i formalnej technologii rozwoju, która określa odpowiedzialność każdego uczestnika rozwoju wrzącej kaskada oprogramowania cyklu życia wzrasta. Nie bez powodu kaskadowy model cyklu życia jest wprowadzany do standardów rozwoju oprogramowania.
W dużych zespołach programistów na pierwszy plan wysuwa się problem zarządzania.
W przypadku bardzo dużych projektów oprogramowania kluczowe są kwestie uporządkowanego i skoordynowanego rozwoju: strukturyzacja, integracja, zapewnienie prawidłowej interakcji programów, organizacja prawidłowego i skoordynowanego wdrażania nieuniknionych zmian i wpływają na samą możliwość ich stworzenia.
W małych projektach oprogramowania algorytmiczne rozkosze odgrywają decydującą rolę wpływ poszczególnych utalentowanych osobowości, podczas gdy w dużych projektach czynniki te są wyrównane i nie mają decydującego wpływu na proces rozwoju.
Twórcy oprogramowania o przeciętnych możliwościach i większości z nich oraz przestrzegający dyscypliny technologicznej w ramach odpowiedniej technologii powinni opracować oprogramowanie o wymaganej jakości. „Zachowaj porządek, a on cię wesprze”.
Informatyka, cybernetyka i programowanie
Iteracja N USDP Zunifikowany proces tworzenia oprogramowania Model przypadku użycia opisuje przypadki, w których aplikacja będzie używana. Model analityczny opisuje podstawowe klasy aplikacji. Model projektowy opisuje relacje i relacje między klasami i przydzielonymi obiektami, a model wdrażania opisuje dystrybucję oprogramowania na komputerach.
Lekcja nr 20
Ogólne zasady i podejścia do tworzenia oprogramowania
Modele rozwoju oprogramowania
- Wodospad
- Model kaskadowy
- Spirala
- Ekstremalne programowanie
- Przyrostowy
- Metodologia MSF
Model wodospadu
Model spiralny
Rozwój przyrostowy
Analiza wymagań
Design
Realizacja
Komponent
testowanie
Integracja
Testowanie
całość
Iteracja 1 Iteracja 2 .... Iteracja N.
Ujednolicony proces rozwoju oprogramowania (USDP)
- Model przypadku użycia opisuje przypadki, w których aplikacja będzie używana.
- Model analityczny opisuje podstawowe klasy aplikacji.
- Model projektowy opisuje relacje i relacje między klasami i wybranymi obiektami.
- Model wdrożenia opisuje dystrybucję oprogramowania na komputerach.
- Model implementacji opisuje wewnętrzną organizację kodu programu.
- Model testowy składa się z komponentów testowych, procedur testowych i różnych opcji testowych.
Metodologia MSF
Typowe elementy architektury oprogramowania i typowe wymagania dotyczące oprogramowania
Odporność na awarie- zestaw właściwości systemu, który zwiększa jego niezawodność poprzez wykrywanie błędów, przywracanie i lokalizowanie złych konsekwencji dla systemu. Opracowując dowolny rzeczywisty system zapewniający odporność na uszkodzenia, należy przewidzieć wszelkiego rodzaju sytuacje, które mogą prowadzić do awarii systemu i opracować mechanizmy radzenia sobie z awariami.
Niezawodność - zdolność systemu do wytrzymywania różnych awarii i awarii.
Awaria Jest przejściem systemowym powodując błąd w całkowicie niedziałającym stanie.
Crash - błąd w działaniu systemu, który nie prowadzi do awarii systemu.
Im mniej awarii i awarii w określonym przedziale czasu, tym bardziej niezawodny system.
Jak również inne prace, które mogą Cię zainteresować |
|||
| 57355. | Różnorodność związków organicznych, ich klasyfikacja. Materia organiczna dzikiej przyrody | 48,5 KB | |
| Różnorodność związków organicznych zależy od unikalnej zdolności atomów węgla do łączenia się za pomocą prostych i wielokrotnych wiązań w celu utworzenia związków z prawie nieograniczoną liczbą atomów połączonych w łańcuchy rowerowe rowery trójkołowe policykliczne tusze itp. | |||
| 57359. | Modele informacji o przetwarzaniu tekstu | 291 KB | |
| Podstawowe pojęcia: model; model informacyjny; ustny model informacyjny; adnotacja; kompendium. Streszczenie z lat. Utwórz podsumowanie do 2. Zapisz dokument we własnym folderze pod nazwą Podsumowanie. | |||
| 57361. | Liczba ı liczba 3. Część liczb na granicach 3. Liczba zapisana 3. Liczba liczb 3. Numer wpisu | 35,5 KB | |
| Skylki całego stworzenia Hto sto peshto Hto sto przypięty Hto posid numer 1 Hto stoist pid numer 2 Imię Susіdіv іzhachka. Hto sushid bilochki dla praworęcznych Hto sushid żyrafa żyrafa Hto є znajdź Hto є znajdź nisko Hto stań na środku stworzenia Gra Pokaż mi nie zamiatane. | |||
