* se dă testul asociat

Trebuie să existe documentație pe wiki-ul asociat proiectului cu:

* împărțirea echipei și responsabilitățile fiecărui membru * împărțirea pe sarcini/activități nu se cere un format anume; recomandăm crearea unei diagrame WBS fiecare sarcină/activitate finală (frunză în arborele WBS) trebuie să aibă precizate următoarele informații * descriere (ce face acea activitate) * responsabil (persoană sau echipă) * durată + deadline (când începe, cât durează, când se termină) * dependințe cu alte activități (ce condiții trebuie îndeplinite pentru începerea, rularea sau încheierea activității - eventual în format finish-to-start, finish-to-finish etc.) * intrare (input) (ce date folosește activitatea) * ieșire (output) (ce rezultă în urma încheierii activității) * tehnologiile folosite framework-uri, limbaje de programare, biblioteci, formate de fișiere etc. pentru diferitele module ale proiectului * documentația de început a proiectului (prezentare) descrierea proiectului obiective componența echipei și responsabilitățile fiecărui membru resurse folosite (site, listă de discuție etc.) descrierea arhitecturii link-uri către celelalte elemente == Discuție == === Împărțirea pe activități == * numărul de activități (ar trebui să fie undeva la 30-50 - poate și mai multe) activități scurte și clare; o activitate de genul “implementarea core-ului” este destul de generică și ar trebui impărțită în continuare trebuie să acopere toate aspectele proiectului (testare, dezvoltare, monitorizare, management, evaluare, finalizare, prezentare, team-building ) trebuie să fie cât mai clar specificate (descriere, responsabil, timeline, dependințe, resurse, input, output) există un sistem de notificare a deadline-urilor? == Împărțirea echipei == * care este structura echipei? (câte sub-echipe care sunt responsabilitățile fiecăreia) * cine a fost ales PM și de ce? care sunt rolurile sale? trebuie să fie responsabil cu evaluare persoanelor care lucrează la proiect trebuie să se asigure că fiecare echipă/membru știe la ce să lucreze și ce are de făcut (activități specificate clar sau revizuite acolo unde este cazul) trebuie să se asigure că există un confort în structura actuală a echipei (să încerce evitarea situației de asociere a unei sarcini unei persoane care nu este potrivită) trebuie să stabilească deadline-uri realiste, să asigure fezabilitatea proiectului, să ia decizii (uneori nepopulare) atunci când este cazul trebuie să aducă un raport de evaluare a progresului în fiecare săptămână (o jumătate de pagină de evaluare a proiectului și echipei) trebuie să fie obiectiv în evaluare - cine își face treaba este “recompensat”, cine nu își face treaba este “penalizat” * cine a fost ales team leader? de ce a fost team leader? care este componența echipei asociate? de ce au fost acei membri aleși în cadrul echipei? care sunt tehnologiile care se doresc a fi folosite? de ce? care este experiența în folosirea acelor tehnologii? rolurile team leader-ului # suport # monitorizare # result-driven # responsabilizare sarcini de dezvoltare/testare # raportare către PM; negociere + decizii în discuții cu acesta * este uniformă împărțirea sarcinilor în cadrul echipei? toate echipele merg în același ritm sau unele au mai mult sau mai puțin de făcut trebuie asigurată coeziunea echipelor; PM-ul și TL trebuie să se asigure de interconectarea componentelor și proiectarea de interfețe stabilirea posibilităților de migrare * asistentul poate aduce amendamente echipei acolo unde este cazul === Documentație === * prezentarea site-ului/wiki-ului ce conține documentația inițială prezentarea echipei descrierea proiectului obiectivele proiectului arhitectura proiectului * pe site/wiki trebuie să apară componența echipei și responsabilitatea fiecărui membru * precizarea împărțirii sarcinilor/activităților (descriere, responsabil, timeline, dependințe, input, output) * există un suport de organizare intern (în general pentru PM)? (clockingit, spreadsheet, diagramă Gantt) == Documentație == === Documentație de utilizator === * depinde foarte mult de tipul proiectului, mai precis de target * scopul documentatiei este sa prezinta toate posibilitatile de utilizare pentru softare-ul respectiv, precum si modurile de utilizare * trebuie sa poata fi inteles usor de catre cel caruia i se adreseaza daca proiectul implica de exemplu un soft de contabilitate, nu trebuie sa se presupune ca persoana care citeste stie sa foloseasca o interfata daca proiectul este un IDE al unui limbaj de programare se presupune ca userul stie bazele operarii unui calculator trebuie sa contine printre altele: Visual Aids (Screenshots, filmulete de cum se foloseste etc), Tutoriale au forme variate, de la un manual la un film sau un slideshow * link pentru user manual writing http://www.asktog.com/columns/017ManualWriting.html

