Nasze działania w praktyce wyznacza trójkąt kompromisów. Patrząc na te wzajemne uwarunkowania widać, że zawsze trzeba iść na jakiś kompromis, bo nie sposób jest wszystko osiągnąć na raz..
Poniżej prezentujemy model tworzenia systemu informacyjnego, zgodnie z podejściem antropocentrycznym Wymagania użytkowników są bardzo ważne, należy je jasno określić. Niestety czasem się zdarza, że sam użytkownik nie wie dokładnie czego chce, dlatego tak ważna jest współpraca zarówno jego jak i projektantów . W fazie rozpoznania szczególnie uwidacznia się problem niejasno sprecyzowanych wymagań przez użytkownika. Należy je jak najprędzej uściślić., bo tylko wtedy kolejny etap analizy przyniesie nam konkretne rezultaty. Po zdefiniowaniu potrzeb użytkowników i celi w specyfikacji funkcjonalnej zamieszczamy funkcje tego systemu czyli to co należy zrobić. Następnie zastanawiamy się nad odpowiednim sprzętem a następnie podajemy wstępny koszt budowy systemu. Ważne jest by na tym etapie dostać akceptacje użytkownika. Część koncepcyjna projektu jest szalenie istotna. Od poprawności jej wykonania zależeć będzie cały projekt. Jeśli popełnimy zbyt wiele błędów na tym etapie, proces ich anulowania będzie szalenie kosztowny!

Spójrzmy teraz na proces projektowania z innego punktu widzenia. Postacie wymagań wejściowych:

• język naturalny (zbieramy jak najwięcej informacji)
• formularze (obraz przepływu danych między źródłem informacji a odbiorcą)
• schematy danych

Dokumentacja:

• stanowi bazę do przyszłych zmian systemu
• jest podstawą wdrażania systemu
• jest podstawą szkolenia użytkowników
• powinna być tworzona na bieżąco
• powinno się dokumentować także zmiany w systemie

Tak więc krytycznym etapem projektu są błędy, które się w nim pojawiają. Tu jeszcze raz podkreślamy jak ważnym etapem jest prawidłowa analiza potrzeb. Żeby unikać błędów należy sprzęgać proces projektowania z procesem kontroli i weryfikacji jakości.

Praca, błędy i koszty w tworzeniu systemu.

Rozkład pracy w cyklu tworzenia systemu:

» Testowanie	15%
» Kodowanie	7%
» Projektowanie	5%
» Specyfikacja i potrzeby	6%
» Eksploatacja	67%

Źródło błędu:

» Analiza potrzeb	56%
» Kodowanie	7%
» Projektowanie	27%
» Inne	10%

Koszty poprawienia błędów:

» Analiza potrzeb	82%
» Kodowanie	1%
» Projektowanie	13%
» Inne	4%

Metodologia V:

Jak widzimy całe sedno sprawy polega na tym, że do kaskady czynności projektantów dokłada się kaskadę czynności weryfikacyjnych. Mamy tu do czynienia ze sprzężeniem zwrotnym. Ramię zstępujące koresponduje z ramieniem wstępującym. Tak więc mówiąc prościej, jeśli zostaną wykryte jakieś nieprawidłowości po przez sprawdzenie po prawej stronie to wszystko jest zwracane na lewą stronę, gdzie zostaje naprawione i podlega raz jeszcze sprawdzeniu.
Jeśli chodzi o wady metodologii kaskadowej i metodologii V to można spróbowac ująć to w ten sposób:
"Dopóki wszystko nie będzie gotowe to tak naprawdę nic nie jest gotowe"
Czyli każda część składowa musi być gotowa i działać poprawnie, żeby oprogramowanie zostało zaakceptowane. Jeśli chodzi o wykrywanie błędów to na samym początku są zawsze wykrywane te najprostsze błędy, zaś najtrudniejsze dopiero na sam koniec (trzeba przeglądać dużą ilość kodu).

Swoistym zerwaniem z koncepcją kaskadową i literą V jest:

Model spiralny tworzenia pojektów W modelu spiralnym buduje się coraz lepsze modele systemu. Kolejne spirale są już gotowe do użytkowania. Proces projektowania odbywa się wraz procesem selekcjonowania koncepcji. Zaletą jest możliwość przyjrzenia się czemuś konkretnemu przez klienta podczas projektowania. Jednak tworzenie prototypów wymaga dodatkowych kosztów co podwyższa cenę projektu, jednak unikamy w ten sposób kosztów za popełnione błędy w systemie. Ewolucja metod projektowania:

1. Kaskadowe
2. Prototypowanie błyskawiczne
3. Trzy warstwy konstrukcji

Klasy wielokrotnego użytku pozwalają wyprodukować moduły przy bardzo ograniczonym nakładzie pracy. Są to prototypy fragmentów programu.