Termin „inżynieria oprogramowania” został użyty po raz pierwszy w 1967 roku. Wtedy to odbyła się pierwsza konferencja na ten temat zorganizowana przez NATO. Od tego czasu inżynieria oprogramowania przeszła znaczący rozwój (...)

Ogólnie można powiedzieć, że inżynieria oprogramowania zajmuje się inżynierskim podejściem do tworzenia oprogramowania. Inżynieria oprogramowania dąży do ujęcia działań związanych z budową programów komputerowych w ramy typowe dla innych dziedzin inżynierii. W szczególności inżynieria oprogramowania stosuje wiedzę naukową, techniczną oraz doświadczenie w celu projektowania, implementacji, walidacji i dokumentowania oprogramowania.

 

Inżynierię oprogramowania można podzielić na kilka zasadniczych dyscyplin. Dyscypliny te są związane z typowymi etapami działań inżynierskich w dowolnej dziedzinie inżynierii. Oczywiście, dyscypliny inżynierii oprogramowania mają istotne cechy wyróżniające je spośród dyscyplin sformułowanych ogólnie. Dla ustalenia uwagi spróbujemy porównać niektóre dyscypliny inżynierii oprogramowania z dyscyplinami inżynierii budowlanej.

 

Dyscyplina 1. Wymagania

 

Aby zbudować dom, przyszli jego właściciele lub mieszkańcy muszą określić swoje potrzeby. Te potrzeby należy sformułować tak, aby wykonawcy domu byli w stanie jak najlepiej je spełnić. Potrzeby mogą dotyczyć funkcjonalności domu (układ funkcjonalny, liczba pokoi itp.), jak i jego cech niefunkcjonalnych (estetyka, kolor itp.).

 

Podobnie w przypadku budowy systemu oprogramowania należy zebrać dokładne wymagania od jego przyszłych użytkowników. Zadanie to jest znacznie bardziej złożone od zebrania wymagań na dom lub nawet złożony budynek wielofunkcyjny. Systemy informatyczne realizują coraz bardziej złożoną funkcjonalność dla coraz większej liczby grup użytkowników. Stąd też bardzo istotne jest uzyskanie od tychże użytkowników (jak również od innych grup zainteresowanych systemem) wszystkich niezbędnych informacji dotyczących ich potrzeb. Należy też zwrócić uwagę na to, że potrzeby użytkowników systemów oprogramowania są bardzo zmienne, co zdecydowanie odróżnia te potrzeby od potrzeb właścicieli domów.

 

Dyscyplina 2. Projektowanie

 

Na podstawie wymagań zebranych od klientów architekt przystępuje do projektowania domu. Najpierw musi określić strukturę domu, w szczególności z jakich pomieszczeń będzie się składał dom, jakie będą przejścia między pomieszczeniami, ile będzie miał kondygnacji, jak będzie ukształtowany dach itd. Potem ekipa inżynierów konstruktorów projektuje detale konstrukcyjne: typy stropów, rodzaj belek konstrukcyjnych, rodzaj elewacji itd.

 

System oprogramowania też wymaga projektu. Jest to o tyle istotne, że liczba elementów, z jakich skonstruowany jest typowej wielkości system oprogramowania, znacznie przekracza liczbę elementów konstrukcyjnych budynku. Niezbędne jest określenie przez architektów, z jakich składników będzie zbudowany system i na jakich maszynach (komputerach, procesorach) będzie on wykonywany. Bardzo istotne jest też pokazanie wykonawcom, w jaki sposób system będzie realizował swoją funkcjonalność. Podobnie jak w przypadku projektowania budynków, konieczne jest użycie „rysunków technicznych”. Dla systemów oprogramowania istnieje standardowy język graficznego opisu systemu (...)

 

Dyscyplina 3. Implementacja

 

Plany architektoniczne i projekt konstrukcyjny budynku są podstawą do rozpoczęcia budowy. Zgodnie z projektem należy wytyczyć budynek, zbudować fundamenty, wznieść mury, pokryć dachem i wykonać prace instalacyjno-wykończeniowe.

 

Wykonanie (implementacja) systemu oprogramowania również wymaga zachowania zgodności z projektem. System oprogramowania jest konstruowany poprzez pisanie programów w odpowiednich językach programowania. W zachowaniu zgodności z projektem mogą pomóc odpowiednie metody przekształcania projektu w kod systemu. Dla dobrze zaprojektowanego systemu prace związane z implementacją (kodowaniem) sprowadzają się do uzupełnienia elementów kodu wygenerowanych na podstawie projektu szczegółowego (...)

 

Dyscyplina 4. Walidacja

 

