Przegląd specyfikacji wymagań oprogramowania – 10 kroków do zapewnienia wysokiej jakości

To niebywałe, jak proste metody mogą być zaskakująco skuteczne!
W tym artykule pokażę Ci jak krok po kroku wdrożyć proces przeglądu specyfikacji wymagań oprogramowania.
Proces, którego oczekiwane ROI jest na poziomie min. 10:11.
Zaczynamy?

Cel – dlaczego warto testować specyfikację wymagań oprogramowania?

Celem przedstawionego procesu jest trwałe podniesienie jakości dokumentacji. Nie chodzi wyłącznie o testowanie, ale przede wszystkim o zapobieganie pojawianiu się podobnych błędów w przyszłości.

Wdrożenie tego procesu powinno zająć nie więcej niż 1 dzień pracy kilku osób. Taki będzie koszt.
A zyski?

Spójrz na poniższy wykres2
Według badań przeprowadzonych w NASA, koszty wprowadzenia zmiany na etapie developmentu to od 20 do 100 razy tyle, ile kosztuje ta sama zmiana na etapie budowania koncepcji.
Wprowadzenie tej zmiany w trakcie testów czy utrzymania, to nawet 1000 razy więcej.

przegląd specyfikacji wymagań oprogramowania - NASA koszty naprawy błędów na różnych etapach
Źródło: https://www.nasa.gov/seh/2-5-cost-effectiveness-considerations

Być może więc inwestycja w ten proces zwróci się już po wykryciu pierwszego błędu w specyfikacji.

Kroki procesu przeglądu specyfikacji wymagań oprogramowania

Poniższa checklista wraz z arkuszem do wprowadzania wyników znajduje się na stronie z materiałami do pobrania

Pobierz checklistę do przeglądu dokumentacji
POBIERZ CHECKLISTĘ

1. Ustal cel przeglądu

Celem procesu kontroli jakości specyfikacji wymagań oprogramowania jest oczywiście poprawa tej jakości. Co to dokładnie znaczy?

Ustal kryteria dotyczące maksymalnej akceptowalnej liczby błędów na 1 stronę tekstu.
Np. kontrola musi wykazać mniej niż 1 krytyczny błąd na stronę (średnio), aby uznać proces za zakończony z sukcesem.

2. Wybierz dokument

Zacznij na małą skalę. Wybierz jeden dokument. Im bardziej typowy, tym lepiej.
Jeżeli chcesz aktywnie brać udział w tym procesie, to nie wybieraj własnej specyfikacji wymagań.

3. Wybierz zawartość (losowo)

Wybierz losowo fragment dokumentu, który będzie podlegał kontroli. Mogą to być nawet 3 strony i raczej nie więcej niż 10, gdyż bardzo ciężko utrzymać skupienie na przeglądzie przez długi czas.

Ważne, aby ten fragment zawierał głównie treść, a nie diagramy.

4. Ustal kryteria przeglądu

Ustal kategorie błędów. Na przykład:

  • cel przeglądu: niejednoznaczne wyrażenia,
  • poza zakresem przeglądu: błędy logiki biznesowej (nie inwestujemy czasu w pełną analizę),
  • itd.

Podobnie ustal priorytety błędów, przykładowo:

  • błąd krytyczny – niejednoznaczność, której zmiana po wdrożeniu zajmie min. 1 dzień pracy programistycznej,
  • błąd pomijalny – niejednoznaczność, której zmiana po wdrożeniu może zostać wykonana w mniej niż 1 godzinę, bez ryzyka wygenerowania nowych błędów (np. zmiana koloru)

5. Wybierz osoby i ustal role

Jeżeli tylko masz możliwość, to na potrzeby przeglądu zbuduj zespół z kilku osób (2-5) z podziałem na role:

  • koordynator procesu – ktoś, kto wdraża kroki z tej listy
  • przeglądający – osoba zgłaszająca błędy w specyfikacji
  • analityk – ktoś, kto zbierze i przeanalizuje wyniki

6. Wykonaj przegląd specyfikacji wymagań oprogramowania

Pobierz checklistę do przeglądu dokumentacji

Każdy z przeglądających analizuje dokument i raportuje błędy z podziałem na kategorie. Możesz skorzystać z wspomnianego szablonu.

Dopisuj do zgłoszeń obszar, którego dotyczą, oraz możliwą przyczynę powstania błędu.

7. Zbierz i opracuj wyniki

