Inżynieria oprogramowania jako działalność inżynierska

Inżynieria oprogramowania jest jedną z najważniejszych współcześnie dziedzin wiedzy inżynierskiej. Każda osoba we współczesnym świecie ma do czynienia z dziesiątkami systemów, w których oprogramowanie stanowi zasadniczy składnik. Aby wytworzyć system oprogramowania w sposób efektywny, musimy zastosować typowe zasady metod inżynierskich, dostosowanych do specyfiki oprogramowania. Zasady te muszą uwzględniać olbrzymią złożoność systemów oprogramowania. Niestety, złożoność rodzi wiele problemów i prowadzi do częstych niepowodzeń podczas projektów konstrukcji oprogramowania. Świadczą o tym typowe objawy „chronicznej choroby”, jaka od lat trapi inżynierię oprogramowania. Pokonując zasadnicze przyczyny niepowodzeń należy zastosować najlepsze praktyki inżynierii oprogramowania, które są przedstawione w poszczególnych rozdziałach niniejszego podręcznika.

Dyscypliny inżynierii oprogramowania

Dyscypliny inżynierii oprogramowania związane są z typowymi etapami działań inżynierskich w dowolnej dziedzinie inżynierii, przy czym posiadają one istotne cechy wyróżniające je spośród dyscyplin sformułowanych ogólnie. Najczęściej w inżynierii oprogramowania wyróżniamy takie dyscypliny jak: wymagania, projektowanie, implementacja, walidacja, nadzór i środowisko pracy. W różnych metodykach może występować nieco inny podział na dyscypliny.

Kryteria powodzenia projektu

Z punktu widzenia uczestników projektu budowy oprogramowania można wyróżnić trzy kryteria warunkujące powodzenie. Można uznać, że projekt skończył się sukcesem, jeżeli a) projekt mieści się w budżecie, b) projekt mieści się w ramach czasowych, oraz c) dostarczony system spełnia rzeczywiste potrzeby klienta.

Problemy inżynierii oprogramowania

Inżynierię oprogramowania trapi „przewlekła choroba”, która ma szereg objawów. Najczęściej spotykane objawy to: niezadowoleni klienci, niezadowoleni dostawcy, kłótnie o zakres systemu, chaotyczne zarządzanie zmieniającymi się wymaganiami, programiści pracujący w trybie 24/7, stres pod koniec projektu, brak stabilności rezultatów między projektami oraz syndrom „prawie gotowego” systemu. Przyczynami tych problemów są najczęściej: nieprecyzyjne specyfikowanie, zła komunikacja, brak projektowania architektonicznego, brak zarządzania złożonością systemu, bardzo późne odkrywanie poważnych nieporozumień, brak zarządzania zmianami, nieużywanie narzędzi wspomagających.

Najlepsze praktyki inżynierii oprogramowania

Odpowiedzią na problemy inżynierii oprogramowania jest stosowanie najlepszych praktyk, które są rezultatem doświadczeń z wielu projektów. Podstawowy zestaw takich praktyk obejmuje: produkcję iteracyjną, stosowanie architektur komponentowych, stałą kontrolę jakości, systematyczne zarządzanie wymaganiami, zarzadzanie zmianami oraz modelowanie wizualne. Wyrazem najlepszych praktyk w podejściu zwinnym (agile) jest manifest zwinnego wytwarzania oprogramowania, który promuje nastawienie na czynnik ludzki, współpracę z klientem oraz ciągłe dostarczanie działającego oprogramowania. Najlepsze praktyki stanowią zasadniczy element współczesnych metodyk wytwarzania oprogramowania.

Produkty cyklu wytwarzania oprogramowania

