Inżynieria Programowania zakres i organizacja przedmiotu

Prezentacja na temat: "Inżynieria Programowania zakres i organizacja przedmiotu"— Zapis prezentacji:

1 Inżynieria Programowania zakres i organizacja przedmiotu
w y k ł a d 1 Inżynieria Programowania zakres i organizacja przedmiotu

2 Konspekt bieżącego wykładu
Wprowadzenie Dziedzina Inżynierii Programowania Oprogramowanie Proces tworzenia oprogramowania Pojęcie metodyki Modele cyklu życiowego oprogramowania Wykład inauguracyjny poświęcony jest przedstawieniu zakresu, jaki obejmuje Inżynieria Oprogramowania

3 mgr inż. Aleksander Pyszny.
Wprowadzenie Warunki zaliczenia Sun.iinf.polsl.gliwice.pl/~jszedel/sds/IP-NSM Plan przedmiotu Procesy związane z tworzeniem oprogramowania Wymagania i specyfikacje oprogramowania Analiza i projektowanie Weryfikacja i atestowanie Kolokwium na ostatnim wykładzie, najprawdopodobniej bez możliwości korzystania z materiałów. Pozycje literatury znajdują się na kolejnych slajdach, decyzja o tym czy slajdy zostaną przekazane studentom zapadnie później. Przedmiot będzie prowadzony zgodnie z przebieg typowego projektu informatycznym realizowanego zgodnie z modelem kaskadowym. Materiały opracowane dla potrzeb wykładu z przedmiotu Inżynieria Oprogramowania są kompilacją informacji (tekstów i rysunków) zaczerpniętych ze źródeł wymienionych w liście literatury na następnym slajdzie. Autorami kompilacji są: dr inż. Jacek Szedel, dr inż. Michał Kolano, mgr inż. Aleksander Pyszny.

4 Wprowadzenie Literatura w języku polskim
G. Booch, J. Rumbaugh, I. Jacobson: “UML. Przewodnik użytkownika”, WNT, Warszawa, 2001, 2002 J. Górski (red.): „Inżynieria oprogramowania w projekcie informatycznym”, wyd. II rozszerzone. Mikom, Warszawa 2000 A. Jaszkiewicz: "Inżynieria oprogramowania", Helion, 1997 P. Szmal (red.): "Inżynieria programowania. Metody i ćwiczenćia laboratoryjne", Skrypt uczelniany Politechniki Śląskiej nr 2120, Gliwice, 1998 R. L. Baber: "O oprogramowaniu inaczej", WNT, Warszawa 2001 M. Kliszewski: „Inżyżnieria oprogramowania obiektowego. Część 1: Analiza obiektowa”, WKT „RESPEKT”, Tomaszów Mazowiecki M. Kliszewski: „Inżynieria oprogramowania obiektowego. Część 2: Projekt obiektowy”, WKT „RESPEKT”, Tomaszów Mazowiecki Literatura: Choć większa część literatury dotyczy zagadnień związanych z modelowaniem obiektowym wykład objemować będzie również aspekty modelowania strukturalnego (diagramy DFD i ERD). Do zaliczenia wykładu przedmiotu, oprócz uczestniczenia w wykładach niezbędne jest przynajmniej przejrzenie pracy p.Jaszkiewicza. Jeśli chodzi o laboratorium to w pierwszym semestrze dotyczy ono bardziej aspektów związanych z testowaniem i uruchamianiem, a więc procesami związanymi z realizacją prostych projetków. W celu zaliczenia przedmiotu należy zapewnić sobie dostęp do skryptu pod redakcją p.dr.Szmala