W trakcie i po zakończeniu budowy budynku przeprowadzane są niezbędne sprawdzenia (kontrola jakości). Geodeci sprawdzają, czy budynek został postawiony w prawidłowym miejscu. Służby instalacyjne sprawdzają prawidłowość zainstalowania sieci i urządzeń instalacyjnych. Najważniejsze jednak, aby sami mieszkańcy sprawdzili, czy zostały zrealizowane ich wymagania. W razie wykrycia usterek należy dokonać niezbędnych poprawek. Przy tym należy uważać, aby usterki wykryć w odpowiednim czasie. Jeżeli na przykład stwierdzimy, że przecieka sieć hydrauliczna po wykonaniu wszystkich tynków i podłóg, znalezienie usterki stanie się bardzo kosztowne (trzeba rozkuwać ściany i podłogi). Jeszcze trudniejsze byłoby przesuwanie ścian, jeśli właściciel stwierdzi, że jego potrzeby dotyczące rozkładu pomieszczeń zostały niewłaściwie zrozumiane.

 

W przypadku systemów oprogramowania wykrycie usterek jest bardzo złożonym problemem. Wynika to przede wszystkim ze złożoności i zmienności wymagań oraz złożoności systemów. Przede wszystkim należy sprawdzić, czy system został zbudowany zgodnie z potrzebami klienta i użytkowników. Można zauważyć, że w zasadzie jedynym kryterium walidacji jest zgodność z tymi potrzebami. System dobrej jakości to system zgodny z nałożonymi na niego wymaganiami. W trakcie walidacji sprawdza się zatem, czy funkcjonalność systemu jest odpowiednia dla potrzeb klienta. Równocześnie sprawdza się inne elementy jakości, takie jak na przykład niezawodność (w tym odporność na awarie sprzętu) czy wydajność (szybkość działania). Należy podkreślić, że walidacja nie powinna być wykonywana dopiero po zakończeniu implementacji. Powinno się ją przeprowadzać jak najwcześniej w celu zmniejszenia ryzyka niepowodzenia. Podobnie jak w przykładzie z naprawą instalacji, często zdarzają się sytuacje, kiedy niewykryte usterki systemu są bardzo kosztowne w naprawie, jeśli zostały dostrzeżone zbyt późno.

 

Dyscyplina 5. Nadzór

 

Podczas projektowania i budowy domu obowiązują pewne procedury związane ze sposobem wykonywania czynności, przepisami administracyjnymi i bezpieczeństwem pracy. Odpowiedni inspektorzy i kierownicy budowy dostosowują te procedury do warunków na budowie oraz kontrolują ich przestrzeganie.

 

W trakcie budowy systemu oprogramowania też bardzo istotne jest przestrzeganie pewnych procedur i reguł postępowania. W tym celu zostały opracowane odpowiednie standardowe metodyki. Odejście od przestrzegania (lub po prostu brak) metodyk jest bardzo częstą przyczyną niepowodzeń projektów, w które wkrada się chaos organizacyjny. Czynności zawarte w metodykach dotyczą wszystkich etapów budowy systemu — od wymagań aż do walidacji i oddania systemu do użytku. Nad przestrzeganiem metodyki powinien czuwać odpowiedni kierownik (tzw. metodyk).

 

Dyscyplina 6. Środowisko pracy

 

Podczas projektowania i budowy domu bardzo istotne jest środowisko pracy. Współcześni architekci używają systemów CAD (ang. Computer Aided Design), które wyręczają ich w żmudnych pracach kreślarskich. Ekipy budowlane używają odpowiednich narzędzi, które również przyspieszają ich pracę.

 

Budując system oprogramowania, również powinniśmy bardzo uważnie podejść do budowy środowiska pracy. Bardzo istotny jest wybór narzędzi wspomagających projektowanie systemu. Podczas budowy systemu niezbędne jest posiadanie narzędzi umożliwiających zarządzanie złożonym kodem (dobre środowisko zintegrowane oraz narzędzia do zarządzania konfiguracją i zmianami). Dobrze dobrane środowisko pracy ułatwia również rozbudowę systemu (tzw. ewolucję systemu) (...)

 

Na koniec tego krótkiego przeglądu należy podkreślić, że — mimo istotnych analogii — budowa domu w istotny sposób różni się od budowy systemu oprogramowania. W pierwszym przypadku mamy dosyć dobrze opisane i ustalone wymagania, podczas gdy w przypadku oprogramowania wymagania są często nie do końca uświadomione oraz podlegają częstym zmianom. Konieczne jest zatem przeplatanie się czynności różnych dyscyplin oraz powtarzanie tych czynności w miarę rozwoju systemu. 

 

Fragment pochodzi z książki "Inżynieria oprogramowania w praktyce. Od wymagań do kodu z językiem UML" Michał Śmiałek, Kamil Rybiński, Helion 2023