www.romver.ru / Полный список статей / Проектирование интерфейса как часть ТЗ

Vnedrenie sistem avtomatizacii biznesa, kak znaet luboy vovle4enniy v etu oblast' specialist, otnud' ne avlaetsa legkim delom. Esli samo sozdanie sistemi, voob6e govora, texni4eski ne o4en' slojno (k primeru, nel'za skazat', 4to srednestatisti4eskaa sistema napolnena slojney6imi algoritmami), to vnedrenie trebuet ot avtomatizatora nedujinnoy kvalifikacii, redkogo uporstva i izvorotlivosti. Pri etom korni mnogix problem naxodatsa v texni4eskom zadanii. Kak govoritsa, «4to zadumali, to i sdelali», no potom inogda okazivaetsa, 4to zadumali-to i nepravil'no. Dla re6enia problem, voznikau6ix pri sozdanii TZ, a proavlau6ixsa pri vnedrenii, pridumano mnojestvo texnologiy i metodov, odnako samo ix koli4estvo svidetel'stvuet o tom, 4to ni odin metod k polnomu uspexu ne privodit. Krome togo, mnogie metodi imeut principial'niy nedostatok – oni uveli4ivaut ob&em 4asti raboti, pust' i radi ekonomii na drugom etape, i trebuut ser'eznix investiciy v obu4enie sotrudnikov (xarakterniy primer – RUP). Su6estvuet, odnako, podxod, kotoriy ne trebuet osoboy kvalifikacii sotrudnikov, zna4itel'no obleg4aet vnedrenie, vovse ne uveli4ivaa ob&em rabot.

Su6nost' podxoda mojet bit' opisana odnoy frazoy — proektirovanie interfeysa ne est' 4ast' processa razrabotki, a 4ast' processa sozdania specifikaciy na sistemu.

Zdes' neobxodimo sdelat' dva vajnix uto4nenia. Vo-pervix, interfeys vsё ravno budet razrabotan (praktika pokazivaet, 4to zakaz4iki po4emu-to neoxotno opla4ivaut funkcional'nost' bez interfeysa). Vo-vtorix, ot proektirovania interfeysa ni4ego osobogo ne trebuetsa — na nego mogut bit' videleni te je resursi, 4to i v slu4ae obi4noy razrabotki, ravno kak i polu4it'sa on mojet takim je. Avtoram, zarabativau6im sebe na jizn' razrabotkoy ergonomi4nix interfeysov, nepriatno eto govorit', no interfeys mojet bit' daje ne ergonomi4nim, vse ravno vnedrenie budet obleg4eno; razumeetsa, v slu4ae ergonomi4nogo interfeysa vnedrenie budet e6ё bolee prostim, no takoy interfeys doroje i dol'6e delaetsa.

Predlagaemiy podxod pozvolaet re6it' sleduu6ie problemi:

• Ustranit' razli4ia vo vzgladax na postanovku zada4i zakaz4ika i ispolnitela. Specifikacii na skol'ko-nibud' slojnie sistemi sli6kom abstraktni. Ix s trudom uderjivaut v golove daje avtori, a do konca ne ponimaet nikto, v osobennosti klu4evoe lico — zakaz4ik. Dla nego eta specifikacia ni4em ne otli4aetsa ot sakral'nix pis'men (mnogie daje predpolagaut, 4to neponatnie TZ prednazna4eni dla togo, 4tobi proizvesti na nix vpe4atlenie i sodrat' pobol'6e deneg). Net raznici, 4to podsunut emu razrabot4iki, real'noe TZ ili instrukciu k gazonokosilke na farsi — vse odinakovo neponatno. Naivno predpolagat', 4to zakaz4ik, legko podpisav6iy takoe TZ, takje legko primet razrabotannuu sistemu. Prototipi interfeysa avlautsa tem edinstvennim dokumentom, kotoriy zakaz4ik mojet ponat' i ocenit'. A ponav i oceniv — soznatel'no podpisat'.
• Obleg4it' process vnedrenia sistemi. Vesomaa 4ast' problem vnedrenia v ka4estvenno vipolnennom proekte prixoditsa na interfeys, sozdanniy formal'no pravil'no, no neadekvatno predstavleniam zakaz4ika. Ne su6estvuet vida TZ, krome sobstvenno prototipa interfeysa, kotoriy bi mog integrirovat' takogo roda trebovania. Nagladniy primer: v lubom TZ mojno propisat', 4to «v sisteme est' adresnaa kniga, kotoraa sostoit iz takix-to dannix i takix-to funkciy». No nevozmojno formalizovat' uje v TZ, kak eta adresnaa kniga doljna real'no rabotat' (kakie-to funkcii nujno «vita6it'» naverx, kakie-to mojno «zadvinut'»), kak, v konce koncov, eta adresnaa kniga doljna vigladet'. Pri etom apellacii ispolnitela k podpisannomu texni4eskomu zadaniu – deskat', vot je pere4islennie funkcii... vot oni vse nalico — kak pravilo, ne srabativaut, poskol'ku pri izvestnoy izvorotlivosti v kontekste pol'zovatel'skogo interfeysa prointerpretirovat' TZ vsegda mojno o4en' po-raznomu. Tol'ko zaranee sproektirovanniy interfeys pozvolaet zastraxovat'sa ot takogo roda pretenziy.
• Sokratit' 4islo dorabotok sistemi, vizvannix nesootvetstviem ee funkcional'nosti ojidaniam klienta. Tol'ko uvidev samu sistemu, zakaz4ik mojet real'no ponat' ee vozmojnosti, ravno kak i ocenit' sobstvennie potrebnosti. Dla zakaz4ika programmniy produkt i ego interfeys sover6enno tojdestvenni. Sledovatel'no, pokazav zakaz4iku interfeys na stadii podgotovki TZ, mojno snizit' koli4estvo i ob&em peredelok, potrebnost' v kotorix voznikaet iz-za rasxojdeniy ojidaniy zakaz4ika s zaplanirovannoy v TZ funkcional'nost'u sistemi. (Nujno, vpro4em, otmetit', 4to takie peredelki 4a6e vsego ne problemati4ni dla razrabot4ikov, kotorie obi4no nastaivaut na dopolnitel'noy oplate etix uslug.)
• Snat' risk neobxodimosti dorabotki funkcional'nosti sistemi, iz-za neudovletvorennosti zakaz4ika predlojennim interfeysom. Pri razrabotke interfeysa net re6itel'no nikakoy garantii togo, 4to on budet prinat zakaz4ikom. Opisanie funkciy sistemi binarno, funkcia mojet bit', mojet ne bit'. Dokazatel'stvo eё nali4ia redko trebuet argumentacii. Interfeys je mojet bit' libo dostato4no xoro6im, libo nedostato4no xoro6im. Kogda v delo vstupaut otnositel'nie termini, vse uslojnaetsa, 4to mojet privodit' v vozniknoveniu konfliktnix situaciy. Ne4ego i govorit', 4to pri peredelke nedostato4no xoro6ego interfeysa funkcional'nost' sistemi, kotoraa uje est', menaetsa toje, pri4em bez oplati truda razrabot4ika.

