Listopadowy numer Software Develper Journal zawie­ra bar­dzo cie­ka­wy arty­kuł: Czynniki suk­ce­su w pro­jek­tach pro­gra­mi­stycz­nych.

Wnioski z ankiet:

Wymagania i ich odpo­wied­nie prze­twa­rza­nie to klu­czo­we zagad­nie­nie w pro­jek­tach. Popełniane w tym obsza­rze błę­dy to głów­ne źró­dło pro­ble­mów w pro­jek­tach. Dlaczego tak się dzie­je? Oto głów­ne przy­czy­ny wska­za­ne przez oso­by badane:

1. nie­zna­jo­mość metod i tech­nik zbie­ra­nia wymagań;
2. trud­no dotrzeć do informacji;
3. oso­by dostar­cza­ją­ce wyma­ga­nia są rzad­ko dostępne;
4. nie­pre­cy­zyj­ne wymagania.

Wydają się oczy­wi­ste, a że z fak­ta­mi nie dys­ku­tu­je­my uzna­je­my je.

Ad.1. To chy­ba powszech­na bolącz­ka wie­lu dostaw­ców IT. Najczęściej obser­wu­ję meto­dę pole­ga­ją­ca na ​„zbie­ra­niu wyma­gań” meto­dą pyta­nia ​„cze­go Pan/Pani ocze­ku­je od sys­te­mu” i ta for­ma jest gwoź­dziem do trum­ny pro­jek­tu. Dlaczego? Odpowiedź zawar­ta jest w pozo­sta­łych trzech pun­kach: wywia­dy cier­pią bo trud­no dotrzeć do danych i ich posia­da­czy a ci ostat­ni naj­czę­ściej poda­ją wyma­ga­nia ​„z gło­wy” co daje w efek­cie ład­nie sfor­ma­to­wa­ny ale nie­pre­cy­zyj­ny opis.

Pojawia się pró­ba dia­gno­zy. Pełna tak zwa­na śla­do­wal­ność wyma­gań (nazwa­na tu hiper­tra­ce­bi­li­ty) jest podob­no kosz­tow­na i trud­na do utrzy­ma­nia. Zaraz potem: nie­dba­łość w defi­nio­wa­niu wyma­gań – no to w koń­cu dokład­nie czy nie? Kolej na ana­li­ty­ków: zrzu­ca­nie odpo­wie­dzial­no­ści ? ana­li­ty­cy two­rzą doku­ment wyma­gań i wypy­cha­ją go do pro­gra­mi­stów. Oczywiście jest to pro­blem, co z tym? Analityk powi­nien pono­sić odpo­wie­dzial­ność za swój pro­dukt do koń­ca pro­jek­tu. Założenie, że moż­na stwo­rzyć skoń­czo­ny doku­ment wyma­gań. Otóż moż­na ale o tym za chwi­lę. Poza waż­ny­mi ele­men­ta­mi zarzą­dza­nia takim pro­jek­tem, w tym zarzą­dza­niem zespo­łem auto­rzy wska­za­li jed­ną z głów­nych moim zda­niem przy­czyn: brak doku­men­tu HLD (pro­jek­tu wysokopoziomego).

Otóż nie da się czymś tak zło­żo­nym jak opro­gra­mo­wa­nie (zakła­dam, że to nie try­wial­ny sys­tem), zarzą­dzać na pozio­mie deta­licz­nych szcze­gó­łów. Jedynym spo­so­bem jest uprasz­cza­nie i pra­ca z abs­trak­cja­mi. Czym są owe abs­trak­cje? Modele! Już w 1984 roku zauwa­żo­no, że:

I just read an idea by [[Stephen Hawking]] and [[Leonard Mlodinow]], cal­led [[Model-Dependent Realism]][2]: ?the idea that a phy­si­cal the­ory or world pic­tu­re is a model (gene­ral­ly of a mathe­ma­ti­cal natu­re) and a set of rules that con­nect the ele­ments of the model to obse­rva­tions.? (za Model-Dependent Realism: Is This the Worldview of Software Engineering? ? THINK IN MODELS).

I nie cho­dzi tu o to, że inży­nie­ria opro­gra­mo­wa­nia, to jakiś zło­żo­ny model mate­ma­tycz­ny. Chodzi w ogó­le o posłu­gi­wa­nie się mode­la­mi – abs­trak­cja­mi – na każ­dym eta­pie pro­jek­tu. To jedy­ny spo­sób by ​„ogar­nąć pro­jekt” w cało­ści. Tak samo jak nie da się myśleć o samo­cho­dzie w kon­tek­ście tysię­cy jego pod­ze­spo­łów, tak nie da się tak myśleć o czym­kol­wiek podob­nie złożonym.

ad.2. Docieranie do infor­ma­cji para­dok­sal­nie nie jest trud­ne, jest ich po pro­tu mało w fir­mach. Bardzo czę­sto postę­po­wa­nie poszcze­gól­nych wyko­naw­ców jest efek­tem ich doświad­cze­nia, kom­pe­ten­cji oraz przy­zna­nych upraw­nień. Problemem, a może raczej wyzwa­niem jest zapi­sa­nie czę­ści tych ​„reguł”.

ad.3. To dla mnie kurio­zal­ny powód. Jest raczej dowo­dem sła­bo­ści kie­row­ni­ka pro­jek­tu (bo nie analityka).

ad.4. Zacytuje dla przy­po­mnie­nia: ​„nie­pre­cy­zyj­ne wyma­ga­nia”. Od tego jest ana­li­ty­ka by były pre­cy­zyj­ne. Problem ten poja­wia się czę­sto w sytu­acji gdy owym ​„ana­li­ty­kiem” jest dostaw­ca opro­gra­mo­wa­nia, któ­ry ​„cze­ka na wyma­ga­nia” mimo, że zawarł w ofer­cie i umo­wie pozy­cję ​„ana­li­za wymagań”.