1. wprowadzenie 5



Pobieranie 0.8 Mb.
Strona1/11
Data07.05.2016
Rozmiar0.8 Mb.
  1   2   3   4   5   6   7   8   9   10   11

1. WPROWADZENIE 5

1.1 Jakość oprogramowania 6





2. MODELE CYKLU ŻYCIA OPROGRAMOWANIA 9

  1. Model wodospadowy 9

  2. Model ewolucyjny 11

  3. Prototypowanie 12

  4. Formalne transformacje 13

  5. Montaż z gotowych elementów 13

  6. Realizacja przyrostowa 14

  7. Model spiralny 15

  8. Podsumowanie 16

3. FAZA STRATEGICZNA 18

  1. Decyzj e strategiczne 18

  2. Harmonogramowanie 19

4. SPECYFIKACJA OPROGRAMOWANIA 21

4.1 Proces formułowania wymagań 21



  1. Formularz zapisu wymagań funkcjonalnych 23

  2. Hierarchia wymagań funkcjonalnych 24

  3. Diagramy przypadków użycia 24

  4. Formalne specyfikacje 24




  1. Specyfikacje algebraiczne 24

  2. Specyfikacje bazujące na modelu 27

4.2 Walidacja wymagań i prototypowanie 29

5. PROJEKTOWANIE OPROGRAMOWANIA |30



  1. Jakość projektu 32

  2. Analiza i projektowanie obiektowe 35




  1. Historia standaryzacji 39

  2. Przegląd ogólny UML 40

  3. projektowanie z wykorzystaniem notacji UML 40

  4. Diagramy przypadków użycia 41

  5. Diagramy klas 45

  6. Diagramy sekwencji 56

  7. Diagramy współdziałania 61

  8. Diagramy zmian stanów 65

67 70 71 76 79 80 90 90 92 96 99

5 2 8 1 Strukturalizacja diagramów zmian stanów
5 2 8 2 Historia w diagramach zmian stanów
5 2 9 Diagramy czynności
5 2 10 Model implementacyjny
5 2 11 Diagram wdrożeniowy
5 2 12 Wzorce projektowe
5 3 Analiza i projektowanie strukturalne
5 3 1 Diagram przepływu danych
5 3 2 Narzędzia specyfikacji procesu
5 3 3 Diagram związków encji ^

  1. Diagram przejść stanów ^

  2. Diagram struktury 100

102
6. TESTOWANIE 102

105 107 109

6.1 Testowanie defektów 104
611 Testowanie funkcjonalne W^

  1. Testowanie strukturalne

  2. Testowanie interfejsów


112 113

  1. Testowanie stresowe

  2. Testowanie porównawcze



  1. Testowanie integracyjne

  2. Testowanie wątków F^^^

7. NIEZAWODNOŚĆ OPROGRAMOWANIA 114

  1. Testowanie statystyczne

  2. Modelowanie niezawodności

  3. Techniki programowania dla systemów o dużej niezawodności 117

8. ESTYMACJA KOSZTÓW OPROGRAMOWANIA 121

Lfc 8 • 1 Model COCOMO 123



  1. Model COCOMO 2 *' * 125

  2. Szacowanie czsu trwania projektu *2°

9. UDOSKONALENIE PROCESU PRODUKCJI 130

9.1 CMM model dojrzałości procesu 131

LITERETURA ! 132

1. Wprowadzenie

Pod koniec lat sześćdziesiątych miał miejsce tzw. kryzys oprogramowania. Wiele realizowanych wówczas projektów programowych kończyło się fiaskiem, a ceny realizowanego wówczas oprogramowania rosły bardzo szybko (około 12% na rok) przy zmniejszających się cenach sprzętu. Przyczyny upadku wielu realizowanych pod koniec lat sześćdziesiątych i na początku lat siedemdziesiątych projektów programowych to:

- duża złożoność produkowanych systemów, nowe dziedziny
zastosowań,

niepowtarzalność poszczególnych przedsięwzięć,

- niesystematyczny proces budowy oprogramowania, trudności w
ocenie stopnia zaawansowania prac programistycznych,
pozorna łatwość wytwarzania i dokonywania poprawek (np. 100
linii w 1 dzień, 1000 linii w 10 dni ?).

Zdano sobie sprawę, że ulepszenia w procesie produkcji oprogramowania mogą przynieść duże korzyści ekonomiczne. Pomysłów na poprawę procesu produkcji oprogramowania szukano w innych naukach inżynieryjnych np. u inżynierów mechaników (ang. mechanical engeneering) czy inżynierów budowy dróg i mostów (ang. civil engeneering). Powstająca dziedzina, poprzez analogie z tymi naukami, została nazwana ang. software engeneering, a w języku polskim przyjął się termin inżynieria oprogramowania. Celem inżynierii oprogramowania (ang. software engineering) jest:

poszukiwanie i wdrażanie metod oraz technik produkcji

programów o wysokiej jakości,


I - produkcja w sposób najbardziej efektywny.

Ocena, czy oprogramowanie jest wysokiej jakości, jest sprawą subiektywną.

Oprogramowanie wysokiej jakości na pewno powinno spełniać następujące

warunki: |gj

działać zgodnie z wymaganiami określonymi przez specyfikację

projektową,

być tak szybkie, wydajne i funkcjonalne jak oczekuje użytkownik, dać się łatwo pielęgnować (korekcja i modyfikacja), - posiadać pełną dokumentację użytkową i projektową, która umożliwia

spełnienie poprzednich postulatów. Inżynieria oprogramowania dotyczy oprogramowania tworzonego przez zespoły, a jej zasady są wykorzystywane w rozwoju systemu, zawiera aspekty techniczne i nie- techniczne, występują w niej podejścia formalne i praktyczne. Inżynieria oprogramowania oferuje:

techniki i narzędzia ułatwiające pracę nad złożonymi systemami,

W systematyzuje proces produkcji oprogramowania tak, by ułatwić jego U monitorowanie i planowanie,

metody wspomagające analizę nieznanych problemów i ułatwiające wykorzystywanie wcześniejszych doświadczeń.

tożynieria oprogramowania zajmuje się:

snosobami prowadzenia przedsięwzięć informatycznych,

" gikami szacowania kosztów, harmonogramowama,
metodami analizy i projektowaniat systemów,
technikami zwiększania niezawodności oprogramowania,
sposobami testowania systemów, szacowania niezawodności, I

sposobami przygotowywania dokumentacji technicznej i użytkowej,

. procedurami kontroli jakości,

- technikami pracy zespołowej.

Inżynieria oprogramowania jest dynamicznie rozwijającą się dziedziną, a jej sukces i rozwój jest powodowany: \**ą rozwojem metodyk,

- rozwojem narzędzi CASE (ang. Computer Aided Software Engineering)


wspierających cały proces produkcji oprogramowania,

edukacją - wydziały na uczelniach, kierunki kształcenia

- doświadczeniami praktycznymi,

[-«. pracami naukowymi, których rezultaty prezentowane są na szczeblu I krajowym, europejskim czy ogólnoświatowym.

1.1 Jakość oprogramowania

Ocena jakości oprogramowania jest sprawą subiektywną Model Mc CalTa dzieli kryteria oceny jakości na grupy związane:



  1. ze sposobem działania oprogramowania,

  2. z możliwością zmian i poprawek w programie,

  3. z mobilnością oprogramowania. I

Ad. a)

Kryteria związane ze sposobem działania oprogramowania mogą dotyczyć oceny następujących cech:

- pnzyjazność - dotyczy projektu interfejsu z użytkownikiem,

zpieczenstwo - kontrola uprawnień dostępu oraz odporność na skutki nieprawidłowej obsługi, " wydajność,

poprawność - stopień realizacji wymagań, kompletność i logiczność

- SS^28"^ <^^aze sp^kacją

^twounosc - odporność na błędy, sposoby reakcji na nie.


Ad.b) \*A

Kryteria oceny związane z możliwością wprowadzania zmian i poprawek w

programie mogą dotyczyć oceny cech takich jak:



  • pielęgnowalność - stopień przystosowania programu do działań zmierzających do{ jego poprawienia, modyfikacji, rozszerzania, adaptowania do nowych wymagań, I

  • elastyczność - możliwości rozbudowywania oprogramowania o nowe funkcje oraz uniwersalność zaimplementowanych rozwiązań,

  • testowalność - przystosowanie oprogramowania do procesu testowania, tzn. jego struktura, dokumentacja.

Ad. c) ■."■"•;. |

Kryteria oceny związane z mobilnością oprogramowania mogą dotyczyć oceny cech takich jak:



  • przenośność - zdolność do łatwego uruchamiania na innych (niż środowisko projektowe) systemach,

  • uniwersalność - odnosi się do możliwości wykorzystania istniejącego oprogramowania lub jego fragmentów do konstrukcji innych systemów, otwartość - stopień przystosowania programu do współpracy lub wymiany informacji z innymi systemami komputerowymi.

