Wymiarowanie oprogramowania

Bardzo czę­sto spo­ty­kam się z meto­da­mi wymia­ro­wa­nia opro­gra­mo­wa­nia, czy­li mówiąc ludz­kim języ­kiem: oce­ny pra­co­chłon­no­ści jego wytwo­rze­nia. Typowym argu­men­tem za sto­so­wa­niem tych metod jest potrze­ba pla­no­wa­nia. Nie raz spo­ty­kam się z porów­na­nia­mi do pomia­ru powierzch­ni np. w budow­nic­twie (cytat celo­wo ze stro­ny sto­sow­ne­go stowarzyszenia):

Wymiarowanie opro­gra­mo­wa­nia, ma podob­ne zna­cze­nie, co wymia­ro­wa­nie w innych dzie­dzi­nach inży­nie­rii. Określa wiel­kość, pozwa­la na porów­ny­wa­nie róż­nych przed­się­wzięć, sza­co­wa­nie kosz­tów wytwa­rza­nia i lep­sze pla­no­wa­nie. Punkty funk­cyj­ne ? naj­bar­dziej popu­lar­na i pro­mo­wa­na przez spe­cja­li­stów jed­nost­ka wiel­ko­ści opro­gra­mo­wa­nia, to przy­kła­do­wo odpo­wied­nik metrów kwa­dra­to­wych w budow­nic­twie. Wyobraźmy sobie tę bran­żę, przy zało­że­niu, że nie posłu­gu­je­my się żad­ną jed­nost­ką powierzch­ni. Inwestycje były­by wyce­nia­ne, a ich reali­za­cja pla­no­wa­na nawet bez pró­by osza­co­wa­nia np. powierzch­ni użyt­ko­wej? Wydaje się to absur­dem, a jed­nak w takiej rze­czy­wi­sto­ści funk­cjo­nu­je rynek opro­gra­mo­wa­nia i nie­ste­ty ‑zwią­za­ny z nim świat zamó­wień publicznych.Nie jest to tyl­ko pro­blem pol­ski, jest to bolącz­ka całej bran­ży. Nic dziw­ne­go, że aż 63% pro­jek­tów koń­czy się poraż­ką, a pla­no­wa­ny czas prze­kra­cza­ny śred­nio o 80%, zaś kosz­ty śred­nio o 55%. Na świe­cie stra­ty będą­ce skut­kiem tych nie­po­wo­dzeń liczo­ne są w set­kach miliar­dów dola­rów rocz­nie. Walkę z tym pro­ble­mem pod­ję­to już wie­le lat temu. Zamawiane opro­gra­mo­wa­nie, wszę­dzie tam gdzie decy­den­ci są świa­do­mi zagro­żeń, jest mie­rzo­ne. A coraz wię­cej admi­ni­stra­cji pań­stwo­wych jako nor­mę, trak­tu­ją obo­wią­zek wymia­ro­wa­nia opro­gra­mo­wa­nia przed jego zamó­wie­niem. Dobre prak­ty­ki i narzę­dzia będą­ce wyni­kiem tej bata­lii są na wycią­gnię­cie ręki. 

