Evolutia si maturizarea proceselor software fileSumar Evolutia produselor/ proceselor software Zone...
Transcript 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
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 Directionareaimplementarii
Verificareaimplementarii
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
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 XMI
n 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.