RSS
 

Archiwum dla kategorii ‘X. Inżynieria oprogramowania’

Miary oprogramowania

21 lis

Proces pomiaru

Miara oprogramowania to jednostki przydzielone w procesie pomiaru, inaczej jest to wyrażenie wielkości charakteryzującej pewną cechę, tj. atrybut oprogramowania lub procesu wytwórczego.

Proces pomiaru składa się z pięciu etapów:
- sformułowanie – zdefiniowanie celów pomiarów, jednoznaczny dobór rzetelnych metryk, czyli proponowanych, postulowanych miar,
- pomiar – zebranie danych niezbędnych do obliczenia sformułowanych miar,
- analiza – obliczenie wartości miar na podstawie danych uzyskanych w pomiarach,
- interpretacja – ocena wyników pomiaru, zidentyfikowanie anormalnych wartości pomiaru oraz ich przyczyn, wskazanie działań naprawczych,
- sprzężenie zwrotne – wprowadzenie zmian w produkcie u/lub procesie wytwarzania oprogramowania.

Obliczone miary powinny być przechowywane trwale w repozytorium danych w celu wspomagania statyczne kontroli procesu wytwórczego.

Podział miar ze względu na przedmiot pomiaru:
- miara procesu – pozwala dokonywać oceny procesu wytwórczego, artefaktów, miary są zbierane podczas trwania wszystkich przedsięwzięć jednostki lub zespołu, pozwalają wprowadzać ulepszenia modelu procesu wytwórczego, na ich podstawie są wykonywane decyzje strategiczne,
- miara produktu – pozwala ocenić przedsięwzięcie programistyczne, harmonogramy poszczególnych faz, postępy realizacji prac, decyzje podejmowane są taktyczne, miary te pozwalają oszacować czas i zasoby niezbędne do wytworzenia produktu, a także wykryć odchylenia w realizacji harmonogramu oraz budżetu.

Przegląd miar oprogramowania
Podział kategorii miar ze względu na dane wejściowe, niezbędne do obliczenia wartości danej miary:
- miary oparte na wielkości kodu źródłowego,
- miary uwzględniające funkcje oprogramowania.

Pierwsza z kategorii miar wykorzystuje wielkość oprogramowania, mierzoną w liczbie linii kodu – podstawowa jednostką zwana jest LOC (ang. lines of code), a w przypadku złożonego oprogramowania używa się jednostki KLOC (1 KLOC = 1000 LOC).

PODSTAWOWE MIARY OPARTE NA WIELKOŚCI KODU ŹRÓDŁOWEGO
Podstawowe miary oparte na wielkości kodu źródłowego

TC – koszt całkowity wytworzenia oprogramowania,
TD – całkowita wielkość dokumentacji w stronach,
TE – całkowita liczba błędów w kodzie,
TMM – całkowita liczba osobomiesięcy niezbędna do wytworzenia produktu końcowego,
l – długość kodu źródłowego w liniach.

Podstawową miarą wykorzystującą funkcje oprogramowania jest miara punktów funkcyjnych. W celu obliczenia tej miary niezbędne są następujące dane początkowe:
- liczba wejść użytkownika (ang. external inputs) – liczba miejsc, w których użytkownik może wprowadzić dane do programu,
- liczba wyjść użytkownika (ang. external outputs) – liczba miejsc, w których informacja jest udostępniana użytkownikowi,
- liczba zapytań użytkownika (ang. external inquiry) – liczba miejsc, w których użytkownik może po wprowadzeniu danych uzyskać natychmiastowo informację zwrotną,
- liczba struktur danych (ang. internal logical files) – liczba logicznych struktur przechowywania danych,
- liczba interfejsów z innymi systemami oraz aplikacjami (ang. eternal interface files) – liczba miejsc, w których oceniany program przekazuje cyfrowo informacje do systemów/aplikacji zewnętrznych.

Następnie do każdej z obliczonych wartości należy przypisać wagi odpowiadające złożoności danej kategorii (proste, średnio złożone, złożone). Kategorie te można zidentyfikować, posiłkując się diagramami przepływu danych DPD.

OBLICZANIE SUMY WAŻONEJ
Obliczanie sumy ważonej

