OiZPI Część 7 Zarządzanie w fazie strategicznej

Prezentacja na temat: "OiZPI Część 7 Zarządzanie w fazie strategicznej"— Zapis prezentacji:

1 OiZPI Część 7 Zarządzanie w fazie strategicznej
Charakterystyka oprogramowania Zarządzanie jakością oprogramowania cz. I w materiałach wykorzystano: K.Subieta: Budowa i integracja systemów informatycznych A.Kobieliński: Inżynieria Oprogramowania I.Sommerville: Software Engineering Guides S.H. Kan: Metryki i modele w inżynierii jakości oprogramowania G.G. Shulmeyer: Handbook of Software Quality Assurance

2 Zarządzanie w fazie strategicznej cz. I
Objaśnienie podstawowych pojęć Zakres i charakterystyka czynności wykonywanych w ramach fazy strategicznej Aktorzy fazy strategicznej

3 Faza strategiczna w projektach informatycznych
Faza strategiczna (ang strategy phase) ma miejsce przed podjęciem ostatecznych decyzji o realizacji przedsięwzięcia i obejmuje następujące czynności: określenie celu przedsięwzięcia, oszacowanie ryzyka związanego z projektem oszacowanie kosztów projektu zapewnienie finansowania projektu, zaproponowanie organizacji pracy zespołu projektowego Faza strategiczna dotyczy głównie nabywcy dedykowanego systemu informatycznego, choć w przypadku firm sprzedających oprogramowanie rynkowe (tzw. z półki) jest to faza, w której rozważana i planowana jest produkcja nowego produktu, lecz nie została jeszcze podjęta ostateczna decyzja o rozpoczęciu prac. Faza strategiczna ma kluczowe znaczenie dla sukcesu całego przedsiewzięcia.

4 Artefakty fazy strategicznej
Definicja celów przedsięwzięcia Opis zakresu przedsięwzięcia Opis systemów zewnętrznych, z którymi system będzie współpracować Ogólny opis wymagań Ogólny model systemu Wizja proponowanego rozwiązania Oszacowanie kosztów Wstępny harmonogram prac Raport oceny rozwiązań, zawierający informację o rozważanych rozwiązaniach oraz przyczynach wyboru jednego z nich. Opis wymaganych zasobów - pracownicy, oprogramowanie, sprzęt, lokale. Definicje standardów.

5 Kierowanie projektem Sposoby kierowania projektem:
projekt kierowany przez użytkownika wymaga bardzo dokładnego sformułowania wymagań w stosunku do systemu przez jego uczestnika, często łącznie z przygotowaniem niezbędnych modeli systemu; ten sposób wymaga obecności specjalistów pracujących dla klienta, projekt w konsultacji z użytkownikiem wymagania dla systemu formułowane są przez twórców w konsultacji z użytkownikiem. Użytkownik zatwierdza wymagania w późniejszych etapach projektowania (specyfikacje, zwłaszcza zewnętrzna), niezależnie od użytkownika stosowany najczęściej w przypadku systemów oferowanych „z półki” na rynku; wymaga przeprowadzenia odpowiednich badań użytkowników, a najczęściej pewnego zaangażowania przyszłych użytkowników.

6 Role fazy strategicznej
Klient (inwestor, udziałowiec) - w przypadku małych, dedykowanych projektów występuje samodzielnie, najczęściej reprezentowany przez wyłoniony spośród pracowników średniego i wyższego stopnia zarządzania zespół projektowy, Doradcy - w przypadku dużych i średnich przedsięwzięć niezbędne jest zaangażowanie niezależnych firm konsultingowych i audytorskich lub powołanie niezależnych grup specjalistów Dostawca – występuje w roli oferenta a w przypadku oprogramowania „na półkę” jako inwestor Uwaga na firmy doradcze -> Arthur Andersen (Enron / Xerox)

7 Role fazy strategicznej
Chcę kupić system klasy X Odbiorca Mam system klasy X Dostawca Przedmiot transakcji = ??? Doradca Za odpowiednim wynagrodzeniem pomogę wam ustalić przedmiot transakcji Uwaga na firmy doradcze -> Arthur Andersen (Enron / Xerox) Przedmiot transakcji - jest niedookreślony w chwili podjęcia decyzji o współpracy Stopień niedookreślenia – jest w porównaniu do innych branż jest bardzo wysoki Systemy COTS – 20% funkcjonalności nietypowej, jest ona jednak kluczowa

