Plan de proiect. Planificarea proiectului. Noțiuni de bază. Metoda de calcul al riscului cumulat este o metodă de evaluare a factorilor de risc care vă pot împiedica să primiți venitul planificat. Atunci când se construiește rata de actualizare folosind această metodă, se ia ca bază rata fără risc

  • 08.07.2020

Planificarea este fundația pe care se construiește orice proiect. Și cu cât este mai puternic, cu atât este mai probabil ca proiectul să aibă succes. Pentru aceasta, există un plan de management al proiectului, care constă din trei blocuri: activități (obiective, concepte de proiect, alocări de resurse etc.), sarcini și resurse (oameni, echipamente, bani etc.).

Ce este un plan de management de proiect?

Un plan de management de proiect este un document care conține toate elementele unui proiect: de la activități și resurse până la criterii de evaluare a succesului și a riscurilor. Prin elaborarea acestui plan, managerul de proiect încearcă să acopere întregul proiect, de la inițiere până la închidere.

Planul este cel mai important document la crearea unui proiect – la nivel de implicare a părților interesate. Așa cum un proiect nu poate fi implementat fără participarea unei părți interesate, un proiect va eșua fără un plan de management bine gândit. Documente precum un plan de gestionare a costurilor, termenelor, calității, riscurilor, resurselor etc. fac parte dintr-un plan de management mai amplu.

În managementul de proiect tradițional, planul prevede constrângeri în toate cele cinci faze: pornire, planificare, executare, monitorizare și finalizare. Proiectele agile nu pot fi planificate până la sfârșit din cauza naturii de lucru cu un model agil. Prin urmare, planurile sunt elaborate și aprobate pe parcursul ciclului de viață al proiectului.

Există de obicei două planuri de management implicate într-un proiect:

  1. baza— aprobat de conducere (client). Determină succesul sarcinilor, controlează timpul și calitatea.
  2. muncitor- spre deosebire de precedenta, managerul de proiect ii face modificari in functie de noi informatii sau sarcini.

Pentru ce este?

Un plan bun ar trebui să răspundă la întrebări de bază:

  • De ce?— Ce problemă rezolvă proiectul, care este valoarea lui? De ce este sponsorizat proiectul?
  • Ce?— Care sunt principalele produse (livrări) ale proiectului? Ce trebuie făcut pentru a finaliza cu succes?
  • OMS?— Cine va fi implicat în lucrul la proiect și de ce va fi responsabil fiecare dintre participanți? În ce format vor fi organizate?
  • Când?- Care este perioada de timp a proiectului? Când vor fi îndeplinite etapele cheie?
O etapă este o etapă în timpul unui proiect (de exemplu, trecerea la o nouă iterație).

Obiectivele Planului de Management al Proiectului sunt:

Componentele cheie ale unui plan de management de proiect


Nu va funcționa să faci planuri conform unui singur șablon, dar există trusa elemente de baza, știind care, este ușor să construiți cadrul viitorului proiect:

  • scurtă descriere a planului- câteva paragrafe despre elementele cheie ale proiectului, care sunt dezvăluite în plan.
  • aliniere strategică și organizațională- aceasta include rezultatele analizei părților interesate și a obiectivelor organizaționale care vor fi susținute pe parcursul implementării proiectului.
  • definirea domeniului de aplicare al proiectului- acest paragraf include următoarele elemente: sarcină și obiective, rezultate așteptate, instrumente PBSși WBS. În secțiune este important să se indice și specificații de calitate - criterii de eficacitate a unui produs sau serviciu din punctul de vedere al clientului.
PBS (product breakdown structure) este un instrument de analiză, documentare și comunicare a rezultatelor proiectului. PBS face parte din metodologia de planificare bazată pe produs (una dintre principalele metode din modelul de management al proiectelor PRINCE2).
WBS (work breakdown structure) - defalcare ierarhică munca de proiectareîn sarcini (operații) mai mici până la nivelul în care modurile de realizare a muncii sunt clare, există posibilitatea de evaluare și planificare.
  • evaluarea fezabilității și planurile de urgență- contine o evaluare a fezabilitatii economice, tehnice si organizatorice a proiectului, identificarea si analiza riscurilor, ofera planuri de actiune in situatii critice pentru eliminarea factorilor de risc.
  • restricții- o listă a restricțiilor cunoscute impuse de mediu sau management (buget fix, lipsă de resurse etc.).
  • cerințe pentru a echipă de proiect — definirea organizării echipei de proiect, a rolurilor și responsabilităților participanților. Aici intervin cerințele de formare.
  • cerinte materiale- include elemente ale locului, software, echipamente și alte resurse pentru finalizarea proiectului.
  • program și repere- Această secțiune definește reperele și programul activităților proiectului, inclusiv trei elemente cheie: livrări (rezultate ale lucrărilor), datele sau durata și dependențele critice.
  • buget (estimare)- cheltuielile preconizate sunt de obicei împărțite în trei tipuri: capital (achiziționarea unui depozit pentru depozitarea produselor), consumabile (achiziții săptămânale de materiale pentru achiziții) și forță de muncă (plata salariilor membrilor echipei)
  • Managementul riscurilor— o descriere detaliată a procesului de management al riscului: de la identificare (prin brainstorming, interviuri, analiză SWOT) până la selectarea unui sistem de monitorizare (pro- sau reactiv).
  • managementul schimbării- similar cu paragraful anterior, se referă doar la posibile modificări (și vor fi multe dintre ele). Aici merită să prescrii un algoritm pentru efectuarea modificărilor, metodologii de management (ADKAR, AIM și altele), o formulă pentru calcularea probabilității de succes a modificărilor etc.
  • managementul comunicațiilor— subiectul privește atât echipa, cât și părțile interesate. Managerul de proiect din această secțiune ar trebui să descrie sistemul de comunicare care va fi utilizat și canalele de comunicare a documentației privind performanța proiectului către părțile din proiect.
  • atașamente- orice documente pot ajunge aici: de la note individuale la prezentări și certificate.

Lista secțiunilor planului este completată în funcție de specificul unui anumit proiect.

Planurile de bază și de lucru ale proiectului

În timp ce lucrează la un proiect, managerul de proiect, membrii echipei și Părțile interesate lucrează cu două tipuri de planuri:

  • baza- primar, stabil, aprobat de client sau de alta persoana prespecificata, convenit cu toate partile interesate.
  • muncitor- versiunea planului de bază, care afișează modificări în termeni, cost și alți parametri ai proiectului.

Pe parcursul derulării proiectului puteți compara planurile de bază și de lucru, să înțeleagă unde „se lasă” munca și unde, dimpotrivă, proiectul este finalizat mai repede (mai economic) decât era planificat. În cazuri rare modificările pe parcursul derulării proiectului sunt aduse planului de management de bază.

În Worksection, diagrama Gantt vă permite să vedeți diferența dintre planul de bază și cel de lucru
(albastru - timpul total, roșu - sarcini restante, verde - sarcini finalizate la timp)

Elaborarea unui plan de management de proiect

Ca și în cazul elementelor cheie ale unui plan de management de proiect, nu există o modalitate corectă de a-l dezvolta.

Am conceput o procedură simplă pas cu pas pentru scrierea unui plan, constând din 16 puncte:

  1. Stabiliți condițiile de pornire pentru elaborarea unui plan- este important să înțelegeți cu cine îl veți dezvolta (singur, cu participarea managementului, a părților interesate), unde și când etc. Este important să prescrii tehnicile (de exemplu, brainstorming) și software-ul (cum ar fi Microsoft Visual Studio) care vor fi utilizate la crearea planului - acest lucru va economisi mult timp și va simplifica sarcina.
  2. Stabiliți condițiile de început pentru proiect- acesta descrie conținutul proiectului, o listă de cerințe pentru rezultate și managementul acestuia. De exemplu, a fost conceput un proiect pentru a vinde spinner de neon de înaltă calitate cu imprimeuri de supereroi. Ca urmare a implementării cu succes a proiectului anual, 100.000 de unități de marfă trebuie vândute în termen de 12 luni de la începerea proiectului, după care va avea loc vânzarea afacerii. Structura de management al proiectului va consta dintr-un manager general de proiect în biroul central și departamentele relevante din birouri regionale proiect.
  3. Definiți acțiunile care trebuie întreprinse pentru cele care vor fi realizate de echipa de proiect și externalizarea.
  4. Creați un proiect WBS împărțindu-l în bucăți mai mici și ușor de gestionat. Aceasta este similară cu abordarea Agile, în care codul complet este împărțit în multe bucăți mici de lucru.
  5. Scrieți un set de sarcini pentru a efectua fiecare parte a WBS și construiți o dependență între ele. Deci, sarcina de cumpărare și echipare a unui depozit regional pentru depozitarea filătorilor poate fi finalizată numai după analizarea pieței și vânzarea unei anumite cantități de mărfuri într-o anumită zonă.
  6. A determina competentele necesare pentru a finaliza fiecare sarcină. Este important aici să nu se adapteze cunoștințele și abilitățile necesare potențialilor participanți la proiect, ci să se concentreze pe cerințele „ideale”.
  7. Estimați timpul și costul pentru a finaliza sarcinile.
  8. Proiectați un proiect. Tehnica este bună doar pentru afacerile cu produse alimentare și este ușor să o afișați prin diagrame (de exemplu, o diagramă Gantt).
  9. Crea plan calendaristic proiect- date de început, intermediare, de sfârșit. De exemplu, o schemă simplificată: la 1 noiembrie se lansează un proiect, la 1 decembrie, începerea vânzărilor pentru Anul Nou, la 31 decembrie, însumând rezultatele vânzărilor de Anul Nou, la 15 ianuarie, lansarea unui linie specializata de Valentine's Day, pe 20 februarie, rezumat etc.
  10. Calculați costul proiectului(în cazul nostru, cât va costa să vindeți cu succes 100.000 de spinners și să vindeți afacerea).
  11. Specificați cerințele de calitate(de exemplu, standardele de calitate prescrise pentru fabricarea de filare).
  12. Atribuiți anumiți oameni responsabili pentru sarcini. Aici vă va veni de folos punctul 6, cu lista căreia veți asocia competențele membrilor echipei.
  13. Planificați formatul de lucru cu părțile interesate- selectarea canalelor de comunicare, determinarea gradului de implicare a acestora în lucrarea la proiect etc.
  14. Calculați riscurile (de exemplu, folosind formula metodei cumulative).În exemplul nostru cu spinneri, aceasta poate fi o suprasaturare banală a pieței, încălcarea termenilor contractului de către expeditorii de marfă etc. În analiza de risc, utilizați datele din paragrafele precedente.
  15. Notați constrângerile proiectului și, ținând cont de ele, introduceți datele în planul de management al proiectului.În cazul nostru, piesele spinner sunt livrate din China, asamblarea are loc în Ucraina, iar acest lucru limitează deja posibilitatea unui control strict al calității materialelor și schimbarea rapidă.
  16. Treceți din nou prin toate punctele planului pentru a ajunge la zen. Rămâne de finalizat lista de achiziții și cerințe pentru acestea, cu care să ne coordonăm părțile interesate- și în mâinile tale plan gata management de proiect.
