Motiva ţia – Punctele de bază

1. Motivaţia – Punctele de bază • Problema mea – Cerinţele • Client şi Utilizator • Cum reuşim? • Echipa mea- Comunicarea • Distribuţia echipei • Cum lucrăm împreună? • Punctul de plecare - decizii • Ce este deja făcut? - refolosire • Cu ce încep? – unelte

2. Evoluţia dezvoltării software-ului • Problema dezvoltării de software • Continua şi constanta creştere în volum şi complexitate • Primele abordări de Software Engineering • Erau o replică a hardware-uluisau a altor discipline inginereşti • Cheia pentru un software bun …

4. Lanţul creării de valoare

5. Un sistem informatic constă din oameni şi maşini care produc şi/sau folosesc informaţii care sunt unite prin sisteme de comunicaţii • Un sistem informatic este integrat dacă: • Procesele de afaceri şi procesele informatice care le susţin sunt corelate în profunzime • Legatura între diferitele programe este în mare masură automatizatăşi • Datele sunt achizitionate din timp şi sunt stocate împreuna pentru toate programele, fiind gestionate centralizat. • Un sistem informatic redă atât procesele productive, interne cât şi schimburile din interiorul firmei şi dintre firmă şi mediul înconjurător

6. Structura sistemelor informatice integrate

7. Sisteme IT orientate pe funcţiuni/procese

8. Software standard • Avantaje • Costuri mai mici • Asistenţă mai bună • Stabilitate • Risc investiţional redus • Dezavantaje • Parţial, funcţionalităţi inutile • Dependenţa de furnizor Software individual • Avantaje • Susţinere mai bună a proceselor de afaceri • Extinderea sistemului se poate adapta • Dezavantaje • Costuri mai mari • Dependenţa de know-how individual • Risc investiţional crescut

9. Rezolvarea problemei • Ce fel de cerinţe am? • scrise? verbale? complete? • Cum pot aduna cerinţele şi cum le pot verifica? • Cum obţin feedback pentru efortul meu? • Cum îl menţin? • Cum reduc complexitatea integrării? • Cum şi când imi testez produsul? • Când consider că este complet?

10. Reutilizare şiUnelte • Ce este disponibil? • Comercial şi Open Source • Ce pot folosi? • Buget, Complexitate, Familiaritate, Bariere legale • Ce trebuie să folosesc? • Ce ajutor primesc la folosirea unor pachete? • Cum evaluez softwareOpen Source? • Ce riscuri sunt legate de reutilizare?

11. Statistici privind dezvoltarea de software • In istoria proiectelor IT sunt multe nereuşite • 30 - 40% din proiectele de sistem eşuează înainte de finalizare1 • Jumătate din proiecte îşi depăşesc bugetul sau termenul cu 200% sau mai mult 1 • Proiectele eşuate sunt în valoare de mai mult de 100 miliardeUS$/an, doar in SUA2 • 67% din proiectele CRM eşuează 3 1 B.P. Lientz and K.P. Rea, Breakthrough Technology Project Management 2 Computerworld 3 The Economist

12. Failed 28% Challenged 46% 26% Succeeded The Need • Based on more than 23,000 IT projects • Challenged means completed over budget or past the original deadline • http://www.standishgroup.com/ • Needs still growing faster than the ability to create solutions • International solutions required • Off-shoring to get better prices for labor is commonplace • Many examples of off-shoring failure • Still very difficult - failures and overruns abound

13. Procesul de dezvoltare de software • Orice software este dezvoltat in cadrul unei structuri organizatorice si modelul proceselor - process model - descrie acest cadru • Sunt descrise activitatile ce trebuie derulate si rezultatele – numite artefacte – ce trebuie realizate • Pentru fiecare activitate se definesc roluri pentru angajati, care folosesc metode, directive, conventii, liste de verificare si modele

14. PEOPLE TECHNOLOGY PROCESS Procesul Conform dictionarului Webster, un procesuleste “a system of operations introducing something ... a series of actions, changes, or functions that achieve an end or result”, procesul este deseori descris ca un picior al triadei process - people - technology si ca un liant care uneste cele trei elemente si alte aspecte, în cadrul unui sistem

15. Dezvoltarea de software • Faza de planificare • Faza de definire • Perspectiva funcţională • Perspectiva orientată obiect • Perspectiva orientată pe date • Perspectiva algoritmică şi bazată pe reguli • Perspectiva bazată pe reguli • Perspectiva bazată pe stare • Perspectiva structurală • Ergonomia software – nivelul locului de muncă

16. Dezvoltarea de software • Faza de proiectare • Factori de influenţă • Decizii fundamentale • Baze de date • Dezvoltarea orientată pe obiecte şi pe archetipuri • Componente software • Aplicaţii distribuite • Arhitecturi Web • Dezvoltarea structurată şi modulară • Faza de implementare • Faza de punere în funcţiune, service şi mentenanţă