TEI – całkowita liczba wejść użytkownika,
TEO – całkowita liczba wyjść użytkownika,
TEQ – całkowita liczba zapytań użytkownika,
TILF – całkowita liczba struktur danych,
TEIL – całkowita liczba interfejsów do systemów/aplikacji zewnętrznych.

Następnie po obliczeniu sumy (S) możliwe jest obliczenie punktów funkcyjnych (ang. functional point) za pomocą następującego wzoru:

Wzór na funcional point

gdzie Suma – współczynnik złożoności ustalony na podstawie odpowiedzi na czternaście pytań.

Każdemu z czternastu pytań należy przyporządkować ocenę w skali od zera (nie dotyczy/nieistotne) do 5 (bardzo istotne). Lista pytań:
1.Czy system wymaga tworzenia kopii danych (backupów)?
2.Czy niezbędna jest transmisja danych do/z innych systemów?
3.Czy przetwarzanie danych odbywa się w sposób rozproszony?
4.Czy efektywność jest bardzo istotna?
5.Czy system będzie uruchamiany w istniejącym/silnie eksploatowanym środowisku?
6.Czy system umożliwia wprowadzanie danych przez użytkownika?
7.Czy sposób wprowadzania danych jest bardzo złożony/skomplikowany?
8.Czy dane są modyfikowane w czasie rzeczywistym?
9.Czy kategorie opisywane w tabeli (obliczanie sumy ważonej) są bardzo złożone?
10.Czy algorytmy przetwarzania danych są bardzo złożone?
11.Czy kos ma podlegać ponownemu użyciu?
12.Czy projekt obejmuje wdrożenie systemu?
13.Czy system będzie działał u wielu klientów?
14.Czy użytkownik będzie mieć możliwość modyfikacji/konfiguracji systemu?

Miarę FP można również wykorzystywać jako podstawę do normalizacji wyników pomiarów jakości, wydajności pracy, konstruując następujące miary:
- liczba błędów na punkt funkcyjny,
- liczba usterek na punkt funkcyjny,
- punkt funkcyjny na osobomiesiąc pracy,
- koszt wytworzenia jednego punktu funkcyjnego,
- wielkość dokumentacji przypadającej na jeden punkt funkcyjny.

 

Model Boehma i model ISO 9126

20 lis

Model Boehma to klasyczny model jakości, wyróżnia się trzy charakterystyki – warunki konieczne i wystarczające, niezbędne do osiągnięcia ogólnej jakości:
- łatwość konserwacji,
- przenośność,
- przydatność (ang. usability).

Podcharakterystyki odnoszą się głównie do jakości kodu źródłowego.

Model ISO 9126

Model jakości ISO 9126:1991 jest standardem opisującym jednolity model jakości oprogramowania. Standard ten definiuje charakterystyki i podcharakterystyki jakości oprogramowania, a także miary odpowiednie do kwantyfikacji poszczególnych charakterystyk. Standard ten opiera się na modelach McCalla oraz Boehma, można go stosować do oceny jakości dowolnego rodzaju oprogramowania.

MODEL JAKOŚCI ISO 9126
Model jakości ISO 9126

 
Brak komentarzy

Napisane w kategorii 6. Modele jakości

 

Model McCalla

19 lis

Czynniki jakości podzielono na następujące trzy grupy charakterystyk związanych z:
- funkcjonowaniem oprogramowania,
- modyfikowalnością produktu,
- przenośnością produktu.

TRÓJKĄT JAKOŚCI MCCALLA
Model jakości McCalla

W ramach każdej z tych grup opracowano zestaw charakterystyk jakości, dla których zaproponowano zbiór podcharakterystyk. Model ten znany jest jako trójkąt jakości McCalla. Charakterystyki jakości w tym modelu reprezentują zewnętrzną perspektywę oprogramowania, czyli sposób w jaki jest ono odbierane przez użytkowników. Podcharakterystyki prezentują oprogramowania z punktu widzenia dewelopera, podczas gdy miary stanowią narzędzie kwantyfikacji jakości. Dla każdej z podcharakterystyk wykonuje się subiektywną ocenę w sakli od 1 do 10. Niektóre charakterystyki mają wspólne podcharakterystyki. Następnie, po uwzględnieniu wag poszczególnych miar, możliwe jest obliczenie ocen poszczególnych charakterystyk jakości oraz oceny jakości całego produktu

 
Brak komentarzy