Metoda de calcul al riscului cumulat este o metodă de evaluare a factorilor de risc care vă pot împiedica să primiți venitul planificat. La construirea unei rate de actualizare pentru aceasta metoda Rata de rentabilitate fără risc este luată ca bază, iar la aceasta se adaugă rata de rentabilitate a riscului de a investi într-un proiect sau companie.

În Vladislav Gagarsky, ca exemplu, el oferă următoarea schemă de afirmare:

  1. Liderii echipei de proiect trimit planul dezvoltat în comun managerului de proiect.
  2. Managerul aprobă planul de management al proiectului sau, în caz de erori, asigură efectuarea modificărilor.
  3. Managerul de proiect transmite planul aprobat liderilor echipei de proiect pentru implementare ulterioară.

Dar această schemă este mai potrivită pentru echipele gata făcute care realizează mai multe proiecte unul după altul sau și-au schimbat profilul de activitate. Pentru cei care „de la zero” au decis să scrie și să aprobe un plan de management al proiectului, tehnica nu va funcționa. În astfel de cazuri proiect de bază aprobat de șeful companiei sau al proiectului (clientului) la propunerea managerului de proiect.


Verdict

nu salvator de vieti.

Va fi o declarație inițial fără instrumente pentru implementarea ei. Instrumentul poate deveni cu el proiecte / sarcini / subsarcini și ținând cont de bani, timp și oameni responsabili chiar în sarcini. Acesta este cel mai bun mod de a organiza munca vizuală a companiei, unde legătura dintre linia de bază și planurile de lucru este evidentă pentru toată lumea.

Dar planul este începutul care va determina 50% din succesul proiectului.

Planificare este un proces de dezvoltare și adoptare a obiectivelor de natură cantitativă și calitativă și de determinare a modalităților de a le atinge cel mai eficient. Aceste setări, dezvoltate cel mai adesea sub forma unui arbore de obiective, caracterizează viitorul dorit și, dacă este posibil, sunt exprimate numeric printr-un set de indicatori care sunt cheie pentru acest nivel de management.

Nevoia de planificare este determinată de mai multe motive. Cele mai semnificative dintre ele: incertitudinea viitorului, rolul coordonator al planului, optimizarea consecințelor economice.

Într-adevăr, dacă viitorul proiectului ar fi absolut predeterminat, nu ar fi nevoie să elaborăm constant planuri, să îmbunătățim metodele de pregătire și structurare a acestora. Acest lucru arată că scopul principal al întocmirii oricărui plan nu este acela de a determina cifre și repere exacte, deoarece acest lucru este imposibil în principiu, ci de a identifica un anumit „coridor” pentru fiecare dintre cele mai importante zone, în cadrul căruia un sau altul indicator poate varia.

Semnificația rolului de coordonare al planului este că prezența unor ținte bine structurate disciplinează atât activitățile prospective, cât și cele curente, le aduce într-un anumit sistem și permite companiei să lucreze fără întreruperi semnificative.

Ultimul motiv pentru necesitatea întocmirii planurilor este că orice discrepanță între activitățile sistemului necesită costuri financiare (directe sau indirecte) pentru a o depăși. Probabilitatea unei astfel de nepotriviri este mult mai mică dacă lucrarea este efectuată conform planului; in plus, consecintele financiare negative sunt mai putin semnificative.

Planificarea vă permite să asigurați un grad ridicat și o mare probabilitate de atingere a obiectivelor pe baza pregătirii sistematice a deciziilor. Astfel, este o condiție prealabilă pentru implementarea eficientă a proiectului. Planul de proiect este principalul instrument de integrare a participanților la proiect. Elaborarea și acordul planului de proiect asigură o mai bună înțelegere de către toți participanții a sarcinilor și responsabilităților lor.

Planul de proiect analizează în detaliu modul de echilibrare costurile proiectului, momentul implementării, programul și calitatea.

În etapa de planificare a proiectului, sunt rezolvate următoarele sarcini:

  • clarificarea și precizarea scopurilor și rezultatelor proiectului;
  • clarificarea compoziției și domeniului de aplicare a proiectului;
  • elaborarea unui calendar și buget real pentru proiect (sau fazele individuale ale acestuia);
  • clarificarea nevoii de resurse a proiectului, un plan pentru sprijinirea resurselor proiectului (sau faze individuale ale proiectului);
  • evaluarea riscurilor și dezvoltarea unui plan de răspuns la risc;
  • clarificarea ordinii de interactiune in echipa de proiect, precum si intre echipa de proiect si mediul extern;
  • dezvoltarea și perfecţionarea procedurilor de management de proiect;
  • aprobarea planului de către principalii participanți la proiect;
  • aprobarea planului de proiect.

Structura extinsă a planului de management al proiectului

Principalii pași de planificare

Formarea scopurilor

Ca parte a planificării, sunt stabilite două grupuri de obiective.

Obiective formale reprezintă un criteriu de evaluare a utilităţii activităţii şi a stării proiectului, care derivă din motivarea activităţilor factorilor de decizie.

Goluri reale reprezintă modalități de atingere a obiectivelor formale (produsele care urmează a fi produse, calitatea și cantitatea acestora, resursele necesare, calitatea și cantitatea acestora).

Analiza problemei

Analiza problemei include următorii pași:

  • determinarea stării reale (analiza poziției);
  • prognoza pozitiei;
  • identificarea problemelor prin contrastarea sistemului de obiective și a rezultatelor analizei și previziunii situației;
  • structurarea problemei.

În cursul problemelor de structurare, acestea trebuie mai întâi împărțite în două grupuri:

  • Probleme de natură externă, a căror soluție nu poate fi influențată de echipa de proiect pe toată perioada de planificare.
  • Problemele sunt interne, a căror soluție depinde de managementul eficient al proiectului.

Apoi, este necesar să împărțiți problemele atribuite celei de-a doua categorii în două clase:

  • Probleme, a căror rezolvare nu necesită costuri financiare și de timp semnificative. Această clasă de probleme este rezolvată în cursul planificării curente sau operaționale.
  • Probleme care necesită mult timp și o sumă semnificativă de finanțare pentru rezolvare.

Aceste probleme sunt luate în considerare în procesul de planificare și prognoză pe termen lung.

Căutați alternative

Alternativele sunt soluții care se exclud reciproc.

Prognoza joacă un rol important în implementarea proiectelor pe termen lung. Există două tipuri de prognoze care trebuie distinse.

  • Predicții de influență dați o idee despre ce rezultate va duce fiecare dintre deciziile disponibile, adică Cum această decizie afectează performanța proiectului.
  • Prognoze de dezvoltare situațiile se aplică indicatorilor Mediul extern, pe care factorii de decizie nu le pot influența în perioada analizată.

Evaluarea alternativelor

Evaluarea alternativelor în ceea ce privește acceptabilitatea, eficacitatea și riscul acestora este baza pentru luarea deciziilor. Alternativa legală și realizabilă practic este considerată optimă, ceea ce permite să ne apropiem cât mai mult de atingerea obiectivelor reale stabilite în condițiile restricțiilor existente - resurse, timp, forță de muncă etc.

În timpul implementării proiectului, planul trebuie actualizat ținând cont de starea actuală și de modificările efectuate. Astfel, planul proiectului devine baza pentru evaluarea progresului realizat pe parcursul implementării acestui proiect.

Pentru a asigura fezabilitatea și acuratețea planului de proiect, managerul de proiect trebuie să rezolve următoarele sarcini.

  1. Implicarea principalilor participanți la proiect în procesul de planificare, asigurând responsabilitatea pentru parametrii planificați.
  2. Obținerea unei înțelegeri de comun acord a structurii și domeniului proiectului și a cerințelor de resurse cu clientul și principalii participanți la proiect.
  3. Planificare structura organizationala implementarea proiectului și asigurarea faptului că resursele necesare sunt atrase către proiect.
  4. Acordați responsabilitatea participanților principali pentru rezultate.

Imaginează-ți că te confrunți cu nevoia de a dezvolta un site web pentru prima dată. Cum să nu uiți nimic pe drum și deja la etapa inițială pentru a estima costurile financiare și cu forța de muncă? Mai jos vă împărtășesc experiența mea în elaborarea unui plan de proiect pentru dezvoltarea unui site web de marketing pentru o companie de servicii.

Există opțiuni mai simple, cum ar fi realizarea unei pagini de destinație folosind serviciul LP Generator sau similar. Nu poți să fii limitat la o singură pagină și să faci un site web cu drepturi depline pe un constructor de site-uri web. Acestea sunt variante de lucru, nu descurajez pe nimeni de la ele. Totul depinde de obiectivele pe care le-ați stabilit pentru site și, în consecință, de cerințele dvs. Propun un plan de proiect pentru un site web orientat spre SEO cu mai multe pagini fără a utiliza un constructor de site-uri web.

