Informacinių sistemų projektavimas ir diegimas. Informacinės sistemos perkėlimas į komercinę veiklą

Išsami informacija Paskelbta: 2018-07-14 21:24: Apžvelgiami pagrindiniai įmonių informacinių sistemų diegimo etapai. Be to, atliekama kiekvieno etapo projektinių dokumentų peržiūra, parodoma tam tikro etapo duomenų priklausomybė nuo vėlesnių etapų dokumentų.
Parsisiųsti: PDF.
Raktiniai žodžiai: ERP sistemos dokumentai, įmonės informacinių sistemų diegimo dokumentacija, informacinių sistemų dokumentacija, dokumentai informacinėje sistemoje, projekto dokumentacija ERP sistemos, darbo dokumentacija YRA, techninę dokumentaciją KIS, reglamentas informacinė sistema, informacinių sistemų projektavimo norminiai dokumentai, programinės įrangos diegimo dokumentai, informacinių sistemų diegimo dokumentai, programinės įrangos produkto diegimo etapai ir dokumentai, informacinių sistemų bandomasis veikimas, GOST R 54869-2011, ANSI PMBoK.

Neabejotinai labiausiai slegianti situacija yra netikrumas. Nežinojimas, kas nutiks toliau jus nerimą keliančiu klausimu, turi itin neigiamą poveikį. Ne išimtis ir įmonės informacinės sistemos (toliau – CIS) diegimo procesas. Tarkime, jūs ką tik prisijungėte prie projekto komandos be jokios darbo patirties ar teorinių žinių. Atlikdami konkrečias užduotis esame panašūs į „aklus kačiukus“, laukiančius rytojaus įspūdžių. Kitas ne mažiau iliustratyvus pavyzdys – konsultantas jau keletą metų sprendžia griežtai ribotą problemų spektrą, nenorėdamas suprasti, kuriems aukštesnio lygio procesams jos aktualios. Tokiais atvejais nereikėtų stebėtis, kai netikėtai užduotis paaiškėja, kad ji buvo atlikta „vakar“. Norint neįtraukti to, kas išdėstyta pirmiau, būtina aiškiai suprasti MIS įgyvendinimo etapų seką ir kiekviename etape parengtus dokumentus.

Tikslas ir užduotys

Šio darbo tikslas – išnagrinėti pagrindinius įmonių informacinių sistemų diegimo etapus, siekiant užtikrinti geresnį diegimo procesą. Norint pasiekti šį tikslą, reikia išspręsti šias užduotis:

• literatūros apie NVS diegimą apžvalga;
• pagrindinių NVS diegimo etapų svarstymas;
• projekto dokumentų ir jų priklausomybių nuo etapų analizė.

1. Įmonės informacinių sistemų diegimo metodų apžvalga

Įmonės informacinę sistemą reprezentuoja informacinių sistemų (toliau – IS) rinkinys, apibrėžiantis tam tikrą dalykinę sritį. Yra keletas IS diegimo būdų, kurie taip pat taikomi ir MIS diegimui (1 pav.). Apžvalgą pradėkime nuo valstybės deklaruojamo požiūrio. Mes kalbame apie pramonės standartus, visų pirma, GOST R 54869-2011, taip pat tarptautiniai ISO standartas 21500. Dokumentuose yra aprašyti projekto valdymo etapai nuo inicijavimo proceso iki užbaigimo, nepriklausomai nuo diegiamos sistemos tipo. Todėl galima naudoti šiuos standartus techninių, informacinių ir korporatyvinių sistemų diegimui. Skliautas profesinių žinių projektų valdymas, kurį pristato ANSI PMI PMBoK, reguliuoja planavimo, vykdymo, peržiūros ir įtakos procesus nuo projekto inicijavimo etapo iki projekto užbaigimo. Panašiai kaip GOST R 54869-2011 ir ISO 21500, jį leidžiama naudoti diegimo valdymui įvairių tipų sistemos

Ryžiai. 1.

„Accelerated SAP“ (toliau – ASAP), „Accenture Delivery Methods“ (toliau – ADM) ir „Microsoft Dynamics Sure Step“ (toliau – MDSS) metodikas atitinkamai naudoja SAP, „Accenture“ ir „Microsoft“ įmonės, diegdamos supakuotą. NVS sprendimai. Metodai yra orientuoti tik į NVS diegimo projektų įgyvendinimą. Aukščiau aptartuose metoduose CIS įvesti pirmiausia naudojama pakopinė schema. Šiai schemai būdinga griežta projekto etapų įgyvendinimo laiko priklausomybė. Veikia šioje stadijoje gali būti vykdoma tik tuo atveju, jei buvo įgyvendintos visos ankstesnio projekto etapo veiklos. Etapų pavadinimai skiriasi priklausomai nuo požiūrio, tačiau kūrinio turinys išlieka nepakitęs. Todėl visai įmanoma suformuoti vienas sąrašas tiek operacijas, tiek parengtus dokumentus. Apibendrinkime NVS diegimo požiūrių analizės rezultatą su tipinių projekto įgyvendinimo etapų sąrašu (2 pav.).

Ryžiai. 2.

2. Projekto dokumentai tipiniams projekto įgyvendinimo etapams

Ankstesnėje dalyje buvo išryškinti tipiniai NVS diegimo projektų įgyvendinimo etapai, įskaitant

• projekto rengimas;
• dizainas;
• įgyvendinimas;
• pasirengimas bandomajai pramoninei eksploatacijai (toliau – AAP);
• OPE;
• perėjimas prie produktyvios veiklos (toliau – PE)

ir kurios yra bendros ASAP, ADM, MDSS metodikoms ir standartams. Leidžiama, kad VĮ etapo nebuvimas, tada 4 ir 5 projekto fazėse bus atitinkamai pasirengta PE ir VĮ. Išsamiau pažvelkime į kiekvieno etapo dokumentus (3 pav.).

Ryžiai. 3.

2.1. Projekto rengimo etapas

Pradinis NVS diegimo projekto etapas yra pasirengimas. Šio etapo kontekste suformuluojami tikslai ir uždaviniai, taip pat rengiami dokumentų šablonai ir padidintas projekto grafikas. Pagrindinis etapo dokumentas yra chartija, kurioje apibrėžiami projekto tikslai, taip pat nurodoma funkcinė, organizacinė, techninė ir metodinė projekto apimtis. Be to, dokumente aprašomi projekto dalyviai ir nustatyta projekto dokumentacijos tvirtinimo tvarka. Rengiama projekto komandos mokymo koncepcija, kurioje siūlomas požiūris į kliento NVS diegimo komandos mokymą. Čia generuojami dokumentų šablonai, naudojami dokumentacijai rengti vėlesniuose projekto etapuose. Įstatuose nurodyta projekto apimtis yra būtina norint nustatyti projekto laiką. Pastarieji atsispindi padidintame tvarkaraštyje, kuris vėliau patikslinamas kiekvienam etapui. Taigi chartija yra dominuojantis pasirengimo etapo dokumentas.

2.2. Projektavimo etapas

Baigę rengti projektą pereiname prie sistemos projektavimo etapo. Projektuojamų sprendimų kokybė, tarpusavio ryšys ir detalumas yra lemiamas veiksnys, lemiantis sėkmingą CIS diegimą. Klaidos, padarytos projektavimo etape, yra gana daug darbo jėgos pašalinti. Projektavimo etapo pradžią lydi mokomosios medžiagos ir užsakovo komandos mokymo plano parengimas. Anksčiau suformuotoje projekto komandos mokymo koncepcijoje yra tik paviršutiniškas šių dokumentų turinys. Toliau užsakovo projekto komanda kartu su rangovo specialistais dalyvauja užsakovo verslo procesų apklausoje. Proceso analizės rezultatas – funkciniai ir techniniai reikalavimai projektuojamai sistemai.

Klientų reikalavimai lyginami su standartiniu CIS sprendimu (Fit analizė), siekiant nustatyti funkcinius trūkumus (GAP analizė). Funkcinis trūkumas reikalauja modifikuoti sistemą, kuriai parengtos kūrimo specifikacijos, kuriose nurodoma problema ir siūlomas sprendimo vektorius. Kuriama vaidmenų ir galių koncepcija, kuri apibrėžia vartotojų vaidmenų sąrašą ir jų kūrimo bei priskyrimo darbuotojams taisykles. Standartinis CIS funkcionalumas, kūrimo specifikacijos, vaidmenų ir autoritetų samprata yra būtini projektiniams sprendimams suformuluoti. Dizaino sprendimai apima kliento verslo procesus „kaip yra“ ir „kaip bus“ modeliais, nurodant sistemos patobulinimus ir vartotojo vaidmenis.

Dizaino sprendimai kuriami remiantis Fit/GAP kliento funkcinių ir techninių reikalavimų analize. Projektų patirtis rodo, kad sprendimai dažniausiai formuojami kiekvieno kliento verslo procesui. Be to, atskirai išryškinami pagrindiniai duomenų tvarkymo, organizacinės struktūros ir migracijos sprendimai. Istorinių sistemos duomenų perkėlimo klausimas nagrinėjamas atskirai atitinkamoje koncepcijoje. Koncepcija apima duomenų perkėlimo metodo, pagal projektinius sprendimus naudojamų perkėlimo mechanizmų ir siūlomo perkėlimo plano aprašymą. Šiame etape taip pat kuriamos galutinių vartotojų mokymo ir perėjimo prie sistemos koncepcijos. Vartotojų mokymo koncepcija nustato treniruočių tvarką ir planuojamą laiką, reikalingą mokymo medžiagą, taip pat atliekamų pratimų sąrašą.

Perėjimo prie sistemos koncepcijoje aprašoma naujojo CIS sprendimo naudojimo tvarka ir ankstesnės sistemos veikimas, pateikiamas veiksmų sąrašas, suteikiantis vartotojams galimybę dirbti su nauju sprendimu, ir apibrėžiamas atliekamų operacijų rinkinys. rankiniu būdu NVS techniniai specialistai. Visi šiame etape sukurti dokumentai yra tarpusavyje susiję. Labiausiai galima svarstyti dizaino sprendimus reikšmingus dokumentus, nes jie yra sistemos diegimo, vartotojų mokymo, duomenų migracijos ir perėjimo prie siūlomo CIS sprendimo taikymo pagrindas.

2.3. Įgyvendinimo etapas

Sistema įdiegta pagal projektavimo etape parengtus dokumentus. Projektavimo klaidos neišvengiamai lemia neteisingą sistemos konfigūraciją ir modifikavimą, todėl projektavimo etapas yra toks svarbus. Vadovaujantis projektiniais sprendimais, kūrimo specifikacijomis ir vaidmenų bei galių samprata, sistema diegiama, atitinkamai parengiami atliekamų nustatymų aprašymai, specifikacijų techninis įgyvendinimas ir vaidmenų bei galių nustatymai. Į nustatymų aprašą neįtrauktas operacijas CIS specialistai turi įvesti rankiniu būdu. Todėl tokių operacijų aprašymas yra perėjimo prie sistemos naudojimo instrukcijose, kurios nuoroda yra atitinkamoje koncepcijoje.

Pagal duomenų migracijos koncepciją šiame etape buvo parengti ir įgyvendinti projektiniai sprendiniai CIS. Čia taip pat rengiamos instrukcijos, kuriose aprašomos duomenų įkėlimo ir stebėjimo procedūros, taip pat pateikiami šablonų įkėlimo pavyzdžiai. Sukonfigūruota ir modifikuota sistema naudojama vidiniam testavimui. Testavimą atlieka NVS specialistai pagal funkcinio testavimo scenarijus. Scenarijuose yra pratimų, atspindinčių projektavimo sprendimų verslo procesus. Funkcinio testavimo tikslas – patikrinti tinkamą veikimą individualios programos. Integracijos testavimas, priešingai nei funkcinis testavimas, leidžia ištirti teisingą programų, dalyvaujančių viename verslo procese, sąveiką.

Integracijos testuose dalyvauja ir NVS specialistai, ir pagrindiniai kliento vartotojai. Funkcinės ir integracijos testavimo klaidos įrašomos į problemų žurnalą, kad vėliau būtų pašalintos. Klaidų skaičius problemų žurnale rodo kliento verslo reikalavimų supratimo gilumą. Jei žurnale taip pat yra didelis skaičius kritinių pastabų, yra didelė projekto sustabdymo tikimybė (kadangi komentarai turi būti pašalinti prieš AAP etapą).

2.4. Pasirengimo bandomajam-pramoniniam darbui etapas