5 Wprowadzenie Literatura w jęz. polskim (c.d)
J. Martin, J.J. Odell: „Podstawy metod obiektowych”, WNT, Warszawa 1997 E. Yourdon: "Współczesna analiza strukturalna", WNT, Warszawa, 1997 P. Fuglewicz, K. Stąpor, A. Trojnar: "CASE dla ludzi", Lupus, Warszawa, 1996 R. Barker, C. Longman: "CASE MethodSM. Modelowanie funkcji i procesów", WNT, Warszawa, 1996 R. Barker: "CASE MethodSM. Modelowanie związków encji", WNT, Warszawa, 1996 P. Coad, E. Yourdon: "Analiza obiektowa", READ ME, Warszawa 1994 P. Coad, E. Yourdon: "Projektowanie obiektowe", READ ME, Warszawa 1994 P. Coad, J. Nicola: "Programowanie obiektowe", READ ME, Warszawa 1993 D. Van Tassel: "Praktyka programowania", wyd.2, WNT, Warszawa 1987

6 Wstęp (c.d) Literatura w jęz. angielskim
I. Sommerville: "Software engineering", Addison-Wesley, Reading, New York 1998 R.S. Pressman: “Software engineering. A practitioner’s approach”, McGraw-Hill Companies, Inc., New York, Toronto 1997 G. Booch: "Object-oriented analysis and design (with applications)", Benjamin/­Cummings, Redwood City 1994 Większość wykładu opiera się na pracy Sommerville'a. W internecie znaleźć można zestaw slajdów zawierających wykład na podstawie książki.

7 Wprowadzenie Definicje Przedmiot zainteresowania Obszar zastosowania
Na samym początku odpowiedzieć należy na pytanie -czy IP jest nauką i czy powinna być wykładana na uczelni technicznej ? -czym zajmuje się IP -gdzie można stosować metody IP

8 Inżynieria programowania
Inżynieria programowania – to dyscyplina wiedzy inżynierskiej, której celem jest przyczynienie się do produkowania oprogramowania o dobrej jakości, oddawanego na czas, mieszczącego się w budżecie i spełniającego potrzeby użytkowników. Inżynieria programowania - to konsekwentne stosowanie ustalonych przez naukę i zweryfikowanych w praktyce zasad, metod i środków w pracach nad wytwarzaniem i konserwacją oprogramowania oraz ich organizowanie ze względu na cele ekonomiczno-techniczne. Inżynieria oprogramowania nie jest nauką, jest raczej wiedzą inżynierską.

9 Definicje literaturowe
Inżynieria Programowania to: Zastosowanie systematycznego, zdyscyplinowanego, ilościowego podejścia do wykonywania, wykorzystywania i konserwowania oprogramowania [IEEE 93] Zastosowanie metod naukowych i matematycznych, dzięki czemu możliwości sprzętu komputerowego stają się użyteczne dla ludzi dzięki programom, procedurom i odpowiedniej dokumentacji [Boehm-S.E. Economics 1981] Wiedza techniczna dotycząca wszystkich faz cyklu życia oprogramowania, której celem jest uzyskanie wysokiej jakości produktu - oprogramowania [Jaszkiewicz-I.O. 1997] Trzy definicje z trzech różnych źródeł: pierwsza kładzie nacisk na metodykę, druga podkreśla aspekt naukowy, a trzecia jakość dostarczanego produktu

10 Przedmiot zainteresowań
Różne aspekty tworzenia, rozwijania i eksploatacji oprogramowania Próba racjonalizacji postępowania w celu: uzyskania oprogramowania działającego niezawodnie i efektywnie na rzeczywistym sprzęcie i realizującego zadany cel ograniczenie wysiłku i czasu niezbędnego do uzyskania produktu o pożądanych cechach zapewnienie optymalnego wykorzystania zasobów zachowanie ustalonego budżetu i terminów projektowych

11 CASE Grupy aspektów Organizacja prac nad oprogramowaniem Metodyki
Narzędzia Osoba prawna Osoba fizyczna Firma CASE

12 Obszar zainteresowania
Duże systemy liczba wykonawców: od kilkudziesięciu do kilku tysięcy wyodrębniony zespół kierujący wykonawcy o różnych kwalifikacjach, zespół nie w pełni stabilny Małe systemy metody IP można z powodzeniem stosować w przedsięwzięciach o mniejszej skali, chociaż część problemów zanika (np. ze względu na uproszczoną organizację)

