Inżynieria oprogramowania

Z Encyklopedia Zarządzania
Wersja z dnia 00:49, 14 lis 2023 autorstwa Zybex (dyskusja | edycje) (cleanup bibliografii i rotten links)
Inżynieria oprogramowania
Polecane artykuły

Inżynieria oprogramowania jest to wiedza techniczna obejmująca wszystkie fazy życia oprogramowania - projektowania, implementacji oraz konserwacji, której zastosowanie prowadzi do stworzenia gotowego produktu, czyli oprogramowania wysokiej jakości. Oprogramowanie traktowane jako produkt ocenia się według kryteriów zbliżonych do tych stosowanych dla innych wyrobów, a więc cechować się ono powinno:

  • niezawodnością,
  • zgodnością z wymaganiami użytkownika,
  • efektywne,
  • ergonomiczne,
  • łatwe w konserwacji.

"Od początku istnienia, w ramach inżynierii oprogramowania występowały dwa nurty:

  • nurt formalny, który postuluje jak najszersze stosowanie metod formalnych: formalnych języków specyfikacji, formalnych transformacji, formalnych dowodów poprawności,
  • nurt praktyczny, który opiera się na stosowaniu notacji nie w pełni sformalizowanych, w dużej mierze graficznych, oraz proponuje metody, w których dużą rolę odgrywa wiedza i doświadczenie ludzkie". (Jaszkiewicz A., 1997, s. 11)

TL;DR

Artykuł omawia inżynierię oprogramowania, modele cyklu życia oprogramowania oraz metodyki wspomagające proces definiowania zadań. Wyróżnione modele cyklu życia to: kaskadowy, prototypowanie, realizacja przyrostowa, montaż z gotowych elementów i spiralny. Metodyki wspomagające to m.in. OpenUP i CDM Fast Track.

Modele cyklu życia oprogramowania

Produkcja oprogramowania jest procesem, który dla zapewnienia dobrego rozplanowania oraz możliwości monitorowania działań, realizowany jest w pewien systematyczny sposób. Modele cyklów określają kolejne fazy, w których wykonywane są określone czynności, a także precyzują kolejność ich wykonywania.

Model kaskadowy

Model ten jest analogiczny do modelu prowadzenia przedsięwzięć w innych gałęziach inżynierii, posiada fazy:

  • określenia wymagań - zleceniodawca określa cele, cechy szczególne oraz wymagania wobec systemu,
  • projektowania - faza, w której zostaje stworzony projekt systemu odpowiedni do ustalonych wcześniej wymagań,
  • implementacji - faza, w której poszczególne składowe systemu są implementowane w środowisku programistycznym i testowane,
  • testowania - integracja wszystkich modułów systemu oraz testowanie całego systemu,
  • konserwacji - system jest używany przez zleceniodawcę, natomiast producent dokonuje modyfikacji oprogramowania, na które może składać się rozszerzanie funkcjonalności, usuwanie błędów.

Model ten jest procesem liniowym, przedstawia cykl życia oprogramowania jako kolejne fazy następujące po sobie. Dodatkowo można wyróżnić fazy nie dotyczące bezpośrednio procesu tworzenia oprogramowania, takie jak:

  • faza strategiczna występująca przed podjęciem formalnych decyzji, w której podejmowane są decyzje rzutujące na dalsze etapy pracy,
  • faza analizy - tworzenie modelu systemu
  • faza dokumentacji, w której opracowywana jest dokumentacja techniczna oprogramowania, najczęściej przebiega ona równolegle z pracami nad systemem,
  • faza instalacji - instalacja gotowego systemu użytkownikowi.

Prototypowanie

Model prototypowania cechuje się minimalnym ryzykiem spowodowanym złym określeniem wymagań przez zleceniodawcę.

  • "ogólne określenie wymagań,
  • budowa prototypu,
  • weryfikacja prototypu przez klienta,
  • pełne określenie wymagań,
  • realizacja pełnego systemu zgodnie z modelem kaskadowym.

