Na ten wpis pew­nie wie­lu z Was cze­ka, tak przy­naj­mniej suge­ru­ją listy do mnie i gło­sy na forach, a tak­że poten­cjal­ni klien­ci. Ci, któ­rych nie­ste­ty cza­sem kry­ty­ku­ję, tak­że pew­nie cze­ka­ją. Pokażę na pro­stym przy­kła­dzie, pro­ces od ana­li­zy przez wyma­ga­nia aż do pro­jek­tu dedy­ko­wa­ne­go opro­gra­mo­wa­nia. Całość będzie zgod­na z faza­mi CIM/PIM (www​.omg​.org/​mda). Projekt dzie­dzi­ny, któ­ry powsta­nie będzie speł­niał zasa­dy SOLID pro­jek­to­wa­nia obiek­to­we­go, pro­jek­to­wa­nia przez kom­po­zy­cje (zamiast dzie­dzi­cze­nia) (pole­cam arty­kuł Łukasza Barana) i DDD. Opis doty­czy każ­de­go pro­jek­tu zwią­za­ne­go z opro­gra­mo­wa­niem, tak­że goto­wym np. ERP, CRM, EOD itp.

Korzystałem z opi­su zasad gry w sza­chy zamiesz­czo­ne­go na WIKI:

Zasady gry w sza­chy ? pra­wi­dła regu­lu­ją­ce spo­sób roz­gry­wa­nia par­tii sza­chów. Choć pocho­dze­nie gry nie zosta­ło dokład­nie wyja­śnio­ne, to współ­cze­sne zasa­dy ukształ­to­wa­ły się w śre­dnio­wie­czu. Ewoluowały one do począt­ków XIX wie­ku, kie­dy to osią­gnę­ły wła­ści­wie swą bie­żą­cą postać. W zależ­no­ści od miej­sca zasa­dy gry róż­ni­ły się od sie­bie, współ­cze­śnie za prze­pi­sy gry odpo­wia­da Międzynarodowa Federacja Szachowa (Fédération Internationale des Échecs, FIDE). Przepisy te mogą się róż­nić w przy­pad­ku róż­nych warian­tów gry, np. dla sza­chów szyb­kich, bły­ska­wicz­nych czy kore­spon­den­cyj­nych. (Zasady gry w sza­chy ? Wikipedia, wol­na ency­klo­pe­dia).

To na co chcę zwró­cić tu uwa­gę w szcze­gól­no­ści, to metafora:

pro­jek­tu­jąc (mode­lu­jąc) opro­gra­mo­wa­nie dla czło­wie­ka, mode­lu­je­my narzę­dzie dla tego czło­wie­ka a nie jego samego.

Swego cza­su pisa­łem, w arty­ku­le o nazy­wa­niu klas, że opro­gra­mo­wa­nie z regu­ły zastę­pu­je dotych­cza­so­we narzę­dzie czło­wie­ka a nie czło­wie­ka jako takie­go. Druga waż­na rzecz: aktor jest rów­no­praw­nym ele­men­tem sys­te­mu (tu sys­te­mem jest orga­ni­za­cja z jej ludź­mi i uży­wa­ny­mi przez nich narzę­dzia­mi). No to zaczynamy.

Cel zamawiającego

Często pro­jekt zaczy­na się od pustej kart­ki, ale nie raz Zamawiający (spon­sor pro­jek­tu) ma już swo­je wyma­ga­nia, z regu­ły jest to jakaś lista w rodzaju:

Z regu­ły z listy wyma­gań (a potra­fi mieć set­ki pozy­cji) nie wyni­ka wprost cel spon­so­ra, a jedy­nie to jak sobie on wyobra­ża roz­wią­za­nie swo­je­go pro­ble­mu (wyobraź­cie sobie powyż­szą listę bez skraj­nej lewej i pra­wej kolum­ny). Wstępne upo­rząd­ko­wa­nie tej listy pozwa­la uznać, że wyma­ga­niem jest wytwo­rze­nie pro­gra­mu do gry w sza­chy na tablet i smart­fon. Pozostałe to pew­ne cechy tego ​„głów­ne­go” wyma­ga­nia biznesowego.