8 Etapy fazy strategicznej u zamawiającego
Opracowanie strategii IT w firmie Określenie celów przedsięwzięcia Określenie za- kresu i kontekstu przedsięwzięcia Wstępne określenie wymagań Przygotowanie kilku koncepcji rozwiązań IT – information technology (technologii informacyjnej) Powołanie zespołu projektowego Określenie zakresu, założeń oraz celów przedsięwzięcia Określenie wymagań w stosunku do zamawianego systemu Wykonanie zgrubnej analizy i projektu systemu Przygotowanie propozycje kilku możliwych rozwiązań i oszacowanie kosztów ich realizacji Analiza rozwiązań i przyjęcie najkorzystniejszego z nich Określenie wstępnego harmonogramu przedsięwzięcia Określenie wymaganych standardów Przedstawienie wyników fazy strategicznej organom decyzyjnym Stworzenie zapytania ofertowego ujmującego standardy obowiązujące w projekcie Zapytanie ofertowe Określenie wstępnego harmonogramu Zaprezentowanie wniosków org.decyzyjnym Analiza rozwiązań

9 Etapy fazy strategicznej u wykonawcy
Pytania do oferenta Zapytanie ofertowe Analiza zapytania ofertowego Zgrubna analiza wymagań Rozpoznanie możliwości wyk. komponentów Koncepcja realizacji systemu IT – information technology (technologii informacyjnej) Powołanie zespołu projektowego Określenie zakresu, założeń oraz celów przedsięwzięcia Określenie wymagań w stosunku do zamawianego systemu Wykonanie zgrubnej analizy i projektu systemu Przygotowanie propozycje kilku możliwych rozwiązań i oszacowanie kosztów ich realizacji Analiza rozwiązań i przyjęcie najkorzystniejszego z nich Określenie wstępnego harmonogramu przedsięwzięcia Określenie wymaganych standardów Przedstawienie wyników fazy strategicznej organom decyzyjnym Stworzenie zapytania ofertowego ujmującego standardy obowiązujące w projekcie Oferta Decyzja o zaangażowaniu w projekt Oszacowanie ryzyka i zasobów niezbędnych do realizacji projektu

10 Oprogramowanie Czym jest oprogramowanie Rodzaje programów
Charakterystyka oprogramowania Cechy oprogramowania

11 Czym jest oprogramowanie
Oprogramowanie to: kod (program), realizujący określone funkcje struktury danych umożliwiające programowi odpowiednie przetwarzanie danych dokumentacja opisująca mechanizmy działania programu przedstawiająca sposoby korzystania z programu

12 Rodzaje programów Rodzaje programów:
ogólne „z półki”, („off the shelf”) na zamówienie („bespoke”) Problemy i metody stosowane w obu przypadkach są identyczne. Główna różnica to źródło specyfikacji programu dla ogólnych tworzona wewnętrznie np. przez dział marketingu w systemach na zamówienie określana przez klienta składającego zamówienie

13 Systemy COTS Model pośredni to systemy COTS (commercial off-the-shelf)
System posiada typowe funkcje dla danej klasy systemów Pewna część jest nadmiarowa Pewne specyficzne wymagania wymagają dodatkowej konfiguracji lub uzupełnienia funkcjonalności Brakująca część jest krytyczna dla powodzenia projektu Część nadmiarowa Część dopasowana Brakująca część 10% 60%-70% 20%-30% Wymagania klienta

14 Charakterystyka oprogramowania
Oprogramowanie jest tworzone, a nie produkowane w klasycznym sensie Oprogramowanie nie „zużywa się” z biegiem czasu, ale może się pogarszać na skutek wprowadzanych zmian Oprogramowanie w większości budowane jest od podstaw, rzadziej składane z gotowych elementów (ta sytuacja ulega stopniowej zmianie) cechy oprogramowania w porównaniu z innymi dziedzinami produkcji

15 Ewolucja oprogramowania
Aby oprogramowanie pozostawało użyteczne musi się zmieniać Ważne zagadnienie – organizacje są „uzależnione” od oprogramowania, z którego korzystają Przyczyny występowania konieczności zmian Zmiana regulacji prawnych Zmiana zasad działania organizacji Zmiana platformy sprzętowej i systemowej Pojawianie się nowych wymagań

