University of Southern California
    
Home   Contact Us    
Center for Systems and Software Engineering

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


Technical Reports

USC-CSE-89-505

Barry Boehm, "What We Really Need Are Process Model Generators," 11th International Conference on Software Engineering, May 15-18, 1989, p. 397 (pdf)

A good many of the problems on software projects arise from mismatches between the process model used by the project and the project's real-world process drivers: budget, schedule, available commercial off-the-shelf (COTS) software, customer standards, user mission or technology uncertainties, etc. The primary process modeling approach to date for avoiding these mismatches has been to try to develop the perfect process model: one which will work well for any combination of process drivers.

Our position in this paper is that a good process model generator would be nearly as effective as the perfect process model, and much more likely to be achievable. A process model generator is a technique which operates on a project's process drivers as inputs to produce a process model for the project which is tailored to its particular process drivers.

Added June 18th, 2008


USC-CSE-89-504

Barry Boehm, Frank Belz, "Experiences with the Spiral Model as A Process Model Generator," an expanded version of Proceedings of the 5th International Software Process Workshop, 1989. Experience with Software Process Models, October 10-13, 1989, pp. 43-45 (pdf)

Many of the problems on software projects arise from mismatches between the process model used by the project and the project's real-world process drivers, such as budget, schedule, and available commercial off-the-shelf (COTS) software. The primary process modeling approach to date for avoiding these mismatches has been to try to develop the perfect process model: one which will work well for any combination of process drivers.

Our position is that a good process model generator would be nearly as effective as the perfect process model, and much more likely to be achievable. A process model generator is a technique which operates on a project's process drivers as inputs to produce a process model for the project which is tailored to its particular process drivers.