Od dłuż­sze­go cza­su prze­sta­łem na tym eta­pie uży­wać poję­cia wyma­gań funk­cjo­nal­nych i nie­funk­cjo­nal­nych. Na pra­wie każ­dym szko­le­niu i więk­szo­ści pro­jek­tów usły­szy­cie, że to kanon ana­li­zy wyma­gań, a ja – i nie tyl­ko jak poka­zu­je lite­ra­tu­ra- uwa­żam, że sko­ro spon­sor pro­jek­tu (tak zwa­ny biz­nes) z regu­ły nie rozu­mie tych pojęć, to nie nale­ży ich uży­wać w dia­lo­gu z biz­ne­sem na tym eta­pie pro­jek­tu, a tym bar­dziej żądać takie­go podzia­łu. No to kie­dy? Zobaczycie pod koniec :). Nie znam przy­pad­ku, by zama­wia­ją­cy ​„biz­nes” popraw­nie roz­róż­nił te dwie gru­py wyma­gań albo potra­fił same­mu spi­sać ​„przy­pad­ki uży­cia”. A jeże­li jesz­cze zażą­da­my podzia­łu na FURPS to będzie ​„masa­kra”. Czy ma to robić od razu ana­li­tyk? A po co sko­ro Zamawiający i tak tego nie zwe­ry­fi­ku­je a jest adre­sa­tem tego doku­men­tu? Na tym eta­pie, powyż­sza lista, moż­na poprze­stać na uzna­niu powyż­szej listy za ​„wyma­ga­nia biz­ne­so­we” (czy­li te, któ­re wprost for­mu­łu­je ​„biz­nes”).

Na zakoń­cze­nie

Analiza i pro­jek­to­wa­nie obiek­to­we (ang. OOAD) to nie­ja­ko ​„imple­men­ta­cja” kla­sycz­nej ana­li­zy sys­te­mo­wej. Nie ma ona nic wspól­ne­go ze struk­tu­ral­ny­mi meto­da­mi ana­li­zy i pro­jek­to­wa­nia opro­gra­mo­wa­nia (cze­go wie­lu zda­je się nadal nie dostrze­gać). Wygląda na to, że jest znacz­nie trud­niej­sza ale prak­ty­ka poka­zu­je, że daje znacz­nie lep­sze rezul­ta­ty. Języki obiek­to­we to nie jakieś tam nowa nazwa kla­sy na pod­pro­gra­my, a zupeł­nie nowy para­dyg­mat pro­gra­mo­wa­nia: musi być poprze­dza­ny ana­li­zą i pro­jek­tem. Jego zale­tą jest to, że pozwa­la na odwzo­ro­wy­wa­nie, nie­mal­że jak w grze, ana­li­zo­wa­ne­go i roz­wią­zy­wa­ne­go pro­ble­mu, pozwa­la na prze­te­sto­wa­nie pomy­słu na pro­gram zanim powsta­nie choć jed­na linia pro­gra­mu. Problemem i wyzwa­niem na eta­pie ana­li­zy jest zro­zu­mie­nie pro­ble­mu, co mam nadzie­ję pokazałem.

Niestety wie­le ana­liz doku­men­to­wa­nych z uży­ciem nota­cji UML nie ma wie­le wspól­ne­go z OOAD, sta­no­wią echa struk­tu­ral­nych metod ana­li­zy i pro­jek­to­wa­nia, sto­so­wa­nia baz rela­cyj­nych już na eta­pie ana­li­zy (obiek­to­we narzę­dzia nie czy­nią pro­jek­tów obiek­to­wy­mi). Niestety błę­dy te popeł­nia­ją nawet wykła­dow­cy wie­lu uczel­ni i kursów.