Definirea principalelor blocuri de lucru

Sarcina dezvoltării unui site include diverse etape în care sunt implicați diverși specialiști. Încep prin a identifica principalele blocuri mari. În acest moment, planul arată astfel:

  1. Marketing clasic: cunoașterea produsului, concurenții, dezvoltarea unui USP
  2. Selectarea semanticii
  3. Dezvoltarea structurii site-ului
  4. prototipare
  5. Proiecta
  6. Aspect
  7. Programare
  8. Testare
  9. lansa

Imaginea devine mai clară, dar nu sunt suficiente detalii, așa că am împărțit sarcinile mari în altele mai mici.

Număr aproximativ și tipuri de pagini

Pentru a calcula planul proiectului, alcătuiesc o listă orientativă a paginilor site-ului și a tipurilor de sarcini care sunt necesare pentru această pagină. Mă ajută să calculez orele de muncă pentru sarcini. Este posibil ca lista de pagini să se schimbe în timpul lucrului, dar în această etapă va fi suficientă pentru calcule. Masa va arăta cam așa.

Pagini (măști) Număr de pagini Collect SA TK de la un specialist SEO Text Prototip Proiecta Aspect Programare
Acasă 1 1 1 1 1 1 1 1
către clienții corporativi 1 1 0 1 1 1 1 1
Servicii (pagina secțiunii) 1 1 1 1 1 1 1 1
Sectiunea Servicii 3 3 3 3 2 2 2 2
Subsecțiunea Servicii 7 7 7 7 1 1 1 1
Întrebări și răspunsuri (FAQ) 1 0 1 0 1 1 1 1
Pagina cu un singur articol X X X X 1 1 1 1
Contacte 1 0 1 1 1 1 1 1
Despre companie 1 0 1 1 1 1 1 0
Preturi 1 0 1 0 1 1 1 1
17 13 16 15 11 11 11 10

Detalierea listei de sarcini

Pentru a calcula costurile cu forța de muncă, încerc să împart sarcinile astfel încât să fie atribuită câte una fiecărei sarcini. specialist responsabil. Imediat la lista de sarcini adaug coloana „Contractant” și numărul estimat de ore pentru finalizarea sarcinii.

O sarcină Executor testamentar Ceas cometariu
Identificarea serviciilor de bază și identificarea concurenților Marketer 6 Este important să înțelegeți scopul site-ului. După studierea concurenților, lista poate fi ajustată.
Analiza expresă a site-urilor concurenților Marketer 24 În funcție de cunoștințele pieței și de complexitatea proiectului, timpul poate fi ajustat.
Declarația de beneficii și dezvoltare a USP Marketer 8 Pe baza informațiilor despre companie și concurenți, dezvoltăm oferta principală și răspundem pe scurt la întrebarea: „de ce ar trebui să cumpărați de la noi”.
Planificarea inițială a structurii șantierului Marketer 2 Abia atunci poate fi compilată structura de bază a site-ului, care în această etapă arată ca o listă de pagini.
Colectarea nucleului semantic și segmentarea Specialist SEO 26 Un specialist SEO colectează o listă completă de interogări și le combină în grupuri semantice. Timpul pe care îl calculez este de aproximativ 2 ore pentru fiecare pagină a structurii preliminare a site-ului (pentru care SEO este relevant, desigur). Dacă un site există deja, atunci ar trebui să țineți cont de interogările pentru care site-ul este deja în rezultatele căutării.
Coordonarea și aprobarea acesteia. nuclee Marketer 8 Este mai bine să coordonați nucleul semantic cu clientul pentru a evita neînțelegerile în viitor.
Corectarea structurii sitului, ținând cont de nucleul familial Specialist SEO 6 Sugestii SEO-specialist pentru lista de pagini, navigare.
Rafinarea și coordonarea structurii șantierului, ținând cont de nucleul familial Marketer 4 În această etapă, obținem scheletul site-ului. În plus, presupun prezența unor pagini tipice. De exemplu, că toate paginile diferitelor servicii sunt realizate conform aceluiași șablon.
Ghid de bază SEO pentru conținut pentru pagini după pagină Specialist SEO 8 Pentru a nu fi nevoit să reluați prototipuri sau chiar pagini finalizate, vă recomand să obțineți dorințe SEO deja în această etapă. Acest paragraf este despre blocurile din pagină. Am pus 0,5 ore pe 1 pagină.
TOR SEO pentru conținutul paginii Specialist SEO 30 Acest paragraf este despre recomandări cu privire la textele care ar trebui să fie în pagini. Am pus 2 ore pe pagină.
Scrierea textelor Copywriter/Marketer 90 Dacă ai norocul să găsești un bun copywriter, îi poți încredința scrierea textelor. În cele mai multe cazuri, texte pentru paginile de servicii, pagini unice precum „Despre companie”, „404”, „Contacte”, etc. eu scriu eu. Îmi iau timpul conform propriilor standarde, așa că alocă 6 ore pe pagină, dar se poate schimba de la proiect la proiect.
Prototiparea paginii Marketer 82 Planificăm și 6 ore pentru 1 pagină, plus 2 zile lucrătoare pentru cea principală, deoarece este necesar să pregătim layout-ul, antetul și subsolul. Îmi este convenabil să fac prototipuri în paralel cu scrierea textelor.
Întocmirea specificațiilor tehnice pentru proiectant Marketer 13 Deși prototipurile din Axure RP sunt destul de descriptive, există câteva puncte care trebuie acordate designerului, mai ales la început. Descrieți stilul schema de culori. Îmi este convenabil să trimit exemple de stil și să discut verbal pentru a fi sigur că vorbim despre același lucru.
Proiectarea paginii de start + recomandări pentru adaptare Designer 16 Deoarece acum este imposibil să trăiești fără un site mobil, te sfătuiesc să te gândești la o versiune adaptivă deja în această etapă. S-a dovedit a fi o schemă de lucru, atunci când designerul nu pregătește mai multe opțiuni de proiectare, ci scrie recomandări. Se petrece mai puțin timp, iar rezultatul este același.
Design de alte pagini + recomandări pentru adaptive Designer 66 Numar 6 ore pe pagina. Undeva poate fi mai mult, undeva mai puțin. În acest moment, am stabilit și pregătirea recomandărilor pentru proiectantul de layout pentru layout adaptiv.
Aprobarea și aprobarea proiectului Marketer 14 Aprobarea machetelor necesită întotdeauna timp, mai ales când vine vorba de aprobarea stilului și designului primelor pagini. Vă sfătuiesc să planificați timp pentru asta.
Pregătirea meta tag-urilor optimizate și H1 Specialist SEO 16 În general, acest articol poate fi activat oricând înainte de lansarea site-ului, dar nu uitați!
Intocmirea specificatiilor tehnice pentru layout si programare Marketer 17 Din moment ce mă gândesc la o variantă a site-ului de service, nu presupun module greu de implementat. Prin urmare, stau 1,5 ore pe pagină.
Recomandări SEO pentru etapa de layout și programare Specialist SEO 6 Din nou, pentru a nu o reface, este mai bine să pregătiți imediat site-ul, ținând cont de promovarea ulterioară în motoarele de căutare.
Aspect (adaptabil) Compozitor 104 Totul depinde de complexitatea layout-urilor. Presupun 2 zile pentru implementarea infrastructurii, pregătirea pentru lucru și 8 ore pentru 1 pagină.
Aprobarea si coordonarea layout-ului Marketer 24 Nu puteți include acest articol, dar trebuie totuși să verificați aspectul, să scrieți modificări și să îl acceptați. În funcție de echipă și de proiect, acest lucru poate dura mult timp. Prin urmare, recomand să-l așezați în proiect.
Programare Programator 80 Ansamblu de pagini disparate într-un site finit. Încheierea în CMS a modulelor pentru gestionarea ulterioară a conținutului site-ului fără participarea dezvoltatorului.
Aprobarea și aprobarea părții software Marketer 15 Sincer să fiu, se pare că nu petrec mult timp acestei sarcini. Fără această etapă, nu vei face 100%, lasă timp pentru asta.
Testare și depanare Marketer 40 Această sarcină este să faceți clic pe toate butoanele, să vedeți toate paginile, să încercați toate funcțiile din CMS și să verificați site-ul în diferite browsere și pe diferite dispozitive. Dacă proiectul este mic, atunci poate fi suficient să verificați pe cont propriu, pentru complex includem testeri.
Lansarea versiunii de luptă a site-ului Programator 8 Până în acest moment, toate verificările au fost efectuate pe un loc de testare. Abia acum ne trecem la un site deschis pentru utilizatori.
Conectarea analizelor + CallTouch + stabilirea obiectivelor Marketer/Programator 16 Un articol opțional care începe să devină o normă, deoarece fără analize este imposibil de înțeles cum se descurcă site-ul sarcinilor sale.
Recomandări pentru optimizarea SEO primară Specialist SEO 8 Ascultăm cu atenție ce ne spune specialistul SEO și urmăm recomandările acestuia. Dacă site-ul a fost pregătit inițial conform planului actual, atunci ar trebui să existe un minim de îmbunătățiri, dar pregătim robots.txt și harta site-ului abia acum.
Implementarea recomandarilor SEO Compozitor/Programator 16 Numar 2 zile lucratoare.
Verificarea aplicării recomandărilor SEO pe site-ul de testare Marketer 4
Aplicarea recomandărilor SEO pe site-ul principal Programator 3

Calculul termenilor proiectului

Cea mai mare parte a lucrării este făcută, apoi pictăm orele primite de zi. Unele etape se vor desfășura în paralel. De exemplu, dau un calcul când 1 specialist din fiecare direcție lucrează la un proiect, respectiv, numărul maxim de ore de lucru pe zi este de 8 ore pe specialist.

Tabelul este mare, așa că dau un link către o foaie de calcul Google, unde puteți vedea rezultatul final.

La final, dau costurile cu manopera pentru fiecare specialist. Astfel, cunoscând tariful pe oră, puteți estima costul proiectului. Masa arată așa.

