Articolul principal: Model cascadă

Model cascadă ciclu de viață(Engleză) model de cascadă) a fost propus în 1970 de Winston Royce. Acesta prevede implementarea succesivă a tuturor etapelor proiectului într-o ordine strict fixă. Trecerea la etapa următoare înseamnă finalizarea completă a lucrărilor în etapa anterioară. Cerințele determinate în etapa formării cerințelor sunt strict documentate sub formă de specificații tehnice și sunt înregistrate pentru întreaga dezvoltare a proiectului. Fiecare etapă culminează cu lansarea unui set complet de documentație suficientă pentru a permite continuarea dezvoltării de către o altă echipă de dezvoltare.

Etapele proiectului conform modelului cascadei:

1. Formarea cerințelor;

2. Design;

3. Implementare;

4. Testare;

5. Implementare;

6. Operare și întreținere.

Avantaje:

· Documentație completă și coordonată la fiecare etapă;

· Este ușor de determinat calendarul și costurile proiectului.

Defecte:

În modelul în cascadă, trecerea de la o fază de proiect la alta presupune că rezultatul (ieșirea) fazei anterioare este complet corect. Cu toate acestea, inexactitatea oricărei cerințe sau interpretarea ei incorectă are ca rezultat faptul că este necesar să „retragi” la faza incipientă a proiectului, iar reelaborarea necesară nu numai că aruncă echipa de proiect în afara programului, dar duce adesea la o evaluare calitativă. creșterea costurilor și, eventual, până la rezilierea proiectului în forma în care a fost inițial destinat. Conform specialiști moderni Principalele concepții greșite ale autorilor modelului cascadei sunt ipotezele că proiectul trece prin întregul proces o dată, arhitectura proiectată este bună și ușor de utilizat, designul de implementare este rezonabil și erorile de implementare sunt ușor eliminate. prin testare. Acest model presupune că toate erorile vor fi concentrate în implementare și, prin urmare, eliminarea lor are loc uniform în timpul testării componentelor și a sistemului. Astfel, modelul cascadei nu este foarte realist pentru proiecte mari și poate fi folosit eficient doar pentru a crea sisteme mici.

Model iterativ

O alternativă la modelul secvenţial este aşa-numitul model de dezvoltare iterativă şi incrementală. dezvoltare iterativă și incrementală, IID), care a primit tot de la T. Gilb în anii '70. Nume model evolutiv. Acest model se mai numește model iterativȘi model incremental .

Modelul IID implică ruperea ciclului de viață al proiectului într-o succesiune de iterații, fiecare dintre ele seamănă cu un „mini-proiect”, incluzând toate procesele de dezvoltare aplicate la crearea unor piese mai mici de funcționalitate în comparație cu proiectul în ansamblu. Scopul fiecăruia iterații- obținerea unei versiuni funcționale sistem software, inclusiv funcționalitatea definită de conținutul integrat al tuturor iterațiilor anterioare și actuale. Rezultatul iterației finale conține toată funcționalitatea necesară a produsului. Astfel, odată cu finalizarea fiecărei iterații, produsul primește un increment - creştere- la capacitățile sale, care se dezvoltă în consecință evolutiv. Iterativitatea, incrementalitatea și evoluția în acest caz sunt expresia aceluiași sens în cuvinte diferite din puncte de vedere ușor diferite.

După cum spune T. Gilb, „evoluția este o tehnică concepută pentru a crea aspectul de stabilitate. Șanse creație de succes a unui sistem complex va fi maximizat dacă este implementat într-o serie de pași mici și dacă fiecare pas conține un succes clar definit, precum și posibilitatea de „revenire” la cel anterior etapa reusitaîn caz de eșec. Înainte de a pune în acțiune toate resursele destinate creării unui sistem, dezvoltatorul are posibilitatea de a primi semnale de feedback din lumea reală și de a corecta posibile greșeliîn proiect”.

Abordarea IID are și laturile sale negative, care, de fapt, sunt reversul avantajelor. În primul rând, o înțelegere holistică a capacităților și limitărilor proiectului a lipsit de foarte mult timp. În al doilea rând, atunci când iterați, trebuie să renunțați la o parte din munca făcută anterior. În al treilea rând, conștiinciozitatea specialiștilor atunci când efectuează munca este încă în scădere, ceea ce este explicabil din punct de vedere psihologic, deoarece aceștia sunt în mod constant dominați de sentimentul că „totul poate fi refăcut și îmbunătățit oricum mai târziu”.

În majoritatea sunt implementate diverse variante ale abordării iterative metodologii moderne dezvoltare (RUP, MSF, XP).

Model în spirală

Model în spirală(Engleză) model în spirală) a fost dezvoltat la mijlocul anilor 1980 de Barry Boehm. Se bazează pe ciclul clasic Deming PDCA (plan-do-check-act). Atunci când se utilizează acest model, software-ul este creat în mai multe iterații (învârtiri în spirală) folosind metoda de prototipare.

Fiecare iterație corespunde creării unui fragment sau a unei versiuni a software-ului, la care se clarifică obiectivele și caracteristicile proiectului, se evaluează calitatea rezultatelor obținute și se planifică activitatea următoarei iterații.

La fiecare iterație sunt evaluate următoarele:

· riscul depășirii termenelor și costurilor proiectului;

· necesitatea de a efectua o altă iterație;

· gradul de completitudine și acuratețe de înțelegere a cerințelor sistemului;

· fezabilitatea rezilierii proiectului.

Este important de înțeles că modelul în spirală nu este o alternativă la modelul evolutiv (modelul IID), ci o versiune special dezvoltată. Din păcate, modelul în spirală este adesea folosit în mod eronat ca sinonim pentru modelul evolutiv în general, sau (nu mai puțin eronat) menționat ca model complet independent împreună cu IID.