Powyżej opisane pożądane cechy oprogramowania powinny być brane pod uwagę w projekcie oprogramowania. Problem jest osiągnięcia optimum, gdyż niektóre z wyżej wymienionych cech są sprzeczne. Decyzja co optymalizować, jakie są priorytety poszczególnych cech powinna być ustalona z klientem - np. lepszy interfejs użytkownika to zwykle spadek efektywności. Wzrost niezawodności oprogramowania może powodować spadek efektywności, jednak zawsze priorytet niezawodności powinien być wyższy niż efektywności ze względu na następujące powody:

  1. Sprzęt jest coraz szybszy, tańszy, ważniejsza jest wygoda pracy użytkownika.

  2. Zawodne oprogramowanie będzie unikane przez użytkowników niezależnie od tego jak jest efektywne.

  3. Są zastosowania (ang. safety -critical systems), gdzie koszt błędu systemu może znacznie przekraczać koszt samego systemu a koszty ludzkie nie są do zaakceptowania.

  4. System zawodny trudno jest ulepszyć, poprawić. System niezawodny można stroić, lokalizować przyczyny opóźnień.

5. Nieefektywność powoduje, że program wykonuje się dłużej, jednak jego
I skutki można przewidzieć. W zawodnym systemie skutki pracy mogą byc

trudne do przewidzenia, błędy w projekcie mogą prowadzić do katastrofy.

6. Zawodne systemy mogą powodować utratę danych.

7

Niezawodność programowania zależy od:

" p°P^ości odwzorowania projektu w implementację, l jawności elementów i ich złożenia. ^

Kluczem do niezawodności oprogramowania jest specyfikacja.





Koszt

Niezawodność Rys. 1.1 Koszt oprogramowania a niezawodność

Specyfikacje niepełne - nie określają co się ma dziać, gdy wystąpi błąd, decyzja spoczywa na programiście i często nie jest właściwa. Specyfikacje formalne powinny prowadzić do bardziej niezawodnych systemów, ale ze względu na trudności ich tworzenia, nie wiemy czy one rzeczywiście odzwierciedlają oczekiwania użytkownika.



1. 2. 3. 4. 5. 6.
Pytania kontrolne oj

Czym zajmuje się inżynieria oprogramowania ?

Jakie są cechy oprogramowania wysokiej jakości ?

Jakie można stosować kryteria oceny oprogramowania ?

Od czego zależy niezawodność oprogramowania ?

Jakie cechy oprogramowania są związane z jego działaniem ?

Co oferuje inżynieria oprogramowania ? 7. Dlaczego ważniejsza jest niezawodność oprogramowania,

efektywność ?

niz

2. Modele cyklu życia oprogramowania

Modele cyklu życia oprogramowania pokazują, jak można organizować proces


produkcji oprogramowania. piuucs

2.1 Model wodospadowy

Model wodospadowy (ang. waterfall) zaproponowany prawdopodobnie przez Royce w 1970 był pierwszym sposobem ma organizowanie procesu produkcji oprogramowania. Inne nazwy tego modelu to model kaskadowy czy liniowy. Przez analogię do prowadzenia prac inżynieryjnych wprowadzono fazy:

- specyfikacji wymagań (określenie funkcji systemu),

- projektowania oprogramowania (ang. design),

- implementacji (ang. implementation, coding), - testowania,

- użytkowania i pielęgnowania. Przejście do kolejnej fazy następuje po zamknięciu, zakończeniu fazy aktualnej. W praktyce stosowane są jednak nawroty do wcześniejszych faz np. pewne problemy implementacyjne mogą występować ze względu na braki w projekcie, należy się wówczas wycofać do fazy projektowania, ale braki w projekcie mogą być spowodowane brakami w specyfikacji. Im więcej faz będzie obejmował nawrót, tym większe będą koszty jego przeprowadzenia. Model wodospadowy może być stosowany do produkcji systemów, dla których można przygotować dokładną specyfikację wymagań, gdyż koszt usunięcia błędów popełnionych we wczesnych fazach, a zauważonych w fazach późniejszych, jest bardzo wysoki. W produkcji oprogramowania zgodnie z modelem wodospadowym, kontakty z klientem są podczas specyfikacji wymagań, a następnie podczas instalacji systemu. Występuje długa przerwa w kontaktach z klientem podczas której mogą zmienić się jego oczekiwania. Jeżeli czas produkcji systemu będzie długi, to może dojść do sytuacji, w której system nie spełnia oczekiwań użytkowników, czyli nie przejdzie walidacji. W modelu wodospadowym możliwa jest weryfikacja systemu, czyli sprawdzenie, czy spełnia on specyfikację.

W modelu można także wyróżnić inne fazy, nakładające się na niektóre z wyżej

wymienionych (rys. 2.1): . i I ••

- strategiczna - podejmowanie decyzji, wymaga ogólnego określenia runKcj