Sistemos diegimas baigtas, o problemų žurnale yra nedaug komentarų. Prasideda pasiruošimas OPE. Pagrindinis šio etapo tikslas – šviesti galutinius vartotojus. Parengiamos instrukcijos galutiniams vartotojams (verslo procesų ar operacijų kontekste). Toliau, remiantis jais, generuojami vartotojų mokymo scenarijai ir įtraukiami į galutinį mokymo planą. Siūlomas mokymo planas buvo sukurtas anksčiau mokymo koncepcijos kontekste. Vartotojų mokymas vyksta artimomis realioms sąlygoms. Todėl būtina parengti dalyvių sąrašą ir paskirti jiems realius vaidmenis testo pratimams atlikti. Mokymai yra tam tikras sistemos testavimas, atnaujinant problemų žurnalą.

Toliau analizuojamos mokymų metu gautos pastabos. Tęsti projektą galima, jei problemų žurnale yra pastabų, kurios netrukdo įgyvendinti projektą. Tokiu atveju parengiamas OPE dalyvaujančių vartotojų sąrašas ir priskiriami reikiami vaidmenys. Rengiamas perėjimo prie sistemos naudojimo AAP režimu planas, įskaitant būtinų veiksmų, užtikrinančių MIS veikimą, sąrašą ir jų įgyvendinimo laiką. Konkrečiuose plano žingsniuose pateikiamos nuorodos į operacijas iš perėjimo prie sistemos naudojimo instrukcijų. Duomenų perkėlimo planas panašus į sistemos perėjimo planą, tačiau jame yra nuorodų į perkėlimo instrukcijas. Klientas pateikia duomenų pildymą ir patikrinimą atsisiuntimo šablonuose. Pasirengimo etapas baigiasi vartotojų įkūrimu EPE sistemoje, taip pat pagrindinių ir kintamųjų duomenų migravimu.

2.5. Pilotinio veikimo etapas

Bandomasis testavimas leidžia patikrinti sistemos veikimą atliekant realias verslo operacijas, naudojant ankstesnės sistemos istorinius duomenis. Kintamųjų duomenų įkėlimas pasirengimo EPE etape ribojamas iki vieno laikotarpio. Todėl pirmas dalykas, kurį vartotojai daro sistemoje, yra patikrinti, ar likučiai įkelti teisingai. Tada darbuotojai įveda medžiagų judėjimą ir sąskaitos operacijas pagal pirminius tam tikro laikotarpio dokumentus. Vartotojų komentarai dirbant su sistema įrašomi į problemų žurnalą. EPE etapas baigiasi periodo uždarymu logistikos, apskaitos ir kontrolės moduliuose.

2.6. Perėjimo prie produktyvios veiklos etapas

Sėkmingas EPE etapo užbaigimas leidžia kalbėti apie perėjimą prie PE. Pagrindinė perėjimo sąlyga – pastabų nebuvimas problemų žurnale ir visos projekto dokumentacijos atnaujinimas remiantis pastabų taisymo rezultatais. Panašiai kaip ir ruošiantis VĮ, rengiami sistemos vartotojų sąrašai, perėjimo prie VP planai ir duomenų migracija. Užpildomi duomenų atsisiuntimo šablonai. Sukūrus vartotojus NVS, atlikus visas operacijas nuo perėjimo plano ir duomenų perkėlimo, prasideda darbas PE režimu. Nuo šio momento visas iškilusias pastabas ar problemas sprendžia klientų aptarnavimo komanda. Diegimo, pasirengimo eksploataciniam ir pramoniniam bandymui etapuose sistemos klaidos buvo fiksuojamos problemų žurnale ir rangovo specialistai ištaisė.

3. Rengiamų dokumentų priklausomybė nuo projekto etapų

Projektavimo dokumentus užsakovas tvirtina projektavimo etape. Vėliau diegimo, paruošimo AAP ir AAP etapuose kliento pastabos apie įdiegtą sistemos prototipą atsispindi problemų žurnale. Problemų žurnalo komentarų taisymas susideda iš dokumentų atnaujinimo ir pakartotinio patvirtinimo bei papildomos sistemos konfigūracijos ir demonstravimo klientui. Toliau pateiktame paveikslėlyje parodytas projektavimo, mokymo, sistemos perėjimo ir duomenų perkėlimo procesų dokumentų srautas (4 pav.). Tarkime, remiantis mokymų rezultatais, paaiškėjo, kad vienas iš mokymų scenarijų prieštarauja reikalavimams. Kokios pasekmės?

Ryžiai. 4.

Pirma, beveik visi dokumentai gali būti keičiami – nuo ​​dizaino sprendimų iki galutinio vartotojo mokymo scenarijų. Antra, būtina koreguoti ir dokumentus dėl perėjimo prie CIS naudojimo, ir apie duomenų migraciją. Galiausiai, trečia, iš naujo apmokykite galutinius vartotojus. Tokios didelės darbo sąnaudos atsiranda dėl to, kad, viena vertus, projektavimo, mokymo, perėjimo prie sistemos ir perėjimo procesai yra glaudžiai tarpusavyje susiję, kita vertus, kuo vėliau suformuluojami komentarai, tuo sunkiau ir brangu juos pašalinti. Štai kodėl projektavimo sprendimų kokybė lemia NVS diegimo sėkmę.

Rezultatai ir išvados

Pagrindiniai darbo rezultatai yra MIS diegimo metodikų svarstymas, tipinių sistemų diegimo etapų nustatymas, projektinės dokumentacijos peržiūra ir dokumentų priklausomybė nuo projekto etapų. IS diegimo metodikų analizė leido identifikuoti projektų rengimo, projektavimo, įgyvendinimo, pasirengimo AAP, AAP ir perėjimo prie AAP fazes, kurios būdingos nepriklausomai nuo pasirinkto standarto ar projekto valdymo metodikos. Projektinės dokumentacijos aprašymas sudaromas kiekvienam tipiniam CIS diegimo etapui ir aiškiai pateikiamas kaskadinės diagramos pavidalu (3 pav.). Duota Trumpas aprašymas dokumentus ir jų rengimo tvarką. Pagrindinis akcentas – dokumentų paskirtis, o ne jų turinys.

Parodyta dokumentų priklausomybė nuo projekto etapų. Kaip parodyta paveikslėlyje, dėl nedidelio vieno dokumento pakeitimo reikia atnaujinti dokumentus, naudotus rengiant originalą (4 pav.). Tai žymiai padidina darbo intensyvumą. Išsamus tipinių darbų aprašymas kiekviename projekto etape, projekto dokumentacijos analizė ir pagrindinių dokumentų turinio reikalavimų nustatymas taip pat lemia perspektyvią tolesnių tyrimų kryptį.

Literatūra

1. GOST R 54869-2011. Projektų valdymas. Projekto valdymo reikalavimai. – M.: Standartinform, 2011. – 10 p.
2. Zandhuis A., Stellingwerf R. ISO 21500. Projektų valdymo gairės. Kišeninis vadovas. – NL.: Van Haren Publishing, 2013. – 148 p.
3. ANSI/PMI 99-001-2014. Projektų valdymo žinių įstaigos vadovas (PMBOK vadovas). – Pensilvanas.: Projektų valdymo institutas, 2013 – 589 p.
4. Prekės ženklas H. SAP R/3 diegimas naudojant ASAP: oficialus SAP vadovas. – NJ.: Sybex Inc, 1999. – 591 p.
5. Kress R. IT valdymas kaip verslas: nuoseklus „Accenture“ vidaus IT vadovas – Ely: IT valdymo leidyba, 2012. – 140 p.
6. Shankar C., Bellefroid V. Microsoft Dynamics Sure Step 2010. – Birmingham: Packt Publishing, 2011. – 360 p.
7. Informacinių sistemų projektavimas: pamoka/ Gvozdeva T.V., Ballod B.A. – Rostovas n/d.: Feniksas, 2009. – 508 p.
8. Kovaliovas S., Kovaliovas V. Paslaptys sėkmingų įmonių: verslo procesai ir organizacinė struktūra. – M.: BITEK, 2012. – 498 p.
9. Stepanovas D. Ju. Logistikos verslo procesų apžvalga, naudojant įmonės pirkimo veiklos pavyzdį // Logistika šiandien. – 2014. – 65 t., Nr.5. – p.208-228.
10. Stepanovas D. Ju. Universalių reikalavimų vartotojų programoms formavimas rengiant ABAP kūrimo specifikacijas // Šiuolaikinio mokslo aktualijos. – 2014. – 78 t., 4 nr. – p.258-268.

Įgyvendinimas

Sunku duoti patarimų, kaip įdiegti modulio kodą, nes kiekvienas kūrėjas turi tam tikrų įpročių ir savo kodo kūrimo stilių. Įgyvendinant projektą svarbu koordinuoti kūrimo komandą (-as). Visiems kūrėjams taikomos griežtos šaltinio testo kontrolės taisyklės. Kūrimo komanda, gavusi techninį projektą, pradeda koduoti modulius, o šiuo atveju pagrindinė užduotis yra suprasti specifikaciją. Dizaineris nurodo, ką reikia padaryti, o kūrėjas – kaip tai padaryti.

Kūrimo etape glaudžiai sąveikauja dizaineriai, kūrėjai ir bandymų komandos. Intensyvaus kūrimo atveju testeris tiesiogine to žodžio prasme yra „pririštas“ prie kūrėjo, iš tikrųjų jis yra kūrimo komandos narys.

Dizaineris šiame etape veikia kaip „vaikščiojantis žinynas“, nes nuolat atsako į kūrėjų klausimus dėl techninės specifikacijos.

Dažniausiai vartotojo sąsajos keičiasi kūrimo etape. Taip yra, be kita ko, dėl to, kad moduliai periodiškai demonstruojami klientui. Duomenų užklausos taip pat gali labai pasikeisti.

Reikėtų pažymėti, kad visam projektui surinkti turi būti skirta darbo vieta. Būtent šie moduliai siunčiami testavimui. Bandytojo ir kūrėjo sąveika be centralizuoto projekto dalių perdavimo yra priimtina, tačiau tik tuo atveju, jei būtina skubiai patikrinti kokį nors pakeitimą. Labai dažnai kūrimo etapas ir testavimo etapas yra tarpusavyje susiję ir vyksta lygiagrečiai. Klaidų sekimo sistema sinchronizuoja testuotojų ir kūrėjų veiksmus.

Kūrimo metu turėtų būti organizuojamos nuolat atnaujinamos paruoštų projektų modulių saugyklos ir bibliotekos, kurios naudojamos renkant modulius. Patartina, kad saugyklos atnaujinimo procesą valdytų vienas asmuo. Viena iš saugyklų turėtų būti skirta moduliams, kurie išlaikė funkcinį testavimą, o kita - moduliams, kurie praėjo ryšio testavimą. Pirmasis iš jų yra juodraščiai. Antrasis yra kažkas, iš kurio jau galima surinkti sistemos paskirstymo komplektą ir pademonstruoti jį klientui atliekant kontrolinius testus ar pereinant bet kokius darbo etapus.

Dokumentacija kuriama viso kūrimo proceso metu. Kai modulis išlaiko saito testavimą, jį galima aprašyti dokumentacijoje. Jei moduliai keičiasi dažnai, aprašymas pradedamas tik tada, kai modulis tampa daugiau ar mažiau stabilus.

Projektavimo rezultatų apdorojimas

Kūrimo etape, kaip taisyklė, dar kartą patikrinamas funkcijų atomiškumas, taip pat ar dubliavimosi nebuvimas.

Pageidautina, kad projektavimo etape jau būtų sukurta „funkcinio objekto“ matrica. Iš esmės tai formalizuotas atvaizdavimas to, ką įmonė bando daryti (funkcijas) ir kokią informaciją reikia apdoroti, kad būtų pasiektas rezultatas (subjektas). Tokia matrica leidžia patikrinti šiuos taškus:

• ar kiekviena esybė turi konstruktorių – funkciją, kuri sukuria objekto egzempliorius (create);
• ar yra kokių nors nuorodų į šį subjektą, tai yra, ar šis subjektas kur nors naudojamas (nuorodos);
• ar yra šio subjekto pakeitimų (atnaujinimas);
• ar kiekvienas subjektas turi destruktorių – funkciją, kuri ištrina objekto egzempliorius (delete).

Dažnai naikintojo vaidmenį atlieka duomenų archyvavimo programų rinkinys. Dažnai informacinėse sistemose informacija tiesiog kaupiama. Tai leistina tik tuo atveju, jei per visą informacijos kaupimo laikotarpį (ir, tiesą sakant, per visą informacinės sistemos gyvavimo laiką), jos veikimo charakteristikos tenkina kliento reikalavimus. Praktiškai tai itin retas sutapimas. Tai daugiausia lemia apdorotos informacijos kiekio augimas. Reikėtų pažymėti, kad šiuo atveju negalima pasikliauti tik DBVS ar aparatinės įrangos galia, nes tokie platūs produktyvumo didinimo metodai suteikia mažą numatomą greičio padidėjimą. Tiesą sakant, labiausiai tikėtina testavimo užduotis yra reaguoti į sistemą ar atskiras jos dalis į apdorojamų duomenų kiekio padidėjimą. Šiuo atveju testavimo grupė sukuria modulį (net abstrakčiams) duomenims generuoti, parenka užklausų rinkinį, kurio greičio charakteristikos yra kritinės, tada atlieka matavimus ir nubraižo vykdymo greičio priklausomybę nuo kiekvienos užklausos duomenų kiekio. . Toks paprastas veiksmas leis išvengti rimtų klaidų tiek kuriant, tiek diegiant informacinę sistemą.

