scispace - formally typeset
Search or ask a question
Author

Mary Beth Chrissis

Other affiliations: Software Engineering Institute
Bio: Mary Beth Chrissis is an academic researcher from Carnegie Mellon University. The author has contributed to research in topics: Capability Maturity Model Integration & LeanCMMI. The author has an hindex of 10, co-authored 19 publications receiving 7128 citations. Previous affiliations of Mary Beth Chrissis include Software Engineering Institute.

Papers
More filters
ReportDOI
01 Feb 1993
TL;DR: This paper serves as one of the best sources for understanding the CMM, and it should clear up some of the misconceptions associated with software process maturity as advocated by the SEI.
Abstract: : This paper provides a technical overview of the Capability Maturity Model for Software and reflects Version 1.1. Specifically, this paper describes the process maturity framework of five maturity levels, the structural components that comprise the CMM, how the CMM is used in practice, and future directions of the CMM. This paper serves as one of the best sources for understanding the CMM, and it should clear up some of the misconceptions associated with software process maturity as advocated by the SEI.

1,579 citations

Book
01 Jan 1994
TL;DR: The Capability Maturity Model for Software and the Evolution of the CMM: BackGROUND, CONCEPTS, STRUCTURES and USAGE are explained.
Abstract: I. THE CAPABILITY MATURITY MODEL FOR SOFTWARE: BACKGROUND, CONCEPTS, STRUCTURES AND USAGE. 1. Introducing Software Process Maturity. The Evolution of the CMM. Immature versus Mature Software Organizations. Fundamental Concepts Underlying Process Maturity. Total Quality Management and the CMM. Customer Satisfaction. Benefits and Risks of Model-Based Improvement. 2. The Software Process Maturity Framework. Behavioral Characterization of the Maturity Levels. Skipping Maturity Levels. Visibility into the Software Process. Prediction of Performance. 3. The Structure of the Capability Maturity Model. Internal Structure of the Maturity Levels . Maturity Levels. Key Process Areas. Key Practices. Common Features. 4. Interpreting the CMM. Interpreting the Key Practices. The Key Process Area Template. Interpreting the Common Features. Organizational Structure and Roles. Understanding Software Process Definition. The Evolution of Processes. Applying Professional Judgment. 5. Using the CMM. A CMM-Based Appraisal Method. Process Assessments and Capability Evaluation. Software Process Improvement. Using the CMM in Context. 6. A High-Maturity Example: Space Shuttle Onboard Software. Introduction. Background. Approaches to Process Improvement. Overall Lessons. II. THE KEY PRACTICES OF THE CAPABILITY MATURITY MODEL FOR SOFTWARE. 7. The Key Areas for Level 2: Repeatable. Requirements Management. Software Project Planning. Software Project Tracking and Oversight. Software Subcontract Management. Software Quality Assurance. Software Configuration Management. 8. The Key Process Areas for Level 3: Defined. Organization Process Focus. Organization Process Definition. Training Program. Integrated Software Management. Software Product Engineering. Intergroup Coordination. Peer Reviews. 9. The Key Process Areas for Level 4: Managed. Quantitative Process Management. Software Quality Management. 10. The Key Process Areas for Level 5:Optimizing. Defect Prevention. Technology Change Management. Process Change Management. Appendix A: References. Appendix B: Acronyms. Appendix C: Glossary. Appendix D: Abridged Version of the Key Practices. Appendix E: Mapping the Key Practices to Goals. Appendix F: Comparing ISO 9001 and the CMM. Appendix G: An Overview of ISO's SPICE Project. Appendix H: Change History of the CMM. Appendix I: Change Request Form. Index. 0201546647T04062001

1,395 citations

Book ChapterDOI
01 Jan 2001
TL;DR: An overview of the Capability Maturity Model for Software (Software CMM) and the concepts of software process maturity and a discussion of likely future directions for CMM-like models are provided.
Abstract: This article provides an overview of the Capability Maturity Model® for Software (Software CMM®) and the concepts of software process maturity. (Capability Maturity Model and CMM are registered in the U.S. Patent and Trademark Office.) It contains a background discussion of why process is crucial to organizational and project success, a description of the development of the CMM, a detailed summary of the model, and a description of the model's use for process improvement and the evaluation of software suppliers; describes the use of the CMM in the context of the SEI's IDEALSM (IDEAL is a service mark of Carnegie Mellon University) approach to process improvement; summarizes some of the strengths and weaknesses of the current model and its use; characterizes the state of the practice and the return on investment for software process improvement; and concludes with a discussion of likely future directions for CMM-like models. Keywords: capability maturity model; trademark; Carnegie Mellon University; principles; total quality management; software; maturity model; uses; key process improvement; case studies

1,342 citations

