Patricia A. McQuaid

Entry strategies into the process improvement initiative

One of the more important steps in starting a process improvement initiative is to determine the appropriate tasking and the scope of the process improvement program. There is great temptation for an organization to attempt to take on too much too fast, especially if it feels that it must catch up with its competition. For example, an organization will assess its capability against all of the key process areas (KPAs) of the Capability Maturity Model (CMM) and try to set up working groups and action plans in a broadly based approach to implement multiple levels of KPAs at the same time. While it is natural to want to initiate a program quickly, it is important for an organization trying to get a process improvement initiative started to be as realistic as possible in these beginning stages. It might not be appropriate for an organization to conduct an assessment right away, yet another organization might want to focus on only a few areas to get its process improvement initiative started, show positive results and then expand. This paper will identify critical factors to consider and discuss process improvement entry strategies that the authors have helped their clients to achieve over the past five years. Copyright

Software disasters—understanding the past, to improve the future

Over the years, there have been several major software disasters, resulting from poor software project management, poor risk assessment, and poor development and testing practices. The results of the disasters range from project delays, project cancelations, loss of millions of dollars of equipment, to human fatalities. It is important to study software disasters, to alert developers and testers to be ever vigilant, and to understand that huge catastrophes can arise from what seem like small problems. This paper examines such failures as the Mars Polar Lander, the Patriot missile, and the Therac‐25 radiation deaths. The focus of the paper is on the factors that led to these problems, an analysis of the problems, and the lessons to be learned that relate to software engineering, safety engineering, government and corporate regulations, and oversight by users of the systems. A model named STAMP, Systems‐Theoretic Accident Modeling and Process, will be introduced, as a model to analyze these types of accidents. This model is based on systems theory, where the focus is on systems taken as a whole, as opposed to traditional failure‐event models where the parts are examined separately. It is by understanding the past, that we can improve the future. Copyright