metodologii de dezvoltare a aplicatiilor...
TRANSCRIPT
M E T O D O L O G I I D E D E Z V O L T A R E A A P L I C A T I I L O R S O F T W A R E
Managementul Proiectelor
Cuprins
Introducere Fazele de realizare a unui produs software Metodologii de dezvoltare Criterii de selectare a unei metodologii Metodologia cascada Metodologia V Metodologia spirala Metodologii agile SCRUM Extreme Programming (XP)
Metodologia Rational Unified Process Concluzii
Introducere
Aplicatiile sunt livrate cu defecte
Rata de erori si defecte nu ar fi tolerata pentrusistemele hardware
ENIAC 1946
Tehnologii, teorii, practici dezvoltate > software de calitate
Introducere
Evolutia echipamentelor hardware si a tehnologiilorsoftware
Performanta hardware > 10 000 milioane ori
Performanta software > 500 ori
Multe produse software caracterizate prin: Costuri ridicate
Intarzieri in realizare
Fiabilitate scazuta
Lipsa de satisfactie a clientului
Cum a crescut productivitatea software
Introducere
Care sunt motivele pentru care aplicatiile software sunt livrate cu defecte? Software-ul mai complex decat hardware-ul
Greu de desoperit toate defectele in faza de testare
Care este solutia?
Introducere
Ciclul de viata al unui produs software (eng: Software Product Life Cycle)
Ciclul de realizare a unui produs software (eng: Software Development Life Cycle)
Ciclul de realizarea a unui produs software
Analiza cerintelor
Realizarea specificatiilor
Proiectare
Dezvoltare
Testare
Instalare
Mentenanta
Începutul unui proiect8
Un proiect poate începe: cu o idee a clientului
cu o idee a unei echipe de dezvoltare
Aceasta idee poate fi: clara, bine definita
vaga, prost definita
Pentru a continua cu succes, este nevoie de ingineria cerintelor.
Caracteristicile specificatiilor9
Spun ce trebuie facut, nu cum
Sunt clare (neambigue)
Sunt suficient de detaliate
Sunt complete
Detalii de implementare la analiză?10
NU Clientul nu este competent in detalii tehnice
Clientul nu poate fi de acord in cunostinta de cauza custipularile tehnice din specificatii.
E necesar sa restrangem multimea posibilelor solutiiletehnice?
DA Este nevoie sa integram intr-un sistem existent
Timpul de dezvoltare depinde de implementare
Intretinerea (costul) depinde de implementare
Responsabilităţile Analistului
11
sa extraga si sa clarifice cerintele clientului
sa ajute la rezolvarea diferentelor de opinie intre clienti si utilizatori.
sa sfatuiasca clientul despre ce este tehnic posibil sau imposibil
sa documenteze cerintele
sa negocieze si sa obtina o intelegere cu clientul.
Activităţile Analistului12
Ascultare: Inregistreaza cerinteleclientului.
Reflectare: Traduce cerintele in limbajtehnic. Verifica pertinenta.
Scriere: Se cade de acord asupraformularilor.
Repeta pana cand se ajunge la o intelegere cu clientul in ceea ce privestecerintele.
Probleme Potenţiale13
Procesul iterativ poate fi lung sicomplicat
Negocieri
Diferenta culturala dintre client sianalist
Diferente intre cerintele clientului si ale utilizatorilor
Filmele SF vazute de client
Filmele SF vazute de programatori
Rezultatul Analizei14
Document de specificatii
Acest document este folosit ca referinta
Provocari Nivelul de detaliu
Mare: mai precis, obtinut mai greu, munca inutila
Mic: prea vag, nu poate ghida eficient dezvoltarea
Audienta documentelor
2 versiuni: una pentru client, alta pentru dezvolatori?
Notatia folosita
Informala, semiformala, formala
Tipuri de specificatii15
Specificatii functionale Ce trebuie sa faca sistemul
Specificatii non-functionale Specificatii privind datele
Formatul datelor la intrare/iesire
Formatul datelor din interiorul sistemului
Constrangeri
tehnologice
performanta
Recomandari Ajuta la luarea deciziilor de proiectare cand sunt mai multe
optiuni
Exemple
16
Specificatii functionale
Sistemul se va opri in maxim 5 secunde dupa ce temperaturaprocesorului atinge 80 grade Celsius.
Sistemul va permite cautarea si afisarea titlurilor cartilorscrise de un anumit autor.
Specificatii privind datele
Datele vor fi exportate in format XML
Datele din tampoanele de intrare si iesire vor fi criptate
Constrangeri
Implementarea se va realiza folosind un limbaj orientat obiect.
Metodologia de dezvoltare va fi Prototipizare
Recomandari
Se va folosi cat mai putina memorie
Proiectare
Siguranta, flexibilitate si fiabilitate Selectarea tehnologiilor utilizate Impuse de client Restrictrii date de software (ex. OS sau hardware) Criterii de performanta
Descompounerea problemei in subprobleme Implementarea modulara Functiile fiecarui modul Relatiile dintre module
Utilizare limbaj UML pentru descriere Daca utilizam OOP trebui sa aplicam sabloane de proiectare
(design patterns) Nivelul de detaliu ?
Implementare (Realizare)
Implementarea efectiva a codului
Testarea este parte integranta a procesului de implementare Fiecare funcite, clasa sunt testate
Principiu de urmat: scrie mai intai testele si apoi functiile siclasele (Junit)
Documentarea codului (javadocs)
Pot aparea modificari ca urmare a unor problemeneprevazute
Pot aparea cerinte noi
Testare
Teste de functionare
Teste de performanta
Teste de acceptanta
Testare automata
Testare manuala
Echipa de testare conlucreaza cu echipa de programatori
Instalare
Incepe dupa ce programul a trecut testele
Acest proces este simplu sau complicat in functie de tipul aplicatiei. Ex: aplicatie desktop, aplicatie de tip servicii web, etc.
Mentenanta
Instruirea utilizatorilor
Suport
Rezolvarea probleme care apar
Adaugare de noi functionalitati
Echipa ce realizeaza mentenanta != echipa de implementare
Metodologii de dezvoltare a produselor software
• Metodologii de dezvoltare software = este o subdisciplina in cadrul ingineriei software care se ocupa cu definirea, structurarea si controlulprocesului de dezvoltare a aplicatiilor software.
• Cum efectuam activităţile indicate de SDLC• Exemple de metodologii:
– Build and Fix– Metodologia cascadă (cu feedback)– Metodologia V– Modelul în spirală– RUP (Rational Unied Process)– XP (Extreme Programming)
Clasificare metodologii
Dezvoltarea incrementala
Dezvoltarea iterativa Incurajeaza comunicarea cu clientul
Sistemul evolueaza prin adaugarea de nou functionalitati in fiecare iteratie
In primele iteratii se poate pune accentul pe functionalitatilecritice
Criterii pentru selectarea unei metodologii
Buget Joaca un rol cheie
Dimensiunea echipei Metodologii agile = echipe mici
Tehnologiile utilizate
Unelte si tehnici
Natura proiectului
Procese existente in companie
Build and FIX
Cowboy coding
O metodologie? utilizata de multe firme. Costuri foarte ridicate pentru proiecte complexe
Produsul nu este livrat la timp
Prodosul are o calitate slaba
Nu este generata documentatie
Mentenanta este foarte dificial datorita lipse de documente de design si arhitectura
Metodologia Cascada
Metodologia Cascada
Analizacerinte
Realizarespecificatii
Proiectare
Implementare
Testare
Instalareintegrare
Metodologia Cascada (cont.)
Este o metodologie secventiala Utilizata de multe companiii mari Aplicabil pentru proiectele care sunt bine definiti de la inceput Iesirile unei faze reprezinta intrarile pentru faza urmatoare Avantaje Este un model riguros Pune accent pe documentare Este simplu, usor de inteles si de urmarit Usor de insusit de catre membrii echipei
Dezavantaje Nepractic in multe tipuri de proiecte Ce se intampla daca clientul isi modifica cerintele pe parcursul proiectului? Ce se intampla daca in faza de implementare se descompera ca o anumita
componenta este difcil de implementat asa cum a fost proiectata initial?
Pot aparea probleme noi pe parcursul dezvoltarii
Metodologia V
Metodologia V
Analizacerinte
Realizarespecificatii
Proiectarearhitectura
Implementare
Testaresistem
Teste de integrare
TestareUnitati
Proiectaredetaliata
Testare de acceptanta
Metodologia V
Extensie a modelului cascada
Parcurgerea fazelor nu este liniara
Sunt definite 3 tipuri de faze Fazele de verificare
Fazele de codare
Fazele de validare
Metodologia V
A fost dezvoltata in paralel in SUA si Germania
Este un model rigid
Testarea este activitate cheie in cadrul ciclului de dezvoltare
Evita intoarcerile
Durata de dezvoltare este lunga
Produsul apare tarziu
Partea superioara a V-ului implica utilizatorul final
Metodologia spirala
Metodologia Spirala
Modelul Spirala (cont.)
Un model adoptat in multe proiecte IT
Este un model iterativ
Potrivit pentru proiecte mari, complexe
Fiecare faza incepe cu analiza cerintelor si se incheiecu analiza de catre client a progreselor realizate in cadrul iteratiei
Armata SUA a adoptat acest model pentrudezvoltarea sistemului Future Combat System (FCS)
Modelul Spirala (cont.)
Modelul Spirala (cont.)
Cerintele pentru sistem sunt descrise in detaliu
Este realizata o arhitectura preliminara a sistemului
Este construit un prim prototip pe baza arhitecturiipreliminare – in mod uzual un model la scara al produsului final
Un nou prototip este realizat urmand procedurile: Este evaluat primul prototip in termeni de calitati, defecte si
riscuri
Sunt definite ceinrtele pentru noul prototip
Este planificat si construita arhitectura pentru noul prototip
Este construit si testat al doilea prototip
Metodologii agile
Dezavantajele metodelor clasice de management a proiectelor
Forțe uriaşe în timpul etapei de planificare;
Resurse enorme pentru modificarea cerinţele tehnice într-un mediu ce se schimbă rapid;
Tratarea personalului ca factor de producţie;
Rezultatul metodelor clasice
Haos datorită schimbării cerinţelor - cerinţele unui proiect pot să se schimbe în faza de design, implementare şi chiar lansare. În mai toate metodologiile de dezvoltare, analiza este făcută în partea de început a proiectului, şi nici o schimbare nu mai este permisă pînă spre final.
Estimări nerealiste de timp, cost şi calitate a proiectelor - managerul de proiect şi dezvoltatorii tind să subestimeze cît timp şi resurse sunt necesare pentru un proiect, şi cîte funcţionalităţi pot fi livrate. Acestea nu pot fi niciodată prevazute 100% în faza de început a ciclului de dezvoltare.
Soluţia?
Agile Software Development
Este un grup de metodologii de dezvoltare a aplicatiilor software
Au la baza principiile iterative
Minimizarea riscuri prin prin dezvoltarea in perioade scurte (iteratii)
Durata unei iteratii de la 1 la 4 saptamani
Fiecare iteratie cuprinde toate sarcinile
Fiecare iteratie poate fi privita ca un miniproiect
Rezultatul fiecarei iteratii este o noua versiune a produsului
Se pune accent pe comunicarea in timp real
Colaborare intre programatori si client
In general sunt echipe mici de dezvoltare
Caracteristicile Agile
Este iterativ: o iteraţie are între 1-4 saptămîni,în rezultat sunt livrate anumite funcţionalităţi ale proiectului.
Este bazat pe timp:durata iteraţiei e fixă şi nu poate fi modificată pe parcursul proiectului. În acest fel există întotdeauna un rezultat productiv la finalul iteraţiei.
Deschis către client:la finalul fiecărei iteraţii există un rezultat care poate fi prezentat clientului.
Bazat pe livrarea de versiuni intermediare ale produsului: fiecare iteraţie va implementa complet toate “task-urile” cuprinse în acea iteraţie
Metodologii agile
XP
SCRUM
DSDM,
Crystal,
Feature Driven
Lean Development
etc.
Toate folosesc principii de baza ale filozofiei Agile, dar o implementează în moduri diferite.
Metodologiile agile
Prioritatea este satisfacerea nevoilor clientului prin livrarea în timp a soft-ului;
Cererile de schimbare sunt binevenite, chiar şi în stadiile avansate ale dezvoltării;
Livrăm frecvent soft funcţional, cu o frecvenţăsăptămînală spre lunară, cu preferinţă pentru termene mai scurte;
Principiul Agile:YAGNI
"You Aren't Going To Need It... unless the businesssays so!".
Prin acest principiu suntem încurajaţi să
implementăm doar acele elemente pe care le
solicită clientul şi nimic mai mult!
Metodologia Scrum
Principiul metodologiei SCRUM
• dezvoltarea incrementală a aplicaţiei software;
• livrări frecvente - de regulă au loc o dată la 4 săptămâni;
• clientul primeşte de fiecare dată o aplicaţie ce conţine un număr tot mai
mare de funcţionalităţi şi care se află în perfectă stare de funcţionare.
Metodologia SCRUM
Reguli în Scrum
Această metodă necesită patru tipuri de şedinţe : Şedinţele zilnice: echipa se reuneşte în fiecare zi şi petrece circa 15 minute, în
picioare, pentru a răspunde la următoarele trei întrebări: ce am făcut ieri? Ce voi face azi? Cu ce obstacole mă confrunt azi?
Şedinţele de planificare: întreaga echipă se adună pentru a decide care sunt funcţionalităţile care vor alcătui următorul sprint, şi pentru a actualiza lista generală.
Şedinţele de revizuire a activităţii: în timpul acestei şedinţe, fiecare membru prezintă ceea ce a făcut pe durata sprintului. Se organizează o demonstraţie a noilor funcţionalităţi şi o prezentare a arhitecturii. Aceasta este o şedinţă informală, de două ore, la care participă toată echipa.
Şedinţele retrospective: la finalul fiecărui sprint, echipa analizează aspectele care au funcţionat bine, precum şi pe cele care au funcţionat mai puţin bine. În timpul acestei şedinţe de 15–30 de minute, se organizează un vot de încredere pentru a decide ce îmbunătăţiri trebuie implementate.
Avantaje
reducerea documentaţiei la minimul cu scopul sporirii productivităţii; evitarea „efectului de tunel", adică faptul de a obţine rezultatul abia la livrarea
finală şi de a nu întrezări nimic concret pe durata întregii faze de dezvoltare; compunerea secvenţială a conţinutului sprint-urilor permite efectuarea unei
modificări sau adăugarea unei funcţionalităţi care nu era prevăzută iniţial. Acesta este principalul aspect care face ca această metodă să fie „agilă“;
metodă participativă: fiecare membru al echipei este invitat să îşi exprime părerea şi poate contribui la toate deciziile luate în cadrul proiectului, fiind astfel mai implicat şi mai motivat;
facilitarea comunicării: lucrînd în aceeaşi sală de dezvoltare sau fiind conectată prin intermediul diferitelor mijloace de comunicare, echipa poate comunica uşor şi poate schimba informaţii despre impedimentele întâlnite în scopul eliminării cât mai rapide a acestora;
ameliorarea cooperării: comunicarea zilnică dintre client şi echipa face posibilă o colaborare mai strânsă între cele două părţi;
creşterea productivităţii: prin eliminarea anumitor „exigenţe" specifice metodelor clasice, precum documentaţia;
timpul de livrare a produsului final se reduce semnificativ.
Riscuri şi soluţii
• Dimensiunea echipei: fiind limitată la 7 -10 persoane, dimensiunea echipei se poate transforma într-un obstacol dacă se depăşeşte numărul de membri recomandat. În acest caz, organizarea de şedinţe devine imposibilă. Soluţia constă în realizarea unui „Scrum of Scrums“ -împărţirea proiectului în echipe de dimensiuni standard şi adăugarea unei instanţe superioare care să grupeze ScrumMasterii fiecărui Scrum;
• Cereri multiple: cererile pot proveni din mai multe surse în cadrul unui proiect şi pot uneori să fie dificil de gestionat datorită aspectului lor contradictoriu. Pentru a remedia această problemă, trebuie să se utilizeze în mod obligatoriu o aplicaţie de gestiune a cererilor;
• Calitatea produsului realizat: cu cât numărul echipelor este mai mare, cu atât calitatea este mai greu de controlat. Pentru aceasta, este important să existe o politică de calitate riguroasă şi un plan de calitate a proiectului. Verificarea frecventă a codului şi introducerea unor indicatori pentru măsurarea performanţei programatorilor permit reducerea la minimum a acestui risc.
Organizare Scrum
• Metodologia SCRUM implică intervenţia a trei protagonişti :• Product owner: responsabilul de produs şi coordonatorul echipei
clientului. El este cel care defineşte şi stabileşte funcţionalităţile prioritare şi alege data şi conţinutul fiecărui sprint pe baza volumelor de lucru comunicate de echipă.
• ScrumMaster: acesta facilitează buna desfăşurare a proiectului, are grijă ca fiecare membru să poată lucra la capacitate maximă eliminând impedimentele şi protejând echipa de perturbările exterioare. De asemenea, acordă o atenţie specială respectării diferitelor faze SCRUM.
• Echipa: fiind de regulă alcătuită din circa 4-10 persoane, echipa adună la un loc specialiştii necesari în cadrul unui proiect, şi anume: arhitectul, designerul, programatorul, testerul etc. Echipa se organizează singură şi rămâne neschimbată pe toată durata sprintului.
Scrum demo
DEMO
Metodologia XP
Metodologia XP
Extreme Programming(XP) XP descrie 4 principale activitai Codare – principala activitate Testare – orice modul implementat trebuie testa Ascultare(comunicare) – programatorul trebuie sa comunice cu
clientul pentru a intelege necesitatile acestuia Proiectarea – realizarea unei arhitecturi corecte a sistemului va
eficientiza sistemul si va reduce dependentele care nu sunt necesareintre diferitele module ale sistemului
Se preteaza pentru proiecte cu cerinte dinamice sau celecare nu sunt bine definite de la inceput
Trebuie sa existe un parteneriat intre client siprogramatori
Nu genereaza foarte multa documentatie
Metodologia XP (cont)
Extreme Programming
57
Extreme Programing (XP) este o model modern, uşor (lightweight), de dezvoltare, inspirat din RUP.
Dezvoltarea programelor nu înseamnă ierarhii, responsabilităţi şi termene limită, ci înseamnă colaborarea oamenilor din care este formată echipa
Membrii echipei sunt încurajaţi să-şi afirme personalitatea, să ofere şi să primească cunoaştere şi să devină programatori străluciţi
XP consideră că dezvoltarea de programe înseamnă în primul rând scrierea de programe
Idei importante in XP
58
Echipa de dezvoltare nu are o structură ierarhica. Fiecare contribuie la proiect folosind maximul din cunoştinţele sale.
Scrierea de cod este activitatea cea mai importantă.
Proiectul este în mintea tuturor programatorilor din echipa, nu în documentaţii, modele sau rapoarte.
La orice moment, un reprezentant al clientului este disponibil pentru clarificarea cerinţelor.
Codul se scrie cât mai simplu.
Se scrie cod de test întâi.
Daca apare necesitatea rescrierii sau aruncării de cod, aceasta se face fără milă.
Modificările aduse codului sunt integrate continuu (de câteva ori pe zi).
Se programează în echipă (programare în perechi). Echipele se schimbă la sfârşitul unei iteraţii (1-2 săptămâni).
Se lucrează 40 de ore pe săptămână, fără lucru suplimentar.
Metodologia RUP
Metodologia RUP
Rational Unified Process
Metoda iterativa dezvoltata de catre Rational Software
Este o colectie de procese ce descriu ciclul de dezvoltare al produselor software
Pune acent pe descriere proceselor sub forma unordiagrame – in contrast cu celelate modele
Utilizeaza UML ca limbaj de descriere
IBM ofera unelte pentru automatizarea proceselordescrise de RUP
Metodologia RUP (cont)
RUP defineste 6 principii de urmat Dezvolta software-ul in mod iterative
Gestioneaza cerintele
Utilizeaza arhitecturi bazate pe component
Modeleaza in mod visual aplicatiile
Verificia calitatea software-ului
Gestioneaza schimbarile in software
Metodologia RUP (cont)
Procesele definite de RUP Dimensiune timp, dimensiune statica
Metodologia RUP (cont)
Ciclul de dezvoltare al aplicatiei este descompus in sub-cicluri, fiecare ciclu este cumpus din faze
Fazele sunt: Initializare
Elaborare
Constructie
Tranzitie
RUP - Initializarea
Un document de viziune
Un model Use-case initial (10-20% complet)
Un plan de proiect cuprinzand fazele si iteratiile
O analiza a riscurilor
Un model de bussines daca e necesar
Unul sau mai multe prototipuri
RUP - Elaborare
Cea mai critica faza a proiectului
Cele mai importante componente ale sistemului suntdezvoltate acum
Un model use-case (80% complet)
Capturarea cerintelor suplimentare
Arhitectura generala a sistemului
Un prototip executabil
Modelul de bussinis si riscurile revizuite
Planul de realizare al proiectului
Un manual preliminar de utilizare (optional)
RUP - Constructie
Restul componentelor nerealizate in faza anterioaraconstuite si integrate in produs
Toate componentele sunt testate
Rezultatul trebuie sa fie un produs pregatit pentru a fi livrat utilizatorului
Este realizat manualul de utilizare
RUP - Tranzitie
Produsul este instalat\livrat utiliatorului
Utilizatorul testeaza produsul
Defectele sunt raportate si fixate
Aceasta faza poate fi foarte simpla sau foartecomplexa depinzand de tipul produsului (ex. Aplicatie desktop, aplicatie pe mai multe niveluri)
RUP - Iteratii
Fiecare faza din RUP poate fi descompusa in iteratii
Avanatajele metodelor iterative Riscurile sun gestionate mai bine
Schimbarile sunt mai usor de controlat
Calitate mai buna
RUP - Unelte
Rational Requisite®Pro--Keeps the entire development team updated and on track throughout the application development process by making requirements easy to write, communicate and change.
Rational ClearQuest™--A Windows and Web-based change-request management product that enables project teams to track and manage all change activities that occur throughout the development lifecycle.
Rational Rose 98--The world's leading visual modeling tool for business process modeling, requirements analysis, and component architecture design.
Rational SoDA--Automates the production of documentation for the entire software development process, dramatically reducing documentation time and costs.
Rational Purify®--A run-time error checking tool for application and component software developers programming in C/C++; helps detect memory errors.
Rational Visual Quantify™--An advanced performance profiling tool for application and component software developers programming in C++, Visual Basic, and Java; helps eliminate performance bottlenecks.
Rational Visual PureCoverage™ --Automatically pinpoints areas of code not exercised in testing so developers can thoroughly, efficiently and effectively test their applications.
Rational TeamTest--Creates, maintains and executes automated functional tests, allowing you to thoroughly test your code and determine if your software meets requirements and performs as expected.
Rational PerformanceStudio™--An easy-to-use, accurate and scalable tool that measures and predicts the performance of client/server and Web systems.
Rational ClearCase®--Market-leading software configuration management tool, giving project managers the power to track the evolution of every software development project.
Concluzii