Journal ArticleDOI
TL;DR: The capability maturity model (CMM), developed to present sets of recommended practices in a number of key process areas that have been shown to enhance software-development and maintenance capability, is discussed.
Abstract: The capability maturity model (CMM), developed to present sets of recommended practices in a number of key process areas that have been shown to enhance software-development and maintenance capability, is discussed. The CMM was designed to help developers select process-improvement strategies by determining their current process maturity and identifying the issues most critical to improving their software quality and process. The initial release of the CMM, version 1.0, was reviewed and used by the software community during 1991 and 1992. A workshop on CMM 1.0, held in April 1992, was attended by about 200 software professionals. The current version of the CMM is the result of the feedback from that workshop and ongoing feedback from the software community. The technical report that describes version 1.1. is summarised. >

1,179 citations

Book
01 Feb 2003
TL;DR: In this paper, the authors present an overview of the capabilities of the CMMI model and its application in the context of software process improvement, including the following: Capability Maturity Level 0: Incomplete, Capability Level 1: Performed. Capability level 2: Managed. Matability Level 3: Defined. Capable Level 4: Optimizing.
Abstract: Preface. Purpose of This Book. Audience. Organization of This Book. How to Use This Book. Readers New to Process Improvement. Readers Experienced with Process Improvement. Readers Familiar with CMMI. Additional Information and Reader Feedback. Acknowledgments. I. ABOUT CMMI. 1. Introduction. About Capability Maturity Models. Evolution of CMMI. Coverage of the Bodies of Knowledge. Systems Engineering. Software Engineering. Integrated Product and Process Development. Supplier Sourcing. Selecting Disciplines. Process Areas for Systems Engineering. Process Areas for Software Engineering. Process Areas for Integrated Product and Process Development. Process Areas for Supplier Sourcing. Multiple Disciplines. A Conclusion. Resolving Different Approaches of CMMs. Choosing a Representation. Continuous Representation. Staged Representation. Comparison of the Continuous and Staged Representations. Factors in Your Decision. Why Not Both Representations? Choosing Your Approach to Process Improvement. Scenario 1. Scenario 2. The Advantages of CMMI. 2. Process Area Components. Required, Expected, and Informative Components. Required Components. Expected Components. Informative Components. Components Associated with Part Two. Process Areas. Purpose Statements. Introductory Notes. Related Process Areas. Specific Goals. Generic Goals. Practice-to-Goal Relationship Tables. Specific Practices. Typical Work Products. Subpractices. Generic Practices. Generic Practice Elaborations. Supporting Informative Components. Notes. Examples. Discipline Amplifications. References. Numbering Scheme. Typographical Conventions. Representation-Specific Content. Discipline-Specific Content. 3. Process Institutionalization. Overview. Process Institutionalization. Performed Process. Managed Process. Defined Process. Quantitatively Managed Process. Optimizing Process. Relationships among Processes. Generic Goals and Generic Practices. GG 1 Achieve Specific Goals. GG 2 Institutionalize a Managed Process. GG 3 Institutionalize a Defined Process. GG 4 Institutionalize a Quantitatively Managed Process GG 5 Institutionalize an Optimizing Process. Applying Generic Practices. Process Areas That Support Generic Practices. 4. Relationships among Process Areas. Four Categories of CMMI Process Areas. Process Management. Fundamental Process Management Process Areas. Progressive Process Management Process Areas. Project Management. Fundamental Project Management Process Areas. Progressive Project Management Process Areas. Engineering. Engineering Process Areas and Recursion. Support. Fundamental Support Process Areas. Progressive Support Process Areas. 5. Tying It All Together. Understanding Levels. Structures of the Continuous and Staged Representations. Understanding Capability Levels. Capability Level 0: Incomplete. Capability Level 1: Performed. Capability Level 2: Managed. Capability Level 3: Defined. Capability Level 4: Quantitatively Managed. Capability Level 5: Optimizing. Advancing through Capability Levels. Understanding Maturity Levels. Maturity Level 1: Initial. Maturity Level 2: Managed. Maturity Level 3: Defined. Maturity Level 4: Quantitatively Managed. Maturity Level 5: Optimizing. Advancing through Maturity Levels. Process Areas. Specific Practices. Base and Advanced Practices. Generic Goals and Practices. Common Features. Representation Comparison. Equivalent Staging. 6. Using CMMI Models. Interpreting CMMI Models. Appraisals and Benchmarking. Appraisal Requirements for CMMI. ISO/IEC 15504 Compatibility and Conformance. Adopting CMMI. Organizations with Experience. Organizations New to Process Improvement. CMMI Model Training. Model Tailoring. Tailoring Constraints for Process Improvement. Tailoring Constraints for Benchmarking. Planning Tailoring for Benchmarking. Appraisal Considerations. 7. CMMI Case Study: United Space Alliance, LLC. Background. USA Mission and Vision. Deploying Company Goals. Process Ownership. CMMI Case Study Activity. The Initiating Phase. Project Selection. Primary Avionics Software System Project Background. Cockpit Avionics Upgrade Project Background. CMMI Model Selection and Scope. CMMI Training. CMMI Supplemental Resources. The Diagnosing Phase. Collecting Information. Recording Observations. CMMI Model Results. Engineering Process Areas. Requirements Management and Requirements Development. Technical Solution. Product Integration. Verification and Validation. Project Management Process Areas. Project Planning. Project Monitoring and Control. Integrated Project Management. Supplier Agreement Management. Risk Management. Quantitative Project Management. Process Management Process Areas. Organizational Process Focus and Organizational Process Definition. Organizational Training. Organizational Process Performance. Organizational Innovation and Deployment. Support Process Areas. Configuration Management. Process and Product Quality Assurance. Measurement and Analysis. Decision Analysis and Resolution. Causal Analysis and Resolution. Lessons Learned. Interpretation Issues. Next Steps. II. THE PROCESS AREAS. Causal Analysis and Resolution. Configuration Management. Decision Analysis and Resolution. Integrated Project Management. Integrated Supplier Management. Integrated Teaming. Measurement and Analysis. Organizational Environment for Integration. Organizational Innovation and Deployment. Organizational Process Definition. Organizational Process Focus. Organizational Process Performance. Organizational Training. Product Integration. Project Monitoring and Control. Project Planning. Process and Product Quality Assurance. Quantitative Project Management. Requirements Development. Requirements Management. Risk Management. Supplier Agreement Management. Technical Solution. Validation. Verification. III. THE APPENDICES AND GLOSSARY. Appendix A. References. Publicly Available Sources. Regularly Updated Sources. Appendix B. Acronyms. Appendix C. CMMI Project Participants. Product Team. Sponsors. Steering Group. Configuration Control Board. Stakeholders/Reviewers. Glossary. Index. 0321154967T01292003