Adaug si un tabel general cu termenii proiectului.

Ore zile
Timp total pentru proiect: 760 62
Zile lucrătoare pe lună 20
Durata proiectului (luni) 3.1

Înțeleg că 62 de zile nu înseamnă 760 de ore. Diferența se datorează îndeplinirii simultane a unor sarcini de către diferiți specialiști.

Acest plan de dezvoltare a site-ului a fost elaborat pe baza experienta personalași nu este singura opțiune corectă. Dar sper să vă fie util ca punct de plecare dacă dezvoltați un site pentru prima dată sau, ca reprezentant al afacerii, plănuiți să comandați un site într-un studio și doriți să înțelegeți mai bine acest proces.

Planificarea proiectelor este un proces continuu, rafinat pe tot parcursul ciclului de viață, în timpul căruia Cel mai bun mod atingerea scopurilor si obiectivelor stabilite, tinand cont de situatia actuala si in schimbare. Un plan de proiect competent, ținând cont de specificul produsului, caracteristicile și tendințele pieței, preferințele consumatorilor, riscurile și alți factori, vă permite să evitați cheltuielile ineficiente chiar și în stadiul de concepție și dezvoltare. O astfel de planificare nu oferă întotdeauna rezultate pozitive, dar chiar și concluziile negative sunt de mare beneficiu.

Prima sarcină a scrierii unui plan este de a da un impuls imediat demarării procesului de proiect. Planul proiectului trebuie să convingă factorii de decizie că ideea este viabilă, că va îndeplini așteptările, programul, bugetul etc. Dacă dezvoltarea nu este convingătoare la nivelul planului, este posibil ca proiectul să nu progreseze dincolo de etapa inițială. Si invers - plan de succes formează imediat reputația managerului de proiect și oferă o bază solidă pentru demararea implementării procesului.

Planul de proiect este întocmit conform schemei generale standard, dar conținutul documentului este întotdeauna unic, deoarece combinația de caracteristici ale produsului și condițiile de implementare a acestuia este unică. Planul de execuție a proiectului oferă îndrumări întregii echipe de proiect și direcționează:

  • după sfera de activitate
  • prin prioritate
  • privind alegerea metodelor de management,
  • conform standardelor de calitate
  • sub forma menținerii comunicării cu părțile interesate,
  • conform criteriilor de măsurare a performanței etc.
  1. Contextul proiectului.
  2. Sarcini și obiective.
  3. Scară.
  4. Frontiere (restricții).
  5. Ipoteze (presupune).
  6. influențe și dependențe.
  7. Riscuri si probleme.
  8. Strategii și metode.
  9. Mijloace și metode de control al timpului, resurselor, calității, amplorii.
  10. Comunicatii.
  11. Program de livrare.
  12. Performanța și măsurarea acesteia.
  13. Realizarea beneficiilor.

O schemă standardizată facilitează navigarea printr-un document care se poate întinde pe sute de foi, dacă se dorește a fi realizate idei mari. Simplificați procesul de lucru cu planul și permite o ordine logică, consecventă și structurată a etapelor de planificare a proiectului. Dacă, de exemplu, elementele care sunt incluse în scară nu sunt documentate, se poate dovedi că printre participanții la proiect nu există o înțelegere comună a cine eliberează ce. Și dacă nu specificați nivelul de calitate, se poate dovedi că că o calitate suficientă pentru producător poate să nu fie suficientă pentru client.

Lipsa detaliilor adecvate duce la erori, dar excesul de detalii cu numeroase repetări împiedică înțelegerea conținutului proiectului. Prin urmare, planul de apărare a proiectului este de obicei testat pe ascultători care nu au cunoștințe prealabile despre proiect, cu implicarea reprezentanților unui public larg. Contextul adăugat planului de proiect va ajuta la încadrarea programului de implementare în contextul general, iar glosarul, decodificarea abrevierilor și abrevierilor tehnice vor face ușor pentru oricine să înțeleagă esența proiectului fără a implica surse de informații terțe.

Planificarea domeniului

Domeniul de subiect aici este setul de produse și servicii care ar trebui să fie produse ca urmare a finalizării proiectului. Planificarea proiectului din punct de vedere al domeniului subiectului include următoarele proceduri:

  • Analiza stării actuale.
  • Clarificarea caracteristicilor de bază ale proiectului.
  • Confirmarea criteriilor de succes și a problemelor proiectului.
  • Analiza ipotezelor și limitărilor care au fost acceptate în etapa inițială a proiectului.
  • Definirea criteriilor pentru rezultatele proiectului în etapele intermediare și finale.
  • Construirea unei descompunere structurală a zonei date.

În procesul de viață a proiectului, elementele care alcătuiesc această zonă pot suferi modificări. Obiectivele lucrării și caracteristicile pot fi precizate atât la atingerea rezultatelor intermediare, cât și la etapa de dezvoltare a proiectului.

Planificarea timpului proiectului

Principalele concepte ale acestui parametru sunt: ​​termenele limită, durata lucrărilor, datele cheie etc. Munca coordonată a participanților este organizată pe baza planurilor calendaristice - documente de proiectare și tehnice care determină lista lucrărilor de proiect, relația dintre acestea. , secvență, termene limită, interpreți și resurse. În timp ce lucrezi la un proiect pentru întreg ciclu de viață se intocmeste un program de lucru pe etape si niveluri de conducere.

Structura de defalcare a muncii (WBS)

WBS - afișarea grafică a ierarhiei lucrărilor de proiectare - prima etapă programare proiect. În esență, WBS este împărțirea proiectului în astfel de părți care sunt necesare și suficiente pentru planificare și control eficient. Redactarea structura ierarhica necesită respectarea următoarelor reguli:

  1. Executarea lucrării nivelului superior se realizează prin executarea lucrării nivelului inferior.
  2. Un proces părinte poate avea mai multe joburi copil, a căror execuție închide automat procesul părinte. Dar pentru un loc de muncă de copil, există doar un loc de muncă de părinte.
  3. Descompunerea procesului parental în lucrări ale copilului se realizează după un singur criteriu: fie prin resurse atrase, fie pe tip de activitate, fie pe etape ale ciclului de viață etc.
  4. La fiecare nivel trebuie colectate lucrări echivalente pentru copii. Criteriile de identificare a omogenității acestora pot fi, de exemplu, volumul și timpul de lucru efectuat.
  5. La construirea structurii în ansamblu, este necesar să se aplice diferite criterii de descompunere la diferite niveluri ierarhice.
  6. Secvența criteriilor de descompunere este aleasă astfel încât cea mai mare parte posibilă a interacțiunilor și dependențelor dintre lucrări să fie la nivelurile inferioare ale structurii ierarhice. Lucrări niveluri superioare- autonom.
  7. Descompunerea muncii este considerată completă dacă munca de la nivelul inferior este clară pentru manager și participanții la proiect, modalitățile de realizare sunt clare. rezultat finalși indicatorii săi, responsabilitatea pentru efectuarea muncii este distribuită fără ambiguitate.

Pe baza WBS, este creată o listă de lucrări de proiect. Și apoi se determină succesiunea implementării lor, relația cu ajutorul modelelor organizaționale și tehnologice și durata muncii.

Durata muncii

Durata muncii este determinată pe baza standardelor, pe baza experienței personale (când există un exemplu de muncă similară), pe baza metodelor de calcul pentru planificarea proiectelor. Astfel de metode includ, de exemplu, metoda de analiză a evenimentelor PERT, care este utilizată atunci când există incertitudine în estimarea duratei operațiunilor. Există, totuși, diferite moduri de a gestiona timpul proiectului.

  • OBRAZNIC. Metoda este considerată ca o medie ponderată trei tipuri previziuni: optimiste, așteptate și pesimiste. După stabilirea duratei fiecărei prognoze (folosind o formulă și/sau implicând experți), se calculează probabilitatea fiecărei prognoze. Și apoi valorile fiecăreia dintre previziuni și probabilitățile lor sunt înmulțite, iar valorile sunt adăugate.
  • diagrama rețelei. O diagramă de rețea este o afișare grafică a activităților și a dependențelor dintre ele. Mai des, este prezentat sub forma unui grafic, ale cărui vârfuri sunt lucrări de proiectare, iar succesiunea și relația lor este demonstrată prin săgeți de conectare.
  • Diagramele Gantt. Aceasta este o diagramă orizontală cu afișarea lucrărilor de proiectare sub formă de segmente orientate conform calendarului. Lungimea segmentului corespunde duratei lucrării, iar săgețile dintre segmente indică relația și succesiunea lucrării.

În plus, în fiecare proiect se asigură optimizarea lucrărilor în funcție de criteriul timpului, se aprobă planuri calendaristice. Scopul general al metodelor de planificare a timpului proiectului este de a reduce durata proiectului fără a pierde calitatea componentelor acestuia.

Forța de muncă din proiect

În această parte a planificării, cantitatea de resurse disponibile este mai întâi determinată. Acest lucru se realizează prin întocmirea unei liste de interpreți, disponibilitate și posibilitatea participării acestora la proiect.

Apoi, pentru fiecare lucrare a proiectului, executanților li se atribuie definirea ariei lor de responsabilitate. Adesea în planul calendaristic la nivelul repartizării resurselor de muncă apar contradicții. Apoi se efectuează analiza contradicțiilor și eliminarea lor.

Costul proiectului

Există mai multe etape în planificarea costurilor proiectului:

  1. În prima etapă, se determină costul utilizării resurselor, a fiecărei lucrări de proiect și a proiectului în ansamblu. Costul proiectului aici este costul total al resurselor și al lucrării. Factorii luați în considerare includ costul echipamentelor (inclusiv echipamentele închiriate), forța de muncă a angajaților cu normă întreagă și a celor angajați în baza unui contract, materiale, transport, seminarii, conferințe, costul instruirii etc.
  2. A doua etapă presupune pregătirea, coordonarea și aprobarea devizului de proiect. Devizul de proiect aici este un document care conține justificarea și calculul costului total al proiectului. Este produs, de regulă, pe baza cantității de resurse necesare, a cantității de muncă etc.
  3. A treia etapă include pregătirea bugetului, coordonarea și aprobarea acestuia. Bugetul introduce restricții la resurse și este întocmit sub forma:
  • diagrame cu bare ale costurilor și costurilor cumulate,
  • diagrame cu linii ale costurilor cumulate distribuite în timp,
  • diagrame circulare ale cheltuielilor,
  • calendare și planuri,
  • matrice de distribuție a costurilor.