systemu,

- analizy - budowany jest logiczny model systemu, |


dokumentacji.

Określanie Projektowanie Implementa Testowanie Praca



u , cja Pielęgnowanie

wymagań m ^i^^^i^

Dokumentacja

Faza

strategiczna Analiza

Rys. 2.1 Model wodospadowy



Określenie, jaki jest koszt realizacji poszczególnych faz modelu wodospadowego, jest zagadnieniem trudnym.

Wymagania i

projekt

Implementacja

Testowanie

systemy sterowania, systemy operacyjne systemy naukowe systemy biznesowe

46% 33% 44% 44%

20% 17% 26% 28%

34% 50% 30% 28%

Tab. 2.1 Procentowe koszty realizacji faz modelu wodospadowego

W tabeli 2.1 przedstawiono dane dotyczące różnych typów systemów pochodzące sprzed kilku lat W aktualnie produkowanych systemach rośnie udział kosztu testowania, dla wielu systemów przekracza 60% kosztu produkcji całego systemu, a dla pewnych dochodzi nawet do 80%.

Mimo, że model wodospadowy został zaproponowany wiele lat temu, jest nadal stosowany przy produkcji systemów, dla których można przygotować dokładne wymagania i których czas produkcji nie jest zbyt długi. Jest to model bardzo „lubiany" przez kierowników projektów ze względu na narzucenie kolejności wykonywania prac i łatwość zarządzania przedsięwzięciem (planowanie, ^rmonogramowanie, monitorowanie). Każda faza modelu wodospadowego

S^hM2^ W "fizycznie" istnieJe> czymś co dostarcza się klientowi (ang. e). W tab. 2.2 przedstawiono rezultaty faz modelu wodospadowego.



Fg-yą modelu wodospadowego
^ngHzg_wymagań

Specyfikacja systemu

Projektowanie architektury

Projektowanie interfejsów



Projektowanie jednostek

Kodowanie

Testowanie jednostek

Testowanie modułów

Testowanie integracyjne

Rezultat


Studium wykonalności, „zgrabnej wymagania

Dokument opisujący wymagania

Funkcjonalna specyfikacja systemu, plan testów akceptacyjnych, szkic podręcznika użytkownika



Specyfikacja architektury, testy systemowe

Specyfikacja interfejsów, testy integracyjne

Projekt szczegółowy, testy jednostkowe

Kod programu

Raport testowania jednostkowego

Raport testowania modułów

Raport testowania integracyjnego, podręcznik użytkownika




Testowanie systemowe

Testowanie akceptacyjne

Raport testowania systemowego



System i dokumentacja

Tab. 2.2 Rezultaty faz modelu wodospadowego

2.2 Model ewolucyjny

Model ewolucyjny (ang. exploratory programming) inaczej odkrywczy jest stosowany w przypadkach, gdy określenie dokładnych wymagań klienta nie jest możliwe (np. systemy sztucznej inteligencji, nowe dziedziny zastosowań). Ideą modelu ewolucyjnego jest opracowanie pracującego systemu bardzo szybko i oddanie sytemu w użytkowanie. Klient pracując „odkrywa" nowe potrzebne mu funkcje. Następują szybkie modyfikacje systemu, dostosowujące go do nowych wymagań. Modyfikacje trwają dopóki system nie będzie odpowiadał klientowi lub okaże się, że nie da go się adoptować (rys.2.2).

Systemy w -ten sposób tworzone mają bardzo zagmatwaną strukturę. Wprowadzenie każdej kolejnej zmiany jest coraz trudniejsze, może się nawet okazać, że nie będzie można jej przeprowadzić. Ze względu na konieczność szybkiej produkcji nowej wersji systemu nie tworzy się dokumentacji i w związku z tym metoda ta nie gwarantuje możliwości pielęgnowania systemu. Konieczność bardzo szybkiej produkcji systemu wymaga użycia specjalnych j środowisk produkcji (RAD), czy języków programowania takich jak np. Lisp, Prolog.

Zaletą modelu ewolucyjnego jest możliwość stosowania nawet w przypadkach kłopotów z określeniem wymagań klienta. Przy produkcji oprogramowania j według tego modelu, nie ma weryfikacji (sprawdzenia czy spełnia wymogi), gdyż wymagania zmieniają się wielokrotnie. Metodę te można stosować w przypadku systemów małych (np. poniżej 100000 linii kodu) czy średnich (np.

11


noniżej 500000 linii kodu) o krótkim czasie życia. Często metodą tę stosuje się do opracowania prototypu operacyjnego na którym przez jakiś czas pracują Użytkownicy, a w tym czasie buduje się dobrze zorganizowany system.