Trăsătură distinctivă Modelul în spirală este o atenție deosebită acordată riscurilor care afectează organizarea ciclului de viață și punctele de control. Boehm formulează cele mai comune 10 riscuri (în funcție de prioritate):

1. Lipsa de specialişti.

2. Termene și buget nerealiste.

3. Implementarea unei funcționalități necorespunzătoare.

4. Proiectarea unei interfețe de utilizator greșite.

5. Perfecționism, optimizare inutilă și șlefuire a detaliilor.

6. Un flux constant de schimbări.

7. Lipsa de informare despre componente externe, definind mediul de sistem sau implicate în integrare.

8. Dezavantaje în munca efectuată de resurse externe (în raport cu proiectul).

9. Performanță insuficientă a sistemului rezultat.

10. Lacuna în calificările specialiștilor din diferite domenii.

Modelul în spirală de astăzi definește următorul set general de puncte de control:

1. Concept of Operations (COO) - conceptul (utilizarea) sistemului;

2. Obiectivele ciclului de viață (LCO) - obiectivele și conținutul ciclului de viață;

3. Life Cycle Architecture (LCA) - arhitectura ciclului de viață; aici se poate vorbi despre gradul de pregătire a arhitecturii conceptuale a sistemului software țintă;

4. Capacitate operațională inițială (IOC) - prima versiune a produsului creată, potrivită pentru funcționarea de probă;

5. Capacitate operațională finală (FOC) – un produs finit, implementat (instalat și configurat) pentru funcționare reală.

Care este modelul cascadei

Ciclul de viață al software-ului este perioada de existență a software-ului asociată cu pregătirea pentru dezvoltarea, dezvoltarea, utilizarea și relucrarea acestuia, începând din momentul în care se ia decizia de a dezvolta sistem nou până în momentul în care toată folosirea lui încetează complet. Modelul ciclului de viață al software-ului identifică seturi specifice de activități, artefacte, roluri și relațiile lor. Determină care artefacte sunt intrările pentru care activități și care artefacte apar ca ieșiri, ce roluri sunt implicate în diverse lucrări, modul în care lucrările se raportează între ele în timp, care sunt criteriile pentru calitatea rezultatelor obținute, cum se evaluează gradul de conformitate a diferitelor artefacte sarcini comune proiect și când să treci de la o activitate la alta.

Modelul ciclului de viață al software-ului Waterfall presupune executarea secvenţială a diferitelor etape de activitate, inclusiv analiza cerinţelor, proiectarea, codificarea şi testarea modulelor individuale (componentelor), testarea ansamblurilor şi testarea integrată a întregului produs final. În acest caz, se presupune o delimitare clară a etapelor, la care un set de documente elaborate în etapa anterioară este transmisă ca date de intrare pentru următoarea. Astfel, fiecare tip de activitate se desfășoară într-o fază a ciclului de viață al software-ului; mișcarea în direcția opusă de-a lungul acestui lanț este imposibilă.

Etapele activității

Analiză. Faza de analiză examinează și determină sarcina pe care programul ar trebui să o îndeplinească. Rezultatul acestei faze este un set de cerințe pentru software.

Proiecta. În această etapă, cerințele identificate în timpul analizei sunt transformate într-o descriere a principiilor de decizie - un document în conformitate cu care se iau decizii specifice în implementarea programului. Principalul rezultat al celei de-a doua faze este primirea unui proiect, care poate include text în limbaj natural, un model software, algoritmi, tabele, formule matematice etc. Proiectarea detaliată presupune identificarea componentelor software, determinarea structurii acestora și a metodelor de interacțiune.

Implementarea. Odată finalizată proiectarea inițială, urmează faza de implementare, în care sunt create și testate modulele software definite în proiect. Principalele rezultate ale acestei faze sunt modulele de cod sursă și testele unitare de sine stătătoare. După implementare, ei trec la testarea sistemului și apoi la punerea în funcțiune.

Implementare și exploatare. Produsul software finit este transferat clientului, se efectuează teste de acceptare, se efectuează instruirea utilizatorilor și operarea de probă, după care software-ul este pus în întreținere și începe operatiune de productie sistem software.

Dezavantajele abordării în cascadă

• Acumularea diferitelor greșeli comise în primele etape ale proiectului. Dacă abia spre sfârșitul proiectului devine evident că s-au făcut erori, atunci orice revenire la etapele anterioare pentru corectarea erorilor devine extrem de costisitoare. Metoda „cascadei” nu identifică și nu atenuează în mod eficient consecințele unor astfel de riscuri.
• Creșterea nejustificată a timpului de implementare, depășirea bugetului și riscul eșecului complet al proiectului datorită acumulării de erori de la etapă la etapă.
• Toate deciziile cheie sunt luate atunci când analiștii și dezvoltatorii nu au o înțelegere completă a sistemului. Este foarte dificil să stabiliți procesul real de creație softwareîntr-o schemă atât de rigidă, de aceea este întotdeauna nevoie să revenim la etapele anterioare pentru a clarifica și revizui mai devreme deciziile luate. La începutul unui proiect, dezvoltatorii se confruntă cu sarcina descurajantă de a defini complet toate cerințele de sistem. Acest lucru necesită discuții atente și cuprinzătoare cu utilizatorii și cercetarea proceselor de afaceri. Utilizatorii trebuie să fie de acord cu tot ceea ce este dezvăluit într-un astfel de sondaj, deși este posibil să nu înțeleagă pe deplin rezultatele. Cu puțin noroc, aproximativ 80% din cerințele pentru sistem pot fi colectate în acest fel în faza de analiză. În timpul proiectării, pot apărea noi probleme, acestea trebuie discutate din nou cu utilizatorii, ceea ce va duce la apariția de noi cerințe pentru sistem. În timpul procesului de implementare și testare, se descoperă adesea că unele dintre deciziile luate anterior nu pot fi implementate sau rezultă că cerințele nu au fost suficient de detaliate și implementarea lor este incorectă. Trebuie să revenim la etapa de analiză și să revizuim aceste cerințe.
• Metoda cascadei nu oferă capacitatea de a se adapta rapid la schimbări, în special în etapele ulterioare ale ciclului de viață al software-ului.
• Este posibil ca produsul final să nu fie solicitat din cauza declarațiilor inexacte ale cerințelor sau modificărilor acestora în timpul perioadă lungă de timp crearea de software.