13 Oprogramowanie Czym jest oprogramowanie Rodzaje programów
Charakterystyka oprogramowania Cechy oprogramowania

14 Czym jest oprogramowanie
Oprogramowanie to: kod (program), realizujący określone funkcje struktury danych umożliwiające programowi odpowiednie przetwarzanie danych dokumentacja opisująca mechanizmy działania programu przedstawiająca sposoby korzystania z programu

15 Rodzaje programów Rodzaje programów:
ogólne „z półki”, („off the shelf”) na zamówienie („bespoke”) Problemy i metody IP stosowane w obu przypadkach są identyczne. Główna różnica to źródło specyfikacji programu dla ogólnych tworzona wewnętrznie np. przez dział marketingu w systemach na zamówienie określana przez klienta składającego zamówienie

16 Charakterystyka oprogramowania
Oprogramowanie jest tworzone, a nie produkowane w klasycznym sensie Oprogramowanie nie „zużywa się” z biegiem czasu, ale może się pogarszać na skutek wprowadzanych zmian Oprogramowanie w większości budowane jest od podstaw, rzadziej składane z gotowych elementów (ta sytuacja ulega stopniowej zmianie) cechy oprogramowania w porównaniu z innymi dziedzinami produkcji

17 Atrybuty oprogramowania
Podstawowe atrybuty dobrego oprogramowania uniwersalność - możliwość dostosowania oprogramowania do zmieniających się potrzeb pewność - niezawodność i bezpieczeństwo, czyli zabezpieczenie przed oddziaływaniem otoczenia (security) oraz pewność pracy (safety) - awaria oprogramowanie nie powinna powodować fizycznych i ekonomicznych szkód wydajność - oprogramowanie nie powinno marnować zasobów systemowych wygoda w użyciu - oprogramowanie powinno mieć właściwy interfejs użytkownika i dokumentację

18 Kompromisy Koszt Wydajność
Jeśli wymagany jest wysoki poziom jednego z atrybutów (np. wydajności) koszty wytworzenia oprogramowania rosną wykładniczo Koszt Tutaj dobrze pasuje następujący przykład: Załóżmy, że elektrownia Rybnik została zmodernizowana i stała się elektrownią atomową. Potrzebne jest oprogramowanie do sterowania prętami grafitowymi regulującymi przebieg reakcji rozszczepiania atomu i niedopuszczające do przegrzania reaktora. Odpowiednie oprogramowanie gotowa jest dostarczyć za 1600 zł + VAT firma JanSOFT z Klimaszowej. Pan Jan Kowalski, właściciel firmy, twierdzi że napisał w Visual Basicu nie jeden program i jak dotychczas nikt nie narzeka. Pytanie – dlaczego to jest śmieszne. Odpowiedź: gdy wymagany jest wysoki poziom jednego z atrybutów (tutaj pewność) nikt nie weźmie na poważnie takiej oferty. Wydajność

19 Inne atrybuty oprogramowania
Poprawność określa, czy oprogramowanie wypełnia postawione przed nim zadania i czy jest wolne od błędów. Łatwość użycia jest miarą stopnia łatwości korzystania z oprogramowania. Czytelność pozwala na określenie wysiłku niezbędnego do zrozumienia oprogramowania. Ponowne użycie charakteryzuje przydatność oprogramowania, całego lub tylko pewnych fragmentów, do wykorzystania w innych produktach programistycznych. Stopień strukturalizacji (modularność) określa, jak łatwo oprogramowanie daje się podzielić na części o dobrze wyrażonej semantyce i dobrze wyspecyfikowanej wzajemnej interakcji.

20 Inne atrybuty oprogramowania
Efektywność opisuje stopień wykorzystania zasobów sprzętowych i programowych stanowiących podstawę działania oprogramowania. Uniwersalność mówi o łatwości przenoszenia oprogramowania na inne platformy sprzętowe czy programowe. Skalowalność opisuje zachowanie się oprogramowania przy rozroście liczby użytkowników, objętości przetwarzanych danych, dołączaniu nowych składników, itp. Współdziałanie charakteryzuje zdolność oprogramowania do niezawodnej współpracy z innym niezależnie skonstruowanym oprogramowaniem.

