Corso di Laurea Magistrale in Ingegneria Informatica per la Gestione d aziendad

Transcript

1 Corso di Laurea Magistrale in Ingegneria Informatica per la Gestione d aziendad Gestione della Qualità-II parte La produzione del software: metodologie e standards a.a Docente: Gigliola Vaglini Lezioni 17,18 Improvements models 1

2 I modelli per il miglioramento Modelli di accertamento e miglioramento: consentono di valutare la capacità e la maturità di un processo di produzione e manutenzione del software (PMS) e sono capaci di guidare verso la loro crescita. Consentono di definire processi per la valutazione dei processi. Maturity models A maturity model can be described as a structured collection of elements that describe certain aspects of maturity in an organization,, and aids in the definition and understanding of the organization's processes and in the organization improvement. 2

3 Maturity models A maturity model may provide, for example : a place to start the benefit of a community s prior experiences a common language and a shared vision a framework for prioritizing actions a way to define what improvement means for your organization. A maturity model can be used as a benchmark for comparison and as an aid to understanding - for example, for comparative assessment of different organizations where there is something in common that can be used as a basis for comparison. The Capability Maturity Model (CMM) is the most widely used model of assesment and improvement. Active development of this model began in 1986 at the Software Engineering Institute located at Carnegie Mellon University in Pittsburgh, Pennsylvania on behalf of DOD and Mitra Corporation. 3

4 Capability Maturity Model (CMM) The CMM was originally intended as a tool to evaluate the ability of government contractors to perform a contracted software project. In the case of the CMM the basis for comparison among organizations would be the organizations' software development processes. Though it comes from the area of software development, it can be, has been,, and continues to be widely applied as a general model of the maturity of processes. Capability Maturity Model 4

5 Capability Maturity Model Structure The Capability Maturity Model involves the following aspects: Maturity Levels: A 5-Level 5 process maturity continuum - where the uppermost (5th) level is a notional ideal state where processes would be systematically managed by a combination of process optimization and continuous process improvement. Key Process Areas: A Key Process Area (KPA) identifies a cluster of related activities that, when performed collectively, achieve a set of goals considered important. Cont. Goals: The goals of a key process area summarize the states that must exist for that key process area to have been implemented in an effective and lasting way. The extent to which the goals have been accomplished is an indicator of how much capability the organization has established at that maturity level.. The goals signify the scope, boundaries,, and intent of each key process area. Common Features: Common features include practices that implement and institutionalize a key process area. There are five types of common features: Commitment to Perform, Ability to Perform, Activities Performed, Measurement and Analysis,, and Verifying Implementation. Key Practices: The key practices describe the elements of infrastructure and practice that contribute most effectively to the implementation and institutionalization of the KPAs. 5

