Robert Szmurło 1
Złożoność inżynierii oprogramowania Programowanie komputerowy jest zdecydowanie najbardziej skomplikowanym zadaniem intelektualnym podejmowanym przez człowieka. Kiedykolwiek. Gerald M. Weinberg - Understanding the professional programmer, 1988 Problem: Kod zbudowany jest z wielu tysięcy linii kodu (w przypadku średnich systemów komercyjnych) Instrukcje mogą być pogrupowane w procedury; kod nadal posiada tysiące procedur Procedury są pogrupowane w moduły (klasy, komponenty); kod nadal posiada setki modułów 2
Inżynieria oprogramowania - nie tylko 'kodowanie' Środowisko Klient Programista Model środowiska Oprogramowanie Model oprogramowania 3
Definicja Zastosowanie: systematycznego, zdyscyplinowanego, ilościowego podejścia do rozwoju, eksploatacji, utrzymania oprogramowania. IEEE Std 6 10.12.1990 IEEE Standard Glossary of Software Eng. Terminology 4
Computing Curricula Program nauczania informatyki Struktury dyskretne Podstawy programowania Algorytmy i złożoność Architektura systemów komputerowych Systemy operacyjne Technologie sieciowe Języki i paradygmaty programowania Komunikacja człowiek-komputer Grafika komputerowa Sztuczna inteligencja Bazy danych Problemy społeczne i zawodowe Inżynieria oprogramowania Nauki obliczeniowe 5
Inżynieria oprogramowania - Nauczanie Moduły wchodzące w skład procesu nauczania inżynierii oprogramowania. Obligatoryjne Opcjonalne Wymagania Metody formalne Projektowanie Systemy specjalne Walidacja Komponenty Ewolucja Niezawodność Under auspices of Procesy Zarządzanie Narzędzia API 6
Plan wykładu Wymagania użytkownika i oprogramowania Jakość wymagań oprogramowania Programowanie obiektowe Język UML Statyczne modele architektury Dynamiczne modele architektury Techniki modelowania Zarządzanie (IS) Narzędzia CASE Testowanie oprogramowania Ewolucja oprogramowania 7
Pracodawcy się skarżą Absolwenci nie potrafią się komunikować, Mają niedostateczne przygotowanie do pracy w zespole, Brak im umiejętności skutecznego i produktywnego zarządzania ich pracą indywidualną. 8
Czym jest inżynieria oprogramowania? Inżynieria oprogramowania dotyczy między innymi zarządzania złożonością Złożonością potrzeb klienta Złożonością kodu Złożonością procesu wdrożenia Złożonością procesu ewolucji oprogramowania Inżynieria oprogramowania dotyczy zaspokajania rzeczywistych potrzeb klienta Inżynieria oprogramowania dotyczy organizacji pracy zespołowej Małe zespoły (2-6 osób) Duże zespoły (dziesiątki osób) Rozdzielone zespoły (np. rozwój systemów przez oddziały w różnych krajach) 9
Inżynieria oprogramowania kryterium sukcesu Projekt został wykonany w założonym budżecie Projekt zakończył się w terminie Dostarczony system spełnia rzeczywiste potrzeby klienta System zaspokajający potrzeby Proszę. To są moje potrzeby Projekt systemu informatycznego 10
Kryzys inżynierii oprogramowania Grupa Standish, Chaos Report, 2004 34% - projektów informatycznych zakończonych sukcesem 82% - przekroczenie założonego budżetu 52% - średnia spełnionych wymagań użytkowników Na pierwszej konferencji NATO związanej z inżynierią oprogramowania (1967) stwierdzono: mamy kryzys 11
Typowe objawy choroby projektu Niezadowoleni klienci To nie jest system jakiego oczekiwaliśmy! Żaden z naszych urzędników nie będzie w stanie się nim posługiwać Niezadowoleni dostawcy Czego oni w końcu od nas chcą? Dlaczego oni nieustannie zmieniają zdanie?... ale my odwaliliśmy taki kawał roboty! Konflikty dotyczące zakresu Wymagacie od nas zrealizowania dwa razy większego systemu od tego jaki określiliście w kontrakcie!..., ale te funkcje miały być dotępne dopiero w następnej wersji! Nie dostarczyliście funkcjonalności określonej w paragrafie 7 punkt 8b naszego kontraktu! - Ależ oczywiście, że dostarczyliśmy 12
Typowe objawy choroby projektu Chaotyczna obsługa zmian wymagań koledzy, dodajcie nam tu jeszcze taką małą tabelkę na środku, to was prawie nic nie będzie kosztowało, myśleliśmy, że ta zmiana nie będzie miała dla was istotnego znaczenia Niewyspani programiści poprosimy pizzę pod drzwi o północy i dużo Jolt Coli, dajcie nam dziesięciu nowy programistów Stres pod koniec projektu ten system działa jak żółw, przecież tu brakuje jeszcze funkcji z punktu 10 podpunkt 89 specyfikacji Brak powtarzalności procesu to o ile tym razem przekroczymy budżet? właściwie to jak będziemy tym razem pisać te wymagania? Godzenie się na marsz ku klęsce: musicie ten system zrobić dwa razy szybciej niż konkurencja. OK, damy radę! 13
Typowe przyczyny choroby Niedokładne specyfikowanie wymagań czy ''konto'' oznacza ''konto użytkownika'' czy też ''konto bankowe'', a może ''stan zasobów''? Zła komunikacja to ten formularz jest tak istotny? Brak precyzyjnej architektury to właściwie na której maszynie ma być zainstalowany podsystem wydruków? Brak panowania nad złożonością systemu nasza baza danych ma 1500 tabel, a kod zawiera 2000 klas! Zbyt późne wykrywanie niespójności i dopiero teraz mi mówisz, że ta twoja procedura nie ma parametru Y? Niewystarczające testowanie wygląda na to, że już działa 14
Typowe przyczyny choroby Subiektywizm w ocenach ta specyfikacja jest całkiem dobra Brak kontroli zmian: a właściwie to skąd wynika potrzeba tego nowego formularza? kto grzebał w interfejsie komponentu Z? Niestosowanie narzędzi: nam wystarczy dobre środowisko deweloperskie! Zbyt późna weryfikacja spełnienia wymagań zamawiającego: mogliście się wcześniej zapytać, jaki kolor mają mieć wszystkie ekrany! 15
Lekarstwo na chorobę projektu Jim Johnson, Standish Group Jest coraz lepiej (spójrz na statystyki), ale dlaczego? Ludzie (organizacje zajmujące się rozwojem oprogramowania) zaczynają stosować systematyczne metodyki wytwarzania oprogramowania. Czego więc potrzebujemy? Metodyki! Metodyka grupuje trzy podstawowe elementy w jedną spójną całość: Notacja -język modelowania, za pomocą którego zapisuje się produkty procesu tworzenia oprogramowania (modele). Techniki zbiór sposobów postępowania w celu stworzenia konkretnych elementów modeli (zapisanych za pomocą notacji). Proces techniczny uporządkowanie wytwarzania oprogramowania poprzez wyodrębnienie atomicznych zadań do wykonania (przy użyciu technik) i określenie kolejności oraz zależności między nimi. 16
Notacja dla modelowania wymagań Notacja powinna ograniczać stopień skomplikowania wymagań Notacja powinna być łatwo ulegać transformacji do projektu a następnie kodu Metodyka! Co tworzymy za pomocą notacji? modele, które opisują złożone wymagania użytkownika modele, które pozwalają śledzić złożone zależności między tymi wymaganiami modele, które są zrozumiałe przez użytkowników (rysunek jest wart więcej niż tysiąc słów) modele, które mogą być później użyte przez architektów do projektowania systemu Jaki język pozwala tworzyć takie modele? 17
Notacja redukuje złożoność UML pozwala na abstrakcję pozwala nam skoncentrować się na najbardziej istotnych elementach; pozwala tworzyć ogólne pojęcia definiując je za pomocą mniejszych Miasto Dom Budynek użyteczności publicznej Okno 18
Proces tworzenia oprogramowania Modele procesu tworzenia oprogramowania Iteracja Specyfikowanie oprogramowania Projektowanie i implementowanie oprogramowania Zatwierdzanie oprogramowania Ewolucja oprogramowania Zautomatyzowane wspomaganie procesu 19
Każdy proces uwzglednia Specyfikowanie oprogramowania Funkcjonalność oprogramowania i ograniczenia jego działania muszą być zdefiniowane. Projektowanie i implementowanie oprogramowania Oprogramowanie, które spełnia specyfikację, musi być stworzone. Zatwierdzanie oprogramowania Oprogramowanie musi być zweryfikowane, aby zapewnić, że robi to, czego oczekiwał klient. Ewolucja oprogramowania Oprogramowanie musi ewoluować, aby spełniać zmieniające się potrzeby użytkownika. 20
Modele procesów tworzenia oprogramowania Model kaskadowy W tym modelu podstawowe czynności specyfikowania, tworzenia, zatwierdzania i ewolucji są odrębnymi fazami procesu takimi jak specyfikowanie wymagań, projektowanie oprogramowania, implementacja, testowanie itd. Tworzenie ewolucyjne (RAD) W tym procesie czynności specyfikowania, projektowania i zatwierdzania przeplatają się. Pierwsza wersja systemu powstaje bardzo szybko na podstawie abstrakcyjnych specyfikacji. Później jest udoskonalana zgodność z informacjami otrzymanymi od klienta. Tworzenie formalne systemu (modelowanie) To podejście jest oparte na budowaniu formalnych matematycznych specyfikacji systemu i przekształcaniu tych specyfikacji w program za pomocą metod matematycznych. Weryfikacja zgodności komponentów polega na wnioskowaniu matematycznych o ich zgodności ze specyfikacją. Tworzenie z użyciem wielokrotnym (linie produkcyjne) W tym podejściu zakłada się istnienie dużej liczby komponentów zdatnych do ponownego użycia. Proces budowy systemu polega głównie na integrowaniu tych fragmentów, a nie na tworzeniu ich od początku. 21
Model kaskadowy 22
Tworzenie ewolucyjne Równoległe czynności Specyfikacja Ogólny Ogólnyopis opis Tworzenie Zatwierdzanie Wersja początkowa Wersje Wersje Wersje pośrednie pośrednie pośrednie Wersja końcowa 23
Tworzenie formalne Tworzenie formalne systemów Definicja wymagań Specyfikacja formalna Integracja i testowanie systemu Przekształcenia formalne Przekształcenia formalne T1 Specyfikacja formalna T3 R1 P1 T2 R2 P2 T4 Program wykonywalny R3 P3 P4 24
Tworzenie z użyciem wielokrotnym Specyfikacja wymagań Analiza komponentów Modyfikacja wymagań Tworzenie i integracja Projekt systemu z użyciem wielokrotnym Zatwierdzanie systemu 25
Tworzenie spiralne 26
Podstawy modelowania UML Diagram klas Diagram pakietów Diagram komponentów Diagram przypadków użycia Diagram czynności Diagram sekwencji Diagram obiektów Diagram wdrożenia Diagram komunikacji Diagram stanów 27
Diagram klas 28
Diagram pakietów 29
Diagram komponentów 30
Diagram przypadków użycia 31
Diagram czynności 32
Diagram sekwencji 33
Diagram stanów 34
Techniki wyodrębniana oraz specyfikowania wymagań Analiza dokumentów Zapoznanie się z dokumentami dostarczonymi przez klienta w celu odkrycia rzeczywistych potrzeb Podkreślanie rzeczowników i czasowników Określanie niektórych paragrafów jako wymagań Metodyka! Praca bezpośrednio z klientem Spotkania i rozmowy z klientem oraz przyszłymi użytkownikami Praca grupowa Grupowe sesje modelowania wymagań: użytkownicy, analitycy określają i zapisują wymagania za pomocą określonej notacji Burze mózgów 35
Cykl życia podejście inżynierskie Wymagania Projekt Implementacja 36
Inżynieria wymagań Proces: Wymagania 37
Imżynieria wymagań Wymagania Wymagania funkcjonalne Wymagania pozafunkcjonalne 38
Interakcja Dziękuję za uwagę. Chcemy być coraz lepsi! Jeżeli coś cię zainteresowało napisz e-maila: robert@iem.pw.edu.pl Jeżeli coś cię bardzo znudziło napisz e-maila: robert@iem.pw.edu.pl Jeżeli zauważyłeś błąd napisz e-maila: robert@iem.pw.edu.pl 39