Modulių specifikacija turi būti baigta projektavimo stadijoje, kuri realiuose projektuose dažnai tiesiog nesuteikiama reikšmės. Ir veltui – nes dėl neapgalvoto modulių diegimo gali būti prarasti bet kokie duomenų bazės schemos privalumai. Taigi, nepaisydami modulio specifikacijų, rizikuojate į informacinę sistemą įtraukti:

• nekontroliuojamas duomenų apimčių augimas;
• užklausų gijos, turinčios iš esmės didelę konflikto tikimybę, arba užklausų gijos, kurios vyks „amžinai“ (bandyti vykdyti giją, aptikti konfliktą ir atšaukti visus veiksmus, bandyti dar kartą ir pan.) dėl su jomis prieštaraujančių gijų;
• maišymo sistemos ir sąsajos moduliai;
• modulių dubliavimas;
• verslo logikos išdėstymo klaidos;
• užsakovui reikalingų sistemos funkcijų neįdiegimas arba nevisas įgyvendinimas.

Tai nėra visas sąrašas problemų, kurios bus aptiktos tiek visapusiško testavimo etape, tiek paleidžiant sistemą, o gal net ir sistemos veikimo metu (kai moduliai iš tikrųjų pradedami naudoti).

Be to, modulio specifikacijų nebuvimas neleis tiksliai įvertinti kiekvieno modulio sudėtingumo ir dėl to nustatyti modulio kūrimo sekos bei teisingai paskirstyti darbuotojų krūvį. Įprasta situacija tokiu atveju yra „kažkas kažko laukia“, o informacinės sistemos kūrimo procesas stovi vietoje.

Sistemos moduliai

Dažnai turime apsvarstyti didelis skaičius paslaugų ar palaikymo procesai, kurie nėra tiesiogiai susiję su apibrėžta verslo funkcija. Paprastai tai yra sistemos funkcijos, esančios bet kurioje informacinėje sistemoje, pavyzdžiui:

• eilių tvarkyklė arba užduočių planuoklė;
• spausdinimo tvarkyklė;
• įrankiai, skirti prieiti prie duomenų ir kurti ad hoc užklausas (dažnai tai yra ataskaitų generatoriai);
• tvarkyti katalogus ir kitus failų sistemos išteklius;
• automatinė atsarginė kopija;
• automatinis atkūrimas po sistemos gedimo;
• priemonės vartotojų prieigai prie sistemos reguliuoti (sudarytos iš vartotojų kūrimo priemonių ir privilegijų jiems suteikimo priemonės);
• informacinės sistemos vartotojo aplinkos nustatymo įrankis;
• priemonė vartotojui pakeisti savo nustatymus (įskaitant slaptažodį);
• programų valdymo įrankis;
• informacinės sistemos administratoriaus aplinka.

Kai kurias iš šių funkcijų turi atlikti operacinė sistema, tačiau jei ji veikia nevienalytėje aplinkoje, nėra garantijos, kad vartotojams patiks skirtingos sąsajos skirtingose ​​operacinėse sistemose. Idealiu atveju visos kliento programos turėtų veikti toje pačioje operacinėje sistemoje, tačiau praktikoje kūrėjams dažnai tenka susidurti su visu „zoologijos sodu“ su įvairiomis kliento darbo vietomis - tai yra kelių bandymų automatizuoti verslą rezultatas. Kūrėjo tikslas – kad sistema būtų kuo homogeniškesnė arba bent jau galutinio vartotojo darbo vietos būtų panašios.

Užduotis sukurti informacinę sistemą heterogeninėje aplinkoje žymiai padidina reikalavimus kodo kūrėjams ir pasirinktam kūrimo įrankiui. Tai ypač pasakytina apie sistemos modulių kūrimą. Reikėtų atkreipti dėmesį į modulius, nuo kurių priklauso kodo įgyvendinimas Operacinė sistema. Tokie moduliai turi būti paskirstyti atskirai kiekvienai operacinei sistemai į grupes, pavyzdžiui, Win98, WinNT ir kt. Kiekvienos grupės moduliai turi turėti griežtas mainų sąsajas – jų perduodami ir priimami duomenys yra griežtai apibrėžti, o už bet kokį nukrypimą nuo specifikacijos yra baudžiama. Nė vienas iš šios grupės ribų esančių modulių negali naudoti jokių kitų skambučių, išskyrus mainų sąsajas. Tokiu būdu moduliai, kurie priklauso nuo operacinės sistemos, yra izoliuojami nuo kitų modulių.

Paprastai tariant, sistemos modulių izoliavimo praktika griežtai reguliuojant jų ryšio sąsajas žymiai sumažina klaidų taisymo ir sistemos palaikymo išlaidas. Be to, tai palengvina testavimą, ty klaidų aptikimą ir derinimą. Kita problemos pusė ta, kad reikalavimai sistemos modulio mainų sąsajos kodui smarkiai didėja. Tai pirmiausia derinama ir turėtų veikti labai aiškiai.

Informacinės sistemos stebėjimo priemonės

Jei informacinė sistema yra didelė, tuomet turėtumėte apsvarstyti užduotį ją administruoti iš vienos darbo vietos. Būtina pasirūpinti ne tik galutiniu informacinės sistemos vartotoju, bet ir ją aptarnausiančiu personalu. Ypatingas dėmesys turėtų būti skiriamas kritinėms informacinės sistemos sritims stebėti, nes gedimo dažnai lengviau išvengti nei ištaisyti jo pasekmes. Stebėjimas reiškia tas užduotis, kurių klientas, kaip taisyklė, negalvoja apie būtinybę išspręsti ir kurių paprastai nėra analitiniame tyrime ir net projektuojant. Stebėjimo priemonių poreikis išryškėja tik sistemos paleidimo etape, o šis poreikis yra didesnis, kuo sudėtingesnė sistema ir tuo joje yra daugiau kritinių skyrių.

Kūrėjai ir dizaineriai turėtų įvertinti sistemos sudėtingumą. Jei priimamas sprendimas parašyti visapusišką administravimo ir stebėjimo priemonę, kuri nenumatyta techninėse specifikacijose, tokiu atveju techninės specifikacijos turėtų būti keičiamos, o ne sekti užsakovo pavyzdžiu. Sudėtingoje sistemoje vis tiek turėsite stebėti svarbius procesus. Labai sunku tokius įrankius įdiegti į paruoštą sistemą, nes monitoriai dažnai gauna pradinius duomenis iš gana žemo lygio sistemos modulių. Taip pat mažai tikėtina, kad tai būtų įmanoma nepakeitus duomenų bazės schemos, ir nėra garantijos, kad toks pakeitimas nepablogins sistemos našumo.

Monitorių kūrimas yra gana specifinė užduočių klasė: viena vertus, jie turi apdoroti pakankamą kiekį informacijos, kita vertus, neturi reikšmingos įtakos kitų informacinės sistemos komponentų veikimui. Tai verčia kūrėjus būti ypač atidiems kuriant monitorius ir labai kruopščiai rašant savo modulių kodą.

Sąsajos

Galutinio vartotojo sąsajas klientas kritikuoja daugiausiai dėl to, kad būtent šias informacinės sistemos dalis jis gali daugiau ar mažiau kompetentingai įvertinti – dažniausiai tik jas mato. Tai reiškia, kad sąsajos yra dažniausiai keičiamas informacinės sistemos elementas diegimo etape.

Dažnai keičiamas (-i) informacinės sistemos komponentas (-ai) turi būti izoliuotas (-i) nuo retai keičiamų komponentų, kad kai kurie pakeitimai neapimtų kitų. Vienas iš tokio atskyrimo būdų yra duomenų užklausų izoliavimas iš sąsajos taip:

• kiekviena užklausa yra užkoduota identifikatoriumi arba „uždaroma“ konkrečios sistemos funkcijos;
• sąsajos kūrėjas nieko nežino apie duomenų užklausą, išskyrus pasirinkimo atributų parametrus – jų tipą ir, galbūt, eilučių skaičių pasirinkime;
• klaidų tvarkymas duomenų užklausose yra atskiras modulis;
• klaidų tvarkymas interpretuojant užklausos rezultatą taip pat yra atskiras modulis.

Apdorojant duomenų užklausų rezultatus taip pat turėtumėte Ypatingas dėmesys atkreipkite dėmesį į pagrindinės kalbos ir DBVS tipų atitikimo klausimus, įskaitant skaičių tipų tikslumo klausimus, nes jų atvaizdavimas skirtingose ​​DBVS labai skiriasi. Taip pat atkreipkite dėmesį į duomenų užklausas, kuriose naudojamos konkrečiai operacinei sistemai būdingos funkcijos, pvz., atributo reikšmės baitų ir žodžių funkcijos (pavyzdžiui, šios funkcijos „Intel“ ir „SUN SPARC“ veiks skirtingai). Duomenų tipus galima tiesiogiai perduoti užklausoje naudojant perdavimo funkcijas ir DBVS integruotas funkcijas arba taikomosios programos funkcijas. Ne visoms DBVS numanomas tipo konvertavimas duoda tą patį rezultatą, todėl jei informacinė sistema naudoja duomenis iš kelių duomenų bazių, valdomų skirtingų DBVS, tuomet geriau vengti numanomų tipų konvertavimo.

Taip pat turėtumėte nustatyti gana griežtas vartotojo sąsajų išvaizdos taisykles. Visiems informacinės sistemos komponentams turėtų susidaryti vieno stiliaus įspūdis.

Duomenų bazės versijos

Daugeliu atvejų pirmoji projekto duomenų bazės versija sukuriama gana greitai - tai yra visiškai normalizuotos struktūros įgyvendinimas, kuris gaunamas analizės etape. Pagrindinis šios duomenų bazės tikslas – teikti prototipų kūrimą, demonstracijas ir kai kuriuos kūrėjų bei dizainerių eksperimentus.

Duomenų bazės kūrimo ir jos užpildymo pradžios duomenimis scenarijai taip pat yra informacinės sistemos šaltinio kodas, jam taikomos versijų valdymo taisyklės. Pažymėtina, kad duomenų bazės versijas prižiūrėti scenarijaus lygiu vis dar lengviau nei pačios DBVS teikiamų duomenų iškrovimo ir įkėlimo įrankių lygmenyje, nes daugeliu atvejų tokie įrankiai negali atlikti kelių paprastų, bet būtinų funkcijų:

• kontroliuoti, kokie duomenų objektai ir duomenys vyksta įkeliant objektus A ir B, ir įkelti į duomenų bazę tik A ir B „skirtumą“ (atlikti versijos atnaujinimą);
• patikrinkite, ar įkėlimo objektuose C ir D vykstantys pakeitimai neprieštarauja, palyginti su įkėlimo objektu A (sujungti versijas).

CASE įrankiai turi duomenų bazės schemos versijos valdymą, o kai kurie turi nustatymus, leidžiančius valdyti paleisties duomenis. Tai leidžia naudoti šiuos įrankius duomenų bazės versijos valdymui.

Patikimiau valdyti trigerių ir saugomų procedūrų šaltinio kodo versijas naudojant tą pačią versijų valdymo sistemą, kuri pritaikyta saugoti paties projekto šaltinio kodą.

Apdorojimo logikos išdėstymas

Vienas iš svarbių projektavimo klausimų yra verslo logikos išdėstymas duomenų apdorojimui: patalpinti jį (ir kokią dalį) serveryje saugomų procedūrų, paketų, trigerių, kitų vientisumo apribojimų pavidalu tiesiai duomenų bazės serveryje arba kliento funkcijų forma (kliento programinėje įrangoje). Sąsajos taisyklių ir duomenų taisyklių vieta yra tiksliai nurodyta: pirmosios visada yra kliente, antrosios - serveryje. Verslo logikos taisyklės šiuolaikinėse DBVS gali būti pateikiamos ir kliente, ir serveryje. Pažvelkime į vieną paprastos verslo taisyklės pavyzdį:

• Reikšmę rodymo lauke įveda vartotojas, o ne pasirenka iš sąrašo, tačiau galiojančių reikšmių rinkinys yra griežtai ribojamas (pavyzdžiui, dvi ar trys skirtingos reikšmės).

