Web Design: Ciclul de planificare

Proiectarea site-urilor web este un subiect de studiu adesea neglijat până după ce a fost dezvoltat un background de programare. Mai rău, poate fi ignorat în totalitate sau ratat de studenții în informatică atunci când cursurile care acoperă subiectul se află în alte programe, cum ar fi artele grafice sau media. Rezultatul este că programatorii încearcă să înțeleagă cum să scrie cod destinat elementelor de aspect și design fără a înțelege designul. Studiind mai întâi aceste elemente, putem dezvolta o mai bună cunoaștere a conceptelor de design web înainte de a scrie cod.

O serie de factori afectează designul în dezvoltarea web, complicând ceea ce altfel i s-ar părea utilizatorului final un proces relativ simplu de afișare a unei imagini sau a unui document. Într-adevăr, procesul de dezvoltare implică nu numai HTML și multimedia care alcătuiesc aspectele vizuale ale paginii, ci și considerații de inginerie software, interacțiune om-computer, asigurarea și testarea calității, managementul proiectelor, ingineria informațiilor și cerințelor, modelarea și analiza și proiectarea sistemului.

Site-urile de astăzi devin acum mai centrate pe aplicații decât site-urile tradiționale. Acest lucru ne complică și mai mult proiectele, pe măsură ce integrăm software și baze de date vechi, ne străduim să satisfacem cerințele de date în timp real, să abordăm vulnerabilitățile de securitate inerente mediului în care lucrăm, și asistență și întreținere continuă tipice aplicațiilor software robuste.

Ca răspuns la aceste progrese în complexitate și capacitate, dezvoltarea web a crescut pentru a îmbrățișa multe dintre aceleași procese ale dezvoltării software.

Dezvoltarea web este cel mai bine realizată ca un proces liniar, dar este de obicei finalizată asincron. Procesul de planificare descris este menit să se bazeze pe el însuși pentru a rafina cerințele proiectului, aspectul și planurile de dezvoltare. Cu toate acestea, limitările în termenele, revizuirile la jumătatea proiectului și timpul extins care poate fi investit în etapele timpurii ale proiectării determină mulți programatori să înceapă dezvoltarea în timp ce un proiect este încă în curs de proiectare.

Începând devreme cu programarea în timpul planificării proiectării se poate accelera un proiect atunci când este puțin probabil ca elementele create devreme să fie afectate de modificările ulterioare ale domeniului de aplicare. Când este realizată cu atenție, programarea timpurie permite, de asemenea, posibilitatea de a testa conceptele înainte de a investi timp într-o idee care poate să nu funcționeze. Este important să evitați aspectele care se presupune că se schimbă, cum ar fi aspectul vizual sau anumite bucăți de conținut, concentrându-vă în schimb pe structura datelor, cadrele și alte componente care sunt ușor de adaptat la modificările de proiectare.

În timp ce planificați, fiți atenți la indicatorii care arată că lucrurile nu merg cum trebuie. Unele dintre problemele mai importante care ar trebui rezolvate includ:

1. Cazuri de utilizare vag definite și cerințe de proiect inadecvate
2. Domeniu de caracteristici prea larg sau nedefinit
3. Dispute nerezolvate între părțile interesate cu privire la caracteristicile proiectului
4. Orar nerealist, buget sau resurse inadecvate

Atunci când vă gândiți la etapele, sarcinile, obiectivele sau orice altă etichetă pe care o puneți dvs. sau  echipa pe obiective, un acronim la îndemână este SMART. SMART înseamnă Specific, Măsurabil, Accesibil, Realist și în Timp util. Ideea este să vă verificați toate obiectivele în raport cu aceste criterii pentru a determina dacă acestea sunt adecvate și bine dezvoltate. Asigurându-vă că toate obiectivele dvs. îndeplinesc criteriile SMART, veți avea șanse mai mari de a vă menține proiectul la timp și bine planificat.

Specific

Obiectivul dvs. este suficient de specific pentru a-și transmite întregul scop? Deși nu doriți să specificați implementarea obiectivului, ar trebui să transmiteți suficiente informații specifice pentru ca persoana desemnată să își poată începe porțiunea de implementare.

Exemplu bun: Livrați propunerea standard cu cotații de preț ajustate pentru a reflecta rata de discount a clienților de 15%.

Exemplu greșit: Livrați o propunere clientului.

Măsurabil

Obiectivul dvs. ar trebui să aibă un indicator clar al momentului în care este finalizat.

Exemplu bun: Completați primele 15 pagini identificate în planul site-ului.

Exemplu greșit: Finalizați primele 20% din site.

Accesibil

Este posibil, sau nu, să finalizăm obiectivul?

Exemplu bun: Duceți serverul la un curier până la închiderea activității în data livrării.

Exemplu greșit: Transportați serverul cu mașina de la Constanța la Timișoara în 24 de ore.

Realist

Este posibil să se finalizeze obiectivul având în vedere cronologia și resursele disponibile?

Exemplu bun: Solicitați echipei A (20 persoane) să completeze 10 pagini până mâine.

Exemplu greșit: Solicitați lui Ion, începător, să completeze 10 pagini până mâine.

La timp

Va fi obiectivul util dacă este finalizat la (nu aproape de sau înainte de) termenul limită?

Presupunând un termen limită de propunere pentru vineri dimineață:

Exemplu bun: Finalizați harta site-ului până la sfârșitul zilei de miercuri pentru a o include în propunere.

Exemplu greșit: Finalizați harta site-ului până la sfârșitul zilei de vineri pentru a o include în propunere.

„Dar, stai așa,, accesibil și realist sună ca fiind același lucru!” Ei bine, da, sunt destul de asemănătoare. Cu toate acestea, diferența constă în ceea ce mai știți despre proiect, cronologie, resurse și obiective. În exemplul nostru realist, acest lucru este evidențiat prin specificarea resurselor disponibile pentru obiectiv. Deși compania noastră, de exemplu, ar putea aloca resurse suficiente pentru a completa 10 pagini într-o zi, nu ar putea duce niciodată un server cu mașin de la Constanța la Timișoara într-o zi, indiferent de cât de mulți oameni are sau de cât de repede poate circula mașina la limitele de viteză actuale. În același sens, obiectivul de a crea 10 pagini într-o zi este perfect realizabil pentru compania noastră, de exemplu, dar nu este realist dacă compania nu are suficientă forță de muncă pentru a finaliza sarcina.

În timp ce am dat aceste exemple pentru a evidenția particularitățile fiecărui element al testului nostru de turnesol, obiectivele reale ar putea conține toate acestea împreună în până la două sau trei propoziții scurte:

Echipa A va completa propunerea clientului folosind formularele standard, inclusiv discount-ul acestora și un eșantion de plan de site, până la data de 15 pentru livrarea pe data de 20.

Acum trebuie să testăm. Obiectivul este specific? Da. Nu ne-au mai rămas întrebări de bază nepuse înainte de a putea lucra la obiectiv. Este măsurabil? Da. Avem un termen limită pentru data de 15 a lunii pentru o listă specifică de articole. Este accesibil? Da. Cu resurse adecvate nu este nimic imposibil în ceea ce privește obiectivul. Este realist? Presupunând că echipa A are suficient timp și forță de muncă pentru a finaliza sarcina până la termen, da. Este la timp? Lucrarea se va finaliza cu 5 zile înainte de livrare, permițând timp pentru revizuire, modificări sau întârzieri, iar termenul limită nu depășește durata de viață utilă, deci da, avem un obiectiv SMART.

Cum ajungem la obiectivele noastre? Le extragem ca „aspecte importante” care trebuie extrase din cererea clientului, din declarația de misiune sau din alte surse de informații care definesc domeniul de aplicare al proiectului dvs.

Ce facem cu obiectivele noastre? Persoana (persoanele) însărcinate cu obiectivul îl vor transforma în sarcini acționabile sau elemente individuale care trebuie finalizate. De exemplu, obiectivul nostru ipotetic de zece pagini într-o zi ar putea fi împărțit în zece sarcini, câte una pentru fiecare pagină. Sugestie utilă: SMART poate fi aplicat și sarcinilor (practic, pentru orice planificare / obiectiv viitor).

De ce să te deranjezi cu oricare dintre acestea? De ce chiar să creăm un document de aplicare, în primul rând, dacă știm că lucrurile se vor schimba? Ei bine, o facem pentru că lucrurile se vor schimba. Vor apărea idei noi, ar putea fi găsite probleme sau ar putea fi uitat ceva în mix. Etapa de planificare va defini pentru noi și pentru clientul nostru exact ce vom face și ce este menit să acopere prețul, timpul, termenii etc. Deoarece un proiect este în desfășurare, mai ales dacă se țin întâlniri iterative cu clientul, vor intra în joc noi solicitări. Acestea pot fi idei grozave. Pot fi teribile. Acestea pot deraia succesul proiectului dacă nu sunt finalizate. Cu toate acestea, fiecare dintre ele vă va afecta cronologia și resursele. Tendința de a strânge „încă o idee” din nou și din nou se numește ”Feature Creep” (extindere excesivă), deoarece se strecoară în proiectul tău și, în cele din urmă, îți mănâncă resursele și profitul.

Sursa: Michael Mendez, The Missing Link – An Introduction to Web Development and Programming (CC BY-NC-SA 3.0 License), Published by Open SUNY Textbooks, Milne Library (IITG PI), State University of New York at Geneseo. Traducere de Nicolae Sfetcu

Articol publicat sub licență CC BY-NC-SA 3.0