Când să folosiți abordarea cu cascadă

Abordarea cascadă funcționează bine în proiectele în care cerințele pentru produsul software sunt clar definite și nu ar trebui să se schimbe; nu este necesară implicarea clienților în procesul de dezvoltare. Același lucru este valabil și pentru proiectele software, a căror complexitate este determinată de necesitatea de a implementa algoritmi complecși, iar rolul și domeniul de aplicare al interfeței cu utilizatorul sunt mici.

Comparația dintre cascadă și abordări iterative

Figura de mai jos arată clar diferențele dintre abordările în cascadă și iterative. Abordarea în cascadă implică repararea funcționalității software-ului și a capacității de a varia timpul și resursele (de obicei în sus din motivele prezentate mai sus).

În abordarea în cascadă, clientul este implicat în proiect doar într-un stadiu incipient (pentru a determina cerințele software) sau în cazul unei necesități de modificări identificate de dezvoltatori. El poate evalua doar rezultatul final, care poate să nu corespundă ideilor sale.

Abordarea iterativă presupune participarea unui reprezentant al clientului la proiect în toate etapele. Abordarea iterativă poate facilita și simplifica în mod semnificativ procesul de schimbare a funcționalității software-ului.

Principalele avantaje ale abordării iterative pot fi formulate după cum urmează:

• Capacitatea de a atenua impactul riscurilor grave în fazele incipiente ale proiectului, în timp ce acest lucru poate fi încă realizat cu costuri minime. Diferența de cost a unei erori în determinarea cerințelor la începutul și la sfârșitul proiectului este de 1:200.
• oportunitatea de a organiza un fructuos părere cu viitorii utilizatori finali pentru a crea un sistem care le satisface cu adevărat nevoile;
• concentrarea eforturilor pe cele mai importante și critice domenii ale proiectului;
• testarea iterativă continuă a produsului final, permițându-vă să evaluați succesul întregului proiect în ansamblu;
• detectarea precoce a neconcordanțelor între cerințe, modele și codul programului;
• utilizarea eficientă a experienței acumulate;
• o evaluare reală a stării actuale a proiectului și, ca urmare, o mai mare încredere a clienților și a participanților direcți în finalizarea cu succes a acestuia.

Metodologia de dezvoltare software - organizarea muncii, inclusiv principii ideologice, plan, control asupra proceselor, abordare a angajaților. Să evidențiem 12 tipuri:

• Cascada este o abordare tradițională.
• RUP (Rational Unified Process) - rațional.
• Agile este o metodologie generală de dezvoltare flexibilă.
• Crystal Clear este o abordare pentru egalizarea dezvoltatorilor într-o echipă.
• Metoda spirală - spirală.
• DSDM (Dynamic Systems Development Model) este un model dinamic.
• FDD (Feature Driven Development) este o metodologie care ia în considerare schimbările viitoare.
• JAD (Joint Application Development) este o abordare centrată pe utilizator.
• RAD (Rapid Application Development) este un model de dezvoltare rapidă.
• Scrum este un concept de lucru în condiții de termene limită ratate și criză ideologică.
• XP (Extreme Programming) - dezvoltare extremă într-un mediu dinamic.
• LD (Lean Development) este o metodă care implică un tratament atent al tuturor participanților la proces.

Să încercăm să ne dăm seama ce se ascunde în spatele acestor nume englezești.

Cascadă

Modelul Waterfall aparține înțelegerii clasice a dezvoltării software. Întregul proces este rigid și liniar, are obiective clare pentru fiecare etapă, o nouă fază începe la finalizarea celei anterioare, nu există întoarcere. Avantajele metodologiei cascade sunt descentralizarea și controlul strict asupra timpului și calității execuției.

În practică, Cascada de multe ori nu îndeplinește așteptările, deoarece ignoră schimbările dinamice. Astfel, după testare, este foarte dificil să retragi procesul și să adaugi funcții care nu au fost luate în considerare în etapa de dezvoltare. Cascada este, de asemenea, ineficientă, deoarece implică timpi temporari de nefuncționare pentru angajați în cadrul unui singur proiect. Testarea se efectuează numai la sfârșitul dezvoltării, deși problemele găsite în această etapă sunt costisitoare de rezolvat.

RUP

RUP este o abordare iterativă care rezolvă problemele pe care le are Waterfall. Ce este bun la RUP:

• Conturi pentru schimbarea cerințelor. Oricât de bun este managerul de proiect, este imposibil să ții cont de totul la început.
• Integrarea funcțiilor are loc treptat, adică fiecare „detaliu” trece printr-un ciclu de dezvoltare, testare și implementare în proiect. Ca urmare, riscurile și costurile de producție sunt reduse.
• Lansare timpurie a produsului. Software-ul iese cu funcționalitate redusă pentru a ocupa o nișă pe piață și a rezista concurenților, după care devine copleșit de „carne”.
• Reutilizați. Când creșteți funcționalitatea, este mai ușor să identificați soluții standard care vor reduce timpul de dezvoltare.
• Învățare constantă. Datorită iterațiilor frecvente, dezvoltatorii nu au pauze lungi între revizuirile codului, astfel încât creșterea profesională are loc fără probleme și fără durere.
• Îmbunătățirea continuă a produsului. Iterațiile vă permit să evaluați proiectul nu numai din punctul de vedere al conformității cu planul și specificațiile tehnice, ci și să găsiți modalități de creștere a eficienței și calității produsului.

