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

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 …

Lanţul creării de valoare

• 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

Structura sistemelor informatice integrate

Sisteme IT orientate pe funcţiuni/procese

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

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?

Reutilizare şi Unelte• 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 software Open Source?

• Ce riscuri sunt legate de reutilizare?

Statistici privind dezvoltarea de software

• In istoria proiectelor IT sunt multe nereuşite• 30 - 40% 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 Management2 Computerworld3 The Economist

The Need

• Based on more than 23,000 IT projects

• Challenged means completed over budget or past the original deadline

• http://www.standishgroup.com/

Challenged

Succeeded

Failed 28%28%46%46%

26%26%

• 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

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

ProcesulConform 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 triadeiprocess - people - technology

si ca un liant care uneste cele

trei elemente si alte aspecte,

în cadrul unui sistem

PEOPLE

PROCESSTECHNOLOGY

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ă

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ţă

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

Modelul Waterfall

• Ce este Waterfall? DOD-STD-2167, …– Faze

• Definirea cerinţelor• Proiectarea• Implementarea de software• Integrarea şi testarea sistemului

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

Waterfall – teoretic previne schimbarea şi defectele

Boehm’s Cost of change

Cerinţe AnalizăProiec-

tareImplementare

Test

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

În practică, Waterfall generează multă muncă de refacere

Boehm’s Cost of change

Cerinţe Analiză Proiectare Implementare Test

1. Incercăm să prevenim refacerea

2. Facem greşeli & învăţăm pe parcursul proiectului

3. Refacerile intervin ăn momente nefavorabile

4. Durata testării este imprevizibilă

(50%+ din total)

5. Deseori nu ajungen la rezultatul dorit

6. In practică, refacere, nu

testare

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

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

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

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

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!

Abordari iterative

• Timeboxed

• Risk-driven planning

• Client-driven planning

• Evolutionary and Adaptive Planning

• Incremental Delivery

28

Promised Shipping

Date

RELE

ASE

Scrum 30 days

XP 1 week

All

features

Sase principii ale dezvoltarii Agile

time

Working Software = Potentially shippable

2: Frequently deliver time-boxed increments - high-value Working software

4: The Customer can add, delete or reprioritise features at any time. i.e. this is how we “embrace change”

1: Customer lists known requirements (high level), then prioritises them.

prioritised

3: The Customer can release the software at any time they want.

NOT MINI-WATERFALL

5: We protect schedule commitments, despite change

Backlog

6. Stop at any time and still use what has been built.

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

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

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

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

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

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.

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.

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.

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.

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

Metode Agile

Cele mai folosite metode Agile iterative

– SCRUM

– Extreme programming

– Feature Driven Development

– Agile Unified Process

– Microsoft Solutions Framework

Scrum

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

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.

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

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"

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”

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

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

Practici de baza pentru XP

XP

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

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/

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.

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.

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.

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

• 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

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)

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

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

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.

Conceptul de niveluri(layering)

• Modelul clasic, pe 3 niveluri (3-tier)

• Dezvoltari ulterioare au dus la n niveluri– Presentation/User interface– Application– Domain– Infrastructure

Blocuri functionale ale arhitecturii softwareNiveluri logice Niveluri functionale(arhitectura software) (arhitectura de sistem)

Presentation

Application

Domain

Infrastucture

Microsoft – the four tiers of a composite application

• 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

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

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

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

Arhitectura si infrastructura tehnologiilor

• Infrastructura cuprinde, pe langa arhiectura tehnologiilor si aspectul legat de realizarea reala, hardware

• Arhitectura sistemului– partea virtuala– partea fizica

FrameworkPentru proiectarea de solutii(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

FrameworkPentru 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

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

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

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

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)

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)

Requirements Engineering

• Cerinte

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

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

Caracteristicile calitative ale sistemului

• Capabilitatea sistemului– acoperirea functionalitatilor– acoperirea cererilor nefunctionale

• Maturitatea sistemului– respectarea bunelor practici din domeniu

Caracteristici tehnice, nefunctionale de sistem

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

Caracteristici tehnice, nefunctionale de sistem

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