Click here to load reader

Evolutia si maturizarea proceselor software fileSumar Evolutia produselor/ proceselor software Zone de actiune CMM (Capability Maturity Model) Managementul calitatii cf. ISO 9001:2000

  • View
    24

  • Download
    1

Embed Size (px)

Text of Evolutia si maturizarea proceselor software fileSumar Evolutia produselor/ proceselor software Zone...

  • ManagementulManagementul proiectelorproiectelor

    Evolutia si maturizarea proceselor

    Curs, anul II Calculatoare

    Evolutia si maturizarea proceselor software

  • Sumar

    Evolutia produselor/ proceselor softwareZone de actiuneCMM (Capability Maturity Model)Managementul calitatii cf. ISO 9001:2000Managementul calitatii cf. ISO 9001:2000Arhitecturi de sistem bazate pe model (OMG). Fundamente MDAn PIM (Platform Independent Model)n PSM (Platform Specific Model)

    Arhitectura UML: metamodelulEvolutia UML

  • Review: Management de proiect /procese software

    Managementul proiectelor software este legat direct de activităţile de producţie software (creareși întreţinere de programe de calculator) Activităţile sunt organizate într-un proces de Activităţile sunt organizate într-un proces de producţie = proces de dezvoltare softwareExistă activităţi generice in toate procesele de dezvoltare software: specificarea, proiectarea, implementarea, testareaDAR fiecare proces software are caracteristicispecifice și propriul potential de evolutie

  • Evoluţia software-uluiSoftware-ul este in mod inerent flexibil Cerintele se schimba (prin evolutia unui domeniu) ⇒software-ul coresp. trebuie sa evolueze si sa se schimbeA existat o demarcatie traditionala intre dezvoltare si evolutie (mentenanta), ce devine tot mai irelevanta pe evolutie (mentenanta), ce devine tot mai irelevanta pe masura ce tot mai putine sisteme sunt complet noi

    Assess existingsystems

    Define systemrequirements

    Propose systemchanges

    Modifysystems

    Newsystem

    Existingsystems

  • Evaluarea şi evoluţia proceselor! Nu doar produsele software evoluează,

    ci şi procesele prin care se obţin acestea!Un proces software nu trebuie înţeles ca fiind dat si fixat, ci dinamic, evolutivdat si fixat, ci dinamic, evolutiv

    Un proces software trebuie înţeles pentru a fi definit corespunzător

    Dezvoltarea şi evolutia proceselor software este un proces în sine care trebuie mai intaidefinit, şi apoi măsurat şi gestionat

  • Definirea proceselor software

    Prin urmare, pentru a evolua şi îmbunătăţi un proces:n Acesta trebuie mai intai definit si trebuie sa reprezinte

    printr-o aproximaţie rezonabila ceea ce se face efectiv într-o organizaţieîntr-o organizaţie

    Motivul principal pentru care procesele software sunt deficitare este acela ca NU SE FACE ceea ce SE ŞTIE ca trebuie făcutSimpla definire a unui proces face greşelile şi omisiunile mai evidente şi contribuie astfel la îmbunătăţirea efectivă a proceselor

  • Ghid de definire a unui procesSe porneşte cu o definiţie simplificată de proces Se include o fază de planificarePe baza înregistrărilor din organizaţie, se estimează timpul de dezvoltare pentru fiecare estimează timpul de dezvoltare pentru fiecare fază majoră şi categorie de produs softwareSe definesc metrici (de ex. de productivitate)Se menţine o evidenţă a fiecărei dezvoltări (evoluţii) a procesuluiSe produc raportări pentru fiecare dezvoltare (evoluţie) a procesului

  • Zone de acţiune in continuareMaturizarea proceselor software:Software Engineering Institute (CMU + DoD) ⇒Capability Maturity Model

    Calitatea proceselor si produselor software:International Standards Organization ⇒ Specificaţia ISO 9001:2000

    Consultanţă specializata (firme):⇒ metodologii proprietare SPI (Software Process Improvement)Arhitecturi de sistem bazate pe model: Object Management Group ⇒ initiativa MDA

  • CMMCMM (Capability Maturity Model) este un standard “de

    facto”, dezvoltat de CMU/ DoD in anii ‘80

    Acest model a devenit fundamentul organizarii (in 1984)

    si functionarii SEIsi functionarii SEI

    A evoluat ca un cadru procesual de raportare pentru

    evaluarea gradului de maturizare şi potenţialului de îmbunătăţire a unui proces software

    Validitatea CMM este atestata de cresterea utilizarii

    n practic numarul de organizatii ce au adoptat CMM s-a

    dublat in fiecare an (incepand din 1987)

  • CMM defineşte cinci nivele de maturitate pentru un SDP 1. Iniţial2. Repetabil3. Definit4. Managerizat (a cărui complexitate este bine stăpânită)

    Maturizarea proceselor software

    4. Managerizat (a cărui complexitate este bine stăpânită)5. Optimizat (aflat în îmbunătăţire continuă)

    Fiecare nivel de maturitate se descompune în zone majore de proces Acestea au rolul de a indica unei organizaţii pe ce anume trebuie să se concentreze pentru a-şi îmbunătăţiprocesul software

  • 5 - Optimizing

    4 - Managed

    3- DefinedProces standard,consistent

    Proces predictibil

    Process în îmbunătăţire continuă

    3%

    ≈1%Nivele CMM

    2 - Repetable

    1 - Initial

    Proces riguros, “disciplinat”

    >45%

    30%

    20%

    Proces ad-hoc, ocazional

  • Nivel 1 - Iniţial• Procesul software este caracterizabil ca ad hoc, întâmplător,

    ocazional sau chiar haotic

    • Foarte puţine activităţi sunt bine definite şi formează procese

    • Succesul depinde de efortul individual în cadrul organizaţiei • Succesul depinde de efortul individual în cadrul organizaţiei

    (în anumite perioade chiar eroic)

    • Nu se pot identifica zone majore de proces

    Procesele software de pe acest nivel sunt practic necontrolabile!

  • Nivel 2 - Repetabil• Exista procese de baza de management la nivel de proiect, ce

    permit de ex. urmărirea costurilor, planificărilor, funcţionalităţii• Succesul este atins prin tehnici de management de proiect de

    baza si nu prin tehnologii de proces avansate• Exista posibilitatea repetării succesului unui proiect in proiecte • Exista posibilitatea repetării succesului unui proiect in proiecte

    similare prin aplicarea disciplinata a aceloraşi metode• Zone majore de proces:

    n Managementul cerinţelorn Planificarea proiectelorn Urmărirea proiectelorn Managementul subcontractorilor si outsourcing-uluin Asigurarea calităţii programelorn Managementul configuraţiei programelor

  • Nivel 3 - Definit• Procesul de dezvoltare software al activităţilor de management

    si tehnice (inginereşti) e documentat, standardizat si integrat in procesele standard al organizaţiei

    • Toate proiectele utilizează o versiune aprobata, adaptata la client (customizata) a procesului soft. standard al organizaţieiclient (customizata) a procesului soft. standard al organizaţiei

    • Zone majore de proces:n Definirea procesului software standard al organizaţiein Programele de trainingn Managementul software integratn Ingineria produsului softwaren Coordonarea inter-grupurin Reviziile pereche (Peer reviews)

  • Nivel 4 – Managed (mngable)• Poate fi caracterizat si ca predictibil/ cuantificabil

    • Sunt colectate masuri detaliate ale procesului si calităţii produselor software, se fac analize SWOT

    • Atât procesul software cat si produsele sunt determinate si

    controlate cantitativcontrolate cantitativ

    • Exista in utilizare curenta cel puţin un program de măsurare a software-ului (software metrics)

    • Zone majore de proces:n Managementul cantitativ al proceselor

    n Managementul calităţii software-ului

  • Nivel 5 - Optimizing• Managementul procesului include si proceduri deliberate de

    îmbunătăţire/ optimizare

    • Îmbunătăţirea continua a procesului este validata de:

    • feedback-uri (de metrici) cantitative extrase din proces• feedback-uri (de metrici) cantitative extrase din proces

    • aplicarea dirijata a ideilor si tehnologiilor inovative

    • Zone majore de proces:• Prevenirea defectelor

    • Managementul schimbărilor tehnologice

    • Managementul schimbărilor procesului

  • Observaţii • Asigurarea calităţii software este cel mai mare obstacol

    pentru organizaţiile ce vor sa treacă de pe nivelul 1 pe nivelul 2

    • Definirea procesului organizaţiei este cel mai mare obstacol pentru organizaţiile ce vor sa treacă de pe obstacol pentru organizaţiile ce vor sa treacă de pe nivelul 2 pe nivelul 3

    • In medie, unei organizaţii ii trebuie:n 25 luni pentru a trece de pe nivelul 1 pe 2n 22 luni pentru a trece de pe nivelul 2 pe 3n Peste 36 luni pentru a trece de pe nivelul 3 pe 4

  • CMMIClasificarea companiilor in framework-ul CMM este dificila; a oferiexemple este needificatorMai degraba decat o modalitate de clasificare externa, CMM este o metodologie de evaluare si evolutie interna:“CMM has failed to take over the world. It's hard to tell exactly how wide spread it is as SEI only publishes names and achieved levels of wide spread it is as SEI only publishes names and achieved levels of compliance of companies that have requested this information to be listed”. Vezi http://en.wikipedia.org/wiki/Capability_Maturity_ModelS-a dezvoltat “succesorul” CMM, CMM Integration (2002: v.1.1; aug.2006: v.1.2); scopul sau primar este ca modelele de maturitate sadevina utilizabile, prin integrare intr-un framework unic; vezi: http://en.wikipedia.org/wiki/Capability_Maturity_Model_IntegrationVezi si http://www.sei.cmu.edu/cmmi/solutions/ pentru o discutiedetaliata a “zonelor de proces” predominante in dezvoltarea CMMI

    http://en.wikipedia.org/wiki/Capability_Maturity_Modelhttp://en.wikipedia.org/wiki/Capability_Maturity_Model_Integrationhttp://www.sei.cmu.edu/cmmi/solutions/

  • CMMI - StadializareNivel Zone de proces

    Organization innovation and deploymentCausal analysis and resolution

    Organizational process performanceQuantitative project management

    Requirements developmentTechnical solutionProduct integration

    VerificationValidation

    5 (Optimizing)

    4 (ManagerizatCantitativ)

    Software Systems Engineering

    ValidationOrganizational process focus

    Organizational process definitionOrganizational training

    Integrated project managementRisk management

    Decision analysis and resolutionIntegrated Supplier Management

    Integrated TeamingRequirements management

    Project planningProject monitoring and control

    Configuration ManagementSupplier agreement management

    Measurement and analysisProduct & Process Quality Assurance

    3 (Definit)

    2 (Managerizat)

    1 Initial

    Software -CMM Engineering

    -CMM

    Software Acquisition -

    CMM

    CMMI

  • Componente ale CMMINivele de maturitate

    ZonaProces1 ZonaProces2 ZonaProces3

    Scopuri specifice Scopuri generice

    Practicispecifice

    AbilitatiDeterminare DirectionareaimplementariiVerificarea

    implementarii

    Practicigenerice

    Common Features

  • Standardul ISO 9001:2000 de mngmntal calitatii proceselor/ produselor softw.Principii de bază:1. Orientarea catre client

    Implicare activa în identificarea problemelor clientilor, actuale si viitoare si îndeplinirea cerintelor acestora, explicit definite si negociate

    2. Leadership managerialManagerii stabilesc viziunea, unitatea obiectivelor si directia de Managerii stabilesc viziunea, unitatea obiectivelor si directia de dezvoltare a organizatieiManagerii creaza si gestioneaza mediul intern, în care angajatii companiei se pot implica complet în atingerea obiectivelor organizatiei

    3. Implicarea oamenilorAngajatii formeaza principalul factor de succes al organizatiei si implicarea lor totala genereaza beneficii pentru companie

    4. Abordarea bazata pe procesUn rezultat dorit este atins mult mai eficient când activitatile si resursele aferente sunt gestionate ca procese

  • Principii ISO 9001:2000 de management al calitatii proceselor/ produselor softw.

    5. Abordarea bazata pe managementOdata ce procesele au fost identificate, a întelege si a conduce procesele corelate între ele în cadrul unui sistem unitar, contribuie la eficacitatea si eficienta atingerii obiectivelor

    6. Imbunatatirea continuaImbunatatirea permanenta a proceselor si in consecinta a Imbunatatirea permanenta a proceselor si in consecinta a performantelor organizatiei

    7. Abordarea bazata pe fapte în luarea deciziilorProcesul de luare a deciziilor trebuie sa fie bazat pe analiza datelor si faptelor semnificative

    8. Relatii mutual benefice cu furnizoriiPrin crearea si mentinerea unui parteneriat cu furnizorii sai, sevor genera beneficii si valoare adaugata pentru ambele parti

  • Beneficii Implementarea unei structuri organizationale mai bune, care implica echipe de proiectare cu structura:n sef de proiect, responsabil tehnic, responsabil de versiune

    (release manager)n programatori seniori sau juniorin echipe de testare separate (cu responsabil cu asigurarea si n echipe de testare separate (cu responsabil cu asigurarea si

    controlul calitatii aplicatiei si ingineri de test).Control si estimare de proiect la un nivel superior, care atenueaza o mare parte din riscurile tehniceStandardizarea implementarilor - existenta unor standarde pentru formatarea si comentarea codului (C++, SQL, JAVA etc) conduc la o mai buna mentenabilitate, fiabilitate si flexibilitate a codului

  • Beneficii (cont.)Existenta unor metodologii precise de analiza/proiectare, ingineria specificatiilor si testareStabilirea unui ciclu de viata cu puncte de control pe parcursul sau si definirea clara a intrarilor si iesirilorRealizarea de masurari privind evolutia liniei de produse Realizarea de masurari privind evolutia liniei de produse dezvoltate, cu cuantificarea progreselor semnificativen refolosirea unor parti din analiza/proiectare n investirea în instrumente CASE si instrumente proprii dezvoltate

    pentru o mai buna productivitate

    Rezolvarea problemele de acces concurent si control al versiunilor (CVS, MS Visual Source Safe)

  • Initiativa MDA a OMG www.omg.org/mda

    http://www.omg.org/mda

  • MDA si UMLMDA are in centrul sau preocuparea de a folosilimbajele de modelare ca limbaje de programare(PL) nu numai de dezvoltare (DL) Este evidenta aceasta preocupare in dezvoltareaUML ca “limbaj” de modelare “unificator” UML ca “limbaj” de modelare “unificator” n UML “Standard” rezulta din convergenta a 3 notatii OO:w OMT (Rumbaugh), OOSE (Jacobson), Booch

    n O familie de notatii grafice (diagrame), sustinute de un unic meta-model

    UML ca ML/ DL/ PL este suportat de instrumenteCASE importante:n Rational ROSE n Visual Modeler

  • Locul UML in arhitectura MDAOdata cu UML, prioritatea de actiune a OMG s-a mutat de la standardizarea middleware (vezi IDL-CORBA) spre programarea bazata pe model (MDA)Aceasta imbunatateste productivitatea, calitatea silongevitatea produselor softwarelongevitatea produselor softwareMDA consta in separarea logicii fundamentale a cerintelor de specificul unei implementarin O aplicatie se construieste prin crearea intai a unui

    model independent de platforma al aplicatiei (PIM) n Conversia intr-un model specific unei platforme (PSM)

    a PIM e posibila daca acesta reprezinta o specificarene-echivoca a comportamentului functional

  • PIMPIM constituie o exprimare precisa a sistemului; in UML e dat printr-un “core model” adecvatn Si pentru reprezentarea fiecarui mediu de aplicatie se poate

    folosi un “core model”, diferit, insa independent de orice platforma (chiar si de middleware)platforma (chiar si de middleware)

    PIM nu trebuie confundat cu un model al specificatiilor rezultat dupa analiza problemei

    Atat modelul de analiza cat si modelul de proiectare pot fi PIMs, dar PIM difera de aceste modele traditionale prin aceea ca ofera specificatii precise ale functiilor, structurii si comportamentului sistem ce pot fi translatate automat

  • PIM (cont)Cf. paradigmei MDA, chiar daca in proiectare se modifica

    modelele de analiza pentru a reflecta decizii de proiectare

    si structurale, nu se pot specifica detalii dependente de

    platforma sau tehnologie (specifice PSM)

    Facilitati avansate in UML ce fac PIM precise:

    n OCL, ce permite exprimarea constrangerilor asupra elementelor

    modelului intr-o maniera formalizata

    n Sabloanele

    n Semanticile de actiuni

  • PSMPSM contine detalii de proiectare/ implementare

    PSMs pot fi reprezentate prin profile

    n un numar de profile au fost deja adoptate de OMG

    pentru platforme specifice, ca J2EE si CORBA

    Profilele permit reprezentarea informatiei

    specifice unei platforme folosind stereotipuri,

    valori etichetate si constrangeri

  • Validarea MDAEchivalenta cu:n Posibilitatea de creare a PIM si PSM in mod independent

    n Translatarea automata intre PIM - PSM, fara pierderi de informatii

    Translatarile de interes sunt:n PIM → PIM, ca in cazul trecerii de la un model al specificatiilor la n PIM → PIM, ca in cazul trecerii de la un model al specificatiilor la

    modelul de proiectare

    n PIM → PSM, ca in cazul generarii modelelor catre un instrument extern de codificare; o strategie este ca un PIM sa construiasca un model XMI, apoi utilizarea unui script de transformare din limbaj catre PSM (ca XSLT)

    n PSM → PIM, ca in cazul RE; o strategie: importul automat din XMIn PSM → PSM, pentru realizarea si distributia componentelor

  • MDA si UML executabilIn mod esential, MDA apare ca o abordare standard de utilizare a UML ca limbaj de programaren Daca procesul de trecere PIM → PSM → cod (de ex. J2EE sau

    .NET) e automat, UML = LP

    n Daca vreunul din pasii de trecere nu se poate realiza decat n Daca vreunul din pasii de trecere nu se poate realiza decat manual, UML = plan

    O abordare chiar mai directa este Executable UML (Steve Mellor):n PIM → sistem configurat (deployable), obtinut intr-un singur pas

    prin aplicarea unui Model Compiler (MC)

    n Actiunea MC se bazeaza pe arhetipuri reutilizabile; de ex., pentru a genera dintr-un model UML cod pentru 2 platforme diferite ca J2EE si .NET trebuie un MC si cele 2 arhetipuri corespunzatoare

  • Arhitectura UMLIn evolutia UML, arhitectura (cvadristrat, “4-layered”) este un element de maxima stabilitate

    n Desi implementarea specificatiei originale nu a putut fi pastrata pe termen lung

    Pana la UML 1.4, s-a pastrat conceptul si implementarea

    In UML 2.0 s-a expandat pe baza abordarii initiale (4-layer), rezultand o implementare imbunatatita

  • Arhitectura 4-layer meta-model*UML = Notatie

    // Notatii vizuale UML|| Sintaxa

    // Diagrame UML|| Semantica

    // Descrieri in limbaj natural// Descrieri in limbaj natural

    UML-Model = meta-metamodel || metamodel

    || model || use object

    * EBNF: | “or”, || “and”

  • Nivele UMLMeta-metamodel = OMG MOF// Definit de OMG prin MOF (Meta Object Facilities)

    Metamodel = Foundation// Un pachet ce defineste sintaxa modelelor de comportare statice

    || Behavior// Un pachet ce defineste sintaxa modelelor de comportare dinamice// Un pachet ce defineste sintaxa modelelor de comportare dinamice

    || Management// Un pachet ce defineste semantica de grupare/administrare a elem.modelelor= (core || extension mechanism || data types) || (use-case || activity

    || statechart || collaboration) || (model management)

    Model = class || attribute || operation

    Use object = objects // O instanta a unui model

  • Notatie si meta-modelNotatia este partea grafica vizibila in modele (sintaxa grafica a limbajului de modelare)n De ex., notatia unei diagrame de clasa defineste

    cum se reprezinta conceptele de clasa, asociere, cum se reprezinta conceptele de clasa, asociere, multiplicitate etc.

    Meta-modelul UML defineste intr-o maniera mai riguroasa (dar tot prin diagrame, de ex. de clasa) conceptele si relatiile intre acestean Meta-modelul este tot mai important pe masura ce

    avansam: schita → plan → limbaj de programare

  • Meta-modelul UML in descrierea diagramelor

    Prezinta elementele vizuale de modelare dpdvsemantic; este fundamentul notatiei UML

    Nu toate diagramele sunt la fel de intens utilizate, dar toate sunt cuprinse in meta-model

  • Evolutia UML (1)OMG – comitet de standardizare cu rol major si in elaborarea CORBA IDL (Interface Def. Language) si CORBA IIOP (Internet Inter-ORB Protocol) - a publicat o cerere de propunere de standard (RFP)Rational Software a creat consortiul UML PartnersRational Software a creat consortiul UML Partners(cu DEC, HP, IBM, Microsoft, Oracle, Unisys etc.)Contributiile din afara consortiului, ca raspunsuri separate la RFP din partea (ObjectTime, Platinum Technology, Ptech etc.) sunt considerate si preluate in standardul industrial UML 1.1, in toamna 1997OMG da UML 1.1 ca standard industrial - 14.11.97

  • Evolutia UML (2)Dupa versiunea 1.1 se adauga UML si OCL (Object Constraint Language), un limbaj standard in scrierea constrangerilor, bazat pe ideile lui Steve Cook si John DanielsUML 1.2, 1998 (versiune “editoriala pura”); 1.3; 1.4 UML 1.2, 1998 (versiune “editoriala pura”); 1.3; 1.4 (sept.2001) Semnificativ este UML 1.5,2002 (UML with Action Semantics) ⇒ crearea modelelor UML executabileActualmente: UML 2.0, adoptat in octombrie 2004

  • Rolul OMGDupa 1997, OMG isi asuma responsabilitatea formala pentru dezvoltarea standardului UML (desi multi din membrii consortiului UML Partners participa activ)OMG detine “drepturile” asupra UML, transmise de Rational (intre timp preluata de IBM)Rational (intre timp preluata de IBM)OMG a creat dupa 1997 RTF (Revision Task Force), responsabila pt. gestionarea intrebarilor, schimbarilor, imbunatatirilor UML, si publicarea de noi versiuniDe fapt, exista pentru fiecare zona de dezvoltare cate un “task force”, ce pregateste propuneri pt. ratificare si integrare in standardul UML global

  • Strategia de evolutie a UMLTelurile evolutiei UML sunt parte a strategiei MDAStandardul poate esua daca:n e prea rigid sau, dimpotriva, prea relaxatn prea ingust sau prea cuprinzator n prea legat de o anumita tehnologie sau prea vag pentru a fi

    aplicat tehnologiilor realeZona cheie ce apare pe masura stabilizarii UML:n inter-operabilitatea instrumentelor, ce a condus la XMI

    (XML Metadata InterChange) – standard definit in XMLn XML (eXtensible Markup Language) – format standard

    industrial pt. schimb de inf. in medii distribuite

  • UML in strategia OMGCel mai stabil element in evolutia UML e arhitectura (“four layers arch.”)Problema majora: abordarea meta-model in UML nu are inca o implementare corespunzatoare, ceea ce face dificila alinierea UML cu MOF (Meta-Object face dificila alinierea UML cu MOF (Meta-Object Facility) – o tehnologie fundamentala in strategia globala MDA (Model-Driven Architecture) a OMGObiective urmarite in evolutia standard:n Clarificarea problemelor cu meta-modelul UMLn Eliminarea ambiguitatilor din documentul originaln Imbunatatirea consistentei numelor si a facilitatilor de

    adresare cerute de domenii specializate, etc.