Viena vertus, vartotojas reikalauja nedelsiant iš sistemos reaguoti į duomenų įvedimo klaidą, kita vertus, duomenų bazės lauko reikšmės, kurios skiriasi nuo nurodytų (dvi ar trys), yra nepriimtinos. Iš tikrųjų šioje situacijoje reikia laikytis dviejų taisyklių. Duomenų taisyklė šiuo atveju bus organizuota patikrinimo apribojimo forma, o sąsajos taisyklė, kuri draudžia įvesti kitas reikšmes nei nurodytos, tiksliai pakartos duomenų taisyklę, bet bus įgyvendinta vartotojo sąsajos lygiu. Atrodytų, kad formos su sąrašu įgyvendinimas šiuo atveju yra idealus sprendimas, tačiau dauguma operatorių renkasi tipą formoje, ypač jei įvesties reikšmės ilgis yra mažas. Formas su daugybe sąrašų galutiniams vartotojams gana sunku apdoroti. Jei formoje yra reikšmių rinkinys, programos sąsajos lygiu taip pat reikia pasirūpinti, kad simbolių eilučių didžiosios ir mažosios raidės (kai didžiosios ir mažosios raidės nėra reikšmingos) būtų konvertuojamos į didžiąsias arba mažąsias raides.

Šablonai

Šablonų ir bibliotekų naudojimas kuriant „panašius“ modulius yra gana įprasta praktika. Ką šiuo atveju naudoti – objektus ir klases ar bibliotekas – sprendžia konkreti kūrėjų grupė. Daugeliu atvejų diktuoti kūrimo metodą yra beprasmiška, nes kūrėjas kodą rašo taip, kaip išmano ar yra įpratęs. Šiuos momentus dažniausiai kontroliuoja projekto vadovas.

Bet kuriame projekte kodo kopijavimas yra draudžiamas, nes dėl to skirtinguose programos fragmentuose atsiranda skirtingų to paties kodo versijų ir dėl to atsiranda klaidų, kurias sunku aptikti ir ištaisyti. Reikėtų nustatyti griežtą taisyklę: naudojamas funkcijos iškvietimas, o ne jo kopija kode; už bet kokį nukrypimą nuo šios taisyklės baudžiama.

Testavimas

Kaip minėta aukščiau, testavimo grupes galima įtraukti jau ankstyvosiose projekto kūrimo stadijose. Pats išsamus testavimas tikrai turėtų būti atskirtas į atskirą kūrimo etapą. Atsižvelgiant į projekto sudėtingumą, testavimas ir klaidų taisymas gali užtrukti trečdalį, pusę ar daugiau viso projekto kūrimo laiko.

Kaip sudėtingesnis projektas, tuo didesnis klaidų saugojimo sistemos automatizavimo poreikis – klaidų sekimas. Tokia sistema atlieka šias funkcijas:

• klaidos pranešimo saugojimas (su privaloma informacija apie tai, su kuriuo sistemos komponentu susijusi klaida, kas ją rado, kaip ją atkurti, kas atsakingas už jos ištaisymą ir kada ji turėtų būti ištaisyta);
• pranešimų sistema apie naujų klaidų atsiradimą, apie žinomų klaidų būsenos pasikeitimus sistemoje (paprastai tai yra pranešimai el. paštu);
• ataskaitos apie esamas klaidas pagal sistemos komponentus, laiko intervalus, pagal kūrimo grupes ir kūrėjus;
• informacija apie klaidos istoriją (įskaitant panašių klaidų sekimą, klaidos pasikartojimo sekimą);
• prieigos prie tam tikrų kategorijų klaidų taisyklės;
• ribotos prieigos prie klaidų sekimo sistemos sąsaja galutiniam informacinės sistemos vartotojui, kuri naudojama kaip sąsaja keistis informacija tarp vartotojo ir paslaugos Techninė pagalba sistemos.

Tokios sistemos pašalina daugybę organizacinių problemų, ypač automatinio pranešimo apie klaidas klausimą.

Patys sistemos testai gali būti suskirstyti į kelias kategorijas:

• autonominių modulių testai – naudojami jau sistemos komponentų kūrimo stadijoje ir leidžia sekti atskirų komponentų klaidas;
• sistemos komponentų prijungimo testai – naudojami tiek kūrimo, tiek testavimo stadijoje ir leidžia stebėti teisingą sąveiką bei keitimąsi informacija tarp sistemos komponentų;
• sistemos testas yra pagrindinis sistemos priėmimo kriterijus. Paprastai tai yra testų grupė, apimanti autonominius testus ir ryšio testus bei modelius. Šis testas turi atkartoti visų sistemos komponentų ir funkcijų veikimą, pagrindinis jo tikslas – vidinis sistemos priėmimas ir jos kokybės įvertinimas;
• priėmimo testas – naudojamas perduodant sistemą klientui. Čia kūrėjai dažnai sumažina sistemos reikalavimus, palyginti su sistemos testu, ir apskritai aišku, kodėl tai pateisinama;
• našumo ir apkrovos testai yra įtraukti į sistemos testą, tačiau yra verti ypatingo dėmesio, nes ši testų grupė yra pagrindinė sistemos patikimumui įvertinti.

Kiekvienos grupės bandymai būtinai apima gedimų modeliavimo testus. Čia tikrinama komponento, komponentų grupės ar visos sistemos reakcija į tokio tipo gedimus:

• atskiro informacinės sistemos komponento gedimas;
• informacinės sistemos komponentų grupės gedimas;
• informacinės sistemos pagrindinių modulių gedimas;
• operacinės sistemos gedimas;
• „kietas“ gedimas (maitinimo sutrikimas, standžiojo disko gedimas).

Šie testai leidžia įvertinti teisingos informacinės sistemos būklės atkūrimo posistemio kokybę ir yra pagrindinis informacijos šaltinis kuriant strategijas, skirtas užkirsti kelią neigiamoms gedimų pasekmėms pramoninės veiklos metu. Paprastai tai yra testų klasė, į kurią kūrėjai nepaiso ir vėliau kovoja su gamybos sistemos gedimų pasekmėmis.

Kitas svarbus informacinių sistemų testavimo programos momentas yra testavimo duomenų generatorių prieinamumas. Jie naudojami tiek sistemos funkcionalumo, tiek patikimumo, tiek sistemos veikimo testams atlikti. Užduotis įvertinti informacinės sistemos veikimo priklausomybės nuo apdorojamos informacijos apimčių augimo charakteristikas negali būti išspręsta be duomenų generatorių.

Eksploatavimas ir priežiūra

kankinimo išnaudojimas viršija bandymo procesą. Paprastai sistema nėra visiškai pradėta eksploatuoti palaipsniui.

Eksploatacijos pradžia vyksta mažiausiai trimis etapais:

informacijos kaupimas;

pasiekti projektinius pajėgumus.

Pradinis informacijos įkėlimas inicijuoja gana siaurą klaidų spektrą - daugiausia tai yra duomenų nesutapimo problemos įkėlimo metu ir pačių krovėjų klaidos, ty tai, kas nebuvo atsekta bandymo duomenyse. Tokios klaidos turi būti kuo greičiau ištaisytos. Nepatingėkite įdiegti derinimo sistemos versiją (jei, žinoma, jums leidžiama įdiegti visą programinės įrangos kompleksą, kuris lydi informacinės sistemos derinimą vietoje). Jei neįmanoma derinti „tiesių“ duomenų, turėsite imituoti situaciją ir greitai. Tam reikia labai kvalifikuotų testuotojų.

Informacijos kaupimo laikotarpiu atsiras daugiausia klaidų, padarytų kuriant informacinę sistemą. Paprastai tai yra klaidos, susijusios su kelių vartotojų prieiga. Dažnai bandymo etape tokioms klaidoms nekreipiamas deramas dėmesys – matyt dėl ​​modeliavimo sudėtingumo ir didelių procesų automatizavimo įrankių kainos. testavimas informacinė sistema kelių vartotojų prieigos sąlygomis. Kai kurias klaidas bus gana sunku ištaisyti, nes tai yra projektavimo klaidos. Nuo jų neapsaugotas nei vienas geras projektas. Tai reiškia, kad tik tuo atveju turite skirti laiko tokioms klaidoms lokalizuoti ir taisyti.

Informacijos kaupimo laikotarpiu galite susidurti su garsiuoju „bazė nukrito“. Blogiausiu atveju paaiškėja, kad DBVS negali atlaikyti informacijos srauto. Jei tai gerai, konfigūracijos parametrai yra tiesiog neteisingi. Pirmasis atvejis yra pavojingas, nes gana sunku paveikti DBVS gamintoją, o klientui labai nepatinka nuorodos į DBVS techninės pagalbos tarnybą. Ne gamintojas turės išspręsti DBVS gedimo problemą, o jūs - keiskite schemą, sumažinkite užklausų srautą, keiskite pačias užklausas; apskritai - yra daug variantų. Gerai, jei bazinis atsigavimo laikas atitinka suplanuotą.

Sistemos projektavimo pajėgumo pasiekimas esant sėkmingam aplinkybių deriniui reiškia ištaisyti keletą nedidelių klaidų, o kartais ir rimtų klaidų.

Kiti taikomųjų programų kūrimo būdai

Paprastai galutiniai vartotojai ir vadovybė mano, kad projektavimo procesas nedavė jokių rezultatų, nes nėra paruoštų komponentų, kuriuos būtų galima „paliesti“. Dažnai klientas primygtinai reikalauja projekto įgyvendinimo etapą atlikti anksčiau laiko, kad gautų kokį nors rezultatą ir kuo greičiau jį parodytų. Šiuo atveju labai vilioja rinktis pagreitintą programų kūrimą (AAD) arba bendradarbiaujantį taikomųjų programų kūrimą (CAD). Tokie metodai apima veikiančio prototipo kūrimą ir demonstravimą vartotojams. Vartotojai komentuoja, kas jiems patinka, o kas ne. Dizaineris patobulina prototipą, atsižvelgdamas į pastabas, o tada vėl parodo, kas atsitiko. Ir taip toliau. Procesas kartojamas tol, kol naudotojams patinka tai, ką jie mato, ir prototipas tampa veikiančia programa. Paprastai yra laiko limitas ir pakartojimų skaičius, kitaip vartotojai amžiams tobulins prototipą. Teoriškai tai leidžia jums gauti naudotojams reikalingą sistemą. Praktiškai toks požiūris į programų kūrimą kelia rimtų problemų.

• Visas dėmesys sutelktas į ekrano formas, o tai, kas liečia duomenų tvarkymo taisykles ir sistemos funkcijas, lieka už kadro. Kyla pagunda pradėti dirbti su ataskaitomis, o ataskaita yra ne pradinis produktas, o išvestinis informacinės sistemos produktas.
• Vartotojai mano, kad jei susitarta dėl prototipo versijos, modulis yra paruoštas. Tiesą sakant, tai gali būti tik paveikslėlis su „stubų“ rinkiniu, skirtu iškviesti sistemos funkcijas ir sąveikauti su kitais moduliais.
• Moduliai kuriami atskirai vienas nuo kito (tikriausiai daugelis esate susidūrę su apskaitos programomis, kuriose kiekviena darbo vieta yra savarankiška, o funkcijos dažnai dubliuojasi). To pasekmė – prieštaravimai tarp modulių, funkcijų ir duomenų dubliavimasis, kuriuos galima nustatyti tik testuojant modulių rinkinį.
• Funkcionalumas plečiamas lygiagrečiai keliomis kryptimis, o tai reiškia, kad duomenų bazės struktūra turi būti griežtai kontroliuojama. Naudojant DRM, duomenų bazės schema virsta sąvartynu, kuriame lentelės paskubomis sumetamos, todėl susidaro prieštaringų ir pasikartojančių duomenų rinkinys.
• Dokumentacijos naudojant URP metodą, kaip taisyklė, nėra, tiksliau, pamirštama, kad reikia dokumentuoti sistemą, nes sukuriama iliuzija, kad vartotojas jau supranta, kas vyksta. Kai programa pradeda veikti kitaip, nei tikisi vartotojas, iškyla daug problemų.
• Išimtinės situacijos kiekvienam moduliui sprendžiamos skirtingai.
• Visa sistema, kaip taisyklė, neveikia, greičiausiai tai bus tam tikras automatizuotų darbo vietų rinkinys, skubotai sujungtas.

URP ir SRP metodai ne visada gali būti naudojami, bet tik jei:

• Projekto apimtis ir verslo reikalavimai aiškiai apibrėžti, nesikeičia, o pats projektas nedidelis;
• projektas nepriklauso nuo kitų verslo automatizavimo priemonių, išorinių sąsajų, su kuriomis teks spręsti, skaičius yra ribotas;
• sistema orientuota į ekrano formas, duomenų apdorojimas ir sistemos funkcijos sudaro nereikšmingą dalį, ekrano formų patogumas yra vienas iš penkių svarbiausių projekto sėkmės faktorių;
• vartotojai yra aukštos kvalifikacijos ir a priori teigiamai vertina naujos programinės įrangos kūrimo idėją.