16 Cykl zarządzania ewolucją
Struktura cyklu zarządzania ewolucją uwzględnia Zgłaszanie żądań Analizę skutków Planowanie Implementację Dystrybucję Zgłaszanie żądań Analiza skutków Planowanie Implementacja Dystrybucja

17 Prawa Lehmana Lehman et. al. ( ) sformułowali 8 praw określających dynamikę rozwoju oprogramowania Prawo ciągłej zmiany: program pozostający w użytku w określonym środowisku musi się zmieniać lub stawać mniej użytecznym w tym środowisku Prawo rosnącej złożoności : rozwijający się program zmienia się i staje się coraz bardziej złożony. Zachowanie jego wyjściowej złożoności wymaga angażowania dodatkowych środków.

18 Prawa Lehmana Prawo ewolucji dużych programów: ewolucja dużych programów to proces samoregulujący się. Atrybuty systemu takie jak rozmiar, czas pomiędzy kolejnymi wersjami i liczba zgłaszanych błędów są w przybliżeniu stałe dla kolejnych jego dystrybucji. inaczej: dynamika rozwoju dużych programów jest stała o dynamice decyduje proces tworzenia programu przyjęte tu rozwiązania (popełnione błędy) wyznaczają zasadnicze trendy dotyczące nakładów ponoszonych w fazie eksploatacji

19 Prawa Lehmana Prawo stabilności organizacji : tempo rozwoju oprogramowania na przestrzeni cyklu życiowego jest w przybliżeniu stałe i niezależne od ilości zasobów zaangażowanych w jego powstanie. Prawo zachowania zmienności : przyrostowa zmiana w obrębie każdej dystrybucji programu jest w przybliżeniu stała. Prawo ciągłego wzrostu : aby utrzymać wysoki poziom zadowolenia użytkowników funkcjonalność systemu musi ciągle wzrastać.

20 Prawa Lehmana Prawo spadającej jakości : jakość systemu postrzegana jest coraz gorzej, jeśli nie jest on stale dostosowywany do zmian zachodzących w środowisku działania Prawo sprzężenia zwrotnego : znaczący rozwój systemu możliwy jest tylko w przypadku stosowania iteracyjnych metod zarządzania uwzględniających zwrotne informacje od użytkowników.

21 Utrzymanie oprogramowania
Utrzymanie oprogramowania – proces zmian oprogramowania zachodzący po wdrożeniu (dostarczeniu). Rodzaje działań związanych z utrzymaniem oprogramowania Naprawa błędów Dostosowanie do zmian zachodzących w środowisku działania oprogramowania Rozbudowa funkcjonalności Nakłady zasobów na poszczególne działania źródło: Nosek J. T., Plavia P., Software Maintenance: Research and Practice 1990

22 Atrybuty oprogramowania
Podstawowe atrybuty dobrego oprogramowania uniwersalność - możliwość dostosowania oprogramowania do zmieniających się potrzeb pewność - niezawodność i bezpieczeństwo, czyli zabezpieczenie przed oddziaływaniem otoczenia (security) oraz pewność pracy (safety) - awaria oprogramowanie nie powinna powodować fizycznych i ekonomicznych szkód wydajność - oprogramowanie nie powinno marnować zasobów systemowych wygoda w użyciu - oprogramowanie powinno mieć właściwy interfejs użytkownika i dokumentację

23 Kompromisy Koszt Wydajność
Jeśli wymagany jest wysoki poziom jednego z atrybutów (np. wydajności) koszty wytworzenia oprogramowania rosną wykładniczo Koszt Tutaj dobrze pasuje następujący przykład: Załóżmy, że elektrownia Rybnik została zmodernizowana i stała się elektrownią atomową. Potrzebne jest oprogramowanie do sterowania prętami grafitowymi regulującymi przebieg reakcji rozszczepiania atomu i niedopuszczające do przegrzania reaktora. Odpowiednie oprogramowanie gotowa jest dostarczyć za 1600 zł + VAT firma JanSOFT z Klimaszowej. Pan Jan Kowalski, właściciel firmy, twierdzi że napisał w Visual Basicu nie jeden program i jak dotychczas nikt nie narzeka. Pytanie – dlaczego to jest śmieszne. Odpowiedź: gdy wymagany jest wysoki poziom jednego z atrybutów (tutaj pewność) nikt nie weźmie na poważnie takiej oferty. Wydajność

