Wytwarzanie oprogramowania

Podobne dokumenty
Projektowanie systemów informatycznych. wykład 6

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

Zakres wykładu. Podstawy InŜynierii Oprogramowania

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

Etapy życia oprogramowania

RUP. Rational Unified Process

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

Wykład 1 Inżynieria Oprogramowania

Inżynieria oprogramowania (Software Engineering)

Opis metodyki i procesu produkcji oprogramowania

PRZEWODNIK PO PRZEDMIOCIE

Narzędzia CASE dla.net. Łukasz Popiel

Podstawy programowania III WYKŁAD 4

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

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

Feature Driven Development

Programowanie zespołowe

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

Zasady organizacji projektów informatycznych

Procesy wytwarzania oprogramowania Specyfikacja i projektowanie oprogramowania

ZARZĄDZANIE WYMAGANIAMI ARCHITEKTONICZNYMI

Metody wytwarzania oprogramowania. Metody wytwarzania oprogramowania 1/31

Waterfall model. (iteracyjny model kaskadowy) Marcin Wilk

Cykle życia systemu informatycznego

Narzędzia informatyczne wspierające przedsięwzięcia e-commerce

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

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

Przedsięwzięcia Informatyczne w Zarządzaniu

Projektowanie oprogramowania

Konfiguracja modelowania w procesie wytwarzania oprogramowania

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

Zofia Kruczkiewicz - Modelowanie i analiza systemów informatycznych 2

INŻYNIERIA OPROGRAMOWANIA

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

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

Podrozdziały te powinny zawierać informacje istotne z punktu widzenia przyjętego celu pracy

Architektura oprogramowania w praktyce. Wydanie II.

MSF. Microsoft Solution Framework

SYSTEMY INFORMATYCZNE ćwiczenia praktyczne

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

Zagadnienia. Inżynieria Oprogramowania

Inżynieria oprogramowania. Jan Magott

