Data publikacji: 26.09.2014
Kluczową sprawą dla sukcesu projektu, który polega na stworzeniu programu na zamówienie, jest precyzyjne określenie co program ma robić i jak ma wyglądać.
Specyfikacja powinna zawierać:
- Dane wejściowe oraz ich źródło (np. plik, wprowadzenie przez użytkownika, webservice, baza danych)
- Dane wyjściowe – format, postać, miejsce docelowe (np. ekran, drukarka, plik, folder, zapis w bazie danych, webservice)
- Zakres przetwarzania – w jaki sposób dane wejściowe mają być przetworzone na dane wyjściowe
- Interfejs użytkownika, czyli jak program ma wyglądać, w szczególności:
- Menu
- Spisanie i rozplanowanie poszczególnych ekranów (pola wyjściowe i wejściowe, przyciski)
- Przejścia pomiędzy ekranami
Ta specyfikacja jest podstawą do:
- przygotowania wyceny, z której wynika kwota wynagrodzenia zawarta w umowie
- określenia terminu wykonania, który również jest istotnym punktem w umowie
- zbudowania całej koncepcji rozwiązania
Dlatego późniejsze zmiany są trudne do wprowadzenia.
Dlatego tak ważne jest, żeby specyfikacja była kompletna i precyzyjna.
Część zmian jest często możliwych do wprowadzenia, ale trzeba się liczyć z większymi kosztami i przesunięciem terminu zakończenia prac. Im zmiany bardziej rewolucyjne tym trudniej je wprowadzić w życie i tym większe koszty.
Podobnie jak z budową domu – gdy gotowe są fundamenty i powstaje część parterowa, można stosunkowo łatwo zmienić w projekcie rozkład pomieszczeń na górze, ale zmiana tego, co już jest zbudowane jest trudna. Można wprawdzie zburzyć ścianki działowe i na nowo inaczej je postawić, ale wylanych już fundamentów zmienić się nie da (chyba, żeby je zniszczyć i zacząć budowę od nowa). Dodanie jeszcze jednego piętra też może nie być możliwe, bo fundamenty zostały obliczone pod kątem określonego maksymalnego obciążenia, wynikającego z wielkości i funkcji budynku.
Nasze doświadczenie pokazuje, że nie wszystko, zwłaszcza jeżeli chodzi o interfejs użytkownika, daje się przelać na papier w formie specyfikacji. Często dopiero, gdy zamawiający zobaczy działający program, stwierdza, że jednak nie o to mu chodziło, że chciałby coś pozmieniać, chociaż wszystko wykonano zgodnie ze specyfikacją.
Dlatego w naszej pracy wykorzystujemy prototypy.
Prototyp to odpowiednik wizualizacji domu, którą przygotowują najlepsi architekci dla swoich klientów jako element projektu. Wizualizacja pozwala im zobaczyć jak dom będzie wyglądał.
W naszym przypadku prototyp to program, na ogół w postaci strony www, który powinien odpowiadać założeniom ze specyfikacji. Prototyp można przeklikać w celu weryfikacji czy pierwotne założenia były prawidłowe, czy nawigacja jest optymalna i ergonomiczna. Zatwierdzony przez zlecającego prototyp jest już podstawą do wykonania prac programistycznych.
Czasem jest tak, że wykonanie prototypu jest przedmiotem pierwszej umowy z zamawiającym. Wtedy prototyp jest załącznikiem do właściwej umowy. To całkiem sensowne podejście.
A co wtedy, gdy na początku nie są znane wszystkie szczegóły?
Możliwy jest wariant, w którym na starcie nie określamy szczegółów całego projektu a jedynie podstawowe założenia oraz szczegóły tego, co ma być wykonane w pierwszym kroku. Metodyka ta określana jest jako programowanie zwinne lub z ang. agile software development.
Ten wariant jest bardzo dobry zwłaszcza w sytuacjach, gdy zamawiający nie ma precyzyjnej wizji tego, co chce uzyskać, bo wizja krystalizuje się stopniowo w miarę postępu projektu. Minus jest taki, że w tym przypadku nie można określić ani kosztów całego projektu ani terminu ukończenia.
Zainteresowanych zapraszam do kontaktu.