Cykl tworzenia oprogramowania

Cykl tworzenia oprogramowania
Bartosz Marcinkowski Michał Kuciapski

Prezentacja cyklu

Metodyka tworzenia oprogramowania
Wyróżnia się 3 rodzaje metodyk: Strukturalne Obiektowe Społeczne

Tworzenie oprogramowania
Tworzenie oprogramowania jest procesem. Jest to skończony ciąg kroków (czynności) powiązanych ze sobą relacjami, które mają doprowadzić do osiągnięcia zamierzonego celu w postaci oprogramowania (systemu) spełniającego przyjęte wymagania. W procesie tworzenia oprogramowania możliwe są pętle.

Metodyki tworzenia oprogramowania
Zstępujące (ang. Top-down) Wstępujące (ang. Bottom-up)

Cykl życia oprogramowania (systemu)
Cykl życia oprogramowania jest analogiczny do cyklu tworzenia systemów. Reprezentuje powtarzającą się w czasie całość działań prowadzonych od ujawnienia potrzeby budowy systemu aż po zakończenie jego użytkowania W cyklu życia obrazowane są kolejne etapy rozwoju i eksploatacji systemu, wraz z ich kontekstem, produktami, wzajemnymi relacjami i zależnościami w czasie Do najbardziej znanych cykli życia systemu należą: Cykl kaskadowy (liniowy, klasyczny) Cykl spiralny Cykl przyrostowy (i podejścia pochodne)

Elementy faz cyklu W każdej fazie określa się: Cele Działania Kolejność realizowanych działań Punkty przeglądu Produkty i dokumentacje

Kaskadowy cykl życia systemu
Planowanie Identyfikacja problemu Wizja rozwiązania problemu Ocena możliwych rozwiązań Decyzja na temat podjęcia projektu Czy mamy cokolwiek robić?

Planowanie Należy odpowiedzieć sobie na pytania:
W jaki sposób system przyczyni się do rozwiązania problemu? Jakie konkretne efekty biznesowe osiągną udziałowcy systemu po zrealizowaniu celu? Czy cel jest uzasadniony ekonomicznie? Czy cel jest osiągalny w kontekście istniejących ograniczeń (budżet, zasoby, technologia, uwarunkowania o charakterze organizacyjnym na etapie użytkowania, prawo) Jaki konkretnie miałby być zakres systemu? Jakie jest ryzyko podjęcia się tego projektu?

Planowanie – cd Zakres Jakość Koszt Zasoby

Planowanie – cd Informatyzacja hotelu: przykład Cele:
Poprawa obsługi gości Obniżenie kosztów własnych hotelu Efekty biznesowe: Przechwycenie klientów od konkurencji Mniejsze koszty własne Przyjęte kryteria: Zwiększenie liczby gości o 10% w pierwszym roku użytkowania systemu Wskaźnik (kosztyWłasne / gość) w pierwszym roku powinien spaść o 20% ceteris paribus (z pominięciem takich czynników jak spadek zatrudnienia czy fluktuacje płac)

Kaskadowy cykl życia systemu – cd
Planowanie Analiza Szczegółowe badanie dziedziny przedmiotowej Wyszukanie potencjalnych usprawnień Identyfikacja podstawowych problemów na styku przyszły system – organizacja Identyfikacja i dokładna specyfikacja wymagań Co my tak naprawdę mamy zrobić?

Planowanie Analiza Projektowanie Stworzenie kompletnej dokumentacji systemu Weryfikacja stworzonego modelu pod kątem zgodności z wymaganiami i dziedziną przedmiotową Jak dokładnie ma to działać?

Planowanie Analiza Projektowanie Implementacja Kodowanie Testowanie na niskim poziomie (moduły)

Planowanie Analiza Projektowanie Implementacja Testowanie integracyjne Weryfikacja Walidacja Testy akceptacyjne Cośmy tak naprawdę stworzyli? Testowanie i walidacja

Testowanie i walidacja
Weryfikacja Czy rezultat danego etapu jest zgodny z tym, co stworzyliśmy wcześniej? Czy jesteśmy konsekwentni? Walidacja Czy to, co robimy, jest tym, o co nam chodziło? Czy idziemy we właściwym kierunku?

Planowanie Analiza Projektowanie Implementacja Testowanie i walidacja Użytkowanie i adaptacja