17. Caracterizarea fazelor • Obiectivele fazei • Activitatile ce trebuie derulate • Atribuirea rolurilor pe activitati • Artefactele de realizat • Metodele, directivele, conventiilee de verificare si modelele folosite • Tehnologiile, uneltele si platformele de dezvoltare

18. Modelul Waterfall • Ce este Waterfall? DOD-STD-2167, … • Faze • Definirea cerinţelor • Proiectarea • Implementarea de software • Integrareaşi testarea sistemului

19. Modelul Waterfall • Se bazează pe un model clasic, ingineresc • Aplicabil la construcţia de hardware, poduri, clădiri, maşini… • Dezavantaje pentru software • Necesită specificaţii “complete” • Cerinţele noi sunt penalizate • Integration şi testare târzie • Duce la soluţii de ultim moment • Planuri, termene şi estimări nerealiste • Nu au la bază date reale

20. Boehm’s Cost of change Waterfall – teoretic previne schimbarea şi defectele 1. Previne refacerea (datorată schimbărilor şi defectelor) prindefinirea detaliilor de la început 2. Sistemul se construieste pe baza unor specificaţii perfecte 3. Testarea durează puţin deoarece nu au intervenit schimbări 4. Teoretic nu este testare ci validare

21. Boehm’s Cost of change În practică, Waterfall generează multă muncă de refacere 1. Incercăm să prevenim refacerea 2. Facem greşeli & învăţăm pe parcursul proiectului 3. Refacerile intervin ăn momente nefavorabile 6. In practică, refacere, nu testare 4. Durata testării este imprevizibilă(50%+ din total) 5. Deseori nu ajungen la rezultatul dorit

22. De ce este folosit în continuare? • Dă impresia că putem gestiona timpul şi bugetul mai bine • CMMI şi PMI par, la prima impresie, că se bazează pe metodele Waterfall • dar • Metodele iterative sunt la fel de vechi ca Waterfall (de ex, Smalltalk şi LISP) “For every complex problem, there is a solution that is simple, neat, and wrong.” - Mencken

23. Caracteristici ale software-ului modern • Internetul este platforma primara • Aplicatiile Web au capabilitati crescute • Este sustinuta licentierea aplicatiilor • Este minimizat suportul pentru clienti • Mediul se bazeaza pe conectarea mai multor servere • Capabilitatile in-browser cresc • Creste software-ul embedded • Phones, PDAs, alte echipamente

24. Ce se cere? • Un mod de a reduce complexitatea proiectului si de a intelege cerintele • Un mod de a dezvolta planuri bazate pe date reale legate de echipa si de performanta proiectului • Un mod de a evita integrarea riscanta si complexa, precum si testarea, la momente tarzii ale proiectului • Un mod de a se furniza functionalitate, decizia fiind a clientului

25. Dezvoltarea Agile • Un set codificat de practici recomandate • Prezinta ce ar trebui facut • Comunicarea in echipa • Commnicarea cu clientii • Mecanisme de evaluare a progresului • Mijloace de redirectare, atunci cand sunt necesare

26. Caracteristicile metodelor iterative • Mai multe proiecte mai mici in locul unui singur proiect mare - Iteratii • Impartire bazata pe intrebarea: “Care este cea mai mica functionalitate care poate fi tratata si livrata independent?” • La fiecare iteratie se testeaza si se integreaza • La fiecare iteratie se obtine aprobarea/feedbackul clientului • Aprecierea momentului in care aplicatia este finalizata!

27. Abordari iterative • Timeboxed • Risk-driven planning • Client-driven planning • Evolutionary and Adaptive Planning • Incremental Delivery

28. Sase principii ale dezvoltarii Agile 1: Customer lists known requirements (high level), then prioritises them. 2: Frequently deliver time-boxed increments - high-value Working software All features 3: The Customer can release the software at any time they want. 4: The Customer can add, delete or reprioritise features at any time. i.e. this is how we “embrace change” 5: We protect schedule commitments, despite change Promised ShippingDate 6. Stop at any time and still use what has been built. Working Software = Potentially shippable RELEASE prioritised Backlog Scrum 30 days XP 1 week time NOT MINI-WATERFALL

29. Avantajele "Timeboxing" • ‘Munca se incadreaza in timpul avut la dispozitie” – legea lui Parkinson • Oamenii isi amintesc de termenele ratate mai mult decat de caracteristici incomplete • Pasii marunti duc la complexitate redusa si productivitate crescuta • Luarea din timp a deciziilor

30. Orientare spre risc • Identificarea si reducerea tipurie a riscului • Acceptarea si tratarea schimbarilor • Gestionarea complexitatii • Succes timpuriu si repetat • Early partial product • Urmarirea relevanta a progresului

31. Orientarea spre calitate • Testarea din timp duce la defecte mai putine • Produsul final raspunde mai bine cerintelor clientului • Permanenta imbunatatire a proceselor • Comunicare si angajament