Agil

Agile este o metodă de dezvoltare software flexibilă care implică un număr mare de iterații. Documentul Agile Manifesto descrie 4 idei și 12 principii ale unei abordări agile; poate fi descris pe scurt în doar două puncte:

• Relațiile informale sunt mai importante decât cele documentate. Adică, acordurile verbale între angajați, între client și antreprenor sunt cele mai importante, așa cum se reflectă în planuri, contracte și specificații tehnice. Cu alte cuvinte, clientul are întotdeauna dreptate.
• Un produs de lucru este principala evaluare a progresului. Nu instrumentele, soluțiile, performanța sau eleganța contează, ci faptul că toate capabilitățile planificate sunt realizate.

În ciuda deficiențelor sale, Agile a devenit un concept fundamental pentru dezvoltarea de software și se reflectă în alte metodologii, care vor fi discutate mai jos.

Limpede de cristal

O metodologie creată pentru echipe mici de 6-10 angajați. De asemenea, susține principiile dezvoltării agile, dar este puțin mai specific. Ideea principală, care este cuprinsă în nume, este că fiecare echipă este un set de oameni cu niveluri diferite de cunoștințe, abilități și experiență diferite.

De aceea, nu există o abordare universală a dezvoltării software; aceasta trebuie determinată în procesul de comunicare în cadrul grupului. Rolurile, instrumentele și standardele sunt de asemenea atribuite acolo. Apoi grupul este luat ca unitate și aceleași probleme sunt rezolvate la un nivel superior până când ierarhia ajunge la client.

Spirală

Modelul ciclului de viață în spirală este o organizație complexă a ciclului de viață al software-ului care se concentrează pe identificarea timpurie și diminuarea riscurilor proiectului. Dezvoltarea începe la scară mică, problemele locale sunt rezolvate, riscurile și modalitățile de reducere a acestora sunt evaluate. Următorul pas acoperă sarcini mai complexe - următoarea tură a spiralei.

Avantajul abordării nu este în creșterea vitezei de dezvoltare, ci în reducerea nivelului riscurilor. Succesul metodei spiralate depinde de un management conștiincios, atent și competent, iar dimensiunea proiectului nu are o importanță fundamentală.

DSDM

Modelul de dezvoltare a sistemelor dinamice a fost dezvoltat în Marea Britanie la mijlocul anilor 1990 și este o dezvoltare evolutivă a dezvoltării rapide a aplicațiilor (RAD). Ideea principală este standard: atunci când planificați de la început, este imposibil să înțelegeți toate complexitățile dezvoltării, astfel încât întregul proces este o muncă de cercetare.

DSDM are și o diviziune în echipe, fiecare având o persoană autorizată să ia decizii strategice. Toate părțile interesate pot participa la proces: utilizatori, dezvoltatori, clienți, manageri. Testarea este efectuată pe parcursul întregului ciclu de viață.

FDD

FDD este un proces care asigură scalabilitatea și repetabilitatea, încurajând în același timp creativitatea și inovația. Iată principiile de bază:

• Dezvoltarea fiecăruia proiect major trebuie să fie sistematic.
• Procesele ar trebui să fie simple și bine dezvoltate.
• Valoarea și logica procesului ar trebui să fie clare pentru fiecare membru al echipei.
• Se acordă preferință ciclurilor de dezvoltare scurte, iterative. Acest lucru reduce numărul de erori și vă permite să creșteți rapid funcționalitatea.

FDD reglementează timpul care ar trebui să fie alocat fiecărui proces. Activitățile organizaționale din ciclu ar trebui să ocupe nu mai mult de 23-25%, în timp ce 75-77% din timp ar trebui să fie alocat dezvoltării directe, asamblarii și testării funcțiilor.

JAD

JAD este o metodologie menită să maximizeze implicarea în dezvoltarea utilizatorilor finali. Acest lucru se întâmplă prin întâlniri și seminarii comune. JAD a fost inventat în anii 1970 de către angajații IBM și este destinat afacerilor în general. Cu toate acestea, de-a lungul timpului, acest concept a început să fie aplicat cu succes dezvoltării software.

Spre deosebire de abordarea Waterfall, JAD are ca rezultat reducerea timpului de dezvoltare, o mai mare satisfacție a clienților și economii la costurile de cercetare de piață. Pe de altă parte, acest lucru necesită un eșantion mare de clienți și necesitatea dezvoltatorilor de a lucra nu cu cerințele stricte ale specificațiilor tehnice, ci cu opinii în continuă schimbare.

RAD

RAD este o metodologie care prioritizează viteza și ușurința dezvoltării. Una dintre condițiile principale este utilizarea unui limbaj de dezvoltare rapidă. Acesta este numele unui limbaj de programare abstract cu ajutorul căruia un programator este capabil să rezolve probleme mai rapid decât cu reprezentanții generației a treia (C/C++, Pascal sau Fortran). Iată mai multe puncte ale conceptului:

• Utilizarea focus-grupurilor pentru a aduna cerințele.
• Prototiparea și testarea de către utilizatori a design-urilor.
• Reutilizarea componentelor software.
• Utilizarea unui plan care nu include reproiectarea sau designul pentru următoarea versiune a produsului.
• Desfășurarea de ședințe informale la cererea uneia dintre părți.