Użytkowanie i adaptacja
Przygotowanie środowiska Instalacja systemu Przeniesienie danych Szkolenia Udostępnienie manuali Audyt Konserwacja (diagnostyka, drobne błędy) Adaptacja (np. prawo) Ulepszanie (nowe wymagania, lifting)

Zalety Kompletny Sprawdzony w praktyce
Strukturyzowalny (wsparcie narzędzi) Pozwala na łatwą dekompozycję pracy Brak nadmiarowości (koszty!)

Wady Wszystkie wymagania muszą być znane na początku
Brak sprzężenia zwrotnego wymagania – efekty (bardzo późna walidacja) Duża bezwładność (technologia) Olbrzymie koszty usuwania błędów popełnionych na wczesnych etapach oraz korekty wymagań Problemy z alokacją zasobów i znużeniem zespołu

Spiralny cykl życia systemu

Zalety Bardzo elastyczny (zmiany otoczenia, alokacja zasobów, niestabilność wymagań) Nieustanna walidacja Niskie ryzyko niepowodzenia (zakres, jakość)

Wady Długotrwałe dochodzenie do rozwiązania docelowego
Dodatkowe koszty tworzenia kolejnych prototypów Kłopoty z zarządzaniem Presja na zmniejszenie jakości

Podejście przyrostowe
Stopniowo realizowane w całości kolejne usługi systemu Funkcje te są na bieżąco walidowane przez użytkowników Po każdym przyroście można zakończyć budowę systemu (ucierpi zakres, nie jakość) Wymagania mogą być tylko częściowo zidentyfikowane Klient szybko otrzymuje jakiś rezultat Niestety czasochłonny Kłopoty z dekompozycją usług

Podejście przyrostowe – cd

Proces przygotowania aplikacji przy wykorzystaniu podejścia obiektowego

Proces przygotowania aplikacji
Analiza obiektowa – analiza opierająca się na obiektach, ich atrybutach, oferowanych usługach oraz wzajemnych powiązaniach. Projektowanie obiektowe – rozszerzanie modelu analizy o warstwy: dialogu, zarządzania danymi, zarządzania zadaniami oraz elementy specyficzne dla implementacji. Implementacja – stworzenie na podstawie dokumentacji przygotowanej podczas analizy i projektowania aplikacji.

Analiza obiektowa

Analiza obiektowa (OOA) - korzyści
Umożliwia precyzyjne określenie i zamodelowanie wymagań w stosunku do aplikacji (systemu) ze strony klienta i użytkowników. Zwiększa wewnętrzną spójność wyników analizy. Umożliwia budowanie specyfikacji poddających się zmianom. Przyśpiesza i zwiększa szanse przygotowania aplikacji zgodnie wymaganymi funkcjonalnościami.

Analiza obiektowa (OOA) – proces
Definiowanie dziedziny problemu Znajdowanie klas-i-obiektów Znajdowanie struktur Znajdowanie tematów Definiowanie atrybutów Definiowane usług

Analiza obiektowa (OOA) – definiowanie dziedziny problemu
Dziedzina problemu – rozważane pole działania. Zakres obowiązków systemu – powiązany w całość zbiór rzeczy, za które odpowiada system. Przykład: Dziedzina problemu: księgowania procesów. finansowych firmy. Zakres obowiązków systemu: księgowania odnośnie zakupu/sprzedaży/likwidacji środków trwałych.

Analiza obiektowa (OOA) – definiowanie dziedziny problemu
Dziedzina problemu: obliczanie parametrów figur płaskich i brył. Zakres obowiązków systemu: obliczanie pól i obwodów dla określonych figur płaskich i brył. opis dziedziny problemu z uwzględnieniem zakresu obowiązków systemu - link

Analiza obiektowa (OOA) – znajdowanie klas-i-obiektów
Obiekt – abstrakcja czegoś w dziedzinie problemu, odzwierciedlająca zdolności systemu do przechowywania informacji o tym, interakcji z tym czymś, lub obie te rzeczy. Klasa – opis obiektu lub obiektów z jednolitym zbiorem atrybutów i usług, zawierający opis tworzenia nowych obiektów w klasie. Klasa-i-obiekt – termin oznaczający „klasę i obiekty w tej klasie”.

Klasa-i-obiekt Symbol „klasy-i-obiektu” analizy obiektowej

Gdzie szukać: Samodzielna obserwacja Aktywnie słuchaj ekspertów Zapoznaj się z dotychczasowymi rezultatami Zapoznaj się z innymi systemami Dokument formułujący potrzeby