Niezależnie od wybranego cyklu życia, każdy projekt wytwarzania oprogramowania obejmuje kilka dyscyplin. Każda z dyscyplin dostarcza różne produkty, które są efektem czynności wykonywanych w jej ramach. Głównym produktem dyscypliny wymagań jest specyfikacja wymagań. W ramach dyscypliny projektowania powstają m.in. architektura fizyczna i architektura logiczna. Efektem dyscypliny implementacji jest przetestowany (jednostkowo i integracyjnie) kod systemu, a w ramach dyscypliny testowania przeprowadzane są testy akceptacyjne. Ostatecznym produktem wdrożenia systemu jest zainstalowany system w środowisku produkcyjnym.

Cykle wytwarzania oprogramowania

Aby zapanować nad złożonością procesu wytwórczego, czynności w ramach projektu porządkowane są w ramach cyklu wytwórczego. W przypadku niewielkich systemów, gdzie wszystkie wymagania są znane i dobrze udokumentowane, może sprawdzić się cykl wodospadowy. W przypadku bardziej rozbudowanych systemów, gdzie nie wszystkie wymagania są rozpoznane, powinien być wykorzystany cykl iteracyjny.

Co to są metodyki wytwarzania oprogramowania?

Zespoły projektowe potrzebują konkretnych wytycznych, które odpowiadają na podstawowe pytanie „jak należy to zrobić?”. Zespół powinien widzieć co należy wykonać, w jaki sposób oraz kto powinien za co odpowiadać. Opis metodyki zazwyczaj zawiera zatem pięć elementów: opis ról, opis czynności, opis produktów pracy, podział na dyscypliny oraz określenie cyklu życia (zazwyczaj ograniczonego do cyklu wytwórczego). Ważnym elementem definicji produktów pracy jest notacja używana do ich wytworzenia. Przyjęcie jednolitej notacji jest bardzo istotnym elementem zapewnienia jakości wykonywanych produktów. Wśród wielu istniejących i stosowanych metodyk, można wyróżnić dwie główne grupy: metodyki formalne i agilne (zwinne).

Metodyki zwinne

Podstawowe cechy metodyk zwinnych to iteracyjność oraz koncentracja na technikach organizacji zespołu i współpracy z klientem. Bardzo istotna zasadą metodyk zwinnych jest częste dostarczanie działającego oprogramowania. Odbywa się to w stosunkowo krótkich cyklach (iteracjach). Na pierwszy plan wysuwa się zasada zapewnienia maksymalnej satysfakcji klienta. Z najważniejszych metodyk zwinnych warto wymienić Scrum, Extreme Programming, Crystal, Lean Development i Kanban. Często stosowana metodyka Scrum zakłada codzienną kontrolę postępu prac w ramach iteracji (tzw. sprintu) trwającego kilka tygodni (najczęściej 2-3). Każdy sprint funkcjonuje w oparciu o tzw. rejestr sprintu, a jego efektem jest przyrost produktu, który może być w określonym zakresie używany przez klienta. Kolejne sprinty planowane są w ramach tzw. rejestru produktu.

Metodyki sformalizowane

W projektach zamawianych przez instytucje stosujące formalne zasady zamawiania oprogramowania często konieczne jest zastosowanie metodyki sformalizowanej. Metodyka sformalizowana precyzyjnie definiuje role, czynności i produkty pracy. Współczesne metodyki sformalizowane stosują cykl iteracyjny i mogą być zastosowane do projektów o różnej skali. Popularnymi metodykami sformalizowanymi są metodyki z rodziny tzw. procesów zunifikowanych. Rational Unified Process jest metodyką bardzo obszerną i możliwą do zastosowania w bardzo szerokim zakresie dziedzin oraz rozmiarów projektów. Ta uniwersalność metodyki czyni ją jednocześnie trudną do wdrożenia w konkretnym projekcie. Wymagane są stosunkowo pracochłonne czynności związane z adaptacją metodyki do konkretnego środowiska projektowego. Dlatego też opracowano uproszczoną jej wersję – OpenUP, zbliżoną zasadami do metodyk zwinnych.


Ostatnia modyfikacja: piątek, 21 czerwca 2024, 14:34