Bardziej roz­bu­do­wa­ny pro­jekt, wraz z fil­mem o jego powsta­wa­niu tu: Inżynieria opro­gra­mo­wa­nia z uży­ciem narzę­dzia CASE ? przy­kła­do­wy projekt

Koszty

Są zależ­nie od skła­du zespo­łu deve­lo­pe­ra i meto­dy pra­cy. Ale zespół pro­gra­mi­sta i tester, powyż­sze, robio­ne meto­dą ​„agi­le”: czy­li user sto­ry i od razu burza mózgów, ​„wsa­dze­nie” do fra­me­wor­ka, kodo­wa­nie, testy, pro­to­typ, testy u zama­wia­ją­ce­go i kil­ka takich ite­ra­cji ver­sus powyż­sze (to pra­ca ana­li­ty­ka tu moja, na jeden dzień). Porównanie kosz­tu musi każ­dy zro­bić sam, ale z moje­go doświad­cze­nia wyni­ka, że doj­ście do tego eta­pu (prze­my­śla­na i spraw­dzo­na logi­ka sys­te­mu) meto­da­mi burz mózgów i pro­to­ty­po­wa­nia – kolej­ne wer­sje kodu dla Klienta – to kil­ku­krot­nie więk­szy koszt i czas w porów­na­niu z opra­co­wa­niem powyż­szej ana­li­zy i pro­jek­tu i wyko­na­nia popraw­ne­go opro­gra­mo­wa­nia za nie­mal­że pierw­szym podej­ściem na bazie prze­my­śla­ne­go pro­jek­tu (pisze na bazie wyko­na­nych pro­jek­tów, ale pro­por­cje mogą być inne z innym zespo­łem). Na koniec sta­ty­sty­ka pew­ne­go deve­lo­pe­ra (pole­cam cały wątek):

I star­ted a com­pa­ny cal­led Nascent Blue that spe­cia­li­zes in MDD for appli­ca­tion deve­lop­ment. We have actu­al­ly had the oppor­tu­ni­ty to com­pa­re MDD to tra­di­tio­nal deve­lop­ment side-by-side on lar­ge pro­jects. Our client set up ​„the expe­ri­ment” to col­lect the PM data for ana­ly­sis. It was a lar­ge pro­ject with 5 teams. The results:

1. Our team was less than half the size of the other teams.

2. Our team pro­du­ced more than twi­ce the code of the other teams.

3. Our team achie­ved a 75% reduc­tion in cost.

4. Our team achie­ved a 66% reduc­tion in defect rate.

5. Our team was twi­ce as fast (with half the size).

We have sin­ce got­ten more effi­cient and more advan­ced, so I don’t know what the num­bers are now.

We deve­lop our own mode­ling tools (UML, ERD, and DSLs for UI and other things). We also have tools for ADM, so we can achie­ve simi­lar pro­duc­ti­vi­ty gains for re-plat­for­ming and re-archi­tec­tu­re projects.

(źr. Model dri­ven pro­duc­ti­vi­ty | LinkedIn).

Literatura

Wyjątkowo podam zale­ca­ną lite­ra­tu­rę z nadzie­ją, że choć cześć tego uda się Wam ana­li­ty­kom, prze­czy­tać. Sponsorom pro­jek­tów pole­cam roz­waż­ny dobór ana­li­ty­ków i projektantów :).

Kolejność trosz­kę przy­pad­ko­wa (czy­li z mojej pół­ki i tyl­ko część ;)):

1. Tytuł: Metody obiek­to­we w teo­rii i prak­ty­ce, Autor: Ian Graham, Wydanie: WTN, Warszawa 2004

2. Tytuł: Inżynieria Projektowania Strategii Przedsiębiorstwa, Autor: Lechosław Berliński, Ilona Penc-Pietrzak, Wydanie: Difin, Warszawa 2004

3. Tytuł: Inżynieria sys­te­mów infor­ma­cyj­nych, Autor: Paul Beynon-Davis, Wydanie: Warszawa, WNT 2004