* Which Pong manual is better? *# A *#* Insert quarter *#* Ball will serve automatically *#* Avoid missing ball for high score *# B) *#* Joystick *# Pressing the joystick to the “UP” position causes the user paddle line to move upward. *# Pressing the joystick to the “DOWN” position causes the user paddle line to move downward. *#* Quarter slot: *# Inserting a quarter causes the game to begin. *#* Troubleshooting: *# The paddle moves in an unintended direction. — Make sure you are moving the joystick to the correct position. *# Ball stops moving or does not start moving — Ensure the proper amount of quarters has been inserted. * Sa se schiteze documentatia unui DDK + IDE Bundle (Driver Development Kit + Integrated Development Environment) si a unui Player Audio Video.Evidentiati diferentele. === Documentatia de “developer” === * mult mai consistenta si nu depinde foarte mult de tipul proiectului * tipuri de documente generate plan de arhitectura Work Schedules Documente de implementare (detalii de implementare), scrise de Dev-i Planuri de testare (la nivel de modul si la nivel de proiect) * Documentele sunt tehnice, la obiect, si adresate unui cititor familiarizat cu computer Science. Au aproape intotdeauna forma de document clasic. ==== Exemple ==== * Asa nu:(desi e cel mai des realitatea) The technical writing process: # Ask engineer how the damn thing works. # Deafing silence. # Crickets. # Tumbleweed. # Just start writing something. Anything. # Give this something to the engineer. # Watch engineer become quite upset at how badly you've missed the point of everything. # As the engineer berates you, in between insults he will also throw off nuggets of technical information. # Collect these nuggets, as they are the only reliable technical information you will receive. # Try like hell to weave together this information into something enlightening and technically accurate. # Go to step 6. * Exemplu de asa DA: http://bugs.sakaiproject.org/confluence/display/MYSAK/Widget+Development+Manual+-+How+to+write+a+widget+successfully * Exemplu de asa NU: http://www.javaworld.com/javaworld/jw-07-1999/jw-07-javacard.html?page=1 ==== Exercitiu ==== * Sa se schiteze documentatia unui DDK + IDE Bundle si a unui Player Audio Video.Evidentiati diferentele. == Fișiere de configurație == === INI == Unul din formatul cel mai răspândit pentru fisiere de configurație este cel al fișierelor tip INI. Un exemplu ar fi: john_doe_birth_yesterday_death_tomorrow_alive_maybe} ==== Avantaje ==== * simple * mici ca dimensiune * ușor de citit/parsat * folosit in special de catre Microsoft Windows, dar popular și pe alte platforme ==== Dezavantaje ==== * nu există secțiuni imbricate, lipsă de expresibilitate * nu există un standard, dar majoritatea parserelor au un subset comun de funcționalități ==== Parsere ==== * Python: ConfigParser (în biblioteca standard) * Java: IniFile (not standard) * C/C++: iniparser (not standard) * bash: exista scripturi adhoc ce parseaza astfel de fisiere (google) === XML === Alternativa la fisierele .INI sunt fișiere .xml. XML-urile sunt folosite in multe alte situatii (incluzând RPC, baze de date, etc) ==== Avantaje ==== * exista pe toate platormele si sub majoritatea sistemelor de operare * standardizat, http://www.w3.org/XML/ * ușor de citit/parsat * expresibilitate ==== Dezavantaje ==== * considerat de unii foarte încărcat * dificil de parsat de limbaje de scripting precum bash ==== Parsere ==== * Python: xml.sax, xml.dom (în biblioteca standard) * C/C++: libxml2 (not standard, dar librărie utilizată de multe aplicații) * Java: org.xml.sax, org.xml.dom (în biblioteca standard) === Exerciții === # Atașate laboratorului găsiți doua fișiere tipice de configurare clasice ('furate' de pe sistemul meu): avahi-daemon.conf și system.conf. Studiați-le. # Să se scrie un program (în orice limbaj de programare) care să parseze fișierul avahi-daemon.conf și să-l rescrie in formatul .INI în formatul .XML. == Generare documentație == Parte din munca unui programator bun este de a documenta sursele scrise. Din păcate comentariile nu sunt suficiente, ele trebuie sa fie si usor de accesat (mai ales cele care descriu interfața unei librarii). Din acest motiv au fost scrise generatoare de documentație care parseaza sursele și comentariile și produc documentație in diverse formate precum html, pdf. Mai mult, unele limbaje de programare precum Java si Python au înțeles necesitatea documentării surselor și accesul rapid la alte bucăti de cod relevante (locul de definire a funcției, descrierea tipului variabilei) și au inclus in sintaxă un mod standard de adnotare. Câteva exemple clasice de documentație generate din surse cu ajutorul utilitarelor sunt: * KDE * Linux Kernel Sources * Documentatia Java SDK * Documentatia librariilor Python === Utilitare === * C/C++: Doxygen * Java: JavaDoc * Python: pydoc === Exercițiu === # Comentați programul scris anterior la sectiunea 'Fișiere de configurație' in formatul cerut de Doxygen și generați documentația in format 'html'. Un tutorial foarte scurt de Doxygen găsiți la adresa: www.upl.cs.wisc.edu/tutorials/doxygen/ == Comparație între diverse limbaje de programare == Acest subiect este unul foarte dezbătut pe multe liste de discuții, bloguri, forumuri, etc. În continuare sunt prezentate cateva diferențe (părerea autorului). === C/C++ === C/C++ sunt poate cele mai populare/vechi limbaje de programare. Ele intră in categoria limbajelor static typed, adică tipul unui operand se determină la compilare și astfel se determina anumite garanții asupra rezultatului/validitătii operației și posibilitate efectuării unor optimizări mai speciale. C/C++ ofera viteză foarte mare de execuție de aceea ele sunt folosite in locurile unde timpul de răspuns e critic (sisteme de operare, modelare grafică, calcule numerice). Totuși, parte datorită păstrării in timp compatibilitătii cu versiuni mai vechi, cele două limbaje sunt destul de complexe și dezvoltarea aplicațiilor mari e mai dificilă decât in alte limbaje. Unul din dezavantajele majore este lipsa unui 'garbage collector', deci programatorul trebuie sa fie atent la eliberarea zonelor de memorie alocate. === Java === Java a aparut din dorința celor de la SUN de a scrie un limbaj similar cu C, dar care să fie portabil si mai putin complex. Este deasemenea un limbaj static typed. Spre deosebire de C++ Java are un garbage colector, folosește extensiv exceptiile si toate obiectele sunt alocate pe dinamic (nu există noțiunea de pointer sau pointer la pointer la array de pointeri). Java rulează in mașina virtuală (deci nu veți putea scrie un driver de rețea in java). Dezvoltarea in Java e ceva mai rapidă decat in C/C++, iar IDE-uri precum Eclipse ajută foarte mult programatorul. === Python === Python este un limbaj dynamic typed, adică tipul operanzilor și validitatea operațiilor este determinată la rulare. Paradigma este: 'duck typing': If it walks like a duck and quacks like a duck, I would call it a duck. Datorita lipsei de informatie asupra tipului operanzilor sursele in python necesită ceva mai multă testare, dar asta NU ESTE un lucru negativ. Testarea corespunzătoare și diverse utilitare precum pychecker elimină mare parte a problemelor legate de erori de scriere și tipul operanzilor. Python este util in scrierea programelor scurte, dar a fost folosit cu succes si in dezvoltarea aplicațiilor mari. Avantajul fața de celalte limbaje este dezvoltarea foarte rapidă (cam la viteza la care scrii dupa unii) și expresivitatea surselor. Dezavantajul este viteza scăzută de execuție (aproximativ de cinci ori mai mica decât a C-ului). Nu uitați când cântăriți optiunile (răspuns sugerat pentru proiectul de semestru): * portabilitate: NU * grafică: DA * viteză: NU * timp de dezvoltare: scurt * networking: DA * câti dintre voi stăpânesc limbajul * unelte/documentație disponibile == Linkuri == * http://www.artima.com/weblogs/viewpost.jsp?thread=4639 * http://en.wikipedia.org/wiki/Duck_typing * http://en.wikipedia.org/wiki/Type_system * http://en.wikipedia.org/wiki/Comparison_of_Java_and_C%2B%2B * http://www.ferg.org/projects/python_java_side-by-side.html * http://www.artima.com/intv/strongweak.html == Controlul versiunii - SVN == Ce este controlul versiunii? * gestiunea unor mai multe versiuni ale unei entități ce se modifică * exemple: wiki - pentru fiecare modificare se rețin doar schimbările de la versiunea anterioară. Orice modificare poate fi anulată. google docs - versiuni pentru fiecare modificare msword, openoffice - permit atașarea unor numere de identificare pe documentele editate. sisteme de gestiune a surselor - mențin sursele unor programe sub o formă care permite accesul la versiuni anterioare. === Funcționalități comune sistemelor de gestiune a surselor === * există unul sau mai multe repository-uri: depozite în care sunt păstrate sursele + date despre fiecare modificare înregistrată. * utilizatorii au conturi separate: * permite identificarea sursei fiecărei modificări. asupra unor resurse pot scrie doar utilizatorii autorizați. Previne modificările accidentale sau malițioase. * fiecare utilizator are o copie locală (copie de lucru) peste care lucrează. Când acesta hotărăște că a ajuns la o versiune ce merită salvată, o va scrie în repository (commit) * în general un proiect nu se dezvoltă liniar: nu doar se adaugă cod într-o singură direcție. se pot crea ramuri (branch) pe care să se dezvolte anumite funcționalități separat de partea principală a aplicației. Când codul de pe ramură ajunge la maturitate se poate decide integrarea lui în ramura principală (branch merging). se creează ramuri de mentenanță pentru fiecare versiune a unui produs care a fost lansată: deși funcționalitățile noi se adaugă în ramura principală (și în eventuale ramuri de testare), există cazuri când se lucrează și pe ramuri mai vechi pentru a repara probleme apărute în funcționarea programului după ce acesta a fost lansat.