Czego szukać: Struktury – już istniejące relacje, np.: osoba: student, wykładowca, pracownik administracyjny. Inne systemy – systemy, z którymi współpracuje, np.: monitoring, system dystrybucyjny. Urządzenia – z jakimi zewnętrznymi urządzeniami będzie współpracować, np.: czujnik, radar, układ sterowania.

Czego szukać: Zapamiętywana rzecz lub zdarzenie – zdarzenia historyczne przechowywane w systemie, np.: data zdawania egzaminu, zapis położenia statku. Odgrywana rola – rola ludzi w systemie: użytkownik systemu, przechowywane są informacje o nich np.: egzaminator, kierownik magazynu. Procedury operacyjne – jakie procedury operacyjne, służące interakcji z człowiekiem, powinien pokazywać system, np.: polecenie egzaminacyjne.

Czego szukać: Miejsca – punkt w przestrzeni, miejscu, np.: las - las tropikalny, las barbarzyńców, głusza. Jednostki organizacyjne – do jakich jednostek organizacyjnych należą ludzie, np.: powiat, gmina.

Co kwestionować: Co system ma pamiętać o obiekcie Wymagane zachowanie Zazwyczaj wiele atrybutów Zazwyczaj więcej niż jeden obiekt w klasie Atrybuty stosowane zawsze Usługi stosowane zawsze Wymagania wynikające z dziedziny problemu Wyniki dające się wywnioskować

Przykłady w oparciu o metodologię: Symulacja zdawania na prawo jazdy – link Obliczanie pól i obwodów figur – link

Analiza obiektowa (OOA) – znajdowanie struktur
Struktura – jest wyrazem złożoności dziedziny problemu, właściwej dla zakresów obowiązku systemu. Typy struktur: Generalizacja-specjalizacja (gen-spec) – odnosi się do klas, wyrażana słowami „jest” lub „jest rodzajem”, np.: „Informatyka stosowana jest kierunkiem studiów”. Całość-część - odnosi się do obiektów, wyrażana słowem „posiada”, np.: „Prowadzący zajęcia posiada protokoły ocen”.

Generalizacja Specjalizacja1 Specjalizacja2 Oznaczenie dla struktury „gen-spec”

Całość 1,m 1,m 1 1 Część1 Część2 Oznaczenie dla struktury „całość-część”

Strategia tworzenia struktur gen-spec: Traktowanie każdej klasy jako generalizacji i zapytanie w stosunku do potencjalnych specjalizacji: Czy jest w dziedzinie problemu? Czy mieści się w zakresie obowiązków systemu? Czy będzie miało miejsce dziedziczenie? Czy spełnione są kryteria „na co zwracać uwagę i co kwestionować” Analogiczne pytania w stosunku do specjalizacji w poszukiwaniu potencjalnych generalizacji

Strategia tworzenia struktur całość-część: Zestawienie-części – np.: komputer- podzespoły Pojemnik-zawartość - np.: samochód-pasażerowie Kolekcja-elementy – np.: uczelnia-studenci

Przykłady w oparciu o metodologię: Nauczyciel akademicki – link Obliczanie pól i obwodów figur – link

Analiza obiektowa (OOA) – znajdowanie tematów
Temat – jest mechanizmem prowadzącym czytelnika (analityka, eksperta, menedżera, klienta) przez duży złożony model. Tematy umożliwiają ogólniejsze spojrzenie na złożoność dziedziny problemowej. 2 podejścia: Znajdowanie tematów na początku analizy – duże systemy. Znajdowanie tematów po ustalenie struktur – pozostałe.

1 1 2 2 1. Temat1 2. Temat2 Tematy zwinięte 1. Temat1 Klasa-i-obiekt1 Klasa-i-obiekt2 Tematy rozwinięte 2. Temat2 Klasa-i-obiekt1 Klasa-i-obiekt2 Tematy częściowo zwinięte

Strategia: Najwyższą klasę każdej struktury awansowuje się na tematy Poddziedziny problemu Minimalizacja zależności pomiędzy strukturami i połączeniami obiektów Zasada odnośnie ilości elementów

Przykłady w oparciu o metodologię: Obliczanie pól i obwodów figur – link

Analiza obiektowa (OOA) – definiowanie atrybutów
Atrybut – jest pewną daną (stanem systemu), dla których każdy obiekt danej klasy ma swoją własną wartość. Atrybuty uszczegóławiają analizę. Hermetyzacja – polega na ukrywania dostępu do atrybutów, dostęp wyłącznie za pośrednictwem usług.