Nepaisant to, geriau kurti mažas ir, pageidautina, savarankiškas projekto dalis naudojant URP metodą.

Šiuo metu bandoma įdiegti dar vieną būdą greitai parašyti projektą – ekstremalų programavimo metodą. Šio požiūrio principai bus aptarti toliau.

Planavimo žaidimas. Remdamasis programuotojų atliktais vertinimais, klientas nustato sistemos versijų funkcionalumą ir diegimo laikotarpį. Programuotojai diegia tik tas funkcijas, kurios būtinos tam tikroje iteracijoje pasirinktoms funkcijoms.

Dėl šio sprendimo sistemos kūrimas lieka „užkulisiuose“, dėl to kūrimo metu reikia statyti „stubus“ ir perrašyti kodą. Neaišku, kodėl įgyvendinimo terminą nustato užsakovas, nes iš tikrųjų tai yra tiesioginė projektuotojų komandos atsakomybė. Užsakovas, paprastai kalbant, gali išreikšti tik savo pageidavimus dėl terminų („noriu iki tokios ir tokios datos“), o tik projektuotojas gali nustatyti terminą („galima padaryti ne trumpiau nei per tokį ir tokį laiką“). laikas").

Dažnas versijų keitimas (maži leidimai). Sistema pradedama eksploatuoti per kelis mėnesius nuo diegimo pradžios, nelaukiant galutinio visų iškeltų problemų sprendimo. Naujos versijos gali būti išleidžiamos intervalais nuo dienos iki mėnesio.

Viskas gerai, išskyrus vieną dalyką: tokiu laikotarpiu neįmanoma išbandyti daugiau ar mažiau sudėtingo komponento. Klientas iš tikrųjų veikia kaip beta versijos testuotojas. Šiuo atveju jis mato, kad kūrėjai sunkiai dirba ir netgi taiso klaidas. Tačiau kyla pagrįstų klausimų: ar verta įvesti klientą į darbo procesą ir ar būtina atlikti eksperimentus darbo sistema? Be to, kas išdėstyta pirmiau, reikėtų pažymėti, kad toks principas greičiausiai nebus įgyvendintas tose projekto dalyse, kurioms reikalingas darbas 24x7.

Metafora. Bendra sistemos išvaizda nustatoma naudojant metaforą arba metaforų rinkinį, kurį klientas ir programuotojai dirba kartu.

Viena vertus, šis postulatas atrodo visai neblogas, bet, kita vertus, ar prasminga inicijuoti klientą į kūrimo grupės vidaus reikalus? Tai, kas liečia bendrą išvaizdą (sąsajas, ataskaitas ir pan.), iš tiesų gali priklausyti užsakovo kompetencijai, bet kai mes kalbame apie apie tam tikrų komponentų diegimo specifiką, klientas vargu ar gali būti naudingas dėl jam reikalingų žinių trūkumo.

Paprastas dizainas. Sukurta sistema kiekvienu laiko momentu atlieka visus testus ir palaiko visus programuotojo apibrėžtus ryšius, neturi kodų dublikatų ir turi minimalų įmanomą klasių ir metodų skaičių. Šią taisyklę galima trumpai išreikšti taip: „Kiekvieną mintį suformuluokite vieną kartą ir tik vieną kartą“.

Ši idėja taip pat gera, bet nelabai atitinka greito kodo rašymo principą. Galbūt pirmiausia reikėtų pagalvoti, kaip padaryti tą ar kitą modulį, modulių grupę ir tik tada pradėti rašyti kodą?

Testai. Programuotojai visą laiką rašo vienetų testus. Kartu šie testai turėtų veikti tinkamai. Iteracijos etapams klientai rašo funkcinius testus, kurie taip pat turi veikti tinkamai. Tačiau praktiškai tai ne visada įmanoma pasiekti. Norint priimti teisingą sprendimą, reikia suprasti, kiek kainuos pristatyti sistemą su žinomu defektu, ir palyginti tai su defekto ištaisymo vilkinimo išlaidomis.

Kai testus rašo patys programuotojai (ypač dirbant viršvalandžius), šie testai nėra visiškai funkcionalūs ir tikrai neatsižvelgia į kelių vartotojų darbo ypatumus. Kūrėjai paprastai neturi pakankamai laiko sudėtingesniems testams. Žinoma, galite sukurti kūrimo sistemą, kad viskuo tvarkytų tie patys žmonės, bet vis tiek neturėtumėte projekto paversti televizijos laidos „Jūsų režisierius“ analogu. Prie to, kas pasakyta, būtina pridurti, kad sistemos testavimas neapsiriboja komponentų (vienetų) testavimu; Jų tarpusavio sąveikos testai yra ne mažiau svarbūs, tas pats pasakytina ir apie patikimumo testus. Nepaisant to, ekstremalus programavimo metodas nenumato šios klasės testų kūrimo. Tai paaiškinama tuo, kad patys tokie testai gali reprezentuoti gana sudėtingą kodą (tai ypač pasakytina apie testus, kurie imituoja tikrą sistemos veikimą). Ši technologija taip pat neatsižvelgia į kitą svarbią testų klasę – sistemos elgsenos testus, kai didėja apdorojamos informacijos apimtis. Esant dideliam versijų keitimo tempui, tokio testo atlikti technologiškai neįmanoma, nes jo įgyvendinimui reikalingas stabilus ir nepakitęs projekto kodas, pavyzdžiui, per savaitę. Tokie terminai, paprastai kalbant, nėra garantuojami dėl dažni pokyčiai versijos. Tokiu atveju turėsite arba sustabdyti komponentų kūrimą, arba bandymo metu sukurti lygiagrečią projekto versiją, kuri išliks nepakitusi, o antroji pasikeis. Tada turėsite atlikti kodų sujungimo procesą. Tačiau tokiu atveju testą teks sukurti dar kartą, nes ekstremalūs programavimo metodai tiesiog nenumato įrankių, leidžiančių numatyti sistemos elgseną esant tam tikriems pokyčiams, kūrimo.

Sistemos pertvarkymas. Sistemos architektūra nuolat tobulinama. Dabartinis projektas yra transformuojamas, tuo pačiu užtikrinant, kad visi testai būtų atlikti teisingai.

Čia ir prasideda linksmybės. Ekstremalus programavimas remiasi prielaida, kad jį visada galima perdaryti ir be didelių išlaidų. Tačiau praktika rodo priešingai.

Porinis programavimas. Visas projekto kodas yra parašytas dviejų žmonių, kurie naudoja tą pačią darbalaukio sistemą.

Kyla klausimas: ar kas nors matė du visiškai vienodus programuotojus, kurių kiekvienas darbo dienos pabaigoje turėtų laiko parašyti dokumentus savo partneriui? Ar įmanoma rasti programuotojų dvynių, kurie dėl visko sutaria?

Ir svarbiausia, kam mums reikalinga tokia programuotojų pora? Priežastis apskritai paprasta: ne visi gali atlaikyti didelį darbo tempą, kurį sukelia ekstremalus programavimas, o personalo nutekėjimas yra neišvengiamas. Tokia pora gali suteikti kažkokį draudimą – jei vienas pasitrauks, tai gal antrasis darbą atliks iki galo. Tiesa, likęs pateks į dar griežtesnį laiko tarpą – juk darbų kiekis išliks toks pat, o atsarginio bent jau kurį laiką nebus. Toliau vyksta natūralus informacijos perdavimo naujam studentui procesas, kuris vėlgi užtrunka. Ir taip be galo.

Nuolatinė integracija. Naujasis kodas integruojamas į esamą sistemą per kelias valandas. Po to sistema vėl surenkama į vieną visumą ir atliekami visi testai. Jei bent vienas iš jų nėra atliktas teisingai, atlikti pakeitimai atšaukiami.

Šis postulatas yra bent jau prieštaringas, nes neaišku, kas ištaisys klaidas, ne tik vietines, bet ir sukeltas Neteisingas kodas. Juk šiame etape nenumatoma atlikti sudėtingų bandymų, be to, pokyčiai išlieka net ir aptikus klaidą. Tuo pačiu metu Extreme Programming metodas nenumato klaidų sekimo sistemos.

Kolektyvinė nuosavybė. Kiekvienas programuotojas turi galimybę bet kuriuo metu patobulinti bet kurią kodo dalį sistemoje, jei mano, kad tai būtina.

Ar tai neprimena anarchijos? Kaip šiuo atveju rasti pakeitimų autorių? Ar kas nors susidūrė su tokiu „visų amatų domkratu“ plėtojant didelį projektą ir kiek ilgai toks „parankinis“ galėtų išsilaikyti savo darbe? Teisingai, ne per ilgai.

Klientas vietoje. Klientas, kuris yra kūrimo komandos dalis darbo su sistema laikotarpiu.

Tai, žinoma, yra gerai, bet tikslas neaiškus: arba supažindinti klientą su reikalo esme, ar padaryti jį bendraautoriu? Vargu ar tik klientas turės tokį aukštos kvalifikacijos specialistą.

40 valandų savaitės. Viršvalandžių darbo trukmė negali viršyti vienos darbo savaitės. Netgi pavieniai per dažnai kartojami viršvalandžių atvejai yra rimtų problemų, į kurias reikia nedelsiant atkreipti dėmesį, požymis.

Kaip rodo ekstremalaus programavimo praktika (nepaisant daugybės teigiamų pavyzdžių, kuriuos pateikia šio metodo šalininkai), viršvalandžiai šiuo požiūriu yra taisyklė, o ne išimtis, o kova su problemomis šiuo atveju yra nuolatinis reiškinys. Jis sustiprėja tuo metu, kai dabartinė neapdorota produkto versija pakeičiama kita, vėlgi neapdorota, versija. Klientas, įtrauktas į procesą, patiria visus sistemos klaidų pasireiškimo malonumus. Kaip manote, ar ilgai klientui užteks kantrybės tokioje situacijoje? Jam reikia, kad sistema veiktų...

Atvira darbo vieta. Kūrimo komanda yra didelėje patalpoje, kurią supa mažesni kambariai. Darbo erdvės centre sumontuoti kompiuteriai, kuriuose dirba programuotojų poros.

Be to, visa tai, remiantis ankstesniais principais, turėtų būti kliento teritorijoje, nes jis labai aktyviai dalyvauja kūrimo procese. Kyla klausimas: ar toks laimingas sutapimas tikras?

Nieko daugiau, kaip tik taisykles. Ekstremaliomis programavimo technologijomis dirbantys komandos nariai įsipareigoja laikytis nurodytų taisyklių. Tačiau tai yra ne kas kita, kaip taisyklės, kurias komanda gali bet kada pakeisti, jei jos nariai iš esmės susitarė dėl atliktų pakeitimų.

Galbūt galiausiai bus sukurta viena naudinga taisyklė: „pirma galvok, tada daryk“. Tokiu atveju turėsime modelį, labai panašų į „krioklį“. Kažkodėl ekstremalaus programavimo šalininkai įsitikinę, kad naudojant „krioklį“ ir jo klonus kūrimo ciklas turi būti ilgas. Kas sukelia tokį pasitikėjimą – neaišku. Juk nedraudžiama projekto skaidyti į etapus. Kažkodėl manoma, kad planavimas būtinai bus vienkartinis ir nekeičiamas, nors iš tikrųjų tai netiesa, taip pat ir „krioklio“ atveju.

Dėl to gauname metodą, kuris gali būti labai pritaikomas prie labai kintančių projekto reikalavimų, tačiau tuo pat metu neturintis rimtų trūkumų. Paskutinė aplinkybė neleidžia rekomenduoti šis metodas skirtas naudoti projektuose, kuriems reikalingas didelis arba bent jau pakankamas veikimo patikimumas.

ComputerPress 2"2002

Nėra nieko sudėtingesnio, pavojingesnio ir neapibrėžtesnio, kaip vadovauti naujos tvarkos įvedimui, nes kiekviena naujovė turi karštų priešų, kurie gerai gyveno po senojo, ir vangų rėmėjų, kurie nėra tikri, ar gali gyventi pagal naująją.
N. Makiavelis

O dabar įdomi ir kupina kūrybos, projekcijų, kūrybos ir kūrybos projekto dalis baigiasi. Prasideda sunkumai ginti savo sprendimą tikroje atmosferoje konkreti įmonė, ir kas taip pat svarbu, viskas taip pat yra galiojančių teisės aktų ribose.

Pradėti parduotas produktas turi būti dislokuota ant įrangos, paruoštos jos bandomajai operacijai organizuoti.

