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

66 Eseje
podobných systémov. Našťastie počas dlhoročnej práce na riešení
množstva projektov objavuje analytik medzi nimi určité súvislosti a
v sebe schopnosť pozerať sa na systémy z nadhľadu. Takisto by mal
analytik porozmýšľať, u ktorých požiadaviek je pravdepodobnosť zmeny
menšia.
Bolo by pekné, keby sme mohli navrhovať systémy, ktoré by boli
natrvalo flexibilné, ale to nemôžeme. Je potrebné navrhnúť správnu
mieru flexibility. Sústrediť svoje úsilie na veci, ktoré sa menia pomaly.
Požiadavky vždy závisia od faktov z reálneho sveta a od prianí
používateľa. Fakty z reálneho sveta sa menia pomalšie ako priania
používateľov. Dokonca aj keď dôjde k zmene detailov, základné fakty
zostávajú rovnaké. Napr. lietadlo bude stále mať výšku letu a kurz, aj
keby sa technológia ich merania zmenila.
Úlohou softvérového inžiniera je navrhnúť riešenia a implementovať
požiadavky do systému. Nemal by argumentovať tým, že implementácia
nie je možná alebo je príliš nákladná. Pri vývoji softvérového systému
platí pravidlo: „Zákazník má vždy pravdu.“ S týmto konštatovaním úzko
súvisí aj ďalšie pravidlo: „Zákazník platí (alebo neplatí).“
Softvéroví inžinieri sa často ocitnú zoči–voči veľkému množstvu
požiadaviek na systém spolu s nedostatkom času a peňazí na ich
implementáciu. Preto sa musia stanoviť priority jednotlivých
požiadaviek. Rôzne priority určuje zákazník, iné koncový používateľ a iné
softvéroví inžinieri. Preto musia nájsť „spoločnú reč“, ako tieto
požiadavky usporiadať podľa priority. Musia vybrať základné požiadavky,
ktorých implementácia najviac pridá systému na hodnote. Ak systém
nebude spĺňať niektorú z týchto základných požiadaviek, nemožno ho
odovzdať.
Moja osobná skúsenosť
Keď som vyberal túto tému na esej, hneď som si spomenul na projekt
Zber a spracovanie normatívnych dát pre elektromyografiu, ktorý riešime
v rámci predmetu Tímový projekt. Na projekte spolupracujeme s lekárom
z Fakultnej nemocnice. Tento lekár predstavuje typický príklad
zákazníka, ktorý nevie, čo presne chce. Na túto skutočnosť nás už na
začiatku projektu upozornili pedagógovia a študenti, ktorí na ňom
pracovali pred nami.
Počas riešenia projektu sme pochopili náročnosť úlohy analytika –
preniknúť do odbornej terminológie používanej v elektromyografii
nebolo pre nás vôbec jednoduché.
Úvodnú špecifikáciu požiadaviek sme stanovili na základe analýzy
systému, ktorý vytvorili študenti pred nami. Napríklad jedna
z požiadaviek bola umožniť lekárovi rozhodnúť, ktoré z nameraných
údajov zahrnie do databázy a ktoré nie. No na stretnutí so zákazníkom
sme sa dozvedeli, že táto možnosť nie je vhodná kvôli možnej subjektivite
lekára pri takomto rozhodovaní.