Kilka dobrych rad prosto z ostatnich minut wtorkowego wykładu dr Bułki. Rady te dotyczą przede wszystkim specyfikacji pisanych dla większych projektów, realizowanych w zespołach. Myślę jednak, że przydadzą się każdemu, kto zabiera się za jakikolwiek (jedno lub wieloosobowy) projekt informatyczny - w końcu dobry design document to podstawa :). Rady podstawowe

• Za specyfikację odpowiedzialna jest jedna osoba. Za jej dostępność, za wprowadzane do niej poprawki. Osoba ta rozwiązuje też sytuacje konfliktowe. Przykład z wykładu - kiedy przychodzi Project Manager do programisty i mówi, że ma być tak a tak, a on na to - "sorry, ale ta żaba to no way". Osoba odpowiedzialna za spec'a podejmuje ostateczną decyzję co ma być.
• Specyfikacja jest jednolita dla zespołu. Project Manager, programiści, QA, dostawca pizzy - wszyscy korzystają z tego samego dokumentu.
• Należy stosować jakiś sposób oznaczania rzeczy, które są niejasne, zostaną uzgodnione w przyszłości. Przyjęło się oznaczać takie miejsca magicznym FIXME.
• Specyfikacja przedstawia system z punktu widzenia użytkownika. Nie opisujemy szczegółów implementacji, ale to, jak system działa i wygląda dla tego, kto z niego korzysta.

Składowe specyfikacji

• Wprowadzenie - ogólny opis systemu, tzw. The Big Picture. Co to jest, do czego to ma służyć.
• Scenariusze Użycia - jak użytkownik może korzystać z systemu, opisane na konkretnych przykładach, z konkretnymi (nazwanymi) uczestnikami. Ot tata Adam ma syna Jasia, którego chce zapisać do przedszkola (jeśli piszemy system elektronicznej rejestracji do przedszkoli). Co robi? Jak zachowuje się nasz system?
• "niecele" - czyli to, czego system na pewno NIE będzie robił. Jest to bardzo ważne dla naszego klienta, a dla nas jest gwarancją spokojnego snu. Ot, przykładowy klient przychodzi do nas z pretensjami, czemu właśnie wyprodukowany system nie robi tego-a-tego. Pokazujemy mu spec'a i mówimy, że 'jest tu wyraźnie napisane, że system tego robić nie będzie; a pan się pod tym podpisał...' ;). Jest to często pomijana, a tak na prawdę kluczowa składowa dobrego spec'a. Wraz z dobrym określeniem tego co system będzie robił, pomaga zarysować granice funkcjonalności projektu.
• Opis - czym jest projekt, z punktu widzenia. Tu ma miejsce podział systemu na różne fragmenty. Ale uwaga - to nie jest miejsce na Elizę Orzeszkową - mimo wszystko trzeba pisać o konkretach i unikać opisów pogody nad Niemnem.
• Składowe systemu - szczegółowy opis fragmentów, na jakie podzieliliśmy projekt. Jak powinny wyglądać, jak mają działać - ale cały czas z punktu widzenia użytkownika. Pożądane są tu wszelkiego rodzaju rysunki, screeny, concept art'y, itp.

Porada końcowa Luźne stwierdzenia w spec'u są jak najbardziej pożądane. Oczywiście przesadzać nie można, ale odrobinę sensownego humoru nie zaszkodzi. Tyle moich notatek z wykładu. Jak dane mi będzie zdobyć więcej informacji, to również się nimi podzielę. Poważnie też zastanawiam się nad zamieszczeniem notatek i wniosków z poprzednich wykładów dr Bułki - dotyczących prezentacji multimedialnych i przekazu reklamowego w ogóle. Ze swojej strony odniosę się jeszcze do terminu "niecel". Nie mogliśmy znaleźć na wykładzie żadnego dobrego polskiego określenia. Ale tak w tej chwili wydaje mi się, że lepiej brzmiącym słowem - aczkolwiek troszkę mniej mówiącym - byłoby 'antycel'.