* centralizate (ex. cvs, svn, perforce) există un repository central unde sunt trimise toate commiturile toate branch-urile sunt vizibile tuturor utilizatorilor - nu există branch-uri private în general utilizatorii primesc de la repository doar ultima versiune a fișierelor de pe ramura pe care au primit-o. Dacă repository-ul central se defectează este posibil să se piardă istoria modificărilor (rămân doar copiile locale ale utilizatorilor). nu se pot efectua commit-uri fără a avea acces la repository-ul central (acesta devine un single point of failure). Probleme de ordin tehnic (de ex. cade conexiunea la serverul central) vor împiedica utilizatorii normali să facă copii ale unei anumite ramuri, să verifice diferențe între versiunea actuală și alte versiuni anterioare sau să permanentizeze modificările sub forma unui commit. apare problema gestiunii drepturilor: * cine are dreptul să comită într-o anumită ramură * cine are dreptul să creeze ramuri noi * cine are dreptul să creeze taguri trebuie stabilită o convenție de denumire a ramurilor sau a tagurilor. * descentralizate/distribuite (ex. git, darcs, mercurial, bazaar) fiecare utilizator are propriul repository (privat). Utilizatorii pot alege să facă anumite repository-uri publice pentru a colabora cu alți utilizatori. branch-urile din repository-ul privat sunt private și vizibile doar acelui utilizator. Branch-urile de pe un repository public sunt publice. când un utilizator ia conținutul unui repository public îi copie toată istoria. Dacă repository-ul pe care l-a copiat s-ar defecta, istoria modificărilor nu s-ar pierde. utilizatorii pot copia conținutul oricârei ramuri sau commite cod în repository-ul local indiferent de stare în care se află repository-ul din care acesta a derivat. Deși nu este nevoie de un server central, unul dintre repository-uri este ales drept server oficial (de ex. într-o companie pot exista oricâte repository-uri locale, oricâte pentru oricare utilizator, dar un anumit repository este desemnat centrul; deși există multe versiuni ale kernelului Linux, una este considerată centrală: cea a lui Linus. Din aceasta vor deriva repository-urile în care lucrează distribuțiile de Linux, etc.) nu mai există problema gestiunii drepturilor pentru o parte din acțiuni: * fiecare utilizator este liber să-și facă (și șteargă) oricâte ramuri de dezvoltare private. * orice utilizator poate commite oriunde în branch-urile copiei de lucru personale; astfel utilizatorii sunt încurajați să creeze branch-uri locale și să commită cod mai des în ele (nu mai trebuie să ceară voie să creeze un branch, nu trebuie să motiveze cuiva că are o idee ce merită urmărită, etc.) * denumirile ramurilor sau a tagurilor nu mai sunt regularizate decât în repository-ul global. În repository-urile de lucru, utilizatorii pot crea branch-uri cu orice nume, fără a trebui să se consulte cu nimeni. === Numere de versiune === Fiecare modificare înregistrată în repository are un identificator unic. * în cazul sistemelor centralizate acesta este un counter incrementat cu fiecare modificare înregistrată. * în cazul sistemelor distribuite acesta este un identificator unic universal (exemple de astfel de formate de identificatoare: http://en.wikipedia.org/wiki/Universally_Unique_Identifier). Acestea sunt niște numere/șiruri de caractere calculate după niște reguli ce fac aproape imposibilă generarea a două identificatoare identice. (To put these numbers into perspective, one's annual risk of being hit by a meteorite is estimated to be one chance in 17 billion, that means the probability is about 0.00000000006 (6 × 10−11), equivalent to the odds of creating a few tens of trillions of UUIDs in a year and having one duplicate). * Pentru a identifica cea mai recentă versiune a unui repository se folosește termenul HEAD. Anumite sisteme de versiune identifică și modificările începând de la HEAD în ordine inversă cronologică. De ex. în git HEAD~1, HEAD~2, etc. identifică prima, respectiv a doua modificare dinaintea celei din HEAD. === Utilizare SVN === ==== checkout/update ==== Pentru a copia sursele unui proiect se rulează: nume-director-nou} Asta va face o copie locală neautentificată. Marea majoritatea a repository-urilor de svn nu permit acces anonim pentru scriere (eventual doar pentru citire). Pentru a face o copie autentificată rulați: nume-director-nou} La crearea copiei locale va fi solicitată și parola. Repositrory-urile pentru laboratorul și proiectul MPS sunt la adresa prj_name}, unde prj_name este unul dintre: catan, caylus, puerto_j, puerto_v, tnt_j, tnt_v. Comenzile anterioare vor copia tot arborele repository-ului central (toate branch-urile și tagurile vor fi copiate în directorul de lucru). În general nu suntem interesați decât de trunk sau un anumit branch sau tag. Pentru a nu consuma bandă și timp inutil se poate specifica în mod explicit ce subdirector din arbore dorim să copiem local: v1.0.1_nume-director-nou} Presupunând că pe server s-au făcut modificări de la momentul creării copiei locale (sau a ultimei actualizări), pentru a aduce la zi copia locală rulați: svn_update_poate_fi_prescurtata_„svn_up} Atenție: svn update va actualiza doar directorul în care ați rulat comanda (și toate subdirectoarele lui). Dacă doriți să actualizați tot proiectul comanda trebuie rulată din rădăcina acestuia. Există două metode de actualizare a unui anumit director: * svn_up} * director_de_actualizat} Dacă ați șters din greșeală un fișier sau un director dintr-o copie de lucru svn, puteți să-l recuperați rulând: * „svn up” într-un director care include fișierul sau directorul pe care vrem să-l recuperăm. Atenție: în plus această comandă va actualiza toate fișierele din directorul local. * „svn up fname” aceasta va actualiza (restaura) doar fișierul/directorul fname. ==== Structura unui repository ==== O copie locală a unui repository SVN are trei mari componente: * trunk acest director este desemnat ca ramură principală de dezvoltare * branches în acest director se creează alte subdirectoare pentru fiecare ramură adițională de dezvoltare * tags în acest director se creează subdirectoare pentru fiecare tag nou creat. Un tag reprezintă o anumită imagine a unui proiect. Tagurile sunt create atunci când dorim să păstrăm sub un nume mai ușor de ținut minte (decât numărul care identifică acea versiune) care a fost exact imaginea unui proiect la un anumit moment dat (de ex.: lansarea unei versiuni 1.0, 1.1, 1.2, 2.0, etc.)

Tagurile și branch-urile sunt create copiind directorul sursă din care acestea derivă: * creare tag: release-1.0_-m_tagging_the_1.0_release_of_the_calc_project} această comandă copie versiunea curentă a trunk-ului sub tagul “release-1.0” și pune și un comentariu care descrie mai amplu de ce s-a creat noul tag. * creare branch trunk} crearea unui nou branch se face similar cu cea a creării unui nou tag, singura diferență este directorul destinație: la tag e “tag/tag-name”, la branch e “branches/branch-name”.