RAD presupune utilizarea unei game întregi de instrumente în plus față de limbajul de dezvoltare rapidă: sisteme de colectare a cerințelor, medii de dezvoltare, cadre, programe pentru comunicare în grup, software de testare.

Scrum

Scrum este o metodă flexibilă de management de proiect al cărei scop este creșterea productivității în echipele paralizate anterior de procese metodologice mai dificile. Conceptul se bazează pe „sprinturi”. Un sprint este o iterație scurtă, strict limitată în timp (de obicei 2-4 săptămâni). În acest moment, durata întâlnirilor este redusă la minimum, dar frecvența acestora crește (se numesc „scrums”).

Acest lucru face controlul execuției mai flexibil și permite dezvoltatorilor să răspundă mai rapid la problemele care apar. Planificarea tradițională trece în plan secund, iar jurnalul de sprint își ia locul.

XP

Programarea extremă este capacitatea de a se dezvolta în fața cerințelor în continuă schimbare. Iată câteva semne:

• Joc de planificare. La începutul proiectului există doar un plan brut, după fiecare iterație claritatea acestuia crește.
• Frecvența mare a lansărilor. O noua versiune Produsul are modificări minore față de cel precedent, dar timpul de lansare este minim.
• Contact cu clientul. Pentru a satisface cerințele publicului final este necesar raspuns prompt pentru comentarii si sugestii.
• Refactorizarea. Îmbunătățirea calității codului fără a reduce funcționalitatea.
• Standard de executare a codului. Sau aplicați reguli generale, sau diferențele de design nu sunt supuse discuțiilor sau criticii.
• Responsabilitatea colectivă. În ciuda faptului că fiecare membru al echipei își desfășoară propriul domeniu de lucru, întreaga echipă este responsabilă pentru codul în ansamblu.

LD

Dezvoltarea software Lean este o altă ramură a metodologiei flexibile, care presupune menținerea unei stări morale și funcționale ridicate a dezvoltatorilor. Aceasta se exprimă în:

• Recompensarea angajaților pentru munca de succes.
• Schimbarea sarcinilor curente numai dacă este necesar sau la cererea clientului.
• Implementarea strictă a planului: orice exces este considerat o pierdere de timp și resurse.
• Prezentarea conceptului general de „Gândește mare, fă puțin, greșește repede, învață repede.”

Într-un scurt rezumat este dificil să dezvălui toate avantajele și dezavantajele metodologiilor, să arate zone eficiente aplicatii. Vom vorbi separat despre cele mai relevante concepte astăzi. Care anume? Lasă-ți dorințele în comentarii.

Datorită creării paralele a părților client și server. Cu toate acestea, a profita efectiv de această arhitectură s-a dovedit a fi foarte dificilă din cauza complexității dramatic crescute a creării de aplicații într-un mediu eterogen. Pe lângă complexitatea naturală a aplicațiilor de construcție într-un mediu eterogen, există tendința ca aplicațiile să devină mai complexe în timp. În aceste condiții, procesul de dezvoltare sisteme de informare Metoda tradițională în cascadă poate dura mult timp, iar rezultatul nu este garantat pentru a satisface nevoile clientului.

Dezavantajele metodei în cascadă sunt imediat evidente. Principala este execuția secvențială a etapelor. De exemplu, programarea poate începe numai după ce analiza și proiectarea au fost finalizate. Acest lucru duce la pierderi mari de timp și nu permite dezvoltarea rapidă a prototipurilor de sisteme software. Principiul cascadei nu este în concordanță cu natura iterativă a dezvoltării sistemului software, deoarece în ultimele etape poate deveni clar că este necesar să se facă modificări la deciziile luate în etapele anterioare.

Se poate adăuga că în cazul metodelor clasice (de exemplu, când zona A reprezenta organizarea în cascadă a dezvoltării și metodele clasice de proiectare a CI integrale, iar zona B reprezenta abordarea PI în versiunea sa clasică), zona ABS era practic gol.

Inițial, impozitul era perceput pe valoarea cifrei de afaceri brute a mărfurilor unei întreprinderi folosind o metodă în mai multe etape (în cascadă), sau așa-numita cumulată, în care taxa era percepută la fiecare etapă de producție sau circulație a mărfurilor. (excluzând cifra de afaceri în cadrul companiei). Acest sistem a funcționat în Germania, Belgia, Austria și alte țări până la sfârșitul anilor 60. Impozitarea repetată a împovărat mărfurile cu taxe și a îngreunat organizarea plății, deoarece necesita utilizarea unui număr mare de documente. O metodă mai simplă de impozitare, la care au trecut majoritatea statelor, este perceperea impozitului pe vânzări o singură dată - în stadiul de producție, comerț cu ridicata sau cu amănuntul, dar la o cotă mai mare. O taxă unică pe cifra de afaceri a mărfurilor în producție, pe de o parte, restrânge centralizarea activităților industriale și întreprinderi comerciale, întrucât valoarea impozitului crește din cauza impozitării nu numai a producției, ci

I. Modelul lui Ansoff este o metodă de căutare adaptivă atunci când se formulează o strategie de întreprindere. După cum indică și numele, metoda folosește o procedură de căutare pentru a dezvolta o strategie. Acest lucru se întâmplă printr-o abordare în cascadă: la început, se stabilesc reguli generale de luare a deciziilor, care sunt clarificate în etapele ulterioare ale procesului, în timp ce obiectivele stabilite la începutul analizei se pot schimba. Aceasta este adaptabilitatea abordării.