4. Tytuł: UML. Inżynieria opro­gra­mo­wa­nia. Wydanie II, Autor: Perdita Stevens, Wydanie: Helion 2007

5. Tytuł: Strategie Konkurencji, Autor: David Faulkner, Cliff Bowman, Wydanie: Gebethner i ska, Warszawa 1996

6. Tytuł: Cybernetyka w zarzą­dza­niu. Modelowanie cyber­ne­tycz­ne. Sterowanie sys­te­ma­mi, Autor: Zdzisław Gomółka, Wydanie: Warszawa, Placet 2000

7. Tytuł: Modele refe­ren­cyj­ne w zarzą­dza­niu pro­ce­sa­mi biz­ne­su, Autor: Tadeusz Kasprzak, Wydanie: Difin, Warszawa 2005

8. Tytuł: Teoria i Inżynieria Systemów, Autor: Czesław Cempel, Wydanie: Czesław CEMPEL, Poznań 2008

9. Tytuł: Business Inteligence, Autor: Jerzy Surma, Wydanie: PWN, Warszawa 2009

10. Tytuł: Architektura sys­te­mów zarzą­dza­nia przed­się­bior­stwem. Wzorce pro­jek­to­we, Autor: Martin Fowler, Wydanie: Helion Gliwice

11. Tytuł: Head First Object-Oriented Analysis and Design, Autor: Brett D. McLaughlin, Gary Pollice, David West, Wydanie: Helion, Gliwice 2008

12. Tytuł: Projektowanie hur­tow­ni danych. Zarządzanie kon­tak­ta­mi z klien­ta­mi (CRM), Autor: Todman Chris, Wydanie: WNT, Warszawa 2003

13. Tytuł: Komponenty w UML, Autor: John Cheesman, John Daniels, Wydanie: WNT, Warszawa 2000

14. Tytuł: UML prze­wod­nik użyt­kow­ni­ka, Autor: Grady Booch, James Rumbaugh, Ivar Jacobson, Wydanie: WNT, Warszawa 2002

15. Tytuł: Inżynieria opro­gra­mo­wa­nia, Autor: Ian Sommerville, Wydanie: WNT, Warszawa

16. Tytuł: Projektowanie zorien­to­wa­ne obiek­to­wo. Wzorce pro­jek­to­we, Autor: Alan Shalloway, James R. Trott, Wydanie: Gliwice, Helion 2005

17. Tytuł: Wdrażanie stra­te­gii dla prze­wa­gi kon­ku­ren­cyj­nej, Autor: Robert S. Kaplan, David P. Norton, Wydanie: PWN, Warszawa 2010

18. Tytuł: Wzorce pro­jek­to­we, Autor: E.Gamma, R.Helm, R.Jonson, J.Vlissides, Wydanie: Helion, Gliwice 2010

19. Tytuł: UML w kro­pel­ce wer­sja 2.0, Autor: Fowler Martin, Wydanie: LTP

20. Tytuł: Analysis Patterns. Reusable Object Models, Autor: Martin Fowler, Wydanie: Addison-Wesley, 1997

21. Tytuł: Podstawy metod obiek­to­wych, Autor: James Martin, James J.Odell, Wydanie: WNT, Warszawa 1997

22. Tytuł: Tworzenie archi­tek­tu­ry opro­gra­mo­wa­nia, Autor: Christine Hofmeister, Robert Nord, Dilip Soni, Wydanie: WNT, Warszawa 2006

23. Tytuł: Business Process Management, Autor: John Jeston, Johan Nelis, Wydanie: Butterworth-Heinemann, 2008 (Reprint 2009)

24. Tytuł: Requirements Analysis and System Design, Autor: Leszek A. Maciaszek, Wydanie: Addison Wesley 2001

25. Tytuł: Object-Oriented Construction Handbook, Autor: Heinz Zullighoven, Wydanie: Elsevier Inc. 2005

