De ce ar fi termenii de referință (TOR), pe site-ul?
Indiferent de metoda de dezvoltare nu a fost folosit, și indiferent de mărimea sau a fost site-ul dvs., în orice caz, când întâlniți o întrebare: „Și când am terminat lucrul, atunci ne dăm seama că am terminat cu adevărat?“ În dezvoltarea ambelor. și orice problemă comună site-ul - nimeni nu vede punct final. Pe de o parte, se poate spune că viziunea finală a proiectului ar trebui să aibă un manager de proiect. Dar, în cazul în care produsul final se potrivește cu modul în care managerul, dar nu se potrivește cu așteptările clientului? Și dacă în timpul proiectului a schimbat 3 manageri?
Consecință a lui Parkinson Legea „Nouăzeci și nouăzeci“:
Primele 90% din codul ocupă 90% din timpul de dezvoltare. Restul de 10% din codul dura până a doua 90% din timpul de dezvoltare.
A.Kupera din cartea „pacientii spital de boli mentale în mâinile sale.“
TK nu este doar o listă de cerințe, acest document. În cazul în care contractul reglementează relațiile organizatorice și financiare, TOR reglementează procesul de dezvoltare și rezultatul final.
În acest caz, nu contează site-ul mare sau mic este dezvoltat. Problema unei nepotriviri de așteptări poate avea loc indiferent de suma de bani cheltuite, numai efectele pot fi diferite.
Adăugați restricții.
Ori de câte ori vorbesc despre scris TK, vreau să spun, desigur, o metodă de dezvoltare în cascadă. În cazul altor opțiuni (cum ar fi programarea extremă), precum și alte documente compilate frecvent pe alte principii. Acest lucru este - timp.
În valoare de partajare TOR pentru site-uri mici și mari. Acesta este - două. Diferențele de proiecte mici și mari nu sunt în domeniul de aplicare al documentului de ieșire, precum și în cursul dezvoltării lor. Dacă aveți doar 4 persoane din echipa de proiect, toate au cunoscut de mult unul de altul, putem presupune lipsa de formalism. Dacă suntem implicați în dezvoltarea mai multor „departamente“, iar echipa de proiect este format din mai mult de 10 de un minut (la infinit) personal, controlul hoardei poate doar proces. Procesul dă naștere la formalizarea și formalismul lasă amprenta pe formatul documentului.
De fapt, grosimea documentului depinde de complexitatea procesului într-o măsură mai mare decât dimensiunea proiectului.
Vom urma calea cea mai dificilă.
TK răspunde la întrebări
TK a fost creat inițial pentru dezvoltarea mai multor participanți:
- Dezvoltatorii de proiecte (designeri și programatori).
- Manager de proiect.
- Client.
- Birocrați (ei nu pot participa la proiect, dar, de asemenea, trebuie să conta).
Privind înapoi la dat grup de participanți se poate presupune că TK ar trebui mai întâi de toate pentru a răspunde la întrebările lor. În mod ideal, toate documentația de proiect în metoda cascadă este creată pentru a elimina întrebările din procesul de dezvoltare.
Deci, ce întrebări au răspuns de TK.
Pentru cineva pentru a crea un site și pentru ce?
Așa cum se va rezolva problema clientului și utilizatorilor?
Cum va crearea proiectului?
Aceasta va fi luată la ieșire?
TK începe să se dezvolte și pune capăt la acesta.
În mod ideal, ar trebui să treacă prin toate punctele de TOR cu clientul, pentru a verifica cu sistemul rezultat și o săptămână mai târziu pentru a spune: „Uf. Se pare că totul se face. "
„TK este un mijloc de verificare a muncii depuse.“ - o frază scrisă în introducerea multora dintre TK meu.
Ceea ce este necesar pentru a începe proiectul în continuare?
Aceasta este o întrebare la care este bun trebuie să aibă un răspuns de către client. Acesta este sfatul, dar în unele cazuri, este necesar să se efectueze procesul de proiectare. Ai nevoie de a planifica numărul de locuri de muncă necesare hardware și software, etc.
Ce este TK
Mi-a luat o oră, pentru a lua o decizie: pentru a descrie compoziția TK sub forma unei structuri clare specifice sau doar pentru a vorbi despre ceea ce ar trebui să fie acolo. Amintindu toate TK lor, am ajuns la concluzia că structura documentului sa schimbat atât de des în funcție de o serie de factori, o indicație clară că structura va semăna cu un sfat prost cu privire la alegerea costumului. Imaginați-vă că vă sfătuiesc să poarte ceva pentru seara, nici măcar întrebător în cazul în care aveți de gând.
informații generale
Prima parte a TOR oferă o introducere și informații generale despre documentul și proiectul în ansamblu. Introducerea trebuie să fie scrise o dată pentru toată viața. De regulă, sunt scrise expresie atât de abstractă încât fiecare proiect nou doar am tweak câteva cuvinte.
Informații generale includ:
Aceste informații sunt colectate în domeniul de aplicare al proiectului.
Domeniul de aplicare a proiectului
Dacă mutați departe de casele lor și se întoarse să se uite la el de la o distanță care nu va fi capabil de a discerne detalii ale structurii. Puteți conta ferestrele, dar nu demontați din care acestea sunt materiale, puteți admira arhitectura ( „bucura“ este, desigur, nu poate fiecare casă), dar poate doar ghici despre principiile construcției sale, nu va fi văzut interiorul apartamentelor și mîzgălit cuvântul pe intrare ușă.
domeniul de aplicare al proiectului este de aproximativ aceeași. În acest capitol ar trebui să ne imaginăm că vor fi obținute în procesul de dezvoltare, dar nu este absolut intra în detalii. Scrii că site-ul va lucra, „Înregistrare utilizator“, dar nu scrie exact cum va fi construit, sau ce domenii vor trebui să completeze un utilizator.
Domeniul de aplicare al proiectului sunt scrise sub forma unor scenarii de utilizare cu site-ul și oferă funcționalitatea și interacțiunea cu interfața.
arhitectura de informații și de interfață
Pentru a descrie agenția va trebui să descrie sus în jos:
- Structura site-ului. Această așa-numitele prototipuri la nivel înalt.
- șabloane de pagină. prototipuri de nivel scăzut care descriu interfața site-ului în sine.
- Conținutul de inventar. Descrierea tabelară a conținutului fiecărei pagini.
teren
Sitemap realizată grafic într-una dintre notațiilor bine cunoscute: Visio sau Garrett. Vă recomandăm să elaboreze o hartă a site, deoarece, în acest caz, structura rezultată este obținut cel mai intuitiv și ușor de utilizat mai târziu. Pe de o parte, poate părea că într-o listă a scrie o hartă a site va fi mult mai ușor, dar atunci când se opresc să se gândească la conexiuni între diferite zone ale site-ului le va începe să lovească în mod forțat brusc pătrate pe hârtie.
Pentru a afla cum puteți desena structura site-ului cu ajutorul notație folosind Visio, articole întregi scrise, de ce locuiesc pe ea nu va fi. Articolele sunt scrise, cu toate acestea, în limba engleză, dar puteți lua cu ușurință profita de ele.
Nu uitați să atribuie un număr în fiecare pagină a hărții site-ului. Acest lucru este necesar în etapa de descriere a conținutului.
Sfaturi utile atunci când desen harta a site-ului:
- Nu cruța spațiul. Încercați să loc blocuri, astfel încât acestea au fost separate unul de altul. Acest lucru va ajuta la lizibilitatea hărții.
- Nu este mai mică. Citiți textul într-o dimensiune de 4, în principiu, este posibil, dar este un motiv de ură.
- Aliniați „pătrate“ de pagini în raport cu celălalt, bazându-se pe linia. Acest lucru va îmbunătăți percepția nivelurilor de pagini imbricate.
- Nu trece linia. Încercați să evitați un număr mare de intersecții de linii. În cazul în care se intersectează, ei trebuie să „sară“, unul deasupra celuilalt. Cine a fost angajat prin tragere la circuite funcționale în universitate, am înțeles.
- Conectați-vă cardul. Conectați-vă cardul în sine precum și blocuri individuale. Acest lucru va permite mai puțină confuzie în viitor.
- De multe ori pentru a salva fișierul. Trite, dar trebuie doar să ne amintim că. Nu este necesar, din nou, să-și amintească rudele Visio dezvoltatorii de software, de fapt, ele sunt în nici un fel de vină.
Harta site-ului am pus, de obicei, în secțiunea „Aplicații“. Ca o regulă, este pe atât de mult de mare încât a pus în mijlocul TOR devine reală.
aspecte
Pe harta site-ului de la fiecare pagină este pentru noi doar o „pătrat“ pe o foaie de hârtie. Pentru proiectant, coder și programator nu este suficient pentru a dezvolta un site web. Noi încă mai trebuie să cunoaștem prezența și localizarea blocurilor de informații și funcțiile de pe site. Prin urmare, vom trece la șablonul site-ului. În mod ideal, fiecare cutie trebuie să fie circuit detaliat al fiecărei pagini individuale. Acest site prototipuri. Utilizarea de prototipuri depinde de schemele adoptate de muncă în compania-dezvoltator, dar este recunoscut faptul că ea devine extrem de costisitoare pentru client.
Pentru a simplifica aloca un anumit număr de interfață șablon de site, care sunt descrise mai jos harta site-ului.
Descrierea șablon este format din 3 părți:
- Lista de șabloane. Identifică principalele tipuri de pagini și descrie utilizarea acestora.
- model standard. blocuri principale. Descrie blocurile de construcție de bază de pagini, în scopul de a reduce frecvența de apariție informații.
- Descrierea fiecărui șablon, conform listei. Tiparele sunt desenate într-un pachet grafic (Adobe Illustrator, Adobe InDesign, MS Visio și colab.), Și apoi completat de o scurtă descriere.
Disclaimer. Site-ul template-uri de interfață nu trebuie confundat cu șabloanele din sistemul de software, care va opera un site web. Șabloane de interfață descrie numărul de pagini standard, suficient pentru a proiecta site-ul.
EXEMPLU inversare TK Descrierea interfeței șablon (vayrfreyma).
Descrierea conținutului
Cea mai mare parte lungă și obositoare de locuri de muncă. Descrierea conținutului ar trebui să includă o listă a tuturor paginilor cu indicarea exactă a fi plasate pe fiecare pagină de text, imagini, etc. De asemenea, se indică ce șablon este utilizat pentru pagina (vezi. De mai sus). Vă recomandăm să utilizați pentru acest tabel.
O descriere bună a conținutului securității lucrărilor planificate pe scena a site-ului de lansare și de a introduce informații.
funcțional
Descrierea funcționalității site-ului în caietul de sarcini este una dintre secțiunile cheie. Acest lucru este valabil în special pentru site-urile cu un procent mare din programul de lucru: e-commerce, servicii on-line, etc.
Un bun exemplu de descriere funcțională oferă oaspeților. Vă recomandăm să rămână în descrierea funcționalității standard elaborat în conformitate cu site-ul programului. Ar trebui să fie descris: sistemul total, funcționalitatea totală a subsistemelor și a subsistemelor module de interconectare și module împreună și, în cele din urmă, o listă a tuturor funcțiilor modulelor cu descrierea mai mult sau mai puțin detaliată a funcționării acestora. Pentru fiecare modul, trebuie să fie vopsite obiecte care sunt create sau utilizate de aplicație.
De asemenea, este posibil să se descrie structura bazei de date, algoritmi de lucru preliminare, dar pe baza propriilor termeni de referință nu au nevoie. Conform GOST astfel de detalii ar trebui să fie descrise în alte documente: proiecte conceptuale și tehnice.
Uneori, atunci când în curs de dezvoltare site-uri mari trebuie să stea pentru o lungă perioadă de timp pentru a descrie toate caracteristicile părților externe și interne ale site-ului. Unii dezvoltatori împotriva astfel de detalii. Ei cred că este necesar pentru a descrie suprafața funcțională a „clientului a fost clar.“ Prostii! Prin experiență pot spune că detaliile excesive nu este cazul. În cazul unor probleme în proiectarea managerilor de proiect de pe ambele părți devin pedant rare! Ei TK corectează în interiorul și în încercarea de a dovedi cazul lor. Prin urmare, în cazul în care funcționalitatea TOR stabilit cuvinte comune ale clienților să fie în continuare obligat să facă ceea ce vrea.
cerinţe
O secțiune separată ar trebui să fie dedicată cerințele proiectului sau proiectul pentru mediu. Cerințe care pot fi descrise în termenii de referință pe site-ul:
- Cerințe de sistem;
- cerințele de personal;
- Cerințe de fiabilitate;
- Cerințe pentru ergonomie și estetica tehnica;
- cerințele de protecție a informațiilor împotriva accesului neautorizat;
- Cerințe privind securitatea informațiilor în caz de accidente;
- la tipurile de cerințe de sprijin;
- la cerințele software;
- la cerințele privind furnizarea de informații;
- la cerințele hardware;
Acesta poate fi, de asemenea, o serie de cerințe specifice.
Toate cerințele trebuie să fie clar și să încercați să nu uite aspectul personal al dezvoltării proiectului.
Desigur, pentru proiecte mici nu este nevoie să se înregistreze toate cerințele de mai sus. De exemplu, o parte a personalului din site-ul nu face, astfel încât aceste secțiuni sunt transmise.
În procesul de management de proiect, este posibil să observați că există situații care depășesc termenii de referință. Este posibil să fi pierdut ceva, sau există o situație de urgență pe care anterior nu ar fi putut prevedea. Toate acestea vă vor ajuta să dezvolte în continuare documentul, aducând în ea noi informații care vor fi utilizate în comunicarea cu clienții și rezolvarea problemelor.
Ce urmează?
TK este făcută, semnat și a intrat în funcțiune. Ce urmează? dacă lucrarea se încheie cu el în acest moment? Nu.
Proiectul nu merge întotdeauna la fel de pre-planificate. Încercăm să îmbunătățească ceva, pentru a schimba, de multe ori schimbarea cerințele clientului. Termenii de referință este un document, mai degrabă decât tabletele. Cu cerințele în schimbare ale proiectului trebuie să fie schimbat și termenii de referință. Acest lucru se face de obicei cu o listă de modificări documente suplimentare. Desigur, acestea sunt realizate numai în cazul în cazul în care este cu adevărat necesar, în practică, este rară.
De asemenea, ar trebui să fie pregătit ca studiul aprofundat al tuturor participanților TK dezvoltare în procesul de erori vor fi găsite în proiect. Numărul de erori într-un document de mare este direct proporțională cu volumul său și invers proporțional cu timpul necesar pentru a scrie. pentru că timp întotdeauna scurt, este de așteptat ca eroarea în TOR va apărea.
Partea de jos
Am scris acest articol de peste un an în urmă. A fost nevoie de destul de mult timp și eu în acest timp nu a scrie un singur TK mare. Dar, după citirea informațiilor, am fost de acord cu tot ce este scris aici. site-ul TK Deci, bun ar trebui să conțină:
Sper că informațiile vor fi utile unui public mai larg.