Wstęp do Inżynierii Oprogramowania

1. Wstęp do Inżynierii Oprogramowania Bartosz Baliś Bartosz Baliś, 2006

2. Definicja • Inżynieria – projektowanie, budowa i obsługa konstrukcji, maszyn, procesów i systemów w przemyśle i codziennym życiu • Inżynieria oprogramowania – projektowanie, rozwój, dokumentowanie, wdrażanie i pielęgnacja oprogramowania • Cel: jak w każdej inżynierii – optymalizacja kosztów i niezawodność produktu Bartosz Baliś, 2006

3. Powstanie inżynierii oprogramowania • Lata 60 – kryzys oprogramowania • Coraz większe i bardziej złożone systemy • Bo coraz większa moc obliczeniowa komputerów! • Jeden na 4 projekty kończył się porażką • Tworzenie dużych systemów trwało 3-5 lat • Często stawały się przestarzałe, zanim zostały ukończone! • Powstawały systemy niskiej jakości nie odpowiadające wymaganiom • Pielęgnacja oprogramowania stała się niezwykle trudna i kosztowna • Rozwiązanie – opracować metodologię (proces) rozwoju oprogramowania Bartosz Baliś, 2006

4. Jak walczyć ze złożonością?* • Abstrakcja • Ukrywanie szczegółów • Wyodrębnianie wspólnych własności • Wprowadzanie nowych pojęć do oznaczania tych własności • Dekompozycja • Podział problemu/przedmiotu na mniejsze, które mogą być traktowane osobno • Wielokrotne użycie • Ponowne użycie już utworzonych komponentów • Zgodność z ludzkim sposobem myślenia • Używanie pojęć, notacji, języka, narzędzi, itd., odpowiadających ludzkiej psychice, sposobie postrzegania, itd. Bartosz Baliś, 2006

5. Proces inżynierii oprogramowania • Studium wykonalności (feasibility study) • Czy to w ogóle się opłaca? Czy za tyle to zrobimy? • Analiza (analysis) • Czego chce użytkownik • Specyfikacja (specification) • Precyzyjne sformułowanie niezbędnych cech systemu • Projektowanie (design) • Techniczne zaprojektowanie rozwiązania • Implementacja (implementation) • Budowa zaprojektowanego rozwiązania • Testowanie (testing, verification & validation) • Czy system poprawnie robi to, co miał robić? • Integracja (integration, deployment – wdrożenie) • Sytem musi funkcjonować w docelowym środowisku • Pielęgnacja (maintance; też „utrzymanie”, „konserwacja”) • Modyfikowanie działającego systemu w miarę pojawiania się nowych wymagań Bartosz Baliś, 2006

6. Analiza – zbieranie wymagań użytkownika • Większość użytkowników nie wie dokładnie, czego chce! • Ponieważ nie wie dokładnie, co aktualnie robi • know „how”  know „that”! (umiejętności vs. wiedza) • Dlatego twórca oprogramowania (analityk) musi stać się ekspertem w dziedzinie użytkownika! • Przykład: program do projektowania maszyn • Fazy analizy • Faza 1: Wywiad (Discovery) – słuchanie i obserwacja • Faza 2: Udoskonalanie (Refinement) – pytanie i wyjaśnianie • Faza 3: Modelowanie (Modelling) – propozycje i weryfikacje • Wynik: wystarczające zrozumienie problemu, aby można było sformułować dokument specyfikujący wymagania Bartosz Baliś, 2006

7. Specyfikacja – ostatni etap analizy • Precyzyjny zapis pożądanego zachowania systemu • Formalna notacja • Ustrukturyzowana dokumentacja • Wynik: specyfikacja wymagań, która precyzyjnie prezentuje pożądane cechy systemu projektantowi Bartosz Baliś, 2006

8. Projekt • Opracowanie rozwiązania, które odpowiada wymaganiom   • Czerpie z poprzednich doświadczeń (i standardowych technik)   • Wynikiem może być wiele możliwych rozwiązań  • Wtedy potrzebne jest kryterium wyboru pomiędzy nimi • Wynik: dokument, który precyzyjnie opisuje projekt systemu programistom Bartosz Baliś, 2006

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: działający kod i dokumentacja, gotowe do testowania Bartosz Baliś, 2006

10. Testowanie i integracja • Konieczność sprawdzenia, czy implementacja jest zgodna z projektem (czyli, że działa) • A także, czy jest zgodna z wymaganiami! (Czyli, że działa poprawnie) • Testowane są pojedyncze moduły, a także cały system • Następnie testy interakcji ze środowiskiem, innym oprogramowaniem, danymi, itp. • Wynik: przetestowany kod, wdrożony do docelowego środowiska, działający poprawnie Bartosz Baliś, 2006

11. Pielęgnacja • Wymagania użytkowników zmieniają się w czasie  • Nawet najlepsze i najbardziej dogłębne testy nie wykryją wszystkich błędów!  • Zatem oprogramowanie również musi podlegać zmianom  • Zmiany wymagań mogą pociągnąć dodatkową pracę w zakresie implementacji, testowania, projektowania, a nawet nową analizę Bartosz Baliś, 2006

12. Modele cyklu rozwoju oprogramowania (Software Development Life Cycle, SDLC) • Waterfall – wodospad • Incremental – inkrementacyjny • Spiral – spiralny • Inne – fountain, rapid prototyping, ... Bartosz Baliś, 2006

13. Model Wodospadu • Sekwencyjne przejście przez kolejne etapy • Zalety • Prostota • Dobry do małych projektów • Wady • Wszystkie! Bartosz Baliś, 2006

14. Model inkrementacyjny • Seria mniejszych cykli • Każda iteracja dodaje nową funkcjonalność do systemu • Zalety: działająca wersja wcześniej, łatwiejsze zmiany, łatwiejsza praca w mniejszych iteracjach • Wady: mogą wystąpić problemy z architekturą systemu, ponieważ nie wszystkie wymagania są definiowane z góry Bartosz Baliś, 2006

15. Model spiralny • Podobny do inkrementacyjnego • Nacisk na analizę ryzyka • Cztery etapy: • Planowanie • Analiza ryzyka • Budowa • Ewaluacja • System cyklicznie przechodzi przez te etapy • Zalety: analiza ryzyka, dobry do dużych projektów, wcześnie działający system • Wady: może być kosztowny, sukces zależy od analizy ryzyka, niedobry dla mniejszych projektów Bartosz Baliś, 2006

16. Ale jednak ... • Te modele to ostatecznie tylko teoria • Uproszczony model tego, co dzieje się w rzeczywistości • ... lub sugestia, co powinno się dziać • Nie ma „srebrnej kuli” – modelu panaceum • No Silver Bullet, Frederick P. Brooks, 1987 • Z samej natury oprogramowania wynika, że nigdy nie będzie cudownego wynalazku, który w informatyce dokona tego, co elektronika i tranzystory zrobiły dla sprzętu Bartosz Baliś, 2006

17. Wspomaganie procesu – narzędzia CASE • CASE – Computer Aided Software Engineering • Programy wspomagające proces tworzenia oprogramowania • (Prawie) Na każdym etapie! Bartosz Baliś, 2006