Głównym celem realizacji prototypu jest lepsze określenie wymagań, czyli:

  • wykrycie nieporozumień pomiędzy klientem a twórcami systemu,
  • wykrycie brakujących funkcji,
  • wykrycie braków w specyfikacji wymagań".

Realizacja przyrostowa

Początkowe fazy dotyczące wymagań wyglądają tak samo jak w modelu kaskadowym, następnie następuje faza projektowania wstępnego, czyli ogólnego szkieletu całego systemu. Kolejnym krokiem jest proces iteracyjny składający się z:

  • fazy wyboru modułu systemu realizującego podzbiór funkcji,
  • fazy projektowania, implementacji oraz testów, tak jak w modelu kaskadowym,
  • fazy dostarczenia oraz instalacji modułu w systemie.

Postępowanie takie pozwala na częstsze kontakty z klientem, daje możliwość wykorzystania przez niego częściowej funkcjonalności, bez zakończenia całego procesu produkcji. Wiąże się również z koniecznością pracy nad wyodrębnionymi modułami systemu, które zwykle zależne są od reszty systemu. Implementacja takich modułów bez możliwości przetestowania ich współpracy może uniemożliwić wykrycie błędów.

Montaż z gotowych elementów

Model ten charakteryzuje się wykorzystywaniem podobieństw między tworzonymi i gotowymi, wykonanymi wcześniej systemami. Takie podejście pozwala na redukcję nakładów poprzez używanie gotowych elementów na różnych etapach produkcji, na przykład wykorzystywanie gotowych bibliotek, pełnych programów wykonujących pożądane funkcje w systemie. Zalety takiego rozwiązania to:

  • "Wysoka niezawodność. Gotowe elementy są z reguły dobrze przetestowane, ich niezawodność jest więc większa niż nowo tworzonych elementów.
  • Zmniejszenie ryzyka.
  • Efektywne wykorzystanie specjalistów.
  • Narzucenie standardów. Gotowe elementy stworzone z zachowaniem pewnych standardów narzucają zachowanie tych standardów w kolejnych przedsięwzięciach.
  • Potencjalna redukcja kosztów. Koszt gotowego elementu jest z reguły znacznie mniejszy niż koszt jego pierwotnego opracowania. Pewne czynniki, które mogą jednak wpływać na wzrost kosztów wymienione są poniżej".

Natomiast wady modelu to:

  • "Dodatkowy koszt przygotowanie elementów do ponownego wykorzystania. Fragmenty systemu muszą być z reguły w pewien sposób przystosowane do tego celu. Jest to pewien dodatkowy nakład, który należy ponieść w trakcie realizacji przedsięwzięcia bez gwarancji, że zwróci się on w przyszłości.
  • Ryzyko uzależnienia się od dostawcy elementów. Dostawca może zaniechać prac nad biblioteką, nie dostosować jej do nowych wersji sprzętu i oprogramowania systemowego.
  • Niedostatki narzędzi wspomagających ten rodzaj pracy".

Model spiralny

Najbardziej ogólny model cyklu życia oprogramowania, zaproponowany przez Boehma (1988).Składa się z czterech faz realizowanych w kolejnych fazach: analiza ryzyka, konstrukcja (model kaskadowy), atestowanie, planowanie. Analiza ryzyka - ogólne rozważania budowy nowej wersji systemu, budowa prototypów Konstrukcja- (model kaskadowy) konstrukcja kolejnej wersji systemu Atestowanie - w tej fazie oceniana jest oceniana kolejna wersja systemu przez klienta, w przypadku kiedy ocena nie jest pozytywna, rozpoczynany jest kolejny cykl Planowanie - ustalenie celów produkcji kolejnych systemów (Jaszkiewicz A. (1997) s. 15-27)

Formalne transformacje