Klasa-i-obiekt Atrybut1 Atrybut2 Oznaczenia stosowane dla atrybutów

Strategia: Identyfikujemy atrybuty – jaką wiedzę powinien posiadać obiekt: Jak zazwyczaj jestem opisany Co muszę wiedzieć W jakim mogę być stanie Czy należę do dziedziny problemu i obowiązków systemu Do czasu projektowania odroczone: normalizacja, mechanizmy identyfikacji, atrybuty obliczalne

Strategia: Umieszczamy atrybuty – sprawdzamy strukturę. Identyfikujemy powiązania obiektów – określenie skojarzenia pomiędzy obiektami konieczne do wykonania obowiązków. Samolot PlanLotu 0,m 1

Strategia: Sprawdzamy specjalne przypadki: Wartość nie dotyczy Klasy tylko z jednym atrybutem Powtarzające się wartości Powiązania wiele-do-wielu Wielokrotne powiązania Specyfikujemy atrybuty: jednostka miary, zakres, ograniczenie, wykaz, precyzja, domyślna wartość, wymagany, warunki tworzenia i dostępu, wartości narzucone przez inne atrybuty, kody stanów.

Analiza obiektowa (OOA) – definiowanie usług
Usługa – jest to określone zachowanie obiektu, które jest on zobowiązany przejawić. Usługi uszczegóławiają analizę Ustalają komunikację pomiędzy obiektami Operują na atrybutach

Klasa-i-obiekt Usługa1 Usługa2 Oznaczenia stosowane dla usług

Strategia: Identyfikacja stanów obiektu – zmiana zachowania obiektu, np.: ZmieńStatusWindy Identyfikacja wymaganych usług: Algorytmicznie proste: Utwórz, Powiąż, PobierzUstaw, Zwolnij Algorytmicznie złożone: Oblicz, monitoruj Identyfikacja powiązań odpowiadających komunikatom – relacja pomiędzy obiektami typu nadawca komunikatu/odbiorca komunikatu

Strategia: Przykład: Egzaminator -> Egzaminowany komunikat związany z WykonajPolecenie(…) Nadawca Odbiorca

Strategia: Odpowiedź na pytania: Usługi jakich innych obiektów są mu potrzebne Jakie inne obiekty potrzebują jego usług Specyfikacja usług – diagram przepływu sterowania

Warunek (jeśli; war. wstępny; war. rozpoczęcia, zakończenia) Blok tekstowy Pętla (dopóki; wykonuj; powtarzaj; rozpocznij/zakończ) Łącznik (dowiązany do górnej części następnego symbolu) Notacja dla schematu usługi

Warunek wstępny: Podstawa = „Trójkąt” Tak TwórzObiekt typu trójkąt Ustaw długości krawędzi Warunek wstępny: Podstawa = „…”

Analiza obiektowa

Projektowanie obiektowe (OOD) - cechy
Niższy poziom abstrakcji niż w przypadku analizy obiektowej Modelowanie szczególnej implementacji W przeciwieństwie do analizy możliwa zależność od języków programowania Dodanie i modyfikacja możliwa w stosunku do wszystkich warstw

Projektowanie obiektowe (OOD) - składowe
Składowa kontaktu z człowiekiem – WE/WY, np.: Okno, PrezentacjaWyniku Składowa problemu – modyfikacja OOA Składowa zarządzania zadaniami – zadanie wykonywane w czasie rzeczywistym, komunikację i koordynację, np.: MenadżerZadań, Zadanie Składowa zarządzania danymi – dostęp i zarządzanie danymi: pliki, bazy danych

Projektowanie obiektowe (OOD)

OOA oraz OOD Pełna Dokumentacja: Obliczanie pól i obwodów figur – link

Implementacja Na podstawie przygotowanej dokumentacji podczas OOA i OOD napisanie aplikacji Proces: Programowanie Testowanie Projektowanie Analiza

Proszę o ewentualne pytania
Michał Kuciapski

Cykl tworzenia oprogramowania

Podobne prezentacje

Prezentacja na temat: "Cykl tworzenia oprogramowania"— Zapis prezentacji:

Podobne prezentacje

О projekcie

Zwrotny adres

Wejść

Zaloguj się poprzez sieć społeczną:

Cykl tworzenia oprogramowania

Podobne prezentacje

Prezentacja na temat: "Cykl tworzenia oprogramowania"— Zapis prezentacji:

Podobne prezentacje

О projekcie

Zwrotny adres