Napisane w kategorii 6. Modele jakości

 

Jakość oprogramowania

18 lis

Pojęcie jakości

Jakość to stopień, w jakim zbiór przynależnych właściwości spełnia wymagania.

Jakość to zgodność z jawnie oraz niejawnie określonymi wymaganiami.

Model jakości

Model jakości to próba ilościowego zdefiniowania jakości za pomocą zestawu niemierzalnych charakterystyk jakości – czynników, atrybutów wysokiego poziomu oraz ich podcharakterystyk, zwanych także składowymi lub atrybutami niskiego poziomu, możliwych do wyrażenia za pomocą bezpośrednio lub pośrednio kwantyfikowanych miar.

W modelach jakości dopuszczalne jest występowanie atrybutów wysokiego poziomu o wspólnych podcharakterystykach. Charakterystyki z racji posiadania wspólnych składowych, mają wspólne miary. Oceny charakterystyk mogą być skorelowane.

 

Przeglądy i zależności między pojęciami

17 lis

Przegląd (ang. review) to proces, podczas którego produkt, tj. pewien artefakt procesu wytwórczego, jest prezentowany zespołowi projektowemu, menedżerom, użytkownikom, klientom i innym interesariuszom w celu zaopiniowania lub zatwierdzenia.

Ze względu na stopień sformalizowania przeglądy można podzielić na:
- nieformalne – opracowane sytuacyjnie (ad hoc),
- sformalizowane – ich przebieg opisany jest przez konkretne reguły, zasady, procedury lub standardy, mają zdefiniowane zasoby projektowe, cele, odpowiedzialności, ich artefaktem jest dokument o ściśle określonej strukturze.

Inspekcja to zdyscyplinowana technika analizy statyczne, polegająca na wizualnym przeglądzie, tj. ocenie produktów procesu wytwórczego, tj.: kod źródłowy, dokumentacja projektowa, w celu wykrycia anomalii, w tym błędów oraz odstępstw od standardów i specyfikacji.

Do podstawowych celów przeprowadzania inspekcji należy zaliczyć:
- wykrywanie, identyfikację i usunięcie defektów w produktach procesu wytwórczego,
- potwierdzenie jakości produktu procesu wytwórczego,
- doskonalenie procesu wytwórczego za pomocą analizy przyczyn zarejestrowanych defektów,
- promowanie projakościowych praktyk działania.

Inspekcja jest przeprowadzana przez zespół, w którym każda z osób odgrywa jedną lub więcej ról.

ROLE W PROCESIE INSPEKCJI
Role w procesie inspekcji

Fazy procesu inspekcji
I faza: Planowanie (ang. planning) – moderator podejmuje decyzję, który artefakt należy poddać inspekcji, dobiera członków zespołu, określa dokumenty niezbędne do przeprowadzenia inspekcji, definiuje warunki jej zakończenia

II faza: Inicjalizacja (ang. overview) – wyjaśnienie członkom zespołu zasad inspekcji, jej harmonogramu, celów oraz przydziału ról

III faza: Przygotowanie (ang. preparation) – kontrolerzy indywidualnie przeglądają analizowany artefakt w celu znalezienia defektów

IV faza: Kontrola (ang. inspection meeting) – spotkanie wszystkich członków zespołu, podczas którego opracowywana jest spójna lista defektów wykrytych we wcześniejszej fazie przez inspektorów. Spotkanie jest prowadzone przez moderatora, rezultaty praz wykonanych w fazie III są odczytywane przez prezentera. Moderator oraz kontrolerzy w trakcie odczytywania wskazują niezgodności i sugerują poprawki, jakie autor powinien wprowadzić do artefaktu. Opinie te są zapisywane przez sekretarza

V faza: Naprawa (ang. rework) – autor wprowadza modyfikacje, zgodnie z sugestiami

VI faza: Sprawdzenie (ang. follow-up) – moderator sprawdzam czy autor dokonał odpowiednich poprawek. Decyzja o zakończeniu inspekcji jest podejmowana przez lidera przy wykorzystaniu kryteriów zakończenia zdefiniowanych w fazie planowania.