Nu există nici o diferență între lucrul pe un branch sau pe trunk. SVN nu distinge în nici un fel aceste două directoare (nici tag-ul nu e considerat aparte). Dacă cineva consideră că numele acestor directoare nu sunt satisfăcătoare, poate de exemplu să construiască un arbore de tipul următor:

more_stuff}

Adăugarea de fișiere în directorul unei copii de lucru nu implică luarea lor sub gestiunea svn. Pentru a adăuga un nou fișier/director în SVN:

svn_add_fname}

Există cazuri când dorim să adăugăm toate fișierele nou create dintr-un director care este deja indexat în svn. În acest caz comanda

svn_add_dirname-deja-indexat}

se va termina cu o avertizare:

dirname-deja-indexat_is_already_under_version_control}

Pentru a forța adăugarea recursivă a fișierelor din „dirname-deja-indexat” se rulează comanda:

svn_add_dirname-deja-indexat_--force}

Pentru a șterge un fișier/director de care nu mai este nevoie:

svn_rm_fname}

Această comandă va șterge fișierul (directorul) atât de pe disc cât și din svn.

Dacă vreți să ștergeți din svn un fișier cu modificări față de versiunea din HEAD-ul svn-ului veți primi o eroare și operația nu va fi efectuată:

fisier_cu_modificari_has_local_modifications}