21 Proces tworzenia oprogramowania
Zasadnicze czynności Rozkład kosztów Mity o oprogramowaniu Klasyfikacja organizacji procesu tworzenia

22 Proces Proces to sekwencja czynności wykonanych w określonym celu.
Pierwszy krok do sukcesu – dostrzec, że tworzenie oprogramowania nie jest „aktem” lecz procesem. początek koniec sekwencja czynności

23 Proces tworzenia oprogramowania
Proces tworzenia oprogramowania jest to zestaw czynności, metod, praktyk i przekształceń, które stosują ludzie, by opracowywać (tworzyć) i konserwować oprogramowanie i inne pokrewne produkty z nim związane (np. plan przedsięwzięcia, projekt, kod, zestawy testów, podręczniki użytkownika). W miarę jak organizacja (firmy) dojrzewa, proces programowy staje się lepiej zdefiniowany.

24 Schemat prostego procesu
Analiza, Projektowanie Implementacja Testowanie Uruchamianie Bardziej złożone podejścia zostaną omówione na kolejnych wykładach Implementacja zawiera elementy optymalizacji Optymalizacje (pamięciowa i czasowa ) oraz testowanie i uruchamianie będą przedmiotem laboratorium (warsztat programisty) To jest bardzo prosty model, jak widać nie uwzględnia fazy strategiczne, fazy definiowania wymagań, połączone jest analiza i projektowanie, do których zresztą nie można wrócić, jeśli zostanie popełniony jakiś błąd itp. Ten model odpowiada sposobowi, w jaki implementuje się oprogramowania na zajęciach PK1 do PK3 Eksploatacja Konserwacja

25 Zasadnicze czynności Specyfikacja oprogramowania – określenie funkcji systemu i jego ograniczeń) Tworzenie (development) Walidacja (atestowanie) – potwierdzenie zgodności ze specyfikacją Ewolucja – dostosowanie do zmieniających się potrzeb użytkownika

26 Organizacja procesu tworzenia
Poziom organizacji procesu tworzenia (jak ewoluuje organizacja firmy) Wstępny Nieformalny Zarządzany Zdefiniowany Mierzony Optymalizowany

27 Organizacja procesu tworzenia (c.d.)
Poziom wstępny anarchia w tworzeniu, brak standardów, procedur; jedynym efektem prac jest kod programu Poziom nieformalny wykonuje się takie czynności, jak projektowanie, testowanie, ale bez ich planowania i monitorowania, ich jakość zależy od solidności wykonawcy Poziom zarządzany (zaplanowany i śledzony) proces jest monitorowany, weryfikowany jest poprawność, zgodność z harmonogramem, mają miejsce zaplanowane przeglądy

28 Organizacja procesu tworzenia (c.d.)
Poziom zdefiniowany proces tworzenia i zarządzania opiera się na udokumentowanych procedurach i standardach Poziom mierzony przeprowadzane są szczegółowe pomiary jakości procesu i produktu, możliwe jest przewidywanie wydajności procesu (np. w sytuacji zastosowania określonego narzędzia) Poziom optymalizowany ciągłe ulepszanie organizacji dzięki ilościowemu określeniu efektywności procesu oraz poprzez wprowadzanie nowych idei i technologii

29 Koncepcja cyklu życiowego oprogramowania

30 Zasadnicze składowe cyklu wytwórczego oprogramowania
Faza strategiczna: określenie celów, planowanie i definicja projektu Definiowanie wymagań: określenie co oprogramowanie ma robić Analiza: dotyczy dziedziny przedsiębiorczości, wymagań systemowych Projektowanie: projektowanie pojęciowe, projektowanie logiczne Implementacja: rozwijanie, testowanie, dokumentacja Testowanie: sprawdzenie czy system robi to co powinien Dokumentacja: przygotowanie materiałów o systemie Instalacja: uruchomienie systemu u klienta Wdrożenie: przygotowanie użytkowników, akceptacja, szkolenie Działanie: wyłączając wspomaganie tworzenia aplikacji: utrzymanie, konserwacja, pielęgnacja takie pojęcia zdarza się słyszeć jeśli jest mowa o procesie tworzenia oprogramowania

