www.eprace.edu.pl » iso-cmm » ISO 9001 » ISO 9000-3

ISO 9000-3

Wprowadzenie

Teoria stojąca u podstawy normy ISO 9000-3 mówi, że firma, która jest dobrze zarządzana i posiada zdefiniowany proces tworzenia produktu ma większą szansę wyprodukować oprogramowanie, które będzie całkowicie spełniało wymagania klienta, niż firma, która jest źle zarządzana i nie posiada zdefiniowanego procesu tworzenia produktu. Całkowite spełnienie wymagań użytkownika zawiera w sobie zarówno spełnienie wymagań dotyczących funkcjonalności i parametrów technicznych oprogramowania, jak i dotrzymanie zaplanowanych terminów i budżetu.

W dalszej konsekwencji, oczekuje się, że osoby odpowiedzialne za zakup oprogramowania i usług z nim związanych w swoim własnym interesie wybiorą tego dostawcę, który może się wykazać posiadaniem zalecanych przez normę ISO 9000-3 procesów tworzenia produktu oraz zarządzania.

Koncepcja

Najważniejszą koncepcją normy ISO 9000-3 jest to, że wytwarzanie i utrzymywanie oprogramowania jest wewnętrznie silnie zróżnicowanym, lecz spójnie zintegrowanym procesem, który składa się z różnych etapów, kroków, procedur i czynności. Proces ten wymaga też zintegrowanego podejścia do zarządzania. Podstawą tego podejścia jest ustanowienie przez najwyższe kierownictwo polityki jakości, która wymaga stosowania praktyk opisanych w procedurach przy pracach nad tworzeniem produktu. Z kolei zadaniem niższych szczebli zarządzania jest wprowadzanie w życie tej polityki oraz zarządzanie bardziej szczegółowymi procedurami i planami. Wszystkie szczeble zarządzania uczestniczą w procesie wytwarzania produktu przez wykonywanie przeglądów i auditów różnych projektów. Na podstawie wyników tych przeglądów i auditów kierownictwo tak steruje procesem wytwarzania, aby osiągnąć optymalną równowagę między funkcjonalnością, niezawodnością, użytecznością, kosztami i dotrzymaniem terminów.

Zagadnienia

Wytyczne normy ISO 9000-3 rozpięte są wokół trzech głównych zagadnień.

Po pierwsze, zarówno dostawca, jak i odbiorca produktu muszą spełnić pewne obowiązki.

Dostawca jest zobowiązany dostosować organizację zarządzania w firmie tak, aby móc sprawnie zarządzać procesem wytwarzania oraz stworzyć i zastosować sam proces. Najwyższe kierownictwo dostawcy musi najpierw opracować politykę jakości, która określa dla całej firmy wytyczne co do działań mających na celu wytwarzanie produktu o wysokiej jakości.

Z kolei kierownictwo klienta odpowiedzialne jest za zapewnienie, że wymagania co do produktu oraz związanych z nim usług są jednoznacznie i precyzyjnie określone, prośby o zmiany w tych wymaganiach zostały autoryzowane oraz że odbiorca jest gotowy do odbioru gotowego produktu po pomyślnym przejściu testów odbiorczych.

Drugim zagadnieniem jest podział całego procesu wytwarzania na poszczególne etapy.

Główne etapy to:

Każdy etap musi posiadać zdefiniowane dane wejściowe i wyjściowe. Definiuje się zakresy obowiązków i odpowiedzialności dla szeregu pracowników uczestniczących w tym procesie. Określa się środki i narzędzie służące do testowania produktu oraz jego części na różnych etapach procesu wytwarzania. Punktem wyjścia dla tych działań jest polityka jakości. Tworzony jest system jakości. Dodatkowo, proces wytwarzania musi być zarządzany według planów, które określają terminarz prac, zasoby oraz mechanizmy pozwalające na określenie bieżącego statusu prac. Plany muszą też definiować procedury dotyczące przeglądów i auditów, których przeprowadzanie jest niezbędne dla zapewnienia, że produkt spełnia wymagania klienta.

Trzecie zagadnienie odnosi się do działań wspierających procesy samego tworzenia oprogramowania oraz testowania i tworzenia dokumentacji. Działania te to:

Należy sporządzić plany dotyczące realizacji tych działań oraz przydzielić zasoby potrzebne do ich wykonania.

Interpretacja

Wytyczne normy ISO 9000-3 wymagają utworzenia udokumentowanego procesu wytwarzania. Oprócz tego niezbędne są przeglądy rezultatów wykonywania procesu oraz audity samego procesu. Dodatkowo, muszą zostać zaplanowane zasoby potrzebne do realizacji procesu, przeglądów i auditów.

Polityka jakości

Pierwszym dokumentem, jaki zostaje utworzony jest polityka jakości. Jest ona sporządzona i podpisana przez najwyższe kierownictwo firmy. Polityka jakości stanowi raczej krótki dokument o charakterze ogólnym, tak iż stosuje się do wszystkich obszarów firmy, które tylko mają związek z jakością. Najważniejszym jej celem jest określenie podejścia najwyższego kierownictwa firmy do problematyki jakości i wyznaczenie głównych wytycznych dotyczących realizacji celów związanych z zapewnieniem jakości w obrębie całej organizacji. Najczęściej polityka jakości zobowiązuje różne części firmy, czyli np. dział techniczny, dział marketingu, dział sprzedaży, dział finansowy, do postępowania według powszechnie przyjętych zasad w sferze technicznej i biznesowej. Dodatkowo dokument ten wyznacza zakres ról i odpowiedzialności dla poszczególnych działów.

Środowisko wytwarzania

Powyższa interpretacja jest do pewnego stopnia niestandardowa, jednakże należy pamiętać, że ważnym zadaniem dla najwyższego kierownictwa w świetle norm ISO 9000 jest zaangażowanie w kreowanie środowiska wytwarzania. Kierownictwo musi jasno i precyzyjnie zdefiniować, co należy rozumieć pod pojęciem środowiska wytwarzania. Jest to niezbędne dla uniknięcia sporów i niejasności przy realizacji tego środowiska.