Opracowanie specyfikacji



Budowa systemu

Użytkowanie systemu



Rys. 2.2 Model ewolucyjny



2.3 Prototypowanie

W przypadku braków w specyfikacji, trudności w określeniu wymagań, nieporozumień między klientem a projektantami stosuje się szybkie prototypowanie (ang. rapid protyping). Prototypowanie przebiega w następujących krokach:



  • ogólne określenie wymagań prototypowanego systemu,

  • opracowanie szybko działającego prototypu,

  • weryfikacja prototypu przez klienta,

  • określenie szczegółowych wymagań.

rototyp^ pozwala na demonstrację pracującego systemu, a także daje możliwości szkolenia, zanim zostanie zbudowany pełen system. Bardzo często

!!?5^ Slę prototyP interfejsu użytkownika korzystając z generatorów interfejsów użytkownika.

u oWa prototypu odbywa się za pomocą programowania ewolucyjnego, wy orzystuje się gotowe komponenty, stosuje się niepełną realizację, języki wysokiego poziomu,.


2.4 Formalne transformacje

Po definicji wymagań systemu zapisuje sieje w języku formalnym. Podlegają one serii automatycznych przekształceń do programu, a następnie wykonuje się integrację systemu i testowanie.

Bardzo znanym przykładem takiego podejścia do realizacji systemu jest proces Cleanroom zastosowany po raz pierwszy w IBM w 1987 (Mills et al. Selby et al.) następnie modyfikowany w 1994 (Linger), 1999 (Prowell). Proces ten polega na przyrostowej realizacji oprogramowania, każdy stopień realizuje się i pokazuje jego poprawność za pomocą podejścia formalnego. Nie ma w tym procesie testowania ukierunkowanego na wykrywanie defektów, a testowanie systemu ukierunkowane jest na wyznaczenie parametrów niezawodnościowych systemu.

Inna znana metoda to metoda B (Wordsworth 1996) polegająca na zapisie wymagań w notacji matematycznej i automatycznych transformacjach do wykonywalnego kodu. Efektywność kodu w ten sposób uzyskanego jest jednak niska. Niezawodność systemów uzyskanych metodą formalnych transformacji jest bardzo wysoka, gdyż brak jest błędów przy transformacjach. Stosuje sieją do produkcji systemów wymagających dużej niezawodności, bezpieczeństwa. Nie jest to metoda powszechnie stosowana. Formalne specyfikacje wymagają dużych umiejętności zespołu. Nie wszystkie wymagania można formalnie wyspecyfikować np. nie można formalnie wyspecyfikować interfejsu użytkownika.



2.5 Montaż z gotowych elementów

W większości realizowanych projektów ponownie wykorzystuje się kod wcześniej zrealizowany (ang. reuse), często po jego modyfikacjach. W ostatnich latach coraz częściej firmy produkujące oprogramowanie sięgają do „gotowego" kodu, gdyż przyśpiesza to czas produkcji i obniża koszty. W montażu z gotowych elementów (ang. reuse, off-shell programming) korzysta się z gotowych, dostępnych komponentów i tworzy się integrujący je. Często komponenty te są systemami dostarczającymi określone funkcje np. formatowanie tekstu, obliczenia numeryczne, nazywane są one systemami COTS ang. Commercial Off The Shelf. Proces produkcji oprogramowania z zastosowaniem gotowych komponentów przebiega w następujących krokach:

Specyfikacja wymagań. - Analiza komponentów - poszukiwanie komponentów

spełniających fimkcje systemu, zwykle komponenty spełniająj

tylko część wymagań.

ii




do Izo






. Modyfikacja wymagań dostosowanie wymagań

znalezionych komponentów, w przypadku wymagań bardzl


istotnych dla systemu, dla których nie znaleziono komponentów
poszukiwanie rozwiązań alternatywnych.
Projektowanie systemu z komponentami zaprojektowanie
połączeń" między komponentami, ewentualne zaprojektowanie
kodu realizującego wymagania, dla których komponenty nie
były dostępne. vy . | f'

Realizacja systemu i integracja implementacja i testowanie zaprojektowanego kodu i integracja komponentów. Zaletami montażu z komponentów są wysoka niezawodność, redukcja kosztów przyśpieszenie dostawy. Systemy w ten sposób realizowane mogą jednak nie w pełni realizować wymagania klienta. Mogą również wystąpić w przyszłości kłopoty z modyfikacją systemu np. nowe wersje komponentów mogą być niedostępne.





  1   2   3   4   5   6   7   8   9   10   11


©absta.pl 2019
wyślij wiadomość

    Strona główna