1. Sistemos diegimas bandomosios veiklos vietoje

Pagal suprojektuotą technologinę architektūrą, atsispindinčią dokumentacijoje, perkama serverio, ryšio ir kita įranga bei sisteminė programinė įranga. Informacinės sistemos komponentai surenkami į vientisą techninės ir programinės įrangos kompleksą tose vietose, kur planuojamas jos pramoninis panaudojimas.

Dėl to, kad į didelių projektų, naudojama daug įrangos, kurioje programinė įranga yra išsklaidyta po mazgus, mazgus ir net debesis, tada šis procesas turi būti lydimas visos apimties dokumentacijos. Pavyzdžiui, techninėje dokumentacijoje pateikiamos lentelės su serverių, darbo vietų adresais, prieigos būdais ir kt. Vizualiniam vaizdavimui naudojamos komponentų diagramos, leidžiančios suprasti tinklo mazgų vietą, jų sąveikos komponentų pasiskirstymą ir kt. Tačiau vis dar turi būti nustatytos priemonės, reguliuojančios visus infrastruktūros pokyčius, leidžiančius pašalinti įvairių sistemos elementų gedimų pasekmes.

19 pav. – Diegimo etapo techninio aprašymo pavyzdys

Visa tai be galo svarbu, nes kitame etape šiose veiklos vietose pradės grūstis daug specialistų iš diegimo ir palaikymo komandos ir jiems nereikės kaskart išgauti darbui reikalingos informacijos iš skirtingų, net informuotų šaltinių. . Todėl dokumentacija turi būti nuolat atnaujinama ir keičiama kartu su sistemos nustatymų pasikeitimais, pakeitimais architektūrinis sprendimas ir taip toliau.

Pramoniniam sistemos eksploatavimui naudinga įrengti bandymų stendus „kovinėse“ vietose, imituojant veikimą, artimą realiam gyvenimui. Na, staiga atsiras komentarų, reikalaujančių naujų leidimų. Žinoma, visi yra profesionalai, atsakingi žmonės ir visa kita, bet vis tiek geriau pirmiausia paleisti atnaujinimus bandymų stende. Dėl viso pikto.

Tuo tarpu 90% laiko jau praskriejo...

2. Klientų personalo mokymas dirbti su informacine sistema

Kaip jau ne kartą buvo minėta, dideliuose projektuose ypatingas dėmesys skiriamas dokumentacijos kokybei, įskaitant instrukcijas sistemos naudotojams. Dažniausiai vartotojo instrukcijos skirstomos į segmentus pagal veiklos tipą, specializaciją ir kt. Tai leidžia sutelkti dėmesį dokumente į svarbius dalykus ir neapkrauti vartotojų nereikalinga informacija.

Kadangi mokymuose gali būti įtrauktas didelis skaičius skirtingų klientų darbuotojų, kurie, savo ruožtu, siekiant užtikrinti verslo procesų tęstinumą, negali būti mokomi vienu metu, kurie turi būti apmokyti funkcines pareigas ir kiti dalykai gerų priežasčių, būtina kruopščiai planuoti personalo mokymo procesą. Taip pat naudinga suskirstyti mokinius į grupes pagal kategorijas, kurias reikia naudoti skirtingus požiūrius ir mokymo gylį, atsižvelgiant į jų pradinio pasirengimo lygį. Dėl to sudarytas treniruočių grafikas turi būti suderintas su visais suinteresuotosios šalys, ir užsakovo vadovybės patvirtintas kaip privalomas.

O mes dar projektavimo etape perspėjome, kad klientų personalo mokymas yra ne tik labai svarbi užduotis, bet ir labai daug darbo reikalaujanti...

3. Informacinės sistemos trūkumų ir defektų nustatymas

Labai dažnai dideliuose projektuose galutinio leidimo testavimas neleidžia identifikuoti visų probleminių sprendimo sričių. To priežastis gali būti: didžiuliai duomenų kiekiai realiomis kovos sąlygomis, unikalių verslo taisyklių derinių pasireiškimas realiuose verslo procesuose, konkrečios įrangos veikimo ypatybės, specifiniai sistemos komponentų deriniai, apkrovos balansavimas tarp paskirstytų mazgų ir kt.

Dažnai situaciją dar labiau apsunkina tai, kad naujų sistemų įdiegimas pradiniuose etapuose jokiu būdu nepanaikina poreikio atlikti darbus su senomis sistemomis. Tai reiškia, kad vartotojai dubliuoja duomenis abiejose sistemose. Kartais esamus, naujausius duomenis reikia perkelti iš senų parduotuvių į naujas, o informacijos struktūra ir formatas dažniausiai labai labai skiriasi. Pavyzdžiui, jei naujoje duomenų struktūroje nepakanka informacijos, kad būtų galima užpildyti reikiamus duomenis, jie užpildomi kai kuriais duomenimis, priskirtais „pagal numatytuosius nustatymus“, o vėliau naudotojai juos koreguoja rankiniu būdu. Ir tai tik maža dalis to, su kuo susiduriame realiuose projektuose.

Atskira tema – integraciniai sprendimai, kuriuose gedimai gali atsirasti grandinėje, naudojant įvairius komponentus, sukurtus dviejų, trijų ar daugiau komandų. Rasti kaltininkus šioje situacijoje yra labai sunku, nes trūkumai dažniausiai atsiranda integravimo elementų sandūroje dėl diegimo metu nustatytų neatitikimų. Ir čia svarbu ne ieškoti atsakingų už bausmę, o greitai ir konstruktyviai susitarti dėl bendrų prijungtų komponentų kūrėjų nuolaidų ir efektyviai išspręsti problemą.

Atsižvelgiant į visa tai, kas išdėstyta aukščiau, bandomoji eksploatavimo stadija dažniausiai būna kupina emocinių protrūkių ir abipusių pretenzijų tiek tarp kūrimo komandų, tiek su klientais. Šiuo atveju labai svarbus architektų ir sistemų analitikų vaidmuo, kurie turi greitai lokalizuoti problemą, pasiūlyti sprendimą ir dėl jo susitarti su visomis suinteresuotomis šalimis. Norint atlikti tokį darbą, be pagrindinių profesinių įgūdžių, reikia turėti ir derybininko talentą bei vadybos pagrindų išmanymą.

Tuo tarpu projektui skirto laiko dugną pasiekėme...

4. Pakeitimų derinimas diegiant informacinę sistemą

Jeigu kai kurių informacinės sistemos funkcinių modulių veikimas kritiškai neatitinka užsakovo poreikių ir lūkesčių ir randami sprendimai šioms problemoms įveikti, tuomet jie turi būti užfiksuoti ir suderinti su klientu.

Susitarimo dėl naujo sprendimo etapas yra labai svarbus mažiausiai dėl dviejų priežasčių.

Pirma, jei pakeitimų įgyvendinimo apimtis viršija tam skirtas sumas panašios rizikos kalbant apie projektą, reikia arba sudaryti papildomus susitarimus, arba atlikėjų komanda dirbs nuostolingai. Dažnai atlikėjai raginami greitai atlikti pakeitimus, tačiau jie sako, kad į juos atsižvelgsime ir už darbus sumokėsime vėliau, vienoje pakuotėje. Tačiau iš tikrųjų tokie atvejai dažniausiai priveda prie to, kad užsakovas tuomet visiškai pamiršta savo pažadus, o atliktą darbą paskelbia kaip savo pačių klaidų taisymą.

Antra, bet kokie kai kurių sistemos komponentų pakeitimai gali lemti neišvengiamą tarpusavyje susijusių komponentų pasikeitimą, o tai reikalauja kruopščios analizės ir, galbūt, visos posistemių grandinės perplanavimo. Priešingu atveju visos sistemos veikimo defektų atsiradimas yra neišvengiamas. Tai gali pasireikšti, pavyzdžiui, gretimos atlikėjų komandos modulio gedimu, o užsakovas jau paskelbia juos įsilaužėliais ir defektuotojais. Tiesa, žinoma, išaiškės, bet apgultis išliks.

Ir perfrazuojant Jerzy Lecą: „Kai pasiekėme skirto laiko dugną, pasigirdo beldimas iš apačios...“

Kadangi laikas jau pavėluotas, reikia tartis su užsakovu ir įtikinti, kad jis projekte irgi nebuvo dovana, o dalis kaltės tenka jam pačiam.

5. Informacinės sistemos tobulinimas remiantis bandomosios veiklos rezultatais

Jei bandomosios eksploatacijos metu priimami sprendimai ir susitariama atlikti kuriamo programinės ir techninės įrangos komplekso pakeitimus, tai remiantis jais atliekantiems asmenims paskiriamos užduotys jų įgyvendinimui. Procesas, aprašytas skyriuje 3. Projektinio sprendimo įgyvendinimas, kartojamas. Bet…

Jei sistemos projektavimo etape aptarėme neigiamą visapusiško Scrum metodikos (1) panaudojimo dideliuose projektuose poveikį, tai šiame etape ji puikiai tinka. Tai ypač pastebima projektuose, kuriuose klientui perduotas produktas daugeliu atžvilgių jo netenkina. Kitaip tariant, laikas pasiduoti panikai ir labai greitai, stačia galva, keisti jau naudojamą gaminį.

Tiesą sakant, atėjo momentas, kai yra svarbios šios sąlygos:

1. Klientas jau pradėjo realiai dirbti su sistema, turi tam skirto laiko ir dabar aiškiai supranta, ko jam iš tikrųjų reikia. Atitinkamai, jis yra pasirengęs glaudžiai bendradarbiauti su atlikėjų komanda ir jam tai labai reikia;
2. Dokumentacija didžiąja dalimi jau yra paruošta ir jos keitimai bei papildymai nebegali būti atliekami taip greitai, o po fakto, remiantis sėkmingo įgyvendinimo rezultatais.
3. Patobulinimai dažniausiai vyksta atskiruose moduliuose, posistemėse, grandinėse, kuriose už segmentą atsakinga tam tikra atlikėjų komanda. Todėl komunikacija tarp vartotojų ir kūrėjų jau yra lokalizuota, nesunku užmegzti kokybišką grįžtamąjį ryšį;
4. Tobulinimai ir taisymai turi būti atliekami labai greitai, mažais etapais, o rezultatas perduodamas klientui, kuris jais gyvybiškai domisi;

Labai svarbu, kad galiausiai projektinė dokumentacija būtų visiškai suderinta su naujovėmis, o komanda joje nesunkiai rastų aktualų sprendimą analizuojant ir projektuojant vėlesnius pakeitimus.

20 pav. – Informacinės sistemos diegimo etapas

Be komentarų…

6. Informacinės sistemos perkėlimas į komercinę veiklą

Kai bandomosios eksploatacijos metu išsprendžiami visi ginčytini klausimai ir nesusipratimai dėl to, kaip įdiegta sistema turi funkcionuoti ir kiek ji atitinka jos kūrimo sutartį, šalys pasirašo sutarties vykdymo aktus. Užsakovas pilnai atsiskaito už atliktus darbus. Sutartis dėl informacinės sistemos kūrimo ir diegimo gali būti laikoma įvykdyta.

Diegimas pereina į pramoninės veiklos etapą. Šie santykiai dažniausiai teisiškai reguliuojami atskiru susitarimu arba papildomas susitarimas palaikyti sistemos pramoninį veikimą. Šios sutarties ribose gali būti atliekami prevenciniai darbai diagnozuojant sistemos komponentų veikimą, jų sąveiką, šalinant smulkius gedimus ir kt.

7. Skyriaus santrauka

Informacinės sistemos diegimo etapas yra viso jos kūrimo proceso tiesos momentas ir visiems projekto dalyviams žymi sunkiausio laikotarpio pradžią. Tai gali apimti šią veiklą:

1. Sistemos diegimas pramoninės eksploatacijos vietoje, įskaitant įrangos tiekimą, sistemos programinės įrangos įdiegimą, dabartinės diegiamos sistemos laidos diegimą ir kt.;
2. Naudotojų mokymas dirbti su sistema, įskaitant administratorius, įrangos priežiūros specialistus ir kt.
3. Bandomosios eksploatacijos metu nustatytų trūkumų ir defektų nustatymas ir pašalinimas.
4. Sistemos veikimo pakeitimų koordinavimas ir suderinimas su sutartiniais įsipareigojimais;
5. Sutartinių įsipareigojimų įvykdymo dokumentų pasirašymas. Visiškai atsiskaityti už atliktus darbus;
6. Sistemos paleidimas komerciniam eksploatavimui;

Įgyvendinant įmonės IP, sukurtą savarankiškai arba perkamą iš tiekėjo, dažnai sutrinka (perprojektuojami) esami įmonės verslo procesai. Turime juos perstatyti taip, kad atitiktų standartų reikalavimus ir diegiamos sistemos logiką. Iš karto atkreipkime dėmesį, kad informacinių sistemų įdiegimas išsprendžia daugybę vadybinių ir techninių problemų, tačiau iškyla problemų, susijusių su žmogiškuoju faktoriumi.