În același timp, managementul riscului bugetar este luat în considerare într-o secțiune separată a planificării proiectului.

Planificarea riscurilor

Această secțiune descrie procesele implicate în identificarea, analizarea, evaluarea riscurilor și dezvoltarea răspunsurilor la risc. Riscurile sunt caracterizate de 3 parametri:

  • eveniment de risc,
  • probabilitatea apariției unui eveniment de risc,
  • cuantumul pierderilor, în cazul realizării factorului de risc.

O metodă simplă de planificare a riscurilor este implementată urmând următoarea secvență de acțiuni:

  1. Identificarea riscului. Pentru aceasta, nu sunt implicați doar experții, ci și toți cei care vor ajuta la detectarea potențialelor vulnerabilități ale proiectului.
  2. Determinarea probabilității realizării riscului. Măsurarea se face în procente, cote, puncte și alte unități.
  3. Clasificarea riscurilor în funcție de semnificația fiecărui risc specific pentru proiect și locul acestuia în ierarhie. Prioritare sunt cele care sunt de mare probabilitate și importanță pentru proiectul în ansamblu.
  4. Planificarea măsurilor pentru a reduce probabilitatea fiecărui risc individual, indicând angajații responsabili pentru acest lucru.
  5. Planificarea eradicării consecințe negativeîn cazul realizării riscului cu desemnarea unor persoane responsabile.

La crearea unui proiect trebuie scris un plan indiferent de zona în care operează întreprinderea: din proiecte de productieși sfera IT-tehnologiilor și la amenajarea și lucrările de îmbunătățire a orașului. Cu toate acestea, planificarea proiectului în sine nu este „suspendată în aer”, deoarece este precedată de inițierea proiectului, ci finalizată de trecerea la execuția directă a proiectului.

Planificare este procesul de alocare și alocare a resurselor (materiale și umane) ținând cont de costul și timpul proiectului. Planificarea este unul dintre cele mai importante procese pentru un proiect, deoarece rezultatul implementării acestuia este de obicei un obiect, produs sau serviciu unic.

Principal functii de planificare sunt enumerate mai jos.

Transformați nevoile în sarcini gestionabile. Initial, proiectul apare sub forma unor cerinte dezvoltate si agreate cu clientul. Scopul planificării este de a prezenta aceste cerințe ca un set de sarcini individuale care pot fi controlate.

Determinarea resurselor necesare. Planurile detaliate vor determina numărul de persoane echipamentul necesarși condițiile de funcționare care vor fi necesare pentru finalizarea proiectului.

Coordonarea lucrului in echipa pe proiect. De foarte multe ori, execuția unui proiect este împărțită în activități separate care pot fi realizate în paralel. Planurile fac posibilă coordonarea acestor activități prin definirea cine ce face și când.

Evaluarea riscurilor potențiale. Deși unele riscuri pot fi identificate în timpul formulării cerințelor, multe altele sunt identificate după ce a fost efectuată planificarea detaliată. Cunoașterea existenței acestor riscuri vă va permite să le observați mai devreme (dacă s-au materializat) și să vă pregătiți să le abordați.

Alertă de problemă. Abaterea de la plan servește ca semnal al problemelor. Planurile nu sunt o dogmă care trebuie urmată necondiționat. Pentru managerul de proiect, acestea sunt mai mult o presupunere și o bază pentru comparație. Dacă implementarea proiectului nu se ridică la nivelul așteptărilor, atunci este necesar să se efectueze o ajustare adecvată a planului.

grup procesele de planificare prezentată în fig. 3.10. Aceste procese pot fi repetate și pot face parte dintr-o procedură iterativă care se efectuează până la obținerea unui anumit rezultat. De exemplu, dacă data inițială de finalizare a proiectului este inacceptabilă, atunci resursele necesare, costul și uneori ( Grupuri de procese ^ Managementul proiectelor

Grupul de procese de planificare

Managementul resurselor umane de proiect

Planificare

Elaborarea unui plan de management al resurselor umane resurse

Definiție

Managementul timpului de proiect

Definiție

operațiuni

Control

integritate

Planificarea achizițiilor

Managementul costurilor de proiect^

Cost estimat

Managementul Calității Proiectului

Elaborarea unui plan de management de proiect

Definiție

secvente

operațiuni

resurse operaționale

Planificare

calitate

durată

operațiuni

Dezvoltare

orare

Managementul riscului de proiect

Definiție

Planificare

management

risc

Efectuarea unei analize calitative de risc

Efectuarea unei analize cantitative de risc

Planificarea răspunsului la risc

Orez. RĂU. Procese de planificare

proiectul trebuie schimbat. Rezultatul în acest caz va fi termenii conveniți, volumele, nomenclatorul resurselor, bugetul și conținutul proiectului, corespunzător obiectivelor acestuia.

Planificarea este o condiție prealabilă necesară pentru implementarea oricărei sarcini, chiar și a celei mai simple sarcini. Planificarea inadecvată poate duce la eșecul proiectului sau poate produce rezultate inadecvate în mediul proiectului.

Planificarea într-o formă sau alta se realizează pe toată durata de viață a proiectului. La începutul ciclului de viață al unui proiect, se dezvoltă de obicei un plan inițial informal - o idee aproximativă despre ceea ce va trebui făcut dacă proiectul este implementat. Decizia de a selecta un proiect se bazează în mare măsură pe evaluările acestui plan inițial. Planificarea formală și detaliată a proiectului începe după luarea deciziei de implementare a acestuia.

Planificarea constă în întocmirea următoarelor planuri:

  • efectuarea muncii, inclusiv o evaluare a intensității muncii și a termenelor limită;
  • gestionarea conținutului și domeniului de activitate;
  • structura organizationala;
  • managementul configurației;
  • administrare de calitate;
  • managementul riscurilor;
  • managementul achizițiilor;
  • certificarea rezultatelor de proiectare și a activităților executanților.

Definiție niveluri de planificare face si subiect de planificare si se realizeaza pentru fiecare proiect specific, tinand cont de specificul acestuia, amploarea, geografia, calendarul etc. Pe parcursul acestui proces se determină tipul și numărul de niveluri de planificare corespunzătoare pachetelor de lucru alocate pentru proiect, relațiile lor de fond și temporal.

Planurile (grafice, rețele) ca expresie a rezultatelor proceselor de planificare ar trebui să formeze în agregat o anumită structură piramidală care să aibă proprietățile de agregare a informațiilor, diferențiate pe niveluri de management al conștientizării, și să fie eșalonată din punct de vedere al timpului de dezvoltare (scurt). -termen, pe termen mediu și lung). Nivelurile de planificare și un sistem de planuri trebuie construite folosind principiile " părere” care oferă o comparație constantă a datelor planificate cu datele reale, acestea trebuie să fie extrem de flexibile, relevante și eficiente.

Planurile de rețea sunt aglomerate datorită faptului că planul general de rețea constă din multe planuri de rețea privată. În fiecare dintre aceste planuri private, este determinată calea cea mai lungă. Aceste căi sunt apoi puse în locul părților individuale ale rețelei. Cu ajutorul unei astfel de agregări graduale, se obțin planuri de rețea pe mai multe niveluri (Fig. 3.11). De obicei, există un plan conceptual, plan strategic implementarea proiectului, planuri tactice (detaliate, operaționale).

Plan de rețea cu mai multe proiecte (pentru management superior)

Nivelul 1

Nivelul 3

Nivelul 2

Plan de rețea cu repere

Plan detaliat de rețea

Orez. 3.11.Planuri de rețea pe niveluri

Planificare conceptuală, al cărui rezultat este un plan conceptual, este procesul de elaborare a documentației principale pentru proiect, cerinte tehnice, evaluări, grafice integrate, proceduri de control și management. Planificarea conceptuală se realizează în perioada inițială a ciclului de viață al proiectului.

Planificare strategica este un proces de dezvoltare a planurilor strategice, extinse, pe termen lung.

Detaliat (operațional), tactic) planificare asociat cu dezvoltarea de planuri (programe) tactice, detaliate, bazate pe o structură ierarhică de lucru (WBS) pentru managementul operațional

la nivelul executorilor responsabili.

Planificarea managementului conținutului. Una dintre „bolile” comune ale proiectelor software se numește „rism târâtor”, când un șopron pentru depozitarea uneltelor de grădină este atașat mai întâi la o cabină proiectată inițial pentru un câine iubit, iar apoi o casă de mai multe etaje pentru proprietarul său. Și încearcă să construiască toate acestea pe aceeași fundație și din aceleași materiale. Această abordare a cauzat moartea multor proiecte de dezvoltare software. Prin urmare, de îndată ce a fost posibil să se stabilească și să se convină asupra WBS - structura ierarhică a muncii, este necesar să se dezvolte planul de management al domeniului proiectului, pentru care ar trebui:

  • identifica sursele cererilor de schimbare;
  • stabilirea unei proceduri de revizuire, evaluare și aprobare/respingere a modificărilor de conținut;
  • stabilirea procedurii de documentare a modificărilor de conținut;
  • stabilirea procedurii de informare cu privire la modificările de conținut. Prima sarcină care trebuie rezolvată la analizarea unei interogări

pentru modificări - pentru a identifica obiectele modificării: cerințe, arhitectură, structuri de date, coduri sursă, scripturi de testare, documentație utilizator etc. Apoi se cere să se proiecteze și să descrie în detaliu modificările din toate obiectele identificate. În cele din urmă, ar trebui evaluate costurile pentru efectuarea acestor modificări, testarea modificărilor și impactul acestora asupra calendarului proiectului. Această muncă va necesita ore de lucru, și uneori semnificative, ale diferiților specialiști: analiști, designeri, dezvoltatori, testeri, precum și un manager de proiect, și de aceea trebuie luat în considerare în plan.