960 citations


Cited by
More filters
Journal ArticleDOI
S. Agostinelli1, John Allison2, K. Amako3, J. Apostolakis4, Henrique Araujo5, P. Arce4, Makoto Asai6, D. Axen4, S. Banerjee7, G. Barrand, F. Behner4, Lorenzo Bellagamba8, J. Boudreau9, L. Broglia10, A. Brunengo8, H. Burkhardt4, Stephane Chauvie, J. Chuma11, R. Chytracek4, Gene Cooperman12, G. Cosmo4, P. V. Degtyarenko13, Andrea Dell'Acqua4, G. Depaola14, D. Dietrich15, R. Enami, A. Feliciello, C. Ferguson16, H. Fesefeldt4, Gunter Folger4, Franca Foppiano, Alessandra Forti2, S. Garelli, S. Gianì4, R. Giannitrapani17, D. Gibin4, J. J. Gomez Y Cadenas4, I. González4, G. Gracia Abril4, G. Greeniaus18, Walter Greiner15, Vladimir Grichine, A. Grossheim4, Susanna Guatelli, P. Gumplinger11, R. Hamatsu19, K. Hashimoto, H. Hasui, A. Heikkinen20, A. S. Howard5, Vladimir Ivanchenko4, A. Johnson6, F.W. Jones11, J. Kallenbach, Naoko Kanaya4, M. Kawabata, Y. Kawabata, M. Kawaguti, S.R. Kelner21, Paul R. C. Kent22, A. Kimura23, T. Kodama24, R. P. Kokoulin21, M. Kossov13, Hisaya Kurashige25, E. Lamanna26, Tapio Lampén20, V. Lara4, Veronique Lefebure4, F. Lei16, M. Liendl4, W. S. Lockman, Francesco Longo27, S. Magni, M. Maire, E. Medernach4, K. Minamimoto24, P. Mora de Freitas, Yoshiyuki Morita3, K. Murakami3, M. Nagamatu24, R. Nartallo28, Petteri Nieminen28, T. Nishimura, K. Ohtsubo, M. Okamura, S. W. O'Neale29, Y. Oohata19, K. Paech15, J Perl6, Andreas Pfeiffer4, Maria Grazia Pia, F. Ranjard4, A.M. Rybin, S.S Sadilov4, E. Di Salvo8, Giovanni Santin27, Takashi Sasaki3, N. Savvas2, Y. Sawada, Stefan Scherer15, S. Sei24, V. Sirotenko4, David J. Smith6, N. Starkov, H. Stoecker15, J. Sulkimo20, M. Takahata23, Satoshi Tanaka30, E. Tcherniaev4, E. Safai Tehrani6, M. Tropeano1, P. Truscott31, H. Uno24, L. Urbán, P. Urban32, M. Verderi, A. Walkden2, W. Wander33, H. Weber15, J.P. Wellisch4, Torre Wenaus34, D.C. Williams, Douglas Wright6, T. Yamada24, H. Yoshida24, D. Zschiesche15 
TL;DR: The Gelfant 4 toolkit as discussed by the authors is a toolkit for simulating the passage of particles through matter, including a complete range of functionality including tracking, geometry, physics models and hits.
Abstract: G eant 4 is a toolkit for simulating the passage of particles through matter. It includes a complete range of functionality including tracking, geometry, physics models and hits. The physics processes offered cover a comprehensive range, including electromagnetic, hadronic and optical processes, a large set of long-lived particles, materials and elements, over a wide energy range starting, in some cases, from 250 eV and extending in others to the TeV energy range. It has been designed and constructed to expose the physics models utilised, to handle complex geometries, and to enable its easy adaptation for optimal use in different sets of applications. The toolkit is the result of a worldwide collaboration of physicists and software engineers. It has been created exploiting software engineering and object-oriented technology and implemented in the C++ programming language. It has been used in applications in particle physics, nuclear physics, accelerator design, space engineering and medical physics.