După cum este indicat în mesajul de erore, trimițând și parametrul „–force” se poate șterge fișierul.

Modificările aduse copiei locale (adăugări sau ștergeri de fișiere, modificarea unor fișiere deja existente) nu sunt vizibile automat la nivel global. Pentru a înregistra o anumită modificare aceasta trebuie trimisă repository-ului:

svn_commit_-m_adaugat_fisier_gigi.c_sters_fisier_mimi.c_rescris_functia_de_dispatch_din_bibi.c}

Pentru a vedea care sunt diferențele între versiunea copiei de lucru și între versiunea din care aceasta este derivată rulați: * pentru a vedea diferențele pe tot subarborele începând cu diretorul local:

svn_diff}

* pentru a vedea diferențele doar pentru un anumit fișier/director (diferențele pentru un director sunt diferențele pentru toate fișierele din acel director și din subdirectoarele sale)

svn_diff_fname}

Asupra unui fișier pot lucra mai mulți utilizatori în același timp. Dacă un fișier a fost modificat și s-a trimis un commit serverului toate copiile din dosarele de lucru ale utilizatorilor. Dacă pe același fișier mai lucra un utilizator, acesta va trebui să actualizeze acel fișier înainte de a commite modificările lui.

Dacă aceșția lucrează asupra unor secțiuni diferite ale fișierului nu vor exista probleme la combinarea modificărilor efectuate de cei doi:

# creați o copie locală (autentificată) repository-ului proiectului propriu # creați o ramură proprie cu numele “branches/nume_utilizator_svn” unde nume_utilizator_svn este numele vostru de utilizator

* structura repository-ului * alegerea tehnologiilor și limbajelor de programare folosite * proceduri de dezvoltare stabilirea stilului de codare (Coding Style) stabilirea stilului de comentare mod de denumire a fișierelor planuri de code review transmiterea bug-urilor (folosire sisteme de ticketing) comunicarea/colaborarea în cadrul echipei * prezentarea primelor module scrise (da, ar trebui să aveți ceva cod prezent)

* prezentarea tehnologiilor folosite * prezentarea utilitarelor folosite de dezvoltatori (dev tools) (VCS, editoare, pluginuri utile) * prezentarea directoarele specifice din repository exemplu: trunk/src, trunk/doc, trunk/config, trunk/install, branches/0.1 etc. * început de developers documentation cum se lucrează în repository care este stilul de codare documentare unde au loc discuțiile între dezvoltatori cum și cui se trimit tichetele cine este responsabil de un modul dat * link-uri utile pentru dezvoltatori === Raportare === * project manager-ul va raporta starea proiectului în faza inițială fiecare membru știe ce are de făcut starea în cadrul echipei responsabilizarea în cadrul echipei comunicarea acordul fiecărui membru pentru activitățile asociate, pentru tehnologiile și utilitarele folosite evaluarea fiecărui membru (consultare cu team-leaderi sau alte persoane) * acomodarea cu utilitarele și tehnologiile asociate * nivelul de înțelegere a proiectului * responsivitatea (participă la întâlniri, răspunde la solicitări, lucrează la activitățile proprii) * prezentarea persoanelor care manifestă implicare deosebită și a celor care nu manifestă implicare * team leader-ul va raporta starea componentei proiectului de care este responsabilă echipa sa eventuale probleme ar trebui raportate către PM și luate decizii