Differences
This shows you the differences between two versions of the page.
|
mps:laboratoare:laborator-11 [2017/12/12 18:39] andreea.florescu [Terminarea unui proiect (10 min)] |
mps:laboratoare:laborator-11 [2020/10/05 21:06] (current) andra.antonache [Exercitiul 3: Logo-uri (30 de minute)] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== Laborator 11 - Asigurarea calității și finalizarea unui proiect ====== | + | ====== Laborator 11 - Tehnici de prezentare ====== |
| - | ===== Software Quality Assurance (SQA) (15 min) ===== | ||
| - | * ciclu de asigurare a calității produsului software | ||
| - | * se desfășoară de-a lungul întregului ciclu de dezvoltare a produsului software, pe care **îl îndrumă, monitorizează, auditează, evaluează și coordonează** | ||
| - | * complementează procesul de dezvoltare a proiectului | ||
| - | * (în mediile enterprise) este realizat de către un grup de resurse umane dedicate asigurării calității. | ||
| - | === Domeniul QA === | ||
| - | * metodologia QA a fost introdusă inițial în cadrul fabricilor, unde și-a demonstrat aportul la succesul producției de calitate | ||
| - | * ulterior, s-a dorit adoptarea QA la mediul dezvoltator de aplicații software | ||
| - | * //Problema//: produsul software nu este palpabil, deci măsurarea funcțiilor, a beneficiilor și a costurilor sunt mai dificil de determinat | ||
| - | * //Soluția//: s-au adăugat concepte precum quality attributes (metrici software, cerinte functionale si non-functionale) pentru a putea măsura calitatea produsului software. | ||
| - | Cel mai cunoscut //model de atribute// ale produselor software de calitate este **FURPS+ model**, care cuprinde următoarele atribute: | ||
| - | - **funcționalitate** (//functionality//) | ||
| - | * cuprinde toate cerințele funcționale ale sistemului așa cum au fost stabilite în SRS | ||
| - | - **utilizabilitate** (//usability//) | ||
| - | * cuprinde cerințe legate de ușurința de folosire a interfeței sistemului de către utilizator (interfața trebuie să fie estetică, intuitivă, ergonomică, consistentă, accesibilă și celor cu disabilități) | ||
| - | - **încredere** (//reliability//) | ||
| - | * cuprinde cerințe legate de precizia răspunsurilor, de disponibilitatea și toleranța la defecte a sistemului | ||
| - | - **performanță** (//performance//) | ||
| - | * cuprinde cerințe legate de timpii de lucru, precum timp de răspuns (response time), timp de revenire (recovery time), timp de lansare (startup time) | ||
| - | - **avantaje suplimentare** (//supportability//) | ||
| - | * cuprinde cerințe legate de ușurința testării (testability), a mentenanței (maintainability), a configurării (configurability), de gradul de scalare (scalability) și compatibilitate (compatibility) și de oferire de multiple traduceri ale conținutului interfeței cu utilizatorul. | ||
| - | * "**+**" se referă la faptul că la acest model se pot adăuga și alte cerințe de calitate personalizate. \\ \\ | + | ===== Prezentare PPT (10 minute) ====== |
| - | Au apărut **standarde** dedicate produselor software, de tipurile: | + | View [[http://www.slideshare.net/daniel_2r|presentations from Daniel Rosner]] |
| - | * **standarde de managementul calității** (//Quality management//) | + | |
| - | * //ISO 9000 – 3// Quality Management and Quality Assurance Standards – Part 3: Guidelines for the application of 9001 to the development, supply, installation and maintenance of computer software | + | |
| - | * **standarde de documentare** (//Documentation Standards//) specifică formatul și conținutul documentelor de planificare și control și a documentației produsului | + | |
| - | * **standarde de planificare** (//Producing plans//): //IEEE Std1059-1993// Guide for Software Verification and Validation Plans | + | |
| - | * **standarde de Project Management** | + | |
| - | * //General project management//: //IEE Std 1058.1-1987// Standard for Software Project Management Plans | + | |
| - | * **standarde de Software Engineering** | + | |
| - | * //Software Project Lifecycle//: //ISO/IEC WD 15288// System Life Cycle Processes | + | |
| - | * //Software Project Requirements//: //IEEE Std 1233-1996// Guide for Developing System Requirements Specifications | + | |
| - | * **standarde de proiectare** (//Design Standards//) specifică reguli și metode de proiectare a soluției pornind de la specificații și formatul și conținutul documentelor de proiectare | + | |
| - | * **standarde de codare** (//Code Standards//) specifică limbajele de programare alese, convențiile de stil, reguli de construire a interfețelor și modul de comentare a surselor.\\ \\ | + | |
| + | ===== Broșură / materiale promoționale ===== | ||
| + | În timpul unei prezentări către client, //materialele de prezentare// costumizate relativ la produs și la client pot aduce un plus prezentării. | ||
| + | Acestea denotă interes și atenție față de client și pot fi folosite pentru a transmite mai bine anumite informații și pentru a atrage atenția asupra avantajelor produsului.\\ \\ | ||
| - | Ulterior, s-au definit **proceduri**: | ||
| - | * sunt succesiuni de pași ce trebuie urmați pentru a împlini un proces (ex: testare, configuration management). | ||
| - | ===Activități SQA=== | + | ===== Împachetare, deployment (5 min)===== |
| - | //Activitățile principale SQA// sunt: | + | |
| - | * asigură că standardele și procedurile de calitate alese pentru a fi urmate în proiect sunt //adecvate// la specificul proiectului (stabilirea lor este critică pentru că standardele oferă criteriile de evaluare a produsului și procedurile criteriile de comparare pentru procesele de dezvoltare și control) | + | |
| - | * asigură că standardele și procedurile alese sunt //bine documentate// pentru că activitățile de monitorizare, audit și evaluare se bazează pe ele | + | |
| - | * monitorizarea proceselor de dezvoltare și control //în raport cu procedurile de calitate// (pașii urmați coincid cu cei ai procedurilor?) | + | |
| - | * evaluarea proiectului //în raport cu standardele de calitate//. | + | |
| - | Activitățile de evaluare și monitorizare au loc în cadrul **auditurilor**. //Auditul// este //tehnica SQA de bază// folosită pentru verificarea calității produsului | + | Cum un proiect nu poate fi livrat către client sub formă de proiect NetBeans / Visual / etc, clientului îi va fi oferit, în general, proiectul sub forma unui installer. |
| - | * întocmește //rapoarte de audit// care sunt predate management-ului, ce afirmă gradul de implementare a calității și oferă //recomandări// pentru implementarea / sporirea calității în faza următoare a proiectului.\\ \\ | + | Există diferite formate / metode de generare de installere, în funcție de sistemul de operare și de platforma software. |
| - | Există **activități SQA specifice fazelor** ciclului de viață al proiectului | + | |
| - | - //faza de inițiere// | + | |
| - | * SQA intervine în redactarea și revizuirea planului de management | + | |
| - | * asigură că standardele și procedurile alese sunt potrivite, clare și pot servi ca bază de auditare | + | |
| - | - //faza cerințelor software// | + | |
| - | * SQA intervine în revizuirea specificațiilor | + | |
| - | * asigură că specificațiile sunt clar exprimate, sunt categorisite corect în cerințe funcționale și non-funcționale (de interfață, de performanță, etc.), acoperă toate cerințele utilizatorului, pot fi măsurate | + | |
| - | - //faza de proiectare// | + | |
| - | * SQA intervine în revizuirea documentelor de proiectare | + | |
| - | * asigură că toate cerințele software au fost traduse corect în componente software în raport cu standardele și procedurile de proiectare | + | |
| - | - //faza de dezvoltare// | + | |
| - | * SQA asigură că soluția este dezvoltată în concordanță cu documentul de proiectare și cu standardele și procedurile de codare | + | |
| - | - //faza de testare// | + | |
| - | * SQA asigură respectarea standardelor și a procedurilor de testare | + | |
| - | * anunță sfârșitul procedurii de testare a cerințelor funcționale | + | |
| - | - //faza de livrare// | + | |
| - | * SQA verifică și declară respectarea cerințelor non-funcționale | + | |
| - | * anunță că produsul final este gata de livrare | + | |
| - | - //faza de mentenanță// | + | |
| - | * SQA intervine pentru a asigura că subciclurile de dezvoltare respectă normele de calitate | + | |
| - | ===SQAP (Software Quality Assurance Plan)=== | + | În general, mediile vizuale de dezvoltare oferă posibilitatea de generare automată a unui installer pentru proiect, prin intermediul unui proiect de tip installer. (Exemplu: http://support.microsoft.com/kb/307353 ). |
| - | În general, scopul unei organizații este crearea unui **SQAP** care să asigure nivelul dorit de calitate a produsului.\\ \\ | + | |
| - | Din standardul [[http://ieeexplore.ieee.org/document/720573/ | IEEE 730-1998]], structura unui SQAP conține următoarele secțiuni: | + | |
| - | - Scopul documentului (Purpose) | + | |
| - | - Documente referite | + | |
| - | - Management | + | |
| - | - Documentație | + | |
| - | - Standarde, practici, convenții, metrici | + | |
| - | - Revizii și audituri | + | |
| - | - Managementul riscului | + | |
| - | - Raportarea problemelor și acțiuni de corecție | + | |
| - | - Utilitare, tehnici și metodologii | + | |
| - | - Controlul furnizorului | + | |
| - | - Training | + | |
| - | - Colectarea înregistrărilor, mentenanța | + | |
| - | Un exemplu de document SQAP puteți găsi [[http://people.cs.ksu.edu/~ganti/mse_sqa.htm|aici]]. | + | |
| - | ===== Terminarea unui proiect (10 min) ===== | + | Exemplu de aplicație dedicată: http://sourceforge.net/projects/installgen/ |
| + | |||
| - | ===Contexte de terminare=== | + | ===== Scenariu de demo (5 min) ===== |
| - | Un proiect se poate finaliza în următoarele contexte: | + | |
| - | * **s-a terminat** (cazul cel mai fericit – proiect de //succes//) | + | |
| - | * **a fost oprit** din motive (proiect //eșec//): | + | |
| - | * **de afaceri** (apar oportunități noi de business care ar genera un profit semnificativ mai mare decât proiectul actual) | + | |
| - | * **de cost** (bugetul alocat proiectului a fost epuizat și nu mai există surse de finanțare) | + | |
| - | * **de calitate** (calitatea proiectului este foarte redusă, deci investiția nu mai merită) | + | |
| - | * **tehnice** (între timp, au fost lansate soluții mai viabile decât cea a proiectului actual, tehnologiile utilizate de proiect au devenit demodate) | + | |
| - | * **de timp** (timpul alocat proiectului s-a încheiat) | + | |
| - | **Feluri de terminare** a unui proiect: | + | În cadrul unei prezentări, este foarte important pentru client să vadă rezultatul concret. Prezentările teoretice și promisiunile sunt foarte bune în stadiul incipient al proiectului, dar la finalizarea proiectului important este rezultatul. |
| - | * //Extinctie// (proiectul se termină prin succes sau eșec și, pe viitor, nu se va mai lucra la proiect) | + | |
| - | * //Terminare prin adiție// (proiectul se termină cu succes și, pe viitor, echipa care a dezvoltat proiectul se va ocupa de mentenanța produsului) | + | |
| - | * //Terminare prin integrare// (proiectul se termină cu succes și resursele sunt reintegrate în alte proiecte ale companiei – modul cel mai frecvent) | + | |
| - | ===Checklist-ul terminării proiectului=== | + | Pentru a putea demonstra clientului funcționalitatea produsului, se recomandă construirea unui scenariu de demo, care trece utilizarea programului printr-o serie de pași, accentuând funcționalitățile produsului. |
| - | * cuprinde //activitățile rămase// din cadrul proiectului | + | |
| - | * cuprinde //activitățile colaterale// ce trebuie realizate pentru a încheia proiectul în conformitate cu procedurile actuale: | + | |
| - | * completarea și distribuirea rapoartelor de performanță | + | |
| - | * completarea și distribuirea documentației sistemului | + | |
| - | * completarea auditurilor de calitate | + | |
| - | * completarea auditurilor de vânzare | + | |
| - | * revizia sistemului împreună cu help desk | + | |
| - | * întâlnirea cu staff-ul operațional care urmează să preia software-ul (în vederea mentenanței) | + | |
| - | * împlinirea cerințelor de training ale staff-ului operațional | + | |
| - | * primirea sign-off-ului de la staff-ul operațional | + | |
| - | * oferirea detaliilor despre performanța membrilor proiectului (evaluarea echipei și evaluările individuale ale membrilor și a PM-ului) | + | |
| - | * primirea sign-off-ului de acceptare de la client și acceptarea formală a tuturor livrabilelor proiectului. | + | |
| - | În cazul în care se folosește un sistem de bug/issue tracking, trebuie ca //toate issue-urile să fie rezolvate// înainte de finalizarea proiectului chiar dacă ele nu au fost incluse în specificații. | + | De asemenea, un scenariu de demo poate fi folositor și ca help guide. Există aplicații specializate în care pot fi realizate filme de prezentare pas cu pas a modului de funcționare a unui produs software și a modului de utilizare. |
| - | În cazul în care nu se poate acest lucru, cei care predau proiectul trebuie să se asigure că problemele rămase deschise sunt de prioritate scăzută și nu au un impact major asupra funcționalității. | + | O astfel de aplicație este http://www.adobe.com/products/captivate/ |
| - | ===Procesul de terminare=== | + | Aplicații open source: |
| - | * se decide terminarea proiectului | + | * http://camstudio.org/ |
| - | * se obțin aprobările necesare (de la clienți, sponsori) | + | * http://recordmydesktop.sourceforge.net/about.php |
| - | * se comunică decizia părților interesate | + | * http://xvidcap.sourceforge.net/ |
| - | * se realizează activitățile rămase din proiect și cele colaterale | + | |
| - | * se face post-performance analysis | + | |
| - | * se publică raportul final | + | |
| - | * se sărbătorește terminarea proiectului | + | |
| - | * se reasignează resursele (persoane și echipamente) | + | |
| - | * se efectuează închiderea financiară și administrativă | + | |
| - | == Post-Performance Analysis (PPA) (10 min)== | + | Un exemplu de help file realizat folosind captivate (dummy-proof) : http://elf.cs.pub.ro/~mps/labs/lab-12/navigation.html |
| - | Încheierea unui proiect nu presupune numai livrarea produsului, ci și **oportunitatea de a învăța** din această experiență pentru îmbunătățirea contribuțiilor la proiectele viitoare.\\ \\ | + | |
| - | **Recomandări**: | + | |
| - | * analiza finală a proiectului să se bazeze pe //metrici// (așa se pot cuantifica acurat rezultatele); | + | |
| - | * exemplu de metrici: | + | |
| - | - **calitatea produsului**: | + | |
| - | - //Defects per KLOC// (Kilo Line Of Code): numărul de buguri per KLOC, unde **KLOC** este unitatea de măsură pentru codul produsului | + | |
| - | - //MTTC// (Mean Time To Change): cât timp este necesar pentru a localiza eroarea, a proiecta repararea, a o implementa si testa | + | |
| - | - //threat probability//: probabilitatea atacurilor ce exploatează vulnerabilitățile produsului pe o perioadă de timp | + | |
| - | - //security probability//: probabilitatea eliminării vulnerabilităților pe o perioadă de timp | + | |
| - | - **calitatea activităților QA**: | + | |
| - | - //Test Coverage//: numărul de unități testate (KLOC/FP) / dimensiunea sistemului, unde **FP** (function point) este unitate de măsură pentru codul produsului din perspectiva funcționalității de business oferite | + | |
| - | - //Number of tests per unit size//: numărul de teste per KLOC/FP | + | |
| - | - //Cost to locate defect//: costul de testare / numărul de defecte detectate | + | |
| - | - **//Quality of Testing//**: E / ( E + D ), unde E este numărul de erori identificate înainte de livrarea produsului, D numărul de erori identificate după livrare | + | |
| - | - //System complaints//: numărul de plângeri din partea clienților / numărul de plângeri rezolvate | + | |
| - | - //Test Planning Productivity//: numărul de teste proiectate / efortul pentru proiectarea și documentarea testelor | + | |
| - | - //Test Execution Productivity//: numărul de cicluri de testare executate / efortul de testare | + | |
| - | - //Test efficiency//: numărul de teste solicitate / numărul erorilor sistemului | + | |
| - | * să se determine //cauzele// ce au condus la valorile finale ale metricilor | + | ===== Ofertă de preț (5 min) ===== |
| - | * să se rețină și să se înțeleagă aceste cauze, să se determine ce //posibilități// ar fi existat/ar exista pentru a evita producerea acestor cauze, ce posibilități sunt de stimulare a producerii a acestor cauze | + | |
| - | * să se colecteze //valorile reutilizabile// care au fost produse în cadrul proiectului (proceduri, checklisturi, guidelines) și să se facă publice | + | |
| - | **PPA**: | + | În cele mai multe cazuri, scopul final al unui proiect este unul comercial. Astfel, proiectul trebuie să fie oferit la vânzare contra unui cost, care trebuie să: |
| - | * este //analiza situației finale// a proiectului în vederea concluzionării asupra factorilor de succes și a modalităților de stimulare a lor, precum și asupra factorilor de insucces și a modalităților de prevenire, rezolvare a efectelor lor | + | * acopere costurile de realizare, care pot include: |
| - | * este //analiza ce stimulează procesul de învățare// din experiența proiectului | + | * cheltuieli cu personalul |
| - | * este recomandat să se realizeze periodic (imediat după milestone-uri) pentru a putea folosi concluziile analizei chiar in faza următoare | + | * cheltuieli cu aparatura |
| + | * cheltuieli administrative | ||
| + | * licențe | ||
| + | * acopere costurile de întreținere, upgrade, bug fix-ing pe o perioada de timp pentru care o să fie oferit suport către client | ||
| + | * evident, trebuie să existe și un profit în final | ||
| - | **Procesul PPA** are următorii pași: | + | Există mai multe modele de vânzare, care depind și de natura proiectului: |
| - | - invitarea echipei la analiză (propunând ca fiecare membru să reflecteze asupra factorilor de succes/insucces și să vină cu propuneri de îmbunătățire – se trimite un chestionar de analiză) | + | * dacă proiectul este realizat la comandă, cel mai probabil va fi vândut unui singur client și din banii obținuți de la acesta trebuie acoperite toate cheltuielile |
| - | - colectarea individuală a feedback-ului fiecărei persoane implicate în proiect (individual pentru a înțelege întreaga panoramă a proiectului) | + | * contractul de vânzare poate include clauze de asigurare a mentenanței, training, bug-fixing, upgrading. Banii pentru aceste activități pot fi incluși, fie în suma inițială, fie într-o sumă periodică stabilită prin contract. |
| - | - realizarea unei întâlniri a echipei în vederea concluzionării asupra: ce și cum s-a întâmplat, în ce moduri ar fi putut fi prevenite/soluționate problemele? | + | * dacă proiectul este unul general, care va fi vândut mai multor clienți: |
| - | - publicarea și arhivarea sumarului PPA. | + | * se poate alege varianta cea mai des folosită - clientul cumpără inițial o licență, și primește softul, un anumit grad de suport bine definit, acces la bug-fixuri și upgrade-uri. |
| - | În general, se folosește **un chestionar** pentru colectarea informațiilor. De obicei, acesta are conținut diferit între team leaderi și team memberi.\\ \\ | + | * în ultimul timp, a devenit din ce în ce mai populară varianta în care compania vinde servicii reprezentate de anumite acțiuni posibile folosind soft-ul dezvoltat (**Software as a Service**). O astfel de abordare se pretează foarte bine serviciilor online. |
| - | Câteva întrebări de chestionar sunt cele de mai jos: | + | * o altă variantă este cea în care compania distribuie soft-ul gratuit, iar clientul plătește servicii de suport. Serviciile de suport pot reprezenta servicii de modificare a aplicației pentru nevoile clientului, pregătirea unui installer pentru mediul clientului, suport pentru instalare și pentru folosirea produsului, și alte variante în care clientul deși poate folosi soft-ul gratuit, trebuie să plătească. |
| - | - Identificați lucrurile care au mers bine în cadrul acestui proiect. | + | |
| - | - Identificați lucrurile care au mers prost în cadrul acestui proiect. | + | |
| - | - Ce evenimente neprevăzute au afectat pozitiv sau negativ desfășurarea proiectului? | + | |
| - | - În cadrul acestui proiect, ce lucruri ați face diferit dacă ar fi repornit? | + | |
| - | - Descrie un lucru pe care tu l-ai fi putut realiza personal pentru a îmbunătăți calitatea produsului obținut din cadrul acestui proiect. | + | |
| - | - Ai fost informat despre ceea ce se așteaptă de la tine în cadrul acestui proiect? | + | |
| - | - Au fost rolurile membrilor echipei definite clar? | + | |
| - | - Echipa a făcut tot ce se putea face pentru a duce la bun sfârșit acest proiect? | + | |
| - | - Cum s-a comportat echipa în ansamblul său? | + | |
| - | - Care a fost componenta cea mai satisfăcătoare din cadrul proiectului? | + | |
| - | Un exemplu complet de chestionar găsiți [[http://michaelgreer.biz/?p=161|aici]] | + | |
| - | ==Exerciții (50 min)== | + | ===== Estimare costuri (5 min) ===== |
| + | Un mod simplist de a realiza o estimare a costurilor ar fi următorul: | ||
| + | ^ Ce ^ Unitate ^ Cantitate ^Total ^ | ||
| + | | Dezvoltare | 40RON/oră*om | 500 ore*om | 20000 RON| | ||
| + | | Suport | 20RON/oră*om | 200 ore*om|4000 RON | | ||
| + | | Bug fixing | 20RON/oră*om | 200 ore*om | 4000 RON| | ||
| + | | Costuri promovare | - | - | 4000 RON| | ||
| + | | Chirie | 800RON/lună | 2 luni | 1600 RON| | ||
| + | | Costuri administrative | 800RON/lună | 2 luni | 1600 RON| | ||
| + | | Rate (amorsare) echipamente | 800RON/lună | 2 luni | 1600 RON| | ||
| + | | Rate (amorsare) licențe | 800RON/lună | 2 luni | 1600 RON| | ||
| - | - Descrieți sumar conțintul unui SQAP pentru proiectul vostru. | + | ===== Exerciții ===== |
| - | * Parcurgeți secțiunea [[https://ocw.cs.pub.ro/courses/mps/laboratoare/laborator-11#sqap-software-quality-assurance-plan|Software Quality Assurance Plan]] | + | |
| - | - Pregătiți un checklist pentru terminarea proiectului vostru. Argumentați! | + | ==== Exercitiul 1: Prezentare (20 de minute) ==== |
| - | * Parcurgeți secțiunea [[https://ocw.cs.pub.ro/courses/mps/laboratoare/laborator-11#terminarea-unui-proiect-10-min|Terminarea unui proiect]] | + | Parcurgeti una dintre aceste prezentari [1]. Ce parti bune/rele observati? Sustineti prezentarea aleasa. |
| - | - Răspundeți la întrebările de la procesul PPA pentru proiectul vostru. | + | |
| - | * Parcurgeți secțiunea [[https://ocw.cs.pub.ro/courses/mps/laboratoare/laborator-11#post-performance-analysis-ppa-10-min|Post-Performance Analysis]] | + | [1] https://drive.google.com/drive/folders/0B7WjsFvWhalPRV9VSWRmNEM2UG8?usp=sharing |
| + | |||
| + | |||
| + | ==== Exercitiul 2: Realizarea unei prezentari (40 de minute) ==== | ||
| + | Imaginați-vă că ar trebui să realizați acum o prezentare pentru unul din produsele urmatoare dezvoltate de echipa voastra: | ||
| + | # **Program pentru afișarea online a mersului trenurilor și achiziția online de bilete pentru o companie de cai ferate**. Programul va include și interfețe pentru gestionarele de la ghișeele clasice de bilete. | ||
| + | # **Sistem de home-banking** ce permite clienților să folosească servicii online cum ar fi: transfer bancar, schimb valutar, tipărirea de bilanțuri, autorizarea tranzacțiilor online. | ||
| + | # **Sistem de supraveghere a traficului dintr-o rețea** destinat corporațiilor. Sistemul va permite prin intermediul unei interfețe grafice închiderea accesului la anumite servicii (yahoo, youtube) a căror utilizare în timpul programului de lucru de către angajați nu aduce un beneficiu companiei. De asemenea, va putea afișa și rapoarte despre activitatea web a fiecărui angajat. | ||
| + | |||
| + | Scopul este ca aceasta prezentare sa convinga clientul sa achizitioneze produsul vostru. | ||
| + | Care este structura acestei prezentari? Ce elemente esentiale ar trebui sa contina? Imaginati-va ca ceilalti colegi ai vostri sunt reprezentantii companiei si prezentati-le cat mai atractiv produsul. | ||
| + | |||
| + | ==== Exercitiul 3: Logo-uri (30 de minute) ==== | ||
| + | Pe rand, studentii vor folosi https://awwapp.com/ pentru a desena un logo. In cadrul aplicatiei online se poate genera un link catre desen (asistentul poate genera linkul astfel incat oricine sa poata desena pe acelasi canvas sau fiecare persoana care deseneaza partajeaza ecranul sau trimite un link read-only). Ceilalti participanti trebuie sa ghiceaza logo-ul. Persoana care a ghicit preia rolul celui care deseneaza (daca nu a fost deja in acest rol, altfel desemneaza pe cineva care nu a desenat). | ||
| + | |||
| + | <hidden> Exercitii old/fizic | ||
| + | |||
| + | Impartiti-va in doua echipe (sau in 3, conform impartirii proiectului 2). | ||
| + | |||
| + | |||
| + | Din fiecare echipa, pe rand, se desemneaza cate un membru care se duce la tabla si deseneaza pentru echipa lui cate un logo din cele puse la dispozitie de catre asistent. Scopul este sa il recunoasca ceilalti membri (ca la mima, sau ca la jocul Activity). | ||
| + | |||
| + | </hidden> | ||
| + | |||
| + | <hidden> | ||
| + | Sunt peste 30 de logo-uri din care sa aleaga. See [1]. | ||
| + | |||
| + | |||
| + | [1] https://docs.google.com/document/d/1Cfh8CkTS0VezY7XFX84fSpxuMFyjlIOT1Ls1h_EBb8k/edit?usp=sharing | ||
| + | </hidden> | ||
| + | |||
| + | |||
| + | <hidden> In limita timpului | ||
| + | |||
| + | ==== Exercitiul 3: Motto-uri ==== | ||
| + | Analog, doar ca se va primi cate un slogan/motto. Studentii desemnati il vor scrie pe tabla. La fel, scopul este ca fiecare echipa sa ghiceasca (daca se poate) cat mai multe dintre motto-urile propuse. | ||
| + | |||
| + | Sunt peste 30 de motto-uri. See [2]. | ||
| + | |||
| + | |||
| + | [2] http://pastebin.com/0EkDi0Rk | ||
| + | |||
| + | |||
| + | Doar cand ajung la tabla asistentii vad (eventual le arata asistentul de pe latop/telefon sau ceva, sau le printeaza inainte de curs....) logo-urile sau motto-urile. | ||
| + | </hidden> | ||