Model formalnych transformacji opiera się na wymaganiach sprecyzowanych w pewnym formalnym języku, następnie są one automatycznie transformowane do innej postaci formalnej - pośredniej, bądź bezpośrednio do postaci kodu programu. Należy dodać, że wszystkie transformacje wykonywane są automatycznie, bez udziału ludzi (Jaszkiewicz A. (1997) s. 27) W ramach formalnych transformacji wprowadzony został język UML (ang. Unified Modeling Language), który jest powszechnie stosowany w przemyśle oraz w świecie naukowym. Głównymi zaletami tej technologii jest jej przejrzystość, intuicyjność oraz szerokość możliwych zastosowań. (Grobelny M., Grobelna I. (2010) s. 1154)

Wspomaganie procesu definiowania zadań

Wzrost wytwarzanego oprogramowania komputerowego zmusił firmy informatyczne do zastosowania wytwórczych procesów oprogramowania (ang. SDP, software development process).Przyczyniło się to do: zredukowania problemu przekraczania budżetu, łatwiejszego zarządzania inwestycjami, pozwoliło na dotrzymanie terminów. Szkielet SDP, który posiada określoną strukturę, plan oraz kontroluje wykonanie zadań jest tzw. metodyką wytwarzania oprogramowania (SDM). Zespoły informatyczne czy też projekty mogą wymagać zastosowania innej SDM. Opracowano metodyki, które można użyć na potrzeby każdego projektu. Wyróżnić można metodyki: Rational Unified Process, Agile, Scrum, Extreme Programming. Ze względu na oczekiwania twórców systemów informatycznych została opracowana metodyka Open Unified Process (OpenUP), zawierająca praktyki pochodzące z RUP, jak i z Agile.

Metodyka OpenUP

OpenUP opiera się na czterech głównych zasadach:

  1. Współpracy, która ma celu ulepszenia działania
  2. równoważenie sprzeczności, której celem jest maksymalizacja korzyści dla odbiorcy
  3. najszybszej koncentracji na konstrukcji systemu, aby zminimalizować ryzyko oraz organizację fazy wytwarzania
  4. rozwijanie systemu, na podstawie opinii odbiorcy systemu

OpenUP zorganizowana jest w dwóch obszarach: zawartości metody oraz procesu. Zawartość metody (role, zadania, artefakty oraz porady), zawartość procesu składają się szablony, w których zastosowane są poszczególne elementy metodyki. Metodyka OpenUP opisuje trzy poziomy organizacji pracy: poziom osobisty, poziom zespołu oraz poziom odbiorcy systemu. Poziom osobisty - do członka należy wykonanie mikro przyrostów, reprezentujących wyniki jakie zostały osiągnięte w wyniku kilkugodzinnej czy też kilkudniowej pracy Poziom zespołu - zajmuje się kolejnymi interakcjami jakie zostały zaplanowane, w ramach których odbiorca otrzymuje kolejne elementy. Poziom Odbiorcy systemu - jest podzielony na cztery fazy: (rozpoczęcie, opracowanie, wytworzenie, przekazanie). Taki proces wytwórczy pozwala na to aby odbiorca systemu mógł prowadzić nadzór nad finansami, zakresem oraz ryzykiem projektu.(Gratkowski T. 2010, s. 105-107)

Metodyka CDM Fast Track

Metodyka CDM Fast Track dopuszcza możliwość zmian wymagań wobec systemu w trakcie trwania projektu. Cechą charakterystyczną tego podejścia jest możliwość iteracyjnego powtarzania faz jak w modelu przyrostowym oraz spiralnym. "W metodyce CDM Fast Track stosuje się następujące techniki:

  • określanie ram czasowych (ang. timeboxes) i priorytetów,
  • spotkania z użytkownikami (ang. workshops),
  • tworzenie prototypów,
  • iteracyjne dopracowywanie modułów systemu,
  • dostarczanie częściowych rozwiązań,
  • podział prac,
  • udział w pracach projektowych użytkowników mogących samodzielnie podejmować ważne decyzje w dziedzinie tworzonego systemu (Mincer-Daszkiewicz J. (2002) s. 3)

Bibliografia


Autor: Karolina Stawowy


Źródło: „https://mfiles.pl/pl/index.php?title=Inżynieria_oprogramowania&oldid=178676”