Planificarea structurii organizatorice.Structura organizationala- aceasta este o distribuție agreată și aprobată a rolurilor, responsabilităților și obiectivelor activităților participanților cheie la proiect. Trebuie să includă în mod necesar următoarele:

  • un sistem de relații de lucru între grupurile de lucru ale proiectului;
  • sistem de raportare;
  • evaluarea progresului proiectului;
  • sistem de luare a deciziilor.

Trebuie amintit că structura organizatorică a proiectului este un organism „viu”. Începe să prindă contur în etapa de planificare și trebuie să se schimbe pe măsură ce proiectul progresează. Instabilitatea structurii organizatorice (schimbarea frecventă a interpreților) poate deveni o problemă serioasă în managementul proiectului, deoarece există un preț de înlocuire, care este determinat de momentul în care un nou participant intră în contextul proiectului.

Planificarea managementului configurației. Unul dintre procesele importante ale producției de software este managementul configurației. S-a scris mai mult de o carte despre acest domeniu de cunoaștere. Se va vorbi doar despre cum ar trebui să fie planificată această lucrare. Planul de management al configurației proiectului ar trebui să includă:

  • munca pentru a oferi un singur depozit al tuturor documentației de proiect și al codului de program dezvoltat, pentru a asigura siguranța și recuperarea informațiilor despre proiect după un eșec;
  • lucrează la configurarea stațiilor de lucru și a serverelor utilizate de membrii echipei de proiect;
  • munca necesară pentru organizarea ansamblului edițiilor intermediare ale sistemului, precum și versiunea finală a acestuia.

Această lucrare este de obicei efectuată de un inginer de configurare. Dacă proiectul este mic, atunci acest rol poate fi suplimentar pentru unul dintre programatori sau managerul de proiect. În primul rând, „ungerea” acestei lucrări asupra tuturor participanților la proiect este ineficientă. Instalarea și configurarea mediilor de dezvoltare, cum ar fi bazele de date și serverele de aplicații, necesită anumite competențe și cunoștințe despre caracteristicile versiunilor specifice de produs. Dacă aceste abilități trebuie să fie stăpânite de toți dezvoltatorii, atunci va dura prea mult timp de lucru. În al doilea rând, munca de gestionare a configurației de „mântuire” poate duce la iresponsabilitate colectivă, atunci când nimeni nu știe de ce proiectul „nu merge” și cum se „retroduce” la versiunea anterioară.

Managementul configurației poate deveni mult mai complicat dacă echipa de proiect trebuie să susțină mai multe versiuni ale acestui produs care au fost instalate anterior de diferiți clienți în paralel cu dezvoltarea de noi funcționalități de produs, dar toată această muncă ar trebui să fie luată în considerare în planul proiectului.

Planificarea managementului calitatii. Un alt domeniu de bază al cunoștințelor în ingineria software este asigurarea calității. Există opinii diferite despre ce este calitatea software-ului și cum să o asigurați eficient. Ne vom limita la afirmația că asigurarea calității este o lucrare destul de importantă care ar trebui planificată în prealabil și realizată pe parcursul întregului proiect software, și nu doar în timpul testelor de acceptare.

La planificarea acestei lucrări, trebuie să se înțeleagă că produsul proiectului nu trebuie să fie de cea mai înaltă calitate posibilă, ceea ce este de neatins într-un timp finit. Calitate cerută produsul este determinat de cerințele pentru acesta. Sarcina principală a asigurării calității nu este de a căuta erori în produsul finit (controlul producției), ci de a le preveni în procesul de producție.

Planul de management al calitatii ar trebui să includă următoarele activități:

  • verificarea obiectivă a conformității produselor software și a operațiunilor tehnologice cu standardele, procedurile și cerințele aplicabile;
  • determinarea abaterilor de calitate, identificarea cauzelor acestora, aplicarea măsurilor de eliminare a acestora, precum și controlul punerii în aplicare a măsurilor luate și eficacității acestora;
  • furnizarea de top management cu informații independente despre neconformități care nu pot fi rezolvate la nivel de proiect.

Clarificarea conținutului și domeniului de activitate. Clarificarea conținutului (descompunerea) proiectului este una dintre cele mai importante părțile constitutive discipline de management de proiect. Detalierea vă permite să evaluați, de exemplu, costul total al proiectului prin costul total al lucrărilor sale individuale. Rezultatul detalierii domeniului de aplicare al proiectului este structura de defalcare a muncii(Work Breakdown Structure - WBS). În cele mai multe cazuri, această structură este ierarhică. În același timp, procesul de detaliere este structura de defalcare a muncii, adică activitatea de creare a unei structuri de lucru detaliate sau a sarcinii de proiect.

Structura ierarhică a lucrărilor(WBS) este o descompunere orientată către rezultate a muncii efectuate de echipa de proiect pentru a atinge obiectivele proiectului și rezultatele cerute. Cu ajutorul acestuia, întregul conținut al proiectului este structurat și definit. Fiecare nivel următor al ierarhiei reflectă o definiție mai detaliată a elementelor proiectului. Baza dezvoltării WBS este conceptul de proiect, care definește produsele proiectului și principalele lor caracteristici. WBS se asigură că toate activitățile necesare pentru atingerea obiectivelor proiectului sunt identificate. Multe proiecte eșuează nu pentru că nu au un plan, ci pentru că planul omite lucrări importante, cum ar fi testarea și remedierea erorilor, precum și produsele de proiect, cum ar fi documentația utilizatorului. Prin urmare, dacă WBS este compilat corect, atunci orice lucrare care nu este inclusă în el nu poate fi considerată lucrare la proiect. WBS împarte proiectul în subproiecte, pachete de lucru, subpachete. Fiecare nivel următor de descompunere oferă o detaliere consecventă a conținutului proiectului, ceea ce vă permite să estimați momentul și domeniul de activitate. WBS ar trebui să includă toate produsele intermediare și finale.

Puteți descompune munca unui proiect în diferite moduri. De exemplu, GOST 19.102-77 prevede abordarea cascadeiși definește următoarele etapele dezvoltării sistemului software.

  • 1) termeni de referință;
  • 2) proiect de proiect;
  • 3) proiect tehnic;
  • 4) proiect de lucru;
  • 5) implementare.

Dacă urmați acest standard, atunci aceste produse de proiect ar trebui să fie la primul nivel al WBS. Dacă ar fi trebuit să dezvolți un sistem de control automatizat pentru management reactor nuclear sau cu echipaj nava spatiala, exact asta ar fi trebuit făcut. Cu toate acestea, în dezvoltarea de software comercial, această abordare este ineficientă.

Procesul modern de dezvoltare a software-ului comercial trebuie să fie incremental. Aceasta înseamnă că la nivelul superior al descompunerii proiectului ar trebui să existe produsele proiectului, iar la nivelul următor - componentele din care constau aceste produse. Componentele pot fi apoi descompuse în „funcții” - funcțiile pe care trebuie să le implementeze.

Izolarea componentelor care alcătuiesc software, este un element de proiectare la nivel înalt, care ar trebui realizat în faza de planificare a proiectului, fără a aștepta dezvoltarea tuturor cerințelor funcționale pentru software-ul în curs de dezvoltare. Componentele pot fi atât subsisteme de aplicație, cât și infrastructură sau nucleare, de exemplu, un subsistem de autentificare, securitate, o bibliotecă de componente vizuale ale unei interfețe grafice (GUI). Când elaborați un plan de lucru de bază, nu ar trebui să vă străduiți să detaliați toată activitatea IBS cât mai mult posibil, 3-5 niveluri sunt suficiente.

În contextul detalierii, termenii „sarcini” și „lucrări” sunt adesea folosiți în mod interschimbabil. Cu toate acestea, este mai corect să spunem că sarcina determină obținerea unui rezultat intermediar, iar munca este un set de acțiuni pentru a obține aceste rezultate. Întrucât orice sarcină necesită o anumită muncă pentru a fi efectuată sub anumite constrângeri, se poate vorbi cu siguranță despre „matarea” neîndoielnică a sarcinilor la locul de muncă și invers. Acesta este motivul interschimbabilității termenilor în Viata de zi cu zi. În același timp, înțelegerea diferențelor dintre aceste concepte vă permite să simțiți nuanțele unei viziuni de proces a creării produsului și, în consecință, ciclul de viață al proiectelor, inclusiv proiectelor de sisteme software.

LA caz general se poate vorbi despre detalierea: „program – proiect - sarcina este o operațiune. Pe fig. 3.12 prezintă un exemplu de astfel de detaliere (sunt afișate doar operațiunile Sarcinii DAR).


Orez. 3.12.Un exemplu de utilizare a termenilor: program, proiect, sarcină, operațiune

Fiecare element al unei astfel de structuri are constrângeri și alte caracteristici semnificative și date asociate cu acesta. Semnificația se referă la necesitatea sau utilitatea lor pentru luarea deciziilor. Profunzimea detaliilor și nivelul de utilizare a anumitor termeni depind de proiectul specific, cultura de management, standardele ciclului de viață, specificul și domeniul de aplicare al proiectului, precum și de alți factori care sunt unici atât pentru o anumită organizație, cât și pentru o anumită organizație. proiect.

Toate părțile proiectului (subproiectele și pachetele de lucru) trebuie trase la răspundere personală. Pentru fiecare pachet de lucru, rezultatul trebuie să fie clar definit. Activitățile și estimările proiectului trebuie convenite cu membrii echipei cheie, conducerea companiei de implementare și, dacă este necesar, cu clientul. Ca urmare a coordonării, membrii echipei își asumă obligații pentru implementarea proiectului, iar conducerea își asumă responsabilitatea pentru asigurarea proiectului cu resursele necesare.

