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

Bartosz Baliś, 2006 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 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 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 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 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 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 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 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 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 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 Modele cyklu rozwoju oprogramowania (Software Development Life Cycle, SDLC) Waterfall – wodospad Incremental – inkrementacyjny Spiral – spiralny Inne – fountain, rapid prototyping,...

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

Bartosz Baliś, 2006 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 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 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 Wspomaganie procesu – narzędzia CASE CASE – Computer Aided Software Engineering Programy wspomagające proces tworzenia oprogramowania  (Prawie) Na każdym etapie!

Bartosz Baliś, 2006 Technologie i praktyki Technologie  Kompilatory, repozytoria kodu, edytory,... Praktyki  Programowanie w parach (pair programming)  Recenzje kodu (code reviews)  Codzienne spotkania  Etc.