24 Inne atrybuty oprogramowania
Poprawność określa, czy oprogramowanie wypełnia postawione przed nim zadania i czy jest wolne od błędów. Czytelność pozwala na określenie wysiłku niezbędnego do zrozumienia oprogramowania. Ponowne użycie charakteryzuje przydatność oprogramowania, całego lub tylko pewnych fragmentów, do wykorzystania w innych produktach programistycznych. Stopień strukturalizacji (modularność) określa, jak łatwo oprogramowanie daje się podzielić na części o dobrze wyrażonej semantyce i dobrze wyspecyfikowanej wzajemnej interakcji.

25 Inne atrybuty oprogramowania
Efektywność opisuje stopień wykorzystania zasobów sprzętowych i programowych stanowiących podstawę działania oprogramowania. Przenaszalność mówi o łatwości przenoszenia oprogramowania na inne platformy sprzętowe czy programowe. Skalowalność opisuje zachowanie się oprogramowania przy rozroście liczby użytkowników, objętości przetwarzanych danych, dołączaniu nowych składników, itp. Współdziałanie charakteryzuje zdolność oprogramowania do niezawodnej współpracy z innym niezależnie skonstruowanym oprogramowaniem.

26 Zarządzanie jakością oprogramowania
Zręby systemu zarządzania jakością Kolejny wykład: Model dojrzałości procesu Proces przetwarzania skarg Podstawowe narzędzia jakości

27 Zręby systemu Zręby systemu – podstawa, fundament, struktura
Określenie angielskojęzyczne QMF (quality management framework) Koncepcja opracowana w 1982 w kontekście jakości różnych produktów, w tym oprogramowania Została rozwinięta w różnych późniejszych standardach w tym w DOD (US Department of Defense), CMMI (Capability Maturity Model Integration), SW-CMM (Software adopted CMMI)

28 QMF – podstawowe pojęcia
Definiuje podstawowe pojęcia Obiekt – pojęcie uogólnione Proces Wymaganie Użytkownik Ewaluacja Miara i pomiary Jakość

29 QMF – obiekty Obiektem może być Produkt Proces Usługa Zasób Artefakt
Działanie Miara i pomiary Środowisko Kolekcja obiektów

30 QMF – definicje Produkt – namacalne, znaczące wyjście lub usługa będące wynikiem procesu Produktem może być sprzęt oprogramowanie dokumentacja dowolna kombinacja powyższych

31 QMF – definicje Proces – zbiór działań podejmowanych w określonym celu
Jakość produktu zależy od jakości procesu towarzyszącemu jego powstawaniu Wymaganie – pożądana możliwość, cecha, warunek, którą musi posiadać obiekt aby spełnić założenia kontraktu, standardu, specyfikacji lub innej formalnie narzuconej normie Dla produktu, jakim jest oprogramowanie obowiązuje określona kategoryzacja wymagań (patrz poprzednie wykłady)

32 Klient to użytkownik końcowy
QMF – definicje Użytkownik – klient lub użytkownik końcowy Wyróżnia się trzy przypadki Dla uproszczenia termin „użytkownik” odnosi się do wszystkich trzech sytuacji Klient to użytkownik końcowy Klient Użytkownik końcowy Klient Użytkownik końcowy

33 QMF – definicje Ewaluacja – proces wyznaczania stopnia spełniania wymagań Inna definicja – proces wyznaczania jakości produktów i związanych z nimi elementów dokumentacji, procesów i działań mających wpływa na jakość produktu. Ewaluacja może obejmować Wszelkie analizy Inspekcje Przeglądy Testy

34 QMF – definicje Miara i pomiary – zdolność do pomiaru jakości procesów i produktów i możliwość przypisywania jej określonych wartości wyrażonych liczbami Miara określa wielkość odnoszącą się do zgodności procesu i produktu ze standardami Pomiar definiuje proces wyznaczania wartości reprezentującej miarę stosowany w organizacji Uwaga terminologiczna: pojęcie „miara” bywa stosowane zamiennie z pojęciem „metryki” – taka zamiana jest poprawna, ale w niektórych opracowaniach (standardach) pojęcia te posiadają odmienne definicje

