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-ului sau a altor discipline inginereşti
Cheia pentru un software bun …

4. Lanţul creării de valoare

5. Un sistem informatic este integrat dacă:
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 Dezavantaje Software individual 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 şi Unelte Ce este disponibil? Ce pot folosi?
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 software Open Source?
Ce riscuri sunt legate de reutilizare?

11. Statistici privind dezvoltarea de software
In istoria proiectelor IT sunt multe nereuşite
% din proiectele de sistem eşuează înainte de finalizare 1
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 miliarde US$/an, doar in SUA 2
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. The Need Failed 28% Challenged 46% 26% Succeeded
Based on more than 23,000 IT projects
Challenged means completed over budget or past the original deadline
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. Procesul
Conform dictionarului Webster, un procesul este “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
PEOPLE
PROCESS
TECHNOLOGY

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. Waterfall – teoretic previne schimbarea şi defectele
Boehm’s Cost of change
1. Previne refacerea (datorată
schimbărilor şi defectelor) prin definirea 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
Cerinţe
Analiză
Proiec-tare
Implementare
Test
4. Teoretic nu este testare ci validare

21. În practică, Waterfall generează multă muncă de refacere
Boehm’s Cost of change
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)
Cerinţe
Analiză
Proiectare
Implementare
Test
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
Risk-driven – Greatest risk items first
Client-driven – let the client decide
Time-boxed – deliver whatever we have on a fixed date
Evolutionary – be ready to alter plans after every iteration
Incremental – deliver small chunks of functionality

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
6. Stop at any time and still use what has been built.
Promised Shipping Date
Working Software = Potentially shippable
RELEASE
prioritised
Backlog
Scrum 30 days
XP 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
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 Working software
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 customer through early and continuous delivery of 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 Extreme Programming 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 -

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.

51. Reguli si practici XP – Codare
Clientul este mereu disponibil.
Codul va respecta standardele convenite.
Se realizeaza unitati de test (mai intai).
Toate modulele se realizeaza prin pair programming.
La un moment dat, doar o echipa integreaza
Integrarea se face frecvent.
Codul realizat este al tuturor (collective code ownership).
Optimizarea se face la sfarsit.

52. Reguli si practici XP – Testare
Toate modulele de cod au unitati de test.
Inainte de livrare, orice modul trebuie sa treaca testul.
Pentru fiecare bug identificat, se creaza un test.
Testele de acceptanta se ruleaza frecvent si scorurile sunt inregistrate.

53. Aplicatii compozite (Composite Applications)
Dezvoltare de software din perspectiva inginereasca
Valorificarea tehnologiilor, instrumentelor metodelor si dispozitivelor intr-un cadru organizat => framework (tehnic si organizatoric)
Principii de baza – deschidere, interoperativitate, performanta si scalabilitate

54. CA = notiune integratoare pentru toate principiile moderne de dezvoltare de software in medii distribuite
Presupune introducerea a diferitelor niveluri e abstractizare tehnica, respectiv a modelelor, prin prisma a 3 perspective de baza:
Nivelul modelarii logice a sistemului
Nivelul modelarii functionale
Nivelul modelarii tehnice a sistemului

55. Integrarea orizontala si verticala
Integrarea orizontala: folosirea tehnologiilor sistemelor distribuite care permit schimbul de date si informatii intre diferite sisteme sau subsisteme. Ele se gasesc, cu precadere, pe nivelurile de Domeniu si Infrastructura – tehnologii open
Integrarea pe verticala: se refera la folosirea tehnologiilor pentru cresterea performantei nivelurilor de Prezentare si Aplicatie si integrarea lor cu restul tehnologiilor din toate nivelurile.
Interfete de integrare pentru transferul de date bidirectional cu sisteme externe (Legacy)

56. Round-Trip Engineering
Modificarile pe un nivel se reflecta la nivelul modelarii:
Forward engineering: rezultatele activitatii la un nivel da abstractizare mai mare sunt transmise pe niveluri de executie
Reverse engineering: regasirea informatiilor de modelare dupa efectuarea unor modificari in implementarea sistemului

57. Nivelul de modelare '50 '60 '70 '80 '90 '2000 '2010 timp
ARIS
UML
DSL
Aplicatii compozite
Modelare abstracta
WF-Reference Model
BPMN
Workflow
BPEL4WS
Servicii Web
Orientare pe servicii
COM/DCOM
J2EE
Orientare pe componente
Simula
smallTalk
C++ CORBA
Java
Orientare pe obiect
Fortran
Algol
Pascal C
Procedural
assembler
Limbaj masina
timp

58. Descrierea arhitecturii cf. IEEE 1471-2000
Intrebari definitorii:
Totalitatea modulelor tehnice, inclusiv subsisteme si sisteme partiale?
Este oricare dintre unitatile functionale minimale din care se compune sistemul, o marime de referinta?
Ce aspect (perspectiva) este prioritar(a)?

59. Perspective
Arhitectura de business – cuprinde toate specificatiile functionale ale sistemului
Arhitectura software, resp. arhitectura aplicatiei – descrie dependentele structurale si logice, respectiv structura componentelor sistemului
Arhitectura de sistem – reda echivalenta intre arhitectura software si componentele fizice ale sistemului.

60. Conceptul de niveluri (layering)
Modelul clasic, pe 3 niveluri (3-tier)
Dezvoltari ulterioare au dus la n niveluri
Presentation/User interface
Application
Domain
Infrastructure