26. Tytuł: Stosowanie przy­pad­ków uży­cia, Autor: Geri Schneider, Jason P. Winters, Wydanie: WNT, Warszawa 2004

27. Tytuł: Porter o kon­ku­ren­cji, Autor: Michael E. Porter, Wydanie: PWE, Warszawa 2001

28. Tytuł: Strategie Konkurencji, Autor: Michael E. Porter, Wydanie: MT Biznes, Warszawa 2006

29. Tytuł: Michael E. Porter, Autor: Przewaga kon­ku­ren­cyj­na, Wydanie: Helion, Gliwice 2006

30. Tytuł: Systems Analysis and Design with UML Version 2.0, Autor: Alan Dennis, Barbara Halley Wixom, David Tegarden, Wydanie: Second edi­tion, John Wiley and Sons, Inc. 2005, USA

31. Tytuł: UML i wzor­ce pro­jek­to­we. Analiza i pro­jek­to­wa­nie obiek­to­we oraz ite­ra­cyj­ny model wytwa­rza­nia apli­ka­cji, Autor: Craig Larman, Wydanie: Helion, Gliwice 2011

32. Tytuł: Object-Oriented Construction Handbook: Developing Application-Oriented Software with the Tools & Materials Approach, Autor: Heinz Züllighoven, Wydanie: Morgan Kaufmann; 1 edi­tion, October 13, 2004

33. Tytuł: Domain-Driven Design: Tackling Complexity in the Heart of Software, Autor: Eric Evans, Wydanie: Addison-Wesley

(zain­te­re­so­wa­nych pozna­niem opi­sa­nych metod ana­li­zy i pro­jek­to­wa­nia zapra­szam na moje szko­le­nia)

A na zakoń­cze­nie cytat:

Moja rada dla osób zaczy­na­ją­cych pra­cę w IT… zanim usią­dziesz do kom­pu­te­ra i zaczniesz pro­gra­mo­wać czy kon­fi­gu­ro­wać weź kart­kę, pomyśl, napisz i nary­suj co chcesz zro­bić, pomyśl jesz­cze raz, popraw, pokaż innym, spy­taj ich o opi­nie, po raz kolej­ny pomyśl, jesz­cze raz popraw i dopie­ro wte­dy sia­daj do kom­pu­te­ra. (Zanim zaczniesz pro­gra­mo­wać weź kart­kę, pomyśl, napisz i nary­suj co chcesz zro­bić – Computerworld).

W sie­ci moż­na zna­leźć wie­le takich i podob­nych przy­kła­dów, tu jeden z nich któ­ry pole­cam. Powyżej opi­sy­wa­łem pro­ces ana­li­zy biz­ne­so­wej i pro­jek­to­wa­nie z uży­ciem trzech nota­cji (narzę­dzi), bo każ­de z nich powsta­ło dla dane­go obsza­ru poję­cio­we­go (osob­no BMM, BPMN i UML). Poniżej przy­kład ana­li­zy (a raczej spe­cy­fi­ka­cji, autor­ka opi­sa­ła treść doku­men­tu a nie jak powsta­wał) jed­nak co do zasa­dy jest to ​„kla­sycz­ny” pro­ces od opi­su biz­ne­su do spe­cy­fi­ka­cji apli­ka­cji, dodam – bo tu to waż­ne – autor­ka korzy­sta­ła wyłącz­nie z moż­li­wo­ści MS Office/Visio (Visio, poza pew­ny­mi nie­for­mal­ny­mi biblio­te­ka­mi sym­bo­li do two­rze­nia sche­ma­tów blo­ko­wych, nie zawie­ra innych nota­cji niż UML):

Complete Business-Systems Analysis Model (UML Example) […] NOTE: The fol­lo­wing exam­ple is the result of an ana­ly­sis effort that was con­struc­ted with MS Visio and Word. (Complete Business-Systems Analysis Model (UML Example).