Przed rozważeniem standardów jakości oprogramowanie, musisz najpierw omówić ogólne problemy dotyczące jakości każdego rodzaju produktu. Zagadnienia ogólne obejmują definicje i terminologię z danej dziedziny, podstawowe pojęcia dotyczące jakości, rolę dokumentacji w zapewnianiu jakości produktu oraz wybór i stosowanie międzynarodowych standardów jakości. Oczywiście głównymi normami w dziedzinie jakości stały się międzynarodowe normy serii ISO 9000, opracowane przez Międzynarodową Organizację Normalizacyjną. Kolejny podrozdział dotyczy ogólnych zagadnień wymienionych powyżej w świetle serii norm ISO 9000.

1.1 Podstawowe postanowienia serii ISO 9000

Po pierwsze, seria ISO 9000 odnosi się do wszystkich norm międzynarodowych opracowanych przez Komitet Techniczny 176 Międzynarodowej Organizacji Normalizacyjnej (ISO), Zarządzanie Jakością i Zapewnienie Jakości. Seria zawiera obecnie wszystkie normy międzynarodowe 9000 do 9004 (w tym wszystkie części ISO 9000 i ISO 9004), 10001 do 10020 (w tym wszystkie części) oraz ISO 8402. Poniżej podano nazwy głównych norm, które składają się na tę serię.

ISO 9000-1-94 Standardy zarządzania jakością i zapewnienia jakości. Część 1. Wytyczne doboru do aplikacji.

ISO 9000-2-93 Standardy zarządzania jakością i zapewnienia jakości. Część 2. Ogólne wytyczne dotyczące stosowania norm ISO 9001, ISO 9002 i ISO 9003.

ISO 9000-3-91 Standardy zarządzania jakością i zapewnienia jakości. Część 3. Wytyczne dotyczące stosowania ISO 9001 w rozwoju, dostawie i utrzymaniu oprogramowania.

ISO 9000-4-93 Standardy zarządzania jakością i zapewnienia jakości. Część 4. Wytyczne dotyczące zarządzania ogólnym programem niezawodności.

ISO 9001-94 Systemy jakości. Model zapewnienia jakości w projektowaniu, rozwoju, produkcji, instalacji i serwisie.

ISO 9002-94 Systemy jakości. Model zapewnienia jakości w produkcji, instalacji i serwisie.

ISO 9003-94 Systemy jakości. Model zapewnienia jakości w kontroli gotowego produktu i końcowych testach.

ISO 9004-1-94 Zarządzanie jakością i elementy systemu jakości. Część 1. Wytyczne.

ISO 9004-2-91 Zarządzanie jakością i elementy systemu jakości. Część 2. Wytyczne dla usług.

ISO 9004-3-93 Zarządzanie jakością i elementy systemu jakości. Część 3. Wytyczne dotyczące materiałów przetworzonych.

ISO 9004-4-93 Zarządzanie jakością i elementy systemu jakości. Część 4. Wytyczne do poprawy jakości.

ISO 10011-1-90 Systemy jakości. Wytyczne dotyczące audytów. Część 1. Kontrole.

ISO 10011-2-91 Systemy jakości. Wytyczne dotyczące audytów. Część 2. Kryteria kwalifikacji biegłych rewidentów systemów jakości.

ISO 10011-3-91 Systemy jakości. Wytyczne dotyczące audytów. Część 3. Administracyjne zarządzanie programami audytu.

ISO 10012-1-92 Zapewnienie jakości wyposażenia pomiarowego. Wymagania. Część 1. Systemy wspomagania metrologicznego aparatury pomiarowej.

Podręczniki jakości ISO 10013. Przepisy dotyczące rozwoju. (Na etapie publikacji).

ISO 8402-94 Zarządzanie jakością i zapewnienie jakości. Słownik.

Wzmożona konkurencja między organizacjami, producentami produktów, w tym oprogramowania, prowadzi do stawiania bardziej rygorystycznych wymagań dotyczących jakości tych produktów. Aby być konkurencyjnym, organizacje muszą wdrażać skuteczne systemy, które prowadzą do lepszej jakości produktów i większego zadowolenia klientów. Prawidłowo sformułowane i kompletne wymagania klienta zawarte w specyfikacjach technicznych nie gwarantują jeszcze, że wymagania te zostaną w pełni spełnione, ponieważ istnieją niedociągnięcia w systemie zaopatrzenia i wsparcia organizacji. Ta uwaga doprowadziła do opracowania norm związanych z systemami jakości i uzupełniających wymagania klientów dotyczące produktów. Normy międzynarodowe z serii ISO 9000 mają na celu zapewnienie wspólnych ram dla norm systemu jakości. Przez system jakości rozumie się, zgodnie z ISO 8402, całość struktury organizacyjnej, metod, procesów i zasobów niezbędnych do całościowego zarządzania jakością produktów wytwarzanych przez organizację.

System zarządzania jakością organizacji to te aspekty ogólnej funkcji zarządzania stosowane przez organizację, które określają politykę jakości produktów, cele i obowiązki organizacji, a także wdrażają je za pomocą środków planowania, kontrolowania, zapewniania i doskonalenia jakości w ramach systemu jakości. Oprócz celu organizacji, na system zarządzania jakością wpływają jej produkty oraz charakterystyczne dla tej organizacji metody produkcji. Ze względu na to, że metody produkcji organizacji pracujących nawet w tym samym obszarze są różne, a cele organizacji nie zawsze są takie same, systemy jakości tych organizacji nie pokrywają się. Głównym celem systemu zarządzania jakością jest doskonalenie systemów i procesów w celu poprawy jakości produktu.

Seria ISO 9000 określa, jakie elementy powinny być zawarte w systemie jakości, natomiast sama organizacja musi je wdrożyć z uwzględnieniem określonych celów, produktów i procesów, a także konkretnych metod stosowanych przez organizację.

Ponadto wytyczne i wymagania serii ISO 9000 są wyrażone w kategoriach celów systemu jakości, które mają być osiągnięte i nie określają, w jaki sposób cele te mają być osiągnięte, pozostawiając wybór tych sposobów kierownictwu organizacja. Normy z tej serii rozróżniają wymagania dotyczące systemu jakości od wymagań dotyczących produktu klienta. Wymagania systemu jakości są uzupełnieniem specyfikacji produktu. Na przykład ISO 12207 określa cykl życia oprogramowania. Procesy i modele jakości, które są zgodne z procesem zapewniania jakości (2.3 normy ISO 12207) są ustanowione przez serię norm ISO 9000.

ISO 9000-1 identyfikuje cztery ogólne kategorie produktów obejmujące wszystkie rodzaje produktów dostarczanych przez dowolną organizację:

Środki techniczne.

Oprogramowanie.

Materiały przetworzone.

Wymagania systemu jakości określone w normach międzynarodowych serii ISO 9000 mają zastosowanie do wszystkich czterech ogólnych kategorii produktów, ale terminologia oraz niektóre postanowienia i aspekty systemów zarządzania jakością mogą się różnić. Widać to w tytułach norm ISO 9004 - 2 i ISO 9004 - 3. Należy zauważyć, że każda organizacja oferuje produkty co najmniej dwóch kategorii. Na przykład organizacja zajmująca się rozwojem oprogramowania dodatkowo zapewnia swoim klientom usługi konserwacji opracowanego oprogramowania.

Celem wytycznych i wymagań serii norm międzynarodowych ISO 9000 jest spełnienie wymagań z perspektywy czterech aspektów, które są kluczowe dla jakości produktu.

1. Jakość poprzez identyfikację potrzeb klientów na produkty. Pierwszym aspektem jest jakość poprzez definiowanie i ulepszanie produktów w celu spełnienia wymagań i możliwości rynkowych.

2. Jakość poprzez projekt. Drugim aspektem jest jakość poprzez wbudowanie w produkty cech, które pomagają zapewnić, że spełniają one wymagania i możliwości rynku. Innymi słowy, jakość projektu to te właściwości projektu, które wpływają na płynne działanie produktu w różnych warunkach produkcji i zastosowania.

3. Jakość dzięki spójności w projektowaniu. Trzecim aspektem jest jakość ze względu na zachowanie stałej zgodności z projektem, realizację założonych w projekcie cech.

4. Jakość poprzez serwis techniczny. Czwartym aspektem jest jakość poprzez konserwację produktu podczas jego użytkowania w celu utrzymania pożądanych właściwości.

Seria norm ISO 9000 zawiera w całości ogólne wytyczne dotyczące wymagań w zakresie zarządzania i zewnętrznego zapewnienia jakości w czterech wymiarach.

Normy Międzynarodowe z serii ISO 9000 opierają się na założeniu, że cała praca jest wykonywana przez procesy (patrz Rysunek 1). Każdy proces ma czynniki wejściowe. Wynikiem procesu jest rezultat – produkt, namacalny i nienamacalny. Sam proces jest (lub powinien być) transformacją przynoszącą wartość dodaną. W każdym procesie w taki czy inny sposób uczestniczą ludzie i/lub inne zasoby. Wynikiem może być na przykład program, usługa bankowa, gotowy (lub pośredni) produkt dowolnej głównej kategorii produktów. Istnieją możliwości dokonywania pomiarów na wlocie, na różnych etapach procesu, a także na wylocie.

Jak pokazano na rysunku 2, wejścia i wyjścia mogą być kilku typów: związane z produktem (linie ciągłe na rysunku 2) (np. surowce, produkt gotowy) i związane z informacjami (linie przerywane) (np. wymagania dotyczące produktu, specyfikacje informacyjne). Ta liczba reprezentuje procesy dostawcy z procesami poddostawcy i klienta w łańcuchu dostaw. W strukturze tej sieci różne czynniki wejściowe i wyjściowe poruszają się w różnych kierunkach. Termin „produkt” odnosi się tutaj do wszystkich czterech głównych kategorii produktów.

Zarządzanie jakością administracyjną realizowane jest poprzez zarządzanie procesami w organizacji. Sterowanie procesem ma dwie strony:

zarządzanie strukturą i funkcjonowaniem samego procesu, w ramach którego porusza się produkt lub informacja;

zarządzanie jakością produktów lub informacji w strukturze.

Biorąc pod uwagę złożoną strukturę większości organizacji, ważne jest podkreślenie głównych procesów oraz uproszczenie i uszeregowanie procesów w zależności od celów zarządzania jakością. Przykład złożona sieć procesami może być organizacja, która tworzy oprogramowanie zgodnie z ISO/IEC 12207 i DO-178.

Rys.1.1 Cała praca jest wykonywana za pomocą procesów.

Procesy

dostawca

konsument

wymagania

Czynniki wejściowe

Czynniki wyjściowe

Status i charakterystyka

produkty

Status i charakterystyka

produkty

wymagania

Sprzężenie zwrotne

Sprzężenie zwrotne

poddostawca

Rysunek 1.2 Relacja procesów w sieci dostaw w obecności przepływów związanych z produktami i informacjami.

Każda organizacja musi zdefiniować, ustanowić i zarządzać swoją siecią procesów i interfejsów. Organizacja tworzy, ulepsza i utrzymuje stały poziom jakości swoich produktów poprzez sieć procesów. Jest to koncepcyjna podstawa serii norm ISO 9000. Procesy i ich interfejsy powinny podlegać analizie i ciągłemu doskonaleniu w celu zapewnienia jakości wytwarzanych produktów.

Podczas oceny systemów jakości dowolnej organizacji ISO 9000-1 zaleca zadanie trzech ważnych pytań dotyczących każdego procesu w ocenianej sieci.

Czy te procesy są zdefiniowane, a ich procedury udokumentowane?

Czy te procesy są w pełni stosowane i są objęte dokumentacją?

Czy te procesy są skuteczne w osiąganiu oczekiwanych rezultatów?

Wynikiem oceny jest zestaw odpowiedzi na te pytania, związanych odpowiednio z podejściem, zastosowaniem i wynikiem. Ocena systemu jakości może różnić się w badanym obszarze i obejmować różne działania.

Jednym z najważniejszych rodzajów takich działań, realizowanych systematycznie, jest ocena stanu i adekwatności systemu jakości, realizowana przez kierownictwo organizacji zgodnie z ISO 9001, 9002, 9003. Wnioski wyciągnięte w procesie ocena systemu jakości powinna prowadzić do wzrostu jego efektywności i oszczędności. Źródłem informacji do takich wniosków są również wyniki audytów wewnętrznych i zewnętrznych systemu jakości.

Wewnętrzne kontrole jakości przeprowadzane przez samą organizację (pierwsza strona) dostarczają informacji do skutecznego przeglądu zarządzania oraz działań korygujących, zapobiegawczych i doskonalących.

Audyty zewnętrzne prowadzone przez klientów wyrobów (strona druga) oraz organy niezależne (strony trzecie) zapewniają zaufanie klienta do dostawcy i uzyskanie certyfikacji, a tym samym zapewnienie zaufania do szeregu potencjalnych klientów wyrobów organizacji.

Należy również zwrócić uwagę na sytuacje, w których można zastosować serię norm ISO 9000 oraz na to, jak ta seria jest wykorzystywana przez dostawcę.

Normy Międzynarodowe z serii ISO 9000 mają zastosowanie w następujących czterech sytuacjach.

1. Jako wytyczna dla zarządzania jakością. System jakości w tej sytuacji musi poprawić swoją efektywność, aby w ekonomiczny i optymalny sposób spełnić wymagania jakościowe produktu.

2. W zakresie zawarcia umowy między pierwszą a drugą stroną. W takiej sytuacji klient wymaga, aby określone elementy i procesy systemu jakości stały się częścią systemu jakości dostawcy, określając konkretny model zapewnienia jakości.

3. Po zatwierdzeniu lub zarejestrowaniu przez drugą stronę. Jest to sytuacja, w której system jakości jest oceniany przez klienta. Dostawca może zostać oficjalnie uznany za zgodnego z normą.

4. W przypadku certyfikacji lub rejestracji przez stronę trzecią. W tej sytuacji system jakości jest oceniany przez jednostkę certyfikującą, a organizacja zgadza się na utrzymanie takiego systemu jakości dla wszystkich konsumentów swoich produktów.

