Technical Reports


Return to Technical Report System

USC-CSE-97-510 PDF

The Effects of Process Maturity on Software Development Effort

Bradford Clark, USC-Center for Software Engineering

 A software product is often behind schedule, over budget, non-conforming to requirements and of poor quality. Controlling and improving the processes used to develop software has been proposed as a primary remedy to these problems. The Software Engineering Institute at Carnegie Mellon University has published the Software Capability Maturity Model (SW-CMM) for use as a set of criteria to eveluate an organization's Process Maturity. The model is also used as a roadmap to improve a software development process's maturity. The premise of the SW-CMM is that mature development processes deliver products on time, within budget, within requirements, and of high quality.

This research examis the effects of Software Process Maturity, using the SW-CMM, on software development effort. Effort is the primary determinant of software development cost and schedule. The technical challenge in this research is determining how much change in effort is due solely to changing Process Maturity when this change generally occurs concurrently with changes to other factors that also influence software development effort.

The six mathematical models used in this research support the following concludion: For the one hundred twelve projects in this sample, Software Process Maturity was a significant factor (95% confidence level) affecting software development effort. After normalizing fo the effects of other effort influences, a one-increment change in the rating of Process Maturity resulted in a 15% to 21% reduction in effort. The modeling approach used in this analysis can be used in other areas of Software Engineering as well.


Process Support of Software Product Lines (ISPW 10)

Barry Boehm, USC-Center for Software Engineering

The focus of ISPW 10 was on "Process Support of Software Product Lines." Much of the technology currently available to support the software process has focused on the process of developing and evolving a single software product. Increasingly, organizations are finding advantages in product-line software approaches, involving investments in domain engineering, product line architectures, and rapid applications composition with extensive use of commercial-off-the-shelf (COTS) and other reusable software assets. Recent books on software reuse and product line management [Jacobson-Griss-Jonsson, 1997; Poulin, 1997; Reifer, 1997] provide extensive evidence of the advantages: factors of 1.5 to 4 improvements in development time, factors of 1.5 to 6 in productivity, and factors of 2-10 in defect rates. This paper summarizes the original issues and major conclusions of the Workshop.

 Document characteristics: Proceedings, ISPW 10, June 1996, pp. 2-6

USC-CSE-97-508 Postscript, PDF

WinWin Requirements Negotiation Processes: A Multi-Project Analysis

Barry Boehm and Alexander Egyed, USC-Center for Software Engineering

Fifteen 6-member-teams were involved in negotiating requirements for multimedia software systems for the Li-brary of the University of Southern California. The re-quirements negotiation used the Stakeholder WinWin suc-cess model and the USC WinWin negotiation model (Win Condition-Issue-Option-Agreement) and groupware sys-tem. The negotiated results were integrated into a Life Cycle Objectives (LCO) package for the project, including descriptions of the system's requirements, operational concept, architecture, life cycle plan, and feasibility ra-tionale. These were subsequently elaborated into a Life Cycle Architecture package including a prototype; six of these were then implemented as products.

A number of hypotheses were formulated, tested, and evolved regarding the WinWin negotiation processes and their effectiveness in supporting the development of effec-tive LCO packages, in satisfying Library clients, and in stimulating cooperation among stakeholders. Other hy-potheses involved identification of WinWin improvements, relationships among negotiation strategies on LCO pack-age and project outcomes.

Some of the more illuminating results were:

         Most of the stakeholder Win Conditions were non-controversial (were not involved in Issues). Also, most Issues were decoupled from other Issues and were easy to resolve. This implies that requirements nego-tiation support systems should focus at least as much on handling simple relationships well as on handling complex relationships well.

         Similar applications projects did not follow similar processes, confirming our previous conclusion [11] that repeatability of software front-end processes is not a realistic goal.

         The strongest positive effects of using the WinWin approach were increasing cooperativeness, focusing participants on key issues, reducing friction, and fa-cilitating distributed collaboration.

         The major improvements for the WinWin approach (now being implemented) were increasing WinWin training, reducing usage overhead, and concurrent negotiation and prototyping.

Document characteristics: Proceedings, ICSP'98

USC-CSE-97-507 Postscript, PDF

Calibration Results of COCOMO®II.1997

Barry Boehm, Brad Clark, and Sunita Devnani-Chulani, USC-Center for Software Engineering