Așa cum sugerează și numele, aceasta metoda utilizează o procedură de căutare care duce la formularea unei strategii. Trăsătura sa distinctivă este că abordarea în cascadă formulează mai întâi posibile reguli de decizie (în termeni bruti), apoi sunt rafinate secvenţial în conformitate cu etapele luării deciziilor. Acest lucru face posibilă abordarea aceleiași probleme de mai multe ori, obținând de fiecare dată rezultate mai precise. În prima etapă, trebuie să alegeți una dintre alternative: dacă diversificați sau nu compania. În a doua etapă, se identifică o gamă largă de produse și piețe. În a treia etapă, selecția ulterioară are loc conform

În prezent, o serie de întreprinderi din producția galvanică utilizează echipamente învechite care nu pot fi automatizate. Acest lucru duce la o risipă semnificativă de apă pentru spălare. Introducerea semi-automatelor mai avansate și sisteme automatizate pentru operațiunile de spălare în cascadă permite reducerea consumului de apă proaspătă cu 30-35%. Reducerea consumului de apă dulce va rezolva simultan problema și va îmbunătăți calitatea acoperirilor, deoarece datorită cheltuieli mari apa pentru spălare este dificil de realizat și pregătirea adecvată a apei pentru producția de galvanizare. ÎN industria auto, în fabricarea de instrumente, tractoare și inginerie agricolă, s-au folosit deja metode de spălare în cascadă, ducând la o reducere a consumului de apă dulce cu 35-40%. Întreprinderile grele, de inginerie energetică și de transport și producție de mașini-unelte folosesc în principal linii galvanice staționare care consumă cantități mari de apă dulce.

Pentru a elimina acest dezavantaj, B. Boehm a propus o abordare în spirală. Constă în faptul că dezvoltarea proiectului se desfășoară ca în spirală, iar la fiecare pasă etapele de mai sus se desfășoară secvenţial, la care proiectul este clarificat. Această abordare completează metoda în cascadă cu elemente de iterativitate. Dar se caracterizează și printr-o serie de deficiențe semnificative, care includ

În unele metode de proiectare, creșterea rețelei are loc concomitent cu antrenamentul, vezi, de exemplu, STEPNET, algoritm tiled, burst, arbori neuronali, corelație în cascadă.

Alegerea potrivita dimensiunea rețelei are important. Este pur și simplu imposibil să construiești un model bun, și în același timp foarte mic, și unul prea mare se va adapta prea mult la datele de antrenament și va aproxima prost problema reală. De obicei, se începe cu o rețea mică și o crește treptat până când se obține precizia dorită. În acest caz, rețelele sunt antrenate independent la fiecare pas. O altă abordare folosește un algoritm de auto-creștere, atunci când noi elemente sunt adăugate în rețea pe măsură ce apare nevoia, după care antrenamentul are loc din nou (Stepnet, vezi). Menționăm și metoda corelației în cascadă (vezi). O idee complet diferită stă la baza abordării distructive: în primul rând, se ia o rețea supradimensionată și se îndepărtează conexiunile și nodurile care nu afectează în mod semnificativ soluția (vezi, de exemplu,). Se presupune că limita superioară a mărimii este cunoscută

Proiectarea componentelor paralele. Ca un compromis între o schemă rigidă în cascadă și dezvoltarea absolut arbitrară a fragmentelor IC folosind prototipuri, este propusă o metodă de revizuire a fazei, care este o variantă a unei scheme ciclice. Acest compromis păstrează utilizarea modelelor structurale și documentarea procedurilor sistemului în curs de dezvoltare și presupune că nu există restricții privind flexibilitatea în obținerea rezultatului.

Ecuația logistică binecunoscută este cea mai simplă metodă de simulare a unui model de turbulență în cascadă. Ecuația logistică este caracterizată de calea de la comportamentul ordonat la comportamentul haotic prin dublarea perioadei. Această ecuație este adesea folosită ca un exemplu al modului în care pot fi obținute rezultate aleatorii (din punct de vedere statistic) dintr-o ecuație deterministă simplă. - Faptul că ecuația logistică produce rezultate antipersistente nu este atât de cunoscut. Acest lucru îl face un model nepotrivit pentru piețele de capital, deși poate fi un model bun pentru volatilitate.

Creșterea tehnică și economică indicatori ai U. f. iar îmbunătățirea calității concentratului va fi facilitată de dezvoltarea unei noi metode de îmbogățire a claselor mari de cărbune în medii grele, îmbogățirea claselor mici de cărbune pe jiggers, hidrocicloni și tabele de concentrare, intensificarea proceselor de flotație și introducerea noi reactivi de flotație netoxici, foarte eficienți, noi metode de intensificare a dispozitivelor de uscare, introducerea schemelor de apă-nămol cu ​​utilizarea în cascadă a apei și regenerarea apei de spălare; mecanizarea și automatizarea completă a producției și proceselor. Se lucrează la fabricarea de noi echipamente de înaltă performanță, rezistente la uzură, cu putere sporită de șoc. productivitate. Sistemele de management al operațiunilor din fabrică sunt dezvoltate folosind calculatoare electronice.

Sarcinile slab structurate, împreună cu elementele formalizate cantitativ, conțin componente necunoscute (din cauza unui număr de factori greu de luat în considerare) sau nemăsurabile cantitativ. Incertitudinea sarcinilor slab structurate este de obicei asociată cu formalizarea acțiunilor multifațete pe termen lung și implementarea lor în faze sau în cascadă. Astfel de sarcini includ, de exemplu, crearea de asociații de societăți pe acțiuni independente, îmbunătățirea managementului sistemului de producție interregional (dezvoltarea nivelurilor ierarhice de management și o nouă structură a aparatului de management), normalizarea structurii și condițiilor producție etc. Astfel de probleme sunt rezolvate folosind metodologia de analiză a sistemelor, combinând metode economice și matematice cu modelarea prin simulare. Un rol semnificativ este acordat metodelor calitative de analiză și evaluare a deciziilor.