61. Blocuri functionale ale arhitecturii software Niveluri logice
Blocuri functionale ale arhitecturii software Niveluri logice Niveluri functionale (arhitectura software) (arhitectura de sistem)
Compo-sition
Invocation
Data & Infrastructure
Presentation
Application
Domain
Infrastucture

62. Microsoft – the four tiers of a composite application

64. Logica de afaceri este realizata in combinatie de nivelurile aplicatiei si domeniului si opereaza cu:
Entitati – parcurg ciclul lor de viata specific; valorile atributelor lor gefinesc starile entitatii
Clase valori – nu au stari asociate
Servicii – se comporta ca interfete fara stare

65. Tipuri de aplicatii (design patterns)
Transaction script
Logica afacerii este impartita in proceduri individuale care au o legatura directa cu nivelul de prezentare
Aplicatii client-server
Fiecarei tranactii ii corespunde o parte din logica programului si exista o legatura directa cu baza de date in care este memorata starea entitatilor
Nu este o realizare tipica pentru CA

66. Tipuri de aplicatii (design patterns)
Table module
Entitatile extrase din logica de business (tabelele bazei de date) sunt subordonate unei singure clase, respectiv componente
Operatiile asupra acestor date se vor face separat
Adecvat pentru sisteme orientate pe obiecte

67. Tipuri de aplicatii (design patterns)
Domain model
Reprezinta dependentele complexe intre aplixatii intr-un model al datelor, propriu
Gestionarea entitatilor (structura si comportament) este realizata prin Entity services
Caz tipic pentru CA: modelul domeniului este transformat intr-un model al datelor canonic
Paradigma Domain Driven Design

68. Arhitectura si infrastructura tehnologiilor
Infrastructura cuprinde, pe langa arhiectura tehnologiilor si aspectul legat de realizarea reala, hardware
Arhitectura sistemului
partea virtuala
partea fizica

69. Framework Pentru proiectarea de solutii Design principles
(design patterns &design standards)
Design principles
Principii de proiectare => paradigme de proiectare
Design patterns
Modele de proiectare = solutii concrete pentru probleme de proiectare
Design standards
Directive de proiectare elaborate de firma de proiectare
Explicatii ale principiilor si modelelor de proiectare

70. Framework Pentru dezvoltare Implementation frameworks
Componente ale mediului de dezvoltare care pun la dispozitie unelte pentru implementare intr-un mediu integrat: Integrated Development Framework)
Eclipse, VisualStudio, editoare de cod, Source-Code, Build-Tool, Mock-Objects, Code-Analyse-Tools, Testing-Tools
Application frameworks
Platforme tehnice de executie:
Java/JEE, ,NET

71. Framework
Container
O forma speciala de Application framework care asigura ciclul de viata corect si functionalitatea obiectelor (in sensul OO)
Dezvoltatorul este degrevat de sarcini de rutina, tehnice (gestionarea memoriei, gestionarea thread-urilor, etc.)

72. Domeniu
Reuneste continuturi, concepte si idei necesare pentru descrierea unei arhitecturi speciale a unui sistem software
Criterii de descriere
Perspectivele asupra arhitecturii
Modelul folosit la descrierea sa
O descriere cuprinzatoare formeaza modelul domeniului, ca parte a arhitecturii sistemului

73. Caracteristicile modelelor de domeniu
Reutilizabilitatea
Cerintele functionale sunt utile pentru organizatii asemanatoare
Utile pentru descrierea extensiilor si modificarilor sistemului
Portabilitatea
Metamodele
Generatoare de cod, transformatoare intre diferite niveluri de abstractizare
Interoperabilitatea
Descrieri exlicite si formale ale interfetelor

74. Domain engineering
O procedura de stabilire a cerintelor domeniului, avand ca obiectiv identificarea structurilor si dependentelor intre ele
Analiza domeniului (domain analysis)
Proiectarea domeniului (domain design)
Implementarea domeniului (domain implementation)

75. Programarea generativa
Descrie proceduri prin care se realizeaza componente care pot rula automat, respectiv se realizeaza cod compilat din domeniul modelului – generatoare
Transformari orizontale (Query View Transformation)
Transforma descrierea modelului in alt model, la acelasi nivel de abstractizare (in UML – M2M)
Transformari verticale
Asigura trecerea de la un nivel de abstractizare la altul (UML in cod)

76. Requirements Engineering
Cerinte
Calitatea software-ului depinde mai putin de limitarile sale in exploatare cat de erori (nefunctionare) si de durata de intretinere

77. Cerinte functionale – descriu functionalitatea sistemului (use case)
juridic-contractuale – caluze de intretinere, drept de proprietate intelectuala, versiuni ulterioare –updatari)
tehnologice – scalabilitate, extensibilitate, etc.
de calitate – durata maxima de nefunctionare, etc.
asistarea utilizatorului – legatura dintre pagini, workflow
Modularizare – ce pachete se livreaza
Activitati - planificare

78. Caracteristicile calitative ale sistemului
Capabilitatea sistemului
acoperirea functionalitatilor
acoperirea cererilor nefunctionale
Maturitatea sistemului
respectarea bunelor practici din domeniu

79. Caracteristici tehnice, nefunctionale de sistem
Caracteristici relevante d.p.d.v. operational
performanta
securitate
disponibilitate
siguranta in functionare

80. Caracteristici tehnice, nefunctionale de sistem
Caracteristici relevante d.p.d.v. al dezvoltarii
extensibilitate
scalabilitate
testabilitate
integrabilitate
controlabilitatea sistemului