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

Structura sistemelor informatice integrate

Sisteme IT orientate pe funcţiuni/procese

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

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

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 Management 2 Computerworld 3 The Economist

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

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

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

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

Î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

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

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 1 week time NOT MINI-WATERFALL

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 Working software 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 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.

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 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”

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

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

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

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

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

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

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

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