Se poate trece la capitolul următor cu tasta ► și se poate reveni la un capitol precedent cu tasta ◄

Modele (tipuri) de dezvoltare


<

C
a
p
i
t
o
l
u
l

a
n
t
e
r
i
o
r

<

Modelul clasic

Modelul clasic este descris exact de ordinea dată de rolurile de la capitolul anterior. E un model clasic, idealistic și nu am văzut sau auzit vreodată de ceva aplicație făcută după acest model. Motive? Dacă faci aplicația după cerințele unui client sunt mari șanse ca peste un timp sau chiar în timpul dezvoltării clientul să-și schimbe cerințele. Asta distruge toată planificarea și (recomandat) totul se reia de la 0. Dacă e făcută pentru public, cu siguranță că Gigel va vrea nu știu ce funcționalitate și lui Marinel nu-i convine cum merge butonul de închidere de nici nu mai are rost să scriu. Modelul clasic e doar literatură.

Prototipizarea

Prototipizarea și dezvoltarea iterativă și incrementală, (pe cât de ciudat sună) combinate, descriu felul în care funcționează dezvoltarea în realitate.

Protitipizarea se referă la dezvoltarea unei versiuni elementare și stângace a aplicației care face doar în mare ce ar trebui. Nu e un Gears of War 3, seamănă mai degrabă cu un Pacman făcut de un puști de clasa a V-a, însă se apropie de definiția unui joc - ca să dau un exemplu. Totul e făcut la repezeală, și multe cruci își fac programatorii când aplicația e compilată, darămite când mai este și executată.

În cazul cel bun, părțile rele sunt ignorate, și, având la îndemână ceva concret, se poate stabili mai bine ce se dorește în final. Din nou, uitându-ne în jur la programele serioase care au fost vândute pe bani grei, o bună parte din ele au fost doar niște prototipuri și nu aș putea să mă satur să fac referire la produsele MS sau la distribuțiile Linux (și aplicațiile pentru acest sistem de operare).

Dezvoltarea iterativă și incrementală

Ea se referă la aceași realitate descrisă mai sus. Întâi faci o fereastră să se deschidă, apoi în ea faci un omuleț să apară, adaugi pe urmă ziduri, inamici, arme și... așa iese Diablo. Practic se implementează o parte din funcționalitate, este evaluată, pe urmă alte părți, și tot așa până când totul este făcut. În teorie punctele urmate sunt:

- planificare (Ce urmează să fie făcut în faza dată - că e la început, sau e al VII-lea pas)

- analiza riscurilor (cât de tare o să strige clientul când aude că iarăși nu e toată aplicația gata)

- inginerie (magie)

- evaluarea clientului (strigătul)

Și modelul aceasta e deseori folosit. Acuma, vorbind la modul serios, nu întotdeauna calculele de acasă se potrivesc cu cele din piață. Să dezvolți o aplicație costă. Timp, bani, energie mentală. Și după ce ai băgat 1, 2 sau mai multe milioane de euro în ceva, mai degrabă lansezi pe piață un produs la un stadiu avansat, însă nu cum doreai tu, decât nimic. Iar asta e o consecință directă a nivelul unde s-a ajuns. Cu totul. De la sisteme de operare până la aplicația de calculator de buzunar a Windows-ului.

Nu se mai fac jocuri ca Prince of Persia, ăla din 1989, 1990, 1991, care și așa, dezvoltarea lui a durat ceva. Acuma ne strâmbăm la Crysis 2 că nu e DirectX 11 și nu poți face cafea în joc. Asta înseamnă evoluția până la urmă, și aici ne aflăm. Însă metodele de a face toate aceste lucruri posibile nu s-au schimbat prea mult din anii 1990. Ca să faci un omuleț 3D să apară pe ecran nu scrii o linie de cod. Scrii aceleași mii și zeci de mii de linii.


>

C
a
p
i
t
o
l
u
l

u
r
m
ă
t
o
r

>

Ți-a fost de ajutor ce am scris aici?
Hei, mersi de răspuns.