35 QMF – definicje Jakość – stopień w jakim obiekt (proces, produkt, usługa) spełnia zestaw wymaganych atrybutów oraz wymagań Istnieją dwie zasadnicze kategorie rozumienia i postrzegania jakości Jakość rozumiana jako „zgodność z wymaganiami”. Każde odstępstwo od wymagań traktowane jest jako defekt. Inaczej: mówi się o ocenie atrybutów oprogramowania (produktu) Jakość rozumiana jako „przydatność do użytku”. W tym przypadku bierze się pod uwagę wymagania i oczekiwania użytkowników. Specyfika oprogramowania jest duże znaczenie drugiego z wymienionych aspektów.

36 QMF – elementy programu jakości
Program zarządzania jakością obejmuje trzy elementy wymagane do: Ustalenia wymagań i zarządzania zmianami Ustalenia i wdrożenia metod Określenia jakości produktu i procesu W pierwszej kolejności określa się pożądane atrybuty produktu, następnie opracowuje się metody wytwórcze i wdraża je ostatecznie definiuje się sposób opomiarowania jakości procesu wytwórczego i samego produktu. Program jakości Ustal wymagania i zarządzaj zmianami Ustal i wdrażaj metody Ewaluuj proces i jakość produktu

37 QMF – Ustalenie wymagań i zarządzanie zmianami
Ustalenie wymagań, a raczej stworzenie metody ustalania wymagań – pierwszy element programu jakości Wymagania muszą odzwierciedlać aktualne potrzeby społeczności użytkowników Wymagania muszą odzwierciedlać potrzeby inwestorów i respektować wyznaczone przez nich ograniczenia Wymagania należy gromadzić w sposób sformalizowany

38 QMF – Ustalenie wymagań i zarządzanie zmianami
Nie mniej jednak – poczucie jakości jest przeważnie subiektywne (użytkownik postrzega produkt z własnej perspektywy) Proces formułowania wymagań jako proces formalny powinien również podlegać ocenie Współdziała zatem z pozostałymi dwoma elementami QMF (metody i ewaluacja jakości) Cel : wyspecyfikowanie wymagań, których wypełnienie zaowocuje wysokim stopniem jakości i satysfakcji klienta

39 QMF – Ustalenie wymagań i zarządzanie zmianami
Proces akwizycji wymagań wymaga wprowadzenia mechanizmu zarządzania konfiguracją, który umożliwi: Ustalenie momentu, w którym można rozpocząć dalsze działania związane z rozwojem projektu (ustalenie faktu, że specyfikacja wymagań osiągnęła już odpowiedni poziom stabilności) Zapobiegać niekontrolowanym zmianom w zasadniczej specyfikacji produktu Sprawić, że rozwój produktu i kolejne fazy procesu wytwórczego nie będą miały negatywnego wpływu na jego jakość

40 QMF – Ustalenie wymagań i zarządzanie zmianami
Kontrolowaniu zjawiska ewolucji wymagań służy procez zarządzania zmianami Proces powinien być wsparty narzędziami (programy komputerowe w postaci repozytoriów wymagań) Zarządzanie zmianami pozwala na osiągnięcie następujących celów: Wprowadzenie sformalizowane ścieżki zgłaszania żądań zmiany Wprowadzenie mechanizmów oceny żądań Wprowadzenie jasnych reguł akceptacji/odrzucania zmian Wprowadzenie mechanizmów rozliczeń klienta z wykonawcą Wytworzenie poczucia satysfakcji klienta (ktoś zajmuje się moim problemem) Wytworzenie poczucia bezpieczeństwa wykonawcy (nie boję się eskalacji żądań)

41 QMF – Ustalenie i wdrożenie metod
Drugi element QMF polega na wyborze, wdrożeniu określonych procesów metod i praktyk i ma na celu wbudowanie jakości w produkt. Jakość nie jest postrzegana jako byt zewnętrzny w stosunku do produktu – jest jego elementem. Produkt Klient System zarządzania jakością

42 QMF – Ustalenie i wdrożenie metod
Wdrażane metody mogą wynikać z globalnych lub korporacyjnych standardów i mogą być powielane w kolejnych projektach Czasami zachodzi potrzeba wdrożenia wyspecjalizowanych rozwiązań odnoszących się do konkretnego projektu I w jednym i w drugim przypadku mamy do czynienia z organizacją działań firmy (wdrażanie istniejących, względnie opracowywanie istniejących standardów) Istnieje silna zależność pomiędzy jakością procesu a jakością samego produktu Jeśli przykładowo firma jest w wysokim stopniu niezorganizowana (działa chaotycznie) należy spodziewać się, że jej produkty będą posiadały niska jakość

