Wprowadzenie Wiele się mówi o Agile i o ograniczaniu roku dokumentacji i UML w inżynierii oprogramowania. Mam na półce wiele książek o projektowaniu i o UML, wiele z nich to książki napisane przez sygnatariuszy Agile Manifesto. Postanowiłem przygotować krótkie zestawienie. Poniżej zestawienie zawierające obszary i przypadki wykorzystania UML w książkach napisanych przez sygnatariuszy Agile Manifesto. Uwzględnia pełne spektrum: autorów, tytuły, typy diagramów UML oraz obszary modelowania. 1. Martin Fowler Książki zawierające UML UML Distilled Analysis Patterns Patterns of Enterprise Application Architecture Refactoring Domain-Specific Languages Typ UML Diagramy klas Diagramy sekwencji…
Dostałem maila :): Innovation isn?t easy, but it?s less painful when the tools you need to build complex products are familiar and accessible. In that light, small startups have it pretty good. But for large, dispersed and mature organizations, putting Agile processes into practice can feel like an unscalable ideal. The Agile Manifesto debuted in 2001. Your company, and the ways you help it move forward have evolved. Work methods should keep up with you, not the other way around. Here?s how to merge the Manifesto?s aims with the ways…
Kolejnym problemem jest niestety jakość projektowania:Według firmy analitycznej Gartner około 60 proc. wdrożeń wielkich systemów informatycznych kończy się klęską. Przyczyną jest m.in. nieumiejętność przełożenia procesów działających w firmie na działanie systemu informatycznego, brak dostatecznego wsparcia ze strony pracowników i kierownictwa firmy (czasem nawet jawny opór), złe przygotowanie wdrożenia lub jego prowadzenie. (za Serwis Nauka w Polsce - PAP SA).Jak widać, jakość projektowania jest kluczem, zresztą nie tylko w przypadków dużych systemów ale w każdym przypadku. Różnica jest taka, że jeżeli niejedna firma świadomie ryzykuje kilkaset tysięcy rezygnując z etapu niezależnej analizy i projektowania wartej ok. 10-20% tej kwoty, to podobne podejście projekty warte milionów jest już raczej nieracjonalne...
Dlaczego tak często projekty łamią zasady rozsądku i zarządzania ryzykiem?Wczoraj na sali i w kuluarach padły między innymi takie odpowiedzi:dostawcy oprogramowania bardzo często nie potrafią takiej analizy wykonać bo nie mają wymaganych kompetencji, ale potrafią programować i tylko na to się godzą.
dostawcy oprogramowania doskonale wiedzą, że istnieje ryzyko że ich produkt nie spełnia wymagań więc bardzo często nie dopuszczają do takich analiz forsując od razu wdrożenie (wręcz tępią w projektach zewnętrznych analityków!).
klienci mają stale do czynienia z dostawcami a bardzo rzadko z niezależnymi analitykami i bardzo często przyjmują wiarę w to co mówią dostawcy.
