Motivatia

1
Motivatia Punctele de baza

• Problema mea Cerintele
• Client si Utilizator
• Cum reusim?
• Echipa mea- Comunicarea
• Distributia echipei
• Cum lucram împreuna?
• Punctul de plecare - decizii
• Ce este deja facut? - refolosire
• Cu ce încep? unelte

2
Evolutia dezvoltarii software-ului

• Problema dezvoltarii de software
• Continua si constanta crestere în volum si
  complexitate
• Primele abordari de Software Engineering
• Erau o replica a hardware-ului sau a altor
  discipline ingineresti
• Cheia pentru un software bun

3
(No Transcript)
4
Lantul crearii de valoare
5

• Un sistem informatic consta din oameni si masini
  care produc si/sau folosesc informatii care sunt
  unite prin sisteme de comunicatii
• Un sistem informatic este integrat daca
• Procesele de afaceri si procesele informatice
  care le sustin sunt corelate în profunzime
• Legatura între diferitele programe este în mare
  masura automatizata si
• Datele sunt achizitionate din timp si sunt
  stocate împreuna pentru toate programele, fiind
  gestionate centralizat.
• Un sistem informatic reda atât procesele
  productive, interne cât si schimburile din
  interiorul firmei si dintre firma si mediul
  înconjurator

6
Structura sistemelor informatice integrate
7
Sisteme IT orientate pe functiuni/procese
8

• Software standard
• Avantaje
• Costuri mai mici
• Asistenta mai buna
• Stabilitate
• Risc investitional redus
• Dezavantaje
• Partial, functionalitati inutile
• Dependenta de furnizor

• Software individual
• Avantaje
• Sustinere mai buna a proceselor de afaceri
• Extinderea sistemului se poate adapta
• Dezavantaje
• Costuri mai mari
• Dependenta de know-how individual
• Risc investitional crescut

9
Rezolvarea problemei

• Ce fel de cerinte am?
• scrise? verbale? complete?
• Cum pot aduna cerintele si cum le pot verifica?
• Cum obtin feedback pentru efortul meu?
• Cum îl mentin?
• Cum reduc complexitatea integrarii?
• Cum si când imi testez produsul?
• Când consider ca este complet?

10
Reutilizare si Unelte

• Ce este disponibil?
• Comercial si Open Source
• Ce pot folosi?
• Buget, Complexitate, Familiaritate, Bariere
  legale
• Ce trebuie sa 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 nereusite
• 30 - 40 din proiectele de sistem esueaza înainte
  de finalizare 1
• Jumatate din proiecte îsi depasesc bugetul sau
  termenul cu 200 sau mai mult 1
• Proiectele esuate sunt în valoare de mai mult de
  100 miliarde US/an, doar in SUA 2
• 67 din proiectele CRM esueaza 3

1 B.P. Lientz and K.P. Rea, Breakthrough
Technology Project Management 2 Computerworld 3
The Economist
12
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
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

15
Dezvoltarea de software

• Faza de planificare
• Faza de definire
• Perspectiva functionala
• Perspectiva orientata obiect
• Perspectiva orientata pe date
• Perspectiva algoritmica si bazata pe reguli
• Perspectiva bazata pe reguli
• Perspectiva bazata pe stare
• Perspectiva structurala
• Ergonomia software nivelul locului de munca

16
Dezvoltarea de software

• Faza de proiectare
• Factori de influenta
• Decizii fundamentale
• Baze de date
• Dezvoltarea orientata pe obiecte si pe
  archetipuri
• Componente software
• Aplicatii distribuite
• Arhitecturi Web
• Dezvoltarea structurata si modulara
• Faza de implementare
• Faza de punere în functiune, service si
  mentenanta

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 cerintelor
• Proiectarea
• Implementarea de software
• Integrarea si testarea sistemului

19
Modelul Waterfall

• Se bazeaza pe un model clasic, ingineresc
• Aplicabil la constructia de hardware, poduri,
  cladiri, masini
• Dezavantaje pentru software
• Necesita specificatii complete
• Cerintele noi sunt penalizate
• Integration si testare târzie
• Duce la solutii de ultim moment
• Planuri, termene si estimari nerealiste
• Nu au la baza date reale

20
Waterfall teoretic previne schimbarea si
defectele
1. Previne refacerea (datorata schimbarilor si
defectelor) prindefinirea detaliilor de la
început
2. Sistemul se construieste pe baza unor
specificatii perfecte
3. Testarea dureaza putin deoarece nu au
intervenit schimbari
Cerinte Analiza Proiec-tare Implementare Test
4. Teoretic nu este testare ci validare
21
În practica, Waterfall genereaza multa munca de
refacere
1. Incercam sa prevenim refacerea
2. Facem greseli învatam pe parcursul
proiectului
3. Refacerile intervin an momente nefavorabile
6. In practica, refacere, nu testare
4. Durata testarii este imprevizibila (50
din total)
Cerinte Analiza Proiectare Implementare Test
5. Deseori nu ajungen la rezultatul dorit
22
De ce este folosit în continuare?

• Da impresia ca putem gestiona timpul si bugetul
  mai bine
• CMMI si PMI par, la prima impresie, ca se bazeaza
  pe metodele Waterfall
• dar
• Metodele iterative sunt la fel de vechi ca
  Waterfall (de ex, Smalltalk si 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

1. Product Backlog - reposititory for requirements -
   typically high level requirements with high level
   estimates provided by the product stakeholders.
2. Release Backlog - pulled from the product backlog
   and prioritized for an upcoming release.
3. 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.

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 gt 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
Nivelul de modelare '50 '60 '70 '80 '90 '2000 '2010
Nivelul de modelare ARIS UML DSL Aplicatii compozite Modelare abstracta
Nivelul de modelare WF-Reference Model BPMN Aplicatii compozite Workflow
Nivelul de modelare BPEL4WS Servicii Web Aplicatii compozite Orientare pe servicii
Nivelul de modelare COM/DCOM J2EE Aplicatii compozite Orientare pe componente
Nivelul de modelare Simula smallTalk C CORBA Java Aplicatii compozite Orientare pe obiect
Nivelul de modelare Fortran Algol Fortran Algol Pascal C Aplicatii compozite Procedural
Nivelul de modelare assembler Limbaj masina
Nivelul de modelare timp timp timp timp timp timp timp timp
56
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)?

57
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.

58
Conceptul de niveluri(layering)

• Modelul clasic, pe 3 niveluri (3-tier)
• Dezvoltari ulterioare au dus la n niveluri
• Presentation/User interface
• Application
• Domain
• Infrastructure

59
Microsoft the four tiers of a composite
application
60
(No Transcript)
61

• 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

62
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

63
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

64
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

65
Arhitectura si infrastructura tehnologiilor

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

66
Framework

• Pentru proiectarea de solutii
• (design patterns design standards)
• Design principles
• Principii de proiectare gt 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

67
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

68
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.)

69
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

70
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

71
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)

72
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)

73
Requirements Engineering

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

74
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

75
Caracteristicile calitative ale sistemului

• Capabilitatea sistemului
• acoperirea functionalitatilor
• acoperirea cererilor nefunctionale
• Maturitatea sistemului
• respectarea bunelor practici din domeniu

76
Caracteristici tehnice, nefunctionale de sistem

• Caracteristici relevante d.p.d.v. operational
• performanta
• securitate
• disponibilitate
• siguranta in functionare

77
Caracteristici tehnice, nefunctionale de sistem

• Caracteristici relevante d.p.d.v. al dezvoltarii
• extensibilitate
• scalabilitate
• testabilitate
• integrabilitate
• controlabilitatea sistemului