3) o descriere a acțiunilor operatorului atunci când lucrează cu programe (reguli de lansare a programelor, ordinea de lucru, acțiuni posibile situatii non-standard etc.).
Descrierea cazului de testare include descrierea:
1) funcțiile și parametrii software-ului testați de cazul de testare;
2) compoziția mijloacelor tehnice necesare pentru a testa software-ul din acest exemplu;
3) informații de intrare;
4) rezultatele rulării programelor conform exemplului de control;
5) acțiunile operatorului la verificarea programului pe un exemplu de control;
6) rezultatele verificării (standard de control) a programelor pe un exemplu de control.
Procedura de transfer a documentației programului
Toate programele și instrucțiunile verificate de dezvoltator pe un exemplu de control sunt predate clientului în baza unui act care certifică acceptarea acestora pentru funcționarea de probă.
Predată clientului software, instrucțiunile și descrierile algoritmilor trebuie să respecte cerințele privind compoziția și conținutul proiectului de lucru Sistem informatic. Clientul primește programe înregistrate pe suport magnetic. Clientul pune la dispoziție dezvoltatorului suportul magnetic și timpul de calculator necesar pentru punerea în funcțiune a programelor de probă și duplicarea acestora (dacă este necesar).
Acceptarea unui set de sarcini (subsisteme) pentru operarea de probă constă în rezolvarea unui caz de testare de către personalul client special instruit în prezența reprezentanților dezvoltatorului, urmată de analiza rezultatelor. De comun acord, cazul de testare poate fi executat de către dezvoltator în prezența clientului.
Pe baza rezultatelor acceptării, se semnează un act de acceptare a software-ului pentru funcționarea de probă. Descoperit
erorile dezvoltatorului în programe și documentație tehnică sunt eliminate în procesul de punere în funcțiune.
Documentatie organizatorica si administrativa
Pentru principalele lucrări efectuate la etapa „Proiectare detaliată” se întocmește următoarea documentație organizatorică și administrativă:
1) pentru a efectua munca la faza in conformitate cu graficul măsuri organizatorice și tehnice;
2) programul de lucru comun al antreprenorului și clientului;
3) un act de verificare a exemplelor de testare și acceptarea pentru funcționarea de probă a programelor de lucru;
4) un act de pregătire a documentației normative și de referință;
5) un act de implementare a măsurilor organizatorice și tehnice pentru pregătirea întreprinderii pentru implementarea sistemului informațional.
5.5. Punerea in functiune a sistemului informatic
Punerea în funcțiune a sistemului informațional și a acestuia elemente individuale este o tranziție treptată de la metodele existente control la metode de control automat.
Punerea în funcțiune a sistemului informatic este organizată și realizată de către client cu participarea dezvoltatorului și a organizațiilor co-executoare. Interacțiunea organizațiilor clientului, dezvoltatorului și co-executorilor se realizează pe baza unor condiții contractuale și a unui program de punere în funcțiune comercială a sistemului informațional.
Punerea în funcțiune se realizează în etape, începând din etapa de dezvoltare a unui proiect tehnic imediat ce acesta este gata documentatie de lucru si punerea in functiune a mijloacelor tehnice care sa asigure introducerea de cozi sau obiecte ale sistemului informatic capabile de functionare independenta.
Punerea în funcțiune a sistemului informațional ar trebui începută dacă:
1) documente executate privind implementarea planului de acțiuni pentru pregătirea unității;
2) documentație de lucru pentru implementarea unei cozi dedicate sau a unui sistem informațional în ansamblu;
3) personal instruit care asigură instruire pentru punere în funcțiune
operarea si functionarea unei cozi dedicate a sistemului informatic;
4) mijloacele tehnice ale sistemului informatic acceptat în exploatare care asigură funcţionarea complexelor de sarcini implementate.
Organizarea muncii
Implementat:
1) operarea de probă a sarcinilor individuale și a complexelor acestora;
2) acceptarea complexelor de sarcini pentru operare comercială;
3) efectuarea testelor de acceptare;
4) acceptarea sistemului în exploatare comercială.
Compoziția și succesiunea lucrărilor sunt determinate de graficele de punere în funcțiune convenite, care indică componența și calendarul următoarelor lucrări:
1) pentru construcția, montarea, reglarea și testarea obiectelor sistemului informațional din momentul primirii documentației de lucru până la punerea în funcțiune a obiectelor în exploatare comercială;
2) pentru operațiune de probă și teste de acceptare a complexelor de sarcini;
3) pentru a asigura trecerea de la practicile de management existente
La metodele oferite de proiectul sistemului informatic.
În etapa „Punerii în funcțiune a sistemului informațional”
clientul este obligat:
1) execuție completă masuri organizatorice si tehnice pentru pregatirea intreprinderii pentru implementarea sistemului informatic si oficializarea lor prin acte;
2) se asigură că personalul întreprinderii respectă instrucțiunile de muncă și tehnologice;
3) pus în funcţiune mijloace tehnice necesare pentru implementat proces tehnologic procesarea datelor;
4) emite un ordin cu un program de desfășurare a funcționării de probă a sistemului informatic și analizează rezultatele operațiunii de probă împreună cu dezvoltatorul;
5) finalizarea operațiunii de probă a complexelor de sarcini care fac parte din sistemul informațional și acceptarea lor în exploatare comercială;
6) să efectueze modificări în structura organizatorică a întreprinderii în conformitate cu proiectul sistemului informațional;
7) elaborează un proiect de ordin privind componența comisiei de acceptare;
8) elaborați și conveniți cu dezvoltatorul un proiect de program teste de acceptare;
9) organizează activitatea comitetului de acceptare, îi furnizează documentația necesară și testează sistemul informațional;
10) verifică eficacitatea soluțiilor implementate în condițiile de funcționare industrială și, pe baza rezultatelor analizei funcționării sistemului, elaborează recomandări pentru dezvoltarea ulterioară a acestuia.
În etapa „Punerii în funcțiune a sistemului informațional”
dezvoltatorul este obligat:
1) ajusta documentația tehnică pe baza rezultatelor exploatării de probă a sistemului informațional;
2) participa la elaborarea unui proiect de program pentru testele de acceptare a sistemului informatic;
3) efectuează îndrumări metodologice și participă la livrarea sarcinilor (seturi de sarcini) pentru operarea comercială;
4) participă la lucrările comisiei de acceptare a sistemului informațional pentru funcționare comercială.
Procedura de operare de probă
Începutul operațiunii de probă a sarcinilor (complexe de sarcini), termenii de funcționare și componența comisiei pentru acceptarea unei sarcini sau a unui subsistem specific sunt determinate de un ordin emis de client și convenit cu dezvoltatorul. La comanda este atasat un acord cu
un program de operare pilot de către dezvoltator, care definește condițiile de verificare a complexelor de sarcini, procedura de verificare a mijloacelor tehnice la rezolvarea complexelor de sarcini (subsisteme) și procedura de eliminare a deficiențelor identificate în timpul funcționării de probă.
Cerințe suplimentare ale clientului care au apărut în timpul funcționării de probă, care nu sunt prevăzute în termenii de referință și proiectarea tehnică, nu reprezintă un motiv pentru o evaluare negativă a rezultatelor exploatării de probă și pot fi satisfăcute printr-un acord suplimentar în timpul convenit. cadru.
La rezultate pozitive operarea de probă a sarcinilor (subsistemelor), se întocmește un act bilateral la acceptarea acestora în exploatare comercială.
După acceptarea sistemului informatic pentru operare comercială, responsabilitatea pentru funcționarea acestuia în sfera seturilor de sarcini și mijloace acceptate este suportată de client.
Inițial și documente contabile la testarea software-ului sistemului informatic
Testarea comună este efectuată de o comisie a clientului, la care participă managerul de dezvoltare și unii dintre cei mai importanți dezvoltatori. Comisia în timpul testării este ghidată de următoarele documente:
1) aprobat de client și agreat cu dezvoltatorul termenii de referință pentru crearea unui sistem informatic;
2) standardele actuale de stat și din industrie pentru proiectarea și testarea software-ului și documentația tehnică;
3) program de testare pentru toate cerințele tehnice
4) metode de testare pentru fiecare secțiune a cerințelor caietului de sarcini.
Programul de testare, metodele de implementare și evaluare a acestora
rezultatele sunt dezvoltate în comun de către client și dezvoltator și trebuie să fie agreate și aprobate. Acestea conțin clarificări cu privire la cerințele termenilor de referință pentru un anumit sistem și ar trebui să garanteze verificarea corectă a acestora. Documentația pentru sistem ar trebui
să respecte pe deplin programele testate, să se asigure că sistemul este cunoscut de către personalul de exploatare și, de asemenea, să ofere posibilitatea dezvoltării și modernizării programelor pentru a crește durata ciclului de viață al acestora.
Program de testare este un plan pentru o serie de experimente. Este dezvoltat din punctul de vedere al minimizării volumului de testare cu fiabilitatea rezultatelor date și convenite cu clientul. Pentru a face acest lucru, secvența și domeniul de aplicare a fiecărui test în procesul de testare sunt determinate pentru a verifica conformitatea cu cerințele din caietul de sarcini atunci când cost minim. Este deosebit de dificil să alegi un set situatii stresante performanța sistemului sub care urmează să fie efectuate testele. Program de testare ar trebui să conțină următoarele secțiuni clar articulate:
1) obiect de testare, scopul acestuia și o listă a principalelor documente care au determinat elaborarea acestuia;
2) scopul încercărilor, indicând principalele cerințe ale caietului de sarcini care trebuie verificat și restricțiile privind efectuarea testelor;
3) de fapt program de testare care conțin o verificare a caracterului complet al sistemului dezvoltat în conformitate cu termenii de referință și un plan de testare pentru verificarea funcționării programelor în toate secțiunile caietului de sarcini și cerințe suplimentare, formalizat prin decizii separate;
4) metode de testare, care definesc fără ambiguitate toate conceptele caracteristicilor de verificat, condițiile de testare, mijloacele folosite pentru testare, metodele de prelucrare și evaluare a rezultatelor testelor pentru fiecare secțiune a programului de testare.
Cantitate mare de date de testare eterogene
software și varietate modalități posibile prelucrarea, interpretarea şi evaluarea acestora conduc la faptul că cei mai importanți factori pentru procesarea rezultatelor testelor devin metode de procesare și evaluare a rezultatelor. În conformitate cu metodele de testare, instrumentele de automatizare trebuie să asigure integralitatea verificărilor caracteristicilor pentru fiecare secțiune a metodelor și dezvoltarea
protocoale de verificare pentru punctele programului de testare. Complexitatea software-ului și relația strânsă dintre diferitele sale caracteristici duc la necesitatea formulării cu atenție a tuturor condițiilor de testare și a valorilor parametrilor în baza cărora ar trebui să fie efectuat testul.
Rezultatele testelor sunt înregistrate în protocoale , care conțin de obicei următoarele secțiuni:
1) scopul încercării și secțiunea cerințelor din specificațiile tehnice, în conformitate cu care se efectuează încercarea;
2) indicarea metodelor în conformitate cu care au fost efectuate testele, prelucrarea și evaluarea rezultatelor;
3) condiţiile de testare şi caracteristicile iniţialei
4) rezultatele testelor generalizate cu evaluarea lor pentru conformitatea cu cerințele din caietul de sarcini și din alte documente de reglementare;
5) concluzii despre rezultatele testelor și gradul de conformitate a software-ului creat cu o anumită secțiune a cerințelor termenilor de referință.
Protocoalele pentru întregul program sunt rezumate într-un act, în urma căruia
se face o concluzie asupra conformității sistemului cu cerințele clientului și asupra finalizării lucrării cu rezultat pozitiv sau negativ. Când toate cerințele din caietul de sarcini sunt îndeplinite în totalitate, clientul este obligat să accepte sistemul și lucrarea este considerată finalizată.
Cu toate acestea, după cum sa menționat deja, pentru complexele software complexe este dificil să se prevadă și să se formuleze corect toate cerințele specificațiilor tehnice în etapele inițiale de proiectare. Prin urmare, în timpul depanării și testării, se dovedește adesea că unele cerințe ale specificațiilor tehnice nu sunt îndeplinite și, uneori, chiar și în principiu nu pot fi îndeplinite cu cea mai conștiincioasă atitudine față de acest lucru din partea dezvoltatorului. În acest caz, munca în comun a clientului și a dezvoltatorului este necesară în căutarea unei soluții de compromis la finalizarea testelor și la elaborarea unei concluzii. Unele deficiențe ale complexului de programe în timpul procesului de testare sunt doar înregistrate și remediate în ceea ce privește eliminarea comentariilor comisiei,
efectuarea testelor. Acest plan este o anexă la raportul privind rezultatele testelor și vă permite să separați îmbunătățirile ulterioare de testele directe.
Procedura de efectuare a testelor de acceptare
Clientul este responsabil pentru organizarea și efectuarea acceptării pentru operațiune comercială. Acceptarea sistemului informatic pentru exploatarea comercială se realizează la finalizarea acceptării de către client a tuturor seturilor de sarcini (subsisteme) pentru exploatarea comercială.
Sarcinile, seturile de sarcini (subsisteme) și mijloacele tehnice ale sistemului informatic care nu sunt prevăzute în caietul de sarcini, dar implementate de către client în mod independent, pot fi incluse în complexul sistemului informatic urmând a fi predate numai cu acord. cu dezvoltatorul și după efectuarea modificărilor corespunzătoare în termenii de referință pentru crearea sistemului informațional.
La cererea clientului sau dezvoltatorului, în acceptarea sistemului informatic pot fi implicați reprezentanți ai organizațiilor subcontractante.
Clientul prezinta sistemul informatic comitetului de acceptare. Pe lângă membrii comisiei, experți pe probleme specifice crearea de sisteme informatice. Clientul este obligat sa asigure conditiile normale de lucru ale comisiei in conformitate cu programul acceptat de acceptare a sistemului informatic. Pentru decizie promptă probleme organizatorice apărute în procesul de acceptare a sistemului informațional, prin ordin al șefului organizației de dezvoltare, este alocat un reprezentant responsabil din cadrul organizației de dezvoltatori.
Clientul, împreună cu dezvoltatorul, pregătește un proiect de program pentru testarea și acceptarea sistemului informațional și îl prezintă comitetului de acceptare pentru examinare și aprobare. Programul indică: denumirea sistemului informatic ce urmează a fi predat, documentele directive pe baza cărora a fost elaborat sistemul (dacă este cazul), componența comitetului de acceptare și numărul comenzii privind numirea acestuia, scopul, obiectele , volum, loc și
succesiunea testelor, metodologia de realizare a testelor si evaluarea rezultatelor.
Clientul pregătește împreună cu dezvoltatorul și transferă următoarele documente pentru utilizare temporară comisiei:
1) comenzi, instructiuni, planuri, contracte care prevad realizarea unui sistem informatic;
2) tehnice si economice justificare, sarcină tehnică, proiect tehnic, proiectul de lucru al sistemului informatic;
3) acte de luare în considerare și aprobare a proiectului tehnic;
4) acte bilaterale ale clientului și dezvoltatorului privind livrarea sarcinilor, complexelor de sarcini (subsisteme), dispozitivelor și complexelor acestora pentru funcționare comercială în conformitate cu termenii de referință aprobați.
Comisia de acceptare prevede:
1) verificarea documentatiei si functionarii sistemului informatic;
2) organizarea grupurilor de lucru și repartizarea responsabilităților între membrii comisiei pentru testarea subsistemelor individuale;
3) verificarea calculelor eficiență economică sistem informatic creat;
4) organizarea de ateliere și pregătirea actelor de acceptare a sistemului informațional.
Verificarea condițiilor de funcționare și a modului de funcționare a tehnicilor
mijloacele sistemului informațional se realizează concomitent cu verificarea funcționării complexelor de sarcini (subsisteme). Pregătirea personalului responsabil cu funcționarea sistemului informațional se determină în conformitate cu programul de instruire și descrierea postului incluse în proiectul de lucru. Rezultatele auditului sunt discutate la ateliere și documentate în minute.
Etapa finală a lucrărilor comisiei este întocmirea unui act, care indică:
1) componența comisiei, funcțiile și locurile de muncă ale membrilor comisiei;
2) termenul (data) de acceptare a sistemului;
3) componența interpreților (organizații, întreprinderi) care au participat la realizarea sistemului informațional;
4) motivele de acceptare (comenzi, instrucțiuni și
5) lista cu documentația depusă a sistemului informatic
și evaluarea conformității acestuia cu curentul documente normative și tehnice;
6) conformitatea lucrărilor efectiv executate și implementate cu termenii de referință;
7) pregătirea tuturor tipurilor de sprijin și diviziuni structurale clientului la implementarea și funcționarea sistemului informațional;
8) informații despre eficiența sistemului informațional (compararea datelor reale disponibile sau așteptate privind volumul și sursele de economii obținute cu datele calculate);
9) concluziile comisiei privind posibilitatea de acceptare a sistemului informatic;
Actul de acceptare în cinci exemplare este semnat de președinte și de toți membrii comisiei. Data punerii in functiune a sistemului informatic este data semnarii actului de catre comisie.
6. Echipa de dezvoltatori de sisteme informatice
Întrucât crearea unui sistem informațional modern este un proces complex care necesită eforturile comune ale unui număr mare de specialiști diferiți, formarea unei echipe implicate în proiectarea, dezvoltarea și implementarea unui sistem informațional, în conditii moderne devine foarte important.
Organizarea echipei și repartizarea muncii între specialiști pot fi realizate după mai multe principii:
1) bazat pe distribuție analiza de sistem(algoritmizare) si dezvoltare de programe pentru diferite echipe;
Sistem de management IT: trei componente...
În contextul acestei probleme, prin sistemul de management IT ne vom referi la un sistem automatizat de gestionare a 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 serviciu și orientarea întregului personal în vederea 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 despre implementare comercială sau privind prestarea serviciilor 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 specific ITSM 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 set de instrumente hardware și software care automatizează activitățile din cadrul proceselor. Nu vom da atentie speciala software-ul în sine, să spunem asta piata moderna există multe soluții software specializate specifice industriei.
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 cu privire la necesitatea schimbării sistemului de management IT (lansarea unui proiect ITSM), începe etapa de planificare. Aici sunt instalate parametri cheie proiectul, componentele (sarcinile) acestuia sunt alocate, se determină cantitatea necesară de resurse, se realizează succesiunea lucrărilor și se stabilește bugetul.
În această etapă, organizația ia un număr 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. Instrumente comune de căutare cele mai bune solutii 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” de comparare a 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: ceea ce va fi luat ca bază sistem creatîn ce măsură şi în ce mod acest cadru va fi rafinat 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 antreprenorului.
În opinia noastră, o alegere insuficient definită a metodei de dezvoltare presupune riscuri mari abateri fatale de la plan (adică cele care necesită reprogramare și clarificări semnificative 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.
Cu toată varietatea de platforme și bogăția de funcționalități disponibile pe piață a instrumentelor software specializate din clasa „industrială”, organizația are la dispoziție doar trei moduri alternative folosindu-le pentru a construi un sistem de control. 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 mult mod garantat 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. Lucrarea integratorului privind configurarea 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. Se integrează și cu sistem postal 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 automate suficient pentru funcționare. Pe lângă instalarea și completarea manualelor, implementarea unei astfel de soluții implică 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. Acest solutii la cheie 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 (platforma) potrivit și a integratorului potrivit.
Cea mai puțin previzibilă și, prin urmare, mai interesant de luat în considerare din punctul de vedere al participanților la proiect este „Soluția individuală”, în cadrul căreia, în primul rând, proiectarea și dezvoltarea unui anumit organizatie specifica sisteme. 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 baza metodologica proiectarea și implementarea soluțiilor individuale, în caz 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 a unui sistem informațional. 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 linii directoare specifice, cerințe, proprietăți și indicatori de calitate care caracterizează modul în care este organizată dezvoltarea și implementarea 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 Parte substanțială solutii de proiectare predeterminat şi cunoscut interpretului. 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 metodologica Maparea produselor este metoda de planificare bazată pe produs de la Prince2, 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, sumă uriașă greșeli, dispute ideologice fundamentale, descoperiri bruște, încercări care au rezistat timpului și proiectelor 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:
- Formă;
- Programare;
- Conţinut;
- Opțiuni, recomandări.
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:
În cazul metodei „clasice” de implementare, etapele sunt foarte importante, întrucât rezultatele obținute la finalul etapei (produsele de proiect) stau la baza următoarea etapă, iar revizuirea lor este practic imposibilă fără a face modificări în proiect. Luați în considerare principalele produse ale proiectului în fiecare etapă.
Obiectivele etapei sondajului sunt două: să vă faceți o idee despre practica curentă în domeniul subiectului și să clarificați enunțul problemei. Rezultatul principal 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
Formă
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 implementării sistem nou(a fost - a devenit). Î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 întocmesc un raport pe baza notelor lor luate în timpul interviului, precum și pe bază documentele colectate organizații: regulamente, instrucțiuni și așa mai departe. Acuratețea și calitatea sunt proporționale cu calificările consultanților și cu 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: informații generale, descriere situatia actuala, concluzii.
Informațiile generale sunt obiectivele declarate ale sondajului, limitele anchetei (organizaționale și funcționale), lista documentelor utilizate și persoanele intervievate. Acesta oferă, de asemenea, 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 chestionate ale activității organizației, structură unică descrieri. 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, însă, î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 afacerilor. Pentru a satisface un astfel de interes se recomanda coordonarea in prealabil cu conducerea publicarii subiectelor discutate in raport sau prezenta la un interviu a liderului echipei de proiect al clientului.
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 sondaj, 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.
Scopul etapei de proiectare este de a propune și conveni cu clientul organizațional și solutii tehnice care va sta la baza sistemului de management IT creat. Principalele rezultate ale etapei sunt „Modelul sistemului de management IT” și „Descrierile (regulamentele) proceselor” care îl detaliază.
Model de proces
Formă
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 scumpe elemente de design. viitorul 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ă. Scopurile proiectului sunt cunoscute și aprobate, de exemplu, „Implementarea în cadrul Departamentului a unei abordări de proces IT centrată pe nevoile afacerii. Implementarea elementelor „bune practici” globale de management IT”.
Sursele externe utilizate în dezvoltarea modelului sunt standardele acceptate, „bune practici”, precum și experiența anterioară a membrilor echipei.
De bază sursa de proiectare evoluții - un raport asupra sondajului, sau mai degrabă o descriere a practicii curente și a „obstacolelor” din acesta. Model nou ar trebui să mențină practici de management funcționale și să elimine deficiențele.
Î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 se fixează următoarele elemente solutii:
- 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, de rezolvare sau de înregistrare), metode suportate 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 variante 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
Formă
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 proces (fără descriere detaliata cum) ș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:
- Componente și rapoarte furnizate de proces;
- Anexa A - Reguli de clasificare;
- Anexa B - Reguli de stabilire a prioritatilor;
- 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 alte documente (specificații și instrucțiuni).
Scopul etapei de dezvoltare este crearea instrumentelor de automatizare și elaborarea 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 flux de lucru”, „Specificație de metrică” și „Specificație de integrare”. Pe baza acestora, sunt dezvoltate „Scenarii de testare SA”.
Specificația procesului
Formă
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. Cum document de proiect caietul de sarcini conține principalul cerințe funcționale pentru dezvoltare 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 acestuia, ț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: Sarcina tehnică”(pe baza specificațiilor), „Metodologie de testare” (pe baza „Scenariilor de testare”), „Descrierea cardului de punctaj” (pe baza unui set de „Specificații de măsură”).
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).
Formă
Document text, plan în MS Project.
Scop
Documentul servește ca instrument de planificare și organizare acțiune comună participanților să asigure atingerea obiectivelor operațiunii de probă într-o perioadă specificată (de regulă, 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 calendarul fiecărui eveniment. Exemple de astfel de activități pot fi „lansarea și testarea primirii solicitărilor utilizatorilor folosind interfața Web”, „realizarea 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”, „Măsuri organizatorice” (pentru a lansa și începe operarea sistemului de management IT) și „Instrumente de automatizare”. „ desfășurat 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”.
Scopul fazei pilot este testarea sistemului de management IT într-un mediu de producție la sediul clientului. Pe baza Planului de operare pilot, pe parcursul etapei, se formează un produs „intern” „Rezultatele operațiunii pilot”, pe baza căruia vor fi 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”.
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 „SA Stand Experimental” și „Protocolul de Observații și Îmbunătățiri”, se dezvoltă un produs „extern” „SA Industrial Stand”. Etapa rezultată și proiectul în ansamblu este produsul „extern” „Prezentarea rezultatelor proiectului”.
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ă după reguli diferite. 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ă. V hărți 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.
Cu această hartă a produsului creată, puteți trece la planificarea proiectului, de exemplu, utilizând 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. Estimarea duratei rezultatului sarcini de proiectare, obținem planul de bază al proiectului.
Metoda „clasică” de implementare este cea mai comună pe piața serviciilor de consultanță, este foarte populară și testată în timp. Cu toate acestea, are un dezavantaj, sau mai degrabă o caracteristică care, în condițiile actuale, capătă totul. valoare mai mare atât pentru client cât și pentru antreprenor. Este despre despre 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 se poate schimba conditii externe unde își desfășoară activitatea compania
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:
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:
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 o trecere 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 munca î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.
Grupul de sarcini de proiectare „Cercetare” în cadrul primei iterații include o cantitate mare de muncă care, în dezvoltarea „clasică”, este efectuată în etapele de cercetare și proiectare:
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:
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:
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ă:
Grupul de sarcini de proiect „Determinarea limitelor lansării” este format din următoarele lucrări:
Produșii rezultați din iterația 2 sunt:
Pentru a obține o lansare 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 privind operarea pilot (pilot).
Formă
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ă grupe 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 lucrărilor ș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 în 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 de proces ș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, când operațiunea nu este experimentală, ci pilot-industrială), este util să se întocmească un scurt raport intermediar la una sau două săptămâni după lansare.
Grupul va include următoarele:
Grupul de sarcini de proiectare „Dezvoltare” din conținutul său repetă și iterația anterioară. Iterația este finalizată de grupul de sarcini de proiectare „Acceptare”, care va include următoarele lucrări:
Deci produsele iterației 3 sunt:
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 unor circumstanțe noi și în condiții noi, până la eliminarea serviciilor unui furnizor terț.
Î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 nu sunt numai caracteristici de calitate. Între setare de bază sisteme de automatizare „din cutie” și implementarea unei soluții „individuale” dovedite de mai multe ori, există o diferență semnificativă în termenul și costul proiectului pentru client.
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 plătite printr-o „lovitură” mai precisă a rezultatelor proiectului în bugetul planificat și așteptările părților interesate.
Mult succes cu proiectele tale!
ORDINPRIVIND DEZVOLTAREA, OMOLOGAREA ȘI OMOLOGAREA ÎN RZD SA A INSTRUCȚIUNILOR PRIVIND PROCEDURA DE ÎNTREȚINERE ȘI ORGANIZARE A TRAFICULUI PE O CINE FERATĂ DE UTILIZARE NEPUBLICĂ, ȘI ȘI O CINE FEROVIARĂ GESTIONAȚĂ DE O FILIALĂ FUNCȚIONALĂ A SA „SUBDEPARTAMENTUL”
Pentru a imbunătăți ordine unificată privind elaborarea, coordonarea și aprobarea instrucțiunilor privind procedura de deservire și organizare a circulației pe cale ferată nu uz comun, o cale ferată administrată de o ramură funcțională sau subdiviziune structurală a Căilor Ferate Ruse și care nu este cu trenul uz non-public:
1. Aprobați și puneți în aplicare documentele anexate:
1.1. Procedura pentru dezvoltarea, aprobarea și aprobarea de către Căile Ferate Ruse a unei instrucțiuni privind procedura de deservire și organizare a traficului pe o cale ferată nepublică, precum și pe o cale ferată administrată de o ramură funcțională sau unitate structurală a Căilor Ferate Ruse (denumită în continuare denumită Procedură).
1.2. Instrucțiuni privind procedura de deservire și organizare a traficului pe o cale ferată nepublică deținută de Căile Ferate Ruse, precum și pe o cale ferată administrată de o sucursală funcțională sau unitate structurală a Căilor Ferate Ruse (denumită în continuare Instrucțiunea).
2. Șefii sucursalelor funcționale și diviziilor structurale ale Căilor Ferate Ruse SA vor aduce Procedura și Instrucțiunea angajaților implicați, proprietarilor și utilizatorilor căilor ferate nepublice, ale căilor ferate administrate de filialele funcționale sau diviziile structurale ale Căilor Ferate Ruse SA, asigura conformitatea cu Procedura stabilita.
3. Recunoaștem ca nevalid ordinul Căilor Ferate Ruse OJSC din 2 august 2011 N 1686r „Cu privire la elaborarea, coordonarea și aprobarea în Căile Ferate Ruse a unei instrucțiuni privind procedura de deservire și organizare a traficului pe o cale ferată nepublică”.
4. Să impună controlul asupra punerii în aplicare a prezentului ordin vicepreședintelui - șef al Direcției de tracțiune Vorotilkin AV, șefului Direcției centrale de control al traficului Ivanov PA, șefului Direcției centrale de infrastructură Suprun VN, șefului Direcției centrale al Materialului rulant Multiunități Sizov S.V., Șef al Direcției Centrale Reparații Căi Pimenov I.Ya., Șef al Direcției Reparații Material Rulant de Tracțiune Akulov A.P. în conformitate cu competenţa funcţională a întrebărilor.
Vicepreședinte senior al Căilor Ferate Ruse
A.A. Krasnoshchek
abrogat/pierdut Ediție de la 18.02.1991
„CARTA TRANSPORTULUI AUTOMOBIL A RSFSR” (modificată la 18 februarie 1991)
Autostrăzi și căi de acces
16. Drumurile auto de uz general situate pe teritoriul RSFSR se împart în drumuri naționale, republicane și importanță locală. Dintre drumurile de importanță locală se disting drumuri cu semnificație regională.
Autostrăzile de importanță națională și republicană sunt de competența Ministerului Construcțiilor și Întreținerii Autostrăzilor din RSFSR.
Drumurile cu motor de importanță republicană sunt transferate de Ministerul Transporturilor Auto și Autostrăzilor al RSFSR pentru serviciul permanent către autoritățile rutiere ale Consiliilor de Miniștri ale Republicilor Autonome competente și comitetelor executive ale Sovietelor regionale (teritoriale) ale deputaților populari.
Autostrăzile de importanță locală sunt de competența Ministerului Transporturilor Auto și Autostrăzilor al RSFSR și a Consiliilor de Miniștri ale republicilor autonome, a comitetelor executive ale Sovietelor regionale (teritoriale) ale deputaților populari.
Autostrăzile din orașe și așezările muncitorești sunt sub jurisdicția comitetelor executive relevante ale Sovietelor Deputaților Poporului.
din 28.11.69 N 648, din 16.05.80 N 253)
17. Ministerul Drumurilor Auto din RSFSR, Consiliile de Miniștri ale Republicilor Autonome, comitetele executive ale Sovietelor Deputaților Populari, precum și fermele colective, fermele de stat și alte întreprinderi și organizații sunt obligate să întrețină drumurile, indicatoare rutiere, indicatoare și alte mijloace tehnice de control al circulației aflate în jurisdicția lor, în condiții de asigurare a circulației nestingherite și în siguranță a vehiculelor, precum și luarea măsurilor necesare pentru îmbunătățirea circulației pe aceste drumuri.
(Modificat prin Decretele Consiliului de Miniștri al RSFSR din 28.11.69 N 648, din 16.05.80 N 253)
18. Întreprinderile și organizațiile de transport auto, precum și alte întreprinderi, organizații și instituții care dețin autoturisme, la transportul rutier de mărfuri, pasageri, bagaje și poștă, sunt obligate să asigure siguranța circulației și siguranța drumului.
Pe autostrăzi este interzis:
a) trecerea vehiculelor, inălțime totală care cu sarcina depaseste pe cele indicate pe indicatoare rutiere dimensiuni;
b) transportul de mărfuri care ies în lățime peste dimensiunile vehiculelor stabilite prin standardul de stat sau specificații, precum și încărcătura care iese dincolo de hayon cu mai mult de 2 metri sau târâind de-a lungul drumului;
c) trecerea tuturor tipurilor de vehicule cu sarcini pe osie ce depăşesc normele stabilite standardele de stat sau indicate pe indicatoarele rutiere.
Transportul mărfurilor supradimensionate poate fi efectuat în unele cazuri cu permisiunea autorităților rutiere și a Inspectoratului Auto de Stat în modul prevăzut de Reguli.
19. Ministerul Transporturilor Auto al RSFSR și Ministerul Drumurilor Auto al RSFSR acordă asistență tehnică materialului rulant de pe drumurile auto, indiferent de proprietatea acestuia, cu plata costului serviciilor prestate la tarife.
Pe autostrăzile de importanță națională, asistența tehnică a materialului rulant pe traseu este organizată prin intermediul organizațiilor de întreținere a drumurilor din cadrul Ministerului Autostrăzilor din RSFSR. Pe aceleași drumuri, asistența tehnică a materialului rulant este asigurată de stații întreținere autovehiculele și întreprinderile de transport cu motor ale Ministerului Transporturilor Auto din RSFSR la locația acestora.
Lista drumurilor pe care se organizează asistență tehnică se aprobă de Ministerul Transporturilor Auto al RSFSR împreună cu Ministerul Drumurilor Auto al RSFSR și se publică în Colecția de Reguli de Transport și Tarife de Transport Auto al RSFSR.
Procedura de organizare a asistenței tehnice a materialului rulant pe drumurile auto este determinată de Regulamentul de organizare a asistenței tehnice a materialului rulant pe drumurile auto din RSFSR, aprobat de Ministerul Transporturilor Auto al RSFSR împreună cu Ministerul Drumurilor Auto. a RSFSR.
(Modificat prin Decretele Consiliului de Miniștri al RSFSR din 28.11.69 N 648, din 16.05.80 N 253)
20. Suspendarea sau restrângerea temporară a transportului de mărfuri, pasageri, bagaje și poștă pe drumurile auto în RSFSR poate fi efectuată numai în cazuri de fenomene naturale sau din cauza condițiilor rutiere și climatice.
Deciziile de oprire sau restricționare a transportului de mărfuri, pasageri, bagaje și poștă, cu indicarea perioadei de valabilitate a încetării sau restricționării transportului pe autostrăzile de importanță națională, se iau de către Ministerul Construcției și Întreținerii Autostrăzilor al RSFSR, la data de alte drumuri publice - de către Consiliile de Miniștri ale Republicilor Autonome sau comitetele executive ale Consiliilor regionale (regionale) ale Deputaților Populari.
Ministerul Drumurilor Auto din RSFSR, iar pe alte drumuri, Consiliile de Miniștri ale Republicilor Autonome și comitetele executive ale Sovietelor regionale (teritoriale) ale deputaților muncitori sunt obligate să aducă în atenția întreprinderilor, organizațiilor, instituțiilor și instituțiilor interesate. cetățenilor cu privire la suspendarea temporară sau restrângerea transportului pe autostrăzile de importanță națională.
În cazuri urgente, organele Inspectoratului Auto de Stat pot interzice sau restricționa circulația vehiculelor care efectuează transport pe anumite porțiuni de străzi și drumuri atunci când utilizarea acestora amenință siguranța circulației.
(Modificat prin Decretele Consiliului de Miniștri al RSFSR din 28.11.69 N 648, din 16.05.80 N 253)
21. Expeditorii și destinatarii sunt obligați să dispună de căi de acces de la drumurile auto către punctele de încărcare și descărcare și să mențină aceste drumuri în bună stare, asigurând circulația nestingherită și în siguranță a vehiculelor și libera manevrare a acestora în orice moment în timpul transportului.
22. Conformitatea stării drumurilor auto și a căilor de acces situate pe teritoriul RSFSR cu cerințele de siguranță a traficului și siguranța mărfurilor și materialului rulant este stabilită în comun de autoritățile rutiere competente, întreprinderile de transport auto sau organizațiile și organismele Inspectoratul Auto de Stat.
Livrare de marfă Cu mașina cel mai adesea se face „door to door”, adică transportatorul ridică marfa direct de la expeditor și o eliberează destinatarului. Acesta este avantajul incontestabil al transportului rutier față de celelalte tipuri ale sale - feroviar, pe apă și aerian. Tot ce aveți nevoie pentru a efectua transportul - potrivit pentru mișcare transportul de marfă drum. Și dacă drumurile publice fac cel mai adesea posibilă circulația de-a lungul lor (deși opțiunile sunt posibile în Rusia), atunci drumurile de acces către locurile de încărcare, descărcare și zone de încărcare și descărcare nu sunt întotdeauna potrivite pentru circulația transportului de mărfuri.
Adesea, o astfel de problemă apare pe șantierele de construcții și se confruntă cu șoferii care transportă materiale de construcție în vrac - piatră zdrobită, pietriș, nisip etc. Teritoriul este plin, nu există nici măcar un indiciu de drum, barele de fier ies din pământ, iar maistrul cere energic să cheme. Situație familiară? Să ne uităm.
În primul rând, trebuie să înțelegeți ce este un „pasaj”. Legislația nu definește conceptul de „drum de acces auto”, prin urmare, ar trebui să ne ghidăm după interpretarea sa literală - aceasta este o cale care leagă santierşi obiecte de stat şi proprietate privată cu o rețea de drumuri publice și private.
Legislația care reglementează raporturile părților la contractul de transport nu conține instrucțiuni directe cu privire la acțiunile conducătorului auto în cazul în care este imposibil să se circule la locul de încărcare sau descărcare din cauza lipsei unui drum de acces. UATiGNET* și PPGAT**, de asemenea, nu conțin nicio mențiune despre această situație destul de comună.
Până la sfârșitul lunii martie 2018 au existat Reguli generale transportul rutier de mărfuri (aprobat de Ministerul Autotransportului al RSFSR la 30 iulie 1971). § 5 din secțiunea 5 „Reguli de încărcare și descărcare a mărfurilor”, literalmente, va avea următorul cuprins: „Expeditorul și destinatarul sunt obligați să păstreze locurile de încărcare și descărcare, precum și căile de acces către acestea, în bună stare în orice moment al anului pentru a asigură trecerea și manevrarea nestingherite a materialului rulant, precum și asigurarea unei iluminari adecvate pentru lucru seara și noaptea.” Prin ordinul Ministerului Transporturilor al Federației Ruse din 23 martie 2018 nr. 113, OPPGAT au fost declarate nule.
În orice caz, obligația expeditorului și a destinatarului de a menține în stare corespunzătoare căile de acces și zonele de încărcare și descărcare nu intră în conflict cu alte norme de drept. În plus, această cerință este în concordanță cu prezumția de bună-credință a părților la raporturile juridice civile (articolul 10 din Codul civil al Federației Ruse).
Pe de altă parte, acțiunile părților în cazul unei astfel de situații nu sunt clar definite de lege, de aceea se recomandă să se prevadă în contract procedura de sesizări și acțiuni ale transportatorului în cazul în care este imposibil sau prea mare. dificil de condus la locul de încărcare sau descărcare. O astfel de condiție îi disciplinează pe expeditori și destinatari, iar în cazul în care accesul sau manevrarea în timpul descărcării este imposibilă, se evită dificultățile în stabilirea și certificarea acestui fapt.