We have had several experiences in using the Spiral Model [Boehm, 19881 as a process model generator. Our initial experience in generating a process model for the TRW Quantum Leap program was reported in the previous workshop [Boehm-Belz, 19883. Subsequent experiences have generated some significantly different process models for avionics, command-control, exploratory research projects, and small fourth-generation language (4GL) based systems.

Below, we provide a short summary of the use of the spiral model as a process model generator, and a summary of the various process model generation experiences in terms of a Process Model Decision Table showing the critical process driver conditions under which the most familiar process models (e.g., waterfall [Royce, 1970], evolutionary development [McCracken-Jackson, 1982], and transform [Balzer-Cheatham-Green, 1988]) are the appropriate choice of a process model for a particular software project.

Added June 18th, 2008


USC-CSE-89-503

Barry Boehm, Walker Royce, "Ada COCOMO and the Ada Process Model," Proceedings, Fifth COCOMO Users' Group Meeting, Software Engineering Institute, Pittsburgh, PA, November 1989 (pdf)

The original version of the Constructive Cost Model (COCOMO) [Boehm, 1981] was calibrated to 56 software development projects, and validated on 7 subsequent projects. On these projects, the COCOMO development effort estimates were accurate within 20% of the project actuals, about 70% of the time.

Subsequently, COCOMO has done approximately as well on most carefully collected sets of project data [Boehm, 1985; Jopen, 1985; Goudy, 1987]. In some cases, COCOMO has exhibited a systematic bias, but has done approximately as well once recalibrated to the specific environment [Boehm, 1985; Miyazaki-Mori, 1985; Marouane-Mili, 1989]. It should be noted that there are also some sets of project data for which COCOMO has been considerably less accurate [Kemerer,1987; Martin, 1988].

Recently, three software development approaches have motivated the development of a revised version of COCOMO: the use of the Ada programming language, the use of incremental development, and the use of an Ada process model capitalizing on the strengths of Ada to improve the efficiency of software development. This paper presents the portions of the revised Ada COCOMO dealing with the effects of Ada and the Ada process model.The remainder of this section of the paper discusses the objectives of Ada COCOMO. Section 2 describes the Ada Process Model and its overall effects on software development effort and schedule. Section 3 presents the structure and features of Ada COCOMO, and discusses the rationale behind the changes made from the earlier version of COCOMO (called "standard COCOMO" in the remainder of the paper). Section 4 summarizes the current status of Ada COCOMO, including its calibration to date and its currently available implementations; and Section 5 presents the resulting conclusions.

Added June 18th, 2008


USC-CSE-89-502

Walker Royce, "Ada Process Model," SEDD Guidebook, TRW System Engineering and Development Division, November 1989 (pdf)

In 1984 TRW initiated an Independent Reearch and Development project entitled "Ada Applicability For C3 Systems" to evaluate the maturity of the Ada language for large, realtime Command, Control, and Communications (c3) projects such as the Command Center Processing and Display Systun - Replacement (CCPDS-R). Over the next three years, the IRAD resulted in many products, one of which, wes a new approach for developing Ada softsare. The fundamental philosophy inherent in this new approach was to exploit the strengths of Ada as a complete life cycle language in order to effect a more consistent, continuous, and controlled evolution of large, complex software products.

In paralle1,the CCPDS-B project (then in a-proposal anctcompctitive Design-phase) proposed this approach for the large, risky software development task of the FUI Scale Development Contract. Between the extensive early planning for the CCPDS-R software development activities and the continuous incorporation of subsequent lessons learned in a real world application, this approach has proven highly successful.

Added June 18th, 2008


USC-CSE-89-501

Barry Boehm, "Rapid Prototyping, Risk Management, 2167, and the Ada Process Model," Software Risk Management, 1989, pp. 47-52 (pdf)

DoD-STD-2167A offers sufficient degrees of freedom to appropriately accommodate rapid prototyping into a software development, given that one has an appropriate process model to substitute for the waterfall model, which otherwise tends to be used as the default implementation of 2167A.

TRW has been developing an Ada Process Model which incorporates the strengths of Ada, rapid prototyping, risk management, and the Spiral Model into a model which can be expressed as a tailored version of DoD-STD-2167A. We have also been developing an Ada version of the Constructive Cost Model (COCOMO) for software cost estimation, which reflects the added efficiencies of using Ada and the Ada Process Model.

Added June 18th, 2008


USC-CSE-89-500

Barry Boehm, Rony Ross, "Theory-W Software Project Management Principles and Examples," IEEE Transactions on Software Engineering, Volume 15, Issue 7, July 1989, pp. 902-916 (pdf)

A software project management theory is presented called Theory W: make everyone a winner. The authors explain the key steps and guidelines underlying the Theory W statement and its two subsidiary principles: plan the flight and fly the plan; and, identify and manage your risks. Theory W's fundamental principle holds that software project managers will be fully successful if and only if they make winners of all the other participants in the software process: superiors, subordinates, customers, users, maintainers, etc. Theory W characterizes a manager's primary role as a negotiator between his various constituencies, and a packager of project solutions with win conditions for all parties. Beyond this, the manager is also a goal-setter, a monitor of progress towards goals, and an activist in seeking out day-to-day win-lose or lose-lose project conflicts confronting them, and changing them into win-win situations. Several examples illustrate the application of Theory W. An extensive case study is presented and analyzed: the attempt to introduce new information systems to a large industrial corporation in an emerging nation. The analysis shows that Theory W and its subsidiary principles do an effective job both in explaining why the project encountered problems, and in prescribing ways in which the problems could have been avoided.

Added November 11th, 2005


USC-CSE-89-499

Barry Boehm, "Software Factories in the USA," Proceedings of the IFIP 11th World Computer Congress, San Francisco, August 28 - September 1, 1989, pp. 701-703 (pdf)

Software factory technology and practice in the USA has recently accelerated rapidly with the boom in the CASE (Computer Aided Software Engineering) market. Concerns about long-range international competitiveness caused most large USA corporations to focus on corporate restructuring to achieve leaner, more adaptive modes of operation. Concerns with Federal deficits caused similar pressures on USA Government organizations. In the data processing area, this frequently led to downstaffing and attempts to more effectively capitalize software development and maintenance via personal workstations, improved practices and procedures, and CASE tools. This short survey provides a summary of the primary elements of the USA software factory situation in 1989, and a representative set of software factory lessons learned at TRW.

Added June 18th, 2008


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.