WBS este unul dintre principalele instrumente (mijloace) din mecanismul de management al proiectelor, care măsoară gradul de realizare a rezultatelor proiectului. Funcția sa cea mai importantă este de a se asigura că toți participanții la proiect înțeleg și înțeleg cum va fi realizat proiectul. Ulterior, linia de referință va servi drept reper pentru compararea cu execuția curentă a proiectului pentru a identifica abaterile.

Estimarea costurilor proiectului. Procesul de gestionare a unui proiect software începe cu un set de activități care sunt denumite în mod colectiv Planificarea proiectului. Prima dintre aceste acțiuni este efectuarea unei estimări de cost a proiectului. El pune bazele altor activități de planificare a proiectelor. La evaluarea unui proiect, prețul greșelilor este extrem de mare. Este foarte important să se efectueze o evaluare cu risc minim.

Principala dificultate în modelarea algoritmică a costului proiectului este dependența estimării costurilor de proprietățile și parametrii produsului finit. Într-o etapă incipientă a proiectului, este imposibil să se determine cu exactitate aceste proprietăți și parametri. Există multe metode de estimare a costului PP, care ar trebui utilizate în paralel. Dacă rezultatele obținute sunt foarte diferite, înseamnă că pentru analiză au fost folosite informații insuficiente sau inadecvate. Prețul produsului software adesea determinate în prealabil în scopul atribuirii unui contract, ceea ce duce la adaptarea ulterioară a funcționalității sistemului la cele care ar corespunde acestui preț.

Cunoscut modelul de estimare a costurilor proiectului B. Boehma SOSOMO ia în considerare caracteristicile de proiectare, proprietățile software-ului creat, hardware-ul și capacitățile personalului. Acest model include și instrumente pentru determinarea duratei lucrărilor la proiect. Timpul de finalizare a lucrării nu este direct proporțional cu numărul de specialiști angajați pentru proiect. Implicarea mai multor oameni într-un proiect care este în întârziere poate întârzia și mai mult finalizarea acestuia.

Modelele algoritmice de costuri ale proiectelor sunt folosite pentru a gestiona proiectele software, deoarece suportă analiza cantitativa parametrii. Aceste modele vă permit să evaluați contribuția fiecărui parametru individual la costul total al proiectului și să faceți o comparație obiectivă (deși nu imună la erori) a acestor parametri.

Estimarea costului proiectului- una dintre cele mai lucrări importante asupra proiectului, care se determină pe baza costului părților individuale ale proiectului, a condițiilor de executare a lucrărilor, a personalului efectiv al executanților, a metodelor și instrumentelor utilizate. Costul proiectului include și costul întreținerii proiectului, adică. calculatoare, software, pătrate, mobilier, telefoane, modemuri și multe altele. În plus, uneori este necesar să se țină cont Cheltuieli suplimentare(de exemplu, securitate). Costurile suplimentare pentru proiect includ achiziționarea unui sistem de testare, sistem SABE etc. Principala estimare a proiectului este estimarea costului proiectului, exprimat în oameni-zile de muncă ale artiștilor interpreți la proiect. Această evaluare este efectuată într-un stadiu incipient de întreținere și planificare.

Costul total al proiectului este determinat de specialiști experimentați cu o eroare de până la 10%. Estimările costurilor pot fi de sus în jos, de jos în sus sau bazate pe costul unui proiect fabricat anterior. Experții efectuează o evaluare pesimistă, optimistă și reală prin sondajul tuturor membrilor grup de lucruși ajustând fiecare estimare pentru a obține cea mai plauzibilă. În unele grupuri de lucru, evaluările pesimiste și optimiste pot fi foarte diferite.

Metode algoritmice de estimare a costului unui proiect afișarea relațiilor dintre costurile proiectului și factorii care le afectează.

Există diverse abordări empirice pentru estimarea costului unui proiect, de exemplu, costul unui proiect este propus să fie determinat prin formula

PREȚ = (a + b?)m(X),

unde 5 este o estimare a dimensiunii sistemului; a, b, c - constante empirice; X - vector al factorilor de cost cu dimensiune vineri - factor de ajustare bazat pe factori de cost.

O estimare mai simplificată obținută experimental este exprimată după cum urmează:

COST = 5,255 0,91 .

Aceste estimări s-au bazat pe analiza proiectelor în care programele variau între 4.000 și 467.000 de linii de cod și au fost scrise în 28 de limbaje de programare diferite pentru 66 de computere. De la 12 la 11.758 de luni-om petrecute pentru dezvoltare. Sunt cunoscute și alte tehnici empirice de modelare.

Primele modele au folosit indicatori de preț, au luat în considerare personalul și proprietățile proiectului, produs și mediu. Modelele includ o evaluare a celor trei etape ale managementului de proiect. În prima etapă, se construiește un prototip pentru sarcini cu risc ridicat (interfață utilizator, software, sistem de interacțiune, implementări etc.) și se estimează costurile (de exemplu, numărul de tabele din baza de date, ecrane și formulare de raportare etc. .). În a doua etapă se face o evaluare a costurilor de proiectare și implementare a punctelor funcționale ale proiectului, reflectate în cerințele pentru proiect. În a treia etapă, evaluarea se referă la proiectarea finalizată, când dimensiunea sistemului poate fi determinată în termeni de linii de program finite și alți factori.

Următoarea ecuație servește ca model de bază pentru evaluarea experimentală a costului proiectului astăzi:

COST = bS c m(X),

Unde bS c - estimarea inițială, care este ajustată folosind vectorul cost m(X)și contabilizarea numărului de instalații vechi și noi; Cu- un parametru care se modifică de la zero la unu pentru prima etapă a proiectului și de la 1,01 la 1,26 - pentru etapele rămase.

Cu o abordare formalizată, evaluarea proiectului se bazează pe utilizarea metricilor LOC și FP.

Model valoric constructiv(COSOMO - Modelul de cost constructiv), propus de B. Boehm, combină cele mai cunoscute tehnici formalizate de evaluare a proiectelor - estimări LOC(LOC - Lines of Code), care se bazează pe numărul de linii de cod de program. În procesul de aplicare a acestui model se formează estimări preliminare care permit clientului să prezinte cerințe corecte pentru costul și costurile dezvoltării software-ului și oferă, de asemenea, posibilitatea întocmirii unui plan software.

Valori FP orientate pe caracteristiciîn loc să se calculeze scorul LOC, produsul software este măsurat indirect. Nu dimensiunea este luată în considerare, ci funcționalitatea sau utilitatea produsului. Autorul acestei metrici este A. Albrecht. Determinarea dimensiunii caracteristicii constă din mai mulți pași și începe cu identificarea caracteristicilor pe care ar trebui să le aibă o aplicație. International Function Point Users Group (IFPUG) a publicat criterii după care sunt determinate funcțiile aplicației. La calcularea FP-metrics sunt utilizate cinci caracteristici informaționale: numărul de intrări externe; numărul de pini externi (pini înseamnă rapoarte, ecrane, imprimări, mesaje de eroare); numărul de solicitări externe; numărul de fișiere logice interne; numărul de fișiere de interfață externă.

După colectarea tuturor informațiilor necesare, treceți la calcul metric - a determina numărul de indicatori de funcție FP (Function Points) după o anumită formulă, unde valorile coeficienților de intrare pentru ajustarea complexității (fiecare coeficient poate prelua valorile: 0 - fără influență; 1 - aleatoriu; 2 - mic; 3 - medie; 4 - important; 5 - principal) sunt selectate empiric în ca urmare a răspunsurilor la 14 întrebări care caracterizează parametrii de sistem ai aplicației.

Metoda constă în măsurarea tuturor capabilităților unei aplicații într-un mod uniform pentru orice proiect și exprimarea dimensiunii aplicației ca un singur număr, care poate fi apoi folosit pentru a estima numărul de linii de cod, costul și timpul proiectului. Pe baza acestuia se formează metrici de performanță, calitate etc.

Avantaj metrica orientată pe funcție este că acestea nu depind de limbajul de programare și sunt ușor de calculat în orice etapă a proiectului.

Defecte metrici orientate funcțional - rezultatele se bazează pe date subiective, nu sunt utilizate măsurători directe, ci indirecte. În plus, trebuie să aveți anumite abilități pentru a aplica această metodă cu acuratețe și consecvență.

Cu ajutorul tabelelor standard, estimările FP pot fi ușor convertite în estimări LOC, adică. după dimensiunea funcțională, calculați numărul de linii de cod. Cu toate acestea, rezultatele recalculării depind de limbajul de programare utilizat pentru implementarea software-ului (de exemplu, în Java, o unitate de dimensiune funcțională este egală cu 53 de linii de cod sursă). La rândul său, numărul de linii de cod vă permite să determinați intensitatea totală a forței de muncă, exprimată în om-luni, și momentul proiectului.

Atunci când se efectuează o evaluare, există două opțiuni pentru utilizarea datelor LOC și FP: ca variabile de evaluare care determină dimensiunea fiecărui element al produsului sau ca metrici colectate în timpul lucrului la proiectele anterioare și incluse în baza de metrică a firmei.

Exemplu 3.1. Să luăm în considerare procedura de realizare a procedurii de evaluare a muncii pe baza metricii GC.

Etapa 1. Zona de destinație a produsului proiectat este împărțită într-un număr de funcții / i, / 2, / 3, fiecare dintre acestea putând fi

evalua individual

Etapa 2. Pentru fiecare funcție/programator generează cel mai bun LOC n, cel mai rău YUS X si probabil YUS V estimări. În procesul de formare a estimărilor, sunt utilizate date experimentale de la o bază metrică sau reprezentări intuitive ale planificatorului. Intervalul de valori posibile ale estimărilor corespunde gradului de incertitudine prevăzut.

Etapa 3. Pentru fiecare functie f t se determină valoarea estimată a devizului:

YUS I + YUS X + 4 LOC^ oj=6"

da.

Etapa 4. Valoarea performanței GC a dezvoltării funcției este calculată în conformitate cu una dintre cele trei reguli.