Dostawca może wybrać jeden z dwóch sposobów wykorzystania serii norm ISO 9000: „sposób motywowany przez kierownictwo” i „sposób motywowany przez interesariuszy”. Druga metoda jest uważana za najczęstszą.

Stosując metodę motywowaną przez interesariuszy, dostawca początkowo wprowadza system jakości w odpowiedzi na natychmiastowe wymagania klienta. System jakości musi być zgodny z wymaganiami ISO 9001, 9002, 9003. Kierownictwo organizacji odgrywa w tej metodzie wiodącą rolę, ale siłą napędową jest zewnętrzny interesariusz (klienci).

Stosując podejście motywowane zarządzaniem, to kierownictwo organizacji zaczyna podejmować wysiłki w celu identyfikacji przyszłych potrzeb i trendów rynkowych. Wytyczne dotyczące początkowego ustanowienia systemu jakości, który poprawia jakość produktu, to ISO 9004-1 (i inne części ISO 9004). Dostawca może następnie zastosować ISO 9001, 9002 lub 9003 jako model zapewnienia jakości w celu wykazania adekwatności systemu jakości w celu uzyskania certyfikacji. Wdrożony w ten sposób system jakości jest bardziej pojemny i owocny niż ten wdrożony w pierwszy sposób.

Seria norm ISO 9000 zwraca szczególną uwagę na przygotowanie i wykorzystanie dokumentacji jako działania, które dodaje wartości. Odpowiednia dokumentacja odgrywa znaczącą rolę w następujących działaniach związanych z zapewnieniem jakości:

w osiągnięciu wymaganej jakości produktu;

ocena systemów jakości;

w poprawie jakości;

utrzymanie osiągniętego poziomu jakości.

Podczas przeglądów wewnętrznych i zewnętrznych dokumentacja procedur wskazuje, że procesy są zdefiniowane, procedury są zatwierdzone i znajdują się pod kontrolą. Tylko w takich okolicznościach audyty mogą zapewnić pełną ocenę adekwatności zastosowania i wdrożenia sieci procesów organizacji.

Ponadto dokumentacja odgrywa ważną rolę w poprawie jakości produktu. Jeżeli procedury są udokumentowane, stosowane i przestrzegane, możliwe jest określenie sposobu ich wykonywania.

Ponadto bardziej szczegółowo zostanie rozważona norma ISO 9001, która definiuje model zapewnienia jakości w projektowaniu, rozwoju, produkcji, instalacji i serwisie wszystkich rodzajów produktów, w tym oprogramowania.

Jakość oprogramowania jest stałym problemem inżynierii oprogramowania i jest omawiany w wielu dziedzinach wiedzy.

• Phil Crosby: Jakość polega na spełnianiu wymagań użytkowników.
• Waty Hempfrey: Jakość polega na osiągnięciu doskonałego poziomu użyteczności.
• Firma IBM: wprowadził do obiegu wyrażenie „jakość zorientowana na rynek”.
• Kryterium Baldridge'a:„Jakość zorientowana na klienta”.
• System Zarządzania Jakością ISO 9001: Jakość to stopień, w jakim nieodłączne cechy spełniają wymagania.

Akceptowalna jakość Czy pożądany stopień doskonałości tworzonego produktu (usługi) jest w stanie zadowolić użytkowników i jest osiągalny w ramach określonych ograniczeń projektowych.

Jakość w działaniach projektowych:

• Zarządzanie wymaganiami („atrybuty jakości” jako kategoria wymagań niefunkcjonalnych);
• Testowanie (tzw. średni czas między awariami, takie metryki jak MTTF - Mean Time To Failure, czyli średni czas między wykrytymi awariami systemu itp.).

„Dopuszczalna jakość” można porównać z poziomem usług w ramach określonej umowy SLA - Service Level Agreement. Oznacza to, że akceptowalną jakość można uznać za<количественно выраженный>kompromis między klientem a wykonawcą w zakresie właściwości produktu stworzonego przez wykonawcę w interesie<решения задач>klienta, biorąc pod uwagę inne ograniczenia projektowe (w szczególności koszt, który często określany jest jako „koszt jakości”).

Rysunek „Obszar wiedzy — Jakość oprogramowania”

Rysunek „Model systemu zarządzania jakością”

Podstawy jakości oprogramowania

Osiągnięte porozumienie w sprawie wymagań jakościowych (w oryginale - wymagania jakościowe) wraz z jasnym przesłaniem dla inżynierów, czym jest jakość<получаемого продукта>wymagają dyskusji i formalnego zdefiniowania wielu aspektów jakości.

Inżynierowie muszą rozumieć konsekwencje jakości, właściwości i znaczenia jakości w odniesieniu do opracowywanego lub utrzymywanego oprogramowania.

Ważną ideą jest to, że wymagania dotyczące oprogramowania definiują wymagane cechy jakościowe oprogramowania, a także wpływają na metody kwantyfikacji i formułowane w celu oceny tych cech.<соответствующие>kryteria przyjęcia.

Kultura i etyka inżynierii oprogramowania (kultura i etyka inżynierii oprogramowania)

Oczekuje się, że inżynierowie oprogramowania będą postrzegać problemy z jakością oprogramowania jako część swoich<профессиональной>kultura.
Względy etyczne mogą odgrywać znaczącą rolę w zapewnianiu jakości oprogramowania, kulturze inżynierskiej i postawach.<к своей работе>... IEEE Computer Society i ACM opracowały kodeks etyki i praktyki zawodowej oparty na ośmiu zasadach, które pomagają inżynierom wzmocnić ich podejście do jakości i niezależności.<в решении вопросов обеспечения достойного качества создаваемых программных продуктов>w codziennej pracy.

Wartość i koszty jakości

Pojęcie „jakości” w rzeczywistości nie jest tak oczywiste i proste, jak mogłoby się wydawać na pierwszy rzut oka. W przypadku każdego produktu inżynieryjnego jest ich wiele<интерпретаций>jakość, w zależności od konkretnego „układu współrzędnych”. Wiele z tych punktów widzenia należy omówić i zdefiniować na etapie opracowywania wymagań dla oprogramowania. Cechy jakościowe mogą być wymagane w różnym stopniu, mogą być nieobecne lub mogą narzucać pewne wymagania, z których wszystkie mogą być wynikiem pewnych kompromisów.

Koszt jakości można podzielić na:

• koszt ostrzeżenia<дефектов>(koszt prewencji),
• koszt wyceny,
• koszt awarii wewnętrznej,
• koszt awarii zewnętrznej.

Siła napędowa projekty programowe to chęć tworzenia oprogramowania, które ma pewną wartość. Wartość oprogramowania może, ale nie musi być wyrażona w kategoriach wartości. Klient zazwyczaj ma własny pomysł na maksymalny koszt inwestycji, który ma się zwrócić w przypadku osiągnięcia głównych celów rozwoju oprogramowania. Klient może mieć również pewne oczekiwania co do jakości oprogramowania. Czasami klienci nie myślą o problemach z jakością i związanych z nimi kosztach. Czy cechy jakościowe są czysto dekoracyjne, czy nadal stanowią integralną część oprogramowania? Odpowiedź jest prawdopodobnie gdzieś pośrodku, jak to prawie zawsze ma miejsce w takich przypadkach, i jest przedmiotem dyskusji na temat stopnia zaangażowania klienta w proces podejmowania decyzji oraz pełnego zrozumienia przez klienta kosztów i korzyści z tym związanych. z osiągnięciem określonego poziomu jakości. W idealnym przypadku większość z tych decyzji powinna zostać podjęta podczas procesu wymagań, jednak kwestie te mogą być poruszane przez cały czas koło życia oprogramowanie. Nie ma<“стандартных”>zasady, jak dokładnie należy podejmować takie decyzje. Jednak inżynierowie muszą być w stanie wyobrazić sobie różne alternatywy i ich koszty.

Modele i charakterystyka jakości

ISO / IEC definiuje trzy powiązane modele jakości oprogramowania (ISO 9126-01 Inżynieria oprogramowania - Jakość produktu, Część 1: Model jakości):

• jakość wewnętrzna,
• jakość zewnętrzna i
• jakość podczas eksploatacji, a także zestaw odpowiednich prac do oceny jakości oprogramowania (ISO14598-98 Software Product Evaluation).

Jakość procesu inżynierii oprogramowania

Zarządzanie jakością i jakość procesu inżynierii oprogramowania są bezpośrednio związane z jakością tworzonego oprogramowania.

Istnieją dwa główne standardy jakości oprogramowania.

• ZaznaczIT- dotyczy rozważania wspólny system zarządzanie jakością ISO 9001-00 stosowane do projektów oprogramowania.
• Kolejnym ważnym standardem jest CMMI omówione w Obszarze Wiedzy o Procesie Inżynierii Oprogramowania zawiera zalecenia dotyczące usprawnienia procesu. Obszary procesowe (obszary kompetencji) CMMI są bezpośrednio związane z zarządzaniem jakością:
  • zapewnienie jakości procesu i produktu (kategoria procesu CMMI „Wsparcie”),
  • weryfikacja (weryfikacja, kategoria „Inżynieria”) oraz
  • certyfikacja (walidacja, kategoria „Inżynieria”).

W tym samym czasie CMMI klasyfikuje przejrzeć oraz rewizja jako metody weryfikacji, ale nie jako niezależne procesy.

Normy te są jednak uważane za komplementarne, a certyfikacja ISO 9001 pomaga w osiągnięciu wyższych poziomów dojrzałości CMMI.

Jakość oprogramowania

Przede wszystkim inżynierowie muszą określić cel tworzenia oprogramowania. W tym kontekście szczególnie ważne jest, aby pamiętać, że wymagania klienta są nadrzędne i zawierają wymagania dotyczące jakości, a nie tylko funkcjonalności (wymagania funkcjonalne). Inżynierowie są zatem odpowiedzialni za wydobycie wymagań jakościowych, które nie zawsze są wyraźnie przedstawione, oraz omówienie ich znaczenia i trudności w ich osiągnięciu. Wszystkie procesy związane z jakością (np. montaż, kontrola i poprawa jakości) muszą być zaprojektowane z myślą o tych wymaganiach i ponosić ciężar dodatkowych kosztów (jak ważne część składowa koszt oprogramowania).

ISO 9126-01 (Inżynieria oprogramowania - Jakość produktu, Część 1: Model jakości) definiuje, dla dwóch z trzech opisanych w nim modeli, powiązane cechy i „podcharakterystyki” jakości, a także metryki przydatne do oceny jakości oprogramowania.

Rozumienie terminu „produkt” zostało rozszerzone, aby objąć wszystkie artefakty generowane jako dane wyjściowe we wszystkich procesach wykorzystywanych do tworzenia końcowego produktu oprogramowania. Przykładami produktów są (ale nie ograniczają się do):

• kompletna specyfikacja wymagań systemowych,
• specyfikacja wymagań programowych dla komponentów programowych systemu (specyfikacja wymagań programowych, SRS),
• modele,
• dokumentacja testowa,
• raporty generowane w wyniku prac analizy jakości.

Chociaż termin jakość jest najczęściej używany w odniesieniu do produktu końcowego i zachowania systemu podczas pracy, dobrą praktyką inżynierską jest wymaganie, aby zgodność z celami jakości była oceniana dla wyników pośrednich / produktów w cyklu życia we wszystkich procesach inżynierii oprogramowania.

Polepszanie jakości

Jakość oprogramowania można poprawić poprzez iteracyjny proces ciągłego doskonalenia. Wymaga to kontroli, koordynacji i sprzężenie zwrotne w procesie zarządzania wieloma równolegle prowadzonymi procesami:

1. procesy cyklu życia,
2. proces wykrywania, eliminowania i zapobiegania awariom/wadom oraz
3. procesy poprawy jakości.

Teorie i koncepcje mają zastosowanie w inżynierii oprogramowania, podstawowa poprawa jakości. Na przykład zapobieganie i wczesne diagnozowanie błędów, ciągłe doskonalenie i koncentracja na kliencie stanowią zasadę „budowania w jakość”. Koncepcje te opierają się na pracy ekspertów ds. jakości, którzy doszli do przekonania, że ​​jakość produktu jest bezpośrednio związana z jakością procesów wykorzystywanych do jego tworzenia.

Podejścia takie jak TQM(całkowite zarządzanie jakością) i PDCA(Zaplanuj, Wykonaj, Sprawdź, Działaj - Planuj, Działaj, Sprawdzaj, Reaguj/Dostosuj) są narzędziami do osiągania celów jakościowych. Wsparcie zarządzania pomaga w realizacji procesów, ocenie produktów i pozyskiwaniu wszystkich niezbędnych danych. Ponadto opracowywany program doskonalenia jest zwykle ukierunkowany i obejmuje pracę działu lub organizacji jako całości) i szczegółowo określa wszystkie działania i projekty do poprawy.<отдельных аспектов деятельности>w określonym czasie, w którym takie projekty mogą być realizowane z pomyślnym rozwiązaniem odpowiednich zadań. Jednocześnie wsparcie kierownictwa oznacza, że ​​wszystkie projekty doskonalenia mają wystarczające zasoby, aby osiągnąć swoje cele. Wsparcie kierownictwa jest ściśle związane z realizacją aktywnej interakcji w zespole i powinno zapobiegać powstawaniu potencjalnych problemów (oraz biernego lub nawet aktywnego sprzeciwu wobec realizacji programu doskonalenia lub jego poszczególnych projektów). Tworzenie grup roboczych, wsparcie managerów średniego szczebla oraz dedykowane zasoby na poziomie projektu są omawiane w Obszarze Wiedzy Procesowej Inżynierii Oprogramowania.

Procesy jakości oprogramowania

Zarządzanie jakością oprogramowania (SQM) dotyczy wszystkich aspektów procesów, produktów i zasobów. SQM definiuje procesy, właścicieli procesów, a także wymagania dotyczące procesów, pomiary procesów i ich wyników, plus - kanały zwrotne.

