©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 1 Zarządzanie jakością l Omówienie zarządzania jakością oprogramowania i opisanie specyficznych czynności zarządzania jakością

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 2 Cele l Poznać proces zarządzania jakością oraz główne czynności procesów zapewnienia jakości, planowania jakości i kontroli jakości. l Dowiedzieć się, jak ważne są standardy procesu zarządzania jakością. l Poznać pojęcie miary oprogramowania i różnice między miarami produkcyjnymi i kontrolnymi. l Dowiedzieć, w jaki sposób pomiary mogą pomóc w oszacowaniu pewnych atrybutów jakości i poznać obecne ograniczenia miernictwa oprogramowania.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 3 Zawartość l Zapewnienie jakości i standardy l Planowanie jakości l Kontrolowanie jakości l Miernictwo oprogramowania i miary

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 4 Jakość oprogramowania l Jest złożonym pojęciem, którego nie da się zdefiniować w prosty sposób. l W klasycznym ujęciu jakość oznacza, że utworzony produkt spełnia swoja specyfikację. l W idealnej rzeczywistości ta definicja powinna dotyczyć wszystkich produktów.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 5 Pewne uwagi dotyczące jakości l Specyfikacja powinna być poświęcona właściwościom produktu, których klient oczekuje. Firma produkująca może mieć dodatkowe wymagania (np. wymagania stawiane zdatności do pielęgnacji), których nie umieszcza się w specyfikacji. l Nie wiemy, jak specyfikować pewne jakościowe cechy (np. zdatność do pielęgnacji) w sposób jednoznaczny. l Napisanie kompletnej specyfikacji oprogramowania jest bardzo trudne. Bywa tak, że chociaż oprogramowanie jest zgodne ze swoją specyfikacją, użytkownicy nie muszą uważać go za produkt wysokiej jakości.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 6 Zarządzania jakością oprogramowania l Zapewnienie jakości. Ustalenie zrębu firmowych procedur i standardów, które umożliwiają utworzenie oprogramowania wysokiej jakości. l Planowanie jakości. Wybór odpowiednich procedur i standardów z tego zrębu i dostosowanie ich do konkretnego przedsięwzięcia informatycznego. l Kontrola jakości. Definiowanie i wdrażanie procesów, które sprawiają, że zespół budujący oprogramowanie przestrzega standardów i procedur jakości przedsięwzięcia.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 7 Zarządzanie jakością i tworzenie oprogramowania Proces tworzenia oprogramowania Proces zarządzania jakością Standardy Plan Raporty z kontroli jakości i procedury jakości W1 W2W3 W4 W5

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 8 Standardy l Międzynarodowy standard, który można wykorzystać przy opracowywaniu systemu zarządzania jakością we wszystkich gałęziach przemysłu, nosi nazwę ISO Jest to zbiór standardów, które można zastosować do wielu firm, m.in. fabryk i przedsiębiorstw usługowych. l ISO 9001 to najbardziej ogólny z tych standardów. Dotyczy firm zajmujących się procesem jakości w przedsiębiorstwach, które produkują, tworzą i pielęgnują produkty.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 9 ISO 9001 l ISO 9001 jest ogólnym modelem procesu jakości. Uwzględniono w nim rozmaite aspekty tego procesu oraz określono standardy i procedury, które muszą istnieć w firmie. l Nie zależą od gałęzi przemysłu, nie są więc szczegółowo zdefiniowane. l W ramach konkretnego przedsiębiorstwa należy zdefiniować i udokumentować zbiór odpowiednich procesów jakości w postaci firmowego podręcznika jakości.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 10 Zagadnienia uwzględnione w modelu zapewnienia jakości ISO 9001 Zadanie kierownictwaSystem jakości Kontrola niezgodnych produktówKontrola projektów Obsługa, składowanie, pakowanieZakupy i dostarczenie Produkty dostarczane przez sprzedawcówIdentyfikacja i śledzenie produktów Kontrola procesuInspekcja i testowanie Osprzęt do testowania i kontroliStan kontroli i testów Przegląd umowyCzynności poprawiające Kontrola dokumentówRejestry jakości Wewnętrzne kontrole jakościSzkolenie Realizacja usługMetody statystyczne

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 11 ISO 9000 i zarządzanie jakością Plan jakości przedsięwzięcia 3 Plan jakości przedsięwzięcia 3 Plan jakości przedsięwzięcia 1 Plan jakości przedsięwzięcia 1 Plan jakości przedsięwzięcia 2 Plan jakości przedsięwzięcia 2 Firmowy podręcznik jakości Firmowy podręcznik jakości Model jakości ISO 9000 Model jakości ISO 9000 Firmowy proces jakości Firmowy proces jakości Zarządzanie jakością przedsięwzięć Zarządzanie jakością przedsięwzięć Wspomaga jego egzemplarzem jest jest używany przy opracowaniu dokumentuje jego egzemplarzem jest

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 12 l Czynności zapewnienia jakości (Quality Assurance, QA) prowadzą do określenia zrębu osiągania jakości oprogramowania. l Proces QA obejmuje definiowanie i wybór standardów, które dotyczą procesu tworzenia oprogramowania i produktu programowego. l Te standardy można zawrzeć w procedurach lub procesach, które są stosowane w trakcie tworzenia. Procesy mogą być wspomagane przez narzędzia, w które wbudowano wiedzę o standardach jakości. Zapewnienie jakości i standardy

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 13 l Standardy produktowe. Są to standardy, które dotyczą tworzenia produktu. Obejmują standardy dokumentów, takie jak struktura dokumentacji wymagań, standardy dokumentowania, takie jak standardowy komentarz w nagłówku definicji klasy obiektów, i standardy kodowania. l Standardy procesowe. Są to standardy, w których określa się procesy do przestrzegania w czasie tworzenia oprogramowania. Mogą to być definicje procesów specyfikowania, projektowania i zatwierdzania oraz opisy dokumentów, które powinny powstać w trakcie tych procesów. Typy standardów

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 14 Przyczyny ważności standardów oprogramowania l Stanowią obudowę najlepszych albo co najmniej najodpowiedniejszych praktyk. Tę wiedzę często można zdobyć jedynie przez ogromna liczbę prób i błędów. l Stanowią zrąb, wokół którego można zaimplementować zapewniania jakości. Przy założeniu, że standardy są obudową najlepszych praktyk, kontrola jakości może polegać jedynie na upewnieniu się, że starannie przestrzegano standardów. l Pomagają w utrzymaniu ciągłości pracy wykonywanej przez jedną osobę i podjętej przez inną. Standardy sprawiają, że wszyscy inżynierowie firmy postępują w podobny sposób.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 15 Standardy produktowe i procesowe Standardy produktoweStandardy procesowe Formularz przeglądu projektuPrzebieg przeglądu projektu Struktura dokumentacji wymagańZgłaszanie dokumentów Format nagłówka proceduryProces rozpowszechniania wersji Styl programowania w JavieProces akceptacji planu przedsięwzięcia Format planu przedsięwzięciaProces panowania nad zmianami Formularz żądania zmianyProces rejestrowania testów

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 16 Standardy a biurokracja l Inżynierowie oprogramowania czasem uważają, że standardy są biurokratyczne i nieistotne dla technicznych czynności w trakcie budowania oprogramowania. Jest to szczególnie prawdopodobne wówczas, gdy standardy wymagają wypełniania nudnych formularzy i rejestrowania pracy. l Chociaż inżynierowie ogólnie zgadzają się z koniecznością przestrzegania standardów, często znajdują dobre uzasadnienia nieodpowiedniości standardów do przedsięwzięcia, które realizują.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 17 l Standardy dokumentowania są szczególnie ważne w przedsięwzięciu informatycznym, ponieważ dokumenty są jedynym namacalnym sposobem przedstawiania oprogramowania i procesu tworzenia oprogramowania. l Standaryzowane dokumenty maja podobny wygląd, strukturę i jakość. Ich czytanie i rozumienie powinno być więc łatwiejsze. Standardy dokumentowania

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 18 Typy standardów dokumentowania l Standardy procesu dokumentowania. W takich standardach definiuje się proces, którego należy przestrzegać przy opracowywaniu dokumentów. l Standardy dokumentów. Są to standardy określające strukturę i postać dokumentów. l Standardy wymiany dokumentów. Są to standardy, które umożliwiają upewnienie się, że wszystkie elektroniczne kopie dokumentów są ze sobą zgodne.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 19 Proces tworzenia dokumentów z uwzględnieniem kontroli jakości Opracuj ostateczny projekt Opracuj ostateczny projekt Utwórz matrycę Przejrzyj skład Złóż test Sprawdź ostateczny projekt Sprawdź ostateczny projekt Wykonaj korektę Wykonaj korektę Utwórz wstępny projekt Utwórz wstępny projekt Zrecenzuj projekt Zrecenzuj projekt Uwzględnij komentarze recenzenta Uwzględnij komentarze recenzenta Utwórz wstępny projekt Utwórz wstępny projekt Drukuj egzemplarze Drukuj egzemplarze Etap 1: Tworzenie Etap 2: Dopracowywanie Etap 3: Druk Zaakceptowany dokument

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 20 Jakość procesu i produktu l Podstawowym założeniem zarządzania jakością jest to, że jakość procesu tworzenia oprogramowania ma bezpośredni wpływ na jakość dostarczonych produktów. l To założenie pochodzi z systemów produkcji, w których jakość produktu jest ściśle związana z procesem produkcyjnym. l W systemach automatycznej produkcji masowej po osiągnięciu poziomu jakości procesu, jakość produktu jest naturalnie zagwarantowana.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 21 Jakość na podstawie procesu Ulepsz proces Utwórz produkt Zdefiniuj proces Oceń jakość produktu Oceń jakość produktu Opracuj standard procesu Opracuj standard procesu Odpowiednia jakość ? Nie Tak

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 22 Jakość tworzenia oprogramowania Jakość procesu jest szczególnie ważna przy tworzeniu oprogramowania. Przyczyną tego jest to, że np. trudno jest ocenić zdatność do pielęgnacji, bez użytkowania tego oprogramowania przez dłuższy okres. Poprawa jakości polega na znalezieniu produktów dobrej jakości, zbadaniu procesów użytych do stworzenia tych produktów i następnie uogólnieniu tych procesów tak, aby można było je stosować w wielu rozmaitych przedsięwzięciach. Ze względu na złożoność przedsięwzięć zmiana procesu nie zawsze musi prowadzić do poprawy jakości produktu.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 23 Proces zarządzania jakością obejmuje: l Definiowanie standardów procesów, takich jak sposób przeprowadzania przeglądów, czas ich wykonywania itd. l Monitorowanie procesu tworzenia w celu zapewnienia postrzegania standardów. l Przekazywanie kierownictwu przedsięwzięcia i podmiotowi kupującemu oprogramowanie informacji o procesie budowania oprogramowania.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 24 Planowanie jakości l Planowanie jakości należy rozpocząć we wczesnej fazie procesu budowania oprogramowania. W planie jakości należy ustalić pożądaną jakość produktu i sposób jej oceny. l W planie wskazuje się więc, co faktycznie oznacza „wysoka jakość” oprogramowania. Bez takich definicji różni inżynierowie mogą działać w odwrotnych kierunkach. l W planie jakości należy ustalić wybór standardów firmowych, które są odpowiednie dla konkretnego produktu i procesu tworzenia.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 25 Składowe struktury planu jakości l Określenie produktu l Plany dotyczące produkcji l Opisy procesu l Cele jakościowe l Ryzyko i zarządzanie ryzykiem

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 26 Atrybuty jakościowe oprogramowania BezpieczeństwoZrozumiałość PrzenośnośćZabezpieczenie Zdatność do testowaniaWygoda użytkowania NiezawodnośćZdatność do adaptacji Odporność Łatwość nauczenia się ModularnośćEfektywność SolidnośćZłożoność Zdatność do użycia wielokrotnego

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 27 Kontrolowanie jakości l Kontrola jakości polega na badaniu procesu budowania oprogramowania w celu upewnienia się, że procedury zapewniania jakości i standardy są przestrzegane. l W ramach procesu kontroli jakości wyniki procesu tworzenia oprogramowania sprawdza się względem zdefiniowanych standardów przedsięwzięcia. l Proces kontroli jakości obejmuje oddzielny zbiór procedur i raportów, które należy stosować w takcie budowania oprogramowania. l Te procedury powinny być proste i łatwe do zrozumienia dla inżynierów budujących oprogramowanie.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 28 Podejścia do kontroli jakości l Przeglądy jakości, w trakcie których grupa osób recenzuje oprogramowanie, jego dokumentacje i proces użyty do jego utworzenia. Ich zadaniem jest sprawdzenie, czy przestrzegano standardów przedsięwzięcia oraz czy oprogramowanie i dokumenty są zgodne z tymi standardami. l Automatyczna ocena oprogramowania, w trakcie której pewne programy przetwarzają wyprodukowane oprogramowanie i dokumenty oraz porównują je ze standardami dotyczącymi konkretnego przedsięwzięcia.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 29 Przeglądy jakości l Przeglądy są najczęściej stosowaną metodą zatwierdzania jakości procesu i produktu. l Bierze w nich udział grupa osób badających część lub całość procesu tworzenia oprogramowania, system lub związana z nim dokumentację w poszukiwaniu potencjalnych komplikacji. l Wyniki przeglądu są formalnie spisywane i przekazywane autorowi lub komuś odpowiedzialnemu za usunięcie wykrytych usterek.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 30 Rodzaje przeglądów Rodzaje przeglądówZasadniczy cel Kontrola programuWykrycie szczegółowych błędów w wymaganiach, projekcie lub projektulub kodzie. Taki przegląd należy przeprowadzić na podstawie listy kontrolnej z potencjalnymi błędami. Przeglądy postępuPrzekazanie kierownictwu informacji o całkowitym postępie przedsięwzięcia. Jest to przegląd zarówno procesu, jak i produktu. Dotyczy kosztów, planów i harmonogramów. Przegląd jakościPrzeprowadzanie technicznej analizy komponentów produktu lub dokumentacji w celu znalezienia niezgodności między specyfikacją, projektem, kodem i dokumentacją komponentu oraz upewnienia się, że przestrzegano zdefiniowanych standardów jakości.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 31 Miernictwo oprogramowania i miary l Miernictwo oprogramowania polega na wyznaczaniu wartości pewnych atrybutów produktu programowego lub procesu budowania oprogramowania. l Porównując te wartości między sobą oraz ze standardami stosowanymi w całej firmie, można wyciągnąć wnioski o jakości oprogramowania lub procesu tworzenia oprogramowania.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 32 Przykład l Przypuśćmy na przykład, że przedsiębiorstwo zamierza wprowadzić nowe narzędzie programowe do testowania. Przed wdrożeniem tego narzędzia można rejestrować liczbę defektów oprogramowania wykrytych w ustalonym czasie. Po wdrożeniu proces ten powtarza się. Jeśli po wdrożeniu narzędzia w okresie o tej samej długości wykryje się więcej defektów, to można wywnioskować, że to narzędzie skutecznie wspiera proces zatwierdzania oprogramowania.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 33 Miary kontrolne i predykcyjne Pomiary kontrolne Pomiary kontrolne Pomiary predykcyjne Pomiary predykcyjne Produkt programowy Produkt programowy Proces tworzenia oprogramowania Proces tworzenia oprogramowania Decyzje menedżerskie Decyzje menedżerskie

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 34 Związki między atrybutami zewnętrznymi I i wewnętrznymi oprogramowania Wygoda użytkownika Przenośność Niezawodność Zdatność do pielęgnacji Zdatność do pielęgnacji Liczba parametrów procedur Liczba parametrów procedur Złożoność cykliczna Wielkość programu w wierszach kodu Wielkość programu w wierszach kodu Liczba komunikatów o błędach Liczba komunikatów o błędach Wielkość podręcznika użytkownika Wielkość podręcznika użytkownika

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 35 Proces pomiaru produktu Wybierz pomiary do wykonania Wybierz pomiary do wykonania Wybierz pomiary do wykonania Wybierz pomiary do wykonania Wybierz pomiary do wykonania Wybierz pomiary do wykonania Wybierz pomiary do wykonania Wybierz pomiary do wykonania Wybierz pomiary do wykonania Wybierz pomiary do wykonania

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 36 Główne etapy procesu pomiaru produktu l Wybierz pomiary do wykonania l Wybierz komponenty do oceny l Zmierz właściwości komponentu l Zidentyfikuj anomalie w pomiarach l Zanalizuj komponenty z anomaliami

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 37 Miary produktowe l Miary produktowe dotyczą właściwości samego oprogramowania. l Atrybuty oprogramowania, które można łatwo zmierzyć, takie jak rozmiar i złożoność cykliczna, nie są w jasny i uniwersalny sposób związane z atrybutami jakościowymi, takimi jak zrozumiałość i zdatność do pielęgnacji. l Firmy zainteresowane pomiarami musza zgromadzić historyczne dane w bazie danych. Można jej użyć do odkrywania związków atrybutami produktu programowego i aspektami jakości ważnymi dla firmy.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 38 l Miary dynamiczne, które gromadzi się przez pomiary wykonującego się programu. l Miary statyczne, które gromadzi się przez pomiary reprezentacji systemu, takich jak projekt, program i dokumentacja. Klasy miar produktywności

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 39 Miary produktów programowych Miara oprogramowania Opis ObciążenieObciążenie wejściowe to liczba funkcji, które wywołują pewną inną funkcję wejściowe(nazwijmy ją X). Obciążenie wejściowe to liczba funkcji wywoływanych przez i wyjściowe funkcję X. Duża wartość obciążenia wejściowego oznacza, że funkcja X jest silnie powiązana z resztą projektu, więc zmiany w funkcji X będą miały intensywne kaskadowe efekty. Dużą wartość obciążenia wejściowego oznacza, że ogólna złożoność funkcji X jest duża z powodu logiki sterowania niezbędnego do koordynacji wywoływanych komponentów. Długość koduTo miara wielkości programu. Na ogół im większy jest rozmiar kodu komponentu programu, tym jest on bardziej złożony i prawdopodobnie zawiera więcej błędów. Złożoność cyklicznaTo miara złożoności sterowania programu. Złożoność sterowania można powiązać ze zrozumiałością programu. DługośćTo wynik pomiaru średniej długości różnych identyfikatorów w programie. Im identyfikatorówdłuższe są identyfikatory, tym większe jest prawdopodobieństwo, że są znaczące, a to oznacza większą zrozumiałość programu. GłębokośćTo wynik pomiaru głębokości zagnieżdżenia instrukcji warunkowych w zagnieżdżeniaprogramie. Głęboko zagnieżdżone instrukcje if są trudne do zrozumienia i warunkowegoprawdopodobnie zwierają błędy. Indeks FogaTo wynik pomiaru średniej długości słów i zdań w dokumentach. Im większa jest wartość indeksu Foga, tym trudniej jest zrozumieć dokument.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 40 Miary obiektowe Miara obiektowaOpis Wysokość Jest liczbą poziomów drzewa dziedziczenia, w którym podklasy dziedziczą drzewaatrybuty i operacje (metody) po nadklasach. Im wyższe jest drzewo dziedziczeniadziedziczenia, tym projekt jest bardziej skomplikowany, ponieważ żeby zrozumieć klasy obiektów będące liśćmi tego drzewa, trzeba potencjalnie zrozumieć wiele innych klas obiektów. Obciążenie Są pośrednio związane z obciążeniami wejściowymi i wyjściowymi opisanymi wejściowe ina rysunku. W zasadzie oznaczają to samo. Czasem warto jednak odróżnić wyjściowe metodwywołania z innych metod w ramach tego samego obiektu od wywołań z metod zewnętrznych. Waga metodJest to liczba w klasie ważona złożonością każdej metody. Prosta metoda ma w klasiezłożoność 1. Wielka i złożona metoda może mieć tę wartość znacznie większą im jest większa wartość tej miary, tym klasy obiektów są bardziej złożone. Złożone obiekty będą prawdopodobnie mało zrozumiałe. Mogą nie być logicznie spójne, nie będzie więc możliwe ich skutecznie wielokrotnie użycie w roli nadklas w drzewie dziedziczenia. Liczba unieważ-Jest to liczba operacji nadklasy, które unieważniono w podklasie. Duża wartość nianych operacjioznacza, że nadklasa nie jest odpowiednim przodkiem dla tej podklasy.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 41 Analiza pomiarów l Jednym z problemów związanych z gromadzeniem ilościowym danych na temat oprogramowania i przedsięwzięć informatycznych jest zrozumienie, co te dane naprawdę oznaczają. l Łatwo jest niewłaściwie zinterpretować dane i wyciągnąć niepoprawne wnioski. l Pomiary trzeba starannie zanalizować, żeby zrozumieć, co oznaczają.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 42 Główne tezy l Zarządzanie jakością oprogramowania polega na zapewnieniu, że oprogramowanie ma małą liczbę defektów i że spełnia wymagane standardy zdatności do pielęgnacji, niezawodności, przydatności, itd. Czynności zarządzania jakością obejmują zapewnienie jakości, tzn. ustalenie standardów budowania oprogramowania, planowanie jakości i kontrolę jakości, tzn. sprawdzenie, czy oprogramowanie spełnia zdefiniowane standardy. l W firmowym podręczniku jakości należy udokumentować zbiór procedur zapewnienia jakości. Jego podstawą może być ogólny model zaproponowany w standardach ISO l Standardy oprogramowania są ważne dla zapewnienia jakości, ponieważ stanowią wskazanie „najlepszych zwyczajów”.

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 24Slide 43 Główne tezy l Przeglądy wyników procesu tworzenia oprogramowania są najczęściej stosowaną metodą oceny jakości. l Pomiary oprogramowania mogą służyć do gromadzenia ilościowych danych o oprogramowaniu i procesie budowania oprogramowania. Zebrane wyniki pomiarów można wykorzystać do wyciągania wniosków o jakości produktu i procesu. l Miary jakości produktu są szczególnie przydatne do wykrywania anomalnych komponentów, w których występują kłopoty z jakością. Te komponenty należy później szczegółowo zanalizować. l Nie ma standardowych ani uniwersalnych miar oprogramowania. Firmy muszą wybrać miary i analizować wyniki na podstawie lokalnej wiedzy i warunków.