Informacinės sistemos įdiegimas, kaip taisyklė, labai palengvina įmonės veiklos valdymą, optimizuoja vidinius ir išorinius informacijos srautus, pašalina valdymo kliūtis. Tačiau po to, kai sistema sėkmingai įdiegta, „išbandyta“ veikia ir pasirodė esanti efektyvi, kai kurie darbuotojai rodo nenorą naudoti IS savo darbe. Pertvarkymo rezultatas tampa aišku, kad kai kurie darbuotojai iš esmės dubliuoja kitų darbą arba yra visai nereikalingi. Be to, NVS diegimą lydi privalomi mokymai, tačiau, kaip parodyta Rusijos patirtis Norinčių persikvalifikuoti nėra daug. Sulaužyti senus įgūdžius ir diegti naujus – ilgas ir sunkus procesas!

Reikia aiškiai suprasti, kad korporatyvinis IP skirtas supaprastinti organizacijos valdymą, pagerinti procesus, sustiprinti kontrolę ir taip teikti konkurencinę naudą. Tik šiuo požiūriu galima įvertinti jo įgyvendinimo naudą.

Vadovaujantis tokia logika, tampa aišku, kad nors korporacinės IS iš esmės yra skirtos visiems vartotojams suteikti reikiamą informaciją, tačiau NVS kūrimo ir diegimo valdymas yra aukščiausios įmonės vadovybės prerogatyva! Ar vadovai tai supranta?

Čia taip pat turime kovoti su nuolatiniais stereotipais. „Kam man reikalinga korporatyvinė sistema, jei įmonėje jau viskas klostosi gerai? „Kam ką nors laužyti, jei viskas veikia? Tačiau dažniausiai jo laužyti nereikia. Pirmajame etape tereikia kompetentingai ir teisingai įforminti bei perkelti į įmonės IS nustatytus procesus, kuriuose veikia įmonė. Toks formalizavimas tik paaštrins ir išgrynins sėkmingas rinkodaros ir gamybos idėjas, optimizuos valdymo ir kontrolės procesą bei leis atlikti tikslingus pokyčius ateityje.

Naujos IS pristatymas – sunkus procesas, trunkantis nuo kelių mėnesių mažoms IS iki kelerių metų didelių platinamų įmonių, turinčių platų asortimentą ir daug tiekėjų, IS. Informacinės sistemos kūrimo (ar įsigijimo) ir diegimo projekto sėkmė labai priklauso nuo įmonės pasirengimo vykdyti projektą, asmeninio vadovybės intereso ir valios, realios veiksmų programos, išteklių prieinamumo, apmokyto personalo, ir gebėjimas įveikti pasipriešinimą visuose įkurtos organizacijos lygiuose.

Iki šiol atsirado standartinis informacinių sistemų diegimo metodų rinkinys. Pagrindinė taisyklė – reikiamas fazes atlikti nuosekliai ir nepraleisti nė vienos iš jų.

Diegimui svarbūs šie veiksniai:

· aiškiai suformuluotų projekto tikslų ir IP reikalavimų buvimas;

· IP įgyvendinimo ir naudojimo strategijos prieinamumas;

· atlikti priešprojektinę įmonės ir pastatų modelių apklausą „Kaip yra“ ir „Kaip bus“;

· darbų, išteklių planavimas ir įgyvendinimo plano įgyvendinimo stebėsena;

· aukštesnės vadovybės dalyvavimas diegiant sistemą;

· sistemų integravimo specialistų kartu su įmonės specialistais atlieka IS diegimo darbus;

· nuolatinė atliekamų darbų kokybės stebėsena;

· greitai gauti teigiamų rezultatų bent dalyje įdiegtų IS modulių arba bandomojo veikimo metu.

Prieš pradėdami rengti įgyvendinimo projektą, turite:

· kiek įmanoma įforminti IS diegimo projekto tikslus;

· vertinti minimaliai būtinų išlaidų ir išlaidų straipsniai;

· nustatyti aukštą prioritetą įgyvendinimo projektui prieš kitus vykdomus projektus;

· suteikti projekto vadovui maksimalius įmanomus įgaliojimus;

· vykdyti masinį švietėjišką darbą su įmonės personalu, siekiant visiems perteikti artėjančių pertvarkų svarbą ir būtinybę;

· parengti organizacines naujų informacinių technologijų naudojimo priemones;

· paskirstyti asmeninė atsakomybė visuose įgyvendinimo ir bandomosios veiklos etapuose.

Taip pat būtina nustatyti funkcinės zonos informacinės sistemos modulių diegimas:

· organizacinis valdymas;

· organizacinė ir administracinė pagalba;

· verslo procesų valdymas;

· valdymas, planavimas, finansai ir apskaita;

· personalo valdymas;

· dokumentų valdymas;

· logistikos valdymas;

· santykių su klientais ir išorine aplinka valdymas.

Be to, kas išvardinta aukščiau, būtina nustatyti technologinius IS diegimo reikalavimus:

· sistemos platforma – diegimas ir pritaikymas paruoštas sprendimas iš gamintojo arba pagal užsakymą sukurtas pagal kliento technines specifikacijas;

· integruojamumas – duomenys saugomi ir apdorojami vienoje informacinėje erdvėje; tai užtikrina jų išsamumą, nuoseklumą, patikimumą ir pakartotinį naudojimą; sistema gali apimti naujai sukurtas ir jau naudojamas technologijas ir programas;

· pritaikomumas – sistema sukonfigūruojama pagal kliento reikalavimus ir kliento informacinio lauko ypatybes;

· paskirstyta – sistema gali efektyviai veikti geografiškai nutolusiuose įmonės padaliniuose ir filialuose;

· mastelio keitimas – sistema gali būti įdiegta kaip rėmas, kuriame yra pagrindiniai moduliai ir plečiama pagal kintančios išorinės ir vidinės aplinkos reikalavimus.

Pagrindiniai informacinės sistemos diegimo etapai

Fazė „Parengiamieji IS diegimo projekto rengimo darbai“. Priešprojektinės įmonės apklausos metu renkama išsami informacija apie organizacijos struktūrinę struktūrą, funkcinius santykius, valdymo sistemą, pagrindinius verslo procesus, srautus įmonės viduje (Control Flow, Doc Flow, Data Flow, Work Flow, Cash). Srautas), būtinas statybai tinkamų modelių ir objektų automatizavimui parinkimas. Įvertinamas darbo laikas, ištekliai, rūšys ir apimtys, programinės įrangos, techninės ir telekomunikacijų asortimentas ir kaina, personalo mokymo kaina ir kt.

„Projekto rengimo“ etapas. Pasibaigus pirmajam etapui, atliekamas preliminarus planavimas ir projekto paleidimo procedūrų formavimas:

· projektų ir ekspertų grupių formavimas;

· įgaliojimų ir atsakomybės paskirstymas;

· organizacinių ir techninių reikalavimų įgyvendinimo procesui nustatymas;

· klientų specifikacijų ir lūkesčių išaiškinimas;

· diegimo grupės, susidedančios iš klientų įmonės specialistų, mokymas.

Sudarant įgyvendinimo planą kažkodėl dažnai praleidžiamas paskutinis, labai svarbus punktas. Tačiau nuo to labai priklauso viso projekto sėkmė! Pradėjus finansuoti, projektas laikomas pradėtu.

Fazė „Koncepcinė projekto plėtra“. Šio etapo metu:

· sudaromas ir patvirtinamas koncepcinis projektas;

· pasiekiamas privalomas nedviprasmiškas visų projekto dalyvių ketinimų dėl įgyvendinamos IS supratimas;

· išaiškinami ir patikslinami projekto tikslai ir uždaviniai;

· nustatomi sistemos prototipo matmenys;

· susitariama dėl išplėsto darbų plano, bandomosios veiklos etapų sekos ir sąlygų, planavimo, finansinių ir ataskaitinių rodiklių;

Šiuo atveju visi nurodyti veiksmai privalomas yra dokumentuoti, suderinti ir patvirtinti visų suinteresuotų ir atsakingų šalių.

„Projekto įgyvendinimo“ etapas. Pagrindinių diegimo darbų metu sukuriama, įdiegiama ir sukonfigūruojama sistemos aplinka, nustatomos sistemos administravimo procedūros, įdiegiamos pagrindinės techninės ir programinės įrangos sistemos bei taikomosios programos. Sistema konfigūruoja įmonės organizacines, personalo ir organizacines-funkcines struktūras, naudodama tokius organizacinius vienetus kaip filialas, skyrius, skyrius, darbo grupė ir tt

Atliekamas tinklo ir telekomunikacijų įrankių diegimas, konfigūravimas ir sąranka, duomenys perduodami iš ankstesnių vietinės sistemos ir sąsajų su senosiomis ir išorinėmis sistemomis formavimas. Tuo pačiu metu visi sukurti modeliai, planai, veikiantys programinės įrangos produktai ir dokumentacija yra patalpinti realizavimo projekto saugykloje nuo galo iki galo (3 pav.). Svarbi šios saugyklos dalis yra projekto metu sugeneruota dokumentacijos sistema (4 pav.).

Nagrinėjami sisteminiai saugumo klausimai, susiję su sistemos veikimu kelių vartotojų režimu. Kuriamos programos, šablonai, ataskaitos, kliento prieigos formos, platinamos vartotojų teisės. Visos sistemos yra testuojamos „koviniu režimu“, dalyvaujant visoms suinteresuotoms šalims.

Pasibaigus įgyvendinimo etapui, įgyvendinimo projektas laikomas baigtu. Pradedama eksploatuoti informacinė sistema.

7. Sėkmės veiksniai ir nesėkmingų IS diegimų priežastys

modeliavimo informacijos pertvarkymo verslas

Pasaulinės statistikos duomenimis, tik trečdalis informacinių sistemų kūrimo ir diegimo projektų yra sėkmingi. Apie panašius tyrimus Rusijoje nieko nežinoma, bet panašu, kad čia viskas dar blogiau.

Sėkmingas projektas užbaigiamas laiku, neviršijant biudžeto ir pasiekia numatytus rezultatus. Kas atsitiks su likusiais projektais? Jie arba užsitęsia daug ilgiau nei tikėtasi, reikalauja vis didesnio finansavimo, arba sukuriama automatizuota sistema, kurios niekam nereikia, niekas nenori ir negali su ja dirbti.

Nepavykę projektai yra labai panašūs vienas į kitą. Atrodo, kad jie kopijuoja vienas kitą, žaisdami tą patį scenarijų. Daug metų stebėdama blogą praktiką paskatino mane parašyti keletą taisyklių įmonių vadovams, kurios padėtų jiems to išvengti. tipines klaidas diegiant įmonės valdymo automatizavimą. Jie taip pat puikiai tinka biudžeto automatizavimo projektams, valdymo apskaita, gamybos valdymo ir kitose srityse įmonių valdymas.

Reikia pabrėžti, kad šie patarimai pirmiausia skirti aukščiausiajai organizacijos vadovybei, tai yra įmonės savininkui ar generaliniam direktoriui, kurie veikia kaip klientai? pokyčiai įmonių valdymo srityje, įskaitant automatizuotų sistemų kūrimą. Asmenų nesusipratimas?aukštesnis ešelonas? jos vaidmuo tokiuose projektuose yra pagrindinė tokių pastangų nesėkmės priežastis.

Pirmas. Apibrėžkite projekto tikslą

Remiantis ta pačia statistika, septyniasdešimt procentų nesėkmingų projektų tokiais tapo dėl savo tikslų neapibrėžtumo. Kitaip tariant, galutinis rezultatas nebuvo aiškiai apibrėžtas nuo pat pradžių.

Pavyzdys iš praktikos. Vienos didelės holdingo bendrovės informacinių technologijų tarnybos vadovas iš generalinio direktoriaus gauna užduotį įdiegti automatizuotą sistemą, užtikrinančią aukščiausio lygio operatyvios ir patikimos informacijos valdymą. Ieško IT tarnybos vadovo programinė įranga tinka pavestoms problemoms spręsti, kreipiasi į konsultantus. Į mūsų klausimą, kokios problemos paskatino įmonės vadovybę diegti automatizuotą sistemą, pateikiamas toks atsakymas:

· vieningo valdymo apskaitos duomenų pateikimo formato nebuvimas.

· valdymo ataskaitų rengimo reglamentų trūkumas.

· vieningos informacinės aplinkos nebuvimas

Visiškai aišku, kad pirmosios dvi?problemos? nėra susiję su automatizavimu, o pastaroji nėra problema, nes egzistuoja vieninga informacinė aplinka? savaime Nr praktinė nauda neturi supratimo.