Znaczenie środowiska wytwarzania można wyjaśnić następująco. Najważniejszym celem kierownictwa firmy jest osiągnięcie jak najwyższych zysków. Aby to osiągnąć, firma musi korzystać ze swoich zasobów w możliwie jak najbardziej efektywny sposób. Dlatego na kierownictwie spoczywa odpowiedzialność za zapewnienie, że na całym obszarze przedsiębiorstwa stosowane są najbardziej efektywne praktyki tak w sferze technicznej, jak i biznesowej. Musi też zostać stworzona sytuacja, w której poszczególne działy firmy posiadają jednolity pogląd na zakres swoich obowiązków i odpowiedzialności, co pozwala uniknąć sporów na tym tle.

Opisane wyżej czynniki sprawiają, że polityka jakości musi zawierać nieco więcej treści, niż tylko ogólną deklarację najwyższego kierownictwa co do chęci spełniania zaleceń zawartych w normach ISO 9000. Musi ona też określać w ogólnych, ale skonkretyzowanych zarysach obszary odpowiedzialności i prac dla poszczególnych działów firmy. Muszą też zostać zdefiniowane praktyki i procedury, według których będą wykonywane wszelkie czynności mające związek z jakością. Na tej podstawie będą budowane bardziej szczegółowe opisy procedur.

Proces jakości

Norma ISO 9000-3 definiuje proces jakości jako implementację polityki jakości. Oczywiście, proces jakości musi zostać starannie udokumentowany. Dokumentacja ta jest najczęściej nazywana w literaturze podręcznikiem jakości. Nasuwa się tutaj uwaga, że nazywanie wszystkiego pojęciem jakość ma tą wadę, że może wprowadzić pewne zamieszanie i przesłonić kwestie związane przede wszystkim z wytwarzaniem produktu. Dlatego dokument służący do zdefiniowania procesu wytwarzania oprogramowania będzie tutaj nazywany podręcznikiem procesu wytwarzania. Podręcznik procesu wytwarzania faktycznie definiuje proces wytwarzania będący realizacją polityki jakości. Podręcznik ten musi zostać przeglądnięty i zatwierdzony przez najwyższe kierownictwo firmy aby zagwarantować, że dobrze realizuje on cele polityki jakości.

Plan wytwarzania oprogramowania

W wytycznych występuje w dużym stopniu pokrywanie się zagadnień poruszanych w podręczniku procesu wytwarzania, czyli w podręczniku jakości, w planie jakości oraz w planie wytwarzania. Może to prowadzić do pewnych nieporozumień. Zakładamy, że każdy projekt dotyczący implementacji i utrzymywania oprogramowania posiada plan, w którym definiuje się zasoby, terminarz prac i specyficzne podejście niezbędne do tego, aby wprowadzić w życie proces wytwarzania wyrobu opisany w podręczniku procesu wytwarzania. Chodzi tutaj szczególnie o fazy analizy, projektowania i implementacji. Plan ten nazywa się planem wytwarzania oprogramowania. Zakłada się także, że plan ten zawiera w sobie lub pokazuje odnośniki do bardziej szczegółowych planów niższego rzędu, np. planu zarządzania konfiguracją, planu testów, planu kontroli dokumentów.

Plan zapewnienia jakości

Wydaje się, że bardzo potrzebny jest plan zapewnienia jakości, lecz plan ten powinien poruszać przede wszystkim kwestie identyfikowania działań, terminów i zasobów potrzebnych do wykonywania auditów procesu, weryfikacji danych dostarczonych z zewnątrz, analizy błędów i sporządzania raportów. Co za tym idzie, uznajemy, że tylko te zagadnienia wchodzą w skład planu zapewnienia jakości.

Słabe punkty

Używanie pojęcia jakości

Dużym powodem do krytyki jest sposób, w jaki używane jest słowo jakość. Wytyczne normy definiują, że każde działanie, procedura, czynność lub osoba, które na jakimkolwiek poziomie mają związek ze specyfikacją, implementacją, testowaniem i utrzymywaniem oprogramowania, ma udział w pracach mających wpływ na jakość. Umieszczanie wszystkiego pod pojęciem jakości powoduje w pewnym stopniu rozmycie granic między działaniami mającymi na celu wytworzenie i utrzymywanie produktu (analiza, projektowanie, implementacja, testowanie, kontrola konfiguracji, przeglądy) a działaniami opisywanymi w dokumentach zapewnienia jakości (audity, inspekcje, pomiary), które mają za zadanie zagwarantowanie jakości produktu oraz samego procesu jego wytwarzania. Dodatkowo, wytyczne stanowią, że prawie każdy jest odpowiedzialny za jakość, dlatego trudno jest jasno zdefiniować zakresy ról, Odpowiedzialności i kompetencji dla poszczególnych członków personelu zaangażowanych w działania związane z wytwarzaniem i zapewnieniem jakości.

Pominięcie fazy szczegółowej specyfikacji oprogramowania

Kolejny powód do krytyki to pominięcie przez normę ISO 9000-3 jednej z faz tworzenia oprogramowania, jaka występuje w większości projektów: fazy szczegółowej specyfikacji oprogramowania. W każdym dużym i skomplikowanym projekcie wykonuje się szczegółową analizę specyfikacji oprogramowania w tym celu, aby na podstawie ogólnych wymagań klienta stworzyć specyfikację o takim poziomie szczegółowości, że możliwe jest na jej podstawie rozpoczęcie implementacji, a potem testowania. Norma wychodzi od identyfikacji wymagań klienta (sekcja 5.3) wprost do dyskusji nad planem implementacji.

Wymagania normy odnośnie planu jakości