Astăzi vom aprofunda subiectul și vom vorbi despre instrumentele pe care un manager le folosește în munca sa.

La marcaje

Metodologie

Metodologia în managementul proiectelor este standardizarea implementării proiectelor. Standardizarea înseamnă aici o descriere a etapelor de lucru, liste de verificare pentru verificare - un fel de schiță în care puteți arunca un proiect, iar sub supravegherea unui manager va naviga până la finalizare și produsul finit. Deoarece fiecare proiect este unic într-o măsură sau alta, metodologia nu este un panaceu; mai trebuie să vă gândiți.

Există o mare varietate de metodologii de management de proiect - pot fi utilizate doar într-o singură companie sau pot fi globale. Metodologiile vin sub formă de instrumente (cum ar fi Agile), vin sub formă carte mare cu un set de aceste instrumente (PMBoK, de asemenea o metodologie).

În viața mea, am folosit și folosesc în continuare două dintre cele mai populare metodologii - Cascada („cascada” / „cascada”) și Agile (și ramurile sale - Scrum), care vor fi discutate. De dragul de a lărgi orizonturile cititorului, vă voi spune despre alte lucruri pe care le știu. În cazul în care cititorul lucrează cu digital, atunci „cascada” și „angiversat” vor fi suficiente pentru ochi - le puteți folosi la serviciu, în viață, le puteți spune prietenilor și străinilor, la întâlniri, în timp ce beți un smoothie cu un aspect inteligent.

De unde au venit metodologiile?

Desigur, nimic nu vine de nicăieri, iar Petru cel Mare nu auzise nimic despre agil. Metodologiile sunt inventate de tot felul diferite organizațiiși asociații, în care băieții deștepți își adună problemele în grămezi, apoi înțeleg cum ar fi putut fi evitate și apoi împărtășesc soluțiile cu oameni obișnuiți ca mine, de exemplu. Uneori, metodologiile sunt gândite la nivel de stat - ele rezolvă, de asemenea, probleme și colectează cele mai bune practici (în societatea politicoasă, nu o spuneți așa) în cărți și manuale.

Agil și Cascada

Astăzi vom vorbi în principal despre aceste două animale. După ce ai citit această secțiune, poți merge cu încredere și poți cere cea mai tare poziție de manager de proiect în cea mai mare organizație potrivită din oraș.

Cascadă

Metodologia în cascadă, în cascadă este metoda tradițională, cea mai populară și logică de management de proiect. ÎN formă pură poate funcționa complet proiecte simple. Să presupunem că trebuia să plantezi un copac. „Prin cascadă” implementarea proiectului arată astfel:

• Cumpărați un răsad
• Săpa o groapă
• Puneți un răsad în el
• Stropiți cu pământ
• Udă copacul

Fiecare etapă dintr-un astfel de proiect urmează pe cea anterioară și nu poate fi finalizată înainte de cea anterioară - aceasta este o „cascada”. Acest lucru se suprapune și cu „metoda căii critice”, dar voi vorbi despre asta într-un articol separat - reamintește-mi.

Lucrez cu proiecte în domeniul dezvoltării site-urilor web și aplicatii mobile. Etapele de dezvoltare ale unor astfel de proiecte în cascadă sunt aproximativ aceleași:

• Scrie sarcina tehnica
• Desenați un design
• Alcătuiește designul
• Codifica
• Test
• Lansați proiectul

Pentru a vă deplasa de-a lungul cascadei, trebuie să aveți o specificație tehnică clară și o înțelegere a pașilor care se succed. Din practică, voi spune că este nerealist să lucrați în conformitate cu o cascadă pură - undeva se dovedește întotdeauna că ceva a fost omis, undeva trebuie să reveniți la etapa anterioară și să o faceți în paralel cu etapa actuală. Cu toate acestea, cu cât specificațiile tehnice sunt mai clare, cu atât este mai puțin probabil ca proiectul să meargă lateral. Pentru proiectele în care „mersul lateral” este acceptabil, există Agile.

Agil

„Agil” (sau „agil”, sau „ce păcat” - are multe nume grozave) se referă la un tip de metodologie flexibilă. Principala sa diferență față de o cascadă este produsul de lucru în fiecare etapă a lucrării și finalul neclar al proiectului. În exemplul cu același copac, în care fiecare etapă este secvențială, acest agil nu va funcționa: ei bine, ați cumpărat un răsad, dar ce rost are? Agile are o gamă destul de largă de aplicații, dar mai ales a prins rădăcini în IT. Și tipurile și subtipurile sale au acoperit zonele adiacente cu o peliculă groasă - planificarea afacerii, managementul produselor și așa mai departe și așa mai departe.

Ca exemplu de lucru „agil”, să ne imaginăm un proiect mai complex. Să fie acesta un proiect de construcție. Sarcină: construiește o casă în care să poți locui.

Etape de producție (să ne imaginăm că fiecare etapă are exact un sprint):

• Construiți o cutie cu pereți și tavan
• Construiți un acoperiș și acoperiți pereții cu tencuială
• Instalați uși și ferestre în casă
• Furnizați curent, apă, canalizare
• Puneți parchet laminat și tapet
• Aduceți mobilă și televizor
• Lasă pisica să intre

Cascada sau Agile?

Nicio metodologie nu este un panaceu. Cea mai apropiată analogie pe care o pot face este cu listele de verificare - acesta este un lucru atât de cool (a se citi @salakhmir) care ajută foarte mult la muncă, dar din anumite motive nu funcționează pentru toată lumea. Orice instrument este doar un instrument și nu va funcționa singur. Imaginează-ți că pui o lopată pe pământ și aștepți să se întâmple ceva - așa că aici, pentru a se întâmpla ceva, trebuie să faci ceva.