(pier­wot­ne źró­dło jest nie­do­stęp­ne, porów­naj inny mate­riał: https://​www​.com​pu​ter​world​.pl/​n​e​w​s​/​S​k​u​t​e​c​z​n​e​-​m​e​t​o​d​y​-​w​y​m​i​a​r​o​w​a​n​i​a​-​p​r​o​j​e​k​t​o​w​-​I​T​,​4​0​8​5​9​3​.​h​tml)

Ogólnie teza jakiej bro­nią zwo­len­ni­cy tego typu metod brzmi:

moż­li­we jest osza­co­wa­nie pra­co­chłon­no­ści (kosz­tu) wytwo­rze­nia opro­gra­mo­wa­nia wyłącz­nie na bazie wie­dzy o tym, do cze­go ma ono służyć

Innymi sło­wy uwa­ża­my, że na bazie wyma­gań funk­cjo­nal­nych (z regu­ły mowa o przy­pad­kach uży­cia) moż­na osza­co­wać zło­żo­ność apli­ka­cji. Niestety w swo­jej wie­lo­let­niej karie­rze nigdy nie spo­tka­łem się z przy­pad­kiem by wyce­na taka choć zbli­ży­ła się do póź­niej­szych fak­tycz­nych kosz­tów wytwo­rze­nia apli­ka­cji (rzad­kie przy­pad­ko­we zbież­no­ści nie są dowo­dem sku­tecz­no­ści meto­dy). Raczej spo­ty­kam się dość czę­sto z czymś co opi­sa­łem w 2013 roku (tych wycen, zgod­nie z SIWZ, doko­na­no na bazie meto­dy punk­tów funkcyjnych):

Co mnie zasta­na­wia? Przede wszyst­kim to, że ?pro­fe­sjo­nal­ne? fir­my z ogrom­nym (jak twier­dzą na swo­ich stro­nach) doświad­cze­niem, pre­zen­tu­ją ofer­ty opra­co­wa­ne na bazie tej samej doku­men­ta­cji (w koń­cu to prze­targ), a roz­rzut cen tych ofert jest czte­ro­krot­ny!!! ?(Żeliński, 2013)?

Takich przy­pad­ków jest wie­le, i moim zda­niem prak­tycz­nie oba­la­ją tezę o sku­tecz­no­ści tego typu metod (meto­da punk­tów funk­cyj­nych i pokrewne).

Jedną z popu­lar­niej­szych i czę­sto pro­mo­wa­nych metod jest ana­li­za punk­tów funk­cyj­nych pro­mo­wa­na przez International Function Point Users Group (IFPUG). W tej rodzi­ny nale­ży mię­dzy inny­mi COSMIC. Metoda ta bazu­je na dość pro­stych założeniach:

The prin­ci­ples for measu­ring the COSMIC func­tio­nal size of a pie­ce of softwareThe COSMIC method measu­res a size as seen by the ?func­tio­nal users? of the pie­ce of softwa­re to be measu­red, i.e. the sen­ders and/or inten­ded reci­pients of the data that must enter or exit from the softwa­re, respectively.The method uses a model of softwa­re, known as the ?COSMIC Generic Software Model?, which is based on fun­da­men­tal softwa­re engi­ne­ering prin­ci­ples, namely:Functional user requ­ire­ments of a pie­ce of softwa­re can be ana­ly­zed into uni­que func­tio­nal pro­ces­ses, which con­sist of sub-pro­ces­ses. A sub-pro­cess may be either a data move­ment or a data manipulation;Each func­tio­nal pro­cess is trig­ge­red by an ?Entry? data move­ment from a func­tio­nal user which informs the func­tio­nal pro­cess that the func­tio­nal user has iden­ti­fied an event that the softwa­re must respond to;A data move­ment moves a sin­gle data gro­up of attri­bu­tes descri­bing a sin­gle ?object of inte­rest?, whe­re the lat­ter is a ?thing? of inte­rest to a func­tio­nal user;There are four types of data move­ment sub-pro­ces­ses. An ?Entry? moves a data gro­up into the softwa­re from a func­tio­nal user and an ?Exit? moves a data gro­up out. ?Writes? and ?Reads? move a data gro­up to and from per­si­stent sto­ra­ge, respectively.[…]

As an appro­xi­ma­tion for measu­re­ment pur­po­ses (and in light of the appli­ca­bi­li­ty of the method, descri­bed abo­ve), data mani­pu­la­tion sub-pro­ces­ses are not sepa­ra­te­ly measured.

The size of a pie­ce of softwa­re is then defi­ned as the total num­ber of data move­ments (Entries, Exits, Reads and Writes) sum­med over all func­tio­nal pro­ces­ses of the pie­ce of softwa­re. Each data move­ment is coun­ted as one ?COSMIC Function Point? (?CFP?). The size of a func­tio­nal pro­cess, and hen­ce the size of a pie­ce of softwa­re, can be a mini­mum of 2 CFP, with no upper limit. (The COSMIC Software Sizing Methodology. (n.d.). Retrieved May 9, 2019, from COSMIC websi­te: http://​cosmic​-sizing​.org/​c​o​s​m​i​c​-​f​sm/)

(zobacz tak­że opis wdro­żo­nej wer­sji udo­stęp­nio­ny przez ZUS).

Model opi­su­ją­cy fun­da­men­tal­ne zało­że­nia tej meto­dy wyglą­da tak:

źr. http://file.scirp.org/Html/3-9301348_17476.htm
?(?Design of a Performance Measurement Framework for Cloud Computing,? n.d.)?

Generalnie na eta­pie ana­li­zy, bazu­ją­cej na spe­cy­fi­ka­cji wyma­gań funk­cjo­nal­nych, two­rzo­na jest lista inte­rak­cji z apli­ka­cją Entry/Exit (czy­li tego to co widzi i jest w sta­nie opi­sać przy­szły użyt­kow­nik – lewa stro­na powyż­sze­go mode­lu) i lista ope­ra­cji Write/Read (zapis i odczyt danych, pra­wa stro­na mode­lu). Komponent, któ­ry nazwa­no tu Software, to pewien rodzaj czar­nej skrzyn­ki. Metoda ta po pierw­sze wyma­ga spro­wa­dze­nia wyma­gań do pozio­mu kurio­zal­nie roz­drob­nio­nych przy­pad­ków uży­cia (co opi­sa­łem nie­daw­no w arty­ku­le o pew­nej meto­dzie trans­for­ma­cji pro­ce­su biz­ne­so­we­go na przy­pad­ki uży­cia), po dru­gie zupeł­nie abs­tra­hu­je od wewnętrz­nej zło­żo­no­ści (w naj­now­szej wer­sji tej meto­dy przyj­mu­je się wagi zło­żo­no­ści, nie­ste­ty są one uzna­nio­we). Metoda powsta­ła ponad 30 lat temu, w cza­sach gdy inży­nie­ria opro­gra­mo­wa­nia spro­wa­dza­ła się do maksymy:

dane + funk­cje = oprogramowanie

To jest nie­ste­ty jed­nak pre­hi­sto­ria inży­nie­rii opro­gra­mo­wa­nia. Owszem powsta­je jesz­cze opro­gra­mo­wa­nie w myśl tej mak­sy­my (głów­nie sys­te­mu zarzą­dza­nia wie­dzą), ale nawet śred­nio zło­żo­ne biz­ne­so­we apli­ka­cje, two­rzo­ne jako otwar­te archi­tek­tu­ry obiek­to­we, nie­ste­ty nie pasu­ją do tego wzor­ca”. porów­naj­my powyż­szy model z tym:

Obiektowy model dziedziny Zasada SOLID
Obiektowy model archi­tek­tu­ry apli­ka­cji na bazie wzor­ca BCE, Zasada SOLID (opr. Jarosław Żeliński)

Powyżej dość typo­wa obiek­to­wa archi­tek­tu­ra apli­ka­cji. Kilka wniosków:

  • przy­pa­dek uży­cia nie jest nisko­po­zio­mo­wą funk­cją sys­te­mu”, takie ich defi­nio­wa­nie (nie­zgod­ne z UML) pro­wa­dzi do mon­stru­al­nej zło­żo­no­ści i pra­co­chłon­no­ści już na eta­pie ana­li­zy wymagań,
  • ope­ra­cje zapi­su i odczy­tu danych (repo­zy­to­ria, obiek­ty skraj­nie po pra­wej) w żaden spo­sób nie odzwier­cie­dla­ją zło­żo­no­ści apli­ka­cji, ta tkwi” w kom­po­nen­tach wewnętrz­nych a te nie są zna­ne na tym etapie,
  • wie­le zło­żo­nych ele­men­tów kodu – samo­dziel­ne usłu­gi wewnętrz­ne – nie ma bez­po­śred­nio nic wspól­ne­go ani z zapi­sem danych ani z inte­rak­cja z samą aplikacją,
  • uzna­nie, że moż­na osza­co­wać zło­żo­ność wytwo­rze­nia sys­te­mu tyl­ko na bazie pla­no­wa­nych funk­cjo­nal­no­ści i mode­lu danych moim zda­niem jest nie obrony.

Powyższy model poka­zu­je, że klu­czo­wa zło­żo­ność apli­ka­cji tkwi w czę­ści nazwa­nej w COSMIC softwa­re”, cał­ko­wi­cie pomię­tej w toku pro­wa­dze­nia szacowania.

Model COSMIC (i podob­ne meto­dy) cał­ko­wi­cie abs­tra­hu­je od tego, że apli­ka­cja mogła by powstać na bazie obiek­to­we­go para­dyg­ma­tu i wzor­ców SOLID (w szcze­gól­no­ści otwar­tość na roz­sze­rze­nia przy bra­ku wpro­wa­dza­nia zmian czy­li tak zwa­ne open clo­se prin­ci­ple). Uznanie, że każ­de opro­gra­mo­wa­nie moż­na spro­wa­dzić do pozio­mu ope­ra­cji zapi­su i odczy­tu z logi­ką takich ope­ra­cji umiesz­czo­ną w odwo­ła­niach do bazy danych, cofa nas o 40 lat, do cza­sów metod struk­tu­ral­nych (w tych cza­sach powsta­ła ta meto­da COSMIC). Stowarzyszenie pro­mu­ją­ce meto­dę COSMIC pisze: „… 63% pro­jek­tów koń­czy się poraż­ką, a pla­no­wa­ny czas prze­kra­cza­ny śred­nio o 80%, zaś kosz­ty śred­nio o 55%. Na świe­cie stra­ty będą­ce skut­kiem tych nie­po­wo­dzeń liczo­ne są w set­kach miliar­dów dola­rów rocz­nie …”, doda­je, że od 40 lat te sta­ty­sty­ki się nie zmie­nia­ją a meto­da ta ma porów­ny­wal­ny czas ist­nie­nia, wiec jak na tym tle oce­nić jej sta­ły roz­wój i domnie­ma­ną skuteczność?

Wielokrotnie widzia­łem, jak budżet i har­mo­no­gram pro­jek­tu wyli­czo­ny na bazie meto­dy punk­tów funk­cyj­nych, był nisz­czo­ny” jed­nym tyl­ko fak­tem roz­po­czę­cia doku­men­to­wa­nia i imple­men­ta­cji raba­to­wa­nia w przy­pad­ku uży­cia” Wystawianie Faktur Sprzedaży. Klasyka nie­ja­ko oba­la­ją­ca sku­tecz­ność tej meto­dy to sys­tem sco­rin­go­wy, któ­re­go prak­tycz­nie cała zło­żo­ność leży poza ope­ra­cja­mi wejścia/wyjścia, a tego rodza­ju pro­ble­mów w tak zwa­nych sys­te­mach biz­ne­so­wych jest bar­dzo wie­le, zary­zy­ku­je nawet tezę, że to typo­we pro­ble­my w obec­nych sys­te­mach wspo­ma­ga­nia zarzą­dza­nia. Metody tego typu, nie raz opar­ta na zbie­ra­nym doświad­cze­niu, są nadal popu­arc­ne .

Jak więc wymia­ro­wać opro­gra­mo­wa­nie? Tu zno­wu pozo­sta­je uczyć się od naj­star­szej dzie­dzi­ny inży­nie­rii czy­li budow­nic­twa: budow­le moż­na wyce­nić tyl­ko na pod­sta­wie pro­jek­tu całej kon­struk­cji (dla apli­ka­cji jest to jej wewnętrz­na archi­tek­tu­ra i logi­ka dzia­ła­nia), na bazie same­go pomy­słu na wiel­ki dom nie da się wyli­czyć ile będzie kosz­to­wa­ło jego posta­wie­nie. Od wie­lu lat mam do czy­nie­nia z ofer­ta­mi skła­da­ny­mi w odpo­wie­dzi na ten sam doku­ment opi­su­ją­cy wyma­ga­nia, roz­rzut wycen (bywa, że o rząd wiel­ko­ści) oba­la każ­dą teo­rię mówią­ca, że jest moż­li­we sen­sow­ne sza­co­wa­nie na tym (przed-pro­jek­to­wym) eta­pie, a wiem, że wie­le z tych wycen jest przy­go­to­wy­wa­nych wła­śnie na bazie metod opar­tych na punk­tach funkcyjnych.

Jedynym sku­tecz­nym spo­so­bem jaki znam i jaki widu­ję w prak­ty­ce, jest wyce­na na bazie pro­jek­tu zawie­ra­ją­ce­go model dzie­dzi­ny sys­te­mu z dokład­nym mode­lem dzia­ła­nia (logi­ki biz­ne­so­wej). Dużo dokład­niej­sze są wyce­ny, doko­ny­wa­ne rela­tyw­nie niskim nakła­dem pra­cy, przez doświad­czo­nych archi­tek­tów opro­gra­mo­wa­nia na bazie co naj­mniej wstęp­nych pro­jek­tów. Wycena na bazie czar­nej skrzyn­ki”, jaką są przy­pad­ki uży­cia dekla­ro­wa­ne” przez zama­wia­ją­ce­go, to raczej wró­że­nie z fusów.


[uzu­peł­nie­nie] Pewną odmia­ną powyż­szej meto­dy (COSMIC) jest meto­da punk­tów funk­cyj­nych IFPUG (z International Function Point Users Group). Oparta jest dekla­ro­wa­nych funk­cjo­nal­no­ściach i zbie­ra­nych danych histo­rycz­nych ze zre­ali­zo­wa­nych pro­jek­tów. Pomysł pole­ga na uzna­niu, że kosz­ty imple­men­ta­cji podob­nych funk­cji sys­te­mu” są tak­że podobne. 

Niestety to zało­że­nie nie znaj­du­je potwier­dze­nia w prak­ty­ce a twór­cy meto­dy sami przy­zna­ją, że jej sku­tecz­ność jest niska .

Podręcznik Stosowania meto­dy Punktów Funkcyjnych IFPUG w Agencji Restrukturyzacji i Modernizacji Rolnictwa (2018)

Powyższe to wstęp do pew­ne­go ofi­cjal­ne­go doku­men­tu. Konia z rzę­dem temu kto okre­śli poję­cie funk­cjo­nal­no­ści biz­ne­so­wej usłu­gi apli­ka­cji i jej licz­bę jed­no­stek, nie widząc jak będzie reali­zo­wa­na. Prosty przy­kład: apli­ka­cja dla Biblioteki (patrz: Inżynieria opro­gra­mo­wa­nia z uży­ciem narzę­dzia CASE ? pro­jekt badaw­czy) ma mieć funk­cjo­nal­ność «wypo­ży­cze­nie książ­ki» i «zwrot książ­ki», rzecz w tym, że naj­lep­sza spraw­dzo­na imple­men­ta­cja to nie będą dwie funk­cje” tyl­ko jed­na for­mat­ka ekra­no­wa Karta Wypożyczenia a zwrot książ­ki będzie reali­zo­wa­ny poprzez wpi­sa­nie daty zwro­tu na wysta­wio­nej wcze­śniej Karcie Wypożyczenia. W tym momen­cie wymia­ro­wa­nie IFPUG (COSMIC tak­że) jest po pro­stu fun­ta kła­ków war­te: będzie potęż­nie zawy­żo­ne, a deve­lo­per – pod dyk­tan­do takiej wyce­ny – wyko­na bar­dzo złą i kosz­tow­ną imple­men­ta­cję. Innym powo­dem niskiej wia­ry­god­no­ści tego typu metod jest to, że na eta­pie w któ­rym zna­my przy­pad­ki uży­cia a nie zna­my ich imple­men­ta­cji nie mam pod­staw do oce­ny zło­żo­no­ści bo nie wie­my ile będzie sce­na­riu­szy dla każ­de­go przy­pad­ku uży­cia a może ich być wię­cej niż jeden (patrz Use Case 2.0). Po trze­cie jakość mode­lu przy­pad­ków uży­cia też ma ogrom­ny wpływ na tak­że wyce­nę (patrz Przypadki uży­cia i ich deta­le).

Generalnie moż­na pod­su­mo­wać to tak: meto­dy wyce­ny bazu­ją­ce na sta­ty­sty­kach pocho­dzą­cych ze zre­ali­zo­wa­nych pro­jek­tów są opar­te na zało­że­niu, że wyce­nia­ny pro­jekt będzie reali­zo­wa­ny tymi samy­mi lub ana­lo­gicz­ny­mi meto­da­mi co samo z sie­bie jest zaprze­cze­niem postę­pu tech­nicz­ne­go i roz­wo­ju metod inży­nie­rii opro­gra­mo­wa­nia. Praktyka poka­zu­je, że wyce­ny tymi meto­da­mi są prak­tycz­nie pra­wie zawsze zawy­żo­ne a obsza­ry nowa­tor­skie moc­no nie­do­sza­co­wa­ne lub prze­sza­co­wa­ne (bo nowa funk­cjo­nal­ność z zasa­dy nie ma histo­rii). W efek­cie moż­na pod­su­mo­wać to tak: meto­dy sta­ty­stycz­ne wymia­ro­wa­nia, opar­te na przy­pad­kach uży­cia lub funk­cjo­nal­no­ściach, to meto­dy opar­te na pre­dyk­cji histo­rycz­nych danych pro­jek­to­wych, gdzie mate­ria­łem wej­ścio­wym jest model czar­nej skrzyn­ki. Jeżeli do tego doda­my infor­ma­cję o jako­ści reali­za­cji pro­jek­tów infor­ma­tycz­nych publi­ko­wa­ne cyklicz­nie przez Standish Group:

To wnio­sek jaki się nasu­wa to: sto­so­wa­nie metod sta­ty­stycz­nych, zawy­ża­ją­cych wyce­ny, beto­nu­je kata­stro­fal­ny stan opi­sa­ny w tych rapor­tach. Alternatywą jest pro­ces MDA/SPEM, któ­ry zakła­da, że wyce­na będzie doko­ny­wa­na dopie­ro po opra­co­wa­niu co naj­mniej wstęp­ne­go pro­jek­tu imple­men­ta­cji usług apli­ka­cji (przy­pad­ki uży­cia), co nie tyl­ko uwia­ry­god­ni wyce­nę ale tak­że roz­wią­że wie­le wąt­pli­wo­ści na tym wcze­snym etapie. 

(arty­kuł uzu­peł­nio­ny w 2021 r.)

Źródła

Czarnacka-Chrobot, B. (2009). WYMIAROWANIE FUNKCJONALNE PRZEDSIĘWZIĘĆ ROZWOJU SYSTEMÓW OPROGRAMOWANIA WSPOMAGAJĄCYCH ZARZĄDZANIE NA BAZIE UOGÓLNIONYCH DANYCH HISTORYCZNYCH. 13.
Pospieszny, P., Czarnacka-Chrobot, B., & Kobyliński, A. (2015). Application of Function Points and Data Mining Techniques for Software Estimation – A Combined Approach. In A. Kobyliński, B. Czarnacka-Chrobot, & J. Świerczek (Eds.), Software Measurement (Vol. 230, pp. 96 – 113). Springer International Publishing. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑319 – 24285-9_7
Bautista, L., Abran, A., & April, A. (2012). Design of a Performance Measurement Framework for Cloud Computing. 2012. https://​doi​.org/​1​0​.​4​2​3​6​/​j​s​e​a​.​2​0​1​2​.​5​2​011

Inne artykuły na podobny temat

Komentarze

  1. Sylwester 24 listopada 2015 at 19:45

    Aplikację moż­na bar­dzo dokład­nie zwy­mia­ro­wać mając dokład­ny pojekt apli­ka­cji. Nic dodać nic ująć. Tylko, musi­my sobie zadać pyta­nie, jaki pro­cent cał­ko­wi­tej apli­ka­cji został już wyko­na­ny, w momen­cie gdy mamy doklad­ny pro­jekt ? 20%, 30%, czy może połowa ? 

    W budow­nic­twie, dokład­ny pro­jekt kosz­tu­je oko­ło 1% całej inwe­sty­cji. W przy­pad­ku opro­gra­mo­wa­nia, napraw­dę dokład­ny pro­jekt to goto­wa aplikacja.

    • Jaroslaw Zelinski 25 listopada 2015 at 10:34

      Patrzę na to tak. Idąc za MDA, model PIM (plat­form inde­pen­dent) to w zasa­dzie sce­na­riu­sze reali­za­cji przy­pad­ków uży­cia i udo­ku­men­to­wa­na logi­ka dome­no­wa (struk­tu­ra obiek­to­wa, biz­ne­so­we meto­dy obiek­tów), któ­ra te sce­na­riu­sze reali­zu­je. Jest to nie­ja­ko meta­mo­del przy­szłe­go kodu (dzie­dzi­ny sys­te­mu), część dome­no­wa odpo­wia­da­ją­ca za reali­za­cję logi­ki biz­ne­so­wej (czy­li jakieś może 3 – 5% całe­go kodu 🙂 ). Cała resz­ta kodu to inży­nie­ria” reali­zu­ją­ca wyma­ga­nia pozafunkcjonalne. 

      To czy dopie­ro goto­wa apli­ka­cja jest jej jedy­nym pro­jek­tem to kwe­stia tego co nazy­wa­my dokład­nym pro­jek­tem”. Tu się zgo­dzę, że robie­nie tak dokład­ne­go” pro­jek­tu np. w UML nie ma żad­ne­go sen­su. Ale jeże­li umo­wa” z deve­lo­pe­rem mówi, że pro­jekt” zawie­ra: archi­tek­tu­rę kodu (logi­kę jego kon­struk­cji i dzia­ła­nia) oraz to jak ta archi­tek­tu­ra ma reali­zo­wać usłu­gi apli­ka­cji (sce­na­riu­sze reali­za­cji usług) to deve­lo­per ma do wyko­na­nia (zapro­jek­to­wa­nia) swój model PSM (plat­form spe­cy­fic) czy­li imple­men­ta­cję, zapew­ne ma masę pro­ble­mów tech­nicz­nych do roz­wią­za­nia ale logi­kę biz­ne­so­wą ma (te pro­ble­my roz­wią­zał mu ana­li­tyk, pro­jek­tant tej logi­ki). To dla­te­go nie wyobra­żam sobie sen­sow­ne­go wymia­ro­wa­nia nakła­du pra­cy tyl­ko na pod­sta­wie punk­tów funk­cyj­nych” i nigdy nie widzia­łem by taka pro­gno­za się spraw­dzi­ła. Jedynym sku­tecz­nym spo­so­bem wyce­ny jaki znam to zebra­nie ofert fixed-pri­ce na reali­za­cje 🙂 i albo dosta­je ofer­tę albo masę pytań o bra­ku­ją­ce szczegóły :). 

      No i teraz: co nazy­wa­my wyko­na­ną apli­ka­cją”? Nawiązując do budow­nic­twa: mając tyl­ko pro­jekt archi­tek­to­nicz­ny nie mam jesz­cze nawet kawa­łecz­ka domu! Nadal pusta łąka!. Ale deve­lo­per ma pod­sta­wę do opra­co­wa­nia kosz­to­ry­su… by zło­żyć ofertę.

Dodaj komentarz

Twój adres email nie zostanie opublikowany

Komentuj i zadawaj pytania autorowi.

Identyfikator *
E-mail *
Witryna internetowa

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.