31 Definiowanie wymagań Proces ustalania jakie usługi są wymagane oraz jaki jest zakres odpowiedzialności systemu Proces definiowania wymagań zwany też inżynierią wymagań obejmuje: Studium wymagalności Analizę wymagań Specyfikację wymagań Walidację wymagań

32 Projekt i implementacja oprogramowania
Projektowanie to proces konwersji specyfikacji wymagań w projekt działającego systemu Projekt oprogramowania – przygotowanie planu budowy systemu oprogramowania, które zapewni realizację specyfikacji wymagań Implementacja – budowa wykonywalnego program zgodnie z planem projektowym Czynności projektowania i implementacji są ściśle powiązane i mogą się wzajemnie przeplatać

33 Czynności fazy projektowej
Projektowanie architektury Specyfikacja oprogramowania Projekt interfejsu Projektowanie komponentów Projektowanie struktur danych Projektowanie algorytmów

34 Metodologie projektowania
Systematyczne podejście do procesu projektowania Projekt jest zwykle dokumentowany z wykorzystaniem modeli graficznych Niektóre modele Model przepływu danych (data-flow model) Model encja-związak (entity-relation-attribute model) Modele obiektowe (object models)

35 Cykl życiowy oprogramowania
Cykl życiowy oprogramowania (ang. Livecycle) – zależny od organizacji i typu tworzonego oprogramowania zestaw czynności, niezbędnych do jego dostarczenia klientowi w założonym czasie i przy założonym budżecie. Inne określenia – cykl wytwórczy oprogramowania, proces wytwórczy oprogramowania. bez komentarza

36 Generyczne modele cyklu życia oprogramowania
Model kaskadowy (the waterfall model) separacja i rozróżnienie faz specyfikacji i implementacji Model ewolucyjny (evolutionary development) specyfikacja i implementacja przeplatają się Generyczne – może zła nazwa – tłumaczenie z generic - > chodzi o „czyste koncepcje”.

37 Prosty model kaskadowy (wodospadowy)
Określenie wymagań Cele i szczegółowe wymagania wobec systemu. Analiza Projektowanie Szczegółowy projekt systemu uwzględniający wcześniejsze wymagania. Implementacja Testowanie Modyfikacje producenta - usunięcie błędów, zmiany i rozszerzenia. Konserwacja

38 Model kaskadowy Zalety
przydatny w harmonogramowaniu i budżetowaniu przedsięwzięcia formalny odbiór rezultatów poszczególnych faz ułatwia monitorowanie postępu projektu przynajmniej teoretyczna możliwość prowadzenia projektów w reżimie potokowym ułatwia prowadzenie rozliczeń finansowych z klientem Wady narzuca ścisłą kolejność faz wysoki koszt błędów ponoszonych we wczesnych fazach cyklu długa przerwa w kontaktach z klientem problemy z wprowadzaniem zmian w projekcie

39 Model kaskadowy z iteracjami
Określenie wymagań Analiza Projektowanie Implementacja Testowanie Konserwacja

40 czynności przebiegające równolegle
Model ewolucyjny Specyfikacja Wersja początkowa Zarys systemu Rozwój systemu Wersje pośrednie Weryfikacja Wersja końcowa Taki model nieświadomie wykorzystują studenci w czasie prac nad projektami PK czynności przebiegające równolegle

41 Model ewolucyjny Zalety
bardzo dobry dla małych projektów lub części większej całości (np. interfejs użytkownika) dobry dla systemów o krótkim czasie życia (np. migracje danych) projekt może szybko wystartować i to zarówno przy dobrym zrozumieniu potrzeb użytkownika jak i przy słabo zdefiniowanych wymaganiach Wady trudno określić zaawansowanie projektu problemy z budżetowaniem, harmonogramowaniem itp. często wymaga specjalnych narzędzi ułatwiających budowę prototypów wyprodukowane systemy są najczęściej źle ustruktualizowane

