19.1.1. Statystyka procesu produkcyjnego u podstaw Six Sigma
19.1.2. Cykl DMAIC
19.1.3. Cykl DMADV
19.2. Narzędzia Six Sigma
19.2.1. Karta projektu
19.2.2. Ocena ekonomiczna projektu
19.2.3. Drzewa CTQ
19.2.4. FMEA
19.2.5. QFD
19.2.6. Analiza Kano
19.2.7. Mapa procesu
19.2.8. Diagram powinowactwa
19.2.9. Analiza zdolności i wydajności procesu
19.2.10. Analiza Pareto
19.2.11. Diagramy przyczynowo-skutkowe (Ishikawy)
19.2.12. Analiza korelacji
19.2.15. Analiza wariancji ANOVA
19.2.16. Miernik powtarzalności i odtwarzalności (Gauge R&R)
19.2.18. Analiza kosztów i korzyści
19.2.19. Wykresy kontrolne (Shewharta)
19.3. Six Sigma w wytwarzaniu oprogramowania
19.3.1. Dyskusja: kontrowersje i odpowiedzi
19.3.2. Praktyczne zastosowanie?
VI. JAKOŚĆ W PODEJŚCIU ZWINNYM
20. Przegląd metodyk zwinnych
20.1. Agile Manifesto
20.2. Programowanie ekstremalne (XP)
20.3. Scrum
20.4. Inne podejścia zwinne i szczupłe
20.5. Silne i słabe strony metodyk zwinnych
21. Jakość według Agile
21.1. Co znaczy „jakość” w metodykach zwinnych
21.2. Czynniki powodzenia metodyk zwinnych
21.3. Wpływ praktyk zwinnych na jakość oprogramowania
21.3.1. Praktyki planowania i pozyskiwania wymagań
21.3.2. Praktyki zarządzania 490
21.3.3. Praktyki związane z projektowaniem
21.3.4. Praktyki związane z kodowaniem i integracją
21.3.5. Praktyki związane z testowaniem
21.4. Czy Agile może zapewnić jakość oprogramowania? 499
21.4.1. Ograniczenia stosowania metodyk zwinnych
21.4.2. Agile a CMM/CMMI .
21.4.3. Agile w dużych organizacjach
21.4.4. Zaawansowane metryki zwinne 507
21.4.5. Woń psującego się oprogramowania
509
21.5. Podsumowanie i dyskusja o metodykach Agile 510
22. Integracja klasycznych i zwinnych metod zapewnienia jakości
22.1. Zwiększanie zwinności metod klasycznych
516
22.2. Disciplined Agile Development 518
22.3. Stan obecny i perspektywy 520
Podsumowanie
Bibliografia
Słownik skrótów
Skorowidz
Dla kogo jest ta książka?
To nie jest podręcznik dla testerów oprogramowania. Oczywiście testerzy mogą też skorzystać z tej książki, ale jej celem nie jest nauczenie technik testowania, lecz uświadomienie, że
przez samo testowanie nie można zapewnić jakości oprogramowania!
Przez lekturę tej książki odkryjesz (być może ponownie), że
przez testowanie można udowodnić, że w oprogramowaniu są błędy, ale nie, że ich nie ma.
Dowiesz się, w jaki sposób można zapewnić jakość oprogramowania. Zorientujesz się, że jakość oprogramowania jest ściśle związana z metodami wytwarzania oraz jakie praktyki trzeba stosować, aby uzyskać wymaganą jakość oprogramowania.
Być może ta książka zburzy dobre samopoczucie pracowników i właścicieli firm tworzących oprogramowanie metodami zwinnymi, którzy myślą, że Agile jest dobre na wszystko. Niech nie próbują metodami zwinnymi tworzyć oprogramowanie rozrusznika serca albo łazika marsjańskiego. Istnieją dobrze sprawdzone metody klasyczne, które są w stanie w ściśle określonych przypadkach zapewnić znacznie lepszą jakość oprogramowania. A jeśli już stosują metody zwinne, to niech poświęcą chwilę na refleksję, czy spełniają wszystkie zalecenia Agile Manifesto, które są potrzebne dla utrzymania jakości procesu i uzyskania jakości produktów.
Dlatego jeśli:
• jesteś początkującym programistą i myślisz, że jakość to nie twój problem,
• masz już trochę doświadczenia i denerwuje cię dług techniczny,
• zostałeś team leaderem i martwisz się, że w twoim zespole coś nie gra,
• jesteś właścicielem produktu i musisz się domyślać, o co chodzi klientom,
• jesteś szefem firmy IT i nie wiesz, dlaczego praca informatyków tyle kosztuje, to powinieneś sięgnąć po tę książkę.
Natomiast jeśli:
• masz przysłowiowy „nóż na gardle”, bo twój projekt jest już mocno opóźniony,
• twój klient ciągle chce zmian w oprogramowaniu, a nie chce już płacić,
• twój klient wydzwania do ciebie po nocy, to daj sobie spokój. Jest już za późno.
Żartowałem, nigdy nie jest za późno na naukę. Wykaż się zwinnością i zmień swoje myślenie. Następnym razem pójdzie lepiej.
Rysunek 1.
Drzewo jakości
Słowo „drzewo” powinno być tu ujęte w cudzysłów, jako że niektóre składowe pojawiają się w kilku gałęziach drzewa. To znaczy że np. łatwość śledzenia i łatwość testowania określają zarówno funkcjonalność oprogramowania, jak i jego wiarygodność.
Nie jest to jedyny model ani też konkretny model standardowy. Znany jest np. model McCalla czy też model ISO/IEC 9126 (omawiane w dalszej części książki). Podany tu przykład ma nam uzmysłowić złożoność pojęcia jakości oprogramowania. Ma też posłużyć do zilustrowania modelu pomiarów jakości.
6.1. Wagi atrybutów
Jeśli jakość jest zdefiniowana jako stopień spełnienia wymagań, to zachodzi pytanie –jaką skalę wartości może osiągać ten stopień? Do tego celu przyjmuje się skalę od 0 do 1, gdzie 0 oznacza całkowity brak jakości, np. brak realizacji jakiejkolwiek funkcji, a 1 oznacza maksymalną jakość, np. realizację wszystkich wymaganych funkcji.
Skoro jakość jest zdefiniowana jako stopień spełnienia wymagań klienta/użytkownika i składa się ze stopni spełnienia jego wymagań w zakresie funkcjonalności, wiarygodności, wydajności, elastyczności i użyteczności, to jak przekładają się składowe jakości (atrybuty) na jakość całkowitą? Intuicyjnie rzecz ujmując, można przyjąć, że różne składowe jakości mogą mieć różną wagę dla różnych produktów. Wówczas jakość oprogramowania może być matematycznie obliczona jako średnia ważona (ang. weighted mean):
gdzie:
Qk jest jakością oprogramowania na k-tym poziomie drzewa jakości, Q0 jest jakością całkowitą,
Nk + 1 jest liczbą składowych jakości na poziomie k + 1, Qk + 1i jest wartością składowej jakości na poziomie k + 1, Wk + 1i jest liczbą nieujemną określającą wagę i-tej składowej jakości na poziomie k + 1.
Formuła średniej ważonej zapewnia, że jeśli wszystkie składowe Qk+1 niezależnie od wartości wag W są w zakresie od 0 do 1, to wartość Qk jest też w zakresie od 0 do 1. Jakie mogą być wagi składowych jakości? To już zależy od dziedziny zastosowania oprogramowania (czyli typu aplikacji). Przykładowe wagi przedstawiono w tab. 3. Zwróćmy uwagę na wysoką wagę wydajności i elastyczności w przypadku aplikacji internetowych oraz na to, że elastyczność ma większą wagę od wydajności. Elastyczność oznacza tu przede wszystkim przenośność oprogramowania, czyli możliwość uruchomienia na różnych komputerach użytkowników (zarówno nowszych, jak i starszych), na różnych systemach operacyjnych (Windows, Linux lub iOS). Jak oprogramowanie da się uruchomić, to w grę wchodzi wydajność, zwłaszcza szybkość ładowania aplikacji i przesyłania danych przez słabsze łącza.
Tabela 3. Przykładowe wagi głównych składowych jakości
Składowa\typ aplikacji
Funkcjonalność
Aplikacje specjalistyczne
Aplikacje internetowe
Systemy czasu rzeczywistego
Użyteczność
Zwróćmy również uwagę na to, że wydajność wcale nie ma najwyższej wagi dla systemów czasu rzeczywistego. Tam liczy się przede wszystkim wiarygodność, czyli, czy program zdąży zadziałać w określonym limicie czasowym (np. uruchomić tłoki hamulców w samochodzie w czasie 100 ms od wykrycia przeszkody).
Wyżej podane wagi są jedynie propozycjami. Dużo zależy od dziedziny zastosowania. Na przykład w aplikacjach diagnostyki medycznej wiarygodność będzie bardziej istotna niż w przypadku programu do składania tekstów w drukarni; dla aplikacji internetowej do zakupu biletów na samolot najważniejsza będzie wiarygodność, a dla udostępniania zdjęć z wakacji – wydajność.
Ważne jest, aby wagi składowych jakości były ustalane przez klienta/użytkownika, bo muszą odzwierciedlać jego punkt widzenia. Ważne jest też, aby raz ustalone wagi nie były zmieniane w czasie obliczania jakości, a już zwłaszcza nie były zmieniane dla dostosowania wyników do oczekiwań klienta.
Do czego prowadzi takie definiowanie składowych jakości? Można tę czynność kontynuować tak długo, aż każda podstawowa składowa jakości będzie już pojęciem niepodzielnym i to takim, które można mierzyć. Takie mierzalne pojęcie nazywamy metryką.
6.2. Co to są metryki i miar y jakości?
Jak mierzyć np. kompletność funkcjonalną? Jeśli kompletność funkcjonalna jest to stopień realizacji wymaganych funkcji, to można ją wyrazić jako iloraz liczby zrealizowanych funkcji przez liczbę wymaganych funkcji:
W tym rozdziale będziemy odróżniać pojęcie metryki, miary i pomiaru, chociaż nie wszyscy autorzy tak robią 2. W standardzie IEEE 610.12-1990 [34] metryka (ang. metric) to „Miara ilościowa stopnia, w jakim system, komponent lub proces ma dany atrybut”.
2 Na przykład w normie ISO/IEC 9126 metryki i miary są ze sobą utożsamiane.
Definicja ta kieruje czytelnika dalej do terminu „metryka jakości” (ang. quality metric), który ma dwie definicje:
1. „Miara ilościowa stopnia, w jakim element ma dany atrybut jakości”.
2. „Funkcja, której wejścia to dane softwarowe i której wyjściem jest pojedyncza wartość liczbowa interpretowana jako stopień, w jakim oprogramowanie ma dany atrybut jakości”.
Z kolei w słowniku pojęć stosowanych inżynierii wymagań [46] znajdziemy definicje rozróżniające, powołujące się na standard ISO 14598 [47]:
„Miara (ang. measure): Liczba lub kategoria przypisana do atrybutu bytu przez pomiar”.
„Pomiar (ang. measurement): Proces przypisania liczby lub kategorii do bytu w celu opisania atrybutu tego bytu”.
„Metryka (ang. metric): Skala pomiaru i metoda stosowana do pomiaru”.
My będziemy stosować następujące rozumowanie:
• Jakość oprogramowania może być opisana przez zbiór cech (atrybutów) jakościowych (ang. quality attributes) wyrażających stopień spełnienia wymagań (potrzeb i oczekiwań) klienta/użytkownika. Wartość każdego atrybutu można wyznaczyć na podstawie jego atrybutów składowych lub pomierzyć.
• Metryka (ang. metric) jest taką cechą (atrybutem) oprogramowania, którą można mierzyć.
• Miara (ang. measure) jest wartością, która może być przypisana do metryki. Miara opisuje sposób i skalę pomiaru.
• Pomiar (ang. measurement) jest procesem wyznaczenia miary.
6.3. Skalowanie i normalizacja miar
W naszym modelu matematycznym jakości przyjęliśmy, że każda składowa jakości (atrybut jakościowy) może przyjmować wartości od 0 (brak spełnienia wymagań) do 1 (spełnienie wszystkich wymagań). Czyli metryki też powinny przyjmować wartości od 0 do 1. Ale miary mogą mieć inną skalę (ang. measure scale) niż 0–1. Najprostsza sytuacja (jak by się wydawało) jest wtedy, gdy miara ma skalę procentową (ang. percent scale). Wówczas wartość 0% miary jest odwzorowywana na wartość 0 metryki, a 100% miary na wartość 1 metryki.
Taką sytuację mamy np. dla kompletności funkcjonalnej liczonej wg wzoru (1). Jeśli poprawność będziemy mierzyli przez testowanie i będziemy dzielili liczbę błędnie uzyskanych wyników testów przez liczbę wszystkich testów, to dla zachowania skali 0 – całkowity brak poprawności, 1 – stuprocentowa poprawność, musimy wynik dzielenia odjąć od 1: (1)
17
PRINCE2
PRINCE2 jest metodyką zarządzania projektami opracowaną i stosowaną jako standard w Wielkiej Brytanii. Początki tej metodyki sięgają połowy lat siedemdziesiątych XX wieku, kiedy w firmie brytyjskiej Simpact Systems Ltd. opracowano podejście PROMPT (ang. Project, Resource, Organization, Management and Planning Technique) do zarządzania, planowania i organizacji projektów i ich zasobów. We wczesnych latach osiemdziesiątych ta technika została zaadaptowana przez Centralną Agencję Komputerową i Telekomunikacyjną w Wielkiej Brytanii (ang. CCTA – Central Computer and Telecommunications Agency), która zaczęła licencjonować metodykę PROMPT. W 1989 roku CCTA ulepszyła PROMPT i zmieniła jego nazwę na PRINCE (ang. PROMPT In The CCTA Environment). W 1996 roku wyszła druga wersja tego standardu pod nazwą PRINCE2, a w roku 2000 CCTA została włączona do rządowego OGC (ang. Office of Government Commerce). Najnowsza wersja PRINCE2 pochodzi z roku 2009. W 2013 roku własność intelektualna PRINCE2 została przekazana nowej firmie AXELOS, która jest spółką joint venture rządu Jej Królewskiej Mości i brytyjskiej firmy inwestycyjnej Capita Plc.
Obecnie głównym źródłem informacji o PRINCE2 jest Prince2® Wiki [195] – udostępniona na licencji Creative Commons internetowa encyklopedia prowadzona przez AXELOS
Certyfikat PRINCE2 stanowi potwierdzenie znajomości technik zarządzania projektami (nie tylko z dziedziny oprogramowania) na wysokim poziomie.
Podejście PRINCE2 jest oparte na dobrze zdefiniowanej strukturze ról i odpowiedzialności. Każda osoba odgrywająca w projekcie określoną rolę wie, czego się od niej oczekuje i czego może oczekiwać od innych. Zna zarówno ogólne zasady, jak i procedury postępowania właściwe dla danej roli. W przypadku napotkania problemów wykraczających poza kompetencje swojej roli może problemy przekazać (eskalować) na wyższy poziom zarządzania. W PRINCE2 nazywa się to zarządzaniem przez wyjątki (ang. Manage by Exception).
Parametry (zmienne) projektu kontrolowane przez PRINCE2 mogą być zapamiętane przez akronim „BC QRST”:
• Benefits – korzyści,
• Cost – koszt,
• Quality – jakość,
• Risk – ryzyko,
• Scope – zakres,
• Time – czas.
Frank Turley, główny autor Prince2® Wiki, poleca też inny sposób zapamiętania ww. sześciu zmiennych – przez powiedzenie „TeCQuila SoBeR”.
17.1. Główne zasady PRINCE2
W PRINCE2 wszystkie działania są podporządkowane siedmiu głównym zasadom. Są to:
1. Nieustanne uzasadnienie biznesowe.
2. Wyciąganie wniosków z doświadczenia.
3. Zdefiniowane role i odpowiedzialności.
4. Zarządzanie etapami.
5. Zarządzanie przez wyjątki.
6. Skoncentrowanie na produkcie.
7. Dostosowywanie do środowiska projektu.
Nieustanne uzasadnienie biznesowe
Zasada nieustannego uzasadnienia biznesowego (ang. continuous business justification) dla projektu oznacza, że:
• Przez podjęciem projektu przeprowadza się analizę biznesową kosztów i korzyści, aby stwierdzić, czy podjęcie projektu jest opłacalne. Projekty nieopłacalne nie są podejmowane. Dokument uzasadnienia biznesowego nosi nazwę Business Case
• W trakcie projektu dokument Business Case jest przeglądany i aktualizowany, aby sprawdzić, czy projekt ma w dalszym ciągu uzasadnienie biznesowe. Jeśli nie, to powinno się podjąć decyzję o zamknięciu projektu.
Wyciąganie wniosków z doświadczenia
Zasada wyciągania wniosków z doświadczenia (ang. learn from experience) oznacza, że zespoły powinny się uczyć na podstawie doświadczenia z projektów prowadzonych w organizacji. W tym celu w każdym projekcie prowadzi się dziennik wniosków (ang. lessons log), w którym kierownik projektu zapisuje własne spostrzeżenia i rekomendacje na przyszłość, zarówno dla siebie, jak i dla innych. Na koniec projektu kierownik projektu na podstawie zapisów z dziennika tworzy raport wniosków (ang. lessons report), który będzie stanowił obowiązkową lekturę dla innych kierowników projektów przy otwieraniu projektów.
Zdefiniowane role i odpowiedzialności
W PRINCE2 wyróżnia się trzy głównych typy interesariuszy projektu. Są to:
• sponsorzy biznesowi, który określają i pilnują uzasadnienia biznesowego,
• użytkownicy, którzy będą bezpośrednio odnosić korzyści z projektu,
• dostawcy, który zapewniają zasoby i wiedzę ekspercką dla projektu i wytwarzają produkty.
Przez pojęcie dostawcy (ang. suppliers) w PRINCE2 należy rozumieć zarówno dostawców zewnętrznych, jak i wewnętrznych, czyli po prostu zespoły projektowe.
Role uczestników projektu są w PRINCE2 zdefiniowane następująco:
• Rada Projektu (ang. Project Board) – jest to rola zbiorcza, składająca się przynajmniej z trzech członków odgrywających następujące role:
• Dyrektor wykonawczy (ang. Executive) – osoba reprezentująca sponsorów biznesowych, która ponosi główną odpowiedzialność za projekt. PRINCE2 używa terminu „executive”, które po polsku oznacza właśnie „dyrektor wykonawczy”. W tej roli często występuje członek zarządu organizacji, odpowiadający przed resztą zarządu za realizację projektu.
• Starszy użytkownik (ang. Senior User) – reprezentant przyszłych (lub aktualnych) użytkowników, który przedstawia wymagania użytkowników wobec projektu i pilnuje ich realizacji. Tę rolę może odgrywać jedna osoba lub kilka osób.
• Starszy dostawca (ang. Senior Supplier) – reprezentant dostawców (w tym zespołu projektowego), który prezentuje ich punkt widzenia. Tę rolę też może odgrywać jedna osoba lub kilka osób.
• Kierownik projektu (ang. Project Manager) – osoba bezpośrednio zarządzająca projektem, odpowiedzialna przed Radą Projektu,
• Kierownik zespołu (ang. Team Manager) – osoba odpowiedzialna za działanie zespołu na co dzień. Ta rola jest opcjonalna. Kierownik zespołu jest powoływany, gdy jest potrzebna specjalistyczna wiedza z określonej dziedziny (np. z dziedziny wytwarzania oprogramowania), której brakuje kierownikowi projektu. Może być też powołany, gdy zespół pracuje w pewnym oddaleniu od kierownika projektu dla koordynacji kontaktu członków zespołu z kierownikiem projektu. W większych projektach mogą być powoływani kierownicy osobnych zespołów. Kierownicy zespołów są odpowiedzialni przed kierownikiem projektu.
• Organ ds. zmian (ang. Change Authority) – to osoba lub grupa osób, która ma uprawnienia do rozpatrywania wniosków o zmianę lub stwierdzania niezgodności produktów ze specyfikacjami. Zmiany mniejszej wagi mogą być zatwierdzane przez kierownika projektu, a większej – przez organ ds. zmian, który może zarządzać zmianami w ramach ustalonego budżetu zmian. W innych metodykach organ ds. zmian nazywa się często Radą Kontroli Zmian (ang. Change Control Board). W PRINCE2 to nie musi być cała rada, rolę tę może odgrywać pojedyncza osoba.
• Wsparcie projektu (ang. Project Support) – jest to opcjonalna rola pomocnicza, świadcząca usługi administracyjne dla projektu (np. gromadzenia i przetwarzania danych, zarządzania konfiguracją), jak również udzielająca porad i wskazówek do zarządzania projektem. W mniejszych projektach obowiązki te pełni kierownik projektu, w większych może zostać utworzone specjalne „biuro obsługi projektów” obsługujące wiele projektów.
• Zabezpieczenie projektu (ang. Project Assurance) – jest to dodatkowa rola, której zadaniem jest obiektywny wgląd w ciągłość uzasadnienia biznesowego dla projektu i zapewnienie, że projekt to uzasadnienie utrzymuje. Rolę tę może odgrywać cała Rada Projektu, a może być też przydzielona do zupełnie innej osoby, wobec której kierownik projektu będzie czuł większą swobodę niż wobec Rady Projektu.
W każdym procesie wchodzącym w skład PRINCE2 poszczególne role mają jasno określone odpowiedzialności. Na przykład w procesie tworzenia dokumentu inicjującego projekt (ang. PID – Project Initialization Document) role i odpowiedzialności są opisane następująco:
• Rada Projektu
– zatwierdza wszystkie części PID.
• Dyrektor wykonawczy
– tworzy uzasadnienie biznesowe (dokument Business Case),
– zatwierdza wszystkie części PID.
• Starszy użytkownik
– dostarcza informacje i zasoby do opisów produktów,
– dostarcza informacje do podejścia do zarządzania korzyściami.
• Starszy dostawca
– zatwierdza części PID (np. plan projektu),
– zapewnia zasoby pomocne w planowaniu.
• Zabezpieczenie projektu
– przegląda większość informacji w PID.
• Kierownik projektu
– tworzy większość dokumentów wymaganych dla PID,
– tworzy podejście do zarządzania korzyściami.
• Kierownik zespołu
– pomaga w planowaniu (tworzy plan budżetu projektu, dokonuje szacowania itp.).
Zarządzanie etapami
Zarządzanie etapami polega na tym, że cały projekt PRINCE2 jest planowany z podziałem na etapy nadające się do łatwiejszego zarządzania. Etapy są oddzielone punktami kontrolnymi, w których ocenia się wykonanie poprzedniego etapu i planuje podjęcie następnego. PRINCE2 wymaga tylko dwóch etapów w projekcie: etapu inicjacji i przynajmniej jednego etapu zarządzania. Cały projekt jest poprzedzany procesem rozpoczęcia projektu. Przejście od etapu do etapu jest objęte procesem zarządzania granicą etapu. Ostatni etap kończy się procesem zamknięcia projektu.
PRINCE2 nie narzuca, jakie etapy zarządzania mają być stosowane ani sposobu podziału projektu na etapy, ani sposobów przechodzenia między etapami. Te decyzje zostawia dla Rady Projektu i kierownika projektu.
Zarządzanie przez wyjątki
W PRINCE2 każda rola ma swoje obowiązki i odpowiednie do tego uprawnienia do zarządzania. Zarządzanie jest podzielone na cztery poziomy:
1) poziom zarządzania korporacyjnego lub programowego (ponad projektem),
2) poziom dyrektorski (odpowiada Radzie Projektu),
3) poziom kierowniczy (odpowiada kierownikowi projektu),
4) poziom dostarczania (odpowiada kierownikowi zespołu).
Na poziomie zarządzania korporacyjnego lub programowego podejmuje się decyzje co do otwarcia projektu i identyfikacji wykonawcy. Na poziomie dyrektorskim przygotowuje się plany projektu, zapewnia zasoby, zatwierdza ukończenie każdego etapu i autoryzuje przejście do kolejnego etapu. Do odpowiedzialności Rady Projektu należy też określenie parametrów „BCQRST”, które mają być osiągnięte w projekcie. Dla każdego z parametrów określane są granice tolerancji, w których te parametry muszą się zmieścić w każdym etapie. Za utrzymywanie tych granic jest odpowiedzialny kierownik projektu. Może on podejmować decyzje co do konkretnych działań, w tym co do zmiany planów, o ile mieszczą się one w ustalonych granicach. Jeśli działania naprawcze będą wymagały przekroczenia granic tolerancji, to PRINCE2 nazywa taką sytuację wyjątkiem (ang. exception). Wówczas kierownik projektu powinien przekazać (eskalować) problem na wyższy poziom zarządzania, gdzie podejmuje się decyzję co do dalszego postępowania (włącznie z ewentualnym przerwaniem projektu). Sposoby postępowania w takich wypadkach powinny być uprzednio zaplanowane w planie wyjątków
To podejście w PRINCE2 nazywa się zarządzaniem przez wyjątki (ang. Manage by Exceptions).
Skoncentrowanie na produkcie
Zasada skoncentrowania się na produkcie wymaga, aby jak najwcześniej stworzyć opis produktu, który będzie stanowił emanację wizji kierownictwa, potrzeb użytkowników i punkt odniesienia dla dostawców (zespołu deweloperów). Opis produktu powinien określać cel, skład, pochodzenie i formę produktu, a także kryteria jakościowe produktu i sposób ich zapewnienia. Opis produktu zapewnia wspólne zrozumienie przez interesariuszy, co ma być przedmiotem projektu.
Skrócony opis projektu (ang. Project Brief) powinien być szybko sporządzony wraz z uzasadnieniem biznesowym, a pełny opis projektu może być tworzony dłużej z udziałem wszystkich interesariuszy.
Dostosowywanie do środowiska projektu
PRINCE2 może być dostosowany do dowolnego rozmiaru projektu, do różnych warunków i języka. Dostosowywaniu podlegają tzw. tematy (ang. themes), które obejmują:
