Sarcina de operare de probă este de a testa algoritmi, programe și legături proces tehnologic prelucrarea datelor in conditii reale.
Operarea de probă a sarcinilor se desfășoară pe baza informațiilor reale; în această etapă, dezvoltatorul antrenează personalul să lucreze pe un computer folosind un program specific.
Operarea pilot a subsistemelor se efectuează în scopul verificării cuprinzătoare a tuturor elementelor sale, a pregătirii bazei de informații, a depanării procesului tehnologic de colectare și prelucrare a informațiilor, a pregătirii personalului pentru a lucra în condițiile funcționării subsistemului. Operarea de probă a subsistemului ar trebui să fie efectuată pe baza cantității complete de informații reale în modul de funcționare stabilit, cu duplicarea necesară a muncii. Punerea în funcțiune a subsistemului pentru funcționare comercială se efectuează după punerea în funcțiune a sarcinilor complexului de lansare al acestui subsistem pentru funcționare de probă.
Operarea pilot a IS este efectuată în scopul unei verificări cuprinzătoare a funcționării sarcinilor sistemului, verificarea pregătirii părții suport a sistemului pentru funcționare, depanarea finală a procesului tehnologic de colectare și prelucrare a informațiilor. Operarea de probă a sistemului ar trebui să fie efectuată pe baza cantității necesare de informații despre activitatea obiectului în modul stabilit de funcționare. După finalizarea funcționării de probă a sistemului, se realizează un raport privind implementarea.
Implementarea pilot constă în:
1. Pregătirea datelor operaționale inițiale pentru toate complexele acestui proiect
2. Introducerea acestor date în PC și efectuarea overclocking-ului software
3. Analiza rezultatelor obținute pentru a identifica toate erorile și inexactitățile.
Cu rezultate pozitive ale operațiunii de probă, sistemul este pus în funcțiune comercială. În cursul operațiunii comerciale, se efectuează analiza funcționării sistemului, eficacitatea implementării solutii de proiectareîn condițiile funcționării sale industriale, elaborarea de recomandări pentru dezvoltarea ulterioară a sistemului și formarea de soluții standard.
Analiza funcționării sistemului prevede verificarea:
— Funcționarea mijloacelor tehnice
— Funcționarea sarcinilor și subsistemelor în condiții de prelucrare automată
— Acţiunea personalului în condiţiile de funcţionare a sistemului
Rezultatele analizei sunt folosite pentru a evalua calitatea sistemului și realitatea acestuia eficiență economică. Lucrările privind analiza funcționării sistemului sunt efectuate de dezvoltator în ordinea supravegherii terenului pe baza unui acord cu clientul după o anumită perioadă de funcționare a EIS. Supravegherea autorului se realizează pe cheltuiala fondurilor alocate pentru crearea sistemului. Programul de lucru de analiză este întocmit de dezvoltator și convenit cu clientul. Analiza funcționării sistemului începe după emiterea unui ordin de efectuare a acestei lucrări. Comanda indică termenii și obiectele sondajului, precum și desemnat de reprezentantul clientului implicat în această lucrare și de persoana responsabilă pentru depunerea la timp și completă materialele necesare dezvoltator de sistem. Colectarea tuturor datelor, completarea formularelor necesare, înregistrarea în jurnal se realizează de către reprezentantul clientului și este controlată de dezvoltator. Datele acumulate sunt transferate în timpul specificat în program de către reprezentanții dezvoltatorilor pentru dezvoltare. Rezultatele prelucrării datelor pentru fiecare element investigat al EIS sunt înregistrate de dezvoltator cu participarea unui reprezentant al clientului. Pe baza protocoalelor finalizate, dezvoltatorul, după finalizarea tuturor lucrărilor prevăzute de program, întocmește un raport privind analiza funcționării EIS.
Livrarea unui raport privind analiza funcționării sistemului către client este etapa finală a muncii dezvoltatorului. În procesul de analiză a funcționării sarcinilor, subsistemelor și acțiunilor personalului în contextul implementării EIS, se lucrează similar studierii obiectului în ceea ce privește parametrii fiecărei funcții a subsistemelor EIS, luând în considerare luați în considerare complexul mijloacelor tehnice utilizate și următorii factori:
- Primirea la timp a informațiilor necesare către personalul de conducere;
— Creșterea fiabilității informațiilor;
— Îmbunătățirea performanței tehnice și economice a întreprinderii.
Calitatea funcționării subsistemelor individuale este evaluată în ceea ce privește fiabilitatea și actualitatea informațiilor, îmbunătățind calitatea informațiilor relevante. decizii de management. Pe baza rezultatelor analizei funcționării sistemului, sunt elaborate propuneri pentru dezvoltarea ulterioară a EIS.
Sistem de management IT: trei componente...
În contextul acestei probleme, prin sistemul de management IT ne vom referi la un sistem automatizat de management al activităților departamentului IT, construit pe baza unor abordări, metodologii, standarde și soluții software specializate pentru industria IT. Baza conceptuală pentru construirea unui astfel de sistem este „abordarea serviciului”, adică organizarea managementului serviciului IT ca unitate de servicii și orientarea întregului personal în direcția furnizării de servicii afacerii. Prin urmare, un astfel de sistem de management este adesea denumit „Sistem de management al serviciilor IT”, iar implementarea lui este denumită „Implementarea unei soluții ITSM” sau „proiect ITSM”.
Sistemul de management IT nu se limitează, desigur, la instrumente de automatizare. Rezultatul final al unui proiect ITSM este un sistem de management IT funcțional la cheie. Aceasta este o combinație de trei componente - „procese”, „oameni”, „instrumente de automatizare”. Când vorbim de implementare comercială sau de furnizare de servicii de implementare, toate aceste componente, de regulă, sunt incluse în contractul cu contractantul (integrator de sistem, firma de consultanta) ca obiecte formale de livrare.
„Procesele” reprezintă așa-numita documentație de proces, adică o întreagă gamă de documente organizatorice și administrative care descriu și stabilesc regulile de lucru ale personalului departamentului IT, domeniile de responsabilitate și procedura de interacțiune. Baza conceptuală sistem modern Managementul IT (împreună cu abordarea serviciilor deja menționată) este managementul proceselor combinat cu modelul industrial descris în biblioteca ITIL. Un proiect ITSM specific acoperă unul sau mai multe procese interconectate, pentru care se elaborează documentația procesului.
„Oamenii” sunt oamenii din departamentul IT care participă la procesul de implementare și apoi devin utilizatori ai sistemului. Aceștia sunt purtători de experiență și cunoștințe ale tehnologiilor și practicilor specifice ale organizației și aduc o contribuție creativă semnificativă la proiectarea sistemului.
„Unelte de automatizare” este un complex de tehnici și instrumente software care automatizează activitățile din cadrul proceselor. Nu vom acorda o atenție deosebită software-ului în sine, vom spune doar că există multe soluții software specializate specifice industriei pe piața modernă.
Pentru Jet Infosystems, soluțiile emblematice sunt (în ordine alfabetică) liniile de produse BMC Remedy ITSM Suite și HP Software Service Management Center. Astfel, implementarea unei soluții ITSM reprezintă o schimbare intenționată a celor trei componente ale sistemului de management IT: documentatii normative, abilitățile personalului și instrumente de automatizare pentru un număr limitat de activități (procese). După luarea unei decizii fundamentale privind necesitatea schimbării sistemului de management IT (lansarea unui proiect ITSM), începe etapa de planificare. Aici se stabilesc parametrii cheie ai proiectului, se identifică părțile sale constitutive (sarcinile), se determină cantitatea necesară de resurse, se realizează succesiunea lucrărilor și se stabilește bugetul.
În această etapă, organizația ia o serie de decizii importante. În primul rând: ce forțează să implementăm proiectul, independent sau cu implicarea consultanților? Ce software să folosești? Pentru a răspunde la aceste întrebări, există un număr suficient de surse pentru a ajuta organizația, inclusiv cercetări, evaluări și recenzii ale proprietarilor unor astfel de sisteme. Instrumentele comune pentru găsirea celor mai bune soluții sunt solicitarea de propuneri tehnice și comerciale de la integratori de top, organizarea de prezentări tehnice și demonstrații de la diverși furnizori, lansarea de proiecte „pilot” pentru compararea platformelor.
Cu o abordare atentă a organizațiilor în ceea ce privește planificarea în ceea ce privește alegerea instrumentelor software și a unei echipe de interpreți, în cele mai multe cazuri aspectul tehnologic al planificării proiectelor rămâne în spatele scenei: ce va fi luat ca bază a sistemului creat, în ce măsură și cum va fi finalizată această bază pentru a obține rezultatul final. De regulă, problema alegerii metodei de dezvoltare și implementare în etapa de pregătire a proiectului nu este pusă în mod explicit, această metodă este, parcă, ascunsă în planurile detaliate de proiect și rămâne la latitudinea contractantului.
În opinia noastră, o alegere a metodei de dezvoltare insuficient definită implică riscuri mari de abateri inevitabile de la plan (adică cele care necesită reprogramare și clarificare semnificativă). părțile constitutive proiect). O discuție deschisă și un acord asupra așteptărilor clientului și antreprenorului cu privire la metoda de implementare va ajuta la reducerea impactului unor astfel de riscuri.
… și trei opțiuni de implementare
Cu toată varietatea de platforme și bogăție funcţionalitate, prezentate pe piața instrumentelor software specializate din clasa „industrială”, organizația are la dispoziție doar trei modalități alternative de utilizare a acestora pentru a construi un sistem de management. Să le numim condiționat: „Decizie de la producător”, „ cea mai buna practica” și „Soluție individuală”.
„Soluție de la producător” - instalarea unui sistem de automatizare „din cutie” și începerea lucrului conform schemelor tehnologice de referință ale producătorului (cu reglaj ulterioar în procesul de întreținere). Acesta este cel mai rapid și mai ieftin mod de a organiza munca într-un mod nou.
„Cea mai bună practică” este instalarea unei soluții standard, creată în prealabil de compania integratoare pe baza experienței acesteia. Acesta este cel mai garantat mod de a obține un sistem cu adevărat funcțional.
„Soluție individuală” - dezvoltarea unei soluții individuale, începând cu modelul procesului și reglementările procesului și terminând cu caracteristicile setărilor interfeței cu utilizatorul. Această metodă vă permite cel mai bine să țineți cont de dorințele angajaților și de evoluțiile disponibile în organizație.
Atunci când alege o soluție de la un producător, organizația primește un sistem de automatizare cu logica de afaceri preconfigurată și documentație inclusă în pachetul standard de livrare a licenței. Munca integratorului la crearea unei astfel de soluții include instalarea și testarea complexului hardware al clientului, introducerea datelor de referință privind locația obiectelor de serviciu, structura organizationala, servicii, utilizatori. De asemenea, se integrează cu sistemul de e-mail pentru a trimite alerte. Acest lucru este de obicei suficient pentru a începe instruirea angajaților și operarea sistemului de management.
„Cea mai bună practică” (soluția autorului companiei integratoare) oferă, cel puțin, o interfață de utilizator convenabilă, nu supraîncărcată și un set de funcții automatizate suficient pentru funcționare. Pe lângă instalarea și completarea manualelor, implementarea unei astfel de soluții presupune o anumită adaptare a documentației procesului și rafinarea sistemului de automatizare, în principal cu instrumente de configurare, mai degrabă decât programare. Condiții prealabile cheie pentru implementarea cu succes: o evaluare corectă a aplicabilității pentru o anumită industrie și client, prezența unei interfețe simple și frumoase, calitate superioară documentația și fiabilitatea operațională.
Primele două opțiuni („soluția producătorului” și „cea mai bună practică”) au multe în comun. Acestea sunt soluții gata făcute care nu sunt dezvoltate în cadrul proiectului. Implementarea acestora începe în esență cu implementarea și instruirea. Planurile de implementare pentru astfel de soluții sunt elaborate în avans, testate de mai multe ori și nu se modifică de la proiect la proiect. Dacă o organizație a optat pentru una dintre aceste opțiuni de modernizare a sistemului de management, cele mai critice probleme ale proiectului sunt alegerea furnizorului (platformei) potrivite și a integratorului potrivit.
Selectați „Soluție personalizată”. Cum o vom face?
Cea mai puțin previzibilă și deci mai interesantă de luat în considerare din punctul de vedere al participanților la proiect este „Soluția individuală”, în cadrul căreia are loc, în primul rând, proiectarea și dezvoltarea unui sistem specific unei anumite organizații. Proiectele pentru implementarea soluțiilor individuale pot varia semnificativ în ceea ce privește costul și timpul. Din experiența noastră, cel mai important factor aici este modul în care este organizat proiectul.
La fel de cadrul metodologic proiectarea și implementarea soluțiilor individuale, în general, standarde de management de proiect, standarde și de bază reguli managementul ciclului de viață al software-ului, precum și metodologia de proiectare software de la producători cunoscuți (Microsoft, Oracle, HP, BMC etc.). Pe baza acestora, compania integratoare își formează propriul profil de standarde și metode care reglementează procesele de proiectare, dezvoltare, operare și dezvoltare Sistem informatic. Toate aceste standarde și metodologii sunt adaptate și concretizate în raport cu anumite clase de proiecte, în cazul nostru, proiecte ITSM.
Orez. 1. Harta produsului
Rezultatul este un set de beton instrucțiuni, cerințe, proprietăți și indicatori de calitate care caracterizează modul de organizare a dezvoltării și implementării sistemului. O altă parte a caracteristicilor unei soluții individuale - în principal funcționale și tehnice - este determinată creativ de către client și antreprenor aflat deja în procesul de dezvoltare.
Astfel, chiar și pentru o soluție individuală în etapa de planificare a proiectului, o parte semnificativă a deciziilor de proiectare este predeterminată și cunoscută de antreprenor. Prin urmare, este logic să punem discuția despre metoda de dezvoltare la egalitate cu probleme de pregătire a proiectelor precum alegerea platformei (furnizorului) și alegerea arhitecturii.
În ce secvență vor fi obținute rezultatele proiectului? Cum vor fi formate și colectate comentariile clienților? În ce ordine și în ce măsură vor fi acceptate și eliminate comentariile? Acestea și alte întrebări care caracterizează metoda de organizare a proiectului folosită de antreprenor pot fi puse
in faza de planificare, inclusiv pentru a compara mai corect ofertele competitive si a alege pe cea mai buna.
Principala întrebare a metodei de dezvoltare: cum obținem produsele proiectului? Pentru a înțelege noi înșine, pentru a spune clientului despre asta și, cel mai dificil lucru, pentru a ne realiza planurile, folosim hărți de produse ale proiectului. O hartă a produsului este o diagramă a rezultatelor intermediare și finale ale lucrărilor de proiectare, care determină ce și în ce ordine va fi produs în timpul proiectului (vezi). Baza metodologică pentru construirea unei hărți de produs este metoda de planificare bazată pe produs de la Prince2, care este utilizată pentru a dezvolta structura de defalcare a lucrărilor.
Hărțile noastre sunt „desenate” de etapele proiectului, pe care produsele proiectului sunt aplicate sub formă de dreptunghiuri. Dreptunghiurile sunt conectate prin legături, legăturile determină pe baza căror produse sunt dezvoltate următoarele produse. Astfel, harta produsului determină tehnologia de fabricație a sistemului de control.
Toate produsele pot fi împărțite în două grupe. Primul grup este „extern”, care sunt furnizate clientului. Al doilea este „intern”, care este necesar echipei de proiect ca componentă tehnologică, de regulă, pentru a obține unul dintre produsele „externe”.
Folosim o altă clasificare a produselor: „obligatoriu” și „opțional”. Produsele „obligatorii” includ produse a căror dezvoltare este necesară din punct de vedere tehnologic (fără ele nu se poate obține rezultatul final al unui proiect ITSM). „Opțional” se referă la produsele care ar putea fi renunțate. Produsele „opționale” sunt incluse în fișa produsului, de regulă, la cererea clientului.
Compoziția, succesiunea și interrelațiile produselor care alcătuiesc valoarea principală a hărții sunt determinate euristic, este greu de imaginat un algoritm universal pentru compilarea unei astfel de hărți. Acesta este rezultatul multor ani de experiență în implementare, un număr mare de greșeli, dispute ideologice fundamentale, descoperiri bruște, încercări care au trecut testul timpului și proiecte reale.
Pe baza hărții produsului, puteți arăta în mod clar principalele diferențe și caracteristici ale metodei de dezvoltare luate în considerare. Majoritatea proiectelor pe care le-am implementat pot fi atribuite uneia dintre cele două moduri de organizare a muncii. Să le numim în mod convențional „Clasic” și „Iterativ” și să le considerăm pe fiecare separat.
Fiecare exemplu de produs din articol este descris în felul următor:
- Forma;
- Programare;
- Conţinut;
- Opțiuni, recomandări.
Modul „clasic” de implementare a unui sistem de management IT
Esența metodei de implementare „clasică” este dezvoltarea pas cu pas a sistemului, începând cu cercetarea. domeniul subiectuluiși terminând cu implementarea sistemului la cheie și sprijin suplimentar. Evidențiem (și mapăm) următoarele etape ale proiectului:
- examinare;
- Proiecta;
- Dezvoltare;
- Implementare;
- Operare pilot-industrială;
- Punere in functiune;
- Suport tehnic și întreținere.
În cazul metodei „clasice” de implementare, etapele sunt foarte importante, întrucât rezultatele obținute la sfârșitul etapei (produsele de proiect) stau la baza etapei următoare, iar revizuirea lor este aproape imposibilă fără a face modificări la proiectul. Luați în considerare principalele produse ale proiectului în fiecare etapă.
Etapa 1: Examinare
Obiectivele etapei sondajului sunt două: să vă faceți o idee despre practica curentă în domeniul subiectului și să clarificați enunțul problemei. Principalul rezultat al etapei este raportul sondajului. Dacă urmăriți harta, primul produs al etapei este „Structura obiectului managementului” (o altă denumire este „Model de anchetă”). Nu este eliberat clientului, este un produs „intern”. În ea, conform aceleiași scheme „oameni - procese - instrumente de automatizare”, este fixat: ce trebuie investigat în cadrul sondajului, ce documente să primească și să studieze, cu ce oameni să intervieveze, ce instrumente de automatizare utilizate de clientul să ia în considerare.
raport al sondajului
Forma
Document text (în principal), prezentare.
Scop
Raportul sondajului este cel mai interesant și mai interesant de citit documentul de proiect. La începutul proiectului, raportul este util pentru crearea unei atmosfere de înțelegere reciprocă în echipa comună de proiect „Client - Antreprenor”: consultanții demonstrează o înțelegere a specificului și priorităților organizației, iar reprezentanții clienților acceptă și sunt de acord să utilizeze termenii și instrumentele proiectelor ITSM, de exemplu, „structura procesului de rol” și nivelul de maturitate.
A doua viață a „Raportului” începe la sfârșitul proiectului, când este necesar să se demonstreze efectul introducerii unui nou sistem (a fost - a fost). În viitor, după ce sistemul de control este pus în funcțiune, acesta devine inutil și practic nu este utilizat.
Pe baza căruia se dezvoltă
Consultanții pregătesc un raport pe baza notelor lor făcute în timpul interviului, precum și pe baza documentelor colectate ale organizației: regulamente, instrucțiuni și așa mai departe. Acuratețea și calitatea sunt proporționale cu calificările consultanților și numărul acestora per interviu (un consultant este rău). Dacă în timpul sondajului a fost efectuat un sondaj (ceea ce nu se întâmplă de fiecare dată), rezultatele sunt procesate și incluse în raport într-o formă agregată.
Un raport tipic este împărțit condiționat în trei blocuri principale: informatii generale, descrierea situației actuale, concluzii.
Informațiile generale sunt obiectivele declarate ale sondajului, limitele anchetei (organizaționale și funcționale), lista documentelor utilizate și persoanele intervievate. De asemenea, oferă o descriere a metodologiei anchetei, inclusiv metode de colectare a informațiilor, metode de grupare și generalizare, metode și criterii de evaluare.
Descrierea situației actuale este o prezentare structurată a practicii curente „ca atare”, folosind uneori diagrame grafice și desene. Pentru toate domeniile cercetate ale activităților organizației, este utilizată o singură structură de descriere. De exemplu, așa:
- Structura organizatorica si a rolurilor;
- Activități de proces;
- Suport documentare;
- Suport informațional;
- Mijloace de automatizare.
Adesea, secțiunea include cerințe de management și sugestii de îmbunătățire colectate în timpul sondajului, dacă este posibil, fără a modifica formularea.
Secțiunea „Concluzii” conține rezultatele analizei situației actuale. Aproape întotdeauna, acestea sunt rezultatele evaluării nivelului de maturitate al proceselor, precum și „gâturile de sticlă” identificate și riscurile asociate acestora.
După secțiunea „Concluzii”, pare logic să existe câteva recomandări, totuși, în contextul proiectului ITSM aflat în derulare, acest lucru poate fi salvat: proiectul a fost lansat, bugetul a fost aprobat, cerințele au fost formulate - este timpul să începem proiectarea.
Echipa de proiect a clientului este adesea interesată de conținutul interviurilor pe care consultanții le desfășoară cu managementul IT superior și reprezentanții afacerii. Pentru a satisface un astfel de interes, se recomandă coordonarea în prealabil cu conducerea publicării subiectelor discutate în raport sau prezența șefului echipei de proiect al clientului la un interviu.
Pe baza acestuia, este dezvoltat un produs intermediar „Plan de sondaj”, iar din acesta este derivat produsul „extern” „Programa de sondaj”. Produsul „Program de inspecție” este considerat gata atunci când este convenit cu clientul. În acest moment, avem o idee clară despre cum va avea loc examinarea. Ca urmare a Planului de anchetă, produsul „intern” este setul de materiale care alcătuiesc Rezultatele sondajului — tot ceea ce este colectat ca parte a sondajului. În continuare, este produs un „Raport de sondaj” - rezultatul principal al etapei. Produsul „opțional” „Prezentarea rezultatelor sondajului” poate fi derivat din acesta.
Etapa 2: Proiectare
Scopul fazei de proiectare este de a propune și de a conveni cu clientul soluții organizatorice și tehnice care vor sta la baza sistemului de management IT care este creat. Principalele rezultate ale etapei sunt „Modelul sistemului de management IT” și „Descrierile (regulamentele) proceselor” care îl detaliază.
Model de proces
Forma
Document text, prezentare (mai ales).
Scop
Modelul de proces este un set de caracteristici cheie ale sistemului de control care este creat. Acestea sunt cele mai costisitoare elemente de proiectare ale unui viitor sistem care trebuie decise la începutul proiectului pentru a evita o reluare semnificativă. Modelul de proces este compact, conține doar ceea ce este important și este convenabil pentru discuție și acord.
Pe baza căruia se dezvoltă
Constrângerile inițiale în dezvoltarea modelului de proces sunt definirea proiectului în organizație și prevederile corespunzătoare din contractul cu contractantul. De regulă, compoziția proceselor - subsisteme ale viitorului sistem de control - este predeterminată. Obiectivele proiectului sunt cunoscute și aprobate, de exemplu, „Implementarea în cadrul Departamentului a unei abordări de proces IT centrate pe nevoile afacerii. Implementarea elementelor „bune practici” globale de management IT”.
Sursele externe utilizate în dezvoltarea modelului sunt standardele acceptate, „cele mai bune practici” și experiența anterioară membrii echipei.
Principala sursă de dezvoltare a proiectului este raportul sondajului, sau mai degrabă o descriere a practicii curente și a blocajelor din acesta. Noul model ar trebui să păstreze practicile de management care funcționează bine și să abordeze punctele slabe.
În descrierea modelului de proces, este logic să ne bazăm pe împărțirea utilizată pe scară largă a sistemului în trei componente - „procese”, „oameni”, „instrumente de automatizare”.
Pentru fiecare proces, de regulă, modelul surprinde următoarele elemente de decizie:
- Termeni și definiții;
- Profilul standardelor aplicabile și al practicilor de management;
- Nivelul de maturitate țintă și caracteristicile acestuia;
- Obiectivele procesului;
- Intrări și ieșiri (rezultate) procesului;
- Obiecte informative;
- Tipuri de activități, schema generală a procesului.
Setul de alte caracteristici cheie (cu alte cuvinte, „politici”) incluse în model este specific fiecărui proces. Pentru managementul incidentelor, acesta poate fi numărul de linii de asistență, organizarea biroului de asistență (centralizat sau distribuit, rezolvare sau înregistrare), metodele acceptate de contact cu biroul de asistență.
Ca parte a structurii de rol a sistemului („oameni”), modelul definește compoziția și responsabilitatea rolurilor pentru tipurile de activități ale proceselor. Pentru fiecare rol, ar trebui evaluată posibilitatea de a numi sau angaja personal. Dacă este necesară modificarea structurii organizatorice, aceasta trebuie indicată în mod explicit.
În ceea ce privește instrumentele de automatizare, dacă acestea nu au fost încă selectate și achiziționate până în acest moment, atunci modelul de proces include o listă de instrumente software planificate pentru utilizare și determină necesitatea și metodele de integrare cu sistemele aferente (surse de date despre angajați, inventar). sisteme, program de e-mail etc.). .d.).Pentru a preveni ca modelul de proces să devină material de marketing sau, să zicem, un auto-raport al echipei de proiect (pe care am dori să economisim bani), se recomandă includerea acelor elemente ale sistemului pentru care s-au discutat opțiuni alternative de proiectare.
Modelul este produsul central al scenei. Dezvoltarea și aprobarea modelului are loc în mai multe iterații cu implicarea celui mai larg grup de lucru al clientului. Greșelile făcute în timpul dezvoltării modelului se vor face simțite cu siguranță în etapele ulterioare ale proiectului. Prețul emisiunii: cel puțin o prelucrare semnificativă a rezultatelor deja obținute și nemulțumirea clienților. Pe baza modelului convenit, „Schemele de proces” sunt dezvoltate ca pas intermediar în dezvoltarea „Descrierea (reglementărilor) proceselor”.
Reglementarea procesului
Forma
Un document text care conține diagrame grafice.
Scop
După citirea regulamentelor, participanții la proces și părțile interesate (de exemplu, auditorii) ar trebui să își facă o idee despre următoarele lucruri: în ce scop și ce acțiuni sunt efectuate în cadrul procesului (fără o descriere detaliată a modului exact) și cine este responsabil pentru ce.
Pe baza căruia se dezvoltă
Un semifabricat pentru elaborarea reglementărilor este un model de proces. Activitățile convenite anterior sunt împărțite în proceduri, participanții la proceduri și cei responsabili sunt determinați. Procedurile în sine, tranzițiile condiționate și necondiționate între ele sunt descrise, mai detaliat - la punctele de transfer de control.
Regulamentul este o descriere formală legată logic a activităților procesului, cu indicarea celor responsabili. Iată o structură aproximativă a regulamentului (să luăm managementul incidentelor):
- Termeni și definiții;
- Dispoziții generale:
- Scopurile și obiectivele procesului;
- Beneficiile procesului;
- Domeniul de aplicare și limitele procesului;
- Intrări în procesul de management al incidentelor;
- Rezultatele procesului de management al incidentelor;
- Schema generală și descrierea procesului;
- Instrumente de proces;
- Rolurile și responsabilitățile participanților la proces:
- Roluri funcționale;
- Matricea de responsabilitate;
- Reglementarea procesului:
- Recepție și înregistrare;
- Clasificare și suport primar;
- Programare;
- Permisiune, executare;
- închidere;
- Proprietate;
- Valori de proces:
- Componentele și rapoartele furnizate de proces;
- Anexa A - Reguli de clasificare;
- Anexa B - Reguli de stabilire a priorităților;
- Anexa B - Reguli de escaladare.
Pentru ca regulamentul să fie folosit în scopul propus, adică să fie citit până la sfârșit, se recomandă ca toate detaliile care distrag atenția care încalcă o descriere conectată logic să fie plasate în aplicații sau în alte documente (specificații și instrucțiuni).
Etapa 3: Dezvoltare
Scopul etapei de dezvoltare este crearea de instrumente de automatizare și dezvoltarea documentației procesului.
Pe baza „Descrierilor (regulamentelor) proceselor” sunt elaborate „Specificațiile procesului”. Pentru fiecare proces de management din sistem, sunt dezvoltate trei specificații: „Specificație pentru fluxul de lucru”, „Specificație pentru metrici” și „Specificație de integrare”. Pe baza acestora, sunt dezvoltate „Scenarii de testare SA”.
Specificația procesului
Forma
Document text.
Scop
Caietul de sarcini de proces detaliază prevederile regulamentului. Dacă regulamentul stabilește ce și în ce secvență se efectuează în proces, atunci caietul de sarcini răspunde la întrebarea: cum exact și cu ce rezultate sunt efectuate procedurile. Ca document de proiectare, specificația conține cerințele funcționale de bază pentru dezvoltarea unui sistem automatizat. În viitor, este folosit ca bază pentru compilarea scenariilor de testare și a instrucțiunilor de lucru pentru participanții la proces.
Pe baza căruia se dezvoltă
Specificația este elaborată pe baza regulamentului și detaliază procedurile sale, ținând cont de limitările și capacitățile instrumentelor de automatizare selectate.
În specificație, procedurile de proces sunt împărțite într-o secvență de pași - operații elementare ale participanților la proces (utilizatori de sistem). Structura descrierii procedurii este aproximativ următoarea:
- Descrierea procedurii:
- Numărul (identificatorul) procedurii;
- Denumirea procedurii;
- Descrierea procedurii (din regulament);
- Executant responsabil (rol);
- Intrarea în procedură (un eveniment care activează procedura);
- Operațiuni.
Pentru fiecare operație, specificați:
- Numărul operațiunii;
- Numele operațiunii;
- Actiuni luate;
- Rezultatul operațiunii.
După introducerea în funcțiune a sistemului de control, pentru a reduce costurile de întreținere, se recomandă efectuarea mai întâi de modificări la reglementări și specificații, iar apoi „decuparea” instrucțiunilor și scenariilor din caietul de sarcini.
Paralel lucru în curs pentru crearea instrumentelor de automatizare: se creează un produs intermediar „Stand de bază CA (sisteme de automatizare)”, apoi „Sport de lucru CA” - prin montarea standului de bază conform specificațiilor. Produsul „extern” „SA Experimental Bench” este obținut pe baza „SA Workbench” și a setului „SA Testing Scenarios”: prin eforturile unei echipe de testeri și ingineri, sistemul de automatizare este pregătit pentru demonstrație. către client, instruire și operare de probă.
Pe baza specificațiilor și a „SA Experimental Stand”, un set de produse „SA User Instructions” este în curs de dezvoltare. Produsul „extern” rezultat al etapei este o „Demonstrație de CA” pentru echipa de proiect a clientului.
Produsele „externe” opționale în această etapă pot fi: „Termeni de referință” (pe baza specificațiilor), „Metode de testare” (pe baza „Scenariilor de testare”), „Descrierea cardului de punctaj” (pe baza unui set de „Specificații de măsură”) .
Etapa 4: Implementare
Scopul fazei de desfășurare este pregătirea obiectului de control pentru un experiment sau experimental uz industrial sisteme de automatizare.
Plan de operare pilot (pilot).
Forma
Document text, plan în MS Project.
Scop
Documentul servește ca instrument de planificare și organizare a acțiunilor comune ale participanților pentru a asigura atingerea obiectivelor operațiunii de testare într-o perioadă specificată (de obicei, de la două săptămâni la o lună și jumătate).
Pe baza căruia se dezvoltă
Planul include două secțiuni majore: regulile de desfășurare a operațiunii de probă și planul în sine.
Procedura de operare pilot răspunde la următoarele întrebări:
- Ce obiective trebuie atinse?
- Care este intervalul de timp pentru operațiunea de probă?
- Ce departamente și angajați sunt implicați?
- Ce roluri în procese le sunt atribuite?
- Ce fel materiale didactice disponibile membrilor și unde sunt publicate?
- Cui și cu ce întrebări să vă adresați, în ce termeni și cum?
- În ce mod sunt utilizate sistemele și tehnologiile „vechi”?
- Vor fi aduse modificări sistemului în timpul funcționării de probă?
Planul de operare de probă include o listă de etape și sarcini care indică responsabilul, durata și momentul pentru fiecare eveniment. Exemple de astfel de activități pot fi „lansarea și testarea primirii solicitărilor utilizatorilor folosind interfața Web”, „efectuarea unui audit de configurare”.
Rezultatele acestei etape sunt în mare parte „externe” – vizibile pentru client. Dacă urmați structura obișnuită de „oameni”, „procese” și „instrumente de automatizare”, acestea sunt următoarele produse: „Personal instruit”, „ Evenimente organizatorice” (pentru a lansa și începe operarea sistemului de management IT) și „Instrumente de automatizare” implementate la sediul clientului. Pentru a obține aceste rezultate, se elaborează și se agreează cu clientul un „Plan de instruire”, „Plan de implementare SA”, „Plan de emitere a comenzilor și comenzilor” la începerea operațiunii pilot. În paralel, în interesul etapei următoare, se dezvoltă un produs „extern” „Plan de operare pilot”.
Etapa 5: Operare pilot
Scopul fazei pilot este testarea sistemului de management IT în conditii de lucru pe site-ul clientului. Pe baza Planului de operare pilot, pe parcursul etapei, se formează un produs „intern” „Rezultatele operațiunii pilot”, pe baza căruia se vor realiza produsele „externe” „Raport de operare pilot” și „Protocol de observații și îmbunătățiri”. pregătit. Un produs „extern opțional” al etapei ar putea fi o „Prezentare a rezultatelor operațiunii pilot”.
Etapa 6: Punerea în funcțiune
Evenimentul central al fazei de punere în funcțiune este introducerea sistemului de management IT în regim de producție. Pentru a face acest lucru, este necesar să se elimine comentariile formulate în etapa de operare pilot. Pe baza „Standului experimental SA” și a „Protocolului de observații și îmbunătățiri”, este în curs de dezvoltare un produs „extern” „Stand industrial SA”. Etapa rezultată și proiectul în ansamblu este produsul „extern” „Prezentarea rezultatelor proiectului”.
După finalizarea proiectului: Suport tehnic și întreținere
Din punct de vedere al planificării și organizării muncii, suportul tehnic și întreținerea sistemului de management IT are mai degrabă o natură de proces decât de proiect și este construită conform altor reguli. Prin urmare, pe harta noastră, produsele proiectului legate de activitățile de suport și întreținere nu sunt reflectate.
Astfel, cu ajutorul hărții produsului, am examinat tehnologia de implementare a proiectului de dezvoltare și implementare a unei „soluții individuale” pentru un sistem de management IT după schema „clasică”. Trebuie remarcat faptul că, pentru simplitatea prezentării, compoziția produselor proiectului a fost simplificată. În hărțile reale pe care le folosim, pentru un produs al proiectului pot fi furnizate mai multe produse intermediare. De exemplu, „Produsul” devine mai întâi „Schița de produs”, apoi, după acceptarea internă, „Designul produsului” și numai după acordul cu clientul - „Produsul” propriu-zis. Cu alte cuvinte, harta poate afișa nu numai produsele și relațiile lor, ci și cicluri de viață produse individuale.
După ce ați compilat o astfel de hartă a produsului, puteți trece la elaborarea unui plan de proiect, de exemplu, folosind Microsoft Project. Produsele proiectului din plan vor fi prezentate sub formă de repere care trebuie detaliate munca de proiectare. Acest lucru necesită ca fiecare set de legături de produse primite să fie formulat ca sarcini pentru fabricarea unui produs pe baza celor anterioare. Estimând durata sarcinilor rezultate din proiect, obținem planul de bază al proiectului.
Mod „iterativ” de implementare a unui sistem de management IT
Metoda „clasică” de implementare este cea mai comună de pe piață servicii de consultanță, este larg popular și testat în timp. Cu toate acestea, are un dezavantaj, sau mai degrabă o caracteristică care în condițiile actuale devine din ce în ce mai importantă atât pentru client, cât și pentru antreprenor. Este vorba de durata. Proiectele de implementare a sistemelor de control în mod „clasic” sunt rareori implementate în mai puțin de trei luni. Dimpotrivă, nu este neobișnuit ca astfel de proiecte să dureze mai mult de un an. În acest timp, condițiile externe în care își desfășoară activitatea societatea se pot schimba,
precum și planuri, priorități de afaceri. Ideea managerilor de servicii IT despre cum ar trebui să funcționeze sistemul de management se transformă. Toți acești factori, precum și erorile de planificare, se acumulează și duc la faptul că în etapele mijlocii și târzii ale proiectului există o dorință crescută de reducere a restanțelor în detrimentul fie al calității, fie al cantității produselor proiectului.
Modul „iterativ” de implementare reduce semnificativ impactul acestor riscuri. Se vizează, în primul rând, posibilitatea ajustării progresului implementării, presupunând o revizuire a planurilor viitoare la fiecare iterație.
Este evident că rezultatul „proiectului iterativ” asupra obiectelor formale de livrare nu trebuie să difere de „proiectul clasic”. Să aducem schema generala set formal de articole de livrare:
- Oameni:
- Participanții la sondaj;
- Participanții la proiectarea sistemului de control;
- Instruit;
- Participanții la operațiunea pilot;
- Procese (documente):
- Raport al sondajului;
- Model de proces;
- Scheme, descrieri (reglementări) proceselor;
- Specificații;
- Instrucțiuni pentru administratorul de sistem, documentație pentru sistemul de automatizare;
- Instrumente de automatizare:
- Stand de bază al sistemului de automatizare;
- Stand de lucru al sistemului de automatizare;
- Stand cu experienta in sistemul de automatizare;
- Stand industrial al sistemului de automatizare.
Toate aceste produse trebuie obținute în cadrul „proiectului iterativ”, așa cum sunt obținute în cadrul „proiectului clasic”.
Iterația implică repetarea. În cazul nostru, se vor repeta următoarele grupuri de sarcini:
- Cercetare (domeniu);
- Determinarea limitelor rezultatului iterației (eliberarea);
- Dezvoltarea lansării, care include:
- Dezvoltare;
- Testarea rezultatului de către dezvoltator;
- Testarea rezultatului de către managerul de activități;
- Acceptarea eliberării de către managerul de sarcini;
- Acceptarea eliberării de către client.
Este evident că „acceptarea lansării” atât în ciclul de mini-dezvoltare, cât și în ciclul principal de iterație duce fie la trecerea la o nouă iterație, fie la o repetare (într-o oarecare măsură) a celei actuale pentru a elimina deficiențe.
Deci, am descris ce trebuie să fie obținut (produsele proiectului) și cum vom face acest lucru (un ciclu de iterație). Rămâne să arătăm câte iterații va fi dezvoltat produsul și să detaliem activitatea în cadrul fiecărei iterații. Credem că numărul optim de iterații va fi de trei, a patra și următoarele iterații pot fi bine efectuate în suport tehnicși întreținerea sistemului de management IT. La fel ca și pentru metoda de dezvoltare „clasică”, să luăm în considerare logica obținerii principalelor produse ale proiectului în contextul a trei iterații ale proiectului.
Iterația 1: Dezvoltarea unei versiuni pilot (1.0)
Grupul de sarcini de proiectare „Cercetare” din cadrul primei iterații include o cantitate mare de muncă care, în dezvoltarea „clasică”, este efectuată în etapele de cercetare și proiectare:
- examinare;
- Dezvoltarea modelului.
Apoi se efectuează grupul de sarcini de proiectare „Determinarea limitelor lansării”, care va include următoarele lucrări: - Definirea limitelor lansării în termeni de flux de lucru, metrici și integrare;
- Reconcilierea limitelor de eliberare.
Sarcinile incluse în grupul „Dezvoltare” sunt efectuate pentru a obține un prototip al sistemului, gata pentru demonstrație către client.
Prima iterație a dezvoltării este finalizată de grupul de sarcini de proiectare „Acceptare”, care va include următoarele lucrări:
- Demonstrarea eliberării către grupul de lucru al clientului;
Astfel, în condiții și restricții predeterminate, obținem un fel de soluție completă, de lucru (eliberare pilot), care include următoarele produse:
- Personalul client implicat în sondaj;
- Personalul client implicat in proiectarea sistemului de control;
- Raport al sondajului;
- Model;
- Scheme de proces;
- Set de specificații;
- Limitele de lansare convenite 1.0;
- Stand de lucru SA.
Iterația 2: Dezvoltarea unei versiuni beta (2.0)
Grupul de sarcini de proiect „Cercetare” din a doua iterație are o scară semnificativ mai mică decât pentru lansarea pilot și include o sarcină:
- Test de lansare grup de lucru client.
Grupul de sarcini de proiect „Determinarea limitelor lansării” este format din următoarele lucrări:
- Reconcilierea limitelor de eliberare.
- Luarea unei decizii de rafinare a lansării sau trecerea la următoarea iterație.
Produșii rezultați din iterația 2 sunt:
- Limite agreate ale versiunii 2.0;
- Stand cu experienta SA;
- Descrieri (reglementări) proceselor;
- Instructiuni de utilizare pentru sistemul de automatizare;
- Metodologia programului și testării;
- Personalul client implicat in testarea instrumentelor de automatizare.
Iterația 3: Dezvoltarea versiunii de producție (3.0)
Pentru a obține o versiune industrială, grupul de sarcini de proiect „Cercetare” are ca scop extinderea cercului de participanți pentru o testare mai profundă și mai bună a soluției în condiții cât mai apropiate de reale.
Raport asupra operațiunii pilot (pilot).
Forma
Document text.
Scop
Documentul înregistrează rezultatele evaluării activității participanților la operațiunea-pilot în ceea ce privește obiectivele acestei etape a proiectului și, de asemenea, demonstrează starea actuală a sistemului de control, pregătirea acestuia pentru utilizare industrială și domenii de îmbunătățire.
Pe baza căruia se dezvoltă
Raportul servește la comparație indicatori planificați cu actualul, prin urmare, în dezvoltare sunt utilizate două grupuri de surse de informare. Planul de operare pilot și materialele metodologice pentru participanții la proces (regulamente, instrucțiuni etc.) sunt considerate ca bază de evaluare, iar datele efective sunt formate de participanții la operațiunea pilot în cursul activității și analizate de consultanți în timpul auditului de sistem. .
Un raport tipic conține trei secțiuni: informații generale, evaluarea implementării planului de operare pilot, evaluarea activităților din cadrul proceselor reorganizate.
Informațiile generale sunt, în primul rând, sursele de date și criteriile de evaluare utilizate pentru generarea unui raport. Este de dorit ca criteriile selectate să acopere atât controlul proceselor, cât și execuția procedurilor procesului, precum și rezultatele implementării planului de operare de probă.
Evaluarea implementării planului de operare pilot se realizează pentru fiecare element al planului. În cazul nerespectării totale sau parțiale, sunt indicate motivele. Secțiunea poate conține unele caracteristici cantitative și calitative importante ale rezultatelor, de exemplu, numărul de erori și comentarii.
Evaluarea activităților din cadrul proceselor se realizează conform criteriilor elaborate cu formarea unei evaluări generalizate a succesului lansării fiecărui proces și a sistemului de management în ansamblu. În acest caz, pot fi utilizate instrumente de măsură și raportare care fac parte din sistemul implementat. O componentă utilă a acestei secțiuni a raportului este o descriere a deficiențelor identificate, a riscurilor asociate acestora, precum și recomandări pentru reducerea impactului acestora.
La implementarea unui sistem complex, bogat funcțional pe o suprafață mare (de exemplu, atunci când operațiunea nu este experimentală, ci pilot-industrială), este util să pregătiți un scurt raport intermediar la una sau două săptămâni după lansare.
Grupul va include următoarele:
- Instruirea utilizatorilor sistemului;
- Operare pilot-industrială.
- Formarea unei liste de îmbunătățiri;
- Determinarea modului de implementare a îmbunătățirilor;
- Reconcilierea limitelor de eliberare.
Grupul de sarcini de proiectare „Dezvoltare” din conținutul său repetă și iterația anterioară. Iterația este finalizată de grupul „Acceptare” de sarcini de proiectare, care va include următoarele lucrări:
- Dezvoltarea unui program și metode de testare;
- Acceptarea eliberarii de catre grupul de lucru al Clientului;
- Luarea unei decizii de rafinare a lansării sau trecerea la următoarea iterație.
Deci produsele iterării 3 sunt:
- Manualul administratorului;
- Descrierea setărilor sistemului de automatizare;
- Limite agreate ale versiunii 3.0;
- Stand industrial SA;
- Personal instruit pentru clienți;
- Personalul clientului implicat în operarea de probă.
Astfel, metoda de implementare iterativă asigură că toate produsele cheie ale proiectului sunt disponibile, creând valoare suplimentară sub forma posibilității de revizuire constantă a progresului proiectului. O caracteristică a metodei iterative este că, în urma fiecărei iterații, clientul are un set complet de documente, instrumente de automatizare și personal. Cu acest set, organizația are posibilitatea de a continua dezvoltarea sistemului de management IT în lumina noilor circumstanțe și în condiții noi, până la eliminarea serviciilor unui furnizor terț.
Concluzie
În articol, am vorbit despre câteva opțiuni alternative pentru implementarea unui sistem automatizat de gestionare a activităților unui departament IT. Acestea sunt „Soluția producătorului”, „Cele mai bune practici” și „Soluția personalizată”, care, la rândul lor, pot fi dezvoltate atât în moduri „clasice”, cât și „iterative”.
Opțiunile luate în considerare diferă nu numai prin caracteristicile calitative. Există o diferență semnificativă în momentul și costul proiectului pentru client între configurarea de bază a unui sistem de automatizare „din cutie” și implementarea unei soluții „individuale” dovedite de mai multe ori.
Nu există nicio îndoială că timpul și resursele suplimentare cheltuite de organizație pentru analiza și alegerea metodei de implementare în timpul etapei de pregătire a proiectului sunt compensate printr-o „lovitură” mai precisă a rezultatelor proiectului în bugetul planificat și așteptările părților interesate.
Mult succes cu proiectele tale!
În cursul lucrărilor de creare a sistemelor expert, s-a dezvoltat o anumită tehnologie pentru dezvoltarea acestora, incluzând următoarele șase etape: identificare, conceptualizare, formalizare, implementare, testare, operare de probă și implementare.
Acest articol discută a șasea etapă: operare de probă și implementare.
În etapa de testare și implementare, se verifică adecvarea sistemului expert pentru utilizatorul final. Aici sistemul se ocupă de rezolvarea tuturor sarcinilor posibile atunci când lucrează cu diferiți utilizatori. Este recomandabil să organizați funcționarea sistemului nu la standul dezvoltatorului, ci la locul de muncă al utilizatorului. Ar trebui să treceți la această etapă numai după ce sistemul, potrivit expertului, va rezolva cu succes toate sarcinile necesare, astfel încât erorile din decizii să nu creeze o imagine negativă a sistemului pentru utilizator. Adecvarea sistemului pentru utilizator este determinată în principal de confortul de a lucra cu acesta și de utilitatea acestuia.
Sub utilitate Sistemul este înțeles ca fiind capacitatea sistemului în timpul dialogului de a determina nevoia utilizatorului, de a identifica și elimina cauzele defecțiunilor în muncă și de a satisface nevoile utilizatorului (adică de a rezolva sarcinile stabilite). Cu alte cuvinte, este important ca utilizatorul să „aducă la conștiința” sistemului de care are nevoie de informații, în ciuda posibile greșeli permis de acesta din cauza cunoașterii insuficiente a sistemului. Desigur, completitudinea și corectitudinea soluțiilor sunt importante și pentru utilizator, dar aceste caracteristici ar trebui verificate de un expert în etapa anterioară.
Sub comoditate lucrul cu sistemul este înțeles ca:
- naturalețea interacțiunii cu sistemul, adică comunicare într-o formă familiară, deloc obositoare pentru utilizator;
- flexibilitatea sistemului, de ex. capacitatea sistemului de a se adapta la diferiți utilizatori, precum și de a lua în considerare modificările calificărilor aceluiași utilizator;
- toleranța la erori de sistem, de ex. capacitatea sistemului de a nu eșua din cauza acțiunilor eronate ale unui utilizator neexperimentat.
Pe baza rezultatelor operațiunii, poate fi necesară nu numai modificarea regulilor și a datelor (îmbunătățirea sau modificarea limbii de comunicare, instrumente de dialog, instrumente de detectare și corectare a erorilor, personalizare etc.), ci și modificarea input-output dispozitive din cauza inacceptabilității lor pentru utilizator. Pe baza rezultatelor acestei etape, se ia decizia de a replica sistemul. După finalizarea cu succes a fazei de operare de probă și utilizarea sistemului expert de către diverși utilizatori, acesta poate fi clasificat ca un sistem expert industrial.
În general, în timpul funcționării de probă a prototipului, cerințele pentru sistem sunt clarificate: dezvoltatorii și utilizatorii au posibilitatea de a studia și elimina direct consecințele deciziilor de proiectare luate. Principiul construirii unei interfețe WYSIWYG(What You See Is What You Get - ceea ce vedeți este ceea ce obțineți) permite utilizatorului să evalueze direct rezultatele modificărilor introduse în prototip.
Crearea unui sistem informatic incepe din momentul primelor negocieri intre Client si potentialul Contractor si poate sa nu se termine niciodata, deoarece sisteme bune si utile sunt in permanenta imbunatatite si dezvoltate.
etapa preliminara
În această etapă, este necesar să înțelegem principalele scopuri și obiective ale viitorului proiect. Pentru a face acest lucru, reprezentanții cheie ai Clientului și Antreprenorului organizează întâlniri în care discută despre conceptul de sistem informațional, punctele tehnice cheie, calendarul și sfera lucrărilor efectuate, precum și costul și sursele de finanțare. Rezultatul etapei preliminare, pe lângă termenii conveniți ai viitorului contract, ar trebui să fie primul și cel mai fundamental document de proiect - carta de proiect.
Carta proiectului definește următoarele puncte fundamentale legate de procesul de dezvoltare și implementare a unui sistem informațional:
- Scurtă descriere a proiectului, scopurile și obiectivele creării unui sistem informațional.
- Descrierea generală a domeniului de activitate.
- Limitele proiectului: termeni, buget, lista obiectelor de automatizare.
- Descrierea produsului: Lista cu hardware-ul furnizat și software, tipul și numărul de licențe etc.
- Structura organizatorică a proiectului: lista și rolurile membrilor echipei de proiect din partea Antreprenorului și a Clientului, responsabilitățile și atribuțiile acestora, sistemul de management al documentelor de proiect.
- Principalele etape de dezvoltare și implementare a sistemului informațional, un program extins pentru implementarea acestora.
- Cele mai semnificative riscuri de neîndeplinire a obligațiilor din cadrul proiectului, precum și modalități de minimizare a riscurilor.
Cu alte cuvinte, carta de proiect este tocmai carta care este elaborată de managerul de proiect împreună cu membrii principali ai echipei de proiect, aprobată de conducerea Antreprenorului și a Clientului, și nu trebuie ajustată pe toată perioada creării. sistemul informatic.
Finalizarea etapei preliminare poate fi considerată momentul în care se semnează contractul de servicii pentru dezvoltarea și implementarea sistemului informațional și se aprobă carta proiectului.
Cerințe de colectare
În acest moment, toate cifrele cheie - participanții la proiect au fost identificate și nimic nu ne împiedică să începem să colectăm și să aprobăm cerințele pentru viitorul sistem informațional. Reprezentanții contractorului comunică cu viitorii utilizatori și administratori ai sistemului, precum și cu managementul acestora. Pe parcursul sondajului, nu sunt sistematizate doar cerințele și dorințele pentru soluția implementată, ci este analizată și documentația, care ar trebui să devină sursa datelor inițiale ale sistemului, sau a cărei formare ar trebui automatizată ca urmare.
Acest pas ar trebui să aibă ca rezultat termeni de referinta pentru dezvoltarea si implementarea sistemului informatic. Termenii de referință ar trebui să se bazeze pe termenii contractului și pe cerințele stabilite în carta proiectului și să conțină următoarele secțiuni (pentru Rusia, structura termenilor de referință este reglementată de GOST 34.602 89):
- Scopul și scopul creării sistemului.
- Descrierea obiectului de automatizare și a principalelor procese de afaceri automatizate.
- Cerințe de sistem: cerințe de structură; funcții (sarcini) rezolvate de sistem; cerințe pentru suport tehnic și organizatoric; cerințe de fiabilitate, siguranță etc. etc.
- Compoziția și conținutul lucrărilor privind crearea unui sistem informațional.
- Ordinea de control și acceptare a rezultatelor muncii.
- Cerințe pentru sfera de activitate pentru pregătirea unui obiect de automatizare pentru punerea în funcțiune a sistemului informațional.
- Cerințe pentru compoziția proiectării și a documentației utilizator.
Finalizarea etapei de colectare a cerințelor reprezintă aprobarea Termenilor de referință de către Client. În unele cazuri, înainte de începerea lucrărilor la proiect, Clientul are deja un termen de referință (inclus în documentația de licitație). În acest caz, rezultatele sondajului și colectării cerințelor sunt înregistrate în termeni de referință privat, detaliind și concretizând Cerințe generale la sistemul informatic prezentat în caietul de sarcini inițial.
Proiecta
In aceasta etapa, prin eforturile Antreprenorului, sunt concepute in detaliu toate scenariile legate de dezvoltarea si implementarea unui sistem informatic pe teritoriul Clientului. Aceasta se realizează în conformitate cu condițiile mediului informațional (peisaj de sistem) al Clientului și cerințele pentru integrarea sistemului fiind creat cu altele deja disponibile și operate de către Client. produse software. Rezultatul fazei de proiectare ar trebui să fie proiectarea următoarelor secțiuni proiect tehnic (conceptual).:
- Arhitectura sistemului informatic.
- Descrierea structurilor de stocare a informațiilor (bază de date).
- Soluții de proiectare prezentate printr-o descriere detaliată a scenariilor de automatizare pentru toate procesele de afaceri afectate de implementarea sistemului.
- Scenarii pentru integrarea sistemului informatic dezvoltat cu produse software externe.
- Surse de date inițiale și opțiuni pentru conținutul informațional inițial al sistemului.
- Conceptul de diferențiere a drepturilor de acces la date pe baza rolurilor de utilizator, care determină, printre altele, puterile acestora.
- Conceptul de instruire a utilizatorilor sistemului informatic.
Implementarea
Etapa de implementare a tuturor cerințelor pentru sistemul informatic stabilite în Termenii de Referință și Proiectul Tehnic. În această perioadă, Antreprenorul dezvoltă toate componentele software necesare, creează structuri de baze de date, instalează, configurează și testează toate componentele sistemului informațional de pe teritoriul său, simulează scenarii de integrare etc. etc. Finalizarea fazei de implementare este confirmată de apariția acestora documentele de proiect ca ghid pentru instalarea și configurarea sistemului, programul și procedura de testare sistem, precum și un șablon de bază de date și un registru al tuturor dezvoltărilor software finalizate.
Pregatirea sistemului informatic pentru functionare
Toate lucrările din această etapă se desfășoară deja la sediul Clientului și includ instalarea și configurarea tuturor componentelor sistemului în mediul informațional al Clientului, testarea preliminară, dezvoltarea documentației utilizatorului, instruirea utilizatorilor, încărcarea datelor inițiale, testarea în conformitate cu prevederile program și metodologie și alte lucrări pregătitoare.
Până la finalizarea tuturor lucrărilor pregătitoare, procedura de operare a sistemului ar trebui să fie dezvoltată și aprobată. Regulamentul, în special, ar trebui să definească utilizatorii și rolurile acestora în sistem, în conformitate cu responsabilitățile lor.
Operare pilot
Ultima etapă a dezvoltării și implementării inițiale a unui sistem informatic, a cărei sarcină este de a efectua cu succes o operațiune de probă a sistemului pentru un anumit timp, iar scopul este de a confirma că sistemul informațional creat este exact rezultatul că Clientul asteptat.
În această perioadă, utilizatorii încep să opereze sistemul în conformitate cu reglementările elaborate în etapa anterioară. În timpul operațiunii pilot, erorile sunt remediate și sunt convenite îmbunătățirile necesare. Antreprenorul elimină erorile, efectuează îmbunătățiri și, cu condiția ca sistemul să înceapă să funcționeze în conformitate cu toate cerințele care i-au fost prezentate anterior, la sfârșitul perioadei stabilite, primește un protocol privind finalizarea cu succes a operațiunii pilot.
Odată cu finalizarea operațiunii pilot, de regulă, contractul de realizare a unui sistem informatic încetează. Sistemul propriu-zis intră în exploatare comercială, iar Antreprenorul, dacă Clientul este interesat de acest lucru, încheie un contract separat de întreținere a acestuia, pe perioada stabilită prin termenii contractului.
Întreținerea și dezvoltarea sistemului
Operarea industrială poate dezvălui că unele cerințe pentru sistemul informațional creat conțineau inexactități și necesită o formulare sau completări diferite, iar sistemul în sine trebuie îmbunătățit. Nu fiecare Client are personal în personalul său care este capabil să introducă în mod independent toate schimbările dictate de situația reală în sistem, prin urmare, încheie un acord separat cu Antreprenorul pentru întreținerea sistemului informațional.
Utilizatorii sistemului informatic încep să comunice cu reprezentanții serviciului de asistență al Clientului, care primesc solicitări de la aceștia pentru îmbunătățirea funcționalității și eliminarea defectelor, solicitări de transfer de lucru și anunță periodic utilizatorii cu privire la starea solicitării lor. Lista posibilelor îmbunătățiri și procedura de procesare a cererilor este determinată de termenii contractului. Dacă există o nevoie de lucrări care nu se încadrează în esența contractului de asistență, atunci Clientul și Antreprenorul întocmesc un contract separat pentru această specie lucru, care poate fi deja atribuit lucrărilor de modernizare și dezvoltare a sistemului informațional operat.
Teste preliminare
Testele preliminare EIS pot fi autonome și complexe.
Programul de teste autonome indică:
lista de funcții de testat;
descrierea relației obiectului de testare cu alte părți ale EIS;
condiții, procedură și metode pentru efectuarea testelor și a rezultatelor prelucrării;
· Criterii de acceptare a pieselor bazate pe rezultatele testelor.
Un program de testare offline ar trebui să fie atașat programului de testare offline.
Testele (cazurile de testare) pregătite și coordonate în etapa de testare autonomă ar trebui să ofere:
Verificarea completă a funcțiilor și procedurilor conform listei convenite cu clientul;
acuratețea necesară a calculelor, stabilită în TOR;
Verificarea principalelor caracteristici temporale ale funcționării software-ului;
Verificarea fiabilității și stabilității funcționării software-ului și hardware-ului.
Rezultatele testelor autonome ale pieselor EIS sunt consemnate în rapoartele de testare. Protocolul trebuie să conțină o concluzie privind posibilitatea admiterii unei părți din EIS la teste complexe. Dacă testele autonome efectuate se dovedesc a fi insuficiente sau se dezvăluie o încălcare a cerințelor documentelor de reglementare privind compoziția sau conținutul documentației, partea specificată a EIS poate fi returnată pentru revizuire și numită. termen nou teste.
Teste complexe EIS se realizează prin efectuarea de teste complexe. Testul cuprinzător ar trebui:
să fie conectat logic;
· să asigure verificarea performanței funcțiilor părților EIS în toate modurile de funcționare;
· să asigure verificarea reacției sistemului la informații incorecte și urgențe.
Rezultatele testului sunt reflectate în protocol. Lucrarea se finalizează cu executarea certificatului de recepție la exploatare de probă.
În programul de teste complexe ale EIS indicați:
o listă de obiecte de testare;
componența documentației depuse;
o descriere a relațiilor care trebuie testate între obiectele de testare;
secvența părților de testare ale EIS;
· procedura și metodele de testare, inclusiv compoziția software-ului și a echipamentelor necesare pentru testare, inclusiv standuri speciale și locuri de testare.
Protocolul de testare integrat ar trebui să conțină o concluzie cu privire la posibilitatea (imposibilitatea) acceptării EIS pentru operarea de probă, precum și o listă a îmbunătățirilor necesare și a termenelor limită recomandate pentru implementarea acestora.
Operațiunea de probă se efectuează în conformitate cu programul, care indică:
condițiile și procedura de funcționare a părților EIS și a EIS în ansamblu;
· durata operațiunii de probă, suficientă pentru a verifica funcționarea corectă a EIS;
Procedura de eliminare a deficiențelor identificate în timpul operațiunii de probă.
În timpul funcționării de probă a EIS, se păstrează un jurnal de lucru, în care se introduc informații cu privire la durata de funcționare a EIS, defecțiuni, defecțiuni, urgențe, modificări ale parametrilor obiectului de automatizare, ajustări în curs ale documentației și software, ajustare și mijloace tehnice. Informațiile se consemnează în jurnal cu data și persoana responsabila. Jurnalul poate conține comentarii ale personalului cu privire la ușurința de operare a EIS.
Pe baza rezultatelor operațiunii de probă, se ia o decizie cu privire la posibilitatea de a prezenta părți ale EIS și a sistemului în ansamblu pentru testele de acceptare.
Lucrarea se încheie cu executarea unui act privind finalizarea operațiunii de probă și admiterea sistemului la teste de recepție.
