Wstep do Inzynierii Oprogramowania

1
Wstep do Inzynierii Oprogramowania

• Bartosz Balis

2
Definicja

• Inzynieria projektowanie, budowa i obsluga
  konstrukcji, maszyn, procesów i systemów w
  przemysle i codziennym zyciu
• Inzynieria oprogramowania projektowanie,
  rozwój, dokumentowanie, wdrazanie i pielegnacja
  oprogramowania
• Cel jak w kazdej inzynierii optymalizacja
  kosztów i niezawodnosc produktu

3
Powstanie inzynierii oprogramowania

• Lata 60 kryzys oprogramowania
• Coraz wieksze i bardziej zlozone systemy
• Bo coraz wieksza moc obliczeniowa komputerów!
• Jeden na 4 projekty konczyl sie porazka
• Tworzenie duzych systemów trwalo 3-5 lat
• Czesto stawaly sie przestarzale, zanim zostaly
  ukonczone!
• Powstawaly systemy niskiej jakosci nie
  odpowiadajace wymaganiom
• Pielegnacja oprogramowania stala sie niezwykle
  trudna i kosztowna
• Rozwiazanie opracowac metodologie (proces)
  rozwoju oprogramowania

4
Jak walczyc ze zlozonoscia?

• Abstrakcja
• Ukrywanie szczególów
• Wyodrebnianie wspólnych wlasnosci
• Wprowadzanie nowych pojec do oznaczania tych
  wlasnosci
• Dekompozycja
• Podzial problemu/przedmiotu na mniejsze, które
  moga byc traktowane osobno
• Wielokrotne uzycie
• Ponowne uzycie juz utworzonych komponentów
• Zgodnosc z ludzkim sposobem myslenia
• Uzywanie pojec, notacji, jezyka, narzedzi, itd.,
  odpowiadajacych ludzkiej psychice, sposobie
  postrzegania, itd.

5
Proces inzynierii oprogramowania

• Studium wykonalnosci (feasibility study)
• Czy to w ogóle sie oplaca? Czy za tyle to
  zrobimy?
• Analiza (analysis)
• Czego chce uzytkownik
• Specyfikacja (specification)
• Precyzyjne sformulowanie niezbednych cech systemu
• Projektowanie (design)
• Techniczne zaprojektowanie rozwiazania
• Implementacja (implementation)
• Budowa zaprojektowanego rozwiazania
• Testowanie (testing, verification validation)
• Czy system poprawnie robi to, co mial robic?
• Integracja (integration, deployment wdrozenie)
• Sytem musi funkcjonowac w docelowym srodowisku
• Pielegnacja (maintance tez utrzymanie,
  konserwacja)
• Modyfikowanie dzialajacego systemu w miare
  pojawiania sie nowych wymagan

6
Analiza zbieranie wymagan uzytkownika

• Wiekszosc uzytkowników nie wie dokladnie, czego
  chce!
• Poniewaz nie wie dokladnie, co aktualnie robi
• know how ? know that! (umiejetnosci vs.
  wiedza)
• Dlatego twórca oprogramowania (analityk) musi
  stac sie ekspertem w dziedzinie uzytkownika!
• Przyklad program do projektowania maszyn
• Fazy analizy
• Faza 1 Wywiad (Discovery) sluchanie i
  obserwacja
• Faza 2 Udoskonalanie (Refinement) pytanie i
  wyjasnianie
• Faza 3 Modelowanie (Modelling) propozycje i
  weryfikacje
• Wynik wystarczajace zrozumienie problemu, aby
  mozna bylo sformulowac dokument specyfikujacy
  wymagania

7
Specyfikacja ostatni etap analizy

• Precyzyjny zapis pozadanego zachowania systemu
• Formalna notacja
• Ustrukturyzowana dokumentacja
• Wynik specyfikacja wymagan, która precyzyjnie
  prezentuje pozadane cechy systemu projektantowi

8
Projekt