Zależności między pojęciami
Testowanie, weryfikacja oraz walidacja mają ten sam cel główny, którym jest zapewnienie oprogramowaniu jak najwyższej jakości, lecz odmienne cele szczegółowe, związane z zapewnieniem jakości:
- testowanie
– zapewnienie jakości kodu,
- weryfikacja – zapewnienie jakości poszczególnych faz procesu wytwórczego oraz ich produktów,
- walidacja – zapewnienie jakości produktu z perspektywy odbiorcy.

Walidacja stanowi bezpośrednie sprzężenie każdego z artefaktów procesu wytwórczego z wymaganiami użytkownika. Weryfikacja to proces sprawdzenia zgodności specyfikacji z implementacją, realizowany dla każdego z artefaktów. Testowanie oraz przeglądy to jedyne formy realizacji weryfikacji i walidacji.

 

Proces testowania oprogramowania

16 lis

Podział testów ze względu na obszar, który podlega testowaniu:
- jednostkowe (modułów),
- integracyjne (scalenie),
- systemowe,
- akceptacyjne.

Proces testowania oprogramowania przebiega od ogółu do szczegółu – jest to podejście bottom-up. W przeprowadzaniu testów oprogramowania przydatne są specjalistyczne narzędzia do testowania.

PROCES TESTOWANIA OPROGRAMOWANIA – ZESTAWIENIE PRZEGLĄDOWE
Proces testowania oprogramowania - zestawienie przeglądowe

Testowanie regresyjne – służy potwierdzeniu skuteczności dokonanych modyfikacji mających na celu usunięcie wykrytych wcześniej błędów.

 

Testowanie i metody testowania

15 lis

Testowanie jest podstawową metodą analizy dynamicznej, stanowi proces wykonywania programu w celu wykrycia błędów. Czynność ta koncentruje się na sprawdzeniu poprawności wewnętrznej struktury oraz sposobu funkcjonowania programu.

Zasady projektowania dobrych testów:
- od szczegółu do ogółu – testowanie rozpoczyna się od pojedynczych modułów, a kończy na testach całego systemu,
- zgodność produktu z wymaganiami klienta,
- projekt i plan testów – powinny być przygotowane przed implementacją kodu, projekt testów można opracować po sporządzeniu specyfikacji wymagań, szczegółowy zestaw testów po zakończeniu fazy projektowania,
- zasada Pareto – 80% błędów związane jest z 20% dostarczanego oprogramowania,
- testowanie przez osoby z zewnątrz – pozwala wykryć więcej błędów niż testowanie przez twórców systemu.

Metody testowania
Metody projektowania testów można podzielić na dwie podstawowe kategorie:
- metoda białej skrzynki (ang. white box testing), zwana inaczej testowaniem struktury (ang. structural testing),
- metoda czarnej skrzynki (ang. black box testing), zwana też jako testowanie funkcyjne (ang. functional testing).

Metoda białej skrzynki polega na testowaniu wewnętrznej struktury programu – analizie kodu źródłowego. Metoda ta pozwala na takie zaprojektowanie testu, aby objął on:
- każdą linię kodu źródłowego,
- każdą niezależną ścieżkę w module,
- wszystkie warianty decyzji logicznych,
- wszystkie pętle,
- wszystkie wewnętrzne struktury danych.

Można wyróżnić następujące prawidłowości:
- liczba błędów logicznych jest odwrotnie proporcjonalna do częstości wykonywania danego fragmentu kodu – im rzadziej funkcja czy przepływ są wykonywane, tym bardziej prawdopodobne jest, iż zawierają błędy,
- programiści popełniają błędy literowe, nie wszystkie z nich są wykrywane przez kompilatory czy też analizatory składni.

Metoda białej skrzynki pozwala na wykrycie nieprawidłowego użycia:
- operatorów logicznych,
- typów danych,
- wyrażeń arytmetycznych,
- definicji warunków logicznych,
- zagnieżdżeń pętli,
- warunków brzegowych pętli,
- konwersji typów.

Metoda białej skrzynki jest przydatna przy projektowaniu testów jednostkowych oraz integracyjnych. Najczęściej wykorzystywanych wariantem metody białej skrzynki jest zaprojektowana przez McCabe metoda ścieżek podstawowych, polegająca na testowaniu głównych, bazowych ścieżek logicznych w ramach struktur programu.