Procesy zarządzania jakością obejmują wiele czynności. Niektóre z nich pozwalają bezpośrednio znaleźć defekty, inne pomagają dokładnie określić, gdzie może być ważne przeprowadzenie bardziej szczegółowych badań, po czym ponownie prowadzone są prace mające na celu bezpośrednie wykrycie błędów. Wiele działań można również prowadzić, aby osiągnąć zarówno te, jak i inne cele.

Planowanie jakości oprogramowania obejmuje:

1. Określenie wymaganego produktu pod względem cech jakościowych.
2. Planowanie procesów uzyskania wymaganego produktu.

Procesy te różnią się od procesów SQM per se, które z kolei mają na celu ocenę planowanych cech jakościowych, a nie rzeczywistą realizację tych planów. Procesy zarządzania jakością powinny dotyczyć kwestii, w jakim stopniu produkt spełni potrzeby klientów i interesariuszy, będzie miał wartość dla klienta i interesariuszy oraz będzie miał jakość wymaganą do spełnienia określonych wymagań dotyczących oprogramowania.

SQM można wykorzystać do oceny zarówno produktów końcowych, jak i pośrednich. Niektóre ze specjalistycznych procesów SQM są zdefiniowane w standardzie 12207:

• Proces zapewniania jakości;
• Proces weryfikacji;
• Proces walidacji;
• Wspólny proces przeglądu;
• Proces audytu

Wszystkie te procesy wspierają dążenie do jakości, a dodatkowo pomagają w poszukiwaniu możliwe błędy... Różnią się jednak tym, na czym się skupiają.

Procesy SQM składają się z zadań i technik, zaprojektowany w celu oceny, w jaki sposób plany oprogramowania są rozpoczynane i jak dobrze produkty pośrednie i końcowe spełniają określone wymagania. Wyniki tych zadań są raportowane menedżerom przed podjęciem odpowiednich działań naprawczych. Proces SQM jest zarządzany z pewnością, że dane raportowania są dokładne.
Jak opisano w tym obszarze wiedzy, procesy SQM są ze sobą ściśle powiązane. Mogą się nakładać, a czasem nawet nakładać. Wydają się mieć charakter reaktywny, ponieważ postrzegają procesy w kontekście otrzymanej praktyki i już wytworzonych produktów. Odgrywają one jednak główną rolę na etapie planowania, będąc proaktywnymi procesami i procedurami potrzebnymi do osiągnięcia cech i poziomów jakości wymaganych przez interesariuszy.<проекта>oprogramowanie.

Zarządzanie ryzykiem może również odgrywać znaczącą rolę w dostarczaniu wysokiej jakości oprogramowania. Włączenie „regularnej” (jako stałej, a nie okresowej; w oryginale – zdyscyplinowanej) analizy ryzyka oraz<соответствующих>technik kontroli<рисками>w procesach cyklu życia oprogramowania może zwiększyć potencjał wytwarzania produktu wysokiej jakości. Więcej dokładna informacja do zarządzania ryzykiem można znaleźć w Strefie Wiedzy Zarządzania Inżynierią Oprogramowania.

Zapewnienie jakości oprogramowania (SQA)

Procesy SQA dostarczyć potwierdzenie, że oprogramowanie i procesy cyklu życia projektu spełniają określone wymagania. Takie potwierdzenie odbywa się na podstawie planowania (planowania), ustawiania<работ>(odgrywanie) i wykonywanie (wykonywanie) zestawu działań mających na celu uczynienie z jakości integralnej części oprogramowania.
Taki pogląd implikuje jasne i precyzyjne sformułowanie problemu, a także fakt, że wymagania dotyczące odpowiedniego<программному>decyzja. SQA zobowiązuje się do zapewnienia jakości w procesie rozwoju i utrzymania poprzez wykonywanie różnorodnych działań na wszystkich etapach<жизненного цикла>, który pozwala zidentyfikować problemy na wczesnym etapie, które są prawie nieuniknione w każdej złożonej działalności.

Zarządzanie ryzykiem to poważne dodatkowe narzędzie do zapewniania jakości oprogramowania.

SQA w sformułowaniu SWEBOK skupia się na procesach. Rolą SQA jest zapewnienie odpowiedniego zaplanowania procesów, ich kontynuacji w oparciu o wcześniej ustalony plan oraz wykonanie niezbędnych pomiarów procesów i przekazanie wyników pomiarów zainteresowanym stronom (strukturom organizacyjnym i osobom prywatnym).

Plan SQA definiuje środki, które zostaną zastosowane w celu zapewnienia, że ​​opracowywany produkt spełnia określone wymagania użytkownika z najwyższym możliwym poziomem jakości przy danych ograniczeniach projektowych.

Aby to osiągnąć, konieczne jest przede wszystkim jasne zdefiniowanie i zrozumienie celów jakościowych (a także jednoznaczna interpretacja, co jest warunek wstępny wszelkie cele i związane z nimi wymagania). To bez wątpienia powinno znaleźć odzwierciedlenie w odpowiednich planach zarządzania.<проектом>, rozwój i utrzymanie.

Konkretne zadania związane z pracą i zapewnieniem jakości są ustrukturyzowane, wyszczególniając wymagania dotyczące ich kosztów i powiązanych zasobów, celów w zakresie zarządzania i odpowiedniego harmonogramu w kontekście celów określonych w planach zarządzania, rozwoju i utrzymania. Plan SQA określa dokumenty, standardy, praktyki i konwencje, które będą stosowane do nadzorowania projektu oraz sposób weryfikacji i monitorowania tych aspektów w celu zapewnienia, że ​​są one odpowiednie i spójne z określonym planem.
Plan SQA określa mierniki, techniki statystyczne, procedury zgłaszania problemów i podejmowania działań naprawczych, takich jak narzędzia, techniki i metodologie, kwestie bezpieczeństwa fizycznego nośnika, szkolenia oraz raportowanie i dokumentacja związana z kwestiami SQA.

Ponadto SQA zajmuje się również kwestiami zapewnienia jakości związanymi z innymi rodzajami działalności opisanymi w:<различных>plany tworzenia oprogramowania, które obejmują również dostawę, instalację, utrzymanie oprogramowania niestandardowego i/lub replikowanego/od ręki rozwiązania programowe(gotowy do użytku komercyjnego, COTS) wymagany dla tego projektu oprogramowania. Plan SQA może zawierać kryteria akceptacji oprogramowania oraz czynności raportowania i zarządzania niezbędne do zapewnienia jakości.<и контролю над>Pracuje.

Weryfikacja i walidacja (V&V)

Walidacja i weryfikacja oprogramowania to zdyscyplinowane podejście do oceny produktów programowych, które jest stosowane w całym cyklu życia. Wysiłki weryfikacyjne i walidacyjne mają na celu zapewnienie jakości jako integralnej cechy oprogramowania i spełnienia wymagań użytkownika.
V&V zajmuje się bezpośrednio problemami z jakością oprogramowania i stosuje odpowiednie techniki testowe w celu wykrycia określonych defektów. V&V można zastosować do produktów pośrednich, jednak w zakresie, który odpowiada pośrednim „etapom”<соответствующих>procesy cyklu życia.

Proces V&V określa, w jakim stopniu wyrób (wynik) niektórych prac rozwojowych i konserwacyjnych spełnia wymagania sformułowane w ramach tych prac, a finalny wyrób spełnia określone cele i wymagania użytkownika.

Weryfikacja- próba zapewnienia prawidłowego rozwoju produktu (wyrób zbudowany jest we właściwy sposób; zazwyczaj na półprodukt, czasem na produkt końcowy), w tym sensie, że produkt uzyskany w ramach danej działalności spełnia określone specyfikacje w trakcie poprzedniej czynności.
Zaświadczenie- próba zapewnienia stworzenia właściwego produktu (właściwy produkt jest budowany; zwykle w kontekście produktu finalnego), pod kątem osiągnięcia wyznaczonego celu.

Oba procesy – weryfikacja i walidacja- start we wczesnych fazach rozwoju i utrzymania. Zapewniają badania (ekspertyzy) kluczowe możliwości produktu, zarówno w kontekście bezpośrednio poprzedzających wyników (produkty pośrednie), jak i pod względem spełnienia odpowiednich specyfikacji. Celem planowania V&V jest zapewnienie procesom weryfikacji i walidacji niezbędnych zasobów, jasno przypisując role i obowiązki. Powstałe dokumenty planu V&V oraz<детально>opisuje różne zasoby, role i czynności oraz stosowane techniki i narzędzia.
Plan dotyczy również aspektów zarządzania, komunikacji (interakcji), polityk i procedur dotyczących działań weryfikacyjnych i walidacyjnych oraz ich interakcji. Ponadto może odzwierciedlać kwestie zgłaszania usterek i wymagań dokumentacyjnych.

Przegląd i audyty

Pięć rodzajów ocen i audytów:

• Przeglądy zarządzania
• Przeglądy techniczne
• Inspekcje
• Przejścia
• Audyty (audyty)

Recenzje zarządzania

Celem ocen zarządczych jest śledzenie rozwoju<проекта/продукта>, określanie stanu planów i harmonogramów, zatwierdzanie wymagań i przydzielanie zasobów lub ocenianie skuteczności podejść do zarządzania stosowanych do osiągnięcia wyznaczonych celów.

Oceny kierownictwa wspierają decyzje dotyczące wprowadzania zmian i podejmowania działań naprawczych w razie potrzeby podczas realizacji projektu oprogramowania.

Oceny zarządcze określają adekwatność planów, harmonogramów i wymagań, jednocześnie monitorując ich postęp lub niezgodność. Oceny te można przeprowadzać na produkcie, rejestrując je w postaci raportów z audytu, raportów stanu (rozwoju), raportów V&V oraz różne rodzaje plany - zarządzanie ryzykiem projektowym/zarządzanie projektami, zarządzanie konfiguracją, bezpieczeństwo<использования>oprogramowanie (bezpieczeństwo), ocena ryzyka itp.

Recenzje techniczne

Celem ocen technicznych jest zbadanie oprogramowania w celu określenia jego przydatności do zamierzonego zastosowania. Celem jest identyfikacja odchyleń od zatwierdzonych specyfikacji i standardów. Do przeprowadzenia ocen technicznych konieczne jest przypisanie następujących ról: decydent; lider recenzji; rejestrator (rejestrator); a także personel techniczny wspierający (bezpośrednio wykonujący) czynności oceny.

Ocena techniczna wymaga bez wątpienia następujących danych wejściowych:

• Deklaracje celów
• Określony produkt programowy (oceniany)
• Dany plan projektu (plan zarządzania projektem)
• Lista problemów (pytań) związanych z produktem
• Procedury oceny technicznej

Komenda<технической оценки> postępuje zgodnie z zalecaną procedurą oceny. Wykwalifikowane (z technicznego punktu widzenia) osoby prezentują przegląd produktu (reprezentujący zespół programistów). Badanie<продукта> odbywa się na jednym lub kilku spotkaniach (pomiędzy osobami prezentującymi produkt a osobami wystawiającymi ocenę). Ocena techniczna jest zakończona po zakończeniu wszystkich wymaganych czynności badawczych dotyczących produktów.

Inspekcje

Celem inspekcji jest wykrycie i zidentyfikowanie anomalii w oprogramowaniu. Istnieją dwie główne różnice między inspekcjami a ocenami (zarządzającymi i technicznymi):

1. Osoby zajmujące stanowiska kierownicze (kierownicy) w stosunku do któregokolwiek z członków zespołu inspekcyjnego nie powinny brać udziału w inspekcjach.
2. Inspekcja powinna być prowadzona przez bezstronnego (niezależnego od projektu i jego celów) lidera przeszkolonego w zakresie technik inspekcji.

Inspekcja oprogramowania zawsze obejmuje autorów produktu pośredniego lub końcowego, w przeciwieństwie do ocen, które niekoniecznie tego wymagają. Inspekcje (jako tymczasowe jednostki organizacyjne – grupy, zespoły) składają się z lidera, rejestratora, recenzenta oraz kilku (od 2 do 5) inspektorów. Członkowie zespołu inspekcyjnego mogą specjalizować się w różnych obszarach wiedzy (posiadają różne obszary kompetencje), na przykład obszar tematyczny, metody projektowania, język itp. W za ten moment Kontrole (okresu) czasu są przeprowadzane na oddzielnym, małym elemencie produktu (w większości przypadków koncentrując się na poszczególnych cechach funkcjonalnych lub innych; często zaczynając od indywidualnych reguł biznesowych, wymagań funkcjonalnych lub atrybutów jakościowych, przypis autora). Każdy członek zespołu powinien zbadać oprogramowanie i inne dane wejściowe przed spotkaniem kontrolnym, być może stosując pewne techniki analityczne do małych fragmentów produktu lub ogólnie do produktu, biorąc pod uwagę tylko jeden jego aspekt, na przykład interfejsy. Każda znaleziona anomalia powinna być udokumentowana, a informacje przekazane kierownikowi inspekcji. Podczas oględzin prowadzący prowadzi sesję<инспекции>i sprawdza, czy wszystko<члены команды>przygotowany do kontroli.

Powszechnym narzędziem używanym podczas inspekcji jest lista kontrolna zawierająca anomalie i pytania związane z aspektami.<программного продукта>zainteresowań. Wynikowy arkusz często klasyfikuje anomalie i jest oceniany przez zespół pod kątem kompletności i dokładności. Decyzja o zakończeniu kontroli podejmowana jest na podstawie jednego (dowolnego) z trzech kryteriów:

1. Przyjęcie<продукта>bez lub z niewielką potrzebą przetwarzania
2. Przyjęcie<продукта>ze sprawdzeniem przerobionych fragmentów
3. Konieczność ponownej kontroli

Spotkania kontrolne zwykle trwają kilka godzin, w przeciwieństwie do ocen technicznych i audytów, które w większości przypadków wymagają więcej pracy i dlatego trwają dłużej.

Przejścia

Celem uruchomienia jest ocena oprogramowania. Bieg może być przeprowadzony w celu zapoznania (przeszkolenia) słuchaczy z produktem programowym.

Główne cele zamiatania to:

• Poszukiwanie anomalii
• Ulepszanie produktu
• Omówienie alternatywnych sposobów realizacji
• Ocena zgodności z normami i specyfikacjami

Przejazd jest podobny do przeglądu, jednak zazwyczaj odbywa się w mniej formalny sposób. Zasadniczo bieg jest organizowany przez inżynierów dla innych członków zespołu w celu uzyskania od nich informacji zwrotnej na temat ich pracy, jako jeden z elementów (technik) zapewnienia jakości.

Audyty

Cel audytu oprogramowania to niezależna ocena oprogramowania i procesów pod kątem zgodności z obowiązującymi przepisami, normami, wytycznymi, planami i procedurami.

Audyt to formalnie zorganizowana czynność, w której uczestniczą uczestnicy: pewne role takich jak audytor wiodący, inny audytor, rejestrator i inicjator. W audycie uczestniczy przedstawiciel ocenianej organizacji/komórki organizacyjnej. W wyniku audytu identyfikowane są niezgodności i generowany jest raport, którego potrzebuje zespół<разработки>do podjęcia działań naprawczych.

Chociaż istnieją różne formalne nazwy (i klasyfikacje) ocen i audytów, należy zauważyć, że tego rodzaju czynności można przeprowadzić dla prawie każdego produktu na dowolnym etapie procesu rozwoju lub utrzymania.

Względy praktyczne

Wymagania dotyczące jakości oprogramowania

Czynniki wpływu

Na planowanie, zarządzanie i wybór działań i technik SQM mają wpływ różne czynniki, w tym:

• Zakres systemu, w którym będzie działać oprogramowanie (kluczowe dla bezpieczeństwa)<людей>) krytyczne dla biznesu itp.)
• Wymagania systemowe i programowe
• Jakie komponenty są używane w systemie - komercyjne (zewnętrzne) czy standardowe (wewnętrzne)
• Jakie standardy inżynierii oprogramowania mają zastosowanie w danym kontekście
• Jakie są metody i narzędzia programowe wykorzystywane do rozwoju i utrzymania oraz do zapewnienia i poprawy jakości (produkt i procesy)
• Budżet, personel, organizacja działań projektowych, plany i harmonogramy dla wszystkich procesów
• Kim są docelowi użytkownicy i jaki jest cel systemu?
• Poziom integralności systemu

Informacje o tych czynnikach mają wpływ na to, jak dokładnie zostaną zorganizowane i udokumentowane procesy SQM, jakie prace SQM zostaną wybrane (ustandaryzowane w całym projekcie, zespole, jednostce organizacyjnej, organizacji), jakie zasoby są potrzebne i jakie są ograniczenia nakładu pracy ukierunkowanego na jakość zapewnienie.

Rzetelność

Gwarancja- gwarancja<высокой>niezawodność, bezpieczeństwo przed awariami.
W przypadkach, gdy awaria systemu może prowadzić do bardzo poważnych konsekwencji (takie systemy są czasami nazywane w źródłach anglojęzycznych „wysokim zaufaniem” lub „systemem wysokiej integralności”, w języku rosyjskim są czasami określane jako „systemy o zwiększonej niezawodności”, „wysokie dostępność” itp.), ogólna (zagregowana) niezawodność systemu (jako połączenie sprzętu, oprogramowania i ludzi) jest głównym i priorytetowym wymaganiem jakościowym w stosunku do głównej funkcjonalności<системы>.

Rzetelność oprogramowanie zawiera takie cechy jak ochrona przed awariami (tzw. fault-tolerant), bezpieczeństwo użytkowania (bezpieczeństwo – bezpieczeństwo w kontekście akceptowalnego ryzyka dla zdrowia ludzi, biznesu, mienia itp.), bezpieczeństwo informacji lub zabezpieczenia (bezpieczeństwo – ochrona informacji pochodzących z nieautoryzowanych operacji, w tym dostępu do odczytu, a także gwarancji dostępności informacji dla uprawnionych użytkowników, w zakresie nadanych im uprawnień), a także użyteczności. Niezawodność jest również kryterium, które można zdefiniować w kategoriach niezawodności.

Istotną rolę w dyskusji nad tym zagadnieniem odgrywa obszerna literatura dotycząca systemów o podwyższonej niezawodności. Jednocześnie używana jest terminologia pochodząca z dziedziny tradycyjnej mechaniki i systemy elektryczne(w tym te, które nie obejmują oprogramowania) i opisują pojęcia zagrożenia, ryzyka, integralności systemu itp.

Poziomy integralności oprogramowania

Poziom integralności oprogramowania jest określana na podstawie możliwych konsekwencji awarii oprogramowania i prawdopodobieństwa wystąpienia takiej awarii. Gdy ważne są różne aspekty bezpieczeństwa (bezpieczeństwa aplikacji i informacji), techniki analizy zagrożeń (w kontekście bezpieczeństwa użytkowania, bezpieczeństwa) oraz analizy zagrożeń (w zakresie bezpieczeństwa informacji, bezpieczeństwa) mogą być wykorzystane w tworzeniu planów pracy w terenie identyfikacji możliwych źródeł wypadków. Historia awarii podobnych systemów może również pomóc w identyfikacji najbardziej przydatnych technik wykrywania awarii i<всесторонней>ocena jakości oprogramowania.

Rozważając bardziej szczegółowo integralność oprogramowania w kontekście konkretnych projektów, należy zwrócić szczególną uwagę (poprzez przydzielanie odpowiednich zasobów i przeprowadzanie niezbędna praca) nie tylko procesy SQM (zwłaszcza formalne, w tym audyt i atestacja), ale także aspekty zarządzania wymaganiami (w zakresie kryteriów integralności), zarządzania ryzykiem (w tym planowania ryzyka zarówno na etapie rozwoju, jak i eksploatacji i utrzymania systemu ), projektowaniem (co w celu zwiększenia niezawodności bez wątpienia wiąże się z dogłębną analizą i weryfikacją zaplanowanych do zastosowania rozwiązań architektonicznych i technologicznych, często poprzez tworzenie projektów pilotażowych, stanowisk demonstracyjnych itp.) oraz testowaniem (w celu zapewnienia kompleksowe badanie charakterystyki behawioralnej systemu, w tym emulacja środowiska pracy/konfiguracji, w jakiej system powinien być używany podczas eksploatacji).

Charakterystyka defektów

Procesy SQM zapewniają wykrywanie defektów. Opisanie cech defektów odgrywa główną rolę w zrozumieniu produktu, ułatwia dostosowanie procesu lub produktu, a także informuje kierowników projektów i klientów o statusie (stanu) procesu lub produktu. Istnieje wiele taksonomii (klasyfikacji i metod strukturyzacji) defektów (zakłóceń). Charakterystykę defektów (anomalii) stosuje się również w auditowaniu i ocenach, gdzie lider oceny często przedstawia listę anomalii wygenerowanych przez członków zespołu oceniającego do dyskusji na odpowiednich spotkaniach.

Na tle ewolucji (i pojawiania się nowych) metod projektowania i języków wraz z nowymi technologie oprogramowania pojawiają się nowe klasy defektów. Interpretacja (i poprawienie) wcześniej zidentyfikowanych klas defektów (awarii) wymaga ogromnego wysiłku. Podczas śledzenia usterek inżyniera interesuje nie tylko ich ilość, ale także rodzaj. Rozkład defektów według rodzaju jest szczególnie ważny dla określenia najsłabszych elementów systemu, pod względem zastosowanych technologii i rozwiązań architektonicznych, co prowadzi do konieczności ich dogłębnego zbadania, stworzenia specjalistycznych projektów pilotażowych, dodatkowa weryfikacja koncepcje (proof of concept, POC jest często stosowanym podejściem przy korzystaniu z nowych technologii), zaangażowanie zewnętrznych ekspertów itp. Informacje same w sobie, bez klasyfikacji, są często po prostu bezużyteczne do wykrywania przyczyn awarii, ponieważ w celu określenia sposobów rozwiązania problemów należy je pogrupować według odpowiednich typów. Pytanie polega na zdefiniowaniu taksonomii defektów, która będzie miała znaczenie dla inżynierów i organizacji jako całości.

SQM zbiera informacje na wszystkich etapach tworzenia i utrzymania oprogramowania. Zwykle, kiedy mówimy „wada”, mamy na myśli „awaria”, jak zdefiniowano poniżej. Jednak różne kultury i standardy mogą sugerować różne znaczenia tych terminów.

Częściowe definicje tego rodzaju pojęć są następujące:

• Błąd:„Różnica… między wynikiem prawidłowym a obliczonym”<полученным с использованием программного обеспечения>”
• Niekorzyść:„Nieprawidłowa definicja kroku, procesu lub danych w programie komputerowym”
• Niepowodzenie: “<Некорректный>wynik uzyskany w wyniku niedoboru”
• Błąd człowieka/użytkownika:„Ludzkie działanie prowadzące do nieprawidłowego wyniku”

Omawiając ten temat, defekt jest wynikiem awarii oprogramowania. Modele niezawodności budowane są na podstawie danych o awariach zebranych podczas testowania lub użytkowania oprogramowania. Takie modele można wykorzystać do przewidywania przyszłych awarii i pomocy w podjęciu decyzji o przerwaniu testów.

Na podstawie wyników prac SQM mających na celu wykrycie wad podejmowane są działania mające na celu usunięcie wad z badanego produktu. To jednak nie koniec. Istnieją inne możliwe działania, które należy podjąć, aby w pełni wykorzystać wyniki odpowiednich prac SQM. Wśród nich - analiza i podsumowanie (podsumowanie)<по обнаруженным несоответствиям/дефектам>, przy użyciu technik kwantyfikacji (uzyskiwania metryk) w celu ulepszenia produktu i procesu, śledzenia defektów i usuwania ich z systemu (z zarządzaniem i kontrola techniczna podjęcie niezbędnych działań naprawczych). Z kolei źródłem informacji dla doskonalenia procesu w szczególności jest proces SQM.

Dane o niezgodnościach i defektach wykrytych podczas wdrażania odpowiednich technik SQM powinny być rejestrowane, aby zapobiec ich utracie. Dla niektórych techników (np. ocena techniczna, audyt, inspekcje) obecność rejestratora (rejestratora) jest obowiązkowa, właśnie po to, aby rejestrować takie informacje, wraz z kwestiami (w tym tymi, które wymagają dodatkowego rozważenia) i podjęte decyzje... W przypadkach, w których stosowane są odpowiednie narzędzia automatyzacji, mogą one również dostarczyć niezbędne informacje wyjściowe o defektach (na przykład zbiorcze statystyki dotyczące statusu defektów, odpowiedzialnych wykonawców itp.). Dane o defektach mogą być gromadzone i rejestrowane w postaci wniosków o zmianę oprogramowania (SCR), a następnie mogą być wprowadzane do określonych rodzajów baz danych (na przykład w celu śledzenia statystyk międzyprojektowych/historycznych w celu dalszej analizy i doskonalenia procesów), zarówno ręcznie, jak i automatycznie z odpowiednich narzędzi analitycznych (szereg nowoczesnych narzędzi projektowych oraz narzędzi specjalistycznych pozwala analizować kod i modele przy użyciu odpowiednich metryk, które są istotne dla zapewnienia jakości produktów i procesów). Raporty o defektach przesyłane są na szczebel zarządzania organizacji/jednostki organizacyjnej lub struktury (w celu podjęcia odpowiednich decyzji dotyczących projektu, produktu, procesu, personelu, budżetu itp.).

Techniki zarządzania jakością oprogramowania

Techniki SQM można podzielić na kilka kategorii:

• statyczny
• techniki wymagające intensywnego wykorzystania zasobów ludzkich
• analityczny
• dynamiczny

Techniki statyczne

Techniki statyczne zakładają<детальное>badanie dokumentacji projektowej, oprogramowania i innych informacji o produkcie programowym bez jego wykonania. Techniki te mogą obejmować inne „zbiorowe” oceny lub „indywidualne” czynności przeglądowe, omówione poniżej, niezależnie od stopnia wykorzystania narzędzi automatyzacji.

Techniki angażujące ludzi

Forma tego rodzaju techniki, w tym ocena i audyt, może obejmować zarówno formalne spotkania, jak i nieformalne spotkania lub dyskusje dotyczące produktu, nawet bez odwoływania się do jego kodu. Zazwyczaj tego rodzaju technika obejmuje interakcję twarzą w twarz co najmniej dwóch, aw większości przypadków więcej specjalistów. Jednocześnie takie spotkania mogą wymagać wstępnego przygotowania (prawie zawsze w zakresie określenia treści spotkań, czyli listy spraw do omówienia). Zasoby wykorzystywane w takich technikach, wraz z badanymi artefaktami (produkt, dokumentacja, modele itp.), mogą obejmować różnego rodzaju listy kontrolne i wyniki technik analitycznych (omówionych poniżej) oraz prac testowych. Techniki te omówiono na przykład w 12207 przy omawianiu przeglądu i badania.

Techniki analityczne

Inżynierowie oprogramowania mają tendencję do używania technik analitycznych. Z punktu widzenia metod i podejść Agile, jednostki i interakcje zakładają<непосредственное>komunikacja i ciągła interakcja członków zespołu.

Czasami kilku inżynierów stosuje tę samą technikę, ale na różnych częściach produktu. Niektóre techniki opierają się na specyfice używanych narzędzi, podczas gdy inne dotyczą pracy „ręcznej”. Wiele z nich może bezpośrednio pomóc w znalezieniu defektów, ale najczęściej są one wykorzystywane do wspierania innych technik. Szereg technik obejmuje również różne rodzaje oceny (oceny) jako integralną część ogólnej analizy jakości. Przykładami takich technik są analiza złożoności, analiza przepływu sterowania (lub analiza przepływu sterowania) i analiza algorytmiczna.

Każdy rodzaj analizy ma określony cel i nie wszystkie typy mają zastosowanie do każdego projektu. Przykładem techniki konserwacji jest analiza złożoności, która jest przydatna do identyfikowania elementów projektu systemu, które są zbyt złożone, aby można je było poprawnie zaimplementować, przetestować lub konserwować. Wynik analizy złożoności może być również wykorzystany do opracowania przypadków testowych (przypadków testowych). Techniki wyszukiwania defektów, takie jak analiza logiki sterowania, mogą być również stosowane w innych przypadkach. W przypadku oprogramowania z rozbudowaną logiką algorytmiczną niezwykle ważne jest stosowanie technik algorytmicznych, szczególnie w przypadkach, gdy nieprawidłowy algorytm (nie jego implementacja, czyli logika, przyp. autora) może prowadzić do katastrofalnych rezultatów (np. oprogramowanie awioniki, dla którego kwestie bezpieczeństwa użytkowania - bezpieczeństwo odgrywa decydującą rolę).

Inne, bardziej formalne rodzaje technik analitycznych znane są jako metody formalne. Są one używane do walidacji wymagań i projektowania (co prawda, tylko sporadycznie, w obecnej praktyce tworzenia oprogramowania przemysłowego). Walidacja jest stosowana do krytycznych fragmentów oprogramowania (co ogólnie rzecz biorąc ma niewiele wspólnego z metodami formalnymi - jest to naturalny sposób na osiągnięcie akceptowalnej jakości przy minimalizacji kosztów). Służą one najczęściej do weryfikacji krytycznych części krytycznych systemów, np. określonych wymagań.<информационной>bezpieczeństwo i niezawodność.

Techniki dynamiczne

W procesie tworzenia i utrzymywania oprogramowania należy sięgnąć po różnego rodzaju techniki dynamiczne. Zasadniczo są to techniki testowania. Jednak techniki symulacji, sprawdzania modelu i wykonania symbolicznego można uznać za techniki dynamiczne, często polegające na wykorzystaniu fikcyjnych modułów w zakresie logiki wykonywalnej, z emulowanymi danymi wejściowymi i wyjściowymi przy rozważaniu ogólnego scenariusza zachowania wielomodułowego systemy; czasami termin ten odnosi się również do innych technik, w zależności od wybranego źródła).

Przeglądanie (odczytywanie) kodu jest zwykle uważane za technikę statyczną, ale doświadczony inżynier może wykonać kod bezpośrednio „w trakcie” czytania (na przykład używając interaktywnych narzędzi do debugowania krok po kroku, aby przejrzeć lub ocenić kod innej osoby) . Tak więc tę technikę można z powodzeniem omówić jako dynamiczną. Te rozbieżności w klasyfikacji technik wyraźnie pokazują, że w zależności od roli danej osoby w organizacji, może ona na różne sposoby akceptować i stosować te same techniki.

W zależności od organizacji<ведения>projektu, pewne czynności testowe mogą być wykonywane podczas tworzenia systemów oprogramowania w procesach SQA i V&V. Ponieważ plan SQM dotyczy problemów z testowaniem, ten temat zawiera kilka komentarzy na temat testowania.

Testowanie

Procesy potwierdzania<качества> opisane w SQA i V&V<планах>badać i oceniać wszelkie produkty wyjściowe (w tym pośrednie i końcowe) związane ze specyfikacją wymagań oprogramowania dla:

• identyfikowalność,
• spójność,
• kompletność,
• poprawność
• i bezpośrednio wykonujące<требований>(wydajność).

Ta walidacja obejmuje również wszelkie artefakty wyjściowe z rozwoju i utrzymania, gromadzenia, analizy i kwantyfikacji wyników. Działania SQA dają pewność, że odpowiednie (niezbędne w danym kontekście projektu) typy testów są zaplanowane, opracowane i wdrożone, a V&V – opracowanie planów testów, strategii, scenariuszy i procedur<тестирования>.
Zagadnienia związane z testowaniem zostały szczegółowo omówione w Strefie wiedzy dotyczącej testowania. Dwa rodzaje testów podążają za celami SQA i V&V, ponieważ odpowiadają za jakość danych wykorzystywanych w projekcie:

• Ocena i testowanie narzędzi wykorzystywanych w projekcie
• Testowanie zgodności (lub ocena testów zgodności) komponentów i produktów COTS (COTS - reklama półki, produkt gotowy do użycia) do wykorzystania w tworzonym produkcie.

Czasami niezależne organizacje V&V mogą wymagać możliwości monitorowania procesu testowania i, w niektórych przypadkach, poświadczania (lub częściej dokumentowania/rejestrowania) faktycznego wdrożenia.<тестов>do ich realizacji zgodnie z określonymi procedurami. Z drugiej strony można odwołać się do V&V, może to mieć na celu ocenę samego badania: wystarczalności planów i procedur, spójności i dokładności wyników.

Innym rodzajem testów, które są przeprowadzane pod nadzorem organizacji V&V, są testy stron trzecich. Taka osoba trzecia sama nie jest twórcą produktu i nie jest w żaden sposób powiązana z twórcą produktu. Co więcej, osoba trzecia jest niezależnym źródłem oceny, zwykle akredytowanym do posiadania odpowiednich uprawnień (np. organizacja opracowująca normę, której zgodność ocenia niezależny ekspert i której działania potwierdza twórca normy). standard). Celem tego typu testów jest sprawdzenie, czy produkt spełnia określony zestaw wymagań (np. bezpieczeństwo informacji).

Pomiar jakości oprogramowania

Modele jakości oprogramowania często zawierają metryki służące do określenia poziomu każdej cechy jakości w produkcie.

Jeśli cechy jakościowe są dobrane prawidłowo, takie pomiary mogą utrzymać jakość (poziom jakości) na wiele sposobów. Metryki mogą pomóc w kierowaniu procesem podejmowania decyzji. Metryki mogą pomóc w znalezieniu problematycznych aspektów i wąskie gardła w procesach. Metryki są narzędziem oceny jakości ich pracy przez samych inżynierów – zarówno pod kątem celów określonych przez SQA, jak i pod kątem długoterminowego procesu doskonalenia.<достигаемого>jakość.
Wraz ze wzrostem wewnętrznej złożoności, wyrafinowania oprogramowania, kwestie jakości wykraczają daleko poza stwierdzenie faktu - czy oprogramowanie działa, czy działa. Pytanie brzmi, jak dobrze osiągane są skwantyfikowane cele jakościowe.

Istnieje kilka innych tematów, które są omawiane na metrykach bezpośrednio obsługujących SQM. Obejmują one pomoc w podjęciu decyzji, kiedy przestać testować. W tym kontekście przydatne są modele niezawodności i porównanie z benchmarkami (benchmarkami).

Koszt procesu SQM jest jednym z<проблемных>pytania, które zawsze pojawiają się w procesie decyzyjnym, jak będzie zorganizowany projekt (praca projektowa). Często stosuje się ogólne modele kosztów, które opierają się na określeniu, kiedy defekt zostanie wykryty i ile wysiłku trzeba włożyć w jego naprawę w porównaniu do sytuacji, w której defekt został wykryty na wcześniejszym etapie cyklu życia. Dane projektowe mogą pomóc w uzyskaniu jaśniejszego obrazu kosztów.

Wreszcie samo raportowanie SQM zawiera przydatne informacje nie tylko o samych procesach (czyli o ich obecnym stanie, przyp. autora), ale także o tym, jak można usprawnić wszystkie procesy w cyklu życia.

Chociaż, jako szacunki ilościowe (w tym przypadku nadchodzi o wynikach ocen, a nie o procesie pomiarów) cechy jakościowe mogą być przydatne same w sobie (np. liczba niespełnionych wymagań i proporcja takich wymagań), mogą<эффективно>stosować techniki matematyczne i graficzne w celu ułatwienia interpretacji wartości metrycznych. Takie techniki są dość naturalnie sklasyfikowane, na przykład w następujący sposób:

• Na podstawie metod statystycznych (np. analiza Pareto, rozkład normalny itp.)
• Testy statystyczne
• Analiza trendów
• Predykcja (np. modele niezawodności)

Techniki statystyczne i testy statystyczne często dostarczają obrazu najbardziej problematycznych obszarów badanego oprogramowania (i, nawiasem mówiąc, to samo często dotyczy procesów). Powstałe wykresy i wykresy wizualnie pomagają decydentom w identyfikacji obszarów, na których należy skoncentrować zasoby<проекта>... Wyniki analizy trendów mogą wskazywać, że harmonogram nie jest przestrzegany, na przykład podczas testowania; lub że awarie niektórych klas stają się częstsze, dopóki nie zostaną podjęte działania naprawcze podczas tworzenia. Techniki przewidywania pomagają w planowaniu czasów testów i przewidywaniu awarii.

Charakterystyka jakości oprogramowania

Ruchliwość- Zestaw atrybutów związanych z możliwością przenoszenia oprogramowania z jednego środowiska do drugiego.
UWAGA Środowisko może obejmować środowisko organizacyjne, techniczne lub programowe.

Niezawodność- Zestaw atrybutów związanych ze zdolnością oprogramowania do utrzymywania poziomu wydajności w określonych warunkach przez określony czas.

Uwagi:

1. Oprogramowanie nie ulega pogorszeniu ani starzeniu. Ograniczenia niezawodności wynikają z błędów w wymaganiach, projektowaniu i implementacji. Awarie spowodowane tymi błędami różnią się w zależności od sposobu użytkowania oprogramowania i wersji oprogramowania, które zostały wcześniej wybrane.
2. Zgodnie z definicją w ISO 8402 „niezawodność” to „zdolność elementu do wykonania wymaganej funkcji”. W niniejszej Normie Międzynarodowej funkcjonalność jest tylko jedną z cech jakości oprogramowania. Dlatego definicja niezawodności została rozszerzona, aby „utrzymać jej poziom wydajności” zamiast „wykonywać wymaganą funkcję”.

Użyteczność- Zbiór atrybutów związanych z zakresem pracy wymaganym do wykorzystania oraz indywidualną oceną takiego wykorzystania przez określony lub zamierzony zbiór użytkowników.

Uwagi:

1. „Użytkownicy” mogą być interpretowani jako większość bezpośrednich użytkowników oprogramowania interaktywnego. Do grona użytkowników mogą należeć operatorzy, użytkownicy końcowi i użytkownicy pośredni, których dotyczy to oprogramowanie lub którzy są uzależnieni od jego użytkowania. Należy wziąć pod uwagę praktyczność w różnych warunkach pracy użytkownika, które mogą mieć wpływ na oprogramowanie, w tym przygotowanie do użycia i ocenę wyników.
2. Praktyczność, zdefiniowana w tym standardzie jako specyficzny zestaw atrybutów dla oprogramowania, różni się od definicji ergonomicznej, która uwzględnia inne cechy, takie jak wydajność i nieefektywność, jako integralne części użyteczności.

Utrzymywalność- Zestaw atrybutów związanych z zakresem prac wymaganych do przeprowadzenia określonych zmian (modyfikacji).
UWAGA Zmiana może obejmować poprawki, ulepszenia lub adaptację oprogramowania do zmian w środowisku, wymaganiach i warunkach pracy.

Funkcjonalność- Zbiór atrybutów związanych z istotą zbioru funkcji i ich specyficznymi właściwościami. Funkcje to te, które spełniają określone lub domniemane potrzeby.

Uwagi:

1. Ten zestaw atrybutów charakteryzuje to, co oprogramowanie robi w celu zaspokojenia potrzeb, podczas gdy inne zestawy opisują głównie, kiedy i jak to się robi.
2. W tej charakterystyce uwzględniana jest uwaga do definicji jakości dla stwierdzonych i dorozumianych potrzeb.

Wydajność- Zestaw atrybutów związanych z zależnością między poziomem wydajności oprogramowania a ilością wykorzystywanych zasobów w określonych warunkach.
UWAGA - Zasoby mogą obejmować inne produkty oprogramowania, środki techniczne, materiały (np. papier do drukowania, dyskietki) i usługi personelu obsługującego, towarzyszącego lub konserwującego.

Jakość oprogramowania

Jakość oprogramowania- cały zakres funkcji i właściwości oprogramowania, które odnoszą się do jego zdolności do zaspokojenia ustalonych lub przewidywanych potrzeb.

Znaczenie każdej cechy jakości różni się w zależności od klasy oprogramowania. Na przykład niezawodność jest najważniejsza dla oprogramowania dla systemów o krytycznym znaczeniu dla walki, wydajność jest najważniejsza dla oprogramowania dla systemów czasu rzeczywistego, dla których ważny jest czas, a użyteczność jest najważniejsza dla oprogramowania do dialogu użytkownika końcowego.

Ważność każdej cechy jakości również różni się w zależności od przyjętych punktów widzenia.

Widok użytkownika

Użytkownicy są zainteresowani głównie zastosowaniem oprogramowania, jego wydajnością i wynikami jego użytkowania. Użytkownicy oceniają oprogramowanie bez badania jego wewnętrznych aspektów lub sposobu, w jaki zostało stworzone.

Użytkownik może być zainteresowany następującymi pytaniami:

• Czy wymagane funkcje są dostępne w oprogramowaniu?
• Jak niezawodne jest oprogramowanie?
• Jak skuteczne jest oprogramowanie?
• Czy oprogramowanie jest przyjazne dla użytkownika?
• Jak łatwo jest przenieść oprogramowanie i inne środowisko?

Widok programisty

Proces projektowania wymaga, aby użytkownik i programista używali tych samych cech jakości oprogramowania, które są używane do ustalania wymagań i akceptacji. Opracowując oprogramowanie na sprzedaż, wymagania jakościowe powinny odzwierciedlać przewidywane potrzeby.

Ponieważ programiści są odpowiedzialni za tworzenie oprogramowania, które musi spełniać wymagania jakościowe, interesują ich zarówno jakość półproduktów, jak i jakość produktu końcowego. Aby ocenić jakość produktów pośrednich na każdym etapie cyklu rozwojowego, programiści muszą stosować różne metryki dla tych samych cech, ponieważ te same metryki nie mają zastosowania do wszystkich faz cyklu życia.

Na przykład użytkownik rozumie wydajność w kategoriach czasu odpowiedzi, podczas gdy programista używa terminów długość trasy i opóźnienie oraz czasy dostępu w specyfikacji projektu. Metryki używane w interfejsie produktu są zastępowane przez metryki używane w strukturze.

Wprowadzenie do głowy

Menedżer może być bardziej zainteresowany ogólną jakością niż konkretną cechą jakości i z tego powodu będzie musiał określić znaczenie wartości, które odzwierciedlają wymagania biznesowe dla poszczególnych cech.
Kierownik może również potrzebować porównania poprawy jakości z kryteriami zarządzania, takimi jak planowane opóźnienia lub przekroczenia kosztów, ponieważ chce zoptymalizować jakość w ramach ograniczonych kosztów, siły roboczej i ram czasowych.

Ocena jakości oprogramowania,

Poniższy rysunek przedstawia podstawowe kroki wymagane do oceny jakości oprogramowania.

Rysunek „Model procesu oceny”

Proces oceny składa się z trzech etapów: ustalenie (definicja) wymagań jakościowych, przygotowanie do oceny i procedury oceny. Proces ten można zastosować w dowolnej odpowiedniej fazie cyklu życia każdego komponentu oprogramowania.
Celem etapu wstępnego jest ustalenie wymagań w zakresie cech jakościowych. Wymagania wyrażają potrzeby środowiska zewnętrznego dla danego produktu oprogramowania i powinny być zdefiniowane przed rozwojem.
Celem drugiego etapu jest przygotowanie podstaw do oceny.
Trzeci wynik to wniosek dotyczący jakości oprogramowania. Uogólnioną jakość porównuje się następnie z innymi czynnikami, takimi jak czas i koszt. Ostateczna decyzja kierownictwa podejmowana jest na podstawie kryterium kontroli. Wynikiem jest decyzja kierownictwa dotycząca akceptacji lub odrzucenia, bądź wydania lub nie wydania oprogramowania.

Model jakości procesu

Proces rozwoju powinien być zorganizowany w taki sposób, aby zapewnić możliwość pomiaru jakości produktu. Z przeprowadzonych badań wynika, że ​​im wyższa jakość procesu rozwojowego, tym wyższa jakość oprogramowania w tym procesie opracowanego. Jakość na każdym etapie projektu wzrasta, po pierwsze, jako bezpośrednia konsekwencja dojrzałości procesu, a po drugie, dzięki zastosowaniu wyższej jakości półproduktu wytworzonego na poprzednim etapie. Jednocześnie podkreśla się, że istotność drugiego powodu, jakim jest wzrost jakości procesu cyklu życia dla dojrzałych procesów, jest znacznie ważniejsza. Wszystko to można przedstawić w postaci pewnego modelu.

Rysunek „Koncepcyjny model jakości procesu rozwoju”

Wynikają z tego następujące konsekwencje:
Po pierwsze, jakość kumuluje się w produkcie w złożonej produkcji w sposób skumulowany, a wkład w jakość dokonany na wczesnych etapach ma większy wpływ na produkt końcowy niż na późniejszych etapach. Potwierdzają to wszelkie praktyki programistyczne, na przykład wiadomo, że wad projektowych systemu nie da się zrekompensować wysoką jakością kodowania.
Dlatego do zarządzania jakością budowy złożonego systemu konieczny jest dobór producentów na podstawie pomiaru stopnia dojrzałości i przejrzystości stosowanych procesów rozwojowych. Pomiar jakości procesu rozwoju wykonawcy jest ważną częścią ogólne kierownictwo jakość, ważniejsza niż mierzenie jakości produktu wynikowego wytworzonego podczas testów akceptacyjnych.
Po drugie, testowanie i pomiar jakości powinny mieć miejsce na wszystkich etapach cyklu życia. Pozyskiwanie danych wysokiej jakości, które zostały ustalone na wczesnym etapie, może być bardzo kosztowne, jeśli nie są dostępne pełne wyniki

Wytyczne dotyczące stosowania cech jakościowych

1 Zastosowanie

2 Koncepcje dotyczące jakości oprogramowania

2.1 Wprowadzenie użytkownika
2.2 Widok programisty
2.3 Reprezentacja kierownika

3.1 Ustanowienie wymagań jakościowych

3.2 Przygotowanie do oceny

3.2.1 Wybór metryk jakości (wskaźniki)
3.2.2 Określenie poziomów rankingowych
3.2.3 Ustalenie kryterium oceny

3.3 Procedura oceny

3.3.1 Pomiar
3.3.2 Ranking
3.3.3 Ewaluacja

1. Wstęp

2 Wyznaczanie zintegrowanych wskaźników jakości

2.1 Funkcjonalność

2.1.1 Przydatność
2.1.2 Dokładność
2.1.3 Interoperacyjność
2.1.4 Zgodność
2.1.5 Bezpieczeństwo

2.2 Niezawodność

2.2.1 Dojrzałość
2.2.2 Tolerancja błędów
2.2.3 Odzyskiwalność

2.3 Użyteczność

2.3.1 Zrozumiałość
2.3.2 Umiejętność uczenia się
2.3.3 Łatwość obsługi (operacyjność)

2.4 Wydajność

2.4.1 Zachowanie czasu
2.4.2 Zachowanie zasobów

2.5 Konserwacja

2.5.1 Możliwość analizy
2.5.2 Zmienność
2.5.3 Stabilność
2.5.4 Testowalność

2.6 Przenośność

2.6.1 Zdolność do adaptacji
2.6.2 Instalowalność
2.6.3 Zgodność
2.6.4 Wymienne

Uwagi:

1. Interoperacyjność jest używana zamiast interoperacyjności, aby uniknąć ewentualnego pomylenia z interoperacyjnością.
2. Zamienność z konkretnym narzędziem programowym nie oznacza, że ten środek zaradczy wymienne z danym oprogramowaniem.
3. Wymienność może obejmować atrybuty łatwości wdrożenia i adaptacyjności. Pojęcie zostało wprowadzone jako osobna podcecha ze względu na jego wagę.

Jakość projektu

Jakość obejmuje wszystkie działania projektowe, które zapewniają, że projekt jest odpowiedni do celu, dla którego został podjęty. Dlatego zarządzanie jakością ma zastosowanie zarówno do projektu, jak i produktu projektu.
Jakość ma kluczowe znaczenie, ponieważ artykułuje i ustala cele, dokumentuje je (sformalizuje).
Dlatego jakość jest krytycznym elementem zarządzania strukturą projektu.
Wszystko jest mierzalne dla jakości.

Zarządzanie jakością projektu

Jeśli zarządzanie jakością skoncentruje się w jednej jednostce organizacji, nie stanie się ono uniwersalne. Kierownik projektu może delegować aspekty zarządzania jakością. Ostateczną odpowiedzialność ponosi kierownik projektu.

Zasady jakości (ISO 9000)

1. Orientacja konsumencka
2. Odpowiedzialność za zarządzanie
3. Angażowanie ludzi
4. Podejście procesowe
5. Systematyczne podejście do zarządzania
6. Ciągłe doskonalenie
7. Podejmowanie decyzji oparte na faktach
8. Obustronnie korzystne relacje z dostawcami

Rysunek „Różnice w rozumieniu zarządzania jakością w ISO 9000 i PMBoK”

Zarządzanie jakością projektu (PMI): podprocesy

• Planowanie jakości
• Zapewnienie jakości
• Kontrola jakości

Planowanie jakości

Jednym z etapów jest ustalenie, który istniejące standardy odnoszą się do tego projektu i jak się do nich stosować. Wynikiem planowania jakości jest lista wszystkich standardów jakości, które mają zastosowanie do projektu. W załączeniu lista zaleceń dotyczących sposobu spełnienia wymagań tych norm

Proces planowania jakości: wkłady

• Polityka jakości. Dokument, który zawiera zasady definiowania jakości przez organizację, ale nie zawiera sposobów osiągnięcia jakości.
• Treść projektu (zakres). Określa, co należy zrobić w wyniku projektu, a co za tym idzie, co powinno być monitorowane w procesach zarządzania jakością. Ten dokument jest wynikiem procesu planowania zakresu projektu.
• Opis produktu. Zawiera szczegóły techniczne i inne istotne aspekty, które mogą wpływać na planowanie jakości.
• Normy i przepisy. Lista norm i przepisów obowiązujących w danym obszarze lub projekcie.
• Inne dokumenty.

Proces planowania jakości: narzędzia i technologie

• Analiza korzyści/kosztów. Istotne w dyskusji o kosztach jakości. Celem tego narzędzia jest porównanie rzeczywistych kosztów braku jakości z korzyściami zapewniania jakości.
• Porównanie. Służy do generowania pomysłów na ulepszenia poprzez porównanie z innymi projektami. Najskuteczniejszy, gdy dokonuje się porównań z najlepszymi, a nie tylko z innymi projektami wewnętrznymi.
• Schematy. Służy do pokazania interakcji różnych elementów. Istnieje wiele rodzajów wykresów, w tym wykres przyczynowo-skutkowy.
• Konfiguracja eksperymentów. Użyj scenariuszy „co, jeśli”, aby określić, które zmienne mają największy wpływ na końcowy wynik projektu.
• Koszt jakości.

Proces planowania jakości: produkty, rezultaty

• Plan zarządzania jakością. Opisuje, w jaki sposób zespół zarządzający projektem wdroży politykę jakości. Powinien obejmować następujące obszary:
• Kontrola projektu.
• Kontrola dokumentacji.
• Kontrola zakupu materiałów.
• Inspekcje.
• Kontrola testów (testowanie).
• Kontrola oprzyrządowania.
• Działania naprawcze.
• Ewidencja jakości.
• Audyty (plan i procedura)
• Udokumentowane procedury i instrukcje pracy. Opisz szczegółowo procesy i sposób mierzenia jakości procesu, podprocesu oraz poszczególnych wykonywanych działań.
• Listy kontrolne. Listy pytań, aby sprawdzić, czy niczego nie brakuje.

Zapewnienie jakości

Proces zapewniania jakości Czy przyjęcie zaplanowanych systematycznych działań w celu zapewnienia realizacji wszystkich przewidzianych procesów niezbędnych do tego, aby projekt (produkt, usługa) spełniał wymagania jakościowe.
Zapewnienie jakości jest głównym podprocesem zarządzania jakością. Czynność ta prowadzona jest przez cały czas trwania projektu.

Proces zapewniania jakości: Nakłady

• Instrukcja pracy. Kolejne wyjście z procesu planowania jakości.
• Wyniki pomiarów kontroli jakości. Wynik procesu kontroli jakości.

Proces zapewniania jakości: narzędzia i techniki

Narzędzia i techniki planowania jakości. Obejmują one analizę kosztów i korzyści, porównania, wykresy, eksperymenty i szacunki kosztów jakości.

Audyty jakości

Ustrukturyzowane „recenzje”, które potwierdzają „wyciągnięte wnioski”. Rodzaje audytów jakości to:

• wewnętrzne/zewnętrzne,
• system / produkt / proces / organizacja,
• planowane / regularne,
• specjalne i skomplikowane.

Proces zapewniania jakości: wyniki

Poprawa jakości. Obejmuje podejmowanie działań w celu zwiększenia wydajności i produktywności projektu w celu zapewnienia wartości dodanej właścicielom projektu.

Kontrola jakości

Monitorowanie określone wyniki w celu określenia ich zgodności z przyjętymi standardami jakości oraz określenia sposobów eliminacji przyczyn niezadowalających wyników.

Proces kontroli jakości: Nakłady

• Wyniki pracy. Rezultaty zawsze pojawiają się w procesie współpracy, realizacji i zmiany harmonogramu projektu.
• Plan zarządzania jakością. Wynik procesu planowania jakości.
• Instrukcja pracy. Wynik procesu planowania jakości.
• Listy kontrolne.

Kontrola jakości: narzędzia i techniki

• Inspekcje. Obejmuje czynności takie jak pomiary, testowanie, testowanie, aby upewnić się, że wynik spełnia wymagania.
• Wykresy kontrolne. Wykresy przebiegu statystycznie określają górne i dolne granice wyświetlane po obu stronach średnich procesowych.
• Schematy: Ishikawa, Pareto.
• Próbkowanie statystyczne.
• Analiza trendów.

« Cel korzystania z narzędzi- naprawiać wyniki lub zmiany, wyświetlać je graficznie, a następnie w odpowiedni sposób identyfikować i korygować problemy.”

Proces kontroli jakości: wyniki

• Poprawa jakości. Wyjście z procesu zapewnienia jakości.
• Podejmować decyzje. Decyzje podejmowane są w zależności od przyjęcia lub odrzucenia kontrolowanego obiektu.
• Działania naprawcze. Działanie podjęte w celu uzgodnienia niezgodnego obiektu.
• Wypełnione listy kontrolne.
• Konfiguracja procesu.

Bibliografia

• http://sorlik.blogspot.com, Siergiej Orlik, 2004-2005
• Genet A.E. Przewodnik dla dyscypliny „Zarządzanie jakością w rozwoju oprogramowania” 2007, St. Petersburg

Pojęcie „jakości oprogramowania”.

Metody inżynierskie w programowaniu opierają się na idei doskonalenia jakości oprogramowania, do realizacji których powstały metody określania wymagań dotyczących jakości oprogramowania, podejścia do wyboru i doskonalenia modeli do analizy metrycznej wskaźników jakości oprogramowania, metody do ilościowego pomiaru wskaźników jakości na etapach cyklu życia oprogramowania.

Jakość oprogramowania to zbiór właściwości, które określają przydatność produktu (programu) dla użytkowników zgodnie z przeznaczeniem i wymaganiami funkcjonalnymi. Jednocześnie wymagania można interpretować dość szeroko, co rodzi szereg niezależnych definicji pojęcia „jakość”. Najczęściej stosowaną definicją jest ISO 9001, zgodnie z którą jakość to „stopień, w jakim nieodłączne cechy spełniają wymagania”. Jakość oprogramowania to pojęcie względne, które ma sens tylko wtedy, gdy uwzględni się rzeczywiste warunki użytkowania oprogramowania. Dlatego wymagania dotyczące jakości oprogramowania są ustalane zgodnie z warunkami i konkretnym obszarem zastosowania oprogramowania.

Modele jakości oprogramowania mają następujące cztery poziomy prezentacji.

Pierwszy poziom odpowiada definicji cech (wskaźników) jakości oprogramowania, z których każda odzwierciedla odrębny punkt widzenia użytkownika na jakość. Zgodnie ze standardami GOST R ISO / IEC 9126-93, GOST R ISO / IEC 12119-2000, GOST 28195-89 model jakości obejmuje sześć cech lub sześć głównych wskaźników jakości, które wymienimy w kolejności ich znaczenia dla większość użytkowników:

• funkcjonalność;
• niezawodność funkcjonalna;
• łatwość użycia;
• efektywność;
• konserwowalność;
• ruchliwość.

Drugi poziom. Atrybuty dla każdej cechy jakości odpowiadają temu poziomowi, który wyszczególnia różne aspekty danej cechy. W ocenie jakości wykorzystywany jest zestaw atrybutów jakości.

Rozważ zestawy atrybutów dla każdego z wymienionych wskaźników jakości (rys. 3.1).

Funkcjonalność to zestaw właściwości, które określają zdolność oprogramowania do wykonywania zamierzonych funkcji w danym środowisku zgodnie z określonymi wymaganiami. Pod funkcjonować jest rozumiany jako pewna uporządkowana sekwencja działań mających na celu zaspokojenie właściwości konsumentów. Funkcje są cel (główny) oraz pomocniczy.

Do atrybutów funkcjonalność odnieść się:

• bezpieczeństwo- atrybut, który pokazuje zdolność oprogramowania do zapobiegania nieautoryzowany dostęp(przypadkowe lub celowe) do programów i danych;
• interoperacyjność- atrybut, który pokazuje zdolność tego oprogramowania do interakcji ze specjalnymi systemami i środowiskami ( OS, sieć komputerowa);
• funkcjonalna kompletność- atrybut, który pokazuje stopień wystarczalności głównych funkcji do rozwiązywania problemów zgodnie z przeznaczeniem tego oprogramowania.

Niezawodność funkcjonalna. Do atrybutów niezawodności funkcjonalnej oprogramowania należą:

• nieomylność- atrybut, który określa zdolność oprogramowania do działania bez błędów;
• Prawidłowy- atrybut, który pokazuje miarę osiągania prawidłowych wyników;
• sterowność- atrybut charakteryzujący kompletność i skuteczność wykrywania błędów w wynikach pośrednich i wyjściowych
• tolerancja błędu- atrybut charakteryzujący zdolność oprogramowania do prawidłowego wykonywania funkcji w nietypowych warunkach (awaria sprzętu, błędy danych i interfejsów itp.);
• niezawodność- atrybut charakteryzujący zdolność oprogramowania do nie powodowania awarii funkcjonalnych System informacyjny;
• odzyskiwalność to atrybut charakteryzujący zdolność programu do eliminacji błąd oprogramowania oraz do ponownego uruchomienia w celu ponownego wykonania i odzyskania danych w przypadku awarii funkcjonalnej;
• chęci- atrybut, który pokazuje zdolność programu, na dowolne żądanie, do dokładnego wykonania zamierzonej transformacji.

Łatwość obsługi charakteryzuje się wieloma atrybutami, które wskazują na niezbędne i odpowiednie warunki korzystania z oprogramowania przez dany krąg użytkowników w celu uzyskania odpowiednich wyników. Norma definiuje użyteczność jako określony zestaw atrybutów oprogramowania, które charakteryzują jego ergonomię.

Ryż. 3.1.

Atrybuty użyteczności obejmują:

• zrozumiałość- atrybut określający wysiłek włożony w rozpoznawanie pojęć logicznych i warunków użytkowania oprogramowania;
• umiejętność studiowania(łatwość uczenia się) – atrybut określający wysiłek użytkowników w celu określenia stosowalności oprogramowania poprzez zastosowanie kontroli operacyjnej, diagnostyki oraz procedur, zasad i dokumentacji;
• szybkość- atrybut, który pokazuje reakcję systemu podczas wykonywania operacji i kontroli operacyjnej.

Wydajność to zestaw atrybutów, które określają zależność między poziomami wykonania oprogramowania, wykorzystaniem zasobów (narzędzi, sprzętu, materiałów – papier do urządzenia drukującego itp.) a usługami wykonywanymi przez regularny personel serwisowy itp.

Do atrybutów efektywności oprogramowania należą:

• reaktywność- atrybut, który pokazuje czas odpowiedzi, przetwarzanie i wykonanie funkcji;
• efektywne gospodarowanie zasobami- atrybut pokazujący liczbę i czas trwania zasobów wykorzystywanych podczas wykonywania funkcji oprogramowania;
• spójność- atrybut świadczący o zgodności danej cechy z określonymi normami, zasadami i przepisami.

Łatwość utrzymania to zestaw właściwości charakteryzujących wysiłek, jaki należy włożyć w wprowadzanie modyfikacji, w tym dostosowywanie, ulepszanie i dostosowywanie oprogramowania w przypadku zmiany środowiska, wymagań lub specyfikacji funkcjonalnych.

Łatwość utrzymania obejmuje następujące atrybuty:

• analizowalność- atrybut określający wysiłek wymagany do zdiagnozowania awarii lub zidentyfikowania części do modyfikacji;
• stabilność- atrybut wskazujący na stałość konstrukcji i ryzyko jej modyfikacji;
• testowalność-Atrybut wskazujący na wysiłek podczas walidacji i weryfikacji w celu wykrycia niezgodności z wymaganiami oraz potrzebę modyfikacji i certyfikacji oprogramowania;
• zmienność- atrybut określający możliwość usuwania błędów w oprogramowaniu lub wprowadzania zmian w celu ich usunięcia, a także wprowadzania nowych funkcji do oprogramowania lub środowiska operacyjnego.

Przenośność to zestaw wskaźników, które wskazują zdolność oprogramowania do przystosowania się do pracy w nowym środowisku wykonawczym. Środowisko może być organizacyjne, sprzętowe i programowe. Dlatego przeniesienie oprogramowania do nowego środowiska uruchomieniowego może wiązać się z zestawem działań mających na celu zapewnienie jego funkcjonowania w środowisku innym niż środowisko, w którym zostało stworzone, z uwzględnieniem nowego oprogramowania, możliwości organizacyjnych i technicznych.

Przenośność obejmuje atrybuty:

• zdolność adaptacji jest atrybutem, który determinuje wysiłek włożony w adaptację do różne środowiska;
• możliwość dostosowania(łatwość instalacji) - atrybut określający nakłady niezbędne do uruchomienia tego oprogramowania w specjalnym środowisku;
• współistnienie- atrybut określający możliwość użycia specjalnego oprogramowania w środowisku systemu operacyjnego;
• wymienność- atrybut charakteryzujący możliwość przeniesienia oprogramowania z jednego środowiska programistycznego do drugiego z niezbędną instalacją lub adaptacją oprogramowania.

Trzeci poziom zaprojektowany do pomiaru jakości za pomocą metryka, z których każdy jest zdefiniowany jako połączenie metody pomiaru atrybutu i skali pomiaru wartości atrybutu. Do oceny atrybutów jakościowych na etapach cyklu życia (podczas przeglądania dokumentacji, programów i wyników testowania programów) metryki o określonej szacowanej wadze służą do wyrównania wyników analizy metrycznej zagregowanych atrybutów danego wskaźnika i jakości jako całości . Atrybut jakości jest określany za pomocą jednej lub więcej technik oceny na etapach cyklu życia i na końcowym etapie tworzenia oprogramowania.

Czwarty poziom- Jest to element metryki oceny (waga), który służy do oceny ilościowej lub jakościowej wartości pojedynczego atrybutu wskaźnika jakości oprogramowania. W zależności od przeznaczenia, funkcji i warunków utrzymania oprogramowania najczęściej ważne cechy cechy i ich atrybuty. Wybrane atrybuty i ich priorytety są odzwierciedlone w wymaganiach dotyczących rozwoju systemu lub używane są odpowiednie priorytety odniesienia klasy oprogramowania, do której należy to oprogramowanie.

1

Artykuł zawiera krótkie informacje na temat normy ISO 9126 „Technologia informacyjna. Ocena oprogramowania. Cechy jakościowe i wskazówki dotyczące ich stosowania ”. Od widma systemy oprogramowania jest szeroka, wybrano grupę systemów do tworzenia testów. Aby ocenić jakość tej grupy programów, podano krótki opis niektórych systemów oprogramowania. Na podstawie cech tej grupy narzędzia programowe sporządzono listę cech, które decydują o jakości programów. Zgodnie z zaleceniami normy ISO 9126 przeprowadzono badanie charakterystyki wybranej grupy narzędzi programowych. Jako metodę wyznaczania wartości wskaźników jakości zastosowano rejestrację cech (czy lub nie) oraz ocenę ekspercką. Stąd zaproponowana metodologia oceny jakości jednego z rodzajów oprogramowania zgodnie z normą ISO 9126.

standard

Charakterystyka

Kontrola jakości

oprogramowanie

1. Baranyuk V.V., Tiutyunnikov N.N. Kontrola jakości słowniki elektroniczne i encyklopedie // Inżynieria oprogramowania. - 2012 r. - nr 8. - str. 29–37.

2. Glichev A.V., Panov V.P., Azgaldov G.G. Czym jest jakość? - M .: Ekonomia, 1968.135 s.

3. Gorbaczenko I.M. Oprogramowanie do tworzenia zautomatyzowanych systemów szkoleniowych // Problemy informatyzacji regionu. PIR 2005: Postępowanie IX konferencja naukowo-praktyczna(Krasnojarsk, 11–12 października 2005). - Krasnojarsk: IPC KSTU, 2005. - vol. 2. - P. 132-135.

4. Gorbaczenko I.M. Analiza porównawcza istniejące systemy testowanie // Testowanie w dziedzinie edukacji: problemy i perspektywy rozwoju: materiały ogólnorosyjskiej konferencji naukowej i praktycznej. (Krasnojarsk, 19-21 maja 2008) / otv. wyd. GP Karłow. - Krasnojarsk: SibSTU, 2008. - S. 177–183.

5. Lipajew W.W. Problemy zapewnienia jakości złożonego oprogramowania [Zasoby elektroniczne]. - Tryb dostępu: http://quality.eup.ru/MATERIALY4/poksps.htm (data dostępu 04.09.2013).

6. Lozinin A.I., Shubinsky I.B. Charakterystyka jakości oprogramowania i metody ich oceny [Zasoby elektroniczne]. - Tryb dostępu: http://www.ibtrans.ru/Estimating% 20methods.pdf (data leczenia 03.12.2013).

Na nowoczesne komputery zainstalował szeroką gamę oprogramowania (oprogramowania). A chcę, żeby był wysokiej jakości, wydajny, działał bezawaryjnie itp. Rozważmy definicję „jakości oprogramowania” w kontekście standardów międzynarodowych:

1) jakość oprogramowania to stopień, w jakim oprogramowanie posiada wymaganą kombinację właściwości. ;

2) jakość oprogramowania - zbiór właściwości oprogramowania (PS), które określają jego przydatność do zaspokojenia określonych lub domniemanych potrzeb zgodnie z jego przeznaczeniem [GOST 28806-90 „Jakość oprogramowania. Warunki i definicje"].

Celem pracy jest opracowanie metodyki zastosowania wymagań normy ISO 9126 do oceny jakości jednego z rodzajów oprogramowania – systemów tworzenia testów.

Norma ISO 9126

W chwili obecnej najbardziej rozpowszechniony i stosowany wielopoziomowy model jakości oprogramowania, przedstawiony w zbiorze norm ISO 9126. Podstawą regulacji wskaźników jakości systemów jest międzynarodowa norma ISO 9126 „Technologia informacyjna. Ocena oprogramowania. Cechy jakościowe i wskazówki dotyczące ich stosowania ”. Ten standard opisuje warstwową dystrybucję cech oprogramowania. Na najwyższym poziomie wyróżniono 6 głównych cech jakości oprogramowania, z których każda jest określona przez zestaw atrybutów, które mają odpowiednie metryki do późniejszej oceny (rysunek).

Zgodnie z tym modelem funkcjonalność narzędzia programistycznego (funkcjonalność) jest zbiorem właściwości systemu programowego, zdeterminowanych obecnością i specyficznymi cechami zbioru funkcji zdolnych do zaspokojenia danych lub domniemanych potrzeb jakościowych wraz z jego niezawodnością jako system techniczny... Niezawodność - zdolność oprogramowania do wykonywania wymaganych zadań w określonych warunkach przez określony czas lub określoną liczbę operacji. Łatwość korzystania z narzędzia programistycznego (usability) to zbiór właściwości systemu programistycznego, który charakteryzuje nakład pracy wymagany do jego wykorzystania oraz ocenę wyników jego wykorzystania przez dany krąg użytkowników oprogramowania. Wydajność - zdolność oprogramowania do zapewnienia wymaganego poziomu wydajności zgodnie z przydzielonymi zasobami, czasem i innymi określonymi warunkami. Łatwość utrzymania (Maintainability) - łatwość, z jaką oprogramowanie może być analizowane, testowane, zmieniane w celu usunięcia usterek, wdrożenia nowych wymagań, ułatwienia dalszego utrzymania i dostosowania do nazwanego środowiska. Przenośność (przenośność) – zespół właściwości PS, który charakteryzuje zdolność do przenoszenia z jednego środowiska funkcjonowania do innych.

Model jakości oprogramowania (ISO 9126)

Oprogramowanie do tworzenia systemu testowego

Na obecnym poziomie rozwoju technologii komputerowych i systemów wymiany informacji coraz częściej w nauczaniu stosuje się testowanie, które jest wykorzystywane jako narzędzie monitorowania i prognozowania uczelni. Monitoring jako system kontrolno-diagnostyczny zapewnia nauczycielowi obiektywną i operacyjną informację o stopniu opanowania przez uczniów obowiązkowego materiału edukacyjnego, a administracji o skuteczności zarządzania. Komputerowy system testowania jest uniwersalnym narzędziem określania poziomu zaawansowania uczniów na wszystkich poziomach procesu edukacyjnego.

Tworzenie testów na wysokim poziomie metodycznym wymaga od nauczyciela wypracowania jasnej struktury pojęciowej i terminologicznej kursu, tj. tabele pojęć i tez sprawdzonych w testach, uporządkowane według tematów i działów programu nauczania dyscypliny akademickiej.

Komputerowy system testowania jest integralną częścią przyszłego rozwoju nauczania na odległość.

W dzisiejszych czasach coraz częściej zaczęły pojawiać się gotowe narzędzia do tworzenia programów szkoleniowych. Co więcej, te wydarzenia są nie tylko obce (na przykład - Adobe akrobata, Macromedia Authorware, ToolBook II, Quest i inne), ale także krajowych (np. HyperMethod, Docent, Prometheus, powłoka sieciowa OROX, CADIS). Oto krótki opis niektórych z nich.

Jeden z systemów do przeprowadzania testów „Test Constructor” to uniwersalny system sprawdzania wiedzy (strona systemu - http://www.keepsoft.ru/simulator.htm). Program obsługuje pięć typów pytań: zamknięte (do wyboru jednej lub więcej odpowiedzi), otwarte (wprowadzenie odpowiedzi), dopasowywanie i porządkowanie. Pozwala to na przeprowadzenie dowolnych testów. Testy mają możliwość wykorzystania muzyki, dźwięków, obrazów i filmów. Wszelkie dane można wydrukować na drukarce. Kilka osób może samodzielnie przejść testy na jednym komputerze, wchodząc do programu pod własnymi nazwiskami.

Kolejny pakiet to system testowy INDIGO (strona internetowa - http://indigotech.ru/). W tym systemie można również stworzyć 5 rodzajów zadań testowych. Ale oprócz tego cechą konstruktora testów INDIGO jest obsługa wielopoziomowego hierarchicznego grupowania pytań testowych według zadań, tematów itp. W końcu, jeśli pytania testowe są wyświetlane na jednej liniowej liście, to pojawiają się trudności z nawigacją i zrozumieniem, które pytanie do czego się odnosi. W tym systemie możliwe jest ustawienie dla każdej grupy ustawienia indywidualne(w szczególności kolejność, w jakiej zagnieżdżone elementy są zwracane lub losowo wybierane).

Następnym rozważanym pakietem jest VeralTest - zestaw programów do tworzenia backtestów i organizowania testów komputerów wieloużytkownikowych (strona internetowa - http://veralsoft.com/veraltest.shtml). W systemie tym można tworzyć następujące typy rewersów testowych - zamknięte (wybór jednej odpowiedzi i wybór kilku odpowiedzi), wpisanie odpowiedzi tekstowej, wpisanie odpowiedzi liczbowej, pytania do korespondencji.

Pakiet oprogramowania VeralTest jest prezentowany w dwóch edycjach:

VeralTest Express. Umożliwia tworzenie samodzielnych, samoczynnych testów (testów exe), które można uruchomić na dowolnym komputerze bez preinstalacja i ustawienia. Skład pakietu VeraTest Express: edytor testów TestEditor oraz program ResultViewer do przeglądania wyników testów.

VeralTest Profesjonalny. Obsługuje wszystkie funkcje edycji ekspresowej. Dodatkowo w pakiecie znajduje się serwer testowy (program TestServer), który pozwala zorganizować testy w klasie komputerowej lub lokalna sieć przedsiębiorstw. W takim przypadku dostęp do testów odbywa się za pośrednictwem przeglądarki internetowej (np. Internet Explorer, Google Chrome, Mozila firefox). Ta edycja zawiera również program administracyjny TestAdmin, za pomocą którego można rejestrować użytkowników, łączyć ich w grupy, przydzielać użytkownikom testy do uruchamiania, przeglądać i drukować wyniki testów.

Oprócz tych systemów oprogramowania istnieje wiele innych systemów. Niektóre z nich można znaleźć na stronie - http://edu.of.ru/volsch31/default.asp?ob_no = 2300.

W tabeli przedstawiono charakterystykę niektórych narzędzi do tworzenia systemów testowych i porównano je.

Zastosowano do tego rodzaju narzędzia programowe są bardzo trudne do rozważenia pod kątem wydajności, ponieważ wpływ osoby (nauczyciela, który tworzy testy i ucznia, który odpowiada na test) jest ogromny. Jeżeli efektywność rozpatrywać z punktu widzenia szybkości sprawdzania testów, to wskaźnik ten w większym stopniu zależy od szybkości przesyłania informacji przez śieć komputerowa, od liczby pozycji testowych.

Jak widać z powyższego opisu i porównania możliwości, rozważane oprogramowanie może być wykorzystywane do testowania w różnych dyscyplinach, zarówno humanitarnych, jak i technicznych (ze względu na możliwość pracy z tekstem, grafiką, muzyką, multimediami).

Jeśli dasz 1 punkt za obecność każdej cechy, to okazuje się, że z rozpatrywanych systemów MOODLE otrzymał 22 punkty, UniTest System - 15, "Test Constructor" - 11, INDIGO - 14, VeralTest - 12 (wersja Express) i 16 (wersja profesjonalna).

Biorąc pod uwagę obecność systemu ustawień kolejności odsyłania testu, systemu interakcji przez sieć komputerową i inne czynniki, systemy MOODLE, INDIGO i VeralTest posiadają najbardziej zaawansowane możliwości. To właśnie te systemy są najczęściej wykorzystywane w praktyce podczas testowania uczniów.

Wniosek

Ocenę wskaźników jakości narzędzi programowych można przeprowadzić różnymi metodami i metodami. Przedstawiona w artykule metoda oceny jakości, oparta na zasadach normy ISO 9126, pozwala na:

Oceń jakość pakietów oprogramowania za pomocą różne systemy wskaźniki jakości;

Buduj jakość programów podczas tworzenia zakres zadań i kontrolować go na wszystkich etapach cyklu życia, tj. oceniać poziom minimalny jakość z niepełnymi informacjami na temat systemy oprogramowania, co osiąga się przy już uzyskanych wartościach wskaźników jakości;

Charakterystyka porównawcza niektórych narzędzi do tworzenia szkoleń

	Nazwa			„Konstruktor testowy”		VeralTest Express / Profesjonalny
	Niezawodność
	Kompletność (prawdopodobieństwo niepowodzenia)					Niskie wysokie
	Tolerancja błędów (działalność)
	Odzyskiwalność
	Dostępność systemu Zarezerwuj kopię
	Zapisywanie testów do oddzielny plik
	Wygoda użytkowania
	Łatwość nauki
	Dostępność wytyczne uczyć się
	Zrozumiałość
	Dostępność gotowe szablony testy		+ (w języku angielskim)
	Obecność wdrożonego system pomocy
	Wygoda i łatwość użytkowania
	Obecność menu (przycisku) do tworzenia testu
	Praca z grafiką
	Praca z dźwiękiem
	Tworzenie przycisków kontrolnych
	Możliwość automatycznej oceny odpowiedzi
	Ustalanie terminów odpowiedzi na pytania
	Dostępność funkcji wyznaczania czasu odpowiedzi na pytania
	Termin odpowiedzi na każde pytanie
	Ograniczenie całkowitego czasu na wykonanie testu
	Możliwość dzielenia pytań według poziomów trudności
	Funkcjonalność
	Dostępność środków ochrony (np. szyfrowanie testów)
	Możliwość pracy z lokalną siecią komputerową
	Praca w Internecie
	Wygoda akompaniamentu
	Dostępność usługi pomoc techniczna
	Dostępność oddzielnych modułów
	Obecność ustawień dla inżyniera
	Obecność ustawień dla nauczyciela
	Obecność ustawień dla testowanego
	Ruchliwość
	Dostępność wersji sieciowej				+ (internet)
	Zajęta objętość					20,8 MB / 60 MB

Oparte na zainstalowany system wskaźniki jakości, oceniają różne programy o tym samym celu, aby zidentyfikować najlepsze z nich.

Przy opracowywaniu wskaźników oceniających systemy do tworzenia testów za podstawę przyjęto cechy tego typu programów. W przyszłości możesz rozszerzyć listę rozważanych wskaźników, zmienić zgodnie z charakterystyką innych rodzajów narzędzi programowych.

Recenzenci:

Dorrer G.A., doktor nauk technicznych, profesor, kierownik. wydział, FSBEI HPE „Syberyjski Państwowy Uniwersytet Technologiczny”, Krasnojarsk;

Levshina V.V., doktor nauk technicznych, profesor, kierownik. Katedra Zarządzania Jakością i Matematycznych Metod Ekonomicznych, Syberyjski Państwowy Uniwersytet Technologiczny w Krasnojarsku.

Praca została odebrana 05.07.2013.

Odniesienie bibliograficzne

Gorbaczenko I.M. OCENA JAKOŚCI OPROGRAMOWANIA DO TWORZENIA SYSTEMÓW TESTOWYCH // Badania podstawowe. - 2013r. - nr 6-4. - S. 823-827;
URL: http://fundamental-research.ru/ru/article/view?id=31642 (data dostępu: 20.07.2019). Zwracamy uwagę na czasopisma wydawane przez „Akademię Nauk Przyrodniczych”

Oprogramowanie musi spełniać swoje funkcje, spełniać określone kryteria jakości, bezpieczeństwa i niezawodności. Ocena produktu, wymagania dla niego, dokumentacja projektowa to zadanie inżynierów zapewnienia jakości, czyli inżynierów QA.

Zapewnienie jakości oprogramowania obejmuje czynności, które są przeprowadzane na każdym etapie jego tworzenia. Celem jest zapewnienie, że produkt spełnia wymagania funkcjonalne i niefunkcjonalne.

Koncepcja jakości oprogramowania

Na pierwszy rzut oka „jakość oprogramowania” może wydawać się pojęciem abstrakcyjnym. Jednak dla kierowników projektów, programistów, testerów, inżynierów QA i innych osób zaangażowanych w proces rozwoju produktu kryteria jakości są przejrzyste i mierzalne. Przyjrzyjmy się najpierw ogólnej definicji.

Jakość oprogramowania to zbiór cech produktu oprogramowania, które określają zdolność do wykonywania przypisanych mu funkcji.

W chwili obecnej wskaźnik ten jest regulowany przez międzynarodową normę ISO/IEC 25010:2011. Ten standard ustanawia wielopoziomowy system oceny jakości oprogramowania oparty na ośmiu podstawowych cechach.

Parametry jakości oprogramowania

Główne cechy jakości oprogramowania wg ISO/IEC 25010:2011:

1. Funkcjonalność. Oprogramowanie uważa się za funkcjonalne, jeżeli wykonuje powierzone mu zadania, spełnia określone potrzeby użytkowników. Ten aspekt zakłada prawidłowe i dokładne działanie, kompatybilność wszystkich składników wchodzących w skład kompozycji.
2. Niezawodność. Przez niezawodność oprogramowania rozumie się nieprzerwaną realizację powierzonych mu zadań na określonych warunkach przez określony czas.
3. Użyteczność (łatwość użytkowania). Ten parametr charakteryzuje stopień przyjazności dla użytkownika oprogramowania, jego klarowność, łatwość obsługi i nauki.
4. Efektywność. Parametr odpowiada stopniowi, w jakim produkt zapewnia wymaganą wydajność w danych warunkach.
5. Wygoda akompaniamentu. Wskaźnik ten charakteryzuje łatwość analizy, testowania, korekty komponentów oprogramowania, jego utrzymania, a także stopień dostosowania do nowych warunków.
6. Ruchliwość. Łatwość, z jaką można go przenieść na inną platformę. Zapewnienie jakości oprogramowania polega na sprawdzeniu go pod kątem każdego z wymienionych parametrów, zidentyfikowaniu słabych punktów i wyeliminowaniu awarii.
7. Zgodność. Zdolność komponentów oprogramowania do interakcji ze sobą.
8. Bezpieczeństwo, czyli minimalizacja zagrożeń związanych z nieuprawnionym odczytem, ​​zmianami informacji itp. Zagrożenia mogą być również związane z nieprawidłowym użytkowaniem oprogramowania, wpływami zewnętrznymi osób nieuprawnionych, awarią środków technicznych.

Zapewnienie jakości i testowanie

Terminy „testowanie” i „zapewnienie jakości” są z pewnością powiązane, ale nie identyczne. Jaka jest różnica?

Zapewnienie jakości odpowiada za cały proces rozwoju i integruje się na wszystkich jego etapach: od tworzenia wymagań dla przyszłego rozwiązania po testowanie, wydanie produktu i utrzymanie po wydaniu.

Do zadań specjalistów QA należy:

• tworzenie kryteriów jakości;
• planowanie działań w celu spełnienia kryteriów na każdym etapie rozwoju produktu;
• dobór narzędzi testowych;
• testowanie produktu;
• Obliczanie KPI;
• zapobieganie błędom i doskonalenie procesów.

Testowanie- sprawdzenie oprogramowania pod kątem zgodności z wymaganiami.

Widzisz więc, że zapewnienie jakości to szersza koncepcja, która obejmuje prace testowe.

Testowanie może być zautomatyzowane lub może być wykonane ręcznie; może być pełnym cyklem lub mieć na celu sprawdzenie określonego aspektu jakości (bezpieczeństwo, produktywność, użyteczność itp.).

Inżynierowie testów przygotowują strategie testów i plan w oparciu o specyfikę projektu i wymagania dotyczące rozwiązania, tworzą i optymalizują zestaw przypadków testowych w przyszłości, wyszukują defekty, tworzą i wysyłają raporty o wykrytych defektach do programistów oraz weryfikują eliminację defektów.

Funkcja zapewnienia jakości może być wykonywana przez wewnętrzny dział firmy lub może być delegowana na niezależnego wykonawcę, który obiektywnie ocenia samo rozwiązanie, ustala procesy zapewnienia jakości, a tym samym pozwala wprowadzić na rynek produkt wysokiej jakości spełniający wymagania biznesowe i oczekiwania użytkowników.