18,904 citations

Posted Content
TL;DR: Deming's theory of management based on the 14 Points for Management is described in Out of the Crisis, originally published in 1982 as mentioned in this paper, where he explains the principles of management transformation and how to apply them.
Abstract: According to W. Edwards Deming, American companies require nothing less than a transformation of management style and of governmental relations with industry. In Out of the Crisis, originally published in 1982, Deming offers a theory of management based on his famous 14 Points for Management. Management's failure to plan for the future, he claims, brings about loss of market, which brings about loss of jobs. Management must be judged not only by the quarterly dividend, but by innovative plans to stay in business, protect investment, ensure future dividends, and provide more jobs through improved product and service. In simple, direct language, he explains the principles of management transformation and how to apply them.

9,241 citations

Journal ArticleDOI
TL;DR: The aim is to explicate a set of general concepts, of relevance across a wide range of situations and, therefore, helping communication and cooperation among a number of scientific and technical communities, including ones that are concentrating on particular types of system, of system failures, or of causes of systems failures.
Abstract: This paper gives the main definitions relating to dependability, a generic concept including a special case of such attributes as reliability, availability, safety, integrity, maintainability, etc. Security brings in concerns for confidentiality, in addition to availability and integrity. Basic definitions are given first. They are then commented upon, and supplemented by additional definitions, which address the threats to dependability and security (faults, errors, failures), their attributes, and the means for their achievement (fault prevention, fault tolerance, fault removal, fault forecasting). The aim is to explicate a set of general concepts, of relevance across a wide range of situations and, therefore, helping communication and cooperation among a number of scientific and technical communities, including ones that are concentrating on particular types of system, of system failures, or of causes of system failures.

4,695 citations

01 Jan 2007
TL;DR: In this paper, the main definitions relating to dependability, a generic concept including a special case of such attributes as reliability, availability, safety, integrity, maintainability, etc.
Abstract: This paper gives the main definitions relating to dependability, a generic concept including a special case of such attributes as reliability, availability, safety, integrity, maintainability, etc. Security brings in concerns for confidentiality, in addition to availability and integrity. Basic definitions are given first. They are then commented upon, and supplemented by additional definitions, which address the threats to dependability and security (faults, errors, failures), their attributes, and the means for their achievement (fault prevention, fault tolerance, fault removal, fault forecasting). The aim is to explicate a set of general concepts, of relevance across a wide range of situations and, therefore, helping communication and cooperation among a number of scientific and technical communities, including ones that are concentrating on particular types of system, of system failures, or of causes of system failures.

4,335 citations

Journal ArticleDOI
Tore Dybå1, Torgeir Dingsøyr1
TL;DR: A systematic review of empirical studies of agile software development up to and including 2005 was conducted and provides a map of findings, according to topic, that can be compared for relevance to their own settings and situations.
Abstract: Agile software development represents a major departure from traditional, plan-based approaches to software engineering. A systematic review of empirical studies of agile software development up to and including 2005 was conducted. The search strategy identified 1996 studies, of which 36 were identified as empirical studies. The studies were grouped into four themes: introduction and adoption, human and social factors, perceptions on agile methods, and comparative studies. The review investigates what is currently known about the benefits and limitations of, and the strength of evidence for, agile methods. Implications for research and practice are presented. The main implication for research is a need for more and better empirical studies of agile software development within a common research agenda. For the industrial readership, the review provides a map of findings, according to topic, that can be compared for relevance to their own settings and situations.

2,399 citations