Software Processes
Software Process Improvement | CMM & CMMI | Agile Methods | Six Sigma | Maintenance | Requirements | Testing | Inspections | Offshore | Lean
Software Process Improvement
A Framework for Evolving System of Systems Engineering
We provide a framework for examining the differences between systems engineering and system of systems engineering (SoSE). By taking normative, descriptive, and prescriptive views of these constructs, similarities and differences can be better identified. Moreover, we note that additional work is needed in the development of normative and prescriptive models in order to advance our understanding of both systems engineering and SoSE. Article by Ricardo Valerdi, Adam Ross, and Donna Rhodes. (6 pages)
Click Here to Read "A Framework for Evolving System of Systems Engineering"!
Software System Engineering: A Tutorial
Applying system-engineering principles specifically to the development of large, complex software systems provides a powerful tool for process and product management. Software engineering has its early roots in system engineering which is reflected in their many common terms. This article discusses a merger between system engineering and software engineering called software system engineering. System engineering looks at controlling the total system development including software. Software engineering looks at controlling just software development. (System engineers would call software engineering component engineering.) The application of system engineering to the development of software gives a large measure of control software development. Article by Dr. Richard Thayer. (10 pages)
Click Here to Read "Software System Engineering: A Tutorial"!
Your Process Improvement Program - Is the Organization Ready for Change?
There have been numerous accounts of companies achieving the benefits that come with advancing to higher levels of maturity with the Software Engineering Institute's CMMI® framework or initiating a Six Sigma program for higher quality. There are of course numerous other process improvement models such as CobIT and ITIL all of which can result in similar success stories. But the hard reality of some improvement programs is that they can and do fail. David Herron highlights six key risk factors that can contribute to the success of a process improvement program. (4 pages)
Click Here to Read "Your Process Improvement Program - Is the Organization Ready for Change"!
Software Process: A Roadmap
This paper, by Alfonso Fuggetta of the Politecnico di Milano, seeks to briefly present the history and achievements of software process research, some critical evaluation of the software process results produced so far, and possible directions for future software process work. (7 pages)
Click Here to Read "Software Process: A Roadmap"!
Software Processes: A Retrospective and a Path for the Future
This paper, by Gianpaolo Cugola and Carlo Ghezzi, attempts to characterize the main approaches to software processes that were followed historically by software engineering while also identifying the strengths, weaknesses, motivations and misconceptions that lead to the continuous evolution of the software process field. It concludes with a discussion of where the software process field is now and what the research agenda for the future of software processes will look like. (22 pages)
Click Here to Read "Software Processes: A Retrospective and a Path for the Future"!
Process Implementation
This paper, by Sarah A. Sheard of the Software Productivity Consortium, provides a list of software process implementation and institutionalization actions that organizations should consider to ensure that software processes are properly used. Steps outlined include activities needed to establish the environment for software process implementation, ongoing software process maintenance tasks that need to persist, and specific one-time implementation tasks that initiate the use of new software processes. (11 pages)
Click Here to Read "Process Implementation"!
Software Engineering: The State of the Art in 2005
The phrase 'state of the art' refers to software development practices that have consistently yielded results that are in the top 15% of approximately 12,000 software projects examined. There are hundreds of ways to develop software that lead to overruns and failures. Surprisingly, there are only a few ways to develop software that consistently result in successful outcomes. This article by Capers Jones examines the three weakest links in the chain of software development practices: those dealing with planning and estimating before the software project starts, those dealing with the absorption of changing software requirements during the project, and those that successfully minimize software bugs or defects via excellent software quality control. (22 pages)
Click Here to Read "Software Engineering: The State of the Art in 2005"!
The Impact of Poor Quality and Canceled Projects on the Software Labor Shortage
In this article by Capers Jones, the hypothesis is put forward that there would not be a significant software personnel shortage if the current level of software errors could be reduced or eliminated. The amount of software effort spent on software projects that will be canceled due to excessive error content appears to absorb more than 15% of the global software work force. In addition, about 60% of the U.S. software work force are engaged in fixing software errors which might have been avoided. A stronger focus on software quality control and software risk analysis would seem to offer substantial economic advantages, by reducing the amount of software engineering effort currently spent on software defect repairs and software projects too poorly constructed to be completed. (14 pages)
Click Here to Read "The Impact of Poor Quality and Canceled Projects on the Software Labor Shortage"!
A CAI State of the Practice Interview with Dr. Michael Cusumano, MIT Sloan School of Management
Michael A. Cusumano is the Sloan Management Review Distinguished Professor at MIT's Sloan School of Management. He specializes in strategy, product development, and entrepreneurship in the software business. He has been a director of several public and private software companies, and has consulted for approximately 50 major corporations around the world. Professor Cusumano is the co-author of the international best-seller Microsoft Secrets,which has been translated into 14 languages. His most recent book is The Business of Software: What Every Manager, Programmer, and Entrepreneur Must Know to Thrive and Survive, in Good Times and Bad. Our interview with Michael Cusumano and Michael Milutis, Executive Director of the IT Metrics and Productivity Institute (ITMPI), was conducted in June of 2005.
Click Here for the Interview with Dr. Michael Cusumano!
Software Development Worldwide: The State of the Practice
This article by Michael Cusumano, Alan MacCormack, Chris Kemerer, and Bill Crandall reports early descriptive results from a global survey of completed software projects. The survey seeks to examine the impact of different software development practices on various dimensions of software project performance. In the course of their study, the authors contrast more conventional waterfall-style software development models with newer software development styles based on iterative methods. They also speculate on the accuracy of Indian software quality and software productivity reports. (7 pages)
Click Here to Read "Software Development Worldwide: The State of the Practice"!
Trade-offs Between Productivity and Quality in Selecting Software Development Practices
This article by Michael Cusumano, Alan MacCormack, Chris Kemerer, and Bill Crandall looks at how certain software development practices, proposed by various software development models, affect performance. By exploring different software development practices' associations with multiple dimensions of performance across a number of projects, they are able to examine the trade-offs involved in designing software processes for the optimization of specific performance criteria. (8 pages)
Click Here to Read "Trade-offs Between Productivity and Quality in Selecting Software Development Practices"!
Using the Cost of Quality Approach for Software
Cost of Software Quality (CoSQ) is an accounting technique that is useful to enable our understanding of the economic trade-offs involved in delivering good-quality software. Commonly used in manufacturing, its adaptation to software offers the promise of preventing poor software quality but, unfortunately, has seen little use to date. This article by Herb Krasner discusses the rationale and context for using Cost of Software Quality (CoSQ), then defines a basic Cost of Software Quality (CoSQ) model that differentiates the costs involved with handling nonconformances due to a lack of software quality, appraisal efforts performed for the achievement of acceptable software quality, and efforts to prevent poor software quality from occurring. (6 pages)
Click Here to Read "Using the Cost of Quality Approach for Software"!
The Cognitive View: A Different Look at Software Design
"What is software design?" Methodologies are not design - they are frameworks for organizing design efforts. Likewise, languages are not design - they are representations for documenting design once it has been formulated. Still curious? Find the answer in this excerpt from Robert Glass' new book "Software Conflict." (9 pages)
Click Here to Read "The Cognitive View: A Different Look at Software Design"!
Ten Best Influences on Software Engineering
In this article from IEEE Software, Steve McConnell set out to get some perspective on the best influences seen during software engineering's first 50 years. After drafting an initial list of influences, he turned to his IEEE advisory board (IEEE Software has active editorial and industrial advisory boards comprised of leading experts from around the world). What follows is their discussion of best influences on software engineering. (11 pages)
Click Here to Read the Article!
Software Economics: A Roadmap
Software design is an investment activity, and software economics is the field that seeks to enable significant improvements in software design and engineering through economic reasoning about product, process, program, and portfolio and policy issues. This article by Barry Boehm and Kevin Sullivan summarizes the state of the art and identifies shortfalls in existing knowledge. Past work focuses largely on costs, not on benefits. The authors present a roadmap for research emphasizing the need for a strategic investment approach to software engineering. They discuss how software economics can lead to fundamental improvements in software design and engineering, in both theory and practice. (24 pages)
Click Here to Read the Article!
POWER POINT: Software Process Models
Good overview of waterfall and iterative models: advantages, disadvantages and how to choose a model that is right for you. (11 pages)
Click Here to Read "POWER POINT: Software Process Models"!
A Survey of System Development Process Models
This document, produced by the Center for Technology in Government, provides a more in depth overview of common system development process models, used to guide the analysis, design, development, and maintenance of information systems. There are many different methods and techniques used to direct the life cycle of a software development project and most real-world models are customized adaptations of the generic models. While each model is designed for a specific purpose or reason, most have similar goals and share many common tasks. This research paper explores the similarities and differences among these various models and will also discuss how different approaches are chosen and combined to address practical situations.
Click Here to Read "A Survey of System Development Process Models"!
The Demise of the Waterfall Model is Imminent and Other Urban Myths
Rumors of the demise of the Waterfall Life-cycle Model are greatly exaggerated. ACM Queue discovered this and other disappointing indicators about current software engineering practices in a recent survey of almost 200 software professionals. These discoveries raise questions about perception versus reality with respect to the nature of software engineers, software engineering practice, and the industry. (5 pages)
Click Here to Read "The Demise of the Waterfall Model is Imminent and Other Urban Myths"!
Defining Short and Usable Software Processes
Many processes and procedures are large or difficult to use. The situation becomes even worse when complexity is involved. This article by Tim Olson describes best practices for defining short and usable processes and procedures. These best practices have been used at real organizations over the last few years to define short and usable processes and procedures. Measurable results include cutting organizational processes and procedures in half while making them more usable.The objectives of this article are to describe common problems with process documentation, including some human aspects of using process documents, discuss some best practices for defining short and usable processes and procedures, describe some success stories in real organizations, and provide some lessons learned. (10 pages)
Click Here to Read "Defining Short and Usable Software Processes"!
How to Define Short and Usable CMMI Based Processes
This slide presentation by Tim Olson describes common problems with process documentation and presents best practices for improving such documentation. Real industry examples and lessons learned are included. (36 pages)
Click Here to Read "How to Define Short and Usable CMMI Based Processes"!
A Software Process Framework for the SEI Capability Maturity Model
Many organizations have started down the path of software process improvement by conducting a software process assessment and then responding with action plans to address the assessment findings. However, many organizations find themselves struggling to develop software processes that are consistent with the CMM. This document by Tim Olson attempts to address part of this implementation barrier. (959 pages)
Click Here to Read "A Software Process Framework for the SEI Capability Maturity Model"!
A Multi-Disciplinary View on Software Release Decisions
A relatively unexplored area in the field of software management is the process for determining whether or not a software product can be transferred from its development phase to operational use. Many software manufacturers have difficulty in determining the right moment to release their software products. It is a trade-off between an early release, to capture the benefits of an earlier market introduction, and the deferral of product release, to enhance functionality, or improve quality. In this article by Dr. Hans Sassenburg, project software release decisions are researched from both a theoretical as well as an empirical "case study" point of view. In the end, a methodology is proposed for improving strategic software release decisions. (7 pages)
Click Here to Read "A Multi-Disciplinary View on Software Release Decisions"!
The NPVI Method to Support Market Entry Strategies for Software
Market entry strategies deal with the complex trade-off between economising on time-to-market and economising on product maturity. How much testing is required? What are the expected cash inflows and cash outflows if the product is released? What is the market window? Based on product life-cycle models frequently used in the semiconductor industry, a method was defined using one of the most commonly used capital budgeting methods: NPV. This method takes into account the discounted value of money, and can be used to calculate the difference between two alternatives in one single variable. This variable, the NPV Incentive (NPVI), is calculated from various underlying metrics and measures the economic incentive to favour one alternative over another. Practical use of the method requires the ability to determine the values of the underlying metrics with significant certainty. It should be the objective for decision-makers to search for a zone of cost effectiveness: a bandwidth in which the marginal net asset value of additional information is equal or close to zero. Author: Dr. Hans Sassenburg, SEI Europe. (12 pages)
Click Here to Read "The NPVI Method to Support Market Entry Strategies for Software"!
16 Best Practices for Software Development Projects
Most software projects fail. In fact, the Standish Group reports that over 80% of projects are unsuccessful either because they are over budget, late, missing function, or a combination. Moreover, 30% of software projects are so poorly executed that they are canceled before completion. In this article published through IBM, the authors seek to address this probelm by summarizing 16 top best practices for software development projects. (4 pages)
Click Here to Read "16 Best Practices for Software Development Projects"!
Latent Defect Estimation with CRM
Defect removal and defect prevention techniques are no longer good enough to inspire customer confidence in the quality of delivered software products. In this article Joe Schofield describes the "business case" for removing defects and demonstrates how the usage of the Capture-Recapture Method (CRM) in defect removal activities can predict the number of estimated defects remaining in a product. This estimate can then be used to predict quantified, data-driven decisions for how to proceed with a software product. (6 pages)
Click Here to Read "Latent Defect Estimation with CRM"!
Using Peer Review Data to Manage Defects
Peer reviews and software inspections, have become accepted within the software industry as a cost effective way of removing defects. In this article Steven Lett discusses how project managers can maximize the benefits derived from collecting and analyzing project related defect data. Steven describes how peer review data can be utilized for managing software defects in much the same way cost and schedule data are used to manage project commitments. (6 pages)
Click Here to Read "Using Peer Review Data to Manage Defects"!
Myths and Strategies of Defect Causal Analysis
The popular process improvement approaches (e.g., Six Sigma, CMMI and Lean) all incorporate causal analysis activities. In this article David Card explores some of the common misunderstanding associated with the concept of causality and suggests some strategies for applying causal analysis more effectively. David explains how organizations can benefit by gaining a better understanding of the concepts of causality and developing a strategy for applying casual analysis. (6 pages)
Click Here to Read "Myths and Strategies of Defect Causal Analysis"!
Software Reuse and Commercial Off-the-Shelf Software
Organizations faced with the difficulties and costs associated with the development of software have turned to the reuse of existing software or using commercial off-the-shelf (COTS) software as an option. This article by Dan Galorath discusses some of the key issues to consider when reusing software or integrating COTS software. (8 pages)
Click Here to Read "Software Reuse and Commercial Off-the-Shelf Software"!
What Engineering Has in Common with Manufacturing and Why it Matters
Software engineering is more like manufacturing than most people expect. Once we spot their similarities, we can apply the lessons learned over the last 50 years in manufacturing to software development. This article by Dr. Alistair Cockburn picks six lessons to apply to software development gleaned from the manufacturing industry. (9 pages)
Click Here to Read "What Engineering Has in Common with Manufacturing and Why it Matters"!
The End of Software Engineering
"Software engineering" was introduced as a model for the field of software development in 1968. This paper by Alistair Cockburn reconsiders that model in the light of four decades of experience, and finds it lacking in its ability to explain project success and failures, predict important issues in running projects, and help practitioners formulate effective strategies on the fly. (24 pages)
Click Here to Read "The End of Software Engineering"!
He Wrote the Book on Debugging
From the Business Week interview with Watts Humphrey from May of 2005: "Outside of the software world, few know of Watts S. Humphrey. But within, he's a bit of a rock star, known as the "father of software quality." Now a fellow of Carnegie Mellon University's Software Engineering Institute, Humphrey developed the SEI Capability Maturity Model (CMM), which helps developers produce error-free software code efficiently and on schedule." (4 pages)
Click Here to Read "He Wrote the Book on Debugging"!
Watts Humphrey: The Changing World of Software
Since the early days of software development, our industry has been the outstanding example of poor performance. Even today, few expect software to be delivered on time and, when the products finally arrive, they often have lots of defects. How long will customers to tolerate such performance? There are two parts to the answer. First, can anyone do better? And second, will the defects cause damage? Clearly, if no one does better work and if the customers do not suffer intolerable pain, the software marketplace could continue much as today. A closer look, however, shows that our world must change. (3 pages)
Click Here to Read "Watts Humphrey: The Changing World of Software"!
Suitable Development Processes
If you ask computer users for their assessment of software, most are dissatisfied. Software is seen as inconvenient, slow and plagued with errors. The aim of this article by Dr. Erich Meier of Method Park Software is to bring together tried-and-tested measures for counteracting this phenomenon. In so doing, both process standards and reference models such as CMMI and SPICE™ will be analyzed, as will agile methods. (6 pages)
Click Here to Read "Suitable Development Processes"!
DACS State-of-the-Art Report on Software Process Improvement
The purpose of this software process improvement (SPI) State-of-the-Art Report is to provide more insight into the details necessary to demonstrate (from a business, profit and loss, and senior management perspective) the benefits of improved software management using software process improvement techniques. Although the report is primarily focused on the process and cost benefits that can be achieved by means of a software process improvement (SPI) program, the report examines some of the more secondary software process improvement benefits as well. Ultimately, the purpose of the article is to enable software professionals to compare and analyze software process improvement (SPI) methods for the purposes of presentation to senior management. The paper concludes with an extensively annotated bibliography. (44 pages)
Click Here to Read "DACS State-of-the-Art Report on Software Process Improvement"!
Return on Investment from Software Process Improvement as Measured by US Industry
LOGOS performed research, under U.S. Air Force sponsorship, to provide U.S. industry with data on the positive, quantifiable benefits, or ROI, for software process improvement programs based on the Software Engineering Institute's (SEI) Capability Maturity Model for software (CMM). This article by Judith G. Brodman and Donna L. Johnson of LOGOS International describes the research results, which include a profile of software metrics usage according to software maturity level (Levels 1 through 5), the organizational factors that contribute to higher and lower software process maturity, trends in the length of time spent by U.S. industry at each software maturity level, and a summary of the software process improvement ROI data that U.S. industry has amassed to date. (13 pages)
Click Here to Read "Return on Investment from Software Process Improvement as Measured by US Industry"!
Knowledge Management and Process Improvement: A Union of Two Disciplines
Process improvement helps an organization increase its effectiveness through continuous examination with a view to doing things better. Once processes are documented, roles and responsibilities are readily identified, associated activities are performed, and legacy processes are modified to reflect organizational changes. Knowledge management, in turn, facilitates communication among organizations, increasing information sharing and utilizing process documentation. This article by Gregory D. Burke of the FAA and William H. Howard of Northrop Grumman Mission Systems explores the experiences of the Federal Aviation Administration with process improvement and knowledge management and shows just how complementary these two disciplines really are. (9 pages)
Click Here to Read "Knowledge Management and Process Improvement: A Union of Two Disciplines"!
An Introduction to Software Process Improvement
This document is taken from the Software Engineering Institute's (SEI) educational materials package "Lecture Notes on Software Process Improvement" by Laurie Honour Werth. It begins with a history of the Software Engineering Institute (SEI) and its software process work. Terminology is introduced and the five levels of the Software Engineering Institute's (SEI) Capability Maturity Model (CMM) are defined. Possible uses and future directions of the capability maturity model (CMM) are provided. (11 pages)
Click Here to Read "An Introduction to Software Process Improvement"!
The Schedules, Costs, and Value of Software Process Improvement: A Capers Jones Report
The topic of software process improvement is now very popular in the United States, Europe, and the Pacific Rim. There are many local chapters of the well-known software process improvement network or SPIN. Unfortunately the popularity of a topic is not commensurate with the quantitative data that is available about a topic. In the case of software process improvement, there is a severe shortage of information on the schedules, costs, and results of moving from marginal to superior software development performance. This report from August of 2005 by Capers Jones shows a 36 month software process improvement case study derived from several of SPR's clients to illustrate four tangible aspects of software process improvement: 1) what it costs to achieve software excellence; 2) how long it will take to achieve software excellence; 3) what kind of value will result from achieving software excellence; and 4) what kinds of quality, schedule, and productivity levels can be achieved. (30 pages)
Click Here to Read "The Schedules, Costs, and Value of Software Process Improvement"!
Benefits of CMM-Based Software Process Improvement: Initial Results
This report by the Software Engineering Institute (SEI) Joint Program Office from 1994 is intended to provide the reader with the initial results of the effects of software process improvement efforts on organizations. It is intended primarily for software practitioners, members of software engineering process groups, and software managers interested in understanding the business case for investing in software process improvement. (64 pages)
Click Here to Read "Benefits of CMM-Based Software Process Improvement: Initial Results"!
Accumulating the Body of Evidence for The Payoff of Software Process Improvement
Many companies in many different business sectors are reporting successful software process improvement (SPI) programs. They report return on investment (ROI) figures between 5 to 1 and 9 to 1. This article by Dr. Herb Krasner of the University of Texas at Austin summarizes software process improvement (SPI) programs which have emerged in recent years while also exploring software process improvement case studies, ROI payoff data across business sectors, and other measures of software process improvement payoff. Dr. Krasner's article provides an outstanding introduction to the topic of software process improvement (SPI) and is rich with data as well as bibliographic references (18 pages)
Click Here to Read "Accumulating the Body of Evidence for The Payoff of Software Process Improvement"!
Ten Software Process Improvement Traps to Avoid
More organizations are looking at software process improvement (SPI) as a way to improve the quality, productivity, and predictability of their software development, acquisition, and software maintenance efforts. However, software process improvement efforts can be derailed in many ways. This paper by Dr. Karl E. Wiegers describes ten common traps that can undermine a software process improvement program. Learning about these software process improvement killers- and their symptoms and solutions- will help you prevent them from bringing your software process improvement initiative to its knees. (9 pages)
Click Here to Read "Ten Software Process Improvement Traps to Avoid"!
The Three Dimensions of Process Improvement - Part 1
This is the first part of a three-part article by Watts Humphrey on methods of software process improvement that were developed at the Software Engineering Institute (SEI): the Capability Maturity Model (CMM) for software, the Personal Software Process (PSP), and the Team Software Process (TSP). The Capability Maturity Model (CMM) provides an overall framework to describe the activities software organizations need to do to consistently produce effective results; the Personal Software Process (PSP) helps engineers use software process principles in their personal work; the Team Software Process (TSP) shows integrated product teams how to use software processes to consistently produce quality products on aggressive schedules and for their planned costs. Each software process method provides important benefits. Software organizations will get the best results by using all three. (7 pages)
Click Here to Read "The Three Dimensions of Process Improvement - Part 1"!
The Three Dimensions of Process Improvement - Part 2
Part I of this article by Watts Humphrey described the Capability Maturity Model (CMM), why it was developed, and how it can help organizations improve their performance. Part II addresses the Personal Software Process (PSP), which shows engineers how to perform their tasks in an effective and professional way. In the final analysis, to have high-performance software organizations, you must have high-performance software engineers working on high-performance software teams. The objective of the Personal Software Process (PSP) is to show software engineers how to use software process principles in their work. Part III of this article describes the Team Software Process (TSP), which shows integrated product teams how to consistently produce quality products under aggressive schedules and for their planned costs. (9 pages)
Click Here to Read "The Three Dimensions of Process Improvement - Part 2"!
The Three Dimensions of Process Improvement - Part 3
Part I of this article by Watts Humphrey described the Capability Maturity Model (CMM), and Part II addressed the Personal Software Process (PSP). The Capability Maturity Model (CMM) provides an overall framework that has helped many organizations improve their performance and the Personal Software Process (PSP) shows engineers how to use software process principles in doing their personal work. Part III describes the Team Software Process (TSP), which shows integrated product teams how to use these software processes to consistently produce quality products on aggressive schedules and for their planned costs. (8 pages)
Click Here to Read "The Three Dimensions of Process Improvement - Part 3"!
The Business of Software Improvement
The return on investment in improved software practices is well documented. Nevertheless, the software process improvement ROI figures found in published literature are based on operational savings; that is, on reducing development cost per line of code written or per function point delivered. Although these savings are impressive, this article by Steve McConnell argues that the greater business benefit might arise from the significant indirect returns that arise from improved software practices. Better software practices improve predictability of costs and schedules, reduce risk of cost and schedule overruns, provide early warning of problems, and support better management. For a software products company, what would be the business value of improving schedule estimation accuracy from plus or minus 100 percent to plus or minus 10 percent? What would be the value of being able to make a commitment to customers six to 12 months in advance of a scheduled completion date, with high confidence of delivering on that commitment? (4 pages)
Click Here to Read the Article!
A CAI State of the Practice Interview with Capers Jones
Capers Jones is Chief Scientist Emeritus of Software Productivity Research (SPR). Mr. Jones is the designer of several software cost and software quality estimation tools including SPQR/20™, the first commercial software estimating tool to use function points as the basis for sizing software source code, software specifications, and software user documents. He is also an international consultant on software management topics, a speaker, a seminar leader, and an author. As an author, Mr. Jones has written 12 books including his best seller Applied Software Measurement: Assuring Productivity and Quality. His most recent book is Software Assessments, Benchmarks, and Best Practices published by Addison Wesley Longman in 2000. Our interview with Capers Jones and Michael Milutis, Executive Director of the IT Metrics and Productivity Institute (ITMPI), was conducted in July of 2005.
Click Here for the Interview with Capers Jones!
A CAI State of the Practice Interview with Dr. Herb Krasner, University of Texas at Austin
Dr. Herb Krasner is a senior faculty member at the University of Texas at Austin, and the Director of the Software Engineering Industry Affiliates Program. He is also a successful software excellence consultant and President of Krasner Consulting. His personal mission, spanning several decades, has been to enable the development of superior software, and to stamp out poor quality software, wherever found. He is best known for his leading edge work on modeling the costs of software quality, reporting the ROI data for software process improvement, coaching organizational software improvement programs and reporting the results from his empirical studies of professional programmers. He has published over 55 papers, articles and book sections, has spoken at many professional conferences and meetings, and is active in professional organizations and societies. Our interview with Herb Krasner and Michael Milutis, Executive Director of the IT Metrics and Productivity Institute (ITMPI), took place in June of 2005.
Click Here for the Interview with Dr. Herb Krasner!
A CAI State of the Practice Interview with Dr. Victor Basili, University of Maryland
Dr. Victor Basili is Professor of Computer Science at the University of Maryland. He holds a Ph.D. in Computer Science from the University of Texas and honorary degrees from the Universities of Sannio (Italy) and Kaiserslautern (Germany). He was Executive Director of the Fraunhofer Center - Maryland and a founder and principal of the Software Engineering Laboratory (SEL) at NASA/GSFC. He works on measuring, evaluating, and improving the software development process and product via mechanisms for observing and evolving knowledge through empirical research, e.g., the Goal/Question /Metric Approach, The Quality Improvement Paradigm, the Experience Factory. He is a recipient several awards including a NASA Group Achievement Award, a NASA/GSFC Productivity Improvement and Quality Enhancement Award, the 1997 Award for Outstanding Achievement in Mathematics and Computer Science by the Washington Academy of Sciences, the 2000 Outstanding Research Award from ACM SIGSOFT and the 2003 Harlan Mills Award from the IEEE Computer Society. Dr. Basili has authored over 200 papers, served as Editor-in-Chief of several journals (IEEE TSE, Journal of Empirical Software Engineering) and program chair and general chair of several conferences (ICSE). He is an IEEE and ACM Fellow. Our interview between Dr. Victor Basili and Michael Milutis, Executive Director of the IT Metrics and Productivity Institute, was conducted in October of 2006.
Click Here for the Interview with Dr. Victor Basili!
Lecture of Dr. Victor R. Basili for the confirmation of the Laurea Honoris Causa in Ingeneria Informatica, University of Sannio
This wonderfully entertaining and informative lecture by Dr. Vic Basili, Director of the Frauenhofer Center for Experimental Software Engineering at the University of Maryland, chronicles the 30 year software engineering career of Dr. Basili. Along way, Dr. Basili discusses his experiences with NASA and the Software Engineering Laboratory and explains how the field of experimental software engineering began and got to where it is today. (16 pages)
Click Here to Read the Lecture of Dr. Victor R. Basili!
The Value of Software Process Improvements
This report by Capers Jones shows a 36 month case study that illustrates four tangible aspects of software process improvement: 1) What it costs to achieve software excellence; 2) How long it will take to achieve excellence; 3) What kind of value will result from achieving software excellence; and 4) What kinds of quality, schedule, and productivity levels can be achieved? (30 pages)
Click Here to Read "The Value of Software Process Improvements"!
A CAI State of the Practice Interview with Larry Dribin
Dr. Larry Dribin is Director of Chicago's Software Process Improvement Network (C-SPIN). In his private consulting work, Dr. Dribin assists clients with IT process improvement, service level agreement construction, and IT/business measurement. Dr. Dribin also makes extensive use of the SEI's CMM for software and has developed extensions to the CMM for commercial IT organizations. Dr. Dribin holds a Ph.D. in Organizational Psychology from the Illinois Institute of Technology, an MBA in Marketing from Loyola University of Chicago and a Bachelor of Science in Industrial Engineering from Illinois Institute of Technology. He is a member of ACM, CQAA - where he is Director of Research and the IEEE. Our interview between Larry Dribin and Michael Milutis, Executive Director of the IT Metrics and Productivity Institute, took place in November of 2006.
Click Here for the Interview with Larry Dribin!
Positive and Negative Innovations in Software Engineering
There are two kinds of innovations that are important to the software world: product innovations and process innovations. Nevertheless, innovations can either be positive or negative. This article by Capers Jones puts forth the hypothesis that the shortage of positive innovation in our industry is due to a lack of understanding of the underlying problems within the software development domain. (13 pages)
Click Here to Read "Positive and Negative Innovations in Software Engineering"!
Improved Performance Follows Process Improvement
Improved performance in software development can be achieved by investing in best software development practices. In this article from the March issue of the DACS Software Tech News, David Garmus and Stasia Iwanicki discuss how one organization identified improvements by using a combination of quantitative measures and qualitative values. (4 pages) This article was originally published in the Software Tech News, Volume 10, No. 1, March 2007.
Click Here to Read "Improved Performance Follows Process Improvement"!
A CAI State of the Practice Interview with Patrick O'Toole
Pat O'Toole is the Principal Consultant at Process Assessment, Consulting & Training (PACT) where he provides a full range of services to his process improvement clients. Pat is one of the most active CMMI lead appraisers, and has led appraisals spanning all maturity levels, including one of the largest and most complex CMM Level 5 assessment conducted to date. He is an SEI authorized instructor for the "Intro to CMMI" course who has taught this course more than 40 times in 6 countries. Pat is a Visiting Scientist at the SEI, and teaches the "Intermediate Concepts of CMMI" course on their behalf. Our interview between Patrick O'Toole and Michael Milutis, Executive Director of the IT Metrics and Productivity Institute, was conducted in February of 2007.
Click Here for the Interview with Patrick O'Toole!
Implementing an Organizational Software Process Improvement Program
Organizations must be prepared to accomplish key activities when implementing a software engineering process program. Beth Layman, in her article, focuses on describing the "meta-process" that allows an organization to create, use, and improve a set of documented processes that guide software development and maintenance activities. She outlines steps that are complementary to various process improvement paradigms and frameworks. (10 pages)
Click Here to Read "Implementing an Organizational Software Process Improvement Program"!
Software Development Program Characteristics
Typically, very few software development projects in large organizations are delivered in time and within budget. Pekka Forselius in his article introduces Seven Information and Communication Technology (ICT) project types and a method for analyzing the characteristics of an ICT development program. At the end of his article is a brief experience report. (7 pages)
Click Here to Read "Software Development Program Characteristics"!
ICT Project Success with Scope Management
With two thirds of the world's Information and Communication Technology (ICT) projects deemed as failures, it seems that managing scope is not a common practice within Project Management. Pekka Forselius and Carol Dekkers recommend approaches and tips successfully applied worldwide that have dramatically increased the success rate on ICT projects. (9 pages)
Click Here to Read "ICT Project Success with Scope Management"!
Eye on the Prize
Why are your projects being so difficult and how can your process group achieve maturity level 2 if the projects don't get with the program? Why aren't the projects helping you to achieve success? In this article by Patrick O'Toole, the first in a seven part series on "Do's and Don'ts of Process Improvement," the author answers these questions and more. (2 pages)
Click Here to Read "Eye on the Prize"!
Do: Establish the Alignment Principle
Okay, so what is the higher-level business strategy? And how do you define project success? And what do you do with senior management's directive to "achieve maturity level 2"? Patrick O'Toole, Visiting Scientist at the SEI, addresses these questions in this article, the second in a series of seven covering "Do's and Dont's of Process Improvement." (2 pages)
Click Here to Read "Do: Establish the Alignment Principle"!
Positive & Negative Engineering Innovations
This article by Capers Jones puts forth the hypothesis that the main reason for the shortage of positive innovation in software development methods is due to a lack of understanding of the underlying problems of the software development domain. A corollary hypothesis is that lack of understanding of the problems is due to inadequate measurement of quality, productivity, costs, and the factors that affect project outcomes. (5 pages)
Click Here to Read "Positive & Negative Engineering Innovations"!
Shedules, Costs, & Value of Software Process Improvements
The topic of software process improvement is now very popular in the United States, Europe, and the Pacific Rim. Unfortunately the popularity of a topic is not commensurate with the quantitative data that is available about a topic. This report shows a 36 month case study derived from several of SPR"s clients to illustrate four tangible aspects of software process improvement: 1) What it costs to achieve software excellence; 2) How long it will take to achieve excellence; 3) What kind of value will result from achieving software excellence; 4) What kinds of quality, schedule, and productivity levels can be achieved? (30 pages)
Click Here to Read "Schedules, Costs, & Value of Software Process Improvements"!
The Challenge of "Good Enough" Software
This article by James Bach is a slightly updated version of the the original that was published in American Programmer magazine in 1995. The author's ideas are rooted in his experiences at Apple Computer in the late 80's, and Borland in the early nineties. This article was treated as a counter-culture rant in 1995. But today, the agile development movement, which exemplifies these ideas, is well established. (11 pages)
Click Here to Read "The Challenge of "Good Enough" Software"!
Understanding and Improving Software Productivity
The goal of this article by Walt Scacchi at the Institute for Software Research at the University of California is to review a sample of empirical studies of software productivity for large-scale software systems from the 1970s through the early 2000s in order to determine what factors are impacting software productivity. (42 pages)
Click Here to Read "Understanding and Improving Software Productivity"!
Software Development Productivity
The time has come for serious efforts to increase productivity through more efficient use of labor and more effective value propositions for customers. This is how more mature economic sectors have been increasing productivity for decades. But first we need to define what we mean by productivity improvement in the software development industry. Traditionally, we have measured productivity as thousand lines of code (kloc) per labor hour. However, the key process of a development activity is the transformation ideas of into products. To measure the real productivity of software development, we need look at how efficiently and effectively we turn ideas into software. In this article by Mary Poppendieck, the author starts by formulating a new definition of software development productivity. (4 pages)
Click Here to Read "Software Development Productivity"!
Why Software is So Bad and What We Can Do to Fix It
There is something fundamentally wrong with the way we create software. Contrary to conventional wisdom, unreliability is not an essential characteristic of complex software programs. In this article by Louis Savain, the author proposes a silver bullet solution to the software reliability and productivity crisis. (15 pages)
Click Here to Read "Why Software is So Bad and What We Can Do to Fix It"!
The Business Case for Better Software Practices
Slide presentation by Steve McConnell of Construx Software that outlines the opportunity at the heart of software process improvement initiatives while providing an overview for getting started. (39 pages)
Click Here to Read "The Business Case for Better Software Practices"!
Do: Take Time Getting Faster
Disciplined planning and execution significantly reduce the variability of project results. They also establish a solid foundation for getting projects done faster, the organization's ultimate goal. Since you are unlikely to achieve sustainable cycle time reductions without first achieving reasonably predictable results, follow Steven Covey's advice and "put first things first." The EPG's challenge is to convince senior management that generating more reliable estimates is a necessary prerequisite to reducing cycle time - and that once customers believe, once estimation credibility has been established, the tune of the ritualistic dance will be altered forever. This article is the third part in an eight part series by SEI Visiting Scientist Patrick O'Toole. (2 pages)
Click Here to Read "Do: Take Time Getting Faster"!
Do: Align the Reward System
The reward system provides the most tangible evidence of what senior management wants the organization to be when it grows up. If senior management truly wants to transform the organization, they have to take a hard look at the existing reward system and ensure that it is rewarding the desired behavior, and disincentivizing the behavior they are trying to eliminate. Until they do that, their mouths and their money are misaligned. This article is the fourth part in an eight part series by SEI Visiting Scientist Patrick O'Toole. (2 pages)
Click Here to Read "Do: Align the Reward System"!
Do: Become a Learning Organization
Many organizations religiously capture "lessons identified" and then carefully place these pearls of wisdom into a seldom-accessed file cabinet or write-only database. Aldous Huxley told us, "That men do not learn very much from the lessons of history is the most important of all the lessons that history has to teach." Or as one executive put it, "I don't mind my people making stupid mistakes - that's how they learn. I would just like them to make different stupid mistakes next time!" This article is the fifth part in an eight part series by SEI Visiting Scientist Patrick O'Toole. (2 pages)
Click Here to Read "Do: Become a Learning Organization"!
Real CHAOS, Two Wrongs May Make a Right
The common view of IT is that projects are notoriously late, over budget and fail to meet customer's expectations. These outcomes are supported by the Standish Group's CHAOS long standing 1994 report. In his article Robin Goldsmith examines what is really behind the Standish Group's 'statistics' and reveals some additional 'truths' about the state of IT. Most projects' schedules and budgets are not well founded to begin with so the issue of being late or over budget is not as critical an issue as learning what really causes projects to fail. (7 pages)
Click Here to Read "Real CHAOS, Two Wrongs May Make a Right"!
Low Overhead REAL Software Process Improvement
Low-overhead software process improvement initiatives can offer significant benefits compared with the more formal branded initiatives. In this article Robin Goldsmith reveals the key to identifying the 'low hanging fruit' improvement issues. Short cut approaches provide benefits by forgoing analysis and effectively and efficiently implementing known best practices. (9 pages)
Click Here to Read "Low Overhead REAL Software Process Improvement"!
The Many Dimensions of the Software Process
The software process is a becoming a big issue for companies that produce software. As a consequence, the software process is becoming more and more important for permanent employees, long-term practitioners, and short-term consultant in the software industry. Read more in this article from the ACM by Sebastian Tyrrell. (11 pages)
Click Here to Read "The Many Dimensions of the Software Process"!
Future Directions in Process Improvement
As systems become larger and more complex, and as increasing numbers of development programs are integrated and distributed, development processes, methods, and management must change. To keep pace with these changes, the directions of process improvement must also change. This article by Watts Humphrey, James Over, Michael Konrad, and William Peterson describes the likely future directions of process improvement evolution. (11 pages)
Click Here to Read "Future Directions in Process Improvement"!
How to Develop Software Like You Are Commanding a Tank
In "Sources of Power," Gary Klein describes his research of variations in understanding orders among commanders and tank platoon leaders, reaching conclusions that giving answers to what and how does not prepare individual teams for reacting to unforeseen problems. In this article by Gojko Adzic, the author explains how this relates to software, too. (4 pages)
Click Here to Read "How to Develop Software Like You Are Commanding a Tank"!
Ask Different Questions
"Executive questions" provide insight into organizational priorities. It's nice that the Process Improvement Sponsor asks process-related questions in the monthly Steering Committee meeting, but what kind of questions is the senior management team asking in project reviews? What kinds of questions SHOULD the senior management team be asking? (2 pages)
Click Here to Read "Ask Different Questions"!
Alphabet Soup
Whether starting a quality initiative or an exercise program, the secrets to early success are realistic expectations, gradual buildup of capability, and perseverance. Don't overstuff everybody with the nutritional promises of alphabet soup, but prepare them for a few false starts, a few setbacks, and even a few injuries along the way. (2 pages)
Click Here to Read "Alphabet Soup"!
Firm Your Firm by Reaffirming
There are many organizations that can sustain ongoing improvement without a formal assessment to reaffirm their progress, just as there are some long-distance runners that don't feel compelled to run an annual marathon. But for most of us, it's the focus on these measurable goals that helps us sustain our discipline through the trying times. Without these checkpoints, commitment can erode and regression can occur. Read more in this 12th and final installment of Pat O'Toole's "Process Improvement Do's and Don'ts." (2 pages)
Click Here to Read "Firm Your Firm by Reaffirming"!
Software Process Improvement Handbook: A Practical Guide
Unless you can honestly say, "I am building software today as well as software can ever be built," you should always be trying to improve your personal and your team's software development and project management capabilities. This 72-page handbook addresses many issues that can help software organizations implement and sustain a successful process improvement program. Whether you're using the CMM or CMMI as a process improvement framework, or just trying to learn how to work more effectively, you'll find a wealth of pragmatic guidance and useful insights about how to steer your organization toward better productivity and quality.
Click Here to Read "Software Process Improvement Handbook: A Practical Guide"!
DO: Establish Organizational Policies, not CMM Policies
The VP of Engineering is trying to establish a process-disciplined culture in her software development organization. As a consultant, you have encouraged her to think about employing policies as a means to demonstrate her commitment to establishing, following, and improving the project management process. As a consultant to the VP, what 3 points would you recommend be documented in her organization's initial Project Management policy? (2 pages)
Click Here to Read "DO: Establish Organizational Policies, not CMM Policies"!
DO: Separate Process Documentation from Training Material
In this article by Pat O'Toole, the author differentiates between training material and process documentation. For students, training material is typically a single-use asset - they use it in the classroom and then stick it on the shelf. In contrast, process documentation should serve as a ready reference guide for the process executor. Like a preflight checklist, it should focus on the vital process elements that lower the probability that critical steps are inadvertently overlooked. (2 pages)
Click Here to Read "DO: Separate Process Documentation from Training Material"!
DO: Separate Process Documentation from Procedures
Similar to business requirements, process focuses on what you are expected to do. Analogous to implementation detail, procedures describe how you are expected to do it. This distinction is often blurred because documented processes and procedures typically include many of the same elements: purpose, roles, inputs, entry criteria, activities/steps, outputs, exit criteria, etc. The real difference between processes and procedures is found in the "degrees of freedom" provided by the documented component. (2 pages)
Click Here to Read "DO: Separate Process Documentation from Procedures"!
Time Management - Interruptions and Multi-tasking
It is a pretty crazy world out there. People are working longer hours and cramming as much as they can into their day. Unless you have taken on six full-time jobs, you might feel that you are slacking off. Taking on more work, or just trying to do more in each day, can cause you to stretch and grow. However, just cramming more tasks into a day can also lead to poor performance when your focus is totally shot with interruptions, or when numerous tasks are started and few of them are completed adequately. Chronic interruptions and multi-tasking can lead to major goals being pushed out of sight and an overall increase in stress. (3 pages)
Click Here to Read "Time Management - Interruptions and Multi-tasking "!
Doing More for Less in Software and Solutions Development
When the economy gets bumpy, it is natural to tighten budgets, make cuts and expect the organization to work harder so that more can be produced with less.
Memos and emails are sometimes used to announce to an organization that reductions in cost are needed and that any extra effort by staff will be appreciated. The impulse to send a memo is understandable and can help, but might only have a temporary impact on the organization while the "save money" request is still fresh in people's minds.
Instead, a systematic series of improvements is needed to produce more for less consistently over time. These improvements need to address inefficiencies that happen every day in projects in addition to cutting hard expenses. (3 pages)
Click Here to Read "Doing More for Less in Software and Solutions Development"!
Implementing an Improvement Program (a checklist)
Implementing an improvement program can be a nebulous and overwhelming task. There are many places one could start, and many published standards one could adopt. This article provides a summary of the steps to consider when planning and tracking an improvement program. (4 pages)
Click Here to Read "Implementing an Improvement Program (a checklist)"!
A Comparative Analysis of Process Maturity and Quality
This paper by Louis Poulin describes a method used to measure the expected quality of products and services developed by IT organizations. The approach described herein is based on a sample of 40 comprehensive appraisals conducted in South America, Europe and North America, and shows that an IT organization should focus on improving and deploying processes that exploit the opportunities it has of meeting its business objectives and prevent the potential problems to which it is exposed from occurring, and degenerating into crises. Process maturity is meaningless without having this objective in mind. (4 pages)
Click Here to Read "A Comparative Analysis of Process Maturity and Quality"!
Achieving the Right Balance Between Process Maturiy and Performance
This paper by Louis Poulin summarizes observations made in the course of 58 assessments in based on the CMMI and on its predecessor, the CMM. It stresses, among other things, the challenges faced by these organizations in optimizing ways to improve the quality of their products and services using the CMMI as a starting point.(4 pages)
Click Here to Read "Achieving the Right Balance Between Process Maturiy and Performance"!
White Paper: Improving Application Development Effectiveness
The purpose of this article by Nick Spanos of CAI is to define a strategy for improving quality and reducing effort as related to the development of software applications. (4 pages)
Click Here to Read "White Paper: Improving Application Development Effectiveness"!
White Paper: Effective Delivery of I/T Services
An effective I/T Service Delivery organization has clearly defined expectations and utilizes proactive management techniques to meet or exceed expectations and minimize costs. Performance expectations include a variety of factors such as the frequency and priority of problems, the number of completed service requests, responsiveness, lack of customer complaints, and cost-effectiveness. This article examines the challenges associated with managing expectations, measuring performance delivery, and continuously improving performance.(3 pages)
Click Here to Read "White Paper:Effective Delivery of I/T Services"!
Implementing the Plan
An Now that you have spent some time planning your improvement effort, it is time to make those plans a reality. Implementing your plan may feel overwhelming. It includes building and deploying solutions, selling ideas, and overcoming resistance. In this chapter we provide guidance on how to proceed. (14 pages)
Click Here to Read "Implementing the Plan"!
Making Significant Improvements Using Senior Management
Since 1988 we have helped companies improve their performance, quality, and cost. Over that time, there have been a few critical improvements that we have seen organizations make to accelerate change. One of these is changing how the senior manager engages with the organization. (2 pages)
Click Here to Read "Making Significant Improvements Using Senior Management"!
So, You Wanna Be a Cowboy?
The myth of the cowboy, now long separated from society, survives as a caricature of rowdy software cultures. So what attributes do programmers supposedly inherit from cowboys? (3 pages)
Click Here to Read "So, You Wanna Be a Cowboy?"!
In Search of the Missing Link Between Process and Performance
This first article explores some of the possible causes as to how the link between process and performance has become more myth than fact, more correlation than causation, and how unsubstantiated claims can seduce leaders to blindly invest in process improvement. It also addresses the clear, tangible relationships between process improvement and organizational performance, especially in IT/IS organizations. (2 pages)
Click Here to Read "In Search of the Missing Link Between Process and Performance"!
What is Process Improvement?
The first articles in this series, "In Search of the Missing Link Between Process and Performance," probed some of the more significant barriers to achieving business performance improvement through process improvement. Primarily, it explored a strategic error made by many organizations: the pursuit of the false goal. This article dives deeper into process improvement by providing information about how to think about process improvement in terms of what really is and is not process improvement. (4 pages)
Click Here to Read "What is Process Improvement?"!
Improving Performance Through Process Improvement
In the first two articles in this series, we explored the challenges faced in linking process improvement to business performance, and what it means to improve process. This article will help you begin to understand how to structure, at least qualitatively the connection between process improvement and business performance improvement. This article does not get into the math and statistics of process performance models (PPMs) or the number crunching that you would employ in statistical process control; it starts out more fundamental than that. Numbers lead to answers, but before you can seek answers you first need to know what questions to ask; this article will help you begin to form those questions. (5 pages)
Click Here to Read "Improving Performance Through Process Improvement"!
Top
CMM & CMMI
How CMM Impacts Quality, Productivity, Rework, and the Bottom Line
This article, by Michael Diaz and Jeff King of General Dynamics Decision Systems, explores various cost/benefit issues and examines performance results of various General Dynamics Decision Systems' projects with relation to software process maturity. The quantitative data presented indicates that Capability Maturity Model (CMM) based improvement has yielded dividends in terms of higher software productivity and improved software quality. (6 pages)
Click Here to Read "How CMM Impacts Quality, Productivity, Rework, and the Bottom Line"!
CMM vs CMMI: From Conventional to Modern Software Management
This article by Walker Royce, Vice President and General Manager of Strategic Services at the Rational Software Corporation, summarizes some thoughts on making the transition from conventional software management techniques to modern software management techniques. In particular, the author endorses the improvements in the Software Engineering Institute's CMMI (Capability Maturity Model Integrated) approach and seeks to motivate software development organizations to apply the CMMI approach correctly. (11 pages)
Click Here to Read "CMM vs CMMI: From Conventional to Modern Software Management"!
Getting Started with the CMMI
Although CMMI (Capability Maturity Model Integration) documentation is comprehensive, it's difficult to use. The sheer amount of documents, pages, and perceived overlap overwhelms newcomers in particular. Nevertheless, two books on the CMMI (Capability Maturity Model Integration) offer guidance to help users navigate and find what they need. This article by Christof Ebert of IEEE Software provides a succinct and pragmatic review of these two books. (3 pages)
Click Here to Read "Getting Started with the CMMI"!
Competing in the Software Industry - Will CMMI Certification Help?
Foreign software companies are touting certification in the Capability Maturity Model (CMM®) as an important competitive advantage over local firms. This article by Ed Carroll explores the question, "What should software engineers do in this difficult work environment to be competitive in the marketplace." Along the way, the author investigates the various claims of the Capability Maturity Model. (4 pages)
Click Here to Read "Competing in the Software Industry - Will CMMI Certification Help?"!
Demonstrating the Impact and Benefits of the CMMI
Serious process improvement of any kind requires a considerable investment of time and money on the part of the organizations that decide to pursue it. Capability Maturity Model® Integration (CMMI®)-based improvement is no exception, and trustworthy objective evidence about its benefits is essential for addressing a variety of concerns. Increasing numbers of organizations are considering using CMMI models but some remain skeptical about the value of any model-based process improvement. The purpose of this special report, produced by the SEI Joint Program Office in October of 2003, is two-fold: to present preliminary results about CMMI impact and to describe ongoing and future work in this area. Section 2 provides a synopsis of the case studies on which this special report is based. Section 3 follows with a brief discussion of how an organization can demonstrate the impact of CMMI-based process improvement on project performance and product quality. Section 4 presents results from a series of case studies that are publicly available and from others being conducted in collaboration with the Software Engineering Institute (SEISM). Section 5 describes other work underway at the SEI and elsewhere to provide credible evidence about the impact of process improvement based on CMMI models. Section 5 also contains a brief discussion of the limitations of the current work and plans for the future. (55 pages)
Click Here to Read "Demonstrating the Impact and Benefits of the CMMI"!
CMMI for Development
CMMI for Development is a collection of best practices that is generated from the CMMI Framework. The purpose of CMMI for Development is to help organizations improve their development and maintenance processes for both products and services. Whether you are new to process improvement, new to CMMI, or already familiar with CMMI, this publication can help you understand why CMMI for Development is the best model to use for improving your development and maintenance processes. Part one will give you an overview of process improvement and explain what CMMI is all about. Part Two will give you a feel for the scope of the best practices contained in the model. Part Three will provide a list of additional resources for following up on before moving forward with CMMI for Development. (561 pages)
Click Here to Read "CMMI for Development"!
CMMI Level 2 Within 6 Months? No Way!
Global Analytic Information Technology Services, Inc. (GAITS) decided to receive a Software Engineering Institute (SEI) Capability Maturity Model Integration (CMMI) Level 2 rating within five months. The purpose of this article by George Jackelen is to show that when an organization is already doing competent project management, the effort to benchmark that capability by using CMMI is almost straightforward, and it is possible to achieve a Level 2 CMMI appraised rating within six months. This means there must be management support, the right CMMI project personnel, selection of the right effort(s) to be evaluated, and a CMMI appraiser who understands the company's effort and provides positive feedback. (7 pages)
Click Here to Read "CMMI Level 2 Within 6 Months? No Way"!
Mapping TSP to CMMI
This report by James McHale and Daniel Wall provides an essential element to facilitate the adoption of the TSP in organizations using CMMI; namely, a mapping of ideal TSP practices into the specific and generic practices of CMMI. By having such a mapping (also known as a gap analysis), those involved with process improvement and appraisal efforts can more easily determine how well the organization or a particular project is implementing the TSP, how well projects using TSP might rate with respect to CMMI, and where and how to fill any gaps in CMMI coverage. Organizations already following an improvement plan based on CMMI may also determine how TSP adoption might help them to achieve broader, deeper, or higher maturity implementations of CMMI goals and practices. (209 pages)
Click Here to Read "Mapping TSP to CMMI"!
Accelerating Process Improvement by Integrating the TSP and the CMMI
This report by Daniel Wall, James McHale and Marsha Pomeroy-Huff describes how two U.S. Naval Air Systems Command (NAVAIR) organizations integrated the use of the Software Engineering Institute's (SEI) Team Software Process SM methodology and the Capability Maturity Modeling framework to progress from Maturity Level 1 to Maturity Level 4 in 30 months. This is less than half of the average time it has taken other organizations to accomplish the same maturity level progression. This case study describes the process improvement efforts of both NAVAIR groups and how they integrated the two SEI technologies to accelerate process improvement within their organizations. Finally, the report presents the key factors that allowed NAVAIR to achieve these rapid results. (35 pages)
Click Here to Read "Accelerating Process Improvement by Integrating the TSP and the CMMI"!
TSP Can Be the Building Blocks for CMMI
Your organization has a mandate to achieve Capability Maturity Model Integration Level 3. Why would you even consider adding the Team Software Process to your plate when it is already overflowing? In this article, Alan S. Koch will discuss how TSP — far from adding work to a CMMI initiative — can potentially reduce the time and effort that will be required to achieve your goals. Simultaneously, TSP will engage your engineers in disciplined processes, giving them an appreciation for good processes along with the desire to adopt improved processes in every area of the organization. (7 pages)
Click Here to Read "TSP Can Be the Building Blocks for CMMI"!
Profiles of Level 5 CMMI Organizations
Many firms that have achieved Level 5 using the Software Engineering Institute's Capability Maturity Model Integration (CMMI) have taken a different tack in justifying their process improvement initiative's budget. This article by Don Reifer summarizes the profiles of high maturity organizations and explains how they go about justifying their budgets. The article also provides insight into the differing tactics that these firms employ to win the battle of the budget. (5 pages)
Click Here to Read "Profiles of Level 5 CMMI Organizations"!
IMPLEMENTING SCRUM (AGILE) AND CMMI® TOGETHER
If you are a software engineer or IT professional,your group has very likely shown a strong interest in reducing costs, improving quality and productivity. Your group might also have looked at various pre-packaged frameworks, such as Agile (e.g., Scrum and Extreme Programming), CMMI 1,and Six Sigma. At first glance, each of these frameworks might look at odds with each other, making it difficult to use two or more. This typically occurs because much of the information shared regarding these frameworks is from success and failure stories,rather than understanding the specifics of each framework. Each framework can be implemented successfully depending on how much care is placed on its implementation. In this article we compare CMMI and Scrum since they are two commonly used frameworks, and ones we have seen groups struggle with when using them together. First, let us define each briefly. (5 pages)
Click Here to Read "IMPLEMENTING SCRUM (AGILE) AND CMMI® TOGETHER"!
Change Does Not Happen
Adopting the CMMI requires the organization to thoroughly plan the change when improving processes. Organizations that fail to do this are doomed to fail in their efforts. This short paper describes some tools and strategies to make change happen, based on known models. (10 pages)
Click Here to Read "Change Does Not Happen"!
Using The CMMI as an Organizational Development Model
The CMMI® (Capability Maturity Model Integration) has replaced the CMM as the de-facto standard for process quality. Many people are looking in from the outside of the CMMI community trying to gauge the value of the model. In this short paper we describe where the CMMI adds value
to the Software Development community and how to derive it. (6 pages)
Click Here to Read "Using The CMMI as an Organizational Development Model"!
Small Organizations, Small Interventions
Small organizations have very limited resources. This implies that traditional approaches to SPI will probably sink before they succeed for lack of sustaining funding. This white paper shows a proven approach to institutionalizing a managed behavior and beyond, by effecting small incremental changes that are easy to install individually but that collectively achieve most of the required specific practices at ML2. The presentation addresses a niche audience that usually has great difficulty in finding applicable processes and experiences that match their needs. In particular, small organizations, or process engineers working with small organizations; but also, organizations that cultivate individual dissonance in opposition to synchronism or democratic decisions can benefit from it. (5 pages)
Click Here to Read "Small Organizations, Small Interventions"!
Top
Agile Methods
How to Manage Project Benefits and Costs with Evolutionary (EVO) Development
The underlying principle of Evolutionary Development Methods (EVO) is the Plan-Do-Study-Act cycle. In other words, the "process control cycle" as taught by Walter Shewhart of AT&T and, by his pupils, W. Edwards Deming and Joseph Juran. In this chapter excerpt from Tom Gilb's new book "Competitive Engineering", Tom explains how Evolutionary Development Methods (EVO) expand upon the statistical process control cycle of Plan-Do-Study-Act to address the software project management challenges facing us today. It is a lucid and thorough introduction to the subject of Evolutionary Development Methods (EVO), one that covers principles, fundamental process descriptions, and practical real world examples. (30 pages)
Click Here to Read "How to Manage Project Benefits and Costs with Evolutionary (EVO) Development"!
Case Study: From Waterfall to Evolutionary (EVO) Development
Evolutionary Development Methods (EVO) focus on early delivery of high value to software project stakeholders, and on obtaining and utilizing feedback from stakeholders. This paper by Tom Gilb and Trond Johansen describes, from a software project manager's viewpoint, the positive experiences that one organization rapidly achieved when they switched from using the waterfall software development method to the Evolutionary Development Method (EVO). Major benefits came from paying greater attention to the quality of software requirements as opposed to the previous practice of concentrating solely on required software functionality. (11 pages)
Click Here to Read "Case Study: From Waterfall to Evolutionary (EVO) Development"!
A CAI State of the Practice Interview with Tom Gilb, Evolutionary Development Expert Practitioner & Author
Tom Gilb is recognized as a pioneer in software metrics and evolutionary software project management, as well as the inventor of the planning language Planguage. He is directly recognized as the idea source for parts of the Agile and Extreme software programming methods (primarily the incremental cycles). He has published nine books, including Principles of Software Engineering Management (1988, 20th printing), Software Inspection (1993, 13th printing), and Competitive Engineering: A Handbook for Systems Engineering, Requirements Engineering, and Software Engineering using Planguage, which was published in July of 2005. His software development methods are widely and officially adopted by many organizations such as IBM, Nokia, Ericsson, HP, Intel, Citigroup, Symbian, and Philips Medical. Our interview with Tom Gilb and Michael Milutis, Executive Director of the IT Metrics and Productivity Institute (ITMPI), was conducted in December of 2005.
Click Here to Read the Interview with Tom Gilb!
Iterative and Incremental Development: A Brief History
Although many view iterative and incremental development as a modern practice, its application dates as far back as the 1950s. Prominent software engineering leaders from each succeeding decade supported IID practices, and many large projects used them successfully. Find out more in this article by Vic Basili and Craig Larman. (10 pages)
Click Here to Read "Iterative and Incremental Development: A Brief History"!
Agile Processes
The professional goal of every software engineer and every development team is to deliver the highest possible value to employers and customers. And yet, projects fail at a dismaying rate. Though well intentioned, the upward spiral of process inflation is culpable for at least some of this failure. The principles and values of agile development were formed as a way to help teams break the cycle of process inflation, and to focus on simple techniques for reaching their goals. (10 pages)
Click Here to Read "Agile Processes"!
Observations on Balancing Discipline and Agility
Agile development methodologies promise higher customer satisfaction, lower defect rates, faster development times, and a solution to rapidly changing requirements. Plan driven approaches promise predictability, stability, and high assurance. However, both approaches have shortcomings that, if left unaddressed, can lead to project failure. The challenge is to balance both approaches and to take advantage of their strengths and compensate for their weakenesses. This paper, by Barry Boehm and Richard Turner, presents six observations drawn from their efforts to develop such an approach. (8 pages)
Click Here to Read "Observations on Balancing Discipline and Agility"!
An Introduction to Agile Software Development
This paper by Victor Szalvay is an introduction to the Agile school of software development, and is primarily targeted at IT Managers and CXOs with an interest in improving development productivity. The author introduces the waterfall school and compares it to various iterative methods, of which Agile is a subset. Along the way, he seeks to demonstrate the short comings of the waterfall approach while providing a solution in iterative, and more specifically, Agile methods. (11 pages)
Click Here to Read "An Introduction to Agile Software Development"!
Should You Be More Agile?
Agile software development techniques are an effective response to many of the problems that still plague development projects. Agile development has come into focus recently due to the popularity of its most widely known interpretation, eXtreme Programming, but some of its foundations go back as far as 20 years. This article by Rich Mcabe and Michael Polen of the Software Productivity Consortium addresses some of the questions about agile: What is agile? Who needs to be agile? How can any project not creating small business applications seriously consider agile development? Is agile development an "all or nothing" proposition? (6 pages)
Click Here to Read "Should You Be More Agile?"!
When to Be Agile
Not every IT project lends itself to adaptive development. We must understand when adaptive development is appropriate and when predictive development is appropriate. The same question is facing many IT professionals around the world, as adaptive development gains credibility as a mainstream software development approach. As Dave Nicollette shows in this article from 2005, the answers are easy to find, but hard to interpret. (6 pages)
Click Here to Read "When to Be Agile"!
What is Agile Software Development?
In recent years, the ideas of "agile software development," which encompasses individual methodologies such as Crystal methods, eXtreme Programming, feature-driven development, and adaptive software development, are being increasingly applied and are causing considerable debate. This article by Jim Highsmith attempts to answer the fundamental question on many people's minds: What is agile software development? (10 pages)
Click Here to Read "What is Agile Software Development?"!
Learning from Agile Software Development - Part One
Part-one of this two-part article by Alistair Cockburn compares agile, plan-driven, and cost-sensitive software development approaches based on a set of project organization principles, extracting from them ideas for pulling agile techniques into cost- and plan-driven projects. Part one describes how agile and plan-driven teams make different trade-offs of money for information or for flexibility, and presents the first seven of 10 principles for tuning a project to meet various priorities, including cost, correctness, predictability, speed, and agility. (10 pages)
Click Here to Read "Learning from Agile Software Development - Part One"!
Learning from Agile Software Development - Part Two
Part-two of this two-part article by Alistair Cockburn presents the last 3 of 10 principles for tuning a project to meet various priorities, including cost, correctness, predictability, speed, and agility. The author then pulls the material together for actions that plan-driven and cost-sensitive project teams can use to improve their strategies and hedge against surprises. (10 pages)
Click Here to Read "Learning from Agile Software Development - Part Two"!
Gartner Report: Agile Will Benefit Application Development
The flexibility with which requirements are gathered and managed shows how disciplined an agile development process is. Agile development organizations with automated requirements definition and management environments will better support change control, gain testing efficiencies and reduce future maintenance burdens. Read more in this Gartner research report from April, 2005. (4 pages)
Click Here to Read "Gartner Report: Agile Will Benefit Application Development"!
Agile Before Agile Was Cool
Success can be achieved by many means. Sometimes it is obvious which road to take, other times it does not really matter. In this article by Gordon Sleve, the author discusses his introduction to agile, his experiences in the field with it, and his final conclusions. (4 pages)
Click Here to Read "Agile Before Agile Was Cool"!
A Collection of Agile Essays
An entire website of agile essays collected by Scott Ambler. Very useful.
Click Here to Read "A Collection of Agile Essays"!
Agile and the Declaration of Interdependence
There has been recent debate over the apparent incompatibility that is thought to exist between Agile Software Development and Software Process Improvement models such as the CMMI. Michael Harris takes the position that software process improvement projects can benefit by adopting an iterative "Agile" approach. Michael discusses how adopting an agile philosophy can help software process improvement projects deliver recognizable value. (8 pages)
Click Here to Read "Agile and the Declaration of Interdependence"!
Agile CMMI: No Oxymoron
In the ongoing battle between traditional and agile methodologies, many proponents of each side exhibit a general intolerance to the other's ideas. However, this adversarial attitude is not just unreasonable, it's counterproductive to the task at hand: developing the highest-quality software in the shortest possible time. To that end, approaches must be limited by neither hidebound structuralism nor free-flowing flexibility. To the new generation of agile practitioners, the 13-year-old Capability Maturity Model (CMM) may seem to symbolize all that's stodgy in traditional development. However, the melding of Software CMM with the Carnegie Mellon University Software Engineering Institute's other main maturity models (for systems engineering, software acquisition, workforce management and product development) in the form of CMM Integration (CMMI) deserves another look. (6 pages)
Click Here to Read "Agile CMMI: No Oxymoron"!
Using an Agile Software Process with Offshore Development
For the last four years ThoughtWorks operated a lab in Bangalore India to support their software development projects in North America and Europe. Traditional approaches to offshore development are based on plan-driven methodologies, but this was very firmly an agile operation. In this article by Martin Fowler, the author discuss the experiences and lessons learned in doing offshore agile development. (14 pages)
Click Here to Read "Using an Agile Software Process with Offshore Development"!
Adopting and Benefiting from Agile Processes in Offshore Software Development
In modern software development, there are two trends that allow people to get more for less: agile development and offshore outsourcing. In this article by Andrew Filev the author looks at how and when to combine both successfully to raise the competitiveness of your business. (4 pages)
Click Here to Read "Adopting and Benefiting from Agile Processes in Offshore Software Development"!
Making Offshore Agile Work
While the cost-per-developer of offshore development might make it attractive, the benefits frequently fail to materialize. Solutions delivered by offshore teams are all too often characterized by poor solution fitness and quality problems, leading to late delivery and dissatisfied customers. Agile development practices are proven to provide better solutions, but they require a high degree of communication. Adopting them in an offshore environment presents a unique set of challenges. Find out in this article by Ross Pettit how to do it successfully. (4 pages)
Click Here to Read "Making Offshore Agile Work"!
Agile Lessons from "I Love Lucy"
An old "I Love Lucy" episode shows Lucy and Ethel working at a candy factory. Their job is to take pieces of candy off a conveyer belt and put them in packages. At first everything goes well. Then the conveyer belt sends out candy faster and faster. At first Lucy and Ethel try to cope. They try to work faster. Then their work gets sloppy. Finally, rather than packaging the candy at all, they resort to throwing it away, or even eating it. The moral, of course, is that just because you are able to make candy faster, it doesn't mean you can make more money selling more candy. How does this pertain to agile software development? (3 pages)
Click Here to Read "Agile Lessons from "I Love Lucy"!"
The Agile Organization
When successfully adopted, Agile practices create hyper-efficient application development teams capable of regular, and even aggressive, delivery of business value. While an exciting prospect for developers, there will not be much business impact if the rest of the IT organization, and indeed the business itself, can't make use of this new-found efficiency. Staffing and resource decisions need to be made efficiently, requirements captured quickly, testing and production environments instantiated, subject-matter experts made available, and business processes changed or application development agility will be wasted. The drive toward greater responsiveness involves all aspects of IT as well as business partners and corporate practices. (4 pages)
Click Here to Read "The Agile Organization"!
"Agile" vs. "agile" Development
There's no question that "agile" is the buzzword of the times for software developers, ISVs, consultants, and businesses, in general. As with most buzzwords, the term is often over-used and mis-used, especially by those trying to portray their products or services in a new light. In the world of software development, the term "agile" is applied to a wide variety of processes, techniques, tools, projects, and phases of the development life cycle. It's important, therefore, to set out some basic definitions and context for the use of the term "agile." (3 pages)
Click Here to Read ""Agile" vs. "agile" Development"!
How to Get the Most out of Extreme Programming/Agile Methods
This paper by Don Reifer reports the results of an analysis of thirty-one extreme programming (XP)/agile method early adopter projects completed by fourteen firms who have embraced the techniques in the form of lessons learned. The survey results show that early adopters have cut costs, improved productivity and reduced time to market through the use of these methods. To get the most from these methods, fifteen lessons learned have been developed that build on the experiences of others. Several of these lessons run counter to the teachings of the methodology developers. The paper next provides a scorecard that rates XP's performance in eight application domains. The paper concludes by summarizing four critical success factors for early adopters. (11 pages)
Click Here to Read "How to Get the Most out of Extreme Programming/Agile Methods"!
Retrospectives with Large and Distributed Teams: Part 1
You will only follow an agile approach if you have retrospectives in place. We have to question an (agile) process if it is to serve the individuals and their interactions. By "retrospectives" we mean "regular reflection sessions". Retrospectives are a means to establish and preserve the agile value system, by allowing the team to shape the process in such a way that the process supports the team the best. This is the first of a three part series by Jutta Eckstein. (2 pages)
Click Here to Read "Retrospectives with Large and Distributed Teams: Part 1"!
Retrospectives with Large and Distributed Teams: Part 2
In this article by Jutta Eckstein, part 2 in a series, Jutta discusses the importance of individual feature team retrospectives, joint project team retrospectives, and joint site retrospectives. (3 pages)
Click Here to Read "Retrospectives with Large and Distributed Teams: Part 2"!
Retrospectives with Large and Distributed Teams: Part 3
In this article by Jutta Eckstein, part 3 in a series, Jutta discusses how to best conduct 'virtual' retrospectives. (2 pages)
Click Here to Read "Retrospectives with Large and Distributed Teams: Part 3"!
Top
Six Sigma IT
Software Development Convergence: Six Sigma - Lean - Agile
With common messages beginning to emerge from several software relevant areas - Six Sigma for software, Agile software development, and Lean thinking- the various links between Design for Six Sigma (DFSS) and Agile software development have received a lot of recent attention. Nevertheless, this article by David Hallowell, founding partner of Six Sigma Advantage and Master Six Sigma Black Belt, provides a broader view that can illustrate the way Lean thinking aligns well with both Agile software development and software Six Sigma. (4 pages)
Click Here to Read "Software Development Convergence: Six Sigma - Lean - Agile"!
Six Sigma and the Project Management Body of Knowledge
Interest in Six Sigma is growing rapidly within the professional project management community. Consequently, the most common question coming from this group is "How does Six Sigma relate to the Project Management Body of Knowledge (PMBoK)?" In this article by Gary Gack, managing partner of Six Sigma Advantage and Master Six Sigma Black Belt, you'll find the answer. (4 pages)
Click Here to Read "Six Sigma and the Project Management Body of Knowledge"!
Connecting Six Sigma to CMMI Measurement and Analysis
Measurement and analysis (MA) is a Level 2 software support process area within the Capability Maturity Model Integration (CMMI) process. Its purpose is to provide to management the information necessary to monitor and control various required software processes. As with other software process areas of the Capability Maturity Model Integration (CMMI), the emphasis is on what should be done, not how to do it. In this article by Gary Gack of Six Sigma Advantage, the author explains that this is exactly where Six Sigma makes a strong connection to measurement and analysis (MA), and to some of the other process areas, too. (5 pages)
Click Here to Read "Connecting Six Sigma to CMMI Measurement and Analysis"!
A CAI State of the Practice Interview with Gary Gack, CEO of Six Sigma Advantage
Gary Gack has over 40 years experience in the software and IT industry with extensive large-scale software project and software program management, including teams with over 200 software developers. He has owned and managed several software/consulting businesses, and has extensive experience with software process assessments using the SEI/CMM (Capability Maturity Model), ISO 15504 ("Spice"), and various proprietary methods. Gary is the author of numerous articles dealing with software project management, software process improvement, cost accounting and software metrics, and software quality assurance and he has also co-authored many Six Sigma training programs tailored to software and technology audiences. Gary Gack is currently the CEO of Six Sigma Advantage. Our interview between Gary Gack and Michael Milutis, Executive Director of the IT Metrics and Productivity Institute (ITMPI), took place in August of 2005.
Click Here to Read the Interview with Gary Gack!
Six Sigma Applies to IT, As Evidenced by Success
This article by Gary Gack recaps some of the successes that have been achieved with Six Sigma in IT while describing some of the IT activities to which Six Sigma can specifically be applied. (4 pages)
Click Here to Read "Six Sigma Applies to IT, As Evidenced by Success"!
Applying Six Sigma to Software Implementation Projects
Six Sigma can be applied to software implementation projects as well as software development. In this article by Gary Gack, two software project scenarios that feature common pain points are used to provide examples of how Six Sigma can address software implementation issues. (4 pages)
Click Here to Read "Applying Six Sigma to Software Implementation Projects"!
All Together Now: CMM, CRM, ERP, and Six Sigma
While Six Sigma is clearly an alternative to broad-based quality initiatives such as Total Quality Management, proponents say it works just fine with extant project management software, CRM, Balanced Scorecard and other operational and valuation methodologies if those methods and measures are customer-centric. This article from CIO Magazine elaborates. (1 page)
Click Here to Read "All Together Now: CMM, CRM, ERP, and Six Sigma"!
Six Sigma and CMM
Six Sigma has been successfully used within many diverse industries. While Six Sigma philosophy and technique came out of manufacturing environments, it also has been used in projects that span the entire functional organization. A reasonable question therefore is whether Six Sigma is adaptable for software development and maintenance.
Software manufacturing deals with the duplication, packaging and distribution of software. While software firms should take sufficient care to ensure the quality of these operations, it is really the software development process (software requirements through software quality assurance) that is the source of concern.
While there are many parallels between manufacturing and software development, there are many differences as well. Consequently, one is not surprised that the software industry has come up with its own methodologies and tool sets. This article by Jack Horgan of EDA Weekly attempts to compare and contrast. (12 pages)
Click Here to Read "Six Sigma and CMM"!
Combining CMMI, PSP, TSP, and Six Sigma for Software
Personal Software Process (PSP) and Team Software Process (TSP) are software process definitions that are compatible with a wide range of software development concepts such as spiral software development, object oriented software development, and various other sets of software development techniques, each with certain advantages in modeling software requirements and designs. Six Sigma for Software, on the other hand, is not a software development process definition; rather, it is a far more generalized concept for improving software processes and products.
Personal Software Process (PSP), Team Software Process (TSP), and also Capability Maturity Model (CMM) are several potential choices for software development process definitions that can lead to improved software project performance. However, the full potential of the data produced by these software processes cannot be fully leveraged without applying the more comprehensive Six Sigma for Software toolkit. This article by Gary Gack of Six Sigma Advantage explains why. (5 pages)
Click Here to Read "Combining CMMI, PSP, TSP, and Six Sigma for Software"!
Six Sigma Software Metrics - Part 1
Six Sigma brings sharp focus to customer and business requirements as well as the defects associated with the failure to satisfy these requirements. While the relevance of this is clear enough to most software professionals, most software professionals stop short when attempting to figure out how notions of yield, sigma level, or defects per million opportunities (DPMO) fit their world. This article on six sigma software metrics is the first in a four part series by Dave Hallowell of Six Sigma Advantage. (6 pages)
Click Here to Read "Six Sigma Software Metrics - Part 1"!
Six Sigma Software Metrics - Part 2
Part 1 in this series on six sigma software metrics focused on the goal of identifying and removing defects in the software development process as close to the point of occurrence as possible. This second installment by Dave Hallowell of Six Sigma Advantage examines the prediction of software defect insertion and removal dynamics as well as the assessment of actual software defect find rates. (7 pages)
Click Here to Read "Six Sigma Software Metrics - Part 2"!
More on Six Sigma Software Metrics
Parts one and two of this four part series on six sigma software metrics (by Dave Hallowell of Six Sigma Advantage) surveyed the work connected with several goals shared by software organizations and Six Sigma. He explains how reaching those goals involves establishing systems to identify software defects, classify them according to type and point of origin, predict their occurrence, and assess actual defect find rates during software development. Until an organization achieves goals 1-3 and derives the business benefits associated with reduced software defect repair costs, it probably isn't ready to delve into the ins and outs of Defects per Unit (DPU), Defects per Million Opportunities (DPMO), and Sigma levels. Once goals 1-3 are achieved, however, the organization is prepared to tackle those Six Sigma concepts, understand how they work, and determine where they apply within the software development environment. This article, which represents part three in Dave's series, explores goals four and five. (6 pages)
Click Here to Read "More on Six Sigma Software Metrics"!
Six Sigma Software Metrics - Final Installment
This article is the last in a four part series on six sigma software metrics by Dave Hallowell of Six Sigma Advantage. It presents a discussion of Opportunities For Defects (OFD), Defects Per Million Opportunities (DPMO) and Sigma levels. When comparing implementations across companies, the common language of Defects per Million Opportunities (DPMO) and Sigma levels will assist in understanding benchmarking data. Parts one, two and three followed a progression of goals shared by both software development and Six Sigma: 1) reducing released software defects; 2) finding and fixing software defects closer to their point of origin; 3) predicting and tracking software defect appearance and removal rates and repair costs; 4) comparing implementations within the company; and 5) comparing implementations across companies. (6 pages)
Click Here to Read "Six Sigma Software Metrics - Final Installment"!
Integrating ITIL and Lean Six Sigma
As the awareness and penetration of Lean Six Sigma has increased significantly over the last several years, many organizations struggle to understand and leverage the relationships between Lean Six Sigma and several other approaches to software process improvement, including ITIL®, CMMI®, PMBoK®, and others. Gary Gack answers the most frequently asked questions. (12 pages)
Click Here to Read "Integrating ITIL and Lean Six Sigma"!
Applying Six Sigma to Software Implementation Projects
This article, by Gary Gack, focuses on applications of Lean Six Sigma to software or technology implementation projects that may fall within the scope of the IT operations group and/or the software development group. (12 pages)
Click Here to Read "Applying Six Sigma to Software Implementation Projects"!
Mad Belt Disease: Certification- Form or Substance?
Gary Gack discribes the increasingly frantic emphasis on "certification" as a Lean Six Sigma Black Belt as a disturbing trend. He also discusses how we're losing sight of another LSS fundamental - the need to connect LSS projects to important business results. (2 pages)
Click Here to Read "Mad Belt Disease: Certification- Form or Substance?"!
Best Practices Fusion: Lean Six Sigma and CMMI
Use of Lean Six Sigma in software development and IT in general has increased significantly over the last several years, and many organizations are learning to leverage the relationships between Lean Six Sigma and other approaches to software process improvement, including the Software Engineering Institute's Capability Maturity Model Integrated (CMMI), the IT Infrastructure Library (ITIL), the Project Management Institute's Project Management Body of Knowledge (PMBoK), and others. Integration of Lean Six Sigma with ITIL and the PMBoK are addressed in other White Papers in this series and are available from the author, Gary Gack. Lockheed Martin, Motorola, Raytheon, and many others have reported significant gains by combining the best features and ideas from several different best practices models and methods, in several cases creating a "local brand" of integrated process improvement methods. (9 pages)
Click Here to Read "Best Practices Fusion: Lean Six Sigma and CMMI"!
Best Practices Fusion: Lean Six Sigma and ITIL
Use of Lean Six Sigma in software development and IT in general has increased significantly over the last several years, and many organizations are learning to leverage the relationships between Lean Six Sigma and other approaches to software process improvement, including the Software Engineering Institute's Capability Maturity Model Integrated (CMMI), the IT Infrastructure Library (ITIL), the Project Management Institute's Project Management Body of Knowledge (PMBoK), and others. Integration of Lean Six Sigma with ITIL and the PMBoK are addressed in other White Papers in this series and are available from the author, Gary Gack. Lockheed Martin, Motorola, Raytheon, and many others have reported significant gains by combining the best features and ideas from several different best practices models and methods, in several cases creating a "local brand" of integrated process improvement methods. (10 pages)
Click Here to Read "Best Practices Fusion: Lean Six Sigma and ITIL"!
Results Trump Certification
"Certification" has become a very hot topic. The Software Engineering Institute certifies CMMI Lead Appraisers who in turn appraise and "certify" organizations or processes within organizations as having achieved a given level of "maturity" or "capability". Exin and others certify several levels of ITIL specialists, the Project Management Institute certifies Project Management Professionals, and dozens (maybe hundreds) of different firms and organizations certify Six Sigma "belts" of various hues. In general these certifications are based on some combination of knowledge demonstrated largely by testing and by general or specific experience demonstrating some application of the relevant discipline. Unfortunately, though, over-emphasis on certification can lead to a loss of focus on the underlying reasons for certification. Certification is not an end in itself - rather it is a means that, in combination with other factors not necessarily connected to the certification process, is intended to produce improved business outcomes of some sort. Author: Gary Gack. (2 pages)
Click Here to Read "Results Trump Certification"!
Top
Software Maintenance
A CAI State of the Practice Interview with Robert L. Glass, President of Computing Trends
Robert L. Glass is President of Computing Trends, publishers of The Software Practitioner. He has been active in the field of computing and software for over 45 years, largely in industry (1954-1982 and 1988-present), but also as an academic (1982-1988). He is the author of over 20 books including Software Folklore, Computing Catastrophes, Computer Shakeout, Software 2020, Software Runaways, Computing Calamities, and Facts and Fallacies of Software Engineering. He is Editor Emeritus of Elsevier's Journal of Systems and Software, and a columnist for several periodicals including Communications of the ACM (the "Practical Programmer" column) and IEEE Software ("The Loyal Opposition"). Our interview between Robert Glass and Michael Milutis, Executive Director for the IT Metrics and Productivity Institute (ITMPI), was conducted in October of 2005.
Click Here to Read the Interview with Robert Glass!
Software Maintenance is a Solution, Not a Problem
In software maintenance we are usually building new solutions, not just painting over old problems. Nevertheless, software maintenance is still widely perceived as a problem, and not a solution. This article by Robert L. Glass outlines four simple steps that can improve software maintenance practices by changing this traditional mind set. (3 pages)
Click Here to Read "Software Maintenance is a Solution, Not a Problem"!
The Link Between Software Quality and Software Maintenance
Too often, software maintenance is an afterthought in everyone's definition of computing. Computer science and software engineering rarely talk about software maintenance. Until recently, software maintenance tools and techniques were nonexistent, and even today research pays software maintenance scant attention. This article by Robert L. Glass seeks to demonstrate the importance of software maintenance, and give it the attention it deserves, by linking it directly to an issue that lies at the heart of the software industry- Quality. (2 pages)
Click Here to Read "The Link Between Software Quality and Software Maintenance"!
Software Maintenance: An Overview
This article by Gerardo Canfora of the University of Sannio seeks to overview software maintenance, its relevance, the problems, and the available solutions; the underlying objective is to present software maintenance not as a problem, but in terms of solutions. (33 pages)
Click Here to Read "Software Maintenance: An Overview"!
Case Study in Software Maintenance
In an effort to find out more about the tools, procedures, and techniques project personnel use in their work, the Computer-Aided Software Engineering (CASE) Environments Project interviewed personnel in eight software maintenance projects within an agency of the US government. This report by Susan Dart, Alan M. Christie, and Alan W. Brown of the Software Engineering Institute (SEI) highlights the findings of these interviews, provides an analysis of findings, and makes recommendations for improvement in the areas of tools, people, and process. (58 pages)
Click Here to Read "Case Study in Software Maintenance"!
Measurements to Manage Software Maintenance
Software Maintenance is central to the mission of many organizations. Thus, it is natural for managers to characterize and measure those aspects of products and processes that seem to affect cost, schedule, quality, and functionality of a software maintenance delivery. This article by George E. Stark of the Mitre Corporation answers basic questions about software maintenance for a single organization and discusses some of the decisions made based on the answers. (23 pages)
Click Here to Read "Measurements to Manage Software Maintenance"!
What You Need to Know About Software Maintenance
Software accounts now for an increasing share of the content of modern equipment and tools, and must similarly be maintained to ensure its continuous operational efficiency. Although the maintenance of the equipment is discussed extensively, very little is published about software maintenance and how it affects us. This paper by Alain April, A. Abran, and Reiner Dumke presents an overview of key topics of software maintenance. (5 pages)
Click Here to Read "What You Need to Know About Software Maintenance"!
Software Maintenance - An Overview
In the past, software systems have been constructed in an ad-hoc manner, with individual developments having no common strategy to enable the best use of support resources. A strategy, therefore, which focuses on the long-term support of software systems rather than purely rapid software development would be a worthwhile design goal from an architectural and financial viewpoint. Find out more in this article by Carl Allen. (3 pages)
Click Here to Read "Software Maintenance - An Overview"!
New from Capers Jones: The Economics of Software Maintenance in the 21st Century
In every industry maintenance tends to require more personnel than those building new products. For the software industry the number of personnel required to perform software maintenance is unusually large and may soon top 75% of all technical software workers. The main reasons for the high software maintenance efforts are the intrinsic difficulties of working with aging software, and the growing impact of "mass updates" that began with the roll-out of the Euro and the arrival of the year 2000 problem. As Capers Jones explains in this article from February 2006, similar software maintenance efforts will be needed in the future as we run out of telephone numbers and social security numbers. (19 pages)
Click Here to Read "The Economics of Software Maintenance in the 21st Century"!
Measuring and Evaluating the Maintenance Process
Measuring and evaluating the stability of software maintenance processes is important because of the recognized relationship between software process quality and software product quality. Software maintenance is performed continuously and the stability of the software maintenance process has an effect on software product reliability. Nevertheless, a software maintenance process can quickly become unstable because the very act of installing software changes the environment. Software programs must be adaptable to change and the resultant change process must be planned and controlled. This article from 1999 by Norman F. Schneidewind, IEEE Fellow and Director of the Software Metrics Research Center of the Naval Postgraduate School, analyzes the stability of the NASA Shuttle software maintenance process and considers the reliability of the software that the process produces. (22 pages)
Click Here to Read "Measuring and Evaluating the Maintenance Process"!
Geriatric Issues of Aging Software
Maintenance of aging software tends to become more difficult year by year since updates gradually destroy the original structure of the applications and increase its entropy. Aging software may also contain troublesome regions with very high error densities called "error-prone modules." Repairs to aging software suffer from a phenomenon called "bad fix injection" or new defects accidentally introduced as a byproduct of fixing previous defects. Read more in this article by Capers Jones. (13 pages)
Click Here to Read "Geriatric Issues of Aging Software"!
25 Time-Tested Truths About IT Support
Webster's Dictionary defines an axiom as "a self-evident truth that requires no proof." Over the course of decades in IT, I've discovered 25 axioms about the IT support environment. Being aware of these can help you design support processes that will make sense, work well and improve your team's performance. Here are some of the great truths I've learned and how your team can apply them for better IT support. (2 pages)
Click Here to Read "25 Time-Tested Truths About IT Support"!
Critical Application Support Knowledge Becoming Extinct!
If IT professionals do not do something quickly, practical application support knowledge will become a statistic of the Darwin Principle - EXTINCT!
The baby boomers are retiring at an ever increasing rate, critical IT application knowledge is moving off-shore at an ever increasing rate, and the work force is more mobile now than it has ever been.
The IT industry is experiencing an unprecedented "Brain Drain" particularly within the IT application support environment. Who is going to be left behind to mind the store? Where will all the application support knowledge go that has been accumulated over many years? (2 pages)
Click Here to Read "Critical Application Support Knowledge Becoming Extinct!"!
Structuring Meaningful SLA's for IT Support
As service providers IT organizations must demonstrate "value" to business customers. In this case, demonstrating value means delivering support services that meet or exceed the needs of the business at a cost that represents value. Service Level Agreements (SLA's) help demonstrate value by clearly identifying the service responsibilities of the IT organization and performance expectations of the business customer.(6 pages)
Click Here to Read "Structuring Meaningful SLA's for IT Support"!
Visual Analytics in Software Maintenance: Challenges and Opportunities
Visual analytics (VA) is an emerging science at the crossroads of data and information visualization, graphics, data mining, and knowledge representation, with many successful applications in engineering, business and finance, security, geosciences, and e-governance and health. Tools using visualization, data mining, and data analysis are also prominently present in a different field: software maintenance. However, an integrated VA is relatively new for this field. In this article, we discuss the specific challenges and particularities of applying VA in software engineering, highlight the added value of a VA approach, as distilled by us from several large-scale software engineering industrial projects. (11 pages)
Click Here to Read "Visual Analytics in Software Maintenance: Challenges and Opportunities"!
Top
Software Requirements
Karl Wiegers Describes 10 Requirements Traps to Avoid
The path to quality software begins with excellent software requirements. Slighting the processes of software requirements development and management is a common cause of software project frustration and software project failure. This article by Dr. Karl E. Wiegers describes ten common traps that software projects can encounter if team members and customers don't take software requirements seriously. He describes several symptoms that might indicate when you're falling victim to each trap, and offers several solutions to control the problem. (8 pages)
Click Here to Read "Karl Wiegers Describes 10 Requirements Traps to Avoid"!
So You Want to Be a Requirements Analyst?
Be it explicitly or not, someone always performs the role of software requirements analyst on a software project. The official title may be 'software requirements engineer', 'business analyst', 'system analyst', 'product manager', or simply 'analyst', but there will always be someone who needs to translate multiple perspectives into a software requirements specification document and communicate that information with other stakeholders. This article by Dr. Karl E. Wiegers explains hows it's done. (6 pages)
Click Here to Read "So You Want to Be a Requirements Analyst?"!
4 Key Requirements of the Product Life Cycle
Many enterprises view time to market and schedule prerformance as the key differentiators between market leaders and followers. Cristof Ebert shows us that a field study involving many industry projects revealed that only those that took a requirements engineering perspective in four key product life-cycle management activities were successful. (25 pages)
Click Here to Read "4 Key Requirements of the Product Life Cycle"!
Requirements Risks Can Drown Software Projects
Software requirements management is often viewed as a stand-alone task in terms of life-cycle activities. Of course, some of the major risks to project completion are incomplete, inaccurate, or vague requirements. In this article by Theron Leishman and David Cook, the authors will present and discuss several requirements risks that may have major impacts on the success of software projects. We will then consider strategies to help mitigate the impact of these requirements risks. (8 pages)
Click Here to Read "Requirements Risks Can Drown Software Projects"!
Writing a Software Requirements Document
This paper by Tanya Berezin discusses the purpose and contents of a requirements document for a business application. It will help you write a professional requirements document. At the conclusion of the paper, the author includes a bibliography for further, more advanced reading. (22 pages)
Click Here to Read "Writing a Software Requirements Document"!
Writing Software Requirements Specifications
Writing top-quality requirements specifications begins with a complete definition of customer requirements coupled with a natural language that incorporates strength and weakness quality indicators- not to mention the adoption of a good SRS template. Technical communications professionals well-trained in requirements gathering, template design, & natural language use are in the best position to create and add value to such critical project documentation.(18 pages)
Click Here to Read "Writing Software Requirements Specifications"!
ROI is Deceptive Without REAL Requirements and Quantified Intangibles
ROI is intended to provide valid and objective information for making business decisions. However, not quantifying the intangible benefits leaves a gap in the ROI analysis that can lessen the value of the calculation. In this article Robin Goldsmith discusses the Problem PyramidTM which can be used to identify the real value of the business requirements. The combination of the Problem PyramidTM and ROI Value ModelingTM can prevent projects which may seem like good business ideas but whose benefits really won't pay off. The article is also available along with reader feedback commentary at the following site which requires free registration http://www.requirementsnetwork.com/node/735 (8 pages)
Click Here to Read "ROI is Deceptive Without REAL Requirements and Quantified Intangibles"!
Rapid Requirements Engineering - Does a Specification Always Need to Come at the Start?
Requirements and the way they are dealt with are decisive to the success of a project. This statement is never really questioned in modern software engineering circles. Why is it, then, that a systematic requirements engineering (RE) system is so rarely established? Where do the problems lie when it comes to implementing such a system? This paper Michael Gerdom and Dr. Uwe Rastofer of Method Park Software outlines the challenges and how these may be met using the example of the automotive industry. (8 pages)
Click Here to Read "Rapid Requirements Engineering - Does a Specification Always Need to Come at the Start?"!
Managing Process Architecture and Requirements in a CMMI based Software Process Improvement Project
When developing or changing a process, and all its related assets, often the process engineers have to face an important issue: how defining an integrated set of processes so that each process element is designed taking in consideration its relationships with all the other interfacing elements. Together with this issue, we also have the need to ensure that all the relevant requirements for the processes and their process assets are fully understood and correctly managed. These objectives are even more difficult to achieve when more persons are working in parallel to the improvement of different process areas. The approach described in the following paper by Filippo Vitiello leverages a defined process architecture and a documented specification of process requirements to ensure integration among the process elements. (6 pages)
Click Here to Read "Managing Process Architecture and Requirements in a CMMI based Software Process Improvement Project"!
What is the Cost of a Requirement Error?
This paper by Tom King and Joe Marasco presents a simple, practical calculation of the cost of requirements errors in application software development projects. It also recommends a way to find and fix these costly errors early in a project, when they are least expensive to correct. (6 pages)
Click Here to Read "What is the Cost of a Requirement Error?"!
12 Requirements Basics for Project Success
In this article, Dr. Ralph Young of the Northrop Grumman Information Technology Defense Group provides a set of 12 requirements basics; these recommended approaches will contribute to your project's success. The requirements basics are based on industry experience; guidance from requirements-related books, articles, and Web sites; and the author's involvement with projects. Having an experienced requirements subject matter expert on the project staff can help the project manager and the project team guide investments that will help. (11 pages)
Click Here to Read "12 Requirements Basics for Project Success"!
When Telepathy Won't Do: Requirements Engineering Key Practices
The best way to succeed with requirements engineering is to adopt known industry best practices. Karl Wiegers describes 8 such key practices in this article, helping any organization improve the way it elicits, analyzes, specifies, verifies, and manages its requirements. (9 pages)
Click Here to Read "When Telepathy Won't Do: Requirements Engineering Key Practices"!
In Search of Excellent Requirements
This article by Karl Wiegers describes several practical techniques for improving the requirements processes used in some small groups at Eastman Kodak Company and elsewhere. (9 pages)
Click Here to Read "In Search of Excellent Requirements"!
Requirements by Collaboration: Getting it Right the First Time
We know that we must involve all the stakeholders if we want to discover a project's requirements. But we need some guidelines on how to involve the right people and, given how busy everyone is, how to minimize the time and maximize the result. In this article, Ellen Gottesdiener shares her considerable experience running requirements workshops (4 pages)
Click Here to Read "Requirements by Collaboration: Getting it Right the First Time"!
You Know When It's Not There: How Trust Enables and Enhances Collaboration
Great products are built by teams that collaborate in a healthy and transparent manner, and trust is a key ingredient of effective collaboration. The good news is that trust isn't "a feeling" that "just happens." Rather, it is the result of specific actions team leaders can take in a systematic way. In this article, Ellen Gottesdiener explores practical techniques that help you build and sustain trust on your teams. (5 pages)
Click Here to Read "You Know When It's Not There: How Trust Enables and Enhances Collaboration"!
The Whos and Wheres of Stakeholder Requirements
Whether you're working on a collocated or distributed team, it's important to take stakeholder requirements into account. "Who" are they, and "where" are they located? In this article, Mary Gorman offers some tips to help you narrow the gap between thinking and acting globally and locally.
Click Here to Read "The Whos and Wheres of Stakeholder Requirements"!
Improving the Exchange of Requirements and Specifications Between Business Partners
Increasingly complex supplier-relationships dominate product development, independent of industries and products. Mostly the primary source of risks and later problems is insufficient coherence with requirements engineering methodology and collaboration between different business partners during the project. This article based on experiences from various industries and projects provides insight into how to effectively collaborate in requirements engineering. Methods and tools are one side of the medal, but true collaboration also means having a platform to effectively and efficiently exchange requirements, specifications and their entire change management across impacted stakeholders. The Requirements Interchange Format (RIF) has quickly moved forward over the past two years first in automotive and currently starting in domains such as medical and aerospace. This paper describes typical RE collaboration scenarios and what we recommend in order to mitigate risks and thus effectively manage complex supplier relationships. We will not "sell" any tool but rather indicate how RIF is applied in order to share, communicate and collaborate across different tools. (14 pages)
Click Here to Read "Improving the Exchange of Requirements and Specifications Between Business Partners"!
Requirements Engineering for Medical Systems
Requirements engineering is today the most important success factor in developing critical systems, such as medical, automotive, railway, industrial automation and aerospace. Together with Siemens, Vector has summarized experiences from current projects. The presentation begins with an analysis of typical challenges and then highlights solutions and best practices with concrete guidance how to improve requirements engineering for critical systems. (26 pages)
Click Here to Read "Requirements Engineering for Medical Systems"!
Top
Software Testing
Factors Affecting the Effort to Integrate and Test a System of Systems
This article by David Garmus will consider the use of a basic estimating model utilizing functional sizing as one of the key components. The value to be gained from utilizing a functional sizing technique, such as Function Points, is primarily in the capability to accurately size and estimate a project early in the development process. (7 pages).
Click Here to Read "Factors Affecting the Effort to Integrate and Test a System of Systems"!
Factors Affecting the Effort to Integrate and Test a System of Systems
This paper by Richard Stutzke identifies possible factors that affect the effort, duration, and risk to integrate and test a System of Systems (SoS). The paper speculates on possible size measures to consider when estimating the integration and test effort. It also suggests sources of data that might be useful for model builders. (16 pages)
Click Here to Read "Factors Affecting the Effort to Integrate and Test a System of Systems"!
The Cost of Software Quality: Investing in Software Testing, Part 1
Software testing can be considered an investment. A software organization- whether an in-house IT shop, market-driven shrink-wrap software vendor, or Internet ASP- chooses to forego spending money on new software projects or additional software features in order to fund the software test team. What's the return on that investment (ROI)? This article by Rex Black explains how cost of quality analysis provides one way to quantify your software testing ROI. (6 pages)
Click Here to Read "The Cost of Software Quality: Investing in Software Testing, Part 1"!
High Fidelity Systems: Investing in Software Testing, Part 2
Realizing a solid return on your testing investment requires a smart selection of software tests. Cost-of-quality analysis tells us that it's cheaper to find and fix software bugs before the customers do, but, to keep software bugs away from customers, we have to find the ones that matter. In this article by Rex Black you will find out what you need to know to get this right. (5 pages)
Click Here to Read "High Fidelity Systems: Investing in Software Testing, Part 2"!
The Risks to System Quality: Investing in Software Testing, Part 3
Before we can build a high-fidelity software test system, we have to understand what software quality means to our customers. In this article, Rex Black explains how software test professionals can avail themselves of three powerful techniques for analyzing risks to software quality. He further explains how targeting our software testing investment- by increasing effort to those areas most at risk- will result in the highest return on our software testing investment. (7 pages)
Click Here to Read "The Risks to System Quality: Investing in Software Testing, Part 3"!
The Many Flavors of Testing
There is evidence that testing is still vitally important to software development, and that it probably always will be. Reviews may be more cost effective, according to recent studies, and proof of correctness (if it ever scales up to larger problems) may be more rigorous, but neither can take the place of taking the software into a near-real environment and trying it out. This excerpt from Robert Glass's new book "Software Conflict" explores what testing really means. He asserts that there are several flavors of testing, and that all too often when we speak of testing we consider far too few of those flavors. (5 pages)
Click Here to Read "The Many Flavors of Testing"!
A CAI State of the Practice Interview with Rex Black, Author of Critical Testing Processes
Rex Black is president and principal consultant of Rex Black Consulting Services, Inc., a software testing and quality assurance firm serving clients such as Bank One, Cisco, Dell, and the US Department of Defense. He is also the author of Critical Testing Processes and Managing the Testing Process. Rex holds a degree in Computer Science and Engineering from UCLA. He belongs to the Association for Computer Machinery and the American Society for Quality. Our interview between Michael Milutis, Executive Director of the IT Metrics and Productivity Institute, and Rex Black took place in March of 2006.
Click Here to Read "An Interview with Rex Black"!
The Ongoing Revolution in Software Testing
In this article, Cem Kaner discusses paradigmatic shifts in development and how such changes must be applied to testing as well. (29 pages)
Click Here to Read "The Ongoing Revolution in Software Testing"!
Experiences Teaching a Course in Software Testing
The authors of this article teach a class on programmer-testing with a primary focus on test-driven development (TDD) as part of the software engineering curriculum at the Florida Institute of Technology. As of this writing, their course has been offered 3 times. Each session contained a mixture of undergraduate and graduate students. This paper discusses the evolution of the course, their lessons learned and plans for enhancing the course in the future. (8 pages)
Click Here to Read "Experiences Teaching a Course in Software Testing"!
Test Tools for Free
In this short article, Danny Faught discusses some free test tools, along with the basics of 'freeware', and information on a testing freeware newsletter. (2 pages)
Click Here to Read "Test Tools for Free"!
Tell Me About Your Organization's Quality Assurance and Testing
This article by Gary E. Mogyorodi presents 20 questions used to determine and understand how mature the quality assurance and testing environments are within an organization. The questions are ordered to begin with those easiest to answer and become progressively more difficult for organizational compliance. This questionnaire again proves that an organization that has good quality assurance and testing practices tests early and tests often throughout its software development lifecycle. (7 pages)
Click Here to Read "Tell Me About Your Organization's Quality Assurance and Testing"!
Inefficiency and Ineffectiveness of Software Testing: A Key Problem in Software Engineering
Most testing techniques in current use were developed before 1980. Back then, significant programs were less than 10,000 statements. Today, it is common to find consumer products with a few million lines of code. Certainly, testing efficiency has improved somewhat in the past thirty years, but not nearly at the rate of programming efficiency. The most common automation technique, regression test automation, automates only test execution and simple result comparison; design, documentation and maintenance of these tests are time-costly human tasks. Test case management systems still call for step-by-step test documentation with some testers of life-critical applications reporting that they spend as much as 90% of their testing time on documentation-related tasks and only 10% on test execution and result analysis. What's to be done? In this article by Cem Kaner, the author offers some recommendations for addressing these challenges. (4 pages).
Click Here to Read "Inefficiency and Ineffectiveness of Software Testing: A Key Problem in Software Engineering"!
Experiences Teaching a Course in Programmer Testing
The authors of this article, Cem Kaner and Andy Tinkham, teach a class on programmer-testing with a primary focus on test-driven development (TDD) as part of the software engineering curriculum at the Florida Institute of Technology. As of this writing, the course has
been offered 3 times. Each session contained a mixture of undergraduate and graduate students. This paper discusses the evolution of the course, our lessons learned and plans for enhancing the course in the future.
Click Here to Read "Experiences Teaching a Course in Programmer Testing"!
Developing a Compelling Test Automation Business Case
Traditional business cases focus on cost containment and reduction as the primary means of achieving an attractive ROI. While these are important, even crucial aspects, test automation should be viewed through perhaps a wider lens. In this article, Bob Galen explores a slightly wider view to the test automation business case—one where time to market, cycle time, and even creativity are examined as components. (9 pages)
Click Here to Read "Developing a Compelling Test Automation Business Case"!
Establishing your Test Automation SDLC
Testing teams continue to invest in test automation tools & training in an ongoing effort to reduce the overall effort and cost associated with testing. It's exacerbated by our focus on iterating software development in ever shorter cycles—thus increasing the pressure on the testing team. However, few test teams approach their automation efforts as true software development projects, which causes no end of frustration and failure. Join Bob Galen as he establishes a Test Automation SDLC to connect to your Product Development SDLC. (10 pages)
Click Here to Read "Establishing your Test Automation SDLC"!
Test Automation Selection Criteria—Picking the "Right" Candidates
So you've exhaustively evaluated products and selected your test automation tool. You've also received budget sign-off for the tool and some training, so you're ready to go. However, depending on your environment, you have another even more crucial decision-point facing you. If you have a large repository of existing manual test cases, then deciding where and how to begin automation—may be the most daunting decision you've faced. Here Bob Galen will explore decision criteria and strategies for determining where to begin your automation journey. (9 pages)
Click Here to Read "Test Automation Selection Criteria—Picking the "Right" Candidates"!
Improving Testing Efficiency: Agile Test Case Prioritization
A remaining challenging area in the field of software management is the release decision, deciding whether or not a software product can be transferred from its development phase to operational use. Many software manufacturers have difficulty in determining the 'right' moment to release their software products. It is a trade-off between an early release, to capture the benefits of an earlier market introduction, and the deferral of product release, to enhance functionality, or improve quality. Execution testing is currently the most common way of verifying whether a software system is sufficiently defect-free or not. With this approach, testing resources are absorbed not just in testing, but in identifying the causes of defects and aiding re-work of the software. The extent to which rectified software needs to be re-tested is not always known. The stop criterion used is either available testing time or a sufficiently stable product. Whatever criterion is taken, the test process should be as efficient as possible to remove as many defects as possible. In this paper, we describe a method called "Agile Test Case Prioritization" for optimizing testing efficiency. (7 pages)
Click Here to Read "Improving Testing Efficiency: Agile Test Case Prioritization"!
Advanced Software Testing: Decision Tables
Equivalence partitioning and boundary value analysis are very useful techniques. They are especially useful when testing input field validation at the user interface. However, lots of testing that we do as test analysts involves testing the business logic that sits underneath the user interface. We can use boundary values and equivalence partitioning on business logic, too, but three additional techniques, decision tables, use cases, and state-based testing, will often prove handier and more powerful techniques. In this article, we start with decision tables. Conceptually, decision tables express the rules that govern handling of transactional situations. By their simple, concise structure, decision tables make it easy for us to design tests for those rules, usually at least one test per rule. (11 pages)
Click Here to Read "Advanced Software Testing: Decision Tables"!
Advanced Software Testing: State-Based Testing
At the start of this series, I said we would cover three techniques that would prove useful for testing business logic, often more useful than equivalence partitioning and boundary value analysis. We covered decision tables, which are best in transactional testing situations. In the next article, we'll cover use cases, where preconditions and postconditions help to insulate one workflow from the previous workflow and the next workflow.
In this article, we look at state-based testing. State-based testing is ideal when we have sequences of events that occur and conditions that apply to those events, and the proper handling of a particular event/condition situation depends on the events and conditions that have occurred in the past. In some cases, the sequences of events can be potentially infinite, which of course exceeds our testing capabilities, but we want to have a test design technique that allows us to handle arbitrarily-long sequences of events. (16 pages)
Click Here to Read "Advanced Software Testing: State-Based Testing"!
Advanced Software Testing: Use Cases
At the start of this series, I said we would cover three techniques that would prove useful for testing business logic, often more useful than equivalence partitioning and boundary value analysis. First, we covered decision tables, which are best in transactional testing situations. Next, we looked at state-based testing, which is ideal when we have sequences of events that occur and conditions that apply to those events, and the proper handling of a particular event/condition situation depends on the events and conditions that have occurred in the past. In this article, we'll cover use cases, where preconditions and postconditions help to insulate one workflow from the previous workflow and the next workflow. With these three techniques in hand, you have a set of powerful techniques for testing the business logic of a system.
Conceptually, use case testing is a way to ensure that we have tested typical and exceptional workflows and scenarios for the system, from the point of view of the various actors who directly interact with the system and from the point of view of the various stakeholders who indirectly interact with the system. If we (as test analysts) receive use cases from business analysts or system designers, then these can serve as convenient frameworks for creating test cases. (10 pages)
Click Here to Read "Advanced Software Testing: Use Cases"!
Top
Software Inspections
7 Truths About Peer Reviews By Karl Wiegers
The term 'testing' conjures an image of executing software in a prescribed way to see whether it functions as intended. An alternative form of testing (or, more precisely, quality control) is to invite some colleagues to examine your work products for defects and improvement opportunities: a peer review. Whereas traditional testing is limited to executable code, you can apply peer reviews to any software deliverable, design, or document. Peer reviews have long been recognized as a powerful way to improve quality, yet few software organizations have systematic and effective review programs in place. This article by Karl Wiegers presents seven facts about peer reviews that any organization concerned about quality needs to know. (8 pages)
Click Here to Read "7 Truths About Peer Reviews"!
Humanizing Peer Reviews By Karl Wiegers
Peer review - an activity in which people other than the author of a software deliverable examine it for defects and improvement opportunities - is one of the most powerful software quality tools available. Peer review methods include inspections, walkthroughs, peer desk checks, and other similar activities. After experiencing the benefits of peer reviews for nearly fifteen years, I would never work in a team that did not perform them. However, many organizations struggle to implement an effective review program. Many of the barriers to successful peer reviews are social and cultural in nature, not technical. This article by Karl Wiegers explores some of the social and psychological aspects of having people review each other's work, ways to overcome resistance to reviews, and issues regarding management involvement. (8 pages)
Click Here to Read "Humanizing Peer Reviews"!
Improving Quality Through Software Inspections By Karl Wiegers
Software inspections and their cousins, reviews and walkthroughs, are proven techniques for reducing the number of defects in a program before it goes out the door. If you are in an organization of two or more people, some kind of inspection activity should be a part of your standard software development process. (16 pages)
Click Here to Read "Improving Quality Through Software Inspections"!
Top
Offshore
Surviving Global Development
Although there are many good reasons to globally distribute development activities, success is not guaranteed by just opening a development center in another region of the world. This article by Cristof Ebert and Philip De Neve summarizes and distills best practices from true global software development. (8 pages)
Click Here to Read "Surviving Global Development"!
Improving Validation Activities in a Global Software Development
Global software development challenges traditional techniques of software engineering, such as peer reviews or teamwork. In this case study, Christof Ebert, Casimiro Hernandez Parro, Roland Suttels, and Harald Kolarczyk have evaluated experiences with validation activities in a global setting within Alcatel's Switching and Routing business. (10 pages)
Click Here to Read "Improving Validation Activities in a Global Software Development"!
The Hidden Costs of IT Outsourcing and How to Avoid Them
It's one of those days!
Have you ever had one of those days when you get to the office at 8:00 am, pour your first cup of coffee, begin reviewing e-mails... and one jumps out marked "URGENT?" It's from your boss requesting that you attend a meeting in his office at 9:00 am today.
You get to the boss's office and after the usual pleasantries, the bomb hits.
Business is not doing well; all departments, including IT must cut 20% from their budgets by the next quarter.
There can be any number of other "bomb-types" that may require IT outsourcing decisions.
In this article we will explore the Iceberg of IT Outsourcing where 90% of an mass is below the waterline, invisible, unseen and potentially deadly. We will look below the waterline of IT Outsourcing and identify some "hidden costs" which may represent 90% of the real cost and how to avoid them.(3 pages)
Click Here to Read "The Hidden Costs of IT Outsourcing and How to Avoid Them "!
Key Lessons Learned in Offshore Outsourcing: Towards an Offshore Maturity Model
Published by the IEEE Computer Society Press, "Key Lessons Learned in Offshore Outsourcing" is a bird's-eye view of the reality of program implementation -- a kind of offshore "fireside chat." Through relating lessons learned in process, organization, technical matters, and vendor oversight, author Tandy Gold hits upon approaches by which managers responsible for offshoring may claim a formidable edge in the marketplace. "Towards an Offshore Maturity Model" is an excerpt from the book. (11 pages)
Click Here to Read "Key Lessons Learned in Offshore Outsourcing: Towards an Offshore Maturity Model"!
Success Factors in Managing Outsourced Software Development: Part 1
Offshore Outsourcing has become an IT imperative. This article by Tandy Gold outlines the key factors underlying the successful offshore outsourcing of software development. Topics of discussion include typical pitfalls and how to avoid them, offshore vendor evaluation and management, establishing realistic financial goals, security and risk management, and finally, navigating the difficult waters of employee impact. This article is based upon the hands-on guide "Managing Software Development Offshore - Making it Work" (CRC Press, 2004), by the same author. (21 pages)
Click Here to Read "Success Factors in Managing Outsourced Software Development: Part 1"!
Success Factors in Managing Outsourced Software Development: Part 2
Offshore Outsourcing has become an IT imperative. This article by Tandy Gold outlines the key factors underlying the successful offshore outsourcing of software development. Topics of discussion include typical pitfalls and how to avoid them, offshore vendor evaluation and management, establishing realistic financial goals, security and risk management, and finally, navigating the difficult waters of employee impact. This article is based upon the hands-on guide "Managing Software Development Offshore - Making it Work" (CRC Press, 2004), by the same author. (18 pages)
Click Here to Read "Success Factors in Managing Outsourced Software Development: Part 2"!
Lean
Introducing Lean Software Development
Lean Software Development provides a management philosophy together with a set of practical tools for designing and delivering software-intensive products and services. These tools enable us to select design solutions, methods, design tools, and organizational structures based on fitness for purpose. That purpose is to produce value for the customer with minimum waste for us. There is a wonderful supermarket of tools, methods, and techniques from decades of progress in software engineering management. Lean does not invalidate or validate any of these. Instead, it gives us the wisdom to shop wisely and employ just the right combination of remedies needed to maximize customer value, minimize waste, and produce real top-line and bottom-line results. (7 pages)
Click Here to Read "Introducing Lean Software Development"!
The Challenges of Bringing Lean to Software Development
The core problem in software development can be boiled down to the intense pressure for a plan that lays out what the software will be able to do, how long it will take, and what it will cost - and the subsequent expectation that development will follow this plan. The problem is magnified when the software is expected to be developed independently from the system for which the software will supply the brains. This article by Mary Poppendieck looks at these problems from the perspective of various paradigm shift models. (4 pages)
Click Here to Read "The Challenges of Bringing Lean to Software Development"!
The Lean - Agile Connection
This article by Alan Shalloway, CEO of Net Objectives, is about how to develop software. We'll first look at what we are trying to accomplish when we build software. We'll then investigate what we have to do to do this, including the nature of the problems inherent in building software. This may sound a little basic, but there are many inherent flaws in common approaches to building software because people haven't stepped back far enough to see the big picture. Planting the right tree in the wrong forest does not make for good forest management. Once we have a clearer view about we are trying to do, we will move on to an overall view of the tasks needed to build software that is useful and cost effective. We investigate different ways these are accomplished with both standard processes and a lean-agile approach. Finally, we come up with a set of core practices that we should follow to build cost-effective software that give us appropriate solutions so we get the return on investment we want and need. (14 pages)
Click Here to Read "The Lean - Agile Connection"!
