inżynieria oprogramowania - wikidydwikidyd.iem.pw.edu.pl/attachments/inzop_e/io_wprow.pdf · ee...

EE 2007 Inżynieria Oprogramowania 1

Inżynieria Oprogramowania

Robert Szmurło


Złożoność inżynierii oprogramowania

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

„Programowanie komputerowy jest zdecydowanie najbardziej skomplikowanym zadaniem intelektualnym podejmowanym przez człowieka. Kiedykolwiek.”

Gerald M. Weinberg - „Understanding the professional programmer”, 1988


Inżynieria oprogramowania - nie tylko 'kodowanie'

Klient Programista

Środowisko

Model środowiska

Oprogramowanie

Model oprogramowania


DefinicjaZastosowanie:

– systematycznego,– zdyscyplinowanego,– ilościowego

podejścia do– rozwoju,– eksploatacji,– utrzymania

oprogramowania.

IEEE Std 6 10.12.1990IEEE Standard Glossary of Software Eng. Terminology


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

Computing Curricula – Program nauczania informatyki


Inżynieria oprogramowania - Nauczanie

Wymagania

Projektowanie

Walidacja

Ewolucja

Procesy

Zarządzanie

Narzędzia

API

Metody formalne

Systemy specjalne

Komponenty

Niezawodność

Obligatoryjne Opcjonalne

Moduły wchodzące w skład procesu nauczania inżynierii oprogramowania.

Under auspices of


Plan wykładuWymagania 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


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ą.


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)


Inżynieria oprogramowania – kryterium sukcesuProjekt został wykonany w założonym budżecie

Projekt zakończył się w terminie

Dostarczony system spełnia rzeczywiste potrzeby klienta

Projekt systemu informatycznego

Proszę. To są moje potrzeby

System zaspokajający

potrzeby


Kryzys inżynierii oprogramowaniaGrupa 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”


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”


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ę!”


Typowe przyczyny chorobyNiedokł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”


Typowe przyczyny chorobySubiektywizm 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!”


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?

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.

Metodyki!


Notacja dla modelowania wymagańNotacja powinna ograniczać stopień skomplikowania

wymagań

Notacja powinna być łatwo ulegać transformacji do projektu a następnie – kodu

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?

Metodyka!


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

Dom Miasto Budynek użyteczności publicznej

Okno


Proces tworzenia oprogramowania– Modele procesu tworzenia oprogramowania– Iteracja– Specyfikowanie oprogramowania– Projektowanie i implementowanie oprogramowania– Zatwierdzanie oprogramowania– Ewolucja oprogramowania– Zautomatyzowane wspomaganie procesu


Każdy proces uwzgledniaSpecyfikowanie 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.


Modele procesów tworzenia oprogramowaniaModel 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.


Model kaskadowy


Tworzenie ewolucyjne

Specyfikacja

Tworzenie

Zatwierdzanie

Wersja początkowa

WersjepośrednieWersje

pośrednie

Wersjepośrednie

Wersjakońcowa

Ogólny opisOgólny opis

Równoległeczynności


Tworzenie formalne

Definicjawymagań

Specyfikacjaformalna

Przekształceniaformalne

Integracja i testowaniesystemu

Specyfikacjaformalna R1 R2 R3 Program

wykonywalny

T1 T2 T3 T4

P1 P2 P3 P4

Przekształcenia formalne

Tworzenie formalne systemów


Tworzenie z użyciem wielokrotnym

Specyfikacjawymagań

Analizakomponentów

Modyfikacjawymagań

Projekt systemuz użyciem wielokrotnym

Tworzenie i integracja

Zatwierdzaniesystemu


Tworzenie spiralne


Podstawy modelowania UMLDiagram 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


Diagram klas


Diagram pakietów


Diagram komponentów


Diagram przypadków użycia


Diagram czynności


Diagram sekwencji


Diagram stanów


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ń

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

Metodyka!


Cykl życia – podejście inżynierskie

Wymagania Projekt Implementacja


Inżynieria wymagań

Wymagania

Proces:


Imżynieria wymagań

Wymagania funkcjonalne

Wymagania pozafunkcjonalne

Wymagania


Interakcja

Dziękuję za uwagę.

Chcemy być coraz lepsi!

Jeżeli coś cię zainteresowało napisz e-maila:– [email protected]

Jeżeli coś cię bardzo znudziło napisz e-maila:– [email protected]

Jeżeli zauważyłeś błąd napisz e-maila:– [email protected]

inżynieria oprogramowania - wikidydwikidyd.iem.pw.edu.pl/attachments/inzop_e/io_wprow.pdf · ee...

Documents