COCOMO® II is an effort to update software cost estimation models, such as the 1981 COnstructive COst MOdel and its 1987 Ada COCOMO® update. Both these and other 1980's cost models have experienced difficulties in estimating software projects of the 90s due to new practices such as non-sequential and rapid-development process models; reuse-driven approaches involving commercial-off-the-shelf (COTS) packages, reengineering, applications composition, and application generation capabilities; object-oriented ap proaches supported by distributed middleware; software process maturity effects and process-driven quality estimation. The COCOMO® II research effort has developed new functional forms reflecting these practices, and is concentrated on developing a model well-suited for the 1990s and then annually updating it for the forthcoming years of the 21st Century.

The current COCOMO® II.1997 has been calibrated to a dataset of 83 projects from a mix of Commercial, Aerospace, Government, and FFRDC organizations. The estimates of the 1997 calibrated model are within 30% of the actuals 52% of the times before stratific ation by organization; and within 30% of the actuals 64% of the times after stratification by organization.

The 1997 calibration results indicated that the following changes from COCOMO® '81 to COCOMO® II were successfully explaining sources of variation in the project data : Replacing the COCOMO® '81 Development Modes by the 5 exponent drivers Precedentedness, Development Flexibility, Architecture/Risk Resolution, Team Cohesiveness, and CMM-based Process Maturity. Adding multiplicative cost drivers for Amount of Documentation and Multisite Development.

Keywords: Metrics, Empirical Data Analysis, Model Calibration, Model Prediction Accuracy

 Document characteristics: Presented at the SEPG-98

USC-CSE-97-506 Postscript, PDF

Detecting Architectural Mismatches During Systems Composition

Cristina Gacek, USC-Center for Software Engineering

The USC Architect's Automated Assistant (AAA) tool and method provides a capability for early detection of architectural style mismatches among four architectural styles: Main-Subroutine, Pipe-and-Filter, Event-Based, and Distributed Processes. For these four styles, mismatch detection is based on a set of seven conceptual features distinguishing each style, and a set of eight types of bridging connectors characterizing compositions among the four styles.

The work proposed here is to formalize some additional architectural styles--namely Blackboard, Closed-Loop Feedback Control, Logic Programming, Real-Time, Rule-Based, and Transactional Database styles--and to extend the mismatch analysis capability to cover interactions of the original four styles with the new ones. The analysis results will test various hypotheses, such as the sufficiency of the original seven conceptual features and eight bridging connector types to characterize the broader set of styles and their composition.

We will also try to provide a more formal basis for detecting and classifying architectural conceptual features, thus providing a formal framework for extending the models. The application of the broadened mismatch analysis capability to a relevant problem will also be included in the future.

Keywords : Megaprogramming, Software Architectures, Architectural Mismatches, Classification of Systems, Software Architectural Styles

Document characteristics: Qualifying Report for partial fulfillment of Computer Science Department requirements

USC-CSE-97-505 Postscript, PDF

Results of Delphi for the Defect Introduction Model
(Sub-Model of the Cost/Quality Model Extension to COCOMO® II)

Sunita Devnani-Chulani, USC-Center for Software Engineering

In software estimation, it is important to recognize the strong correlation between Cost, Schedule and Quality. They form three sides of the same triangle. Beyond a certain point (the "Quality is Free" point), it is difficult to increase the quality without increasing either the cost or schedule or both for the software under development. Similarly, development schedule cannot be drastically compressed without hampering the quality of the software product and/or increasing the cost of development. Software estimation models can play an important role in facilitating the balance of the three factors.

This paper presents an initial version of the Defect Introduction sub-model of the empirical quality modeling extension to the existing COCOMO® II software cost estimation model. The Quality Model is an estimation model that can be used for predicting number of residual defects/KSLOC (thousands of Source Lines of Code) or defects/FP (Function Point) in a software product. It applies in the early activities such as analysis and design as well as in the later stages for refining the estimate when more information is available. It enables 'what-if' analyses that demonstrate the impact of various defect removal techniques and the effects of personnel, project, product and platform characteristics on software quality. It also provides insights on determining ship time, assessment of quality investment payoffs and understanding of quality strategy interactions.