43 QMF – Ustalenie i wdrożenie metod (standardy rozwoju procesu)
CMMI® (Capability Maturity Model Integration) 1995 rok Standard rozwinięty przez SEI (Software Engineering Institute) przy Carnegie Mellon University Ponadto SCAMPI® (Standard CMMI® Appraisal Methodology for Process Improvement) 2001 rok Wymienione: model procesu i metodykę jego oceny stosuje się charakteryzując dojrzałość procesu wytwórczego i towarzyszącej mu metodyki.

44 QMF – Ustalenie i wdrożenie metod (standardy rozwoju procesu)
Model CMMI® zakłada sześć poziomów organizacji: Wstępny Zarządzany Zdefiniowany Mierzalny Optymalizowany

45 QMF – Ustalenie i wdrożenie metod (standardy rozwoju procesu)
Poziom wstępny – proces jest nieprzewidywalny, źle kontrolowany i czuły Poziom zarządzany – wdraża się standardy i procesy; zarządzanie ma miejsce na poziomie pojedynczego projektu; zarządzanie jest wrażliwe na bodźce zewnętrzne Poziom zdefiniowany – Standardy są wdrożone na poziomie całej organizacji Poziom mierzalny – Proces jest „opomiarowany” i sterowany przez zastosowanie metryk statystycznych i liczbowych Poziom optymalizowany – na tym poziomie kładzie się nacisk na ciągłe doskonalenie procesu

46 QMF – Pomiar jakości produktu i procesu
Trzeci element QMF związany jest z oceną procesu i powstającego w jego efekcie produktu Ocena dotyczy: Jakości produktu Odpowiedniości procesów i działań odpowiedzialnych za jakość produktu Zgodności działań z ustalonym w firmie procesem wytwórczym (rozumianym szeroko, jako metodyka)

47 QMF – Pomiar jakości produktu i procesu
Ocena produktu polega na ustaleniu jego zgodności z wymaganiami w ramach założonych kosztów i ustalonego harmonogramu Koszty wytworzenia i harmonogram należy włączyć do oceny produktu Przykładowo: przy nieograniczonych kosztach i bez założeń co do harmonogramu, przynajmniej teoretycznie można by wytworzyć produkt o bardzo wysokiej jakości Możliwe jest dokonywanie oceny i pomiaru Ocena obejmuje analizy, audyty, wywiady, itp., nie dostarcza „twardej” wiedzy ilościowej Pomiar dostarcza ilościowej wiedzy, może przyjmować formę różnego rodzaju testów, uruchomień, metryk, list kontrolnych, itp.

48 QMF – Pomiar jakości produktu i procesu
Ocena procesu sprowadza się głównie do ustalenia tego, czy produkt wytwarzany jest zgodnie z ustalonymi standardami Zgodność ze standardami rozumiemy jako zgodność ze zdefiniowanym i wdrożonym w firmie procesem wytwórczym i wszystkimi jego elementami, takimi jak standardy dokumentacji, metodyki, zasady bezpieczeństwa, itp. W dojrzałych organizacjach, wnioski z oceny procesu (negatywne) powodują wdrażanie działań naprawczych W ten sposób proces w miarę upływu czasu jest stale doskonalony (Continuous Process Improvement) – poziom szósty CMMI®. W organizacjach mniej dojrzałych w ramach pomiaru jakości procesu rozwijane np. kolejne narzędzia kontrolne – poziom piąty CMMI®.

49 QMF – Podstawowe problemy
Przekonanie, że kwestie jakości są tylko i wyłącznie sprawą działu jakości (osób odpowiedzialnych za jakość) Założenie: „róbmy swoje, błędy wychwycą testerzy” jest sprzeczne z przytoczonym trzyelementowym zrębem systemy jakości Oddzielanie zagadnień jakości od produktu jako takiego Koncentrowanie się na jakości produktu, z pominięciem jakości procesu Wniosek: każdy pracownik zaangażowany w wytwarzanie produktu powinien realizować jakiś „fragment” ogólnego systemu zarządzania jakością W dalszej części wykładu: Zarządzanie skargami Narzędzia jakości w wytwarzaniu oprogramowania