Szybkie tworzenie projektów informatycznych [strona 3]

Dotychczas zajmowaliśmy się wizją produktu, która powinna zabrać mniej więcej połowę czasu poświęconego na pierwszą fazę projektu.

W tym miejscu powinniśmy mieć jasną definicję, nie tylko jakie problemy mamy rozwiązać i w jaki sposób, ale także - co najważniejsze - korzyści biznesowe, jakie będziemy czerpać z gotowego produktu.

Jeżeli nie zostały one wyrażone jasno w wizji projektu, bądź korzyści biznesowe nie przekraczają kosztów kontynuacji projektu, należałoby projekt definitywnie zakończyć. Można oszczędzić dziesiątki, a czasem setki tysięcy złotych i tworzyć o wiele więcej zakończonych sukcesem projektów, jeśli tylko posiada się umiejętność zarzucenia niepotrzebnych projektów a kontynuacji tylko tych projektów, które mają jasną wizję produktu i dobrze sprecyzowane, realne korzyści biznesowe.

Zakładając, że wybieramy kontynuację projektu, następnym naszym celem jest stworzenie szczegółowej specyfikacji produktu. Ten dokument może przyjmować różne nazwy - dokumentacja funkcjonalna, specyfikacja techniczna, projekt systemu. Jednakże kluczową funkcją jest zawsze to samo - dokładne określenie jak budowniczy produktu będą implementować poszczególne funkcje, możliwości, cechy produktu.

Powinno to być zrobione z taką samą szczegółowością jak architekt opisuje szczegóły budowy nowego budynku. Każdy uczestniczący w tworzeniu produktu powinien móc odwołać się do tego dokumentu aby zobaczyć jak ma stworzyć daną funkcję.

Działy specyfikacji produktu
Podobnie jak w wizji produktu, specyfikacja produktu składa się z kilku sekcji. Wraz z kolejnymi projektami sekcje specyfikacji produktu dla poszczególnych zespołów projektowych wyklarują się zgodnie z potrzebami. Poniżej przedstawione są kluczowe działy, niezbędne dla poprawnego stworzenia szczegółowej specyfikacji produktu.

1.Sekcja zależności od środowiska referencyjnego opisuje jak produkt będzie integrował się ze środowiskiem referencyjnym. Przedstawione tutaj będą oczekiwania oraz wymagania dotyczące poprawnego działania produktu w środowisku referencyjnym.
2.Zadania produktu opisują jak w produkcie będą zaimplementowane rozwiązania zidentyfikowane w trakcie współpracy z klientami, użytkownikami produktu. Ta sekcja pozwoli zarówno użytkownikom jak i budowniczym produktu zrozumieć jak ten produkt będzie współgrał ze środowiskiem referencyjnym aby realizować zadania, które zostały wcześniej zidentyfikowane.
3.Sekcja implementacji w detalach opisuje specyfikę budowania aplikacji w serii specyfikacji niższego rzędu (bardziej szczegółowych) - specyfikacja danych, specyfikacja komponentów oraz specyfikacja interfejsu użytkownika.
- Specyfikacja danych służy uszczegółowieniu wszystkich źródeł danych które muszą być utworzone i przedstawia rozwiązania za pomocą których produkt będzie z nich korzystał. Ta specyfikacja musi być na tyle szczegółowa, aby budowniczy 'centrum danych' mogli stworzyć odpowiednie struktury wymagane przez produkt. Powinno się także umożliwić identyfikację, które dane są stałe i wymagają szczególnej ochrony (i tworzenia kopii zapasowych), a które są tymczasowe.
- Specyfikacja komponentów przedstawia szczegóły wszystkich funkcji i wywołań używanych przez poszczególne części produktu, nie tylko dokumentując specyficzne dla produktu elementy, ale także używane elementy środowiska referencyjnego, które integrują się z produktem. Informacje tutaj zawarte powinny pozwolić programistom na tworzenie kodu bez potrzeby przeprowadzania dodatkowych badań, czy też niepotrzebnych konsultacji.
- Specyfikacja interfejsu użytkownika opisuje jak będzie wyglądał interfejs użytkownika dla poszczególnych elementów produktu. Informacje zawarte w tym dokumencie powinny zawierać kompletne projekty graficzne dla każdego przedstawionego użytkownikowi elementu produktu.
4.Specyfikacja środowiska produktu mówi o miejscu produktu w otaczającym go środowisku i bierze pod uwagę takie czynniki jak bezpieczeństwo fizyczne systemu, zagadnienia wymaganej przestrzeni, rozwiązania backupu, procedury awaryjne, licencje na oprogramowanie użyte przy budowie produktu, zagadnienia wydajności, planowanie obciążenia sieci komputerowych.
5.Plan testów wyznacza, które funkcje systemu zostaną przetestowane w fazie budowania produktu. W tej sekcji powinien znaleźć się również harmonogram testów zarówno dla oprogramowania jak i użytego sprzętu.
6.Plan dokumentowania opisuje w szczegółach jak będzie tworzona dokumentacja produktu, zarówno systemowa jak i dla korzystającego z niego użytkownika. Powinny znaleźć się tutaj informacje o formatach w jakich tworzona będzie dokumentacja oraz o dacie jej ostatecznego ukończenia. Dokumentacja systemu powinna być rozwijana wraz z budową aplikacji i ściśle oparta na specyfikacji produktu.
7.Plan budowy produktu to harmonogram czasu spędzonego przez poszczególnych członków zespołu i przedstawienie wynikowych elementów produktu jakie każdy z członków stworzy w określonym czasie. Ten plan powinien być głównym planem obowiązującym dla budowniczych produktu.

Przy końcu fazy tworzenia specyfikacji produktu zespół powinien dokonać aktualizacji dokumentu opisującego ryzyko, umieszczając w nim wszystkie nowe zagrożenia jakie ujawniły się przy tworzeniu szczegółowej specyfikacji produktu. Co za tym idzie należy wypracować działania, które pozwolą to ryzyko zmniejszyć.

Przejście do fazy budowania produktu
Jeśli cała dokumentacja fazy projektowania jest gotowa i podpisana przez kierownika finansowego, zespół może przejść do fazy budowania produktu. Będąc w tym punkcie powinniśmy mieć wystarczającą ilość informacji aby teoretycznie zagwarantować, że zespół budowniczych aplikacji będzie mógł dostarczyć produkt taki, jaki założyliśmy w części wizja produktu oraz uszczegółowiliśmy w części specyfikacja produktu.