Managementul Proiectelor Software

Laborator 2 - Împărțirea rolurilor în echipă. Redactarea specificațiilor de proiect

De adus

  • Componența semigrupei. Se completează aici.
  • Componența echipelor de proiect. Se completează aici.
  • Un nume, identificator pentru echipă.

Rolurile în cadrul Echipei de Proiect (5 min)

Cu cât proiectul este mai mare, cu atât rolurile din echipă sunt mai diversificate (mai specializate pe o anume arie de activități).

Într-un proiect mic, principalele roluri din echipă sunt:

  1. Project Manager
    • responsabil de succesul/eșecul proiectului
    • planifică & monitorizează evoluția proiectului
    • ia decizii
    • adesea, are background tehnic (pentru a înțelege ciclul de viață al proiectului)
    • întotdeauna, are abilități soft (de conducere, de motivare și stimulare, de conștientizare a cauzelor, de decizie, de negociere, de previziune, de inovație)
    • certificări PMI (Project Management Institute): PMP (Project Management Professional)
  2. Team Leader (Lead Developer, Lead QA)
    • responsabil de execuția conform standardelor a activităților planificate
    • monitorizează activitatea echipei sale
    • intervine pentru a corecta, pentru a îndruma (coaching/support)
    • raportează managerului statusul real al proiectului
  3. Software Developer
    • responsabil de implementarea software a cerințelor
    • în metode de dezvolare agile contribuie și la design, arhitectură, specificații
  4. Tester (Quality Engineer)
    • responsabil de verificarea funcționalităților și a performanțelor produsului
    • scrie scenarii de test, le execută, analizează rezultatele ⇒ rapoarte de testare

Într-un proiect mare, pe lângă rolurile de mai sus, apar și altele, precum:

  1. System Architect
    • responsabil de arhitectura produsului software
    • captează interesele partenerilor de business și le transpune alegând arhitectura potrivită
  2. Technical Writer
    • responsabil de documentația tehnică a proiectului
    • primește documente tehnice de la ingineri, pe care le editează spre a fi corecte, clare și conforme cu standardele în vigoare
  3. Analyst (Business Analyst, Business Systems Analyst, Systems Analyst, Requirements Analyst)
    • responsabil de înțelegerea corectă a cerințelor de business
    • studiază specificațiile clienților, clarifică toate detaliile proiectului cu clientul și cu partenerii (stakeholders)
    • redactează specificațiile aplicației software
  4. Consultant
    • analizează fezabilitatea ofertelor de proiecte
    • propune soluții pentru diverse probleme legate de ciclul de viață al proiectelor
    • evaluează gradul de atingere a obiectivelor proiectelor
  5. Experți business: SME (Subject Matters Expert), Product Manager, Program Manager

Gestiunea timpului

Orice membru al echipei și project manager-ul în special trebuie să aibă skill-uri de organizare a timpului pentru a obține maximum de rezultate. Aspecte precum planificarea task-urilor, stabilirea obiectivelor, evitarea întreruperilor, prioritizarea activităților trebuie avute constant în vedere pentru eficientizarea muncii.

Career path

În general, fiecare persoană urmează un set de căi predefinite în cariera IT, fie pe latură tehnică (hard skills) fie pe latură de consultanță (soft skills). Căile în carieră au, în mod tipic, ca vârf poziții de Software/Solutions Architect sau poziții de Program Manager/VP (Vice President).

Redactarea Specificațiilor de Proiect (5 min)

După primirea specificațiilor clientului și după analiza de profunzime a acestora, contractorul redactează documentele de specificație ale soluției oferite, de obicei sub formă de:

  • Software Requirements Specification (SRS)
  • Software Design Description (SDD)

Este *esențial* pentru reușita proiectului ca aceste documente de specificații să fie complete și absolut clare deoarece:

  • acestea reprezintă parte a contractului dintre client și contractor;
  • pe baza acestora se pot determina clar cerințele proiectului, rezolvându-se astfel eventualele conflicte dintre parteneri
  • pe baza acestora se vor realiza estimările de timp și buget și planificările de proiect;
  • pe baza lor se va realiza dezvoltarea soluției și testarea funcționalităților și performanțelor ei;
  • pe baza lor se va realiza evaluarea finală a proiectului (a gradului de atingere a obiectivelor).

Documentul SRS cuprinde descrierea completă a comportamentului sistemului software, adică:

  • a interacțiunilor dintre utilizator și sistem (functional requirements). Acestea se descriu cu ajutorul use-cases (cazurilor de utilizare).
  • a constrângerilor de proiectare și dezvoltare (non-functional requirements). Acestea se referă la restricții de performanță, de securitate, de fiabilitate etc.

Conținutul unui SRS

  • Scopul documentului (Document purpose)
  • Conținutul documentului (Document overview)
  • Descrierea generală a produsului (General description of the product)
  • Situația curentă (The current situation)
    • Misiunea proiectului (Purpose of the product)
    • Contextul proiectului (Product context)
    • Beneficii (Benefit)
  • Cerințe funcționale (Functional requirements)
    • Actori (Actors)
    • Diagrama de sistem (System boundary)
    • Descrierea cazurilor de utilizare (Use cases description)
  • Cerințe nefuncționale (Non-functional requirements)
    • Cerințe de interfață (User Interface Requirements)
    • Cerințe de performanță (Performance Requirements)
    • Cerințe de fiabilitate (Availability & Reliability)
    • Cerințe de securitate (Security Requirements)

System Boundary

Se mai numește și Use-case diagram.

Este:

  • o diagramă UML obținută în urma analizei cerințelor utilizatorului
  • schema funcționalităților oferite de sistemul software, în termeni de actori, cazuri de utilizare și relații între acestea.

