Inżynieria oprogramowania – część I. Kilka słów o metodykach

W związku z zapotrzebowaniem na artykuły z pogranicza technicznego, ale nie niosące zbyt dużego ciężaru gatunku, dziś rozpoczynamy kolejną serię tekstów. Będzie ona mówić o wytwarzaniu oprogramowania z punktu widzenia różnych metodyk. Dzisiaj przedstawimy podstawowe pojęcia, zaprezentujemy podział metodyk oraz omówimy pierwszą z nich. Czym jest inżynieria oprogramowania? Inżynieria oprogramowania jest nauką traktującą o wytwarzaniu […]

W związku z zapotrzebowaniem na artykuły z pogranicza technicznego, ale nie niosące zbyt dużego ciężaru gatunku, dziś rozpoczynamy kolejną serię tekstów. Będzie ona mówić o wytwarzaniu oprogramowania z punktu widzenia różnych metodyk. Dzisiaj przedstawimy podstawowe pojęcia, zaprezentujemy podział metodyk oraz omówimy pierwszą z nich.

Czym jest inżynieria oprogramowania?

Inżynieria oprogramowania jest nauką traktującą o wytwarzaniu oprogramowania w sposób systematyczny. IEEE 610.12-1990 definiuje inżynierię oprogramowania, jako „Zastosowanie systematycznego, uporządkowanego, wymiernego podejścia do wytwarzania, eksploatacji i konserwacji oprogramowania”1.

Sam termin „inżynieria oprogramowania” został użyty na dwóch konferencjach NATO Software Engineering Conferences, które odbyły się w 1968 i 1969 r. Dzięki tym konferencjom termin ten zyskał aprobatę środowiska developerskiego. Celem samych konferencji było zebranie najlepszych praktyk wytwarzania oprogramowania.

Metodologia, metodyka, metoda?

Zdarza się, że terminów tych używa się zamiennie, jednak z punktu widzenia ich znaczenia nie powinno do tego dochodzić. Krótko wyjaśnijmy więc sobie poszczególne z nich:

  • Metodologia wytwarzania oprogramowania – nauka o zasadach, dobrych praktykach itd.;
  • Metodyka wytwarzania oprogramowania – zbiór reguł wytwarzania oprogramowania;
  • Metoda wytwarzania oprogramowania – stosowany sposób wytwarzania oprogramowania.

Bardzo dobry artykuł tłumaczący ten podział znajdziemy na stronie testerzy.pl.

Podział metodyk

Najbardziej znanym podziałem metodyk jest podział na metodyki tradycyjne i zwinne. Jak nietrudno się domyślić, przed powstaniem metodyk zwinnych powstały metodyki tradycyjne. Postaram się teraz pokrótce je opisać.

Metodyki tradycyjne cechują się liniowością postępowania. Idealnym przykładem będzie omówiony w dalszej części tekstu model kaskadowy (waterfall model). Typową ich cechą jest trudność z adaptacją do zmian.

Metodyki zwinne cechują się większą gotowością na zmiany. Wynika to z faktu, iż są iteracyjne – postępowanie wciąż jest w gruncie rzeczy liniowe, jednak jest zapętlone, a same etapy są znacznie krótsze. Idealnym przykładem jest tutaj metodyka SCRUM – model przyrostowy, czyli w każdej iteracji wartość naszego produktu (ilość wykonanych funkcjonalności) się zwiększa. Zatem w każdej jesteśmy gotowi do korekty kursu naszego projektu. Może się zdarzyć także, że w trakcie trwania iteracji (tzw. sprintu) zmienimy jego zakres (scope). Nie jest to jednak zalecane.

Pierwsza metodyka – nieśmiertelny model kaskadowy

Model kaskadowy często nazywany jest po prostu łoterfolem (z angielskiego waterfall model). Należy on do metodyk tradycyjnych i składa się z sześciu etapów. Etapy te w dużej mierze pokrywają się z cyklem życia projektu i przedstawiają się następująco.

1. Planowanie – kończy się wymaganiami produktowymi.
2. Analiza wymagań – kończy się gotowymi modelami, schematami i zasadami biznesowymi.
3. Projektowanie – ten etap generuje architekturę naszego oprogramowania.
4. Implementacja – stworzenie i integracja naszego oprogramowania.
5. Testowanie – wyszukiwanie i naprawianie defektów.
6. Wdrożenie i utrzymanie.

Istotną cechą tego modelu jest fakt, iż żeby przejść do następnego etapu musimy zakończyć obecny.

Wyobraźmy sobie teraz następującą sytuację. Podczas implementacji naszego oprogramowania okazuję się, że wymóg produktowy jest niepełny. Model kaskadowy bardzo słabo radzi sobie z tego typu problemami. Musimy cofnąć się aż o 3 fazy. Często poprzednie fazy są realizowane przez inne zespoły, które mogą być już zajęte innym projektem.

Ten prosty przykład pokazuje, dlaczego model kaskadowy nie jest zwinnym procesem. Zmiany w późniejszych fazach są bowiem utrudnione.

Zalety modelu kaskadowego:

  • Proces, jak i wyjście procesu (oprogramowanie) jest dobrze zdefiniowany. Każdy krok musi się zakończyć, zanim przejdziemy do następnego etapu;
  • Proste śledzenie postępu;
  • Implementacja systemu, który jest w pełni zaprojektowany;
  • W procesie wymagana jest kompletna dokumentacja.

Wady modelu kaskadowego:

  • Model kaskadowy działa dobrze tylko wtedy, gdy pierwsze dwa etapy (planowanie i analiza wymagań) są poprawie przeprowadzone. Jest to jednak często niemożliwe, szczególnie wtedy, gdy klient precyzyjnie nie wie, czego tak naprawdę oczekuje;
  • Model kaskadowy nie jest przystosowany do zmiany wymagań na późniejszych etapach;
  • Proces jest ociężały i potrafi generować zbyt dużo dokumentacji;
  • Nie generuje gotowych do dostarczenia półproduktów;
  • W przeciwieństwie do modelów zwinnych nacisk postawiony jest na raz zebrane wymagania zamiast na nieustanną współpracę z klientem.

Zakończenie

Mam nadzieję, że powyższy tekst się może stanowić interesujące wprowadzenie do cyklu i się Państwu spodobał. Wszelkie komentarze i uwagi są mile widziane :)
W następnej części omówimy inne najbardziej znane metodyki tradycyjne, by w trzeciej i czwartej skupić się na najpopularniejszych metodykach zwinnych.

1 oryginał w języku angielskim – „The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software”.

Autorzy

Artykuły na blogu są pisane przez osoby z zespołu EuroLinux. 80% treści zawdzięczamy naszym developerom, pozostałą część przygotowuje dział sprzedaży lub marketingu. Dokładamy starań, żeby treści były jak najlepsze merytorycznie i językowo, ale nie jesteśmy nieomylni. Jeśli zauważysz coś wartego poprawienia lub wyjaśnienia, będziemy wdzięczni za wiadomość.