The model has two sub-models, namely the Defect Introduction Model and the Defect Removal Model. This paper focuses on the Initial version of the Defect Introduction Model which is the result of a two-round Delphi analysis. It discusses in depth the Defect Introduction rate sensitivities of the various COCOMO® II parameters and gives a detailed explanation of the rationale behind the suggested numeric ratings associated with each of the parameters.

Keywords : Software Metrics, Software Quality Models, Software Defect Introduction, Software Defect Removal, Software Estimation

USC-CSE-97-504 Postscript, PDF

Developing Multimedia Applications with the WinWin Spiral Model

Barry Boehm and Alex Egyed, USC-Center for Software Engineering
Julie Kwan, USC University Libraries
Ray Madachy, USC-CSE and Litton Data Systems

Fifteen teams recently used the WinWin Spiral Model to perform the system engineering and architecting of a set of multimedia applications for the USC Library Information Systems. Six of the applications were then developed into an Initial Operational Capability. The teams consisted of USC graduate students in computer science. The applications involved extensions of USC's UNIX-based, text-oriented, client-server Library Information System to provide access to various multimedia archives (films, videos, photos, maps, manuscripts, etc.).

Each of the teams produced results which were on schedule and (with one exception) satisfactory to their various Library clients. This paper summarizes the WinWin Spiral Model approach taken by the teams, the experiences of the teams in dealing with project challenges, and the major lessons learned in applying the Model. Overall, the WinWin Spiral Model provided sufficient flexibility and discipline to produce successful results, but several improvements were identified to increase its cost-effectiveness and range of applicability.

Document Characteristics: Proceedings, ESEC/FSE 97, Springer Verlag, 1997.

USC-CSE-97-503 Postscript (updated 1999)

WinWin Reference Manual--A System for Collaboration and Negotiation

Ellis Horowitz, University of Southern California

WinWin is a computer program that aids in the capture, negotiation, and coordination of requirements for a large system. It assumes that a group of people, called stakeholders, have signed on with the express purpose of discussing and refining the requirements of their proposed system. The system can be of any type.

 This is the WinWin Reference Manual as of June 1997.

USC-CSE-97-502 Postscript

Detecting Architectural Mismatches During Systems Composition--
An Extension to the AAA Model

Cristina Gacek, USC-Center for Software Engineering

The USC Architect's Automated Assistant (AAA) tool and method provides a capability for early detection of architectural style mismatches among four architectural styles: Main-Subroutine, Pipe-and-Filter, Event-Based, and Distributed Processes.

 The work proposed here is to formalize some additional architectural styles--namely Blackboard, Closed-Loop Feedback Control, Logic Programming, Real-Time, Rule-Based, and Transactional Database styles--and to extend the mismatch analysis capability to cover interactions of the original four styles with the new ones. The application of the mismatch analysis capability to a relevant problem will also be included in the future.

USC-CSE-97-501 Postscript

Extending Reliability Block Diagrams to Software Architectures

Ahmed Abd-Allah, USC-Center for Software Engineering

Reliability block diagrams focus on components and connectors as do software architectures. However, some architectural styles possess characteristics which make traditional reliability block diagrams unusable as an analysis technique. In order to use the diagrams, they must be extended to reflect common architectural choices such as concurrency, distribution, dynamism, and implicit connectors.


Experiences in Software Cost Modeling

Barry Boehm, USC-Center for Software Engineering

My first exposure to software economics came on my first day in the software business, in June 1955 at General Dynamics in San Diego. My supervisor took me on a walking tour through the computer, an ERA 1103 which occupied most of a large room. His most memorable comment was, "Now listen, We're paying this computer six hundred dollars an hour, and we're paying you two hundred dollars an hour, and I want you to act accordingly." This created ...

Appeared In: Capers Jones, Principles of Software Cost Estimating, McGraw-Hill, 1998


Return to Technical Report System

Copyright 1995, 1996, 1997, 1998, 1999 The University of Southern California

The written material, text, graphics, and software available on this page and all related pages may be copied, used, and distributed freely as long as the University of Southern California as the source of the material, text, graphics or software is always clearly indicated and such acknowledgement always accompanies any reuse or redistribution of the material, text, graphics or software; also permission to use the material, text, graphics or software on these pages does not include the right to repackage the material, text, graphics or software in any form or manner and then claim exclusive proprietary ownership of it as part of a commercial offering of services or as part of a commercially offered product.