6 CMM The model identifies five levels of process maturity for an organization: Initial (chaotic,, ad hoc, heroic) ) the starting point for use of a new process. Repeatable (project management, process discipline) the process is used repeatedly. Defined (institutionalized)) the process is defined/confirmed as a standard business process. Managed (quantified) process management and measurement takes place. Optimizing (process improvement) process management includes deliberate process optimization/improvement improvement. Capability Maturity Model Initial. It is characteristic of processes at this level that they are (typically( typically) undocumented and in a state of dynamic change, tending to be driven in an ad hoc, uncontrolled and reactive manner by users or events. This provides a chaotic or unstable environment for the processes. Requirements flow in. A software product is (usually) produced by some amorphous process.. The product flows out and (hopefully) works. Institutional knowledge tends to be scattered in such environments, not all of the participants in the processes may know or understand all of the components that make up the processes. 6

7 Capability Maturity Model Repeatable. Processes and their outputs could be visible to management at defined points, but results may not always be consistent. Some basic processes are established to track cost, schedule, and functionality, and a degree of process discipline is in place to repeat earlier successes on projects with similar applications and scope; nevertheless there could still be a significant risk of exceeding cost and time estimates. Requirements and resources flow in. The production of the software product is visible at defined points. Artifacts of the process are controlled. Capability Maturity Model Defined. There are sets of defined and documented standard processes established and subject to some degree of improvement over time. These standard processes are in place and used to establish consistency of process performance across the organization. Roles and responsabilities in the process are understood.. The software product is visible throughout the software process. 7

8 Capability Maturity Model Managed. Using process metrics,, management can effectively control the software development.. In particular,, management can identify ways to adjust and adapt the process to particular projects without measurable losses of quality or deviations from specifications. The software production is quantitatively understood throughout the software process. Capability Maturity Model Optimizing. Quantitative process- improvement objectives for the organization are established, continually revised to reflect changing business objectives,, and used as criteria in managing process improvement. The software process is continuously improved in a controlled manner. 8

9 Capability Maturity Model Each level is associated with an expected performance Each level is associated with tools to be used during the process, for example, organizational database Una previsione di performance per ogni livello 9

10 Una tipologia di strumenti per ogni livello Struttura dei livelli Ciascun livello di maturità è composto da un insieme di aree chiavi di processo. Ciascuna "area chiave" è organizzata in cinque sezioni dette "Caratteristiche comuni". Le caratteristiche comuni identificano le "Pratiche chiavi che, quando tutte eseguite, permettono il raggiungimento dei goal delle "aree chiavi. 10

11 Ciascuna area chiave definisce un insieme di attività correlate che, quando vengono globalmente sviluppate, garantiscono che il processo sia al livello di maturità ad essa associato, e quindi anche la relativa capacità. Queste aree chiave risultano fondamentali ai fini: dell accertamento: se le attività sono sviluppate allora il processo è al livello associato; del miglioramento: se si vuol passare al livello associato si deve introdurre nel processo lo sviluppo delle attività associate. In each KPA there are five definitions identified: Goals Commitment Ability Measurement Verification The KPAs are not necessarily unique to CMM, representing as they do the stages that organizations must go through on the way to becoming mature. 11

12 Accertamento L accertamento è condotto mediante una analisi dell azienda (documenti organizzativi, procedure aziendali) e realizzando interviste attraverso appositi questionari. Il SEI ha definito un questionario da utilizzare che va adattato e tarato alle varie realtà. Il questionario è suddiviso in sezioni, quali: organizzazione, risorse, personale e formazione, gestione della tecnologia, standard e procedure, metriche di processo, raccolta ed analisi dei dati, controllo processo. 12

13 Accertamento Le domande, divise in due categorie (a e b), sono a risposta booleana (Si/No) ed ognuna di esse, correlata ad una key area, è associata ad un livello di maturità da 2 a 5. La regola che determina il livello di maturità è la seguente: La maturità di un processo è di livello i se si risponde SI all 80% delle domande di tipo a ed al 90% di quelle di tipo b associate ai livelli tra 2 ed i. Le risposte vengono verificate e controllate. Domande per il livello 2 13

14 Domande per il livello 2 Domande per il livello 2 14

15 Domande per il livello 2 Domande per il livello 2 15

16 Come migliorare ad ogni livello Pros Prior to the introduction of CMM, there was no theoretical basis applicable to process maturity for IT-related processes. CMM has been shown to be well-suited for organizations wishing to define their key processes. 16

17 Pros 1300 projects involving products of at least 200 KLOC had been examined to evaluate the possible saving in the five levels. See the table in the following slide. The US Air Force requires level 3 certification from all its contractors. 17

18 Cons The objective of scientifically managing the software process using defined metrics is difficult to achieve until Level 4. The CMM does not help to define the structure of an effective software development organization.. The CMM contains behaviors or best practices that successful projects have demonstrated. Thus, being CMM compliant would not necessarily guarantee that a project would be successful. However, being compliant could increase a project's chances of being successful. Contro I clienti sono spesso orientati a parametri non solo di qualità, ma piuttosto di rapporto tra qualità e costi oppure tra qualità costi e tempi. Un fornitore di Livello 5 CMM garantisce davvero che il progetto software dato in outsourcing si concluderà in tempo e nel budget? 18

19 Contro Le indagini confermano che livelli CMM più alti sono correlati con una minor difettosità del software. I dati su qualità e livello di maturità mostrano che c è un miglioramento indiscutibile nei costi e nel rispetto dei tempi di completamento dei progetti. Ma la massima valutazione CMM non necessariamente garantisce il massimo risparmio per il cliente. Il fornitore passa i suoi minori costi al cliente? I fornitori di Livello 5 sono i migliori, dunque hanno la possibilità di ricaricare di più, non di meno, sui clienti. Per di più, una valutazione di Livello 5 in qualche caso, fanno notare gli esperti, potrebbe comportare investimenti maggiori del necessario. Evoluzione del CMM:CMMI 19

20 Riassumendo Il modello indica ventidue Aree di processi aziendali ( (ProcessProcess area) ) strutturate su cinque livelli, ognuna con i propri obiettivi generici (GenericGeneric Goal) ) e specifici ( (Specific Goal). Gli obiettivi generici e specifici sono implementati da una sequenza temporale di attività generiche ( (GenericGeneric practice) ) e specifiche ( (specificspecific practice), che hanno determinate tipologie di output ( (tipicaltipical work product). ). Il SEI ha constatato che 60 società hanno misurato miglioramenti delle loro prestazioni in termini di costi, qualità, produttività e soddisfazione del cliente con miglioramenti compresi fra il 14% della soddisfazione del cliente al 62% di incremento della produttività. Il CMMI in molti casi si limita a dichiarare quali miglioramenti dei processi devono essere raggiunti, ma non in quale modo. In particolare, non indica gli attori, le applicazioni e le strutture re informatiche protagoniste del cambiamento. I benefici dell'implementazione di un framework CMMI sono limitati per piccole organizzazioni. È significativo che il 70.5% delle società del campione con meno di 25 dipendenti si collochi al livello 2, mentre il 52.8% di quelle che hanno fra i 1000 e i 2000 dipendenti, si collochi al livello più alto (livello 5: ottimizzato). 20

21 An organization cannot be certified in CMMI; instead, an organization is appraised. Depending on the type of appraisal, the organization can be awarded a maturity level rating (1-5) or a capability level achievement profile. Appraisals of organizations using a CMMI model must conform to the requirements defined in the Appraisal Requirements for CMMI (ARC) document. There are three classes of appraisals,, A, B and C, which focus on identifying improvement opportunities and comparing the organization s processes to CMMI best practices. The Standard CMMI Appraisal Method for Process Improvement (SCAMPI) is an appraisal method that meets all of the ARC requirements. A class A appraisal is more formal and is the only one that can result in a level rating. Results of an appraisal may be published (if the appraised organization approves) ) on the CMMI Web site of the SEI. Al momento non esistono authority indipendenti autorizzate a valutare i processi di altre aziende secondo il CMMI, e la valutazione è effettuata direttamente dal SEI. Il SEI ha valutato secondo il CMMI i processi di una ventina di aziende informatiche in tutto il mondo. Fra queste, una decina di aziende indiane; in Italia,, la sola IBM. 21

22 Statistiche SEI has maintained statistics on the "time" to move up" for organizations adopting the earlier Software CMM and primarily using the traditional approach. These statistics indicate that, since 1987, the median times to move from Level 1 to Level 2 is 23 months, and from Level 2 to Level 3 is an additional 20 months. The Software Engineering Institute s (SEI) Team Software Process methodology and the Capability Maturity Modeling framework have been successfully employed to accelerate progress from Maturity Level 1 to Maturity Level 4. They ve demonstrated progressing from Level 1 to Level 4 in 30 months, which is less than half of the average time it has taken traditionally. References Turner & Jain (2002) per un confronto tra CMMI e metodologie Agile Nawrocki e altri (2002) per un confronto tra CMMI e Extreme Programming 22

23 Interestingly,, Turner & Jain (2002) argue that although it is obvious there are large differences between CMMI and agile methods, both approaches have much in common. They believe neither way is the 'right' way to develop software, but that there are phases in a project where one of the two is better suited. They suggest one should combine the different fragments of the methods into a new hybrid method. David J. Anderson (2005) gives hints on how to interpret CMMI in an agile manner. Other viewpoints about using CMMI and Agile development are available on the SEI Web site. To conclude with a similar use of CMMI, Extreme Programming (XP), a software engineering method, has been evaluated with CMM/CMMI (Nawrocki( et al., 2002). For example,, the XP requirements management approach,, (which( relies on oral communication), was evaluated as not compliant with CMMI. 23