Ten arty­kuł jest adre­so­wa­ny do wszyst­kich. Biznes (praw­ni­cy tak­że) może prze­ko­nać się, że opro­gra­mo­wa­nie moż­na nary­so­wać i zro­zu­mieć. Analitycy i pro­gra­mi­ści, że to moż­li­we, a dewe­lo­pe­rzy, że nikt im nie odbie­ra pra­cy a raczej pomaga. 

Wprowadzenie

W dzi­siej­szym świe­cie inży­nie­rii naj­więk­szą war­tość mają czas i zaso­by. Czas to jak naj­szyb­sze odda­nie roz­wią­za­nia (pro­duk­tu) do użyt­ku (szyb­ka komer­cja­li­za­cja), zaso­by to koszt jakim się to odbę­dzie. Kluczem są kosz­ty: ​„time to mar­ket”, tu kosz­tem jest opóź­nie­nie komer­cja­li­za­cji (nie­zre­ali­zo­wa­ne przy­cho­dy), kosz­tem jest tak­że samo powsta­wa­nia opro­gra­mo­wa­nia. Praktycznie od począt­ku inży­nie­rii opro­gra­mo­wa­nia zależ­ność kosz­tów od dys­cy­pli­ny i eta­pu pra­cy się nie zmie­nia, wyglą­da to jak poniżej:

Od same­go począt­ku prac nad opro­gra­mo­wa­niem tak napraw­dę roz­wią­zu­je­my pro­ble­my: począw­szy od pro­ble­mów z odkry­ciem co tak napraw­dę jest roz­wią­za­niem pro­ble­mu (a pro­blem trze­ba naj­pierw ziden­ty­fi­ko­wać), przez pro­ble­my zwią­za­ne z wła­ści­wym zapro­jek­to­wa­niem roz­wią­za­nia (algo­ryt­my, archi­tek­tu­ra kodu), do pro­ble­mów wybo­ru tech­no­lo­gii i imple­men­ta­cji. Patrząc od koń­ca: pomył­ki są bar­dzo kosz­tow­ne dla orga­ni­za­cji (spon­sor pro­jek­tu). Development (kodo­wa­nie i testy) to pra­ca zespo­łów ludzi, są bar­dzo kosz­tow­ne. Najtańsza jest tu pra­ca (etap) ana­li­ty­ka-pro­jek­tan­ta, to jed­nak tak­że czas (pamię­ta­my ​„time to market”). 

Tak więc ​„water­fall” nie wcho­dzi w grę. Praktyka jed­nak poka­zu­je, że roz­po­czę­cie od razu od kodo­wa­nia nie roz­wią­zu­je żad­ne­go pro­ble­mu bo złe pomy­sły są i będą, kory­go­wa­ne dopie­ro na eta­pie kodo­wa­nia gene­ru­ją bar­dzo duże kosz­ty. Lekarstwem jest odej­ście o mono­li­tycz­nej archi­tek­tu­ry na rzecz samo­dziel­nych kom­po­nen­tów, czy wręcz mikro­ser­wi­sów (jed­nost­ki imple­men­ta­cji to poje­dyn­cze przy­pad­ki uży­cia UML, tu rozu­mia­ne jako nie­za­leż­ne mikro-apli­ka­cje ). Dlatego opty­mal­ne wyda­je sie podej­ście: 1. ana­li­za, 2. pro­jek­to­wa­nie HLD: kom­po­nen­ty, 3. ite­ra­cyj­ne pro­jek­to­wa­nie LLD kom­po­nen­tów i ich deve­lop­ment. Osiągamy waż­ną rzecz: naj­droż­sze zaso­by: deve­lop­ment, dosta­ją do imple­men­ta­cji prze­my­śla­ne roz­wią­za­nie, nie tra­ci­my cza­su i środ­ków na kolej­ne pro­to­ty­py w kodzie.