32. Dezvoltarea Agile • Mai mult o filozofie sau un concept decat o metoda specifica • In 2001 s-a constituit alianta • www.agilealliance.com • Incurajarea agilitatii (Agility) • Raspuns rapid si flexibil la schimbare • Motto: Embrace Change • Punct strategic – manevrabilitatea • Dezvoltare timeboxed, iterativa, si evolutiva

33. Agile Manifesto • Individuals and interactions • over processes and tools • Working software • over comprehensive documentation • Customer collaboration • over contract negotiation • Responding to change • over following a plan

34. Agile Principles I • Our highest priority is to satisfy the customerthrough early and continuous deliveryof valuable software. • Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

35. Agile Principles II • Business people and developers must work together daily throughout the project. • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

36. Agile Principles III • Working software is the primary measure of progress. • Agile processes promote sustainable development • The sponsors, developers, and users should be able to maintain a constant pace indefinitely. • Continuous attention to technical excellence and good design enhances agility.

37. Agile Principles IV • Simplicity--the art of maximizing the amount of work not done--is essential. • The best architectures, requirements, and designs emerge from self-organizing teams. • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

38. Stadii ale controlului proiectelor - Highsmith • Mgt de proiect -Stadiul 1: Haos • Control: minim • Mantra: "Just Do It" • Ciclu de viata: nedefinit • Mgt de proiect -Stadiul 2: Control prescriptiv • Control: conformitatea fata de plan • Mantra: Plan the Work & Work the Plan • Ciclu de viata: Waterfall & Task Based • Mgt de proiect -Stadiul 3: Control adaptiv -Agile • Control: conformitate fata de ruzultate acceptabile • Mantra: Embrace Change • Ciclu de viata: Iterative & Feature Driven

39. Metode Agile Cele mai folosite metode Agile iterative • SCRUM • Extreme programming • Feature Driven Development • Agile Unified Process • Microsoft Solutions Framework

40. Scrum • O metoda Agile pentru management de proiect • Inventata de Jeff Sutherland la Easel, in 1993 • Formalizata de Ken Schwaber in 1995

41. Caracteristicile Scrum • "Backlog" pentru activitati prioritizate; • Realizarea unui set definit de pasi din backlog intr-o serie de pasi mai mici: iteratii sau sprints; • Intalnire zilnica scrum, de descriere a progresului si a impedimentelor survenite • Sesiune sumara de planificare a spinturilor din cadrul backlog-ului • Descriere sumara a sprinturilor indeplinite.

42. Practici Scrum I • Clientul trebuie sa devina parte a echipei de dezvoltare • Livrari intermediare dese, functionale • Planuri dese de identificarea si reducerea riscului, elaborate de echipa de dezvoltare • Discutia zilnica in echipa este obligatorie (ce s-a efectuat, ce probleme au aparut, ce urmeaza sa se faca) • Transparenta este obligatorie in planificarea modulelor

43. Practici Scrum II • Daca un sprint are o problema, el nu va fi livrat • Stakeholderii sunt frecvent implicati in evaluarea progresului • Problemele nu sunt ascunse, cei ce le ridica nu sunt penalizati • Se aplica principiul: "Mai multe ore de munca nu implica obligatoriu productivitate mai mare"

44. Backlog Scrum • Product Backlog - reposititory for requirements - typically high level requirements with high level estimates provided by the product stakeholders. • Release Backlog - pulled from the product backlog and prioritized for an upcoming release. • Sprint Backlog – Targeted for the next “Sprint”

45. Scrum Lifecycle • Pre-Game • Planning - Establish vision, set expectations, secure funding • Staging - Identify enough requirements for first iteration • Development - Implement system in 30-day iterations (Sprints) • Release - Deployment

46. XP • Initiat de Kent Beck in 1999 • Bazat pe experienta cu Smalltalk • Creat cu ocazia unui proiect complex la Chrysler • Extreme Programming XP • O incercare de conciliere a umanitatii cu productivitatea • Un mecanism pentru schimbari sociale • O cale spre imbunatatire • Un mod de dezvoltare • O disciplina de dezvoltare software

47. Practici de baza pentru XP

48. XP • Story Cards • Lista de taskuri • grafice • Legatura directa cu clientii • Voluntariat • Modelare "light" • Documentatie minimala • Metrici • Spatiu de proiect comun

49. Reguli si practici XP – Planificare • User stories scrise. • Planificarea livrarilor genereaza termenele. • Livrari mici, frecvente. • Viteza proiectului este masurata. • Proiectul este impartit in iteratii. • Planificarea se reia cu fiecare iteratie. • Rotatia personalului. • Sedinta zilnica. • Replanificare in caz de necesitate. Don Wells - http://www.extremeprogramming.org/

50. Reguli si practici XP – Proiectare • Simplitate. • Folosirea metaforelor – denumiri . • Folosirea cardurilor CRC (Class, Responsibilities, si Collaboration) pentru sesiunile de proiectare. • Solutii punctuale pentru reducerea riscurilor. • Functionalitatile nu sunt adaugate prematur. • Refactoring ori de cate ori este posibil.