• Opracowanie rozwiazania, które odpowiada
  wymaganiom  
• Czerpie z poprzednich doswiadczen (i
  standardowych technik)  
• Wynikiem moze byc wiele mozliwych rozwiazan 
• Wtedy potrzebne jest kryterium wyboru pomiedzy
  nimi
• Wynik dokument, który precyzyjnie opisuje
  projekt systemu programistom

9
Implementacja

• Pisanie kodu  
• Dokumentowanie kodu 
• Debugowanie kodu
• Przygotowanie kodu do testów 
• Informacja zwrotna dla projektantów i
  analityków 
• Informacje dla testerów i integratorów
• Wynik dzialajacy kod i dokumentacja, gotowe do
  testowania

10
Testowanie i integracja

• Koniecznosc sprawdzenia, czy implementacja jest
  zgodna z projektem (czyli, ze dziala)
• A takze, czy jest zgodna z wymaganiami! (Czyli,
  ze dziala poprawnie)
• Testowane sa pojedyncze moduly, a takze caly
  system
• Nastepnie testy interakcji ze srodowiskiem, innym
  oprogramowaniem, danymi, itp.
• Wynik przetestowany kod, wdrozony do docelowego
  srodowiska, dzialajacy poprawnie

11
Pielegnacja

• Wymagania uzytkowników zmieniaja sie w czasie 
• Nawet najlepsze i najbardziej doglebne testy nie
  wykryja wszystkich bledów! 
• Zatem oprogramowanie równiez musi podlegac
  zmianom 
• Zmiany wymagan moga pociagnac dodatkowa prace w
  zakresie implementacji, testowania,
  projektowania, a nawet nowa analize

12
Modele cyklu rozwoju oprogramowania (Software
Development Life Cycle, SDLC)

• Waterfall wodospad
• Incremental inkrementacyjny
• Spiral spiralny
• Inne fountain, rapid prototyping, ...

13
Model Wodospadu

• Sekwencyjne przejscie przez kolejne etapy
• Zalety
• Prostota
• Dobry do malych projektów
• Wady
• Wszystkie!

14
Model inkrementacyjny

• Seria mniejszych cykli
• Kazda iteracja dodaje nowa funkcjonalnosc do
  systemu
• Zalety dzialajaca wersja wczesniej, latwiejsze
  zmiany, latwiejsza praca w mniejszych iteracjach
• Wady moga wystapic problemy z architektura
  systemu, poniewaz nie wszystkie wymagania sa
  definiowane z góry

15
Model spiralny

• Podobny do inkrementacyjnego
• Nacisk na analize ryzyka
• Cztery etapy
• Planowanie
• Analiza ryzyka
• Budowa
• Ewaluacja
• System cyklicznie przechodzi przez te etapy
• Zalety analiza ryzyka, dobry do duzych
  projektów, wczesnie dzialajacy system
• Wady moze byc kosztowny, sukces zalezy od
  analizy ryzyka, niedobry dla mniejszych projektów

16
Ale jednak ...

• Te modele to ostatecznie tylko teoria
• Uproszczony model tego, co dzieje sie w
  rzeczywistosci
• ... lub sugestia, co powinno sie dziac
• Nie ma srebrnej kuli modelu panaceum
• No Silver Bullet, Frederick P. Brooks, 1987
• Z samej natury oprogramowania wynika, ze nigdy
  nie bedzie cudownego wynalazku, który w
  informatyce dokona tego, co elektronika i
  tranzystory zrobily dla sprzetu

17
Wspomaganie procesu narzedzia CASE

• CASE Computer Aided Software Engineering
• Programy wspomagajace proces tworzenia
  oprogramowania
• (Prawie) Na kazdym etapie!

18
Technologie i praktyki

• Technologie
• Kompilatory, repozytoria kodu, edytory, ...
• Praktyki
• Programowanie w parach (pair programming)
• Recenzje kodu (code reviews)
• Codzienne spotkania
• Etc.