Team Se@Msi: Meranie v softvérovom inžinierstve. - FIIT STU ...

Ako zlepšiť softvérové procesy 71
ďalšie normy, ktoré súvisia so zlepšovaním procesu sú napríklad: ISO
9001 – norma pre manažment akosti a SPICE – norma pre ohodnotenie
procesu. Ďalšia norma je napríklad IEEE-EIA 12207, ktorá pokrýva celý
životný cyklus projektu. Elementy tejto normy môžeme namapovať na
CMM elementy [Ferguson98].
V USA prvý príklad na integráciu bol integrovaný softvérový model
vyspelosti procesu FFA, ktorý spojil softvérové inžinierstvo, systémové
inžinierstvo a CMM. Ďalší podobný príklad na integráciu je CMMI, ktorý
zjednotil softvérové inžinierstvo, systémové inžinierstvo a CMM model, a
poskytoval aj možnosť integráciu ďalších CMM modelov [Boehm00].
Dedičstvo vodopádového modelu
V CMM modeli verzie 1.1 sa ukazuje obrovské zlepšenie s porovnaním
predošlými nedisciplinovanými konaniami, ale tento model ešte stále
podporuje sekvenčný vodopádový prístup návrhu systému. Toto
dedičstvo brzdí efektívny vývoj dynamicky sa meniacich systémov, teda
nie je možné používať skoré prototypovanie, tzv. concurrent engineering,
manažment rizík, a ďalšie užitočné kroky, ktorými by sa dalo zjednotiť a
zjednodušiť softvérové a systémové inžinierstvo. Autori CMM modelu
tvrdia napríklad: „Analýza a rozdelenie systémových požiadaviek nie je
povinnosťou softvérových inžinierov, no je predpokladom ich práce”
[Paulk01]. Podľa Boehma sa toto vyhlásenie uplatní iba v niektorých
prípadoch, ba dokonca takýto postoj softvérových inžinierov môže byť
veľmi nebezpečný. Také nebezpečenstvo môže byť napríklad tzv.
oddelenie zainteresovania (separation of concern), čo znamená, že
softvéroví inžinieri sa nezaoberajú určovaním systémových architektúr a
systémových požiadaviek, túto prácu ponechajú na iných. Keby sme
súhlasili takýmto postojom, vývojári softvérových systémov by
nepotrebovali žiadne činnosti, ktoré poskytuje softvérové inžinierstvo.
Boehm skúmal sociálne dôsledky takého postoja pri niektorých
príležitostiach stretnutí výskumných pracovníkov, kde navrhovali letecké
systémové architektúry. Pokiaľ hardvéroví a systémoví inžinieri
diskutovali o tom, aké boli ich predchádzajúce systémové architektúry,
softvéroví inžinieri zostali v pozadí. Čakali na niekoho, kto by im dal
presnú špecifikáciu, čo by oni premenili na kód.
Žiaľ tú separáciu v značnej miere podporujú aj súčasné softvérovo
inžinierske modely, ktoré sa sústredia na abstraktné logické úlohy. V
praxi však rozhodujúcim faktorom je výkonnosť a náklady softvérových
systémov. Boehm hľadal v 16 nových učebniciach o objektovoorientovanom
návrhu už spomenuté výrazy, ale iba v 6 sa vyskytovalo v
registri slovo „výkonnosť“ a iba v 2 slovo „náklady“. Ak rozdelíme úlohy
na abstraktné, logické, oddelené podúlohy, môže byť ohrozená úspešnosť
celého projektu.