Metoda czarnej skrzynki służy do kompletnego testowania zgodności programu z wymaganiami funkcyjnymi. W tej metodzie wnętrze systemu, tj. wewnętrzna struktura programu, jego kod źródłowy, jest dla testującego nieznany niczym czarna skrzynka, a nawet nieistotny. Metoda czarnej skrzynki pozwala na wykrycie błędów związanych z:
- źle zaimplementowaną funkcjonalnością,
- niedostarczeniem pewnej funkcjonalności,
- niewłaściwymi zachowaniami systemu,
- problemami wydajnościowymi.

Testowanie funkcyjne koncentruje się na sferze informacyjnej funkcjonowania systemu informatycznego. Tak więc dla każdego przypadku testowego określa się dane wejściowe oraz oczekiwane rezultaty, które powinny zostać zwrócone przez oprogramowanie. Rezultaty rozbieżne z oczekiwaniami stanowią błędy, które powinny być usunięte.

WARIANTY METODY CZARNEJ SKRZYNKI
Warianty metody czarnej skrzynki

 

Weryfikacja i walidacja

14 lis

Błędem jest każde niepożądane lub nieoczekiwane zachowanie produktu programistycznego wykryte przed przekazaniem go jego odbiorcom.

Błędy, których w trakcie procesu wytwórczego nie wykryto, ulegają wzmocnieniu – ujawniają się, gdy oprogramowanie jest już używane przez odbiorcę. Mogą one prowadzić do awarii oprogramowania, czyli zachowań produktu niezgodnych z oczekiwaniami określonymi na etapie formułowania wymagań.

Każda anomalia działania gotowego produktu, powstałą wskutek niewykrycia błędów przed przekazaniem oprogramowania do eksploatacji, jest usterką.

Aby zapewnić oprogramowaniu jak największą jakość, proces wytwórczy oprogramowania powinien obejmować, oprócz procesów podstawowych, procesy wspomagające, tj. weryfikację, walidację oraz testowanie.

Weryfikacja to proces oceny zgodności artefaktów danej fazy procesu wytwarzania oprogramowania z założeniami przyjętymi na jej początku.

Walidacja, zwana również jako zatwierdzenie, to proces oceny zgodności artefaktów danej fazy cyklu wytwórczego, zwłaszcza gotowego produktu, z wymaganiami klienta.

Weryfikacja stanowi próbę odpowiedzi na pytanie, czy produkuje się produkt taj, jak trzeba, natomiast walidacja pozwala rozstrzygnąć, czy buduje się ten produkt, co trzeba.

Pięć kategorii weryfikacji i walidacji:
- przeglądy (ang. reviews) – stosowanie takich technik, jak przeglądy nieformalne, kontrole drobiazgowe (ang. walkthroughs), inspekcje oraz audyty artefaktów wszystkich faz procesu wytwórczego,
- dowody poprawności (ang. proof of correctness) – znane również jako weryfikacja formalna, polegająca na dowodzeniu tezy, że program jest poprawny, za pomocą formalnego aparatu matematycznego,
- śledzenie wymagań (ang. requirements tracing) – sprawdzenie, czy wszystkie wymagania klienta są zaspokojone oraz przetestowane, tj. skojarzenie każdego z wymagań z odpowiednim przypadkiem testowym i modułem oprogramowania implementującym je,
- testowanie – uruchamianie programu, wprowadzenie danych wejściowych w celu wykrycia nieprawidłowych zachowań programu w określonych warunkach,
- symulacje oraz prototypowanie (ang. simulation and prototyping) – stosowane w celu sprawdzenia specyfikacji produktu pod kątem realizacji wymagań klienta przy założeniu poprawności prototypu oraz symulacji.

Przedstawione techniki weryfikacji i walidacji koncentrują się wokół dwóch zagadnień – struktur oraz dynamiki tworzonego oprogramowania.

Analiza statyczna – przegląd, dowód poprawności, śledzenie wymagań, przedmiotem analizy jest specyfikacja wymagań, projekt systemu, kod źródłowy, gotowy produkt.