Takim obrazom, est' ob&ektivnaa pol'za v tom, 4tobi rassmatrivat' proektirovanie interfeysa ne kak stadiu razrabotki, a kak stadiu sozdania TZ. No kak eto sdelat'? Na perviy vzglad, zada4a kajetsa trudnorazre6imoy, 4asti4no s organizacionnoy, 4asti4no s texni4eskoy storon.

Sna4ala ob organizacionnoy storone. Na perviy vzglad zakaz4ika trudno ubedit' otkazat'sa ot misli, 4to delat' 4to-to «real'noe» nado srazu posle podpisania dogovora. Odnako praktika pokazivaet, 4to promejuto4nie nagladnie rezul'tati raboti nad sistemoy, a imenno prototipi interfeysa, prodemonstrirovannie uje na vtoroy den' raboti, a ne 4erez neskol'ko nedel', privodat klienta v blagodu6estvo. V otli4ie ot obi4nogo TZ, rabota nad kotorim zakaz4iku real'no ne vidna («nu 4to tam, para punktov dobavilas'») prototipi interfeysa legko ponatni i progress v rabote avno zameten. Vtoraa organizacionnaa problema svazana s neobxodimost'u podpisivat' dva dogovora: na sozdanie TZ (4itay — interfeysa) i na razrabotku funkcional'nosti sistemi. Pri4em podpisanie vtorogo dogovora otkladivaetsa na opredelenniy srok, neobxodimiy dla razrabotki interfeysa, 4to rastagivaet proekt vo vremeni. V principe, eta problema nerazre6ima, no, s drugoy storoni, zdes' mnogoe zavisit ot eё vospriatia: da, dogovora dva, no zato vtoroy dogovor polu4aetsa zna4itel'no bolee to4nim (uje imea interfeys, leg4e ocenit' trudozatrati).

Texni4eskaa problema svazana s trudnostami prototipirovania. V obi4nom rejime raboti interfeys sozdaetsa uje v sredstve razrabotki, sozdavat' je prototip takim obrazom nerentabel'no. Interfeys sozdaetsa 4erez mnojestvo iteraciy, a peredelivat' uje sdelannoe uje dorogo. Sravnitel'no nedavno poavilis' special'nie sredstva dla prototipirovania interfeysa (naprimer, Norpath Studio), no poka oni dovol'no sirie. Vixod — ispol'zovanie nespecializirovannix grafi4eskix redaktorov. E6ё neskol'ko let nazad osnovnim takim redaktorom avlalsa MS PowerPoint, sey4as je naibolee udobnim sleduet priznat' MS Visio. Slojnie ekrannie formi, vpro4em, do six por udobnee prosto risovat' na bumage.

I, nakonec, glavnaa problema. Udlinenie processa razrabotki TZ 4asto vosprinimaetsa samimi razrabot4ikami kak bezuslovnoe zlo — privi4ka sna4ala delat', a uj potom dumat', tradicionno sil'na v rossiyskom IT-biznese. Uvi, izmenit' etot obi4ay mojet tol'ko «opit, sin o6ibok trudnix». Poka, vo vsakom slu4ae…

Kone4no, proektirovanie interfesa na etape razrabotki specifikaciy sistemi ne avlaetsa panaceey. Takoy podxod ne pozvolaet ulu46it' ka4estvo razrabotki v principe, naprimer, on vovse ne umen'6aet koli4estvo o6ibok programmirovania. Bolee togo, on ne vsegda primenim. Interfeys slojnoy sistemi nevozmojno s samogo na4ala sproektirovat' polnost'u: pridetsa sna4ala delat' rabotau6uu beta-versiu i okon4atel'no pravit' interfeys uje na eё osnove. Krome togo, vo mnogix proektax iz-za ne zavisa6ix ni ot kogo pri4in ne polu4aetsa rastagivat' process sozdania TZ (zakaz4ik xo4et uvidet' kakie-nibud' rezul'tati uje zavtra). Odnako, u4itivaa nizkie «vxodnie» trebovania k primeneniu predlojennogo metoda (nesravnimie, naprimer, s volokitoy i burokratiey, obuslovlennoy ispol'zovaniem UML), proektirovanie interfeysov na stadii podgotovki specifikaciy po4ti vsegda avlaetsa krayne uspe6nim metodom re6enia problem vnedrenia.