Rozpoczęcie, inicjacja (ang. inception

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

Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010

Egzamin / zaliczenie na ocenę*

Agile Project Management

Cel wykładu. Literatura. Wyższa Szkoła Menedżerska w Legnicy. Modelowanie wymagań Wykład 2

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 5 Definicja systemu

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

Modelowanie i analiza systemów informatycznych

Diagramy przepływu danych I

Metodyki programowania. Tomasz Kaszuba 2015

1. WYMAGANIA WSTĘPNE W ZAKRESIE WIEDZY, UMIEJĘTNOŚCI I INNYCH KOMPETENCJI

Zakład Języków Programowania Instytut Informatyki Uniwersytet Wrocławski

PRZEWODNIK PO PRZEDMIOCIE

Spring Framework - wprowadzenie i zagadnienia zaawansowane

Rational Unified Process. Dokładny opis metodyki i procesu produkcji oprogramowania

Faza analizy (modelowania) Faza projektowania

Spis treúci. 1. Wprowadzenie... 13

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

Modele bezpieczeństwa logicznego i ich implementacje w systemach informatycznych / Aneta Poniszewska-Marańda. Warszawa, 2013.

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

Języki i metodyka oprogramowania

Analiza i projektowanie obiektowe 2016/2017. Wykład 10: Tworzenie projektowego diagramu klas

PRZEWODNIK PO PRZEDMIOCIE

REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl

PRZEWODNIK PO PRZEDMIOCIE

Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty

Podstawy modelowania programów Kod przedmiotu

Agile vs PRINCE /2015 I rok st. magisterskie Informatyka

Projektowanie oprogramowania

Program szkolenia: Wprowadzenie do Domain Driven Design dla biznesu (część 0)

Jak opisać wymagania zamawiającego wybrane elementy

Wprowadzenie, podstawowe pojęcia, projekt a produkt Wykład1

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

Tworzenie gier na urządzenia mobilne

Jakość w procesie wytwarzania oprogramowania

Testowanie oprogramowania

Wykorzystanie standardów serii ISO oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych

Zarządzanie projektami. Wykład 2 Zarządzanie projektem

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

UML w Visual Studio. Michał Ciećwierz

STUDIA NIESTACJONARNE I STOPNIA Przedmioty kierunkowe

Zagadnienia. Inżynieria Oprogramowania

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

IO - Plan wdrożenia. M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak. 5 czerwca 2006

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

Wykład 2. MIS n Inżynieria oprogramowania Marzec Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie

Projektowanie oprogramowania

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

Dokument Detaliczny Projektu

Inżynieria oprogramowania I

Uniwersytet w Białymstoku Wydział Ekonomiczno-Informatyczny w Wilnie SYLLABUS na rok akademicki 2012/2013

Plan wykonania systemu ISOiWUT

KIERUNKOWE EFEKTY KSZTAŁCENIA

Analiza i programowanie obiektowe 2016/2017. Wykład 6: Projektowanie obiektowe: diagramy interakcji

Inżynieria oprogramowania II

Transkrypt:

AiPA 6 Wytwarzanie oprogramowania Proces tworzenia oprogramowania jest procesem przekształcenia wymagań w oprogramowanie zgodnie z metodyką, która określa KTO CO robi JAK i KIEDY. - Wymagania Proces tworzenia oprogramowania Nowe lub zmienione oprogramowanie Metodyka KTO CO JAK KIEDY Zespół Język 1

Wytwarzanie oprogramowania Proces tworzenia oprogramowania jest opisywany w kategoriach ról (w których występują pracownicy), czynności (zadań) skojarzonych z rolami oraz produktów powstających, modyfikowanych lub potrzebnych w związku z realizacją czynności - Pracownik rola k - Czynność - jednostka pracy odpowiada za odpowiada za Produkty 2

Metodyka wytwarzania SI Metodyka: spójny, logicznie uporządkowany zestaw metod i procedur o charakterze technicznym i organizatorskim pozwalający zespołowi realizować cykl życia SI. Metodyka określa KTO CO robi JAK i KIEDY Metodyka określa: fazy przedsięwzięcia i role uczestników; modele tworzone w każdej fazie; scenariusze postępowania; reguły przechodzenia do kolejnej fazy; język, którego należy używać; dokumentację powstającą w każdej fazie. W metodyce może być zastosowane strukturalne lub obiektowe podejście. Podejście strukturalne "widzi" system jako realizację funkcji, które to funkcje korzystają z danych. Obiektowe podejście zakłada budowanie systemu ze składników, które mają i dane i zachowanie. W dziedzinie obiektowego podejścia standardowym od 1997 roku językiem wyrażania wiedzy o SI jest UML (Unified Modeling Language). 3

Metodyka wytwarzania SI ZP (RUP) Może istnieć wiele metodyk różniących się odpowiedziami, które dają na pytania KTO CO robi JAK i KIEDY. Niekiedy termin proces jest używany w sensie metodyka procesu. Zunifikowany Proces (ZP, ang. Unified Software Development Process -USDP) jest uogólnioną metodyką powstałą pod koniec lat 90ch, która jest wynikiem rozwoju od lat 70-ch wielu metodyk, stosujących podejście obiektowe. RUP (Rational Unified Process) jest komercyjnym wariantem ZP, stosowanym i sprzedawanym przez firmę Rational IBM, zawiera między innymi specyficzne komputerowe wspomaganie, własne standardy, dokumenty itp. 4

Zunifikowany Proces ZP może być opisany w dwóch wymiarach: czasu (poziomy)- aspekt cyklu życia procesu, wyrażony w fazach i iteracjach; zawartości: przedstawia dyscypliny: nazwane grupy czynności procesu związane z pewną dziedziną pojęciową w ramach przedsięwzięcia. Dyscypliny grupują czynności logicznie. Zunifikowany proces wyróżnia następujące dyscypliny: Modelowanie biznesowe; Wymagania; Analiza; Projektowanie; Implementacja; Testowanie; Wdrożenie; Zarządzanie przedsięwzięciem. Fazy(etapy): inicjacja (rozpoczęcie), rozwinięcie, budowa, przekazanie. Każda faza ma cel, podzbiór "najważniejszych"dyscyplin, wynik - "kamień milowy". Kamien Milowy (KM): wynik, który pozwoli iść dalej (zbiór kluczowych warunków, które powinny być spełnione i zbiór produktów, które muszą być uzyskane). 5

Zunifikowany Proces Rozpoczęcie Rozwinięcie Budowa Przekazanie KM1 KM2 KM3 KM4 6

Zunifikowany Proces Nakłady na czynności poszczególnych dyscyplin w trakcie projektu: Rozwinięcie Rozpoczęcie Budowa Dyscypliny Przekazanie Modelowanie.przedsięb. Wymagania Analiza i projektowanie Implementacja Testowanie Wdrożenie Wstępna iteracja Iteracja Iter.1 Iter.2 Iter.n, n+1,... 7

Zunifikowany Proces Fazy nie są identyczne pod względem nakładów i harmonogramu Rozpoczęcie Rozwinięcie Budowa Przekazanie Nakłady ~ 5% 20% 65% 10% Czas 10% 30% 50% 10% Wykorzystanie narzędzi generujących kod może zmienić proporcje. Jeden cykl życia systemu to przejście przez cztery fazy. 8

Zunifikowany Proces: fazy a iteracje W każdej z faz proces może przechodzić kilka iteracji - sekwencji działań z ustalonym planem i kryteriami. Iteracja: wykonanie mniej lub bardziej kompletne logicznej sekwencji wszystkich istotnych działań związanych z tworzeniem systemu. Iteracja skutkuje powstaniem nowej wewnętrznej wersji systemu, różnica między aktualną i poprzednią wersją jest "przyrostem" systemu. Na koniec iteracji powstaje zbiór modeli, który reprezentuje wersje systemu. Np. model PU zawiera zbiór już opracowanych PU - niektóre kompletnie, niektóre tylko w zarysie. Spójne z tym są modele analizy i projektu - zawierają realizacje właśnie tych PU. 9

Charakterystyka faz ZP: Rozpoczęcie Cele: - zrozumieć, co się buduje: ustalić zakres i kluczowa funkcjonalnośc; - określić co najmniej jedno możliwe rozwiązanie; - oszacować koszt, harmonogram, ryzyko; - zdecydować, jak będzie przebiegać proces i jakie narzędzia są potrzebne. Główne role: kierownik projektu i architekt. Najważniejsze dyscypliny: - wymagania - analiza; W niewielkim wymiarze mogą się pojawić czynności projektowania i implementacji, jeśli zdecydowano się budować prototyp. Kamień milowy: 10

Charakterystyka faz ZP: Rozpoczęcie, KM1 Warunki, które musza być spełnione Produkty, które musza być uzyskane Wszystkie strony porozumieli się co do celów przedsięwzięcia Wszystkie strony porozumieli się co do zakresu systemu Wszystkie strony porozumieli się co do wstępnego oszacowania kosztów i czasu. Biznesowy aspekt jest wstępnie rozpatrzony przez kierownika przedsięwzięcia Kierownik przedsięwzięcia ocenił zagrożenia Potwierdzono wykonalność techniczną poprzez studium techniczne i/lub prototypowanie Powstał zarys architektury Dokument Wizja, zawierający kluczowe wymagania, cechy i ograniczenia. Wstępny Model PU, w 20-30% kompletny. Słownik przedsięwzięcia. Wstępny plan przedsięwzięcia Studium biznesowe Dokument (lub baza danych) oceny zagrożenia Prototypy Wstępny dokument architektury 11

Charakterystyka faz ZP: Rozwinięcie, KM2 Cele: - wykreować dającą się zrealizować koncepcję architektury i działający szkielet systemu (pierwsza wersja); - uściślić ocenę zagrożeń, zidentyfikować cechy systemu i nadać priorytet ze względu na zagrożenie; - zdefiniować jakościowe atrybuty ( np. akceptowalną niezawodność); - opracować przypadki użycia dla około 80% funkcjonalnych wymagań; - opracować szczegółowy plan fazy budowy; - sformułować potrzeby odnośnie zasobów, czasu, oprzyrządowania, kwalifikacji zespołu i kosztów. Najważniejsze dyscypliny: - wymagania: uściślenie wymagań i zakresu - analiza: ustalić, co i jak należy zbudować; - projektowanie: wykreować stabilną architekturę; - implementacja: zbudować pierwszą (szkieletową) wersję (baseline); - testowanie: przetestować pierwsza wersję. 12

Charakterystyka faz ZP: Rozwinięcie, KM2 Warunki, które musza być spełnione Produkty, które musza być uzyskane Wykreowana architektura i działająca wersja Wizja produktu jest stabilna Wykonalna wersja, Model projektowy Model implementacji, Model rozmieszczenia Model Przypadków użycia Dokument Wizja Ocena zagrożeń przeprowadzona Studium opłacalności ponownie przeprowadzono i osiągnięto porozumienie z zainteresowanymi stronami; Powstał dostatecznie szczegółowy plan odnośnie potrzebnych w następnej fazie czasu i środków, uzgodniony z zainteresowanymi stronami. Zgodzono się na kontynuację przedsięwzięcia. Uaktualniona ocena ryzyka Uaktualnione studium opłacalności. Studium biznesowe i Plan przedsięwzięcia. Podpisana umowa. 13

Charakterystyka faz ZP: Budowa, KM3 Cele: - zakończyć kompletowanie i uzupełnienie wymagań, analizę i projektowanie i rozwinąć wstępną wersję w finalny system. Kluczowe hasło - utrzymanie integralności architektury systemu. Najważniejsze dyscypliny: -- implementacja - testowanie 14

Charakterystyka faz ZP: Budowa, KM3 Warunki, które musza być spełnione Produkty, które musza być uzyskane Powstały produkt informatyczny jest dostatecznie stabilny i jakościowo satysfakcjonujący, żeby przekazać go użytkownikowi. Zainteresowane strony porozumiały się odnośnie przekazania. Finalny produkt Modele Wyniki testów Instrukcja obsługi. Opis. Plan przekazania. 15

Charakterystyka faz ZP: Przekazanie, KM4 Cele: - poprawić błędy; - przygotować użytkownika do użytkowania; - dostosować produkt do funkcjonowania u użytkownika; - przygotować dokumentację użytkownika; - zapewnić konsultacje użytkownika; Najważniejsze dyscypliny: --implementacja - dostosowanie do środowiska użytkownika; - testowanie - beta-testowanie i testowanie akceptacyjne u użytkownika. 16

Charakterystyka faz ZP: Przekazanie, KM4 Warunki, które musza być spełnione Produkty, które musza być uzyskane Beta-testowanie przeprowadzono, konieczne zmiany dokonane, użytkownik usatysfakcjonowany Finalny produkt Dokumentacja użytkownika Uwaga! Zunifikowany proces jest pewnym wzorcem, konkretne przedsięwzięcie może wymagać dostosowania procesu: różna może być liczba iteracji, zawartość faz, zestaw powstających artefaktów. 17

ZP: Podsumowanie Zunifikowany Proces tworzenia SI jest : oparty o PU: - PU służą do specyfikacji wymagań: wszystkich funkcjonalnych i niektórych niefunkcjonalnych. - PU są przedmiotem opracowania w modelach analizy i projektowym w terminach klas i komponentów, w ten sposób ustala się odpowiedzialność klas; - programiści implementują komponenty, które są integrowane w przyrost, każdy przyrost realizuje kilka PU; - testowanie ustala, czy system poprawnie realizuje PU. architekturocentryczny: polega na ustalaniu architektury. PU wyrażają wymagania funkcjonalne, architektura - formę ich realizacji. iteracyjny i przyrostowy: Proces tworzenia produktu informatycznego od rozpoczęcia realizacji do zakończenia może przejść przez kilka cykli: każdy związany z nową wersją dla klienta. Cykl składa się z czterech faz. Na końcu każdej fazy -"Kamienie milowe" procesu - moment podjęcia ważnych decyzji: - czy "iść dalej"? - jaki budżet? - jaki harmonogram? W iteracjach fazy rośnie stopień spójności między modelami i wewnątrz modeli. 18

Alternatywne podejścia do wytwarzania oprogramowania Zarzuty wobec ciężkich procesów: Duża liczba artefaktów Zbiurokratyzowanie Sformalizowanie Wynik - przedłużenie trwania przedsięwzięcia. extreme programming (XP) - przedstawiciel agile (zwinnych) procesów. Zasady: Klient na miejscu Krótkie wersje, ciągłe testowanie i integracja Refaktoring: programiści zmieniają program bez zmiany działania, doskonaląc go Programowanie parami na jednej maszynie Kolektywne prawa do kodu Standardy kodowania umożliwiają komunikowanie się. 19

Technologie realizacji aplikacji Wzorce Zauważono, że w różnych aplikacjach dla przedsiębiorstw pojawiają się te same problemy. Ich zalecane rozwiązania wzorce - są skatalogowane: opisano problem, grupę klas i ich współdziałanie. Zaimplementowane wzorce komponenty można traktować jako klocki budowlane do składania aplikacji. Różni producenci klocków różnie implementują wzorce. Zestaw klocków platforma implementacyjna Najbardziej popularne platformy realizacji aplikacji:.net Microsoft J2EE(Sun Java 2 Platform, Enterprise Edition) 20

Koncepcja MDA (Model Driven Architecture) Nowe podejście do wytwarzania aplikacji modele są niezbędnym składnikiem procesu projektowania systemu, w projektowaniu systemu tworzymy modele różniące się stopniem abstrahowania od szczegółów implementacyjnych, są trzy poziomy abstrakcji i odpowiadające im modele: CIM, PIM i PSM 21

Idea MDA - budować model stopniowo: 1) najpierw wyrazić cele przedsiębiorstwa i dziedzinę problemu w sposób niezależny od sposobu ich realizacji (CIM Computation Independent Model) 2) następnie przedstawić wymagane przetwarzanie w sposób niezależny od platformy PIM (Platform Independent Model), 3) PIM odwzorować w model PSM(Platform Specific Model) Z PSM może być wygenerowany kod aplikacji. Oddzielenie biznesowego aspektu aplikacji od implementacji pozwala na uniezależnienie się od dostawcy implementacji, szybkie tworzenie aplikacji w ślad za zmianą procesów biznesowych. 22

23

Koncepcja MDA (Model Driven Architecture) modele są niezbędnym składnikiem procesu projektowania systemu, w projektowaniu systemu tworzymy modele różniące się stopniem abstrahowania od szczegółów implementacyjnych, są trzy poziomy abstrakcji i odpowiadające im modele: CIM, PIM i PSM 24

Zaliczenie Przy obronie projektu każdy dostanie 2 pytania, odpowiedzi na które zadecydują o ocenie z wykładu. 25