Proces tworzenia oprogramowania



Podobne dokumenty
Co to jest jest oprogramowanie? 8. Co to jest inżynieria oprogramowania? 9. Jaka jest różnica pomiędzy inżynierią oprogramowania a informatyką?

Inżynieria oprogramowania

Etapy życia oprogramowania

Etapy życia oprogramowania. Modele cyklu życia projektu. Etapy życia oprogramowania. Etapy życia oprogramowania

Cykle życia systemu informatycznego

Programowanie zespołowe

In ż ynieria oprogramowania wykład II Modele i fazy cyklu życia oprogramowania

MODELE CYKLU ŻYCIA OPROGRAMOWANIA (1) Model kaskadowy (często stosowany w praktyce do projektów o niewielkiej złożonoś

Inżynieria oprogramowania (Software Engineering)

Zakres wykładu. Podstawy InŜynierii Oprogramowania

Wykład 3 Wymagania. MIS n Inżynieria oprogramowania Październik Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie

Wytwórstwo oprogramowania. michał możdżonek

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32

MODELE CYKLU śycia OPROGRAMOWANIA

Przedsięwzięcia Informatyczne w Zarządzaniu

Błędy procesu tworzenia oprogramowania (Badania firmy Rational Software Corporation)

Wstęp. Podstawy inżynierii oprogramowania. Slajdy na podstawie podręcznika: Iana Sommerville a Inżynieria oprogramowania

Projektowanie oprogramowania. Wykład Weryfikacja i Zatwierdzanie Inżynieria Oprogramowania Kazimierz Michalik

Wprowadzenie do metodologii modelowania systemów informacyjnych. Strategia (1) Strategia (2) Etapy Ŝycia systemu informacyjnego

Programowanie Zespołowe

SYSTEMY INFORMATYCZNE ćwiczenia praktyczne

Waterfall model. (iteracyjny model kaskadowy) Marcin Wilk

Projektowanie systemów informatycznych. wykład 6

Jarosław Kuchta Dokumentacja i Jakość Oprogramowania. Wymagania jakości w Agile Programming

Metody wytwarzania oprogramowania. Metody wytwarzania oprogramowania 1/31

Iteracyjno-rozwojowy proces tworzenia oprogramowania Wykład 3 część 1

Projektowanie zorientowane na uŝytkownika

Inżynieria Oprogramowania. Robert Szmurło

Testowanie oprogramowania

Projektowanie systemów informatycznych. Roman Simiński programowanie.siminskionline.pl. Cykl życia systemu informatycznego

PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU>

Egzamin / zaliczenie na ocenę*

Cele oraz techniki tworzenia prototypów systemów infromatycznych. Inżynieria Oprogramowania

PROJEKTOWANIE. kodowanie implementacja. PROJEKT most pomiędzy specyfikowaniem a kodowaniem

Feature Driven Development

Inżynieria Programowania Zarządzanie projektem

In ż ynieria oprogramowania wykład II Modele i fazy cyklu życia oprogramowania

REFERAT PRACY DYPLOMOWEJ

Inżynieria Programowania Inżynieria wymagań. Plan wykładu. Motto. Wstęp. Notatki. Notatki. Notatki. Notatki. Arkadiusz Chrobot

Inżynieria Programowania Weryfikacja i zatwierdzanie

PRZEWODNIK PO PRZEDMIOCIE

Zasady organizacji projektów informatycznych

Metodyki programowania. Tomasz Kaszuba 2015

Główne założenia XP. Prostota (Simplicity) Komunikacja (Communication) Sprzężenie zwrotne (Feedback) Odwaga (Agressiveness)

Inżynieria Programowania Zarządzanie projektem. Plan wykładu. Motto. Motto 2. Notatki. Notatki. Notatki. Notatki.

PROJEKT INTERFEJSU UśYTKOWNIKA PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU>

Wykład 1 Inżynieria Oprogramowania

Tematy seminariów wg Roger S. Pressman, Praktyczne podejście do oprogramowania, WNT, Zofia Kruczkiewicz

Lekkie metodyki. tworzenia oprogramowania

Inżynieria Programowania Weryfikacja i zatwierdzanie. Plan wykładu. Motto. Wstęp. Notatki. Notatki. Notatki. Notatki.

Opis metodyki i procesu produkcji oprogramowania

Tematy seminariów wg Roger S. Pressman, Praktyczne podejście do oprogramowania, WNT, Zofia Kruczkiewicz

Procesy wytwarzania oprogramowania Specyfikacja i projektowanie oprogramowania

INŻYNIERIA OPROGRAMOWANIA

Podstawy programowania

Wprowadzenie do Behaviordriven

Projektowanie systemu sprzedaŝy ubezpieczeń dla T. U. Generali zgodnie z metodyką User-Centered Design

szkolenia pod drzewem Wybrane Techniki XP bnd 2008 Tomasz Włodarek. Materiał udostępniany na podstawie licencji Creative Commons (by-nc-nd) 1.00.

Inżynieria Oprogramowania. Inżynieria Oprogramowania 1/36

Wprowadzenie do systemów informacyjnych

Laboratorium 5 - Projektowanie programów zorientowanych obiektowo. Indywidualny projekt programistyczny

Acceptance Test Driven Development wspierane przez narzędzie ROBOT Framework. Edyta Tomalik Grzegorz Ziemiecki

Wstęp do zarządzania projektami

Jarosław Żeliński analityk biznesowy, projektant systemów

Inżynieria Programowania Inżynieria wymagań

Podstawy programowania III WYKŁAD 4

Podejście tradycyjne. plan wykonanie sekwencyjna natura wykonywanych zadań

Usługa: Audyt kodu źródłowego

Ogólne określenie wymagań. Ogólny projekt. Budowa systemu. Ocena systemu. Nie. Tak. System poprawny. Wdrożenie. Określenie.

KARTA PRZEDMIOTU. 1. Informacje ogólne. 2. Ogólna charakterystyka przedmiotu. Inżynieria oprogramowania, C12

Testy poziom po poziomie

Wstęp do zarządzania projektami

INŻYNIERIA OPROGRAMOWANIA

PRZEWODNIK PO PRZEDMIOCIE

Charakterystyka oprogramowania obiektowego

Systemy ekspertowe i sztuczna inteligencja. dr Agnieszka Nowak Brzezioska

Inżynieria oprogramowania

Kurs programowania. Wykład 12. Wojciech Macyna. 7 czerwca 2017

PLAN ZARZĄDZANIA KONFIGURACJĄ OPROGRAMOWANIA PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU>

IO - inżynieria oprogramowania. dr inż. M. Żabińska, zabinska@agh.edu.pl

Architektura Systemu. Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu.

Wykład VII. Programowanie III - semestr III Kierunek Informatyka. dr inż. Janusz Słupik. Wydział Matematyki Stosowanej Politechniki Śląskiej

INŻYNIERIA OPROGRAMOWANIA

Jakość w procesie wytwarzania oprogramowania

XQTav - reprezentacja diagramów przepływu prac w formacie SCUFL przy pomocy XQuery

Konwerter Plan testów. Jakub Rauch Tomasz Gołębiowski Adam Busch Bartosz Franaszek 1 czerwca 2008

<Nazwa firmy> <Nazwa projektu> Specyfikacja dodatkowa. Wersja <1.0>

tel. (+48 81) /22 fax (+48 81) Wykład Ćwiczenia Laboratorium Projekt

Narzędzia CASE dla.net. Łukasz Popiel

ZARZĄDZANIE PROCESEM TESTOWYM (SQAM Test Manager) 7-8 luty 2008, Warszawa Zdobądź z nami certyfikat SQAM Test Manager.

Oceny z prezentacji INKU011S. Zofia Kruczkiewicz

Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie

Maciej Oleksy Zenon Matuszyk

Kod doskonały : jak tworzyć oprogramowanie pozbawione błędów / Steve McConnell. Gliwice, cop Spis treści. Wstęp 15.

SVN. 10 października Instalacja. Wchodzimy na stronę i pobieramy aplikację. Rysunek 1: Instalacja - krok 1

Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH. Modeling and analysis of computer systems Forma studiów: Stacjonarne

Dokument Detaliczny Projektu

Tworzenie gier na urządzenia mobilne

Zwinna współpraca programistów i testerów z wykorzystaniem BDD i. by Example (JBehave/Spock/SpecFlow)

Systemy zabezpieczeń

Transkrypt:

Proces tworzenia oprogramowania http://www.projectportfolio.pl/fun/cykl%20zycia%20projektu.jpg Wykorzystane materiały: prezentacje J.E. Sienkiewicza I. Sommerville, InŜynieria oprogramowania, WNT 2003

Czym jest proces tworzenia oprogramowania? Zbiorem czynności i związanych z nimi wyników, które prowadzą do powstania produktu programowego MoŜe obejmować tworzenie oprogramowania od podstaw, jednak coraz częściej nowe oprogramowanie powstaje przez rozszerzanie i modyfikowanie istniejących systemów bądź powtórne wykorzystanie istniejących komponentów Automatyzacja procesu tworzenia oprogramowania jest do tej pory niewielka

Zasadnicze czynności w procesie tworzenia oprogramowania Specyfikowanie. Funkcjonalność oprogramowania i ograniczenia jego działania muszą być dobrze zdefiniowane. Projektowanie i implementowanie. Stworzenie oprogramowania spełniającego specyfikację. Testowanie i zatwierdzanie. Wykazanie, Ŝe wytworzone oprogramowanie spełnia specyfikację i oczekiwania klienta. Ewolucja. Oprogramowanie ewoluuje, aby spełniać zmieniające się potrzeby uŝytkowników.

Specyfikowanie Zasadniczym etapem tworzenia specyfikacji jest tzw. inŝynieria wymagań: proces szukania, analizowania, dokumentowania, sprawdzania i zatwierdzania usług i ograniczeń projektowanego systemu innymi słowy proces ustalenia, co system powinien robić, przy uwzględnieniu istniejących ograniczeń opisy usług i ograniczeń są wymaganiami stawianymi systemowi W wyniku przeprowadzonych analiz dostajemy kompletną Specyfikację Wymagań Systemowych InŜynierii wymagań poświęcone będą osobne wykłady

Projektowanie Projekt oprogramowania to opis struktury oprogramowania, które ma być zaimplementowane; danych, które są częścią systemu; interfejsów między komponentami systemu i uŝytych algorytmów. Proces projektowania moŝe obejmować opracowanie kilku modeli systemu na róŝnych poziomach abstrakcji. Czynności: Projektowanie architektury Specyfikowanie abstrakcyjne Projektowanie interfejsów Projektowanie komponentów Projektowanie struktur danych Projektowanie algorytmów

Ogólny model procesu projektowania Specyfikacja wymagań Czynności projektowe Projektowanie architektury Specyfikowanie abstrakcyjne Projektowanie interfejsów Projektowanie komponentów Projektowanie struktur danych Projektowanie algorytmów Architektura systemu Specyfikacja oprogramowania Specyfikacja interfejsów Specyfikacja komponentów Specyfikacja struktury danych Specyfikacja algorytmów Produkty projektowania

Metody projektowania Do chwili obecnej projektowanie jest często działaniem ad hoc, bez formalnej kontroli zmian ani zarządzania projektowaniem. Lepsze podejście polega na uŝyciu metod strukturalnych, które są zbiorami notacji i porad dla projektantów oprogramowania. Ich uŝycie polega zwykle na opracowaniu graficznych modeli systemu i prowadzi do duŝej ilości dokumentacji projektowej. Metody strukturalne mogą obejmować: modele przepływu danych, modele encja-związek związek, modele strukturalne, modele obiektowe. Metodom projektowania poświęcone będą osobne wykłady

Implementowanie Faza implementowania w tworzeniu oprogramowania to proces przekształcania specyfikacji systemu w działający system, na postawie projektu.

Zatwierdzanie oprogramowania Weryfikacja i zatwierdzenie mają wykazać, Ŝe system jest zgodny ze swoją specyfikacją i spełnia oczekiwania klienta. Obejmuje proces sprawdzania, m.in. kontrole, inspekcje i recenzje w kaŝdym kroku procesu tworzenia, od definicji wymagań uŝytkownika aŝ do implementacji. Z wyjątkiem małych programów, nie naleŝy testować systemu jako pojedynczej całości najpierw naleŝy wykonywać testy jednostkowe, przechodząc do coraz większych struktur.

Testowanie Programiści wykonują pewne testy kodu, który napisali. Zwykle prowadzi to do wykrycia błędów, które naleŝy usunąć z programu. Testowanie programu i usuwanie błędów to dwa róŝne procesy. Znalezienie lokalizacji błędu moŝe wymagać nowych przypadków testowych.

Fazy procesu testowania Testowanie poszczególnych jednostek (klas, komponentów) Testuje się poszczególne jednostki, aby zapewnić, Ŝe działają poprawnie. prawnie. Testowanie modułów i podsystemów Moduł jest kolekcją niezaleŝnych jednostek takich jak klasy obiektów, abstrakcyjne typy danych, albo bardziej luźną kolekcją procedur i funkcji. Kolekcję modułów moŝna z kolei zintegrować w podsystemie (większej całości). Testowanie systemu Proces ma wykryć błędy wynikające z nieprzewidzianych interakcji między podsystemami zintegrowanymi w pełen system oraz problemy z interfejsami podsystemów. Testowanie odbiorcze (akceptacyjne) Jest to końcowa faza procesu testowania przed przyjęciem systemu do uŝytkowania. Testowaniu poświęcone będą osobne wykłady

Testowanie alfa i beta Testowanie alfa jest testowaniem odbiorczym, stosowanym kiedy system jest tworzony dla konkretnego klienta. Proces testowania trwa do momentu osiągnięcia zgody pomiędzy wytwórcą systemu i klientem co do tego, Ŝe dostarczony system jest moŝliwą do przyjęcia implementacją wymagań. Testowanie beta stosuje się, kiedy system sprzedawany jako produkt programowy. Testowanie polega na dostarczeniu systemu pewnej liczbie potencjalnych klientów, którzy zgodzili się z niego korzystać. Klienci informują wytwórców o pojawiających się problemach.

Ewolucja oprogramowania Elastyczność systemów oprogramowania jest jedną z głównych przyczyn, zyn, Ŝe coraz więcej i więcej oprogramowania włącza się do wielkich, złoŝonych systemów. W przypadku oprogramowania, w przeciwieństwie do sprzętu, zmiany mogą być wprowadzone w kaŝdej chwili tworzenia systemu, lub nawet po jego zakończeniu. Koszt tych zmian moŝe być bardzo wysoki, ale wciąŝ będzie niŝszy niŝ odpowiednie zmiany w sprzęcie systemu. Zidentyfikuj wymagania stawiane systemowi Zbadaj istniejące systemy Zaproponuj zmiany systemów Zmodyfikuj system Istniejące systemy Nowy system

Praca, błędy i koszty w tworzeniu systemu Rozkład pracy w cyklu tworzenia systemu: Specyfikacja 6% Projektowanie 5% Kodowanie 7% Testowanie 15% Eksploatacja / ewolucja 67% Źródła błędów: Specyfikacja 56% Projektowanie 27% Kodowanie 7% Inne 10% Koszty poprawienia błędów: Specyfikacja 82% Projektowanie 13% Kodowanie 1% Inne 4% na podstawie: konspekt ISPI R. Tadeusiewicz

Podstawowe modele procesu tworzenia oprogramowania Model kaskadowy (wodospad, ang. waterfall) Podstawowe czynności specyfikowania, tworzenia, zatwierdzania i ewolucji są odrębnymi fazami procesu. Model przyrostowy (ang. incremental) Specyfikowanie, projektowanie, implementowanie i zatwierdzanie przeplatają p się. Model ewolucyjny (ang. evolutionary) Tworzy się prototypy w celu przedyskutowania z klientem oraz uzyskania akceptacji. Model spiralny (ang. spiral) Proces tworzenia ma postać spirali, której kaŝda pętla reprezentuje jedną fazę procesu. Tworzenie formalne systemu (anf( anf. formal) Oparte na budowaniu formalnych matematycznych specyfikacji systemu i przekształcaniu tych specyfikacji w program za pomocą metod matematycznych. matycznych. Tworzenie z uŝyciem wielokrotnym W tym podejściu zakłada się istnienie duŝej liczby komponentów zdatnych z do ponownego uŝycia.

Model kaskadowy Definiowanie wymagań Fazy modelu kaskadowego Projektowanie systemu i oprogramowania Implementacja i testowanie jednostkowe Integracja i testowanie Działanie i pielęgnacja

Opis poszczególnych faz modelu kaskadowego Definiowanie wymagań Zebranie i zdokumentowanie wymagań na system. Powstaje specyfikacja systemu. Projekt systemu i oprogramowania Zdefiniowanie architektury systemu (elementów sprzętowych i programowych). Zdefiniowanie interfejsów i interakcji między poszczególnymi elementami. Powstaje projekt systemu. Implementacja i testowanie jednostkowe Kodowanie poszczególnych jednostek programowych (np.. klas) oraz ich testowanie. Integracja i testowanie Zintegrowanie jednostek programowych do kompletnego systemu. Sprawdzenie, czy kompletny system spełnia specyfikację. Działanie i pielęgnacja Przekazanie systemu do uŝytkowania. Modyfikacja systemu zgodnie ze zmianą wymagań.

Wariant modelu kaskadowego model V Po sprawdzeniu po prawej stronie, jeŝeli wynik danego testu jest niepomyślny, to po następuje odesłanie problemu z powrotem na lewą stronę. Tam problem zostaje naprawiony i jeszcze raz podlega sprawdzeniu. źródło: konspekt ISPI R. Tadeusiewicz

Wady modelu kaskadowego Powodzenie projektu zaleŝy głownie od poprawnej i kompletnej specyfikacji systemu model kaskadowy powinien być uŝywany jedynie wówczas, gdy wymagania są jasne i zrozumiałe. Nieelastyczny podział na rozłączne etapy następnej fazy nie powinno się rozpoczynać, jeśli poprzednia się nie zakończy. Ewentualne iteracje są kosztowne oraz wymagają powtarzania wielu prac koszty opracowania i akceptacji dokumentów są wysokie. Ostatni etap moŝe się rozrosnąć w sposób niekontrolowany.

Model przyrostowy Zasada: opracowanie wstępnej implementacji, pokazanie jej uŝytkownikowi z prośbą o komentarze i udoskonalanie jej w wielu wersjach aŝ do powstania odpowiedniego systemu. czynności równoległe Specyfikacja Wersja początkowa Ogólny opis Tworzenie Wersje pośrednie Zatwierdzanie Wersja końcowa

Tworzenie badawcze w modelach przyrostowych Praca z klientem,, polegająca na badaniu wymagań. Tworzenie rozpoczyna się od tych części systemu, które są dobrze rozpoznane. System ewoluuje przez dodawanie nowych cech, które proponuje klient, aŝ do ostatecznej wersji systemu. Pojawiają się iteracje,, polegające na powtarzaniu pewnych etapów tworzenia systemu. Podejście przyrostowe zaproponowano jako sposób na ograniczenie powtarzania prac w procesie tworzenia oraz danie klientom pewnych moŝliwości odkładania decyzji o szczegółowych wymaganiach do czasu, aŝ zdobędą pewne doświadczenia w pracy z systemem. Klienci identyfikują w zarysie usługi, które system ma oferować. Wskazują, które z nich są dla nich najwaŝniejsze, a które najmniej waŝne. Definiuje się następnie pewną liczbę przyrostów, które maja być dostarczone. Gdy przyrost jest juŝ gotowy i dostarczony, klienci mogą go uruchomić. Oznacza to, Ŝe szybko otrzymują część funkcjonalności systemu

Schemat tworzenia przyrostowego Zdefiniuj zarys wymagań Przypisz wymagania do przyrostów Zaprojektuj architekturę systemu System końcowy Wytwórz przyrost systemu Zweryfikuj przyrost Zintegruj system Zweryfikuj system System nie ukończony

Warianty modelu przyrostowego Programowanie zwinne (ang. Agile software development) Ludzie i interakcje pomiędzy nimi zamiast procesów i narzędzi Działające oprogramowanie zamiast szczegółowej dokumentacji Współpraca z klientem zamiast negocjowania kontraktów Reagowanie na zmiany zamiast realizowania planu Programowanie ekstremalne (ang. extreme Programming,, XP) określenie metafory tworzonego systemu gra planistyczna prosty projekt systemu programowanie sterowane testami (Test Driven Development,, TDD) ciągła integracja, częste wydania systemu udział klienta w zespole programowanie w parach Programowaniu zwinnemu i ekstremalnemu poświęcone będą osobne wykłady

Zalety modelu przyrostowego Klienci nie muszą czekać na dostarczenie całego systemu, zanim zaczną czerpać z niego korzyść. Klienci mogą uŝywać wstępnych przyrostów jako rodzaju prototypu i zdobywać doświadczenia, które inspirują wymagania wobec późniejszych przyrostów. Ryzyko całkowitej poraŝki przedsięwzięcia jest mniejsze. Usługi o najwyŝszym priorytecie będą dostarczane jako pierwsze. Bardzo dobrze sprawdza się w przypadku systemów małych lub średnich oraz tych z krótkim czasem Ŝycia.

Wady modelu przyrostowego Proces nie jest widoczny System ma często złą strukturę Brak dokładnej specyfikacji Dokumentacja czasami nie jest aktualna Konieczne mogą być specjalne narzędzia i techniki Konieczna stała dostępność przedstawiciela klienta. Nie sprawdza się w przypadku duŝych systemów o długim czasie Ŝycia

Model ewolucyjny W tym modelu, podczas projektowania tworzy się prototyp w celu jego przedyskutowania z klientem oraz uzyskania jego akceptacji. Po akceptacji a prototypu przechodzi się do kolejnych etapów tworzenia oprogramowania. Prototypowanie zapobiega błędnemu zrozumieniu wymagań systemu, które k moŝe powodować wzrost kosztów pozwala programistom lepiej zrozumieć potrzeby klienta. Pozwala klientowi zobaczyć jak mniej więcej system będzie wyglądał (moŝna np.. rozpocząć wcześnie szkolenia). Prototyp jest zwykle porzucany (nie jest dalej rozwijany) jest to tzw. prototypowanie z porzuceniem.. W przeciwnym przypadku mamy do czynienia z tworzeniem badawczym. Prototypowanie z porzuceniem ma na celu eksperymentowanie z tymi wymaganiami uŝytkownika które są niejasne, aby lepiej zrozumieć wymagania klienta i wypracować lepszą definicję wymagań stawianych systemowi. Główne wady: konieczne specjalnie narzędzia; prototyp kosztuje.

Model spiralny Zaproponowany w 1998 r. Proces nie jest przedstawiany jako ciąg czynności z pewnymi nawrotami między nimi, ale ma postać spirali. KaŜda pętla spirali reprezentuje jedną fazę procesu. Najbardziej wewnętrzna pętla moŝe być poświęcona wykonalności systemu, następna definicji wymagań stawianych systemowi, kolejna projektowaniu itd. Jawne potraktowanie zagroŝeń.

Model spiralny schemat Określ cele, inne strategie i ograniczenia Analiza zagroŝeń Analiza zagroŝeń Oceń inne strategie, rozpoznaj i zmniejsz zagroŝenia Analiza zagroŝeń Prototyp 3 Działający prototyp Zaplanuj następną fazę Plan tworzenia Plan wymagań Plan cyklu Ŝycia Plan testowania i integracji RECENZJA Analiza zagroŝeń Prototyp 1 Zatwierdzenie wymagań Prototyp 2 Sposób postępowania Symulacje, modele, miary odniesienia Szczegółowe Wymagania Projektowanie projektowanie Kodowanie Weryfikacja i zatwierdzenie Testy akceptacji Działanie produktu Testy integracji Testy jednostek Utwórz, zweryfikuj produkt następnego poziomu

Sektory spirali w modelu spiralnym Ustalanie celów Definiuje się konkretne cele tej fazy przedsięwzięcia. Identyfikuje się ograniczenia, którym podlega proces i produkt. Rozpoznanie i redukcja zagroŝeń Przeprowadza się szczegółową analizę kaŝdego z rozpoznanych zagroŝeń przedsięwzięcia. Tworzenie i zatwierdzanie Po ocenie zagroŝeń wybiera się model tworzenia systemu. Planowanie Recenzuje się przedsięwzięcie i podejmuje decyzję, czy rozpoczynać następną pętlę spirali.

Tworzenie formalne systemów Proces tworzenia jest oparty na matematycznych przekształceniach specyfikacji systemu w program wykonywalny. Podejście to ma wiele wspólnego z modelem kaskadowym. W procesie przekształcania, formalna matematyczna reprezentacja systemu jest metodycznie przekształcana w bardziej szczegółowe, ale wciąŝ matematycznie poprawne reprezentacje systemu. Definicja wymagań Specyfikacja formalna Przekształcenie formalne Integracja i testowanie systemu

Przekształcenia formalne T1 T2 T3 T4 Specyfikacja formalna R1 R2 R3 Program wykonywalny P1 P2 P3 P4

Tworzenie formalne przykład Zapisujemy wymagania w wybranej notacji, np. Backus Naura (BNF): <postal-address> > ::= <name< name-part> > <street< street-address> > <zip< zip-part> <name-part> > ::= <personal< personal-part> > <last< last-name> > <opt< opt-jr-part> > <EOL> <personal-part> <name-part> > <personal< personal-part> > ::= <first< first-name> > <initial< initial> > ". <street-address> > ::= <house< house-num> > <street< street-name> > <opt< opt-apt-num> > <EOL> <zip-part> > ::= <town< town-name> > "," <state< state-code> > <ZIP< ZIP-code> > <EOL> <opt-jr-part> > ::= "Sr." "Jr" Jr." <roman< roman-numeral> > " Przekształcamy formalnie zapisane wymagania do postaci np. gotowego formularza, kodu C++ czy zapytań SQL ręcznie, bądź przy pomocy specjalistycznego oprogramowania. Generujemy parser (np.. programem YACC), który sprawdzi utworzony kod pod względem jego zgodności z wyspecyfikowanymi wymaganiami.

Tworzenie formalne zastosowania i problemy Oprócz specjalistycznych dziedzin procesy oparte na przekształceniach formalnych są uŝywane rzadko. Najlepiej znanym przykładem takiego formalnego procesu tworzenia jest Cleanroom,, pierwotnie opracowany przez IBM. Cleanroom jest oparty na przyrostowym tworzeniu oprogramowania, gdy formalnie wykonuje się kaŝdy krok i dowodzi jego poprawności. Wymagają specjalistycznej wiedzy i w praktyce okazuje się, Ŝe w wypadku większości systemów nie powodują zmniejszenia kosztów lub polepszenia jakości w porównaniu z innymi podejściami. Interakcje systemów nie poddają się łatwo specyfikowaniu formalnemu. Więcej informacji: http://www.fmeurope.org

Tworzenie z uŝyciem wielokrotnym Zakłada się istnienie duŝego zbioru dostępnych komponentów programowych do uŝycia wielokrotnego oraz integrującej je struktury ury Etapy procesu: analiza komponentów modyfikacja wymagań projektowanie systemu z uŝyciem wielokrotnym tworzenie i integracja Specyfikacja wymagań Analiza komponentów Modyfikacja wymagań Projekt systemu z uŝyciem wielokrotnym Tematyce tej poświęcony będzie osobny wykład Tworzenie i integracja Zatwierdzenie systemu

Zautomatyzowane wspomaganie procesu tworzenia oprogramowania Komputerowo wspomagana inŝynieria oprogramowania (CASE) korzysta z róŝnego oprogramowania do wspomagania czynności procesu tworzenia oprogramowania, takich jak inŝynieria wymagań, projektowanie, programowanie i testowanie. Czynności, które moŝna zautomatyzować za pomocą CASE: oprogramowanie do tworzenia graficznych modeli systemu jako części ci specyfikacji wymagań i projektu oprogramowania czytanie projektu za pomocą słownika danych, który przechowuje informacje o encjach i związkach w projekcie generowanie graficznego interfejsu uŝytkownika na podstawie opisu interfejsu, opracowanego interaktywnie przez uŝytkownika śledzenie błędów przez udostępnienie informacji o wykonującym się programie (debugging( debugging) automatyczne tłumaczenie programów ze starych wersji języków programowania

Technologia CASE Technologia CASE jest obecnie dostępna dla większości rutynowych czynności procesu tworzenia oprogramowania. InŜynieria oprogramowania jest czynnością projektową opartą głównie na kreatywnym myśleniu. Istniejące systemy CASE automatyzują pewne rutynowe czynności, ale próby zastosowania sztucznej inteligencji do wspomagania programowania nie powiodły się dotychczas. W większości firm procesy związane z inŝynierią oprogramowania są czynnością zespołową. InŜynierowie spędzają więc sporo czasu na interakcji z innymi członkami zespołu. Technologia CASE nie daje tu zbyt duŝego wsparcia.

Klasyfikacja narzędzi CASE Narzędzia do planowania Narzędzia do szacowania kosztów, arkusze kalkulacyjne Narzędzia do zarządzania zmianami Narzędzia do zapisu i śledzenia wymagań, systemy kontroli zmian, systemy zarządzania wersjami Narzędzia do projektowania Edytory i procesory tekstów, edytory diagramów Narzędzia do zarządzania konfiguracjami Narzędzia do budowania systemów, systemy zarządzania wersjami Narzędzia do prototypowania Języki bardzo wysokiego poziomu, generatory interfejsu uŝytkownika ka Narzędzia wspomagające Edytory projektów, słowniki danych