Susipažinimas su realia įmonės padėtimi leido suprasti, kad kyla problemų dėl korporacijos vadovo įgaliojimų delegavimo verslo padalinių vadovams. Ji turi būti sprendžiama pasitelkus kontroliavimą, pagrįstą reguliariu planavimu ir valdymo apskaita bei tinkama vadovų motyvacija. Kitaip tariant, ar pirmiausia turėtume kalbėti apie valdymo procesų nustatymą įmonės lygiu ir tik po to? apie šių procesų automatizavimą. Tai supratę įmonės vadovai, atsisakę beprasmės automatikos, sutaupė nemažai pinigų.

Gilus projekto tikslų supratimas gali lemti jo įgyvendinimo atsisakymą arba terminų atidėjimą dėl prioritetų peržiūros.

Automatizavimo tikslai turi būti formuluojami ne terminais techniniai privalumai, bet verslo interesų požiūriu. Jie gali būti apibrėžti, pavyzdžiui, taip:

· atsargų mažinimas sandėlyje dėl tikslesnio gamybos ir pirkimų planavimo;

· gautinų sumų sumažinimas dėl informacinė pagalba darbas su skolininkais;

· didesnio skaičiaus investicinių projektų įgyvendinimas, atsisakant įprastinių operacijų, kurias atlieka kvalifikuoti vadovai.

Šis tikslų apibrėžimas leis suprasti, kodėl tai darote, kiek esate pasirengęs mokėti už šių problemų sprendimą ir, kas labai svarbu, gauti projekto sėkmės kriterijus, pagal kuriuos galėsite įvertinti galutinius rezultatus.

Antra. Atidarykite projektą

Automatizuotos sistemos diegimas yra strateginis įmonės projektas. Jis turi būti atidarytas generalinio direktoriaus įsakymu. Įsakymu apibrėžiami projekto tikslai ir terminai bei paskiriamas projekto vadovas.

Pavyzdys iš praktikos. Didelio banko vadovas paveda finansų valdymo vadovui įdiegti biudžeto sudarymo sistemą. Nepaisant to, kad nuo paskyrimo praėjo daugiau nei metai, paskirtas vadovas nesuvokia, kokius įgaliojimus jis turi dėl šio pavedimo, kokių rezultatų ir per kiek laiko iš jo tikimasi. Atrodo, kad projektas egzistuoja, bet viskas nejuda į priekį.

Kitaip tariant, jūs turite aiškiai suprasti, kas yra projektas? Tai visavertė organizacinė struktūra, laikinai sukurta organizacijos viduje, siekiant labai konkrečių tikslų.

Generalinio direktoriaus paskirtas vadovas sudaro projekto komandą. Jame turėtų būti padalinių vadovai ir specialistai, besidomintys galutiniu rezultatu ir kompetentingi projekto dalykinėje srityje. Taigi, jei diegiama biudžeto sudarymo sistema, projekto komandą sudaro finansų ir IT tarnybų vadovai ir specialistai bei gamybos ir pardavimo skyrių atstovai. Projekto vadovas turėtų būti vadovas, kuris įmonės organizacinėje struktūroje užima aukštesnes pareigas nei bet kuris projekto komandos narys.

Trečias. Suteikite projektui išteklių

Pagrindiniai ištekliai– tai pinigai ir žmonės. Todėl būtina patvirtinti projekto biudžetą.

Įvertinimas būtinų išteklių- užduotis nėra lengva, tačiau projekto pagrindimo etape svarbu suprasti, koks biudžetas laikomas priimtinu plėtrai valdymo technologijas ir automatizuotos sistemos diegimas. Faktas yra tas, kad bet kurios problemos sprendimas yra trikampis: pinigai - laikas - rezultatas. Jei norimas rezultatas yra tiksliai apibrėžtas, tada galima apskaičiuoti laiką, reikalingą jam pasiekti ir biudžetą. Jei nėra aiškaus supratimo, kas yra „geras rezultatas“ (tai yra, projekto tikslai nėra tiksliai apibrėžti), tuomet galite išeiti iš biudžeto ir išspręsti problemą tokia forma: koks yra maksimalus. valdymo efektas, kurį galima pasiekti investavus tam tikrą sumą į procesų valdymo ir informacinių technologijų diegimą?

Be to, svarbu dalį projekte dalyvaujančių žmonių darbo laiko skirti su sistemos diegimu susijusiems darbams atlikti. Kitaip?apyvarta? sugadins reikalą. Plačiai paplitusi praktika, kai darbuotojams pavedama įgyvendinti nauja sistema valdymas?neprivalomas?. Kadangi pagrindinis jų darbo krūvis nesumažėja, papildomą darbą jie traktuoja kaip hobį arba kaip erzinančią naštą, priklausomai nuo susidomėjimo laipsnio. Toks požiūris yra gana natūralus, nes įmonės vadovybė, patikėjusi jiems neatlygintinus papildomas darbas, demonstravo savo požiūrį į ją kaip į ką nors antraeilį.

Kontrolė žmogiškaisiais ištekliais projektas apima atlikėjų laiko biudžetą. Faktiškai sugaišto laiko apskaita būtina ne tik norint tinkamai apmokėti atlikėjus, bet ir teisingai įvertinti projekto išlaidas.

Ketvirta. Rūpinkitės motyvacija

Motyvacija- pagrindinis valdymo elementas, todėl turėtumėte atidžiai apsvarstyti projektų vykdytojų motyvavimo schemą. Tai nebūtinai turi būti didelės premijos už sėkmingą sistemos įgyvendinimą.

Dažniausiai naujos vadybos sistemos įdiegimas padeda pagerinti šio darbo dalyvių statusą ir kelia jų profesinį lygį. Tai labai reikšmingos paskatos. Faktas yra tas, kad kūrybingi žmonės į darbą žiūri kaip į savo intelektinio kapitalo didinimo priemonę. Tokie specialistai yra didžiausia vertė bet kokiam su inovacijomis susijusiam verslui.

Projekto komandą formuojančiam vadovui svarbu teisingai suprasti su šio verslo sėkme susijusius atlikėjų lūkesčius. Tai gali būti karjerą, atlyginimo didinimas, naujų žinių įgijimas, naujų profesinio augimo aukštumų siekimas.

Penkta. Valdymo palaikymas

Sėkmė įmanoma tik tuo atveju, jei projektą stipriai remia aukščiausioji įmonės vadovybė. Jeigu generalinis direktorius mano, kad įdiegus automatizuotą sistemą- tai tik IT tarnybos reikalas, tada nieko gero nebus.

Įgyvendinti Informacinės technologijos- reiškia ne tik programų diegimą darbo vietose. Tokie projektai siejami su darbo ir valdymo procesų pokyčiais, pareigų ir galių perskirstymu. Šie pokyčiai dažnai prieštarauja tam tikrų skyrių vadovų ir darbuotojų interesams. Dėl to prasideda sabotažas arba atviras pasipriešinimas pokyčiams. Todėl organizacijos vadovas turi aiškiai parodyti, kieno pusėje jis yra ir, esant reikalui, tvirta ranka nuslopinti pasipriešinimą, suteikdamas paramą projekto komandai.

Šešta. Padalinkite projektą į etapus

Geriausias yra ilgalaikis projektas„supjaustyti į gabalus“ ir nepereiti į kitą etapą neįsitikinęs, kad ankstesnio etapo užduotys yra visiškai įvykdytos. Labai svarbu nustatyti, koks turėtų būti kiekvieno projekto etapo rezultatas.

Taigi, pavyzdžiui, jei kalbame apie automatizuotos biudžeto valdymo sistemos sukūrimą, rekomenduojama paveikslėlyje pateikta veiksmų seka.

Į kitą etapą galite pereiti tik įvykdę tris sąlygas:

· projekto komanda susikūrė bendrą supratimą apie etapo rezultatus;

· šis supratimas įforminamas dokumento forma;

· etapo rezultatus priima užsakovas, tai yra įmonės vadovas.

Šis metodas leidžia kontroliuoti projekto riziką, palaipsniui judant link numatyto tikslo.

Septintas. Valdykite tikslus ir lūkesčius

Darbo eigoje projekto tikslai gali būti koreguojami ar net labai keičiami. Tai įprasta praktika. Situacija keičiasi, mūsų supratimas apie situaciją ir mes darome išvadą, kad mūsų ankstesnės pažiūros yra pasenusios arba klaidingos. Todėl reikia reguliariai (kiekviename projekto etape) grįžti prie šaknų? ir kritiškai išnagrinėti visas pagrindines prielaidas.

Ir paskutinis dalykas. Reikia turėti drąsos uždaryti projektą, jei paaiškėja, kad jis pateko į aklavietę. Projekto vadovas, ėmęsis iniciatyvos nutraukti beviltišką projektą, nusipelno padrąsinimo kaip atsakingas vadovas, užkirtęs kelią įmonės lėšų švaistymui.

Fazė „Parengiamieji IS diegimo projekto rengimo darbai“. Priešprojektinės įmonės apklausos metu renkama išsami informacija apie organizacijos struktūrinę struktūrą, funkcinius santykius, valdymo sistemą, pagrindinius verslo procesus, srautus įmonės viduje (Control Flow, Doc Flow, Data Flow, Work Flow, Cash). Srautas), būtinas statybai tinkamų modelių ir objektų automatizavimui parinkimas. Įvertinamas darbo laikas, ištekliai, rūšys ir apimtys, programinės įrangos, techninės ir telekomunikacijų asortimentas ir kaina, personalo mokymo kaina ir kt.

„Projekto rengimo“ etapas. Pasibaigus pirmajam etapui, atliekamas preliminarus planavimas ir projekto paleidimo procedūrų formavimas:

projektų ir ekspertų grupių formavimas;

įgaliojimų ir pareigų pasiskirstymas;

organizacinių ir techninių reikalavimų įgyvendinimo procesui nustatymas;

klientų specifikacijų ir lūkesčių išaiškinimas;

diegimo grupės, susidedančios iš klientų įmonės specialistų, mokymas.

Sudarant įgyvendinimo planą kažkodėl dažnai praleidžiamas paskutinis, labai svarbus punktas. Tačiau nuo to labai priklauso viso projekto sėkmė! Pradėjus finansuoti, projektas laikomas pradėtu.

Fazė „Koncepcinė projekto plėtra“. Šio etapo metu:

sudaromas ir tvirtinamas koncepcinis projektas;

pasiekiamas privalomas nedviprasmiškas visų projekto dalyvių ketinimų dėl įgyvendinamos IS supratimas;

išaiškinami ir patikslinami projekto tikslai ir uždaviniai;

nustatomi sistemos prototipo matmenys;

susitariama dėl išplėstinio darbo plano, etapų sekos ir bandomosios veiklos sąlygų, planavimo, finansinių ir atskaitomybės rodiklių;

Be to, visi šie veiksmai turi būti dokumentuoti, suderinti ir patvirtinti visų suinteresuotų ir atsakingų šalių.

Ryžiai. 3. Apytikslis įgyvendinimo projekto saugyklos turinys

„Projekto įgyvendinimo“ etapas. Pagrindinių diegimo darbų metu sukuriama, įdiegiama ir sukonfigūruojama sistemos aplinka, nustatomos sistemos administravimo procedūros, įdiegiamos pagrindinės techninės ir programinės įrangos sistemos bei taikomosios programos. Sistema konfigūruoja įmonės organizacines, personalo ir organizacines-funkcines struktūras, naudodama tokius organizacinius vienetus kaip filialas, skyrius, padalinys, darbo grupė ir kt.

Atliekamas tinklo ir telekomunikacijų įrankių diegimas, konfigūravimas ir konfigūravimas, duomenų perkėlimas iš ankstesnių vietinių sistemų, formuojamos sąsajos su senosiomis ir išorinėmis sistemomis. Tuo pačiu metu visi sukurti modeliai, planai, veikiantys programinės įrangos produktai ir dokumentacija yra patalpinti realizavimo projekto saugykloje nuo galo iki galo (3 pav.). Svarbi šios saugyklos dalis yra projekto metu sugeneruota dokumentacijos sistema (4 pav.).

Nagrinėjami sisteminiai saugumo klausimai, susiję su sistemos veikimu kelių vartotojų režimu. Kuriamos programos, šablonai, ataskaitos, kliento prieigos formos, platinamos vartotojų teisės. Visos sistemos yra testuojamos „koviniu režimu“, dalyvaujant visoms suinteresuotoms šalims.

Ryžiai. 4 Apytikslė IS diegimo proceso dokumentacijos sudėtis

Pasibaigus įgyvendinimo etapui, įgyvendinimo projektas laikomas baigtu. Pradedama eksploatuoti informacinė sistema.