Systemy standardowe i dedykowane

Można przyjąć właściwie ze 100% pewnością, że każdy czytający te słowa na co dzień korzysta z oprogramowania. Prawdopodobnie wielu czytelników ma też związek z wdrażaniem lub tworzeniem nowego oprogramowania – jako osoby formułujące wymagania funkcjonalne, testujące gotowy produkt lub nawet piszące samodzielnie kod programów.

Zazwyczaj poruszamy zagadnienia związane z wdrażaniem standardowych systemów, takich jak SAP ERP, SAP CRM, SAP BI i inne. Wykorzystanie gotowych rozwiązań, opracowanych i sprawdzonych wcześniej w tysiącach projektów, w relatywnie krótkim czasie pozwala firmie wykorzystać wiedzę i doświadczenia „wbudowane” w standardowy system przez wiele lat jego rozwoju.

Wiele firm korzysta również w jakimś stopniu z rozwiązań dedykowanych, uzupełniających standardowe systemy. Z jednej strony pozwala to uzyskać rozwiązanie bardzo dokładnie dopasowane do konkretnych potrzeb, stworzone „na miarę” dla firmy. Z drugiej strony stwarza duże wyzwanie efektywnego zorganizowania pracy i zarządzania projektem. Precyzyjne opisanie wymagań, monitorowanie postępów prac, wszechstronne testowanie, dokumentacja rozwiązania – to tradycyjne „trudne tematy” związane z każdym projektem rozwoju oprogramowania.

Dlaczego potrzebujemy metodyki projektowej?

W każdej dziedzinie działalności możemy systematycznie poprawiać jakość pracy poprzez zbieranie doświadczeń, dobrych praktyk („jakie podejście działało wcześniej, a jakie okazało się nieskuteczne”) i wypracowanie na ich podstawie standardów pracy. Oczywiście nie musimy uczyć się tylko na własnych błędach, powinniśmy czerpać również z doświadczeń innych firm i organizacji (np. Project Management Institute), szkoleń i książek uznanych ekspertów.

W efekcie powstaje metodyka, która wyznacza ramy planowania i realizacji projektów, śledzenia postępów, dokumentowania prac. Ułatwia komunikację, ponieważ wprowadza wspólną terminologię, którą posługują się uczestnicy projektu. Wspiera gromadzenie wiedzy i doświadczenia zespołów ze zrealizowanych przedsięwzięć. Dzięki temu kolejne projekty opierają się na wypracowanych wcześniej dobrych standardach oraz unikają wcześniej popełnianych błędów.

Elementy metodyki opisane w tym artykule (podział na fazy, podział ról, dokumentacja) dotyczą szeroko pojętego „rozwoju oprogramowania biznesowego” – opracowania lub rozbudowy dedykowanych rozwiązań IT dla przedsiębiorstw lub innych organizacji, wspierających ich procesy wewnętrzne lub współpracę z kontrahentami. Oprogramowania, które:

  • obejmuje elementy takie jak: interfejs użytkownika, komunikacja z innymi systemami, mechanizmy raportowania, wydruki lub inne komunikaty przesyłane do użytkowników, mechanizmy administracji i monitorowania.
  • korzysta najczęściej z relacyjnej bazy danych do przechowywania danych potrzebnych do działania systemu.
  • jest opracowane w językach programowania 3/4GL, jak Java, C#, C++, VB, SQL
  • zawiera interfejs użytkownika „tradycyjnej” aplikacji desktopowej, aplikacji web lub aplikacji mobilnej.

Metodyki opisanej tutaj nie stosujemy do wdrożeń oprogramowania standardowego, tzn. projektów, które koncentrują się na modelowaniu procesów biznesowych, a następnie parametryzacji i modyfikacji standardowych systemów. Projekty tego rodzaju (np. wdrożenia ERP, CRM, BI) są opisane przez metodykę wdrożeniową All for One GoForward.

Fazy projektu