Regula L. Pentru toate funcțiile se ia aceeași valoare, egală cu productivitatea medie a PR, cf, luată din baza metrică, i.e.

PR, = PR cf; / = 1, 2, ..., P.

regula b. Pentru funcția /-a, pe baza valorii de performanță medie, se calculează o valoare de performanță personalizată:

da medie

MS cool

Unde SUA miercuri - scorul mediu LOC luat de la baza metrică (corespunde productivității medii).

Regula B. Pentru funcția /-a, valoarea performanței reglabile este calculată în funcție de analogul selectat (luat din baza metrică):

LOSzile

ms asteapta

Utilizarea regulii A în pașii următori asigură precizia minimă cu simplitatea maximă a calculelor. Regula B vă permite să obțineți o precizie maximă cu o complexitate maximă a calculelor.

Etapă 5. Estimarea costului total (luni om) pentru proiect este calculată dacă se utilizează regula A:

dacă se utilizează regula B sau C:

b1y ^exp/

Etapa 6. Calculează estimarea costului total al proiectului dacă se utilizează regula A sau B:

COST \u003d UDST cf? YuS 0F /;

dacă se folosește regula B:

COST \u003d UDST an / ^YUS 0J / ,

unde UDST cf este metrica costului mediu al unei linii de cod de program; UDST an, - metrica costului unei linii a analogului (ambele metrici sunt luate din baza metricii).

Elaborarea graficului proiectului. După determinarea complexității lucrării, este necesar să se determine programul de implementare a acestora și termeni generali implementarea proiectului, adică intocmeste un calendar al proiectului Program de bază reprezintă un grafic aprobat cu etapele de timp specificate ale proiectului, reperele și elementele structurii de defalcare a lucrărilor.

Programul de bază este în majoritatea cazurilor un element al contractului cu clientul. Puncte de control (etape) servesc ca puncte de analiză a stării proiectului și de luare a deciziilor în formatul „§o sau 1 §О”, deci ar trebui să demonstreze în mod vizibil stadiul proiectului. Există anumite cerințe pentru selectarea și formarea punctelor de control, de exemplu, punctul de control „Design finalizat” nu este informativ, metoda livrărilor secvențiale este considerată a fi o abordare mai eficientă: punctul de control de mai sus este formulat sub forma „ Testarea cerințelor 1, 3, 5 și 7 a fost finalizată”.

Dacă lucrările nu sunt interconectate, atunci oricare dintre ele poate fi începută și finalizată atunci când ne este convenabil; toate lucrările se pot face în paralel, caz în care durata minimă a proiectului este egală cu durata celui mai lung loc de muncă. Cu toate acestea, în practică, există de obicei dependențe între locuri de muncă, care pot fi „grele”, cum ar fi „analiza - proiectare - codificare - testare - documentare” o anumită funcție sau „soft”, care poate fi revizuită sau atenuată, de exemplu , execuția secvențială a sarcinilor de către un anumit executant poate fi reprogramată pe un alt executant și, în loc să dezvolte software de bază, care ar trebui să precedă dezvoltarea software-ului aplicației, puteți crea „stub-uri” care emulează activitatea acestuia.

Elaborarea unui plan de lucru cu termene limită pentru implementarea acestora poate fi realizată folosind metoda drumului critic CPM sau metoda de analiză și evaluare a programului PERT. Planul proiectului este prezentat pe etape: „Planificare”, „Proiectare”, „Codificare”, „Testare” și „Întreținere”. Planificarea presupune definirea specificațiilor, bugetului și programului, precum și elaborarea planului de proiect în ansamblu.

LA metoda calea critică a proiectului(Critical path) folosește cel mai lung lanț de lucru din proiect. O creștere a duratei oricărei lucrări din acest lanț duce la o creștere a duratei întregului proiect. Un proiect are întotdeauna cel puțin o cale critică, dar poate fi mai mult de una. Calea critică se poate schimba în timpul execuției proiectului.

Atunci când execută un proiect, managerul ar trebui să acorde mai întâi atenție executării sarcinilor de-a lungul căii critice și să monitorizeze apariția altor căi critice. Există recomandare practica: pe calea critică ar trebui să se lucreze cu legături libere, care pot fi întotdeauna reprogramate dacă există amenințarea de termene limită ratate. Programul de lucru este întocmit conform schemei prezentate în fig. 3.13.


Programul de cerințe

la proiect

Orez. 3.13.Pași pentru programarea lucrărilor la un proiect

Când planificați pentru metoda de analiza si evaluare a programelor Evenimentul sau data PERT din plan este un fel de piatră de hotar (punct de verificare) în drumul către implementarea activităților individuale ale proiectului și este folosit pentru a afișa/marca starea de finalizare a anumitor activități. În contextul unui proiect, managerii folosesc repere pentru a indica reperele importante care trebuie atinse pe parcursul unui proiect.

Secvența de etape definite de manager este adesea denumită plan de reper (după evenimente). Definirea unui plan pentru atingerea reperelor relevante creează un program bazat pe repere.

Defalcarea rețelei de lucru și diagrama Gantt pot fi, de asemenea, utilizate în faza de planificare.

Defalcarea rețelei de lucrări(СРР) este o structură ierarhică a descompunerii sarcinilor proiectului în subsarcini. La nivelul inferior, sunt lucrări detaliate pe elementele de activitate din modelul de rețea CPP.

Modelul de rețea vă permite să împărțiți munca în componente și subcomponente principale, să determinați domeniile de activitate care vizează atingerea obiectivelor complexe, să distribuiți pe cei responsabili pentru realizarea lucrărilor individuale pe proiect și să efectuați raportări cu un rezumat al informațiilor privind rezultatele proiectului.

În acest caz, planul de lucru ar trebui să reflecte principalele etape de lucru și starea de lucru necesară în fiecare etapă, împărțirea fiecărei lucrări în sarcini separate, precum și legăturile dintre lucrări, intervalele de timp pentru fiecare activitate, orele de începere și de sfârșit ale lucrării. Planul de lucru include tipuri diferite demonstrații ale funcțiilor proiectului, subsistemelor, fiabilității, echipamentelor de protecție etc. Documentele planului includ, de asemenea, un set de linii directoare și metode pentru efectuarea operațiunilor specificate, menținerea legăturilor de sistem cu alte subsisteme etc.

Planul de lucru sub forma unui grafic CPP conține faze (etape), pași și activități, inclusiv activitățile inițiale și finale ale procesului (Fig. 3.14).

Fază și

Pasul 1 Pasul 2

Orez. 3.14.Graficul pas cu pas al proiectului

O altă formă de prezentare vizuală a planului de lucru poate fi diagramă de rețea, stabilit sub forma unui grafic, la vârfurile cărora se află punctele de lucru, iar pe arce - numărul de zile (săptămâni) necesar pentru a le finaliza (Fig. 3.15). Aceste etichete stabilesc timpul de execuție a procesului. Un arc iese din inițială


Orez. 3.15.

vârf și inclus în vârful final, corespunde marcajului de timp „zero”.

Graficul poate conține trasee ciclice. Conform graficului, se efectuează analiza căilor critice, adică. determina datele privind durata fiecărui proces.

Elaborarea unui program constă în determinarea punctului de plecare (evenimente sau un set de evenimente care au avut loc înainte de începerea execuției unei etape a procesului și pentru care este descris un set de condiții, inclusiv începutul procesului), durata ( interval de timp pentru care procesul trebuie să-și încheie cu succes execuția), termenul (data , până la care procesul își finalizează total sau parțial execuția) și punctul final al procesului (punctul de control la care clientul verifică calitatea rezultatelor procesul).

Programul cel mai de bază vizual poate fi reprezentat Diagrama Gantt- un grafic cu linii, în care sarcinile proiectului sunt reprezentate prin intervale de timp, inclusiv datele de început și de încheiere a implementării lor, ținând cont de eventualele întârzieri. Pe această diagramă operațiunile planificate(elementele structurii de defalcare a lucrărilor) sunt enumerate în partea stângă, datele sunt afișate în partea de sus, iar durata operațiunilor este afișată prin bare orizontale de la data începerii acestei operațiuni până la data finalizării acesteia (Fig. 3.16) .

Plan de proiect

L Elvest K., Goricheva R., Ivannikova O., Plotnikova O.

Specificatiile necesare

2.1. Lista principală de cerințe

Goricheva R.

2.2. Modele de cerințe

Plotnikova O.

2.3. Arhitectură de sistem de nivel înalt

către Sorokina O., Elvest K.

2.4. Criterii de validare a sistemului

Ivannikova O.

2.5. Model de bază de date mitologică

Cechikova A.

2.6. Glosar

Goricheva R., Plotnikova O.

Documentația de proiectare

3.1. proiect de arhitectura

N Elvest K.

3.2. Proiect de interfață cu utilizatorul

| Counters A., Plotnikova O.

3.3. Proiectul Subsisteme

Eu Sorokina O.

3.4. Modelul bazei de date

N Ivannikova O.

3.5. Planul de testare

b Goricheva R.

Document de implementare

4.1. Prezentare generală a implementării

Counters A., Soroki

sha O., Iva

4.2. Manualul utilizatorului

Elvest K., Goricheva

Document de execuție a testului

5.1. Testarea cutiei albe

N Counterchikova A.,

Sorokin

5.2. Testare de integrare

1^ Elvest K

Un tâmplar

5.3. Testare de certificare

cheva R., II

Finalizarea si livrarea proiectului

Tejghea

Orez. 3.16. Diagrama Gantt

Grup de procese de execuție

Grupuri de procese de management de proiect

Managementul Calității Proiectului

Securitate

calitate

Instrumentele software moderne de management de proiect oferă vizualizarea structurii graficului proiectului și a proceselor de execuție a lucrărilor, de exemplu, binecunoscutul și destul de des folosit în practică sistemul de management de proiect. Acest lucru permite dezvoltatorului sau managerului de proiect să vadă cum tipuri diferite activități – în serie sau în paralel, fie că sunt pe calea critică.