Analityk zbiera wyniki do jednego dokumentu, a następnie:

  • potwierdza ważność zgłoszeń (priorytety)
  • grupuje zgłoszenia według kategorii (użyteczność, wydajność itp.)
  • szacuje liczbę błędów w całym dokumencie:
    • mnoży średni wynik przez liczbę stron,
    • zakłada, że część błędów mogła być niezauważona (np. +20% – wynik do wypracowania w miarę zdobywania doświadczenia)
  • oblicza potencjalny koszt pozostawienia dokumentacji w aktualnym stanie:
    • uwzględnia, że tylko część błędów wróci do naprawy (np. 50% – do przeanalizowania na podstawie wcześniejszych doświadczeń, np. zwrotek w systemie ticketowym),
    • przelicza tę liczbę przez średni koszt naprawy błędu na etapie końcowych testów,
  • przedstawia te wyniki koordynatorowi, który podejmuje dalsze decyzje.

8. Zdefiniuj i wdróż działania naprawcze

Na podstawie wyniku z testów specyfikacji wymagań oprogramowania wdróż proaktywne działania naprawcze.

  • skoncentruj wysiłek na tych obszarach, które mają największą liczbę krytycznych błędów,
  • szukaj rozwiązań długofalowych, które wyeliminują przyczynę powstawania błędów, takich jak:
    • zorganizuj szkolenie pomagające zrozumieć dany temat, co przełoży się na precyzyjniejsze wymagania,
    • przygotuj checklisty do wykorzystania w każdym projekcie,
    • opracuj FAQ dla krytycznych zagadnień,
    • stwórz gotowe do użycia szablony,
    • itp.
  • pamiętaj o ROI, czyli żeby koszty tych działań nie przewyższyły spodziewanych korzyści.

9. Powtarzaj aż do osiągnięcia celu z pkt. 1

Zwróć dokument do poprawy. Oczekuj poprawy całości, nie tylko wybranych stron.

Powtórz cały proces po otrzymaniu kolejnej wersji specyfikacji wymagań oprogramowania. Najlepiej wybierz losowo inny zestaw stron dokumentu.
Testuj tak długo, aż cel założony w pkt 1 nie zostanie osiągnięty, lub gdy kontynuowanie procesu przestanie być opłacalne.

10. Oblicz efektywność procesu

Po osiągnięciu celu podsumuj wyniki:

  • liczbę błędów z pierwszego i ostatniego przeglądu,
  • zaoszczędzone koszty, dzięki wczesnemu wykryciu błędów,
  • nakład pracy na działania związane z przeglądami (czas, koszt),
  • efektywność kosztowa – jaki był zysk/strata z inwestycji w ten proces.

Zacznij działać – droga do poprawy specyfikacji wymagań oprogramowania

Zrób pierwszy krok, żeby przekonać się czy to działa.

Pobierz checklistę do przeglądu dokumentacji

1. Pobierz checklistę ze strony z materiałami.
2. Wykonaj przegląd przy minimalnych możliwych kosztach.
3. Sprawdź wyniki.

Jaki uzyskałeś wynik?


Moja działania w zakresie pracy ze specyfikacją wymagań są inspirowane publikacjami Toma Gilba, „Value Planning” oraz „Competitive Engineering

1 Tom Gilb, „Competitive Engineering”, str. 246
2 NASA „Systems Engineering Handbook„, https://www.nasa.gov/seh/2-5-cost-effectiveness-considerations, rozdz. 2.5

Witaj w Project Makers!

Cześć, jestem Artur.

Uruchomiłem bloga Project Makers po to, żeby pokazywać jak przy pomocy podstawowych narzędzi i zdrowego rozsądku, każdy może w krótkim czasie osiągnąć mistrzostwo w zwinnym zarządzaniu projektami.

A wszystko zaczęło się od niezaliczonych egzaminów z programowania
(czytaj dalej…)

Potrzebujesz konsultacji?
Umów BEZPŁATNE spotkanie!

bezpłatne konsultacje zarządzanie projektami

Partnerzy Project Makers

Szukasz ciekawych treści?

Najnowsze wpisy

  • All Post
  • Definiowanie wymagań
  • Narzędzia
  • Planowanie
  • Praca z celami
  • Rekomendacje
  • Rozmowy z ekspertami
  • Zarządzanie budżetem
  • Zarządzanie jakością
  • Zarządzanie zespołem

Znajdź na blogu

Szukasz ciekawych, treści
o Zwinnym Zarządzaniu Projektami?

Zapisz się do Newslettera Project Makers!
Najnowsze trendy, ciekawostki, narzędzia.
Tylko sprawdzone treści. 

Współpracuję z:

Project Makers
u. Dworcowa 8
44-240 Żory
artur@projectmakers.pl

Copyright © 2024 Project Makers