Podstawowym sposobem radzenia sobie ze złożonością projektów jest podział harmonogramu i zakresu na części. Ogólny harmonogram projektu dzielimy na fazy, które odpowiadają różnym rodzajom pracy. W Metodyce Rozwoju Oprogramowania BCC (aktualnie All for One) jest to pięć głównych faz.

  1. W fazie Przygotowania projektu zostają formalnie powołane zespoły projektowe. Kierownik projektu (tę i inne role projektowe objaśniamy dokładnie poniżej) definiuje plany, standardy pracy, narzędzia do wykorzystania w projekcie, organizuje inne zasoby (np. sale projektowe, rzutniki, licencje na oprogramowanie). Przygotowuje pakiet informacji dla pozostałych uczestników projektu, tak aby mogli oni sprawnie rozpocząć swoje prace od początku drugiej fazy projektu.
  2. Faza Koncepcji jest poświęcona na opracowanie szczegółowej specyfikacji rozwiązania (por. sekcja: Dokumentacja).
  3. Podczas Realizacji zostaje opracowane główne rozwiązanie – produkt projektu, tzn. nowy system lub zmiany/rozszerzenia do istniejącej aplikacji. Faza Realizacji obejmuje również testy przewidziane w metodyce BCC.
  4. Przygotowanie do pracy produkcyjnej to zestaw działań przygotowujących do uruchomienia aplikacji w docelowym środowisku. Zależnie od specyfiki projektu może obejmować jedną lub więcej z następujących czynności: opracowanie instrukcji dla użytkowników końcowych, szkolenie użytkowników, ustalenie procedur administracji dla nowej aplikacji (np. objęcie jej systemem backupów), przeniesienie rozwiązania na serwery produkcyjne, napełnienie systemu kompletem danych wymaganych do rozpoczęcia pracy, inne specyficzne dla danego systemu lub organizacji (np. audyt).
  5. Faza Startu produkcyjnego rozpoczyna się, kiedy użytkownicy w organizacji zaczynają faktycznie korzystać z nowego systemu. Zazwyczaj obejmuje od 2 do 6 tygodni wsparcia użytkowników przez zespół projektowy, do czasu wykrycia i rozwiązania ewentualnych problemów, które nie zostały zdiagnozowane wcześniej podczas testów w środowisku rozwojowym.

W każdym projekcie, gdzie faza Realizacji trwa powyżej jednego miesiąca, Metodyka Rozwoju Oprogramowania BCC zaleca iteracyjne podejście do planowania tej fazy. Oznacza to podział realizacji projektu na mniejsze części (iteracje), które kończą się dostarczeniem działających podzbiorów funkcjonalności. Zaplanowanie takich iteracji wymaga dodatkowej pracy dla programisty wiodącego i może niekiedy wymagać tymczasowych zmian w funkcjonalności (aby uruchomić fragmenty rozwiązania niezależnie). Jednak korzyści z takiego podejścia są ewidentne:

  • Testy wykonywane na końcu każdej iteracji pozwalają zweryfikować rzeczywiste zaawansowanie prac, w przeciwieństwie do polegania na samych „raportach statusu”. Unikamy wtedy typowego błędu, popełnianego na początkowym etapie wielu projektów, kiedy poświęcone nakłady pracy są utożsamiane z faktycznymi postępami realizacji projektu.
  • Możliwość konfrontacji właściciela produktu (lub innych przedstawicieli użytkowników systemu) z prototypem rozwiązania na wcześniejszym etapie pozwala na weryfikację, czy specyfikacja wymagań była prawidłowa i czy została właściwie zinterpretowana przez zespół projektowy. Im wcześniej w projekcie zostaną wykryte błędy lub niejednoznaczności w koncepcji, tym większa szansa na ich naprawienie w ramach harmonogramu. Odkładanie tej weryfikacji na koniec fazy realizacji oznacza, że możemy odkryć największe problemy dopiero wtedy, kiedy pozostało już mało czasu na ich rozwiązanie, przed terminem uruchomienia produkcyjnego.

Podejście iteracyjne do planowania projektu

Schemat ilustrujący podejście iteracyjne do planowania projektu zakłada, że iteracje dotyczą przyrostowej realizacji i testów nowego systemu, przed jego uruchomieniem produkcyjnym. W takim przypadku po ostatniej iteracji przeprowadzamy test integracyjny całego rozwiązania i planujemy fazy 4. i 5. projektu.

