Projekty - dokumentowanie pomysłu, prototypów, opisów funkcjonalności itp... Opcje

[olechafm]

Czy istnieje jakaś kompletna metodyka lub wzorzec wykonywania dokumentacji projektu internetowego. Nie chodzi mi o rozwiązania pomagające dokumentować kod w trakcie programowania tak by na koniec powstała nam DTR'ka ale o jakiś standard albo dobre przykłady dokumentacji wykonywanej przed rozpoczęciem projektu. Takiej, na którą przenosi się pomysł, opisuje wszystkie aspekty działania, w której uwzględnia się prototypy, przypadki użycia, diagramy UML itd. Powiedzmy, że jestem pomysłodawcą jakiegoś portalu internetowego, chce wynająć firmę, która mi to napisze i oczekują ode mnie, że przedstawię im ten pomysł w formie na tyle spójnej, jasnej i rzeczowej, że muszę taką dokumentację przygotować. Wiem, że przeważnie to firma realizująca takie zlecenie przygotowuje taki opis bazując na pomysłach i uwagach klienta, ale powiedzmy, że ja chce całość przygotować zanim, wybiorę firmę do realizacji.

Jakie są Wasze doświadczenia, korzystacie z jakichś gotowych szablonów czy wzorców?

up please....

[wookieb]

Proszę nie podbijać tematu.

[Zyx]

Wzorca gotowego nie ma, natomiast istnieją rozmaite metodyki określające, jakie dokumenty muszą powstawać, jaki jest ich cel i kiedy są realizowane.

Najbardziej biurokratyczne podejście to tzw. model kaskadowy składający się z sześciu faz, w trakcie których powstaje kilka różnych, coraz bardziej szczegółowych dokumentacji, zaś kodowanie wszystkiego (i weryfikacja) jest dopiero na końcu. Przejście do następnej fazy robione jest dopiero wtedy, gdy efekt dotychczasowej został ukończony, przejrzany i zatwierdzony. Mimo dużej ilości dokumentów, podejście to jest dość kosztowne, czasochłonne i mało odporne na zmiany wymagań. Dlatego stosowane jest dość rzadko i w zasadzie głównie do projektów, gdzie wymagania są dobrze poznane i istnieją uwarunkowania prawne, które wymagają takiego, a nie innego podejścia (np. aplikacje wojskowe). Do normalnego oprogramowania lepiej jest wykorzystać bardziej elastyczne metody, gdzie dokumentów jest mniej, a za to więcej jest kodowania i testowania tego, co już zostało zrobione:

- model iteracyjny - wykonujemy jedynie ogólny projekt systemu oraz planujemy iteracje. W każdej iteracji planujemy szczegółowo wycinek funkcjonalności, implementujemy go i testujemy. Dzięki temu doprecyzowywanie wymagań może uwzględniać wyniki testów wcześniejszych faz.
- model prototypowy - najpierw robimy prototyp, by sprawdzić czy dobrze zrozumieliśmy klienta, a później robimy dokumentację, opisujemy wyniki testów i implementujemy właściwy system.
- model spiralny - dość ogólny model nieco podobny do modelu iteracyjnego; bez rysunku ciężko mi go opisać .

Dodatkowo masz programowanie zwinne wykorzystujące niektóre z powyższych modeli i nastawione przede wszystkim na samą implementację i częstą inspekcję tego, co się właściwie tworzy.

W zależności od wybranego modelu trzeba stworzyć mniej lub więcej dokumentacji, która zawiera różną ilość informacji. Na pewno można wyróżnić specyfikację wymagań funkcjonalnych. Cały system jest tu rozbity na pojedyncze wymagania, odpowiednio nazwane i ponumerowane. Każde z nich ma opis, informacje o tym, kto będzie je wykonywać, warunki jakie muszą zajść, aby wymaganie mogło być przez system wykonane, opis efektu końcowego, scenariusz użycia...

Generalnie o tym można by pisać i pisać. Napisano o tym całe mnóstwo książek, na studiach miałem to wałkowane przez parę semestrów, więc temat jest rozległy, a co więcej - teoria jest dość trudna do zastosowania w praktyce, gdyż każdy projekt jest inny. Liczy się tu intuicja, umiejętność przewidywania i planowania; łatwo wyczuć, kiedy ktoś postępuje według instrukcji z książki i "nie czai, o co w tym chodzi".

Ten post edytował Zyx 13.07.2011, 09:49:49

[olechafm]

Dzięki Zyx.

Pzdr