42 Hybrydowe modele cyklu życia oprogramowania
W przypadku dużych systemów istną częścią procesu zarządzania projektem jest przeciwdziałanie ryzyku Ponieważ ryzyko wynika głównie z nieodpowiedniej lub niepełnej informacji, aby je wyeliminować należy zdobyć pewne dodatkowe dane. Modele generyczne nie uwzględniają faz związanych z zarządzeniem ryzykiem; w przypadku dobrze zdefiniowanych problemów można wykorzystać model kaskadowy a w przypadku systemów wysokiego ryzyka prototypowanie (cykl ewolucyjny) I właśnie miedzy innymi dlatego powstały modele hybrydowe

43 Model spiralny - wprowadzenie
Przegląd: Ustalenie celów, alternatywnych dróg i ograniczeń Identyfikacja i analiza ryzyka (ew. budowa prototypu) Ogólnie Konstrukcja (model kaskadowy) Atestowanie (w tym przez klienta). Jeżeli ocena nie jest w pełni pozytywna, rozpoczynany jest kolejny cykl. Planowanie: Ustalenie planu kolejnej fazy

44 Model spiralny Boehm’a
Identyfikacja i analiza ryzyka (ew. budowa prototypu) Przegląd: Ustalenie celów, alternatywnych dróg i ograniczeń Przegląd Analiza ryzyka Analiza ryzyka Przegląd Analiza ryzyka Prototyp 3 Prototyp operacyjny Przegląd Prototyp 2 Analiza ryzyka Prototyp 1 Przegląd Symulacja, modele, testy wydajności Plan cyklu życia i akwizycji wymagań Koncepcja działania Wymagania I szczegółowo – opis w materiałach dr.Szmala Projekt produktu Projekt szczegółowy Walidacja wymagań Planowanie tworzenia (rozwijania) Konstrukcja (model kaskadowy) Atestowanie (w tym przez klienta). Kod Walidacja produktu Test jednostek Planowanie scalania i testowania Test scalania Planowanie: Ustalenie planu kolejnej fazy Test akceptacyjny Obsługa

45 Model spiralny Zalety zmniejszenie ryzyka
elastyczność – dla każdego z zagadnień można stosować odmienny model rozwoju przeglądy kończące poszczególne fazy ułatwiają szybkie wykrywanie błędów Wady kontrakty często zawierają specyfikację, harmonogram oraz sposób wytwarzania dostarczanych składowych systemu co często ogranicza zastosowanie modelu spiralnego model wymaga ekspertyz z zakresu zarządzania ryzykiem bez komentarza.

46 Model przyrostowy (odmiana modelu spiralnego)
Określenie wymagań Wybierany i realizowany jest podstawowy zestaw funkcji. Po realizacji pewnych funkcji następuje zrealizowanie i dostarczenie kolejnych funkcji. Ogólny projekt Proces realizowany iteracyjnie Wybór podzbioru funkcji Szczegółowy projekt, implementacja testy Taki model w nieco zmienionej postaci jest wykorzystywany przez Rational Unified Process Dostarczenie zrealizowanej części systemu

47 Model iteracyjny przyrostowy Rational Unified Approach
Metodyka RUP – nakład pracy w ramach poszczególnych etapów. Źródło: RUP © Rational Software

48 Iteracje w modelu Rational Unified Approach
tradycyjny model kaskadowy Przykłady skopiowane z metodyki RUP – jak widać model iteracyjny, w którym w każdym cyklu większość nakładów dotyczy jednego z etapów model iteracyjny Źródło: RUP © Rational Software

49 Podsumowanie Dziedzina Inżynierii Oprogramowania Oprogramowanie
Proces tworzenia oprogramowania Pojęcie metodyki Modele cyklu życiowego oprogramowania