
To co najczęściej wzbudza brak zaufania to teza, że można przeprowadzić analizę i projektowanie oprogramowania "na papierze". Programiści w większości uważają, że to nie możliwe (rok temu na stronach tego bloga burzliwa dyskusja z jednym z nich...). W większości przypadków podczas spotkań (konferencje, projekty itp.) z zespołami programistów słyszę: "czytamy wymagania, kodujemy od razu i tworzymy kolejne wersje aplikacji; inaczej się nie da". W przypadku szkoleń, ostatniego dnia warsztatów najczęściej słyszę: "ooo, w ciągu jednego dnia powstał kompletny projekt dziedziny systemu , przetestowany i oczyszczony z wątpliwości, braku logiki i niespójności, do tego łatwy w dalszym rozbudowywaniu; to co zrobiliśmy teraz na diagramach UML w ciągu dnia, jako zespół tradycyjną metodą robilibyśmy co najmniej tydzień, biorąc pod uwagę kodowanie każdego pomysłu by go dać użytkownikowi do testów". W zasadzie taki proces analizy i projektowania jest znany od lat jako ] (MDA). Larman w swojej książce opisuje niemalże identyczne podejście (tabela poniżej). Kluczową różnicą jest jednak źródło informacji pierwotnej. U Larman'a jest to model przypadków użycia i ich scenariusze. W porównaniu...