Relațiile dintre cazurile de utilizare pot fi de tipul:

  1. includeuse-case-1 includes use-case-2 înseamnă că rezultatul use-case-ului 1 depinde strict de rezultatul use-case-ului 2 pe care îl include.
  2. extenduse-case-1 extends use-case-2 înseamnă că use-case 1 este o alternativă la use-case 2
  3. generalizationuse-case-1 specializes use-case-2 înseamnă că use-case 1 cuprinde același comportament al sistemului ca și cazul general use-case 2, dar că mai aduce în plus câteva detalii.

Mai multe detalii, poți afla aici.

Use-case Diagram pentru Banking System

Exemplu de Document SRS

Arhitectura Proiectului (5 min)

Stabilirea arhitecturii unui sistem software implică:

  1. alegerea șabloanelor arhitecturale potrivite (se pot combina mai multe, se pot personaliza)
  2. în funcție de șabloanele arhitecturale alese, proiectarea structurii sistemului software la nivel de:
    • componente specializate pe o gamă de servicii (module și interfețe),
    • conexiuni dintre componente.

Există mai multe tipuri șabloane arhitecturale (architectural patterns), precum:

    • sistemul software e alcătuit dintr-o serie de componente software ce rulează pe mașini de calcul diferite, ce comunică prin rețea
    • mașinile de calcul interacționează pentru a oferi cât mai rapid un răspuns corect la cererea utilizatorului
  • client-server
    • arhitectură distribuită
    • conține componente furnizoare de servicii = componente server și componente ce solicită servicii = componente client
    • se bazează pe producerea, detectarea, consumarea și reacția la evenimente
    • front-end = interfață de colectare a datelor de la utilizator și de procesare a acestora pentru a fi aduse la formatul prevăzut de componenta back-end
    • back-end = componenta software de procesare a datelor furnizate de front-end
    • arhitectură de tip client-server
    • conține: presentation tier (web browser), business logic tier (middleware - application server: engine de rulare a paginilor web dinamice scrise în ASP.NET, JSP/Java, PHP, Perl, Python, Ruby), database tier (database server)
    • browserul trimite cererile către serverul de aplicație, care le servește interogând și modificând conținutul bazei de date și, de asemenea, generează pagina de răspuns care va fi trimisă înapoi browserului.

Exemplu de descriere a arhitecturii unei aplicații: Platformă de gestiune a datelor medicale electronice

Exerciții (80 min)

  • Împărțiți-vă în echipe de 3 persoane sau 4 persoane.
  • Fiecare echipă primește de la asistent o fișă cu o descriere sumară a cerințelor date de un client care dorește implementarea unei aplicații.
  • 20 minute - Realizați, pe o foaie o arhitectură (module, componente și interconectare) a aplicației. Propuneți două caracteristici/feature-uri suplimentare pentru aplicației, feature-uri pe care le considerați utile și care pot fi implementate. Arhitectura trebuie să fie înțeleasă de alții.
  • 10 minute - Transmiteți fișa cu descrierea și cu arhitectura echipei din dreapta voastră și primiți o fișă și foaie din stânga. Oferiți un feedback constructiv arhitecturii (în scris).
  • 20 minute - Discuții pe marginea arhitecturii și feedback-ului.
  • 10 minute - Primiți o foaie din stanga și dați în dreapta. Citiți cerința, arhitectura și propuneți un număr de membri ai echipei care se va ocupa de implementarea soluției.
  • 10 minute - Transmiteți foaia mai departe și oferiți feedback pe cea pe care o primiți.
  • 10 minute - Discuții pe marginea alcătuirii echipei și a feedback-ului.

Exerciții/Teste extra

Test de motivare personală (10 min)

Încearcă testul de verificare a motivării personale:

Test de gestiune a timpului (10 min)

Exercițiu diagramă de sistem (15 minute)

Să se determine actorii și să se construiască diagrama de sistem (system boundary) în Visio, Dia sau pe hârtie pentru:

  • aplicația software utilizată de secretariatul facultății, adică site-ul studenti.pub.ro
  • aplicația software utilizată de casa de bilete a Teatrului Național (site-ul casei de bilete)

Exerciții de proiectare arhitecturală

  1. (15 min) Proiectați modelul de arhitectură (alegeți/adaptați șabloanele arhitecturale) care ar fi recomandat pentru a implementa următoarele proiecte:
    1. sistemul informatic al Casei Naționale de Asigurări de Sănătate (are în evidență toți bolnavii cronici din țară, returnează spitalelor și farmaciilor din țară fondurile investite în medicamentele compensate și gratuite, supraveghează activitatea caselor județene de Asigurări de Sănătate);
    2. sistemul informatic de asistență a liniei de producție Renault (folosește o serie de senzori, aparatură de măsură și instrucțiunile personalului de comandă pentru a coordona/schimba parametrii pentru procesul de producție, pentru a genera alerte);
    3. Tech Support Forum.
  2. (15 min) Identificați componentele / modulele pe care le-ați folosi pentru a construi soluția software pentru:
    1. implementarea în rețea a jocului Monopoly;
    2. implementarea serviciilor oferite de o agenție de turism.

Interconectați aceste module prin arce conform interacțiunii modulelor în construirea soluției.

  • Puteți utiliza Visio, Dia sau puteți desena pe hârtie.

De adus pentru laboratorul următor

  • Document cu împărțirea rolurilor în cadrul echipei (organizarea echipei și rolul fiecărui membru).
  • CV-urile membrilor echipei.
laboratoare/laborator-02.txt · Last modified: 2012/10/19 10:36 by ciprian.coman