Home   Contact Us    
Center for Systems and Software Engineering

About us
News
History
People
Events
Upcoming
Highlights
Past
Tech. Report
By Author
Research
Projects
Tools
Courses
Education
Degrees
Admissions
Affiliates
List of Affiliates
Private Area
Other Resources


Technical Reports

USC-CSE-97-510

Bradford Clark, "The Effects of Process Maturity on Software Development Effort," Ph.D. Dissertation (pdf)

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.


USC-CSE-97-509

Barry Boehm, "Process Support of Software Product Lines (ISPW 10)," Proceedings, ISPW 10, June 1996, pp. 2-6 (pdf)

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.


USC-CSE-97-508

Barry Boehm, Alexander Egyed, "WinWin Requirements Negotiation Processes: A Multi-Project Analysis," Proceedings, ICSP'98, pp. 125-136 (pdf)

Fifteen 6-member-teams were involved in negotiating requirements for multimedia software systems for the Library of the University of Southern California. The re-quirements negotiation used the Stakeholder WinWin success model and the USC WinWin negotiation model (Win Condition-Issue-Option-Agreement) and groupware system. 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 rationale. 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 effective LCO packages, in satisfying Library clients, and in stimulating cooperation among stakeholders. Other hypotheses involved identification of WinWin improvements, relationships among negotiation strategies on LCO pack-age and project outcomes.


USC-CSE-97-507

Barry Boehm, Bradford Clark, Sunita Chulani, "Calibration Results of COCOMOII.1997," presented at the SEPG-98 (pdf)

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.


USC-CSE-97-506

Cristina Gacek, "Detecting Architectural Mismatches During Systems Composition," Qualifying Report for partial fulfillment of Computer Science Department requirements (pdf)

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.


USC-CSE-97-505

Sunita Chulani, "Results of Delphi for the Defect Introduction Model (Sub-Model of the Cost/Quality Model Extension to COCOMO II)" (pdf)

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.


USC-CSE-97-504

Barry Boehm, Alexander Egyed, Julie Kwan, Ray Madachy, "Developing Multimedia Applications with the WinWin Spiral Model," Proceedings, ESEC/FSE 97, Springer Verlag, 1997, pp. 20-39 (pdf)

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.


USC-CSE-97-503

Ellis Horowitz, "WinWin Reference Manual--A System for Collaboration and Negotiation," this is the WinWin Reference Manual as of June 1997 (updated 1999) (pdf)

WinWin is a computer program that aids in the capture, negotiation, and coordination of requirements for a arge 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.


USC-CSE-97-502

Cristina Gacek, "Detecting Architectural Mismatches During Systems Composition--An Extension to the AAA Model" (pdf)

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

Ahmed Abd-Allah, "Extending Reliability Block Diagrams to Software Architectures" (pdf)

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.


USC-CSE-97-500

Barry Boehm, "Experiences in Software Cost Modeling," Principles of Software Cost Estimating, Capers Jones, McGraw-Hill, 1998 (pdf)

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 some good habits for me, such as careful desk checking, test planning, and analyzing before coding. But it also created some bad habits-a preoccupation with saving microseconds, patching object code, etc.-which were hard to unlearn when the balance of hardware and software costs began to tip the other way.


Copyright 2008 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.