Analiza dynamiczna – testowanie, prototypowanie oraz symulacje, przedmiotem analizy jest kod źródłowy.

 

Procesowość w wytwarzaniu oprogramowania

13 lis

Wyróżnia się trzy kategorię procesów:
- procesy podstawowe – procesy o charakterze fundamentalnym,
- procesy organizacyjne – wyzwalane w celu ustanowienia ram, kontroli i ulepszenia procesu wytwórczego,
- procesy wspomagające – wywoływane przez procesy podstawowe i organizacyjne.

SZCZEGÓŁOWY OPIS PROCESÓW WCHODZĄCYCH W SKŁAD POWYŻSZYCH KATEGORII
Procesy podstawowe:
- akwizycja – zdefiniowanie potrzeby nabycia oprogramowania, przygotowane zapytania ofertowego, wybór,
- zaopatrzenie – podpisanie kontraktu między dostawcą a odbiorcą, określenie wymaganych zasobów i terminu dostarczenia,
- rozwój – analiza wymagań, projektowanie, implementacja, testowanie oprogramowania,
- użytkowanie – testowanie operacyjne, wsparcie użytkowników,
- utrzymanie – analiza problemów, wprowadzanie modyfikacji i adaptacji, wycofanie oprogramowania z użycia wskutek pojawienia się bardziej efektywnych i nowoczesnych narzędzi.

Procesy organizacyjne:
- zarządzanie – definiowanie zakresu, planowanie, wykonanie, kontrola, przegląd i zamknięcie procesu, czynności, bądź zadania (ang. plan – do – check – act),
- zarządzanie infrastrukturą – proces zapewnienia infrastruktury, czyli zasobów sprzętowych niezbędnych do realizacji poszczególnych procesów,
- udoskonalanie – identyfikacja procesów podlegających ocenie w celu wyeliminowania niedoskonałości i defektów,
- szkolenie – rozwijanie umiejętności technicznych i zarządczych członków zespołu.

Procesy wspomagające:
- dokumentowanie – definiowanie procesów podlegających dokumentacji oraz zasad tworzenia dokumentacji oraz zasad tworzenia dokumentacji projektowych,
- zarządzanie konfiguracją – zarządzanie konfiguracją, wersjonowaniem i modyfikacją oprogramowania,
- zapewnienie jakości – zapewnienie jakości produktu (zgodności produktu końcowego z wymaganiami klienta) oraz jakości poszczególnych procesów,
- weryfikacja – kontrola wykonania założeń każdego z procesów,
- walidacja 0 sprawdzenie rezultatów wszystkich procesów pod kątem realizacji wymagań klienta,
- przegląd
– kontrola statusu procesu, czynności bądź zadania,
- audyt – ocena zgodności systemu z wymaganiami i planami,
- rozwiązanie problemów – efektywna identyfikacja oraz eliminacja problemów.

 

Proces i produkt

12 lis

Inżynierię oprogramowania rozpatruje się w dwóch perspektywach:
- dynamicznej
– ukierunkowanej na procesowe aspekty tej dyscypliny,
- statycznej – ukierunkowanej na wymierne rezultaty, tj. produkty wszystkich procesów wytwarzania oprogramowania, tj.: koncepcje, specyfikacje, projekty oraz programy.

Proces wytwórczy oprogramowania to całokształt czynności niezbędnych do opracowania oprogramowania o pożądanych charakterystykach, obejmujący definiowanie, tj. formułowanie i analizę wymagać, tworzenie, a więc projektowanie i implementację, a także pielęgnowanie oprogramowania.

Każda z czynności w ramach procesu wytwórczego składa się z zadań do realizacji, kamieni milowych, produktów, a także punktów kontroli jakości. Proces wytwórczy jest ściśle dostosowany do wybranego cyklu życia systemu.

Produktem fazy procesu wytwórczego jest każdy powstały w rezultacie prac prowadzonych w danej fazie artefakt, czyli twór sztuczny będący rezultatem pracy ludzkiej.

Produktem końcowym procesu wytwórczego jest system informatyczny o pożądanych przez odbiorców charakterystykach. Do najważniejszych produktów procesu wytwórczego należy zaliczyć specyfikację wymagań, projekt systemu, plan testów, kod źródłowy i dokumentację.