W wielu projektach mamy natomiast do czynienia z sytuacją rozbudowy/modyfikacji istniejącego systemu, który działa już produkcyjnie. W takim przypadku rekomendowane jest również podejście iteracyjne, gdzie każda iteracja może kończyć się ministartem produkcyjnym (czyli w praktyce fazy 4. i 5. projektu powielamy dla każdej części zakresu). Z jednej strony oznacza to większy nakład pracy dla administratorów systemu i wsparcia użytkowników (wielokrotne przenoszenie rozwiązania na system produkcyjny). Z drugiej strony zmniejszamy ryzyko każdej iteracji (przenosimy mniejszy zbiór zmian, łatwiej jest przewidzieć wszystkie tego konsekwencje, zamiast startu „big bang”). Dzięki temu podejściu dostarczamy również kolejne grupy funkcji do wykorzystania w organizacji we wcześniejszym terminie (zamiast oczekiwania na zakończenie całości), czyli inwestycja w projekt wcześniej się zwraca.

Role i struktura organizacyjna projektu

Projekty są realizowane przez zespoły osób, powoływane na czas trwania projektu. Wprawdzie kolejne projekty mogą być realizowane przez ten sam zespół, lecz zasadniczo przyjmuje się, że zespół jest tworzony ad hoc do realizacji pojedynczego przedsięwzięcia i nie musi pokrywać się ze stałą strukturą organizacyjną firmy. Osoba może być przypisana do projektu w pełnym wymiarze czasu (w przypadku większych przedsięwzięć) lub tylko na określoną część czasu, przypisanie może być też zmienne w różnych fazach projektu.

Każdy z uczestników projektu powinien mieć jasno określoną rolę w zespole, aby uniknąć nieporozumień i tematów „niczyich”, za które nikt nie ponosi odpowiedzialności. W niewielkich projektach (gdzie cały zespół liczy tylko 2-3 osoby) możliwe jest natomiast łączenie różnych ról przez pojedyncze osoby (na przykład kierownik projektu + właściciel produktu, programista + tester).

Kierownik projektu

Kierownik odpowiada za zorganizowanie projektu i sukces całego przedsięwzięcia. Przygotowuje projekt od strony organizacyjnej od pierwszej fazy projektu (powołanie zespołów, ustalenie standardów pracy i raportowania). Tworzy plan i budżet projektu – na podstawie informacji zebranych od pozostałych uczestników (np. estymacje pracochłonności, sekwencja zależności pomiędzy działaniami).

Podczas trwania projektu główne obszary pracy kierownika projektu to:

  • zbieranie informacji o statusie i postępach prac,
  • jak najwcześniejsze wykrywanie wszelkich przeszkód w postępach prac i zapobieganie ich negatywnemu wpływowi (np. zapewnienie zastępstwa dla nieobecnego pracownika, przyspieszenie terminu podjęcia ważnej decyzji, mediacja pomiędzy zespołami, które nie mogą uzgodnić rozwiązania),
  • obsługa administracyjna projektu/raportowanie.

W dużych przedsięwzięciach kierownik projektu jest wspierany przez biuro projektu/sekretarza projektu i deleguje do nich zadania administracyjne, po to żeby móc skupić się na poziomie merytorycznym i strategicznym projektu.

Właściciel produktu

Właściciel produktu (product owner – nazwa roli zaczerpnięta z podejścia agile – Scrum) reprezentuje szeroko rozumianego „klienta” projektu, czyli odbiorcę rezultatów. Odpowiada za to, by rezultaty projektu były wartościowe dla organizacji, która projekt zamówiła. Właściciel produktu:

  • określa cechy produktu, tzn. odpowiada za treść koncepcji/specyfikacji zakresu projektu,
  • podejmuje decyzje co do priorytetów w realizacji poszczególnych funkcji,
  • wyjaśnia wątpliwości zespołu co do funkcjonalności, które pojawiają się w toku prac,
  • akceptuje wyniki testów.

Programista wiodący

W wielu projektach rozwoju oprogramowania zadania są dzielone pomiędzy dwóch lub więcej programistów, po to żeby zrównoleglić ich działania i dostarczyć rezultaty w krótszym terminie i/lub wykorzystać różne kompetencje (np. specjalista od web services po stronie serwera i specjalista aplikacji dla urządzeń mobilnych). W każdym projekcie należy jednak wyznaczyć pojedynczą osobę pogramisty wiodącego, który odpowiada za całość strony technicznej realizacji rozwiązania.

Programista wiodący w metodyce BCC (aktualnie All for One Poland):

  • definiuje podział rozwiązania na elementy wysokiego i średniego poziomu (moduły, interfejsy pomiędzy nimi), które są następnie przydzielane jako zadania do pozostałych programistów,
  • dba o jednolite standardy pracy, np. konwencje kodowania, wzorce projektowe,
  • reprezentuje zespół programistów w procesach zapewnienia jakości (np. zatwierdzenie specyfikacji systemu, przeglądy kodu),
  • jest głównym punktem komunikacji pomiędzy zespołem programistów a innymi specjalistami technicznym angażowanymi do wsparcia projektu (np. administratorzy systemów IT, specjaliści od testów bezpieczeństwa lub wydajnościowych etc.).

Programista wiodący często jest też odpowiedzialny za samodzielną realizację poszczególnych elementów zakresu rozwiązania, w roli programisty.

Programista

Specjalista w jednym lub kilku językach programowania i technikach wytwarzania oprogramowania. Realizuje zadania przydzielone przez programistę wiodącego oraz wykonuje samodzielne testy jednostkowe swoich prac, przed ich integracją z pozostałymi modułami systemu.

W Metodyce Rozwoju Oprogramowania BCC zasadniczo nie wyróżniamy oddzielnej roli analityka, rola ta jest w praktyce łączona z rolą programisty lub testera. Od osób angażowanych do zespołu programistów jest wymagana umiejętność dokumentowania wymagań biznesowych oraz proponowania sposobów efektywnej implementacji tych wymagań.

Tester

Role związane z testami w projektach rozwoju oprogramowania występują w wielu wariantach i powinny być każdorazowo sprecyzowane przez kierownika projektu, na początku przedsięwzięcia. W małych projektach wystarczające jest połączenie tej roli z funkcją programisty (testy jednostkowe) oraz właściciela produktu (testy integracyjne/funkcjonalne). W większych przedsięwzięciach należy powołać dedykowanych testerów, którzy będą systematycznie weryfikować rezultaty projektu za pomocą zestawu specjalnych technik przygotowanych w celu zapewnienia jakości oprogramowania.

Dokumentacja

Dla osób niezwiązanych blisko z rozwojem oprogramowania słowo „dokumentacja” jest może zupełnie neutralne, ale budzi duże – i skrajne – emocje u specjalistów.

Po jednej stronie mamy liczny obóz programistów, którzy uważają, że „pisanie dokumentacji to marnowanie czasu, który można by poświęcić na tworzenie działającego programu”. Kiedy zostaną przyciśnięci do muru przez swoich przełożonych lub przez korporacyjne standardy, to z największą niechęcią tworzą „dokumentację projektową”, już po faktycznym ukończeniu programowania, jako dokument proforma potrzebny do odbioru prac. Do tego grona można dołączyć też niektórych użytkowników oprogramowania, którzy uważają, że dokładna specyfikacja wymagań jest niepotrzebna, czasochłonna i nudna do opracowania. Wystarczy trzyzdaniowy e-mail (im bardziej ogólne zdania, tym lepiej), a w rezultacie otrzymają „wszystkomający” system i wybiorą z niego to, czego będą potrzebować.

Oczywiście można przesadzić też w drugą stronę. Egzekwować w najdrobniejszych detalach rozrysowanie każdego algorytmu, każdej funkcji programu jako diagram blokowy lub inny schemat, a później pieczołowicie audytować powstający system pod kątem zgodności z tym schematem. Takie podejście tworzy jeszcze większą niechęć w pierwszym obozie wymienionym wcześniej. Programiści wtedy faktycznie zaczynają poświęcać dwa razy więcej czasu na każdą zmianę i zgodność z formalną specyfikacją staje się cenniejsza od dostarczenia wartościowego produktu dla klienta.

Jak zwykle w każdej dziedzinie, należy znaleźć rozsądne rozwiązanie leżące pośrodku.

Podobnie jak z innymi formalnościami, dokumentacja projektowa powinna być wprost proporcjonalna do wielkości, złożoności i krytycznej roli rozwiązania dla organizacji. Jeśli tworzymy skomplikowany system, złożony z wielu modułów, to dokumentacja interfejsów pomiędzy tymi modułami jest kluczowa dla dobrej współpracy pomiędzy poszczególnymi programistami. Kiedy tworzymy niewielką, ale kluczową funkcję, np. transfer przelewu do systemu bankowości elektronicznej, to musimy zaprojektować i opisać ją w każdym szczególe, przewidując zachowanie we wszystkich typowych i nietypowych sytuacjach (np. brak środków na koncie, brak połączenia z bankiem etc.), aby uniknąć sytuacji, kiedy np. kwota przelewu już „zniknęła” z konta systemu księgowego, a nie pojawiła się nigdy na koncie w banku. Natomiast kiedy tworzymy kilkulinijkowe makro w Excelu do wykorzystania przez dwie osoby… nie musimy pisać do niego żadnej dokumentacji ani rysować schematu blokowego.

W Metodyce Rozwoju Oprogramowania BCC zdefiniowaliśmy kilka kluczowych rodzajów dokumentacji, mając na uwadze m.in. zdroworozsądkowe podejście i bilans nakładu pracy do efektów dla projektu.

Specyfikacja wymagań

Dokument specyfikacji wymagań dla nowego systemu jest bezwzględnie wymagany przez Metodykę Rozwoju Oprogramowania BCC jako warunek rozpoczęcia fazy realizacji. Właściciel produktu (por. sekcja: Role i struktura organizacyjna projektu) odpowiada za opracowanie pierwszej wersji specyfikacji wymagań i jej aktualizacje, kiedy podczas projektu pojawiają się zmiany zakresu.

Kompletna, spójna i zatwierdzona specyfikacja jest podstawą komunikacji i planowania prac w projekcie. Każdy uczestnik projektu może odwołać się do niej jako punktu odniesienia do wykonania swoich zadań, np.:

  • programista – buduje system tak, aby spełniał wymagania funkcjonalne zdefiniowane w dokumencie koncepcji,
  • tester – przygotowuje scenariusze testowe weryfikujące zgodność systemu z koncepcją,
  • autor instrukcji użytkownika lub pomocy online do aplikacji – dowiaduje się ze specyfikacji, jaki jest cel implementacji poszczególnych funkcji systemu, i może prawidłowo opracować instrukcje,
  • kierownik projektu i właściciel produktu – mogą odwołać się do specyfikacji w przypadku nieporozumień co do zakresu i ustalić wspólny punkt widzenia, co jest szczególnie istotne w przypadku projektów realizowanych dla klienta zewnętrznego.

Specyfikowanie wymagań w inny sposób niż tworzenie jednego spójnego dokumentu (plus ew. załączniki), np. poprzez określenia poszczególnych wymagań rozsiane po wielu mailach, notatkach ze spotkań lub w rozmowach, tworzy ryzyko, że każdy członek zespołu projektowego „poskłada” te rozproszone informacje w inny obraz docelowego systemu.

W przypadku kiedy do projektu dołączamy kolejne osoby (co jest nieuchronne w przypadku większych przedsięwzięć, w wyniku rotacji personelu lub potrzeby powiększenia/wsparcia zespołu), to wprowadzenie nowego uczestnika projektu jest również znacznie łatwiejsze, kiedy możemy przekazać mu kompletny i aktualny dokument koncepcji.

Format dokumentu

Ze względu na dużą różnorodność produktów programistycznych realizowanych wg metodyki BCC (aktualnie All for One Poland) nie definiujemy pojedynczego szablonu dokumentu koncepcji. Metodyka wyznacza jednak podstawowy obowiązkowy zestaw elementów, który powinna zawierać specyfikacja, oraz dostarcza przykłady takich dokumentów.

Specyfikacja wymagań zawiera:

  • wstęp/cel projektu – streszczenie dokumentu, w szczególności przedstawiające cele opracowania nowego programu lub – inaczej mówiąc – powód „biznesowy”, dla którego zostaje powołany projekt,
  • scenariusze działania systemu – opis typowych użytkowników przyszłego systemu i ich interakcji z systemem,
  • elementy poza zakresem – dla uniknięcia nieporozumień warto wskazać najważniejsze elementy, które mogłyby być kojarzone przez inne osoby z zakresem projektu, jednak nie są objęte projektem (np. „Interfejs użytkownika aplikacji webowej nie będzie wspierał przeglądarki IE7 i wcześniejszych”),
  • specyfikacja szczegółowa – opis poszczególnych wymagań funkcjonalnych oraz pozafunkcjonalnych (związanych z wydajnością lub bezpieczeństwem danych); najbardziej obszerna i najbardziej zróżnicowana sekcja dokumentu, zależna od specyfiki konkretnego systemu.

Elementy wymagane w specyfikacji szczegółowej, zależne od charakteru projektu:

  • dla rozwiązań związanych z interfejsami – szczegółowy format każdego komunikatu (rekordy, pola, typy danych, status obowiązkowy/opcjonalny itp), warunki wywołujące wysłanie komunikatu, sposób potwierdzania transmisji (np. komunikat zwrotny), metody obsługi błędów, metody monitorowania interfejsu,
  • dla rozwiązań związanych z interfejsem użytkownika – szczegółowa specyfikacja każdego ekranu/pola ekranu (etykieta, format i typ danych, status obowiązkowy/opcjonalny/readonly, dodatkowe warunki, takie jak lista wartości i reguły walidacji danych),
  • dla raportów i formularzy wydruków – projekt raportu lub formularza zawierający wszystkie kolumny/pola i ich mapowanie na model danych aplikacji, reguły ustalania wartości pól kalkulowanych i inne (np. „pole z walutą i kursem wymiany ukrywamy, jeśli walutą dokumentu jest PLN”).

Kiedy powstaje specyfikacja wymagań?

Specyfikacja powstaje najczęściej w dwóch krokach:

  1. Osoba inicjująca projekt (wewnątrz organizacji lub klient zewnętrzny) przygotowuje dokument określający cele i założenia nowego projektu oraz najważniejsze wymagania funkcjonalne (np. w formie zapytania ofertowego przesłanego przez kienta). Dokument taki – po omówieniu i wyjaśnieniu nieprecyzyjnych punktów – stanowi punkt wyjścia do zaplanowania projektu, oszacowania jego harmonogramu i kosztu.
  2. Podczas fazy koncepcji w ramach projektu zaplanowane zostają sesje prac koncepcyjnych, kiedy specyfikacja zostaje doprowadzona do finalnej postaci, wymaganej przez metodykę projektową, zgodnie z opisem w poprzedniej sekcji.

W przypadku kiedy właściciel produktu/klient nie jest w stanie dostarczyć wstępnej koncepcji (opisanej w punkcie 1) na początku projektu, całość specyfikacji wymagań zostanie opracowana w ramach punktu 2, lecz w takim przypadku wiążąca wycena projektu może powstać dopiero po zakończeniu fazy Koncepcji.

Możliwy, chociaż rzadko spotykany, jest również przypadek odwrotny: specyfikacja dostarczona w punkcie 1 jest tak wyczerpująca, że zespół może przejść z fazy przygotowania projektu bezpośrednio do fazy realizacji (w przypadku prostego rozwiązania/niewielkiego projektu).

Scenariusze testowe

Koncepcja rozwiązania jest punktem wyjścia dla opracowania scenariuszy testowych, natomiast nie powinna być samodzielną podstawą do wykonywania testów. Wymagania związane z zawartością scenariuszy testowych (np. wskazanie próbek danych testowych i oczekiwanych rezultatów) są domeną zapewnienia jakości oprogramowania.

Dokumentacja techniczna

Podobnie jak w przypadku specyfikacji wymagań, ze względu na ogromną różnorodność możliwych produktów rozwoju oprogramowania metodyka BCC nie definiuje pojedynczego formatu dokumentacji technicznej systemu. Ostatnie lata przyniosły duży postęp w automatycznej lub półautomatycznej dokumentacji technicznej strony systemu, np.:

  • wizualizacja i dwustronna synchronizacja modelu bazy danych (np. w MS Visio),
  • wizualizacja modelu klas w aplikacji przez środowisko rozwoju oprogramowania,
  • generowanie dokumentacji na podstawie komentarzy umieszczonych w kodzie aplikacji,
  • dokumentacja interfejsów web services jako pliki WSDL.

Próby tworzenia i utrzymywania tego typu dokumentacji manualnie w praktyce kończą się jej szybką dezaktualizacją i przyczyniają się do obiegowych opinii typu „dokumentacja systemu jest nieaktualna już w momencie jego startu produkcyjnego”.

Dokumentacja techniczna jest ważna, lecz powinna być ograniczona do elementów, które tworzą faktyczną wartość dla zespołu projektowego – podczas trwania projektu oraz w przyszłości dla zespołów, które będą utrzymywać system. Przykłady takiej dokumentacji:

  • „mapa” głównych modułów technicznych rozwiązania i relacji między nimi (np. jako przewodnik dla nowych programistów, gdzie należy szukać poszczególnych detali implementacji),
  • opis interakcji pomiędzy różnymi elementami, jeśli ich powiązania nie są oczywiste na podstawie samego kodu programu (np. „informacja o mailu do wysłania jest zapisywana w tabeli X, zewnętrzny program Y uruchamiany jako zadanie okresowe na serwerze Z loguje się do bazy danych, pobiera listę rekordów i wysyła wiadomości, korzystając z serwera pocztowego P”),
  • opis implementacji ważnych i skomplikowanych fragmentów rozwiązania, gdzie logika implementacji nie jest łatwa do interpretacji na podstawie kodu (np. mechanizm buforowania danych, którego implementacja jest bardzo zawiła, ponieważ został wysoce zoptymalizowany pod kątem wydajności).

Instrukcje użytkownika

W przypadku prostego programu dokument specyfikacji wymagań może być na tyle czytelny, że nadaje się do przekazania bezpośrednio do końcowych użytkowników. W większości przypadków zalecane jest jednak opracowanie oddzielnych dokumentów instrukcji użytkownika. Różnice pomiędzy instrukcją a koncepcją systemu:

  • jeśli system ma różne grupy użytkowników, to opracowanie oddzielnych instrukcji dla każdej grupy upraszcza poznanie nowego systemu (każdy użytkownik koncentruje się tylko na swojej instrukcji/podzbiorze funkcji istotnych dla niego), podczas gdy specyfikacja wymagań opisuje całość,
  • instrukcje powstają pod koniec projektu (w fazie przygotowania do startu produkcyjnego), kiedy dysponujemy m.in. finalną postacią interfejsu użytkownika, mogą więc odnosić się do zrzutów ekranów i innych detali gotowego systemu, co jest niemożliwe w przypadku specyfikacji wymagań.

Zarządzanie zmianą i zapewnienie jakości

W tej części opracowania zajęliśmy się podziałem projektu programistycznego na fazy, przypisaniem odpowiednich ról i zadań wszystkim jego uczestnikom, a także zagadnieniami związanymi z dokumentowaniem. Inne istotne elementy Metodyki Rozwoju Oprogramowania BCC to zarządzanie zadaniami, sprawami otwartymi i zmianami oraz szeroki temat zapewnienia jakości w projekcie. W kolejnym opracowaniu przedstawimy rekomendacje, standardy i praktyczne zalecenia związane z tymi zagadnieniami, zawarte w Metodyce Rozwoju Oprogramowania BCC (aktualnie All for One Poland).