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

Čo robiť, ked zákazník nevie presne, čo chce 65
pravidlo: „Pokiaľ obrázok má hodnotu tisíc slov, tak prototyp môže mať
takú hodnotu ako tisíc obrázkov.“
Použiť dodané výrobky
Dodané výrobky (COTS, angl. commercial off–the–shelf) môžu výrazne
ušetriť čas vývoja a peniaze. Softvéroví inžinieri však musia nájsť ten
správny výrobok, ktorý vyhovuje požiadavkám zákazníka.
Aj keď je obstarávanie dodaných výrobkov v súčasnosti stále viac
populárne, úloha nájsť správny výrobok zostáva naďalej problematická.
Dôkazom toho je prípad, o ktorom som sa dočítal v článku [Maiden98].
Systém, ktorý používali zamestnanci The London Ambulance Service,
zlyhal kvôli zlému výberu dodaného výrobku. Po zavedení systému
vznikol veľký zmätok, preto ho stiahli z prevádzky a vrátili sa
k pôvodnému manuálnemu dispečingovému systému.
Softvéroví inžinieri môžu počas získavania požiadaviek robiť
prieskum trhu kvôli identifikácii vhodných kandidátov na dodané
výrobky. Preto je vhodné detailne získať tie požiadavky, ktoré dovolia
efektívnu selekciu týchto kandidátov. Kvôli tejto selekcii je takisto
vhodné, ak sa požiadavky dajú merať. Toto je však ľahšie vysloviť ako
v praxi uskutočniť.
Akonáhle sa používanie dodaných výrobkov stane ešte rozšírenejšie,
požiadavky sa budú čoraz častejšie vyjadrovať v tvare: ”Chceme niečo
podobné ako tamten produkt.” [Maiden98]
Musíme si však uvedomiť, že vlastnosti najlepšieho dostupného
dodaného výrobku determinujú požiadavky na systém. Predstavme si, že
zákazník požaduje jednosekundový čas odozvy systému na spracovanie
transakcií. Najlepšie databázové systémy poskytujú dvojsekundový čas
odozvy. Boehm kladie rečnícku otázku: „Chystáte sa vytvoriť svoju
vlastnú verziu Oracle alebo Sybase s nádejou, že ju spravíte dvakrát
rýchlejšiu“ V tejto situácii musíme rozpoznať, že splniť takýto čas
odozvy nie je adekvátna požiadavka.
Život je zmena
Počas vývoja softvérového systému dochádza často k zmene požiadaviek.
Dokonca Hall uvádza, že jediný zaručene platný fakt týkajúci sa
požiadaviek na systém je to, že sa časom určite zmenia. Preto je zbytočné
uvažovať o zmene požiadaviek ako o probléme [Hall97].
Počas vývoja softvérového systému sa analytik prostredníctvom
zjemňovania požiadaviek dozvedá od zákazníka, čo by mal systém robiť.
Najlepší spôsob, ako to dosiahnuť, je neustále presnejšie vymedzovať
požiadavky. Požiadavky musí analytik spravovať a zmeny v nich sledovať.
Takto môže preukázať vývoj požiadaviek v čase. Kvôli tomu, že zmeny
požiadaviek môžu nastať v najnevhodnejšom čase, ktorý dokonca
ohrozuje termín odovzdania, je vhodné niektoré zmeny požiadaviek
predvídať. To však vyžaduje od analytika značné skúsenosti s vývojom