Prototype Model

cel mai important dezavantaj al modelelor anterioare (cascadă și spirală) este că au existat o mulțime de respingere a clienților care se întâmplă după dezvoltarea aplicației și nu a existat nicio implicare a clienților între proiect.

prin urmare, au început noua abordare, care este cunoscută sub numele de model prototip. În acest sens, vom colecta cerințele de la client și vom pregăti un prototip (eșantion) și îl vom examina și aproba de către client. Și numai atunci când sunt mulțumiți, vom începe să lucrăm la proiectele originale, astfel încât să nu existe nicio respingere a clienților.

prototipul este doar eșantionul sau un manechin al Produsului software necesar. Dacă toate modulele menționate sunt prezente, atunci numai dezvoltatorul și testerul vor efectua testarea prototipului.

când folosim modelul prototip

în general, mergem pentru acest model din următoarele motive:

  • ori de câte ori clientul este nou în industria software sau când nu știe să dea cerințele companiei.
  • când dezvoltatorii sunt noi în domeniu.

notă:
el diferență între testarea și testarea prototip este că – în testarea, vom lucra la funcționalitatea, care oferă unele de intrare și de ieșire.
și în testarea prototip, vom testa doar aspectul, ceea ce înseamnă că UI și frontend.

procesul modelului prototip

modelul de prototipuri are faze diferite, care sunt după cum urmează:

  • Analiza cerințelor
  • studiu de fezabilitate
  • creați un prototip
  • testarea prototipului
  • revizuirea și aprobarea clienților
  • Proiectare
  • codificare
  • testare
  • instalare și întreținere

model prototip

analiza cerințelor

acest model începe cu colectarea cerințelor de la clienți. Și aceste cerințe ale proiectului ar trebui să fie în detalii. Aceste detalii sunt primite de analistul de afaceri și analistul de produs. În cazul în care Business analyst este atribuit companiilor de software bazate pe servicii, iar analistul de produs este atribuit companiilor de software bazate pe produse.

studiu de fezabilitate

în etapa următoare, șeful echipelor BA, HR, arhitectură și Finanțe va sta împreună și va vorbi despre costul produsului, ce resursă va fi necesară, Ce tehnologie este utilizată pentru a dezvolta produsul și cât timp este necesar pentru a finaliza produsul și a livra.

creați un prototip

după finalizarea studiului de fezabilitate, vom trece la următoarea etapă, unde vom crea prototipul (eșantion sau manechin) pe baza datelor colectate de la client, iar dezvoltatorul web va proiecta prototipul.

aici avem următoarele tipuri de prototipuri:

  • prototip Static
  • prototip dinamic

prototip Static

în prototipul static, am păstrat întregul prototip al cerințelor într-un document word cu toate liniile directoare, captura de ecran și descrierea modului de construire a software-ului, cum va arăta produsul finalizat și cum va funcționa și așa mai departe.

prototip dinamic

prototipul dinamic este paralel cu browserul, dar aici nu putem oferi detalii, doar funcționalitatea este acolo fără a introduce datele. Este ca o pagină falsă făcută din html cu etichete și linkuri către diferitele pagini către caracteristicile expresive ale produsului.

testarea prototipului

odată ce construim prototipul, BA va testa prototipul și va efectua o rundă de testare a prototipului.

notă:
testarea prototip este de testare, în cazul în care vom testa doar aspectul, ceea ce înseamnă că UI și frontend.

Revizuirea și aprobarea clientului

odată ce testarea prototipului se face, acesta va fi predat clientului pentru revizuire și aprobare. Dacă clientul nu este mulțumit de eșantionul dat, vom schimba prototipul pe baza orientărilor și feedback-ului clientului. Acest proces va continua până când Clientul va fi aprobat și mulțumit de prototip. Este un pic consumator de timp, deoarece trebuie să efectuăm modificările din nou și din nou în prototip.

Proiectare

după obținerea prototipului aprobat, vom începe proiectarea la nivel înalt și la nivel scăzut pentru produsul final și vom lua în considerare toate sugestiile date de client în momentul prototipului final.

codificare

odată ce faza de proiectare a fost finalizată cu succes, trecem la faza noastră de codificare, unde dezvoltatorul în cauză începe să dezvolte produsul pe baza cunoștințelor sale de programare.

testare

după compilarea fazei de dezvoltare, acesta este predat inginerului de testare. Și inginerul de testare testează funcționalitatea aplicației și toate intrările și ieșirile.

instalare și întreținere

odată ce produsul nostru final este dezvoltat și testat în conformitate cu prototipul final, acesta va fi implementat în producție. Și produsul va trece prin întreținerea timpului pentru a reduce orice întrerupere, ceea ce ajută la evitarea eșecurilor semnificative.

notă:

  • pornind de la colectarea cerințelor până la revizuirea clienților, formatul documentat este convertit într-un format prototip, deoarece este o fază extinsă de colectare a cerințelor, iar designul real începe din faza de proiectare.
  • anterior, dezvoltarea prototipului se face de către dezvoltatori. Totuși, acum este realizat de dezvoltatori de conținut sau designeri web unde dezvoltă prototipul produsului cu ajutorul unor instrumente.
  • în acest sens, Clientul devine o șansă în sine de pornire pentru a cere modificări în cerința, deoarece este ușor de a face cerințele modificări în prototip, mai degrabă decât aplicația reală. Prin urmare, costul va reduce, iar așteptările sunt îndeplinite.

avantajul și dezavantajul modelului prototip

există următoarele avantaje și dezavantaje ale modelului prototip:

avantaj dezavantaj
putem detecta cu ușurință funcționalitatea lipsă. este un proces consumator de timp, deoarece dacă Clientul se schimbă în prototip.
și, de asemenea, ne va pierde timpul schimbând din nou și din nou în manechin (prototip), ceea ce va întârzia funcționarea proiectului real.
în acest sens, echipa de dezvoltare și clientul au o comunicare clară cu privire la cerințele și rezultatul produsului. nu există nici o revizuire cerință, dar revizuirea prototip este acolo.
în acest sens, satisfacția clienților există. nu există livrabile paralele, ceea ce înseamnă că cele două echipe nu pot lucra împreună.
putem reutiliza prototipul în faza de proiectare și pentru aplicații similare. uneori, aplicația parțială poate face ca software-ul să nu fie utilizat pe măsură ce sistemul complet a fost proiectat.
în acest model, respingerea clientului este mai mică în comparație cu celelalte modele. analiză insuficientă sau parțială a problemelor.
problemele pot fi identificate în faza incipientă. de asemenea, putem pierde atenția clienților dacă nu sunt mulțumiți de produsul final sau de prototipul original.

Leave a Reply