Veidojot tehnisko uzdevumu, tajā obligāti jāiekļauj visas prasības informācijas sistēmai, pretējā gadījumā izstrādātājs vienkārši nezina, kādam mērķim produkts tiek izveidots, ko un kā tas paredzēts izpildīt. Prasību formulēšana ir jāuzņemas klientam, lai gan praksē parasti palīdz menedžeri, caur kuriem tiek veikts pasūtījums. Bet studentiem, kas iesaistīti kursa darbu, disertāciju rakstīšanā, jāspēj patstāvīgi sastādīt šādus sarakstus.
Kopīga izpratne
IP izveides process ir diezgan sarežģīts, sastāv no daudziem secīgiem posmiem. Speciālisti, kas strādā pie projekta, ir spiesti risināt dažādas grūtības. Zināmā mērā to var vienkāršot, precīzi formulējot prasības informācijas sistēmai. Ne vienmēr ir skaidrs, kāpēc rodas problēmas, jo īpaši strādājot ar novatoriskiem produktiem, un bieži vien grūts uzdevums ir izveidot visaptverošu aprakstu par visām darbībām, kurām produkts ir paredzēts.
Uzmanība visām detaļām
Pilns produkta funkcionalitātes attēls ir pilns informācijas sistēmas prasību saraksts. Tas ietver arī aspektus, kurus klients ierosina, un programmētājs tos realizē, veidojot projektu. Resursu palielināšanas process, to analītiskā izpēte, dokumentēšana un veiktspējas pārbaude ir prasību izstrāde, kuras laikā ir iespējams precīzi noteikt visus ierobežojumus un panākt vienošanos starp “es gribu” un “patiešām īstenojamu”. Svarīgi atcerēties, ka mūsdienu inženieri nav magi, bet cilvēki, kuri izmanto pieejamus tehniskos rīkus, kuru iespējas diemžēl arī ir ierobežotas. Laika aspekts nav mazāk nozīmīgs, jo darbs pie prasību izveidošanas un ieviešanas prasa ievērojamas laika izmaksas - mēnešus un dažreiz gadus.
Kuras tur ir?
Parasti tiek runāts par informācijas un sistēmas un lietotāju prasībām. Dabiskā valoda raksturo tās, kuras iesniedzis konkrēts lietotājs. Lai precizētu formulējumu, varat izmantot diagrammas ar dažādu sarežģītības pakāpi. Tas ļauj jums radīt vispārēju iespaidu par funkcijām, kurām IP ir paredzēts ieviest, un ierobežojumiem, ar kuriem jūs saskarsities savā darbā.
Sistēmas prasības ir tās īpašās projekta iezīmes, kuru pārzināšana ļauj klienta vēlmes pārvērst realitātē. Šīs informācijas sistēmas tehniskās prasības ietver prezentāciju par aprīkojuma īpašībām, tā jaudu, kā arī izvēli par labu konkrētai arhitektūras opcijai. Sistēmai var piedēvēt daudzus citus aspektus, kas lietotājam nav acīmredzami, bet reglamentē to, kāds būs galaprodukts.
Prasības: kur tos iegūt?
Informācijas sistēmas prasību formulēšanas un apstiprināšanas uzdevumi nav tik vienkārši, kā varētu šķist no pirmā acu uzmetiena. Šis termins tiek izmantots, lai apzīmētu tik sarežģītu strukturētu procesu, kura ietvaros tiek izveidota dokumentācija, kuru apstiprina pasūtītājs - būvuzņēmējs, kas skaidri regulē visas produkta specifikācijas. Attīstība ir sadalīta četros secīgos posmos:
- analītiskās aktivitātes, lai noteiktu plānotās iespējamības pakāpi;
- prasību izveidošana, analītiska izpēte tieši;
- prasību noformēšana apliecinošās dokumentācijas veidošanai;
- informācijas sistēmas prasību sertifikācija informācijai, kā arī citi nosacījumi, projekta ieviešanas noteikumi.
Nav tik vienkārši
Ja savulaik tiek noteiktas prasības informācijas sistēmu drošībai, informācijas saturam, formātam, pārvaldības uzdevumiem un citiem projekta funkcionēšanas aspektiem, tas nenozīmē, ka tās paliks nemainīgas līdz “uzvarošajam beigām”. Darbplūsma bieži tiek saistīta ar izmaiņām noteiktajās specifikācijās un prasībās. Tas notiek ne tikai pēc pasūtītāja, bet arī no darbuzņēmēja iniciatīvas, kurš saskaras ar noteiktiem tehniskiem ierobežojumiem, kas kavē īstenot vairākus plānotos aspektus. Ir svarīgi ņemt vērā procesa vadības iezīmes. Izmaiņu vadība ir viens no galvenajiem prasību izstrādes un to ieviešanas aspektiem noteiktā IP.
Svarīgs aspekts darbā ar prasībām ir to personu definēšana, kurām ir sekojoša daudzpusīga informācijas analīze. Šim nolūkam tiek izmantots vispārināts darba modelis. Konkrēta uzņēmuma ietvaros tiek ieviesta unikāla informācijas sistēmas prasību pārvaldības sistēma, kas ļauj formulēt, pielāgot, pieņemt, noraidīt izvēlētos nosacījumus. Daudz kas ir atkarīgs no darba ņēmēju kvalifikācijas, intelektuālā īpašuma veida, pie kura viņi strādā, no standartiem, kurus izmanto darbplūsmā.
Kā tas izskatās?
Praksē informācijas sistēmu drošības prasību formulēšana, analīze, datu aizpildīšana, struktūra (un citas sistēmas un lietotāji) vispirms ietver noteiktas tēmas jomas pazīmju identificēšanu. To pēta kvalificēti analītiķi, nākotnē nosakot izstrādātā produkta lietojuma sektora īpašos parametrus. Pēc tam viņi sāk vākt sākotnējās prasības, sadarbojoties ar personām, kuras formulē šādu informāciju. Paralēli viņi turpina darbu pie priekšmetu zonas uzlabošanas.
Nākamais solis, formulējot prasības pašvaldību informācijas sistēmām, privātām, ko izmanto valdības aģentūrās, ir izveidot identificētas informācijas hierarhisku sistēmu. Ja sākotnējā informācijas vākšana dod haotisku datu kompleksu, tad sistematizācijas ietvaros tas tiek pasūtīts, izveidojot elementu grupas, kurām ir loģiski savienojumi savā starpā.
Turpinot darbu
Nākamais solis informācijas prasību noteikšanai informācijas sistēmās, projekta struktūra, funkcionālās, iekšējās iezīmes ir pretrunu identificēšana un konfliktu risināšana. Saņemot informāciju no plaša spektra trešo personu par izstrādātā IP darbu, viņi sastopas ar šādu problēmu: katram cilvēkam ir savas unikālas idejas par projekta iespējām un tā mērķi. Bieži vien dažādu cilvēku saņemtās idejas nonāk konfliktā viena ar otru, kā arī ir pretrunā ar loģiku, esošajām tehniskajām iespējām, caur kurām sistēma tiek ieviesta. Lai pilnveidotu situāciju, pēc rūpīgas analīzes ir jāidentificē visas pretrunas un jāatrod optimālais kompromisa risinājums to novēršanai.
Nosakot pretrunas un analizējot visu prasību iespējamību, ir jāizveido arī prioritāšu sistēma. Starp vispārīgo prasību kopumu vienmēr ir svarīgākas un mazāk nozīmīgas. Izstrādātāju uzdevums ir cieši sadarboties ar tiem, kas izstrādā prasības, lai identificētu, kuri no izstrādātā produkta funkcionēšanas aspektiem ir visnozīmīgākie un kuri var nogaidīt vai tikt pilnībā atcelti, ja to veicina negatīvi ārējie apstākļi (piemēram, laika trūkums). Izveidojot prioritāšu sistēmu, mēs varam sākt pārbaudīt identificēto aspektu pilnīgumu, savietojamību savā starpā un konsekvenci.
Soli pa solim
Prasības informācijas sistēmām (personas dati, informācija par uzņēmuma darbu un jebkurš cits) tiek formulētas cikliska procesa ietvaros. Visi posmi ir savienoti gan tieši, gan apgriezti. Soļi ir aprakstīti iepriekš: vispirms jums jāidentificē priekšmeta joma, pēc tam pakāpeniski pārejiet uz prasību savstarpējas saderības, kā arī to pilnīguma un citu parametru noteikšanas soli, ļaujot mums runāt par iegūto nosacījumu piemērojamību praksē. Ja jums izdodas izveidot pilnvērtīgu priekšmeta laukuma attēlu, tas jau nosaka darba apstākļus, jo īpaši tā darbību. Cikla atkārtošana dod precīzāku, padziļinātu skatu uz teritoriju, trešais cikls ļaus vēl skaidrāk formulēt prasības. Atkārtošana ir nepieciešama, kamēr visi darbplūsmas dalībnieki precīzi saprot, kam sistēma ir paredzēta un kā tā darbosies, kas jāievieš, strādājot pie projekta.
Lai prasību veidošanas process būtu efektīvs un tā rezultāti būtu izmantojami darbā, nosacījumu formulēšanai ir jāievēro vispārpieņemti algoritmi.
Atsauces punkti
Šī ir pamata metode, lai identificētu prasības valsts informācijas sistēmām, jo īpaši - īsi sakot, absolūti jebkuram, neatkarīgi no tā, kur tās tiek izmantotas. Nosacījumu definīcijas ietvaros kā sākotnējs nosacījums ir jāatzīst, ka viedokļi par izskatāmo jautājumu var atšķirties. Tie tiek identificēti un izmantoti par pamatu pirmā prasības vākšanas procesa formulēšanai, pēc tam - faktiskajiem apstākļiem.
Skatu punkts ir diezgan neskaidrs jēdziens, tāpēc ir izstrādātas vairākas pieejas, kas to interpretē atšķirīgi. Vienkāršākā jēdziena interpretācija ir datu avots, kas apraksta IP darbību. Atsauces punkti kļūst par pamatu IP modelēšanai un informācijas izmantošanai izstrādājumā. Prasību apkopošana ietver visu nozīmīgo atskaites punktu identificēšanu, kurus tālāk izmanto izstrādājuma veidošanas procesā. Tas arī ņem vērā to, kā metodes tiks izmantotas datu apstrādei.
Alternatīva pieeja
Cita jēdziena “skatu punkts” interpretācija ietver termina uztveršanu kā attēlojuma struktūru. Faktiski tas ir produkta modeļa elements. Dažādi skatu punkti ļauj izveidot daudzus ierobežotu stāvokļu mašīnu modeļus, entitāšu mijiedarbību un attiecības starp tām konkrēta projekta ietvaros. Tiek ņemta vērā projekta apjoma specifika.
Skatu punkts var nozīmēt pakalpojuma ārējā saņēmēja viedokli, kas ieviests, izmantojot IP. Balstoties uz TK, ir iespējams identificēt datus, kas tiek izmantoti sistēmas pakalpojumu ieviešanā, to pārvaldībā. Šī pieeja tiek uzskatīta par visefektīvāko. Tas veidoja uz skatu orientētu prasību definīcijas pamatu - īpašu prasību identificēšanas metodi, kas ļauj noteikt informāciju un efektīvi to analizēt.
Darbs ar skatu punktiem
Pirmkārt, tie ir jāidentificē, kā arī jānosaka visi pakalpojumi, kas saistīti ar noteiktu punktu. Tad sistēma tiek strukturēta hierarhiskā veidā, grupējot viedokļus savā starpā, atklājot kopīgus pakalpojumus IP. Tie tika vērtēti kā augstākais hierarhijas līmenis. Viņus mantos visi zemāka līmeņa TK.
TK atbalsts ir jādokumentē. Šī informācija ir skaidri aprakstīta, ņemot vērā identifikācijas rezultātus. Pēc tam ir iespējams sastādīt TK sistēmu, kurā tiks atspoguļoti visi IP objekti, kas identificēti no apkopotās informācijas.
Nesteidzieties!
Parasti darbs pie IP sākas ar liela mēroga prāta vētru, kas paredzēta, lai noteiktu visas iespējamās prasības projektam. Iepriekš jāapzinās, ka gandrīz neiespējami noteikt visas iespējamās prasības ar vienu procedūru. Jo sarežģītāka sistēma, jo vairāk šādu procedūru būs vajadzīgas.Tikai tad, ja atkārtotas prāta vētras sesijas, kurās piedalās gan pasūtītājs, gan darbuzņēmējs, nesniedz noderīgu informāciju, viņi pamatoti pieņem, ka TOR ir identificēti un prasības ir formulētas, mēs varam turpināt to ieviešanu ar tehniskiem līdzekļiem.
Prasību sertifikācija
Šī procedūra ļauj jums saprast, cik lielā mērā prasības atbilst klienta idejām par galaproduktu. Pārbaude ir viens no vissvarīgākajiem posmiem, lai atklātu kļūdainu specifikāciju un jau iepriekš to novērstu. Pretējā gadījumā izmaiņas būs jāveic posmā, kad sistēma jau ir projektēta un konstruēta, kas rada gan īslaicīgus, gan citus resursu zaudējumus. Lielākās problēmas rada kļūdas, kas atklātas pēc produkta ieviešanas uzņēmumā.
Parasti darbs pie sistēmas pielāgošanas tiek novērtēts daudz augstāk nekā neprecizitāšu atklāšana un labošana IP projektēšanas posmā, kodēšanas funkcionalitāte. Prasību maiņa vairumā gadījumu izraisa iespaidīgas strukturālas izmaiņas, ieskaitot pamata līmeni. Tas nozīmē, ka pēc izmaiņu veikšanas jums būs jāveic pilns verifikācijas un testēšanas diapazons, lai pārliecinātos, ka visi paredzētie rīki darbojas pareizi.