Czas a modelowania w języku UML

image Czasami dostaję pytanie: Ile kosztuje modelowanie w UML? Moja odpowiedź brzmi: Dużo, ale koszty się zwracają z zyskiem. Skąd ten zysk skoro modelowanie w UML to czas ludzi, którzy zamiast pisać kod siedzą i modelują a od tego kodu nie przybywa. Moi rozmówcy mają obawy, że to korzystanie z UML wydłuża proces budowy oprogramowania. Pozornie tak i pewnie, można zacząć od razu budować kod (wiele firm działa tak z powodzeniem do dziś), tylko dlaczego jak budujemy dom to najpierw go planujemy? Przecież można włączyć betoniarkę, kupić cegły i do dzieła. Ale my najpierw planujemy dom, może po to by się nie zawalił, może po to by spełniał nasze oczekiwania. Potem jak zatwierdzimy plany to w trakcie budowy są oczywiście pewne zmiany (przestawiamy ścianki, zmieniamy wysokość okna itd. itp.), ale nikt nie burzy wszystkiego i nie zaczyna od nowa. W pisaniu kodu często bywa tak, że albo oddajemy źle napisany komponent (o ile w miarę działa), albo piszemy od nowa (by w miarę działał). Oszczędność o której pisałem na początku to czas jaki tracimy na poprawianie (lub pisanie od nowa) źle funkcjonujących komponentów.  Dziwne jest czasem dla mnie to, że przy budowie domu zatrudnia się obligatoryjnie architekta który go planuje (lub kupuje gotowy projet), a przy budowie oprogramowania, które jest dużo bardziej skomplikowane oszczędza się na projekcie.  Na szczęście moi klienci już dojrzeli korzyści z modelowania i dzięki temu mam co robić bo modelowanie w UML nie musi być ani czasochłonne, ani trudne i kosztowne. 

Technorati Tagi: UML,Unified Modeling Language,proces wytwórczy oprogramowania

Podobne wpisy

  • BPMN vs diagramy aktywności Kilka dni temu po raz kolejny uczestniczyłem w dyskusji na temat przewagi BPMN nad diagramami aktywności i odwrotnie w kontekście modelowania procesów biznesowych i systemowych (patrz […]
  • Kolejne wskazówki dotyczące modelowania w ujęciu Agile Kilkanaście dni temu  opublikowałem 5 wskazówek dla analizy w ujęciu AGILE Scotta Amblera. Chciałbym je teraz uzupełnić o kolejne spostrzeżenia. Tym razem dotyczące przede wszystkim […]
  • 5 wskazówek dla analizy w ujęciu AGILE Scrott Ambler kilkanaście miesięcy temu opublikował 5 wskazówek, które powinny usprawnić analizę w ujęciu AGILE Oto one: 1. Aktywny udział osób zainteresowanych jest najbardziej istotny […]
  • Specyfikacja komponentów i interfejsów w Enterprise Architect W trakcie projektowania systemów na poziomie komponentów istotnym jest aby dobrze wyspecyfikować kanały komunikacji pomiędzy komponentami. Poniżej w tekście tym, postaram się przedstawić […]
  • Nowości w UML 2.2 Kilka tygodni temu pisałem o specyfikacji UML w wersji 2.2. Obiecałem wtedy, że jak ją przejrzę to napiszę o zmianach. Niniejszym informuję, że specyfikacja została przeze mnie […]
Reklama
MODESTO - licencje Enterprise Architect

Zostaw komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Przewiń do góry