Folosesc în principal o metodologie hibridă (atât cascadă, cât și agilă), unde există o specificație tehnică, etapele sunt clare, dar apar abateri pe parcursul proiectului. Din exterior poate părea că se întâmplă haos, principalul lucru este să arăți o față înfățișată - totul decurge conform planului. Abaterile intră adesea în proiecte separate, dar de cele mai multe ori rămân în cadrul celui actual și conduc la o creștere a timpului (bugetului) proiectului. Acest lucru pare rău, dar elementul de politică în lucrul cu oamenii (noi lucrăm cu oameni, nu site-uri web, vă amintiți?) nu poate fi exclus.

Metodologie de management organizatii

Aceste organizații, în cea mai mare parte, gestionează dezvoltarea metodologiilor - sunt dezvoltate de aceiași manageri așa cum vei deveni într-o zi. Nu sunt mulți dintre ei în lume, dar toate sunt extrem de importante - pentru bani și timp poți să-și iei diplomele și să mergi la interviuri, impresionându-i pe intervievatori.

PMI

Management de proiect Institutul este prietenul nostru. Am o afecțiune deosebită pentru această organizație - au o comunitate puternică și o bază bună. Organizația are sediul în SUA, există din 1969, iar standardele lor de management de proiect sunt recunoscute de ANSI.

Produsul principal al PMI este corpul de cunoștințe privind managementul de proiect PMBoK; a șasea parte a fost publicată în toamna anului 2017. Corpul de cunoștințe conține schițe ale execuției proiectului în detaliu - de la colectarea cerințelor părților interesate până la închiderea proiectului. Recomand cel puțin să citești cartea - în ea poți citi despre cascadă cu agil, și despre metoda drumului critic și metoda trecerii rapide - subiectele unuia dintre articolele mele viitoare.

Pe lângă PMBoK, PMI are următoarele lucruri de bază: standarde de management de portofoliu (proiect) și program, standarde de management al riscului și Ghidul Scrum. PMBoK nu este o carte IT, metodele din cod sunt aplicabile practic tuturor proiectelor (pentru unele tipuri există extensii separate) - un must-have, în general.

PMI are o grămadă de diferite tipuri de certificări, cu pași și clopote și fluiere. Certificarile PMI sunt bine cunoscute și populare. De exemplu, PMP - profesionist în managementul proiectelor - confirmă într-un fel că puteți gestiona proiecte. Este imposibil să primești certificate de organizație fără experiență, pentru că sunt mai mult ca o confirmare decât ca diploma universitară pe care ai primit-o în timp ce studiai.

IPMA

International Project Management Association este aceeași organizație ca PMI, doar europeană (Elveția), și se aude mai puțin despre asta. Funcționează din 1965 și se numea inițial Internet (când nu era nicio urmă de Internet).

Ce fac ei acolo nu este clar. Ei bine, ei certifică managerii. Ei își publică propriile reviste – ei înșiși și în cadrul reprezentanțelor. Ei câștigă bani. Și slavă lui Dumnezeu.

PRIȚUL 2

„Prince” (Proiecte ÎN Medii Controlate). Metodologia a apărut în 1989 în Marea Britanie (și apoi s-a separat). Caracteristica cheie metodologia este beneficiul pe care procesele din cadrul proiectului îl vor aduce proiectului. Minimizarea riscurilor, menținerea calității proiectului. Proiectele PRINCE2 au, de asemenea, o dificultate structura organizationala cu comitetul de proiect. În caz contrar, astfel de proiecte, precum proiectele care folosesc alte metodologii, au un început, etape și finalizari - totul este familiar și familiar.

P2M

„Un ghid de management de proiecte și programe pentru inovarea întreprinderilor”. Metodologia japoneză de management al proiectelor este proaspătă de data aceasta, este din 1999. Cheia aici este accentul pus pe inovare și gestionarea așteptărilor părțile interesate. Nu l-am întâlnit îndeaproape, nu l-am studiat, nu pot da o evaluare.

Cadrul de soluții Microsoft

Metodologia „proprietă” de management de proiect, MSF, a fost inventată și introdusă în 1994 de Microsoft. Este special prin faptul că a fost dezvoltat direct pentru dezvoltarea de software și nu a fost adaptat, ceea ce se poate spune despre același PMBoK. În exterior, arată ca o listă de recomandări interne (cum ar fi cea din intro) pentru managerii de proiect. Nici măcar Microsoft nu este folosit în forma sa pură - ei adaugă același agil, de exemplu. Wikipedia are un articol informativ despre acest cadru, vă rugăm să mergeți acolo - există mai multe acolo decât vă pot spune.

rezumat

Nimic nu este un panaceu, dar este posibil și necesar să înțelegem principiile și să luăm tot ce este mai bun din ele. În timp ce scriam articolul, cu coada ochiului am dat peste un articol despre Stahanov - a existat un astfel de tip sub sovietici, a fost folosit în propaganda de productivitate sovietică. A lucrat și după metodologie (a extras cărbune), dar într-o zi și-a dat seama că dacă ar rearanja puțin oamenii și începe niște procese în paralel, ar putea lucra mai bine. Așa că mi-am câștigat o pagină pe Wikipedia. La fel este și aici – testați, aplicați și îmbunătățiți (apoi distribuiți). Tot ceea ce întâlnești, toate sfaturile, sunt o ipoteză care trebuie testată. Bucură de ea!

În partea următoare voi încerca să vorbesc despre sarcinile de planificare și timpul, inclusiv despre propriul meu micromanagement. Articolul ar trebui să îi ajute nu numai pe managerii începători, ci și pe cei care lucrează cu ei. Dacă aveți suficientă pasiune, articolul va fi publicat în această săptămână. A scrie scrisori.