Trzeci z kolei punkt, który może podlegać krytyce to wymagania normy odnośnie planu jakości (sekcja 5.5). Norma stanowi, że plan jakości definiuje dużą ilość zagadnień, z których wiele przynależy faktycznie do dokumentacji definiującej proces wytwarzania lub też do specyficznych planów dotyczących implementacji i testowania produktu. Przykładowo, punkt opisany jako „zdefiniowane wejście i wyjście dla każdej fazy wytwarzania produktu oraz rodzaje testów, weryfikacji i walidacji, jakie należy wykonać” powinien zostać zdefiniowany jako część procesu wytwarzania. Dodatkowo, punkt „szczegółowe planowanie testów, weryfikacji i walidacji, w tym terminarze prac, zasoby oraz osoby zatwierdzające” należy faktycznie do planu implementacji oprogramowania (sekcja 5.4.2) lub do planu testów (sekcja 5.7.2). Z kolei zadanie realizacji punktu „zarządzanie konfiguracją, kontrola zmian, kontrola defektów oraz działania naprawcze” spoczywa na planie zarządzania konfiguracją (sekcje od 6.1.2 do 6.1.3.2).

Wydaje się, że wiele działań zdefiniowanych w planie jakości jako działania mające bezpośredni związek z zapewnieniem jakości są to w rzeczywistości działania związane bardziej z wytwarzaniem produktu i powinny zostać włączone do definicji procesu wytwarzania oraz do planów dotyczących realizacji tego procesu. Z drugiej strony, działania takie, jak audity mające na celu zapewnienie jakości, inspekcje i pomiary należą w planie jakości do działań podlegających nie pod wytwarzanie oprogramowania, ale pod zapewnianie i mierzenie jakości produktu.

Zawartość planu wytwarzania

Kolejny powód do krytyki odnosi się do sekcji 5.4.2, która opisuje zawartość planu wytwarzania. Można odnieść wrażenie, że sekcja 5.4.2.1 może być cokolwiek niejasna. Przykładowo, norma mówi tak: „Zaleca się, aby plan opracowywania określał precyzyjnie opisany proces lub metodologię przekształcania specyfikacji wymagań nabywcy w wyrób programowy.” Krytyce podlega słowo „określa”. „Precyzyjnie opisany proces” powinien zostać określony już wcześniej, kiedy odbywało się dokumentowanie procesu jakości. Nie ma potrzeby powtórnego określania tego procesu w planach opracowywania osobno dla każdego działania związanego z wytwarzaniem. Plan powinien identyfikować specyficzną realizację procesu wytwarzania oraz zasobów i terminarza prac potrzebnych do realizacji tego procesu.

Ostatni punkt budzący wątpliwości dotyczy już sprawy mniej istotnej. Sekcja 5.4.2.1 wydaje się pokrywać w treści z następnymi sekcjami. Identyfikacja danych wejściowych i wyjściowych oraz weryfikacja procedur dla każdej fazy wytwarzania są omówione w sekcji 5.4.4 (Dane wejściowe do etapów opracowywania), w sekcji 5.4.5 (Dane wejściowe do etapów opracowywania) oraz w sekcji 5.4.5 (Weryfikacja każdego etapu).

Najczęściej popełniane błędy

Konflikty kompetencji

Kolejny powód do krytyki jest jednocześnie krytyką i poważnym ostrzeżeniem dla firm, które planują dostosowanie swojego schematu organizacyjnego do wytycznych normy ISO 9000-3. Sekcja 4.1.1.2.3 (Przedstawiciel kierownictwa) stanowi, że przedstawiciel kierownictwa powinien mieć określone uprawnienia i odpowiedzialność w celu zapewnienia, że wymagania normy ISO 9001 są wprowadzane i przestrzegane.” Wątpliwym słowem jest tutaj „zapewnienie”. Kiedy pracownik posiada odpowiedzialność i uprawnienia dla „zapewnienia”, że coś zostanie wykonane, wtedy taka osoba może wydawać polecenia innym pracownikom w zakresie technicznym i w zakresie zarządzania. Pracownik ten posiada teraz uprawnienia wykonawcze, w odróżnieniu od uprawnień do zarządzania personelem. Przypisanie tej funkcji do menedżera odpowiedzialnego za zarządzanie personelem prawie zawsze będzie powodowało konflikty z menedżerami do spraw technicznych.

Firmy powinny zdecydować, kto jest odpowiedzialny za terminarz zajęć i za budżet. Odpowiedni menedżer powinien otrzymać stosowne kompetencje określone w sposób klarowny i jednoznaczny, aby uniknąć konfliktów z innymi pracownikami spowodowanych nakładaniem się kompetencji.

Rozdzielenie zakresów odpowiedzialności

Wydaje się dobrym rozwiązaniem, żeby naczelny menedżer wykonawczy był odpowiedzialny za zapewnienie, że wymagania klienta są realizowane. Naczelny menedżer wykonawczy może zlecić podległym sobie menedżerom lub inżynierom przeprowadzenie auditów procesu i przedstawienie ich wyników. Na podstawie tych wyników naczelny menedżer wykonawczy może wydać dyspozycje potrzebne dla zapewnienia realizacji wymagań klienta. Druga sugestia dotyczy tego, żeby jeden ze starszych menedżerów, najlepiej już na szczeblu dyrektorskim, był odpowiedzialny za wprowadzenie programu zapewnienia jakości wraz z przeglądami efektów pracy nad projektem, pomiarami i szkoleniami. Menedżer ten przedstawiał by raporty ze swoich prac naczelnemu dyrektorowi firmy.

Ogólna koncepcja podejścia do jakości oprogramowania

Poniżej zostało przedstawione ogólne rozumienie inżynierii oprogramowania, obejmujące całą organizację. Rozumiejąc istotę takiego podejścia, wiele firm może spróbować zaimplementować mechanizmy opisane w normie ISO 9000-3. Mechanizmy te mają w znacznej mierze dopomóc w tworzeniu w wysokim stopniu niezawodnych produktów.

Rzut oka na historię

Od ponad dwudziestu lat w branży oprogramowania istniała świadomość istnienia procesu specyfikacji, projektowania, implementacji i testowania programów, opartego na zasadach, praktykach i akceptowanych metodologiach inżynierii. Nadal jednak, pomimo że twórcy oprogramowania posiadają wiedzę o tych procesach i usilnie starają się je stosować, końcowe efekty ich pracy często nie spełniają minimalnych wymagań postawionych przez klientów, inwestorów, czy nawet przez samych projektantów.

Rzeczywistość pokazuje, że zespoły projektantów i programistów zaskakująco rzadko osiągają wyznaczone cele, jeżeli chodzi o funkcjonalność, parametry techniczne czy też niezawodność; na domiar złego najczęściej przekraczane są przy tym terminy i budżety projektów. W przeszłości nie sprawiało trudności przejrzenie tego rodzaju błędów. Produkcja oprogramowania odbywała się na mniej formalnych zasadach. W takiej sytuacji ścisłe przestrzeganie formalnych zasad inżynierii oprogramowania i sztywny podział na etapy tworzenia mogły niszczyć kreatywność projektantów.

Jeżeli chodzi o klientów, przyjmowali oni bez większych generalnych zastrzeżeń oferowane produkty, gdyż odczuwali oni rosnące zapotrzebowanie na aplikacje, które niosły rozwiązania dla ich specyficznych problemów, często będących dużymi wyzwaniami, decydującymi o wyprzedzeniu o krok konkurencji. Przez to producenci oprogramowania nie przywiązywali wagi do tego, że ich wyroby sprzedają się dlatego, że albo nie mają żadnej konkurencji, albo inne rozwiązania są znacznie gorsze.

Sytuacja obecna

Obecnie sytuacja wygląda zupełnie inaczej. Aplikacje są bez porównania większe i bardziej skomplikowane. Od systemów komputerowych żąda się już nie tylko podania mniej lub bardziej optymalnego rozwiązania problemu, ale także bardzo wysokiej niezawodności, kiedy stanowią one kluczowe ogniwo większego systemu. Dlatego produkcja oprogramowania stała się dobrze zdefiniowaną dyscypliną inżynierską. Dodatkowo, rynek odbiorców coraz lepiej orientuje się w tym, czego ma się spodziewać ze strony programów i nie toleruje ani niskiej jakości, ani ukrytych kosztów utrzymywania oprogramowania.

Najważniejsze cele normy ISO 9000-3

Organizacja ISO wyszła naprzeciw problemom związanym z zapewnieniem jakości oprogramowania tworząc normę ISO 9000-3. Norma ta faktycznie odzwierciedla życzenia użytkowników aplikacji odnośnie ich niezawodności i funkcjonalności. Nie zawiera ona wskazówek, jak należy analizować, projektować, kodować, testować czy dokumentować oprogramowanie. Zamiast tego norma wymaga, aby producent zdefiniował proces obejmujący wszystkie te etapy i czynności oraz aby proces ten był poprawnie udokumentowany i realizowany. Podstawowe założenie, na którym opiera się norma, mówi, że jeżeli zdefiniowany proces będzie realizowany, pozwoli to w dużym stopniu dostarczać klientom aplikacje o lepszej jakości, z dotrzymaniem zaplanowanych terminów i budżetów.

Istota inżynierii oprogramowania

Spróbujemy najpierw przedstawić w ogólnym zarysie, jak cały proces tworzenia oprogramowania wygląda w opisie teoretycznym, bez uwzględnienia problemów i komplikacji związanych ze zdarzeniami i czynnikami, jakie niesie rzeczywisty świat. Pomoże to w zrozumieniu, w jaki sposób norma ISO 9000-3 pomaga w zwalczeniu tych komplikacji, tak aby otrzymać końcowy produkt o wysokiej jakości.

Definicja inżynierii oprogramowania

Istnieje wiele definicji inżynierii oprogramowania. Najbardziej klasyczna brzmi tak:

Inżynieria oprogramowania jest to zdefiniowany krok po kroku proces, który ułatwia specyfikację, projektowanie, implementację i testowanie oprogramowania według zbioru ustalonych wymagań w możliwie jak najszybszy i najefektywniejszy finansowo sposób [Kehoe 96].

Definiowanie procesu

Wszelkie czynności związane z tworzeniem i utrzymywaniem oprogramowania muszą być przeprowadzane według zdefiniowanego procesu. Proces ten pełni następujące funkcje:

Muszą także zostać utworzone procesy dotyczące przeglądów wykonywanych zarówno pod kątem technicznym, jak i pod kątem zarządzania zasobami i projektem. Są one niezbędne, aby stale kontrolować techniczną poprawność wykonywanych prac oraz czuwać nad właściwym przebiegiem projektu, włączając w to dotrzymywanie terminów, gospodarkę zasobami i budżetem.

Zidentyfikowanie potrzeb klienta

Pierwszym etapem w procesie tworzenia oprogramowania jest stworzenie "mapy" potrzeb klienta. Klient zawiera w sobie wiele różnych klas użytkowników mających zróżnicowane potrzeby i wymagania. Analityk podejmuje rozmowy z klientem w celu zdefiniowania jego potrzeb oraz wyraźnego oddzielenia potrzeb rzeczywistych od potrzeb subiektywnie odczuwanych.

Sporządza się dokument, w którym potrzeby te zostają zapisane jako dość ogólne wytyczne funkcjonalne i techniczne. Wymagania te zostają następnie bardziej szczegółowo opisane i uszeregowane według priorytetów w dokumencie formalnie definiującym wymagania klienta, podpisanym przez obie strony. Na podstawie tych dokumentów dostawca produktu może określić szacowane całkowite koszty wytworzenia oraz termin, w jakim aplikacja może zostać dostarczona klientowi.

Szacunki oparte są na wymaganiach klienta, posiadanym przez dostawcę doświadczeniu w wytwarzaniu tego rodzaju produktów oraz na analizie spójnego, zdefiniowanego procesu tworzenia oprogramowania. Priorytety klienta oraz oszacowane koszty są mierzalnymi parametrami i stanowią bazę dla podejmowania racjonalnych decyzji na szczeblu zarządzania projektem. Pozwala to stworzyć działający model funkcjonalny przyszłego produktu, a także oszacować całkowite koszty projektu i datę jego sfinalizowania. Kierownictwo wysokiego szczebla podejmuje decyzję o rozpoczęciu realizacji projektu i od tego momentu ruszają prace.

Analiza

Na podstawie ogólnej definicji wymagań klienta projektanci rozpoczynają szczegółową analizę, której wynikiem jest specyfikacja oraz bardziej dokładne określenie kosztów i terminarza prac. Także tutaj wyniki analizy oparte są o mierzalne parametry otrzymane z wcześniejszych etapów działań. W następnym kroku kierownictwo przegląda oszacowane koszty i terminarz prac. Jeżeli są one w zadowalającym stopniu zgodne z oczekiwaniami, prace nad projektem są dalej prowadzone normalnym trybem.

Korekty wcześniejszych założeń

Jeżeli jednak rezultaty analiz znacznie odbiegają od wcześniej założonych kosztów i terminów, należy podjąć odpowiednie kroki dotyczące zarówno aspektów technicznych, jak i marketingowych. Należy podjąć jedną lub kilka z niżej wymienionych akcji:

Bardzo ważną kwestią jest zachowanie równowagi między interesami marketingowymi, biznesowymi i technicznymi, które zwykle są wzajemnie sprzeczne. Równowaga ta pociąga za sobą pewne niepożądane ryzyko, które musi zostać odpowiednio skalkulowane w miarę posuwania się naprzód prac nad projektem.

Proces tworzenia oprogramowania

W momencie, kiedy są zidentyfikowane budżet, terminarz prac i wytyczne techniczne, można rozpocząć proces tworzenia oprogramowania, czyli projektowanie, kodowanie, pisanie dokumentacji oraz testowanie. Kierownicy zespołów projektowych przekazują do kierownictwa firmy okresowe sprawozdania o stanie prac z określeniem wymiernych wskaźników liczbowych. Umożliwia to ocenę, czy postępy prac nad projektem są zgodne z wcześniejszymi założeniami. W razie wystąpienia rozbieżności kierownictwo może podjąć odpowiednie kroki, czyli dostosować przebieg tworzenia oprogramowania, specyfikację produktu lub założenia biznesowe.

Rysunek 4.2. Schemat ogólny procesu wytwarzania oprogramowania


Główne problemy występujące w praktyce

Przejdźmy teraz do bardziej realistycznego podejścia do całego procesu. W rzeczywistości w znakomitej większości przypadków potrzeby klienta nie są zdefiniowane w wystarczającym stopniu szczegółowo i jasno. Specjaliści z działu marketingu lub działu technicznego często zbyt pospiesznie wykonują analizę, aby przyspieszyć datę wypuszczenia produktu na rynek lub przekazania go klientowi. Rezultatem tego jest dość luźno powiązany zbiór słabo sprecyzowanych i nieuszeregowanych wytycznych.

Projektanci usiłują następnie w kolejnych przybliżeniach ustalić bardziej precyzyjnie wymagania odnośnie wyrobu, zasoby potrzebne do jego wytworzenia oraz terminy, w których może on być dostarczony klientowi. Końcowym efektem tych wysiłków jest pełna specyfikacja wyrobu. Sytuację pogarsza fakt, że w większości wypadków firmy software'owe nie posiadają dobrze zdefiniowanego procesu wytwarzania i w związku z tym nie potrafią żadnym sposobem opracować spodziewanego kalendarza prac nad projektem i oszacować wydatków finansowych oraz przewidzieć, jakie zasoby będą potrzebne do jego realizacji. Brak jest dokładnych, sprecyzowanych, czytelnych i uszeregowanych wytycznych oraz oszacowań kosztów opartych o zdefiniowany proces wytwarzania i o dotychczasowe doświadczenia firmy w tworzeniu podobnego oprogramowania. Dlatego zwykle potrzeba wielu godzin dodatkowych dyskusji między klientem a specjalistami z działu technicznego, działu marketingu oraz kierownictwa dostawcy produktu. Dyskusje te mają na celu ustalenie wspólnego stanowiska co do cech funkcjonalnych i technicznych wyrobu, jego jakości, kosztów oraz terminów dostarczenia i instalacji poszczególnych komponentów klientowi. Tego rodzaju dyskusje kończą się niestety najczęściej kompromisem, który jest daleki od oczekiwań obu stron, a jeszcze dalej odbiega od tego, co dostawca może rzeczywiście zrealizować.

Także w trakcie prac nad projektem pojawiają się rozmaite trudności. Rozpoczyna się od problemów z dostarczaniem okresowych raportów o stanie zaawansowania projektu. Często raporty te docierają do kierownictwa nieregularnie i nie zawierają najważniejszej treści, czyli wskaźników wprost wyrażonych liczbowo, które pozwalają określić stopień zaawansowania prac w poszczególnych gałęziach projektu. Kierownictwo nie posiada zatem danych na temat przebiegu projektu, dlatego nie może ustalić, czy posuwa się on zgodnie z planem oraz jakie ewentualne korekty należy wnieść do terminarza prac, budżetu, specyfikacji projektowej czy też do samego procesu, tak aby możliwe było osiągnięcie wyznaczonych celów z uwzględnieniem posiadanych obecnie oraz przyszłości zasobów.

Ryzyko

W większości przypadków nie uwzględnia się ryzyka i nie planuje się środków zaradczych z tym związanych. Ryzyko musi być w szczególny sposób brane pod uwagę w branży związanej z pisaniem oprogramowania, gdzie występuje ono bardzo silnie. Od samego początku należy zwrócić uwagę na zarządzanie w sytuacjach niepowodzeń. Tymczasem brak zarządzania ryzykiem prowadzi do tego, że kierownictwo wszystkich szczebli musi niejednokrotnie stawać w obliczu trudnych i niespodziewanych sytuacji, w których bardzo trudno jest zwalczyć narastające problemy.

Model proponowany przez normę ISO 9000-3

Norma ISO 9000-3 proponuje model, który pomaga przybliżyć rzeczywisty przebieg projektu do idealnego modelu. Działania opisane w normie dotyczą zarówno klienta, jak i dostawcy. Prezentuje ona proces wytwarzania wyrobu, w tym przypadku oprogramowania, który można dostosować do potrzeb konkretnej firmy i konkretnego projektu.

Norma ISO 9000-3 definiuje cały wachlarz terminów, dzięki którym klient, dostawca, podwykonawcy i wszystkie inne podmioty mające związek z projektem mogą precyzyjnie definiować omawiane kwestie.

Zdefiniowanie procesu wytwarzania zyskuje coraz większe znaczenie dla producentów oprogramowania i oczywiście dla klientów. Klienci wymagają od dostawcy posiadania i stosowania procesu, co daje pewność otrzymania oprogramowania wysokiej jakości w większym stopniu, niż jakiekolwiek wymagania techniczne i funkcjonalne. Z kolei dla dostawcy wdrożenie normy ISO 9000-3 oznacza nie tylko znaczne poprawienie swojej pozycji na rynku, ale także pozwala na lepsze zarządzanie projektami i zasobami firmy, obniżenie kosztów własnych oraz skuteczniejsze zarządzanie ryzykiem.

Analiza systemów i procesów

Istota analizy

Analiza, w swej istocie, polega na rozkładaniu dużych, skomplikowanych problemów na mniejsze problemy, które są łatwiejsze do ogarnięcia i które mogą być rozpatrywane do pewnego stopnia w izolacji od całości. Cały system może zostać podzielony na mniejsze komponenty przy użyciu dekompozycji funkcjonalnej lub zorientowanych obiektowo metodologii. Poszczególne komponenty są następnie oddzielnie projektowane, implementowane i testowane, a na koniec łączone razem w kompletny system.

Analiza procesu tworzenia oprogramowania

Także sam proces tworzenia oprogramowania można poddać dekompozycji. Proces ten może zostać podzielony albo na podprocesy, albo na kroki. Każdy z nich ma zdefiniowane dane wejściowe, generowane dane wyjściowe oraz wewnętrzne mechanizmy i metodologie. Proces tworzenia oprogramowania składa się z kilku faz: analizy, projektowania, implementacji, testowania, integracji i utrzymywania. Integracja w tym przypadku oznacza integrację z innymi systemami i środowiskami. Każda faza składa się z szeregu kroków. Jest bardzo ważne, aby poprawnie zdefiniować dane wejściowe i spodziewane dane wyjściowe dla każdej fazy i kroku. Pozwala to kontrolować przepływ danych i ich poprawność na wejściu i wyjściu każdej fazy czy kroku. Dzięki temu możliwe jest wykrywanie problemów i błędów na bardzo wczesnym etapie i sprawne lokalizowanie ich przyczyn. Najbardziej typowe źródła błędów na tym etapie to wadliwe działanie procesu lub brak procesu tam, gdzie jest on niezbędny, niedostatek wiedzy i umiejętności personelu, uwarunkowania środowiska, niepoprawne zarządzanie. Po określeniu przyczyn powstawania nieprawidłowości można przystąpić do ustalenia sposobu naprawienia sytuacji. Przy wyborze środków zaradczych muszą zostać uwzględnione dostępne zasoby oraz budżet projektu. Następnie przystępuje się do realizacji ustalonych działań, co powinno zaowocować usunięciem źródeł błędów i zniknięciem nieprawidłowości.

Schemat dla planów, specyfikacji, procesów i procedur

Każdy etap procesu wytwarzania oprogramowania musi posiadać następujące elementy:

Trudno stworzyć proces, który byłby uniwersalny i zdawał egzamin w zawsze i w każdej sytuacji. Można jednak wyróżnić pewne zasady, praktyki i procedury, które znajdują zastosowanie w większości przypadków. Proces wytwarzania musi zostać dostosowany do konkretnego projektu, z uwzględnieniem wymagań klienta, budżetu oraz terminów. Dla sprawności procesu ważne jest to, aby wzięte zostały pod uwagę mocne i słabe strony danej firmy. Norma ISO 9000-3 w swej istocie nie gwarantuje wytworzenia produktu wysokiej jakości, ale w dużym stopniu pomaga osiągnąć ten cel.

Fazy procesu tworzenia oprogramowania

Poniżej zostało opisane siedem głównych faz, które składają się na proces tworzenia oprogramowania. Zostały one opisane w ujęciu ogólnym, co pozwala na określenie podstawowych zarysów procesu dla konkretnej firmy. Każda organizacja posiada odmienne potrzeby, używa różnej terminologii i pisze oprogramowanie o różnym charakterze. Przedstawiony w tym miejscu opis nie wgłębia się w takie szczegóły, ale pozwala raczej zrozumieć generalne zasady dotyczące poszczególnych faz.

a) Analiza systemowa

W trakcie tej fazy ustala się między klientem a dostawcą wspólne zrozumienie co do najważniejszych i najbardziej ogólnych cech funkcjonalnych i technicznych oprogramowania. Wymagania klienta zostają zidentyfikowane i udokumentowane na razie na poziomie ogólnym. Danymi wejściowymi do tej fazy są wstępne deklaracje ze strony klienta dotyczące jego potrzeb. Cały proces wykonywany podczas tej fazy polega na wyszczególnieniu, sprecyzowaniu i udokumentowaniu funkcjonalnych i technicznych wymagań klienta oraz konfiguracji oprogramowania. Dane wyjściowe z fazy analizy systemowej nazywane są najczęściej dokumentacją wymagań klienta, specyfikacją funkcjonalną lub też specyfikacją systemową. Dokument będący końcowym efektem prac musi zostać skontrolowany i potwierdzony zarówno przez klienta, jak i przez dostawcę. Dokument ten następnie może służyć jako podstawa dla zawarcia kontraktu między obiema stronami, dlatego muszą być w nim wyraźnie i jednoznacznie wyrażone wymagania klienta. Obie strony muszą też uzgodnić najbardziej ogólne zarysy kosztorysu i terminów dostarczenia poszczególnych części produktu do klienta. W fazę analizy systemowej zaangażowani są przede wszystkim przedstawiciele klienta i przyszli użytkownicy, a ze strony dostawcy pracownicy działu marketingu i inżynierowie systemowi, a w znacznie mniejszym stopniu programiści i osoby zajmujące się testowaniem.

b) Analiza specyfikacji oprogramowania

Faza ta jest w pewnym sensie kontynuacją i rozwinięciem fazy poprzedniej. Jej zadaniem jest stworzenie szczegółowej specyfikacji produktu, na której podstawie będzie można projektować i implementować oprogramowanie. Danymi wejściowymi dla tej fazy jest dokumentacja wyjściowa z fazy analizy systemowej. Dane wyjściowe to dokumentacja dotycząca oprogramowania, która ma zawierać szczegółowe wymagania funkcjonalne i techniczne, opis algorytmów, sposób obsługi błędów oraz zewnętrzne przepływy danych. Dokumentacja ta powinna również zawierać konkretne dane co do przewidywanych kosztów i kalendarza prac dla kolejnych etapów związanych z implementacją, testowaniem i tworzeniem dokumentacji. Główny ciężar prac w trakcie trwania tej fazy spoczywa na inżynierach oprogramowania, inżynierach systemowych i pracownikach wykonujących testowanie.

c) Projektowanie

Prace wykonywane w ramach tej fazy mają na celu stworzenie pełnego projektu obejmującego strukturę logiczną, architekturę, sposób obsługi błędów, interfejs użytkownika, dokumentację użytkownika (obejmuje to także pomoc dostępną w programie), modele danych oraz sposoby testowania. Projekt ten ma stanowić bazę dla implementacji, a później testowania oprogramowania. Tworzona jest struktura produktu, czyli system wzajemnych zależności komponentów do pewnego stopnia szczegółowości. Projekt jest także kolejnym przedstawieniem, tym razem pod nieco innym kątem, wymagań użytkownika. W fazie projektowania tworzy się także specyfikację określającą dokumentację projektowania, testowania i dokumentację użytkownika. Czynności fazy projektowania są generalnie wykonywane przez inżynierów oprogramowania, programistów oraz personel wykonujący testy.

d) Implementacja

Najważniejsze zadania fazy implementacji przedstawiają się następująco:

Także do tej fazy należą pewne działania testujące: sprawdzanie kodu, testowanie pojedynczych komponentów, przegląd dokumentacji. Wynikiem prac tej fazy mają być komponenty gotowe do testowania funkcjonalnego i technicznego na wyższym poziomie integracji.

Wszystko to, co związane jest z oprogramowaniem można podzielić na składowe takie jak środowisko programowania, kod źródłowy, narzędzia do testowania (w tym same narzędzia jako aplikacje, materiały do testowania, rezultaty testów), czy też dokumenty techniczne (np. procedury, standardy, plany testów, dokumentacja techniczna, specyfikacje produktu lub projektu). Poszczególne składowe oddziałują na siebie, w związku z czym zmiany w jednej ze składowych pociągają za sobą konieczność wprowadzenia zmian do innych składowych. Dotyczy to automatycznie także zespołów ludzi pracujących nad różnymi składowymi; muszą oni komunikować się ze sobą, gdyż efekty pracy jednego zespołu mają w dużym stopniu wpływ na pracę innych.

Jest to nieuniknione, że w trakcie prac fazy implementacji w dalszym ciągu znajduje się i poprawia błędy fazy projektowania. Wszystkie wykryte i poprawione błędy zostają udokumentowane.

e) Testowanie

Działania wykonywane w ramach tego etapu mają na celu zbadanie zgodności produktu ze specyfikacją wymagań użytkownika. Testowanie przeprowadza się zgodnie ze zdefiniowanym procesem. Tworzy się sytuacje testowania, w których śledzi się, czy spełnione są wymagania określone w specyfikacji. Testy wykonywane są w kontrolowanym środowisku. Również po każdej modyfikacji wprowadzonej do oprogramowania należy powtórnie przeprowadzić testy, aby sprawdzić poprawność nowej wersji.

Efektem prac fazy testowania ma być produkt gotowy do przekazania klientowi. Oprócz tego, zachowuje się raporty zawierające przebieg i rezultaty testów.

Wykryte błędy, czy to fazy projektowania, czy też fazy implementacji są usuwane. Wszystkie błędy oraz sposób ich usunięcia są dokumentowane.

f) Wdrażanie do użytkowania

Etap ten odbywa się najczęściej u klienta. Składa się on z dwóch najważniejszych części: samej instalacji oprogramowania oraz szkoleń personelu klienta. Instalacja i wstępna konfiguracja oprogramowania musi uwzględniać konkretne potrzeby przyszłych użytkowników i być zgodna z wymaganiami zdefiniowanymi w umowie. Z kolei szkolenia mogą być przeprowadzane na miejscu u klienta, przy świeżo zainstalowanym systemie lub też u dostawcy, w specjalnych salach przeznaczonych do szkoleń.

g) Utrzymywanie oprogramowania

Etap utrzymywania oprogramowania w pewnym sensie łączy w sobie elementy wszystkich poprzednich etapów. Utrzymywanie polega na usuwaniu usterek wykrytych już w czasie użytkowania produktu przez klienta oraz na wprowadzaniu udoskonaleń i rozszerzeń.

Prace na typ etapie niosą ze sobą specyficzne trudności, które sprawiają, że zarządzanie utrzymywaniem jest znacznie trudniejsze, niż zarządzanie projektowaniem czy implementacją.

Sterowanie konfiguracją

Zastosowanie procesów sterowania

Procesy sterowania inżynierią oprogramowania są podstawowym narzędziem służącym do usprawnienia prac nad projektowaniem i implementacją oprogramowania tak, aby końcowy produkt spełniał założone wymagania funkcjonalne i techniczne. Firma musi zaimplementować odpowiedni dla swojej specyfiki system sterowania konfiguracją mający za zadanie zarządzanie poszczególnymi składowymi oprogramowania, kodem i dokumentacją. Ponadto, niezbędne jest posiadanie formalnych procesów kontroli efektów pracy dla wszystkich etapów tworzenia produktu, tak aby po zakończeniu każdego etapu można było sprawdzić, czy jego rezultaty spełniają wymagania jakościowe. Kontrola jakości począwszy już od bardzo wczesnych etapów rozwoju oprogramowania jest bardzo pożądana, gdyż błędy i uchybienia popełnione wcześnie i nie usunięte natychmiast pociągają za sobą dalsze, coraz poważniejsze wady produktu w następnych fazach, a koszty usunięcia tych nieprawidłowości w znacznym stopniu wzrastają.

Istota sterowania konfiguracją

Sterowanie konfiguracją stanowi najważniejszy mechanizm kontrolny dla procesu inżynierii oprogramowania. Zawiera ono procedury, procesy i narzędzia umożliwiające zarządzanie zmianami, dostępem i identyfikacją zarówno projektu, jak i produktu.

Pierwszym etapem działań sterowania konfiguracją jest wyznaczenie składowych projektu i produktu. Następnie sterowanie konfiguracją musi mieć możliwość kontroli przyjmowania i wprowadzania zmian wymuszonych zarówno przez uwarunkowania wewnętrzne, jak i zewnętrzne. Żądanie zmiany jest formalną drogą wymuszenia wprowadzenia zmiany w ustalonej składowej.

Sterowanie składowymi za pośrednictwem procesów i procedur ma na celu możliwie szybkie wprowadzanie żądanych zmian oraz poprawne dokumentowanie tych czynności. Ważne jest także, aby nie dopuszczać do realizacji żądań zmian, które pochodzą z nieuprawnionych źródeł, są nieaktualne lub niepotrzebne. Przez przegląd i analizę zażądanych zmian możliwe jest także określenie konsekwencji tych zmian dla innych składowych. W tych składowych będą musiały zostać wprowadzone zmiany będące konsekwencją poprzednich; zmiany te powinny zostać zidentyfikowane i wprowadzone do realizacji, określa się także ich przewidywany koszt i termin zakończenia realizacji.

Kontrola nad sterowaniem konfiguracją sprawuje najczęściej zespół kontroli sterowania konfiguracją. W jego skład wchodzą najczęściej: kierownik projektu, kierownik działu marketingu, kierownik programu, kierownik ds. dokumentacji technicznej i kierownik ds. jakości. Najważniejsze zadania zespołu to zarządzanie przeprowadzaniem zmian przez zatwierdzanie, autoryzację i przegląd zmian. Zespół najczęściej zbiera się w regularnych odstępach czasu.

Przeglądy i inspekcje

Znaczenie przeglądów i inspekcji

Przeglądy techniczne spełniają bardzo ważną rolę w kontrolowaniu całego procesu tworzenia oprogramowania. Podstawowym zadaniem przeglądów jest lokalizacja błędów i pomoc w ich usunięciu oraz zminimalizowaniu skutków ich występowania. Jest to bardzo ważne, gdyż im wcześniej wykryje się usterkę, tym mniejsze koszty pochłania jej usunięcie.

Z punktu widzenia kierownictwa, przeglądy pozwalają znajdywać i neutralizować przyczyny powstawania nieprawidłowości, czuwać nad prawidłowym przebiegiem procesu tworzenia oprogramowania. Przeglądy są niezbędne dla koordynacji pracy w zespołach i w staraniach o zwiększanie wydajności pracy programistów.

Niektóre przeglądy mają za zadanie pomóc dwóm stronom: klientowi i dostawcy w wypracowaniu wspólnego stanowiska co do cech funkcjonalnych produktu, kosztów, kalendarza prac oraz zakresów odpowiedzialności.

Odpowiedzialność personelu

Personel odpowiedzialny za poszczególne obszary: tworzenie specyfikacji, zarządzanie, implementację, testowanie, utrzymywanie oprogramowania powinien posiadać pełną wiedzę na temat przeglądów. Odpowiedzialne osoby muszą wiedzieć, jakie typy przeglądów powinny być wykonywane, w jakich terminach, przez kogo oraz w jakim celu poszczególne z nich są realizowane. Z kolei zadaniem kierownictwa jest wspieranie przeglądów przez przydzielanie odpowiednich środków finansowych i zasobów dla ich realizacji. Obowiązkiem kierownictwa jest także regularne zapoznawanie się z wynikami przeglądów, gdyż dane otrzymane w ten sposób mają duże znaczenie dla sprawnego zarządzania całością procesów związanych z wytwarzaniem oprogramowania.

Jakość Produktu

Jakość produktu będącego oprogramowaniem jest miarą trudną tak do zdefiniowania, jak i do określenia. Tym, co daje się odczuć na pierwszy rzut oka jest wygląd i funkcjonalność interfejsu użytkownika. Istnieją także inne wskaźniki, które składają się na jakość produktu. Lista tych cech wygląda następująco:

Niezawodność określa się jako poziom, na jakim oprogramowanie spełnia swoje funkcje w mierzonym odcinku czasu.

Możliwość testowania odwzorowuje poziom trudności występujących podczas testowania. I tak, im więcej czasu pochłania przetestowanie danego produktu, tym niższa jest jego jakość według tego kryterium.

Przenośność określa ilość środków i czasu potrzebnych do stworzenia i przetestowania implementacji danego produktu na inną platformę sprzętową.

Łatwość użytkowania odnosi się do tego, jak łatwe jest nauczenie się obsługi oprogramowania i posługiwanie się nim z punktu widzenia użytkownika.

Rozszerzalność jest miarą łatwości rozbudowy produktu o nowe moduły, możliwości funkcjonalne czy też zwiększenie jego wydajności i pojemności.

Łatwość utrzymywania odnosi się do tworzenia nowych wersji systemu w celu wyeliminowania błędów wykrytych już w trakcie użytkowania produktu przez klienta.



komentarze

Copyright © 2008-2010 EPrace oraz autorzy prac.