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

Technical Reports

Expand All Reports

• USC-CSE-95-509 - The WinWin Spiral Software Process Model (Barry Boehm, Prasanta Bose)

  1. Barry Boehm, Prasanta Bose, "The WinWin Spiral Software Process Model," Proceedings, 3rd ICSP, 1994 (pdf)

     A primary difficulty in applying the Spiral model has been the lack of explicit process guidance in determining the prospective system's objectives, constraints, and alternatives that get elaborated in each cycle. This paper presents an extension of the spiral model, called the WinWin process model, which uses the Theory W (win-win) approach to converge on a system's next level objectives, constraints, and alternatives. The WinWin Spiral model explicitly addresses the need for concurrent analysis, risk resolution, definition, and elaboration of both the software product and software process in a collaborative manner. The paper discusses an application of the model, identifies the need for support systems to facilitate cost-effective realization of the model, and describes bootstrap experiments that lead to identifying key capabilities of support systems for the model. The key elements of the evolved WinWin support system developed to meet the needs are also discussed.

• USC-CSE-95-508 - Cost Models for Future Software Life Cycle Processes: COCOMO 2.0 (Barry Boehm, Bradford Clark, Ellis Horowitz, Chris Westland, Ray Madachy, Richard Selby)

  1. Barry Boehm, Bradford Clark, Ellis Horowitz, Chris Westland, Ray Madachy, Richard Selby, "Cost Models for Future Software Life Cycle Processes: COCOMO 2.0," Annals of Software Engineering, Springer Netherlands, Volume 1, Number 1, December, 1995, pp. 57-94 (pdf)

     Current software cost estimation models, such as the 1981 Constructive Cost Model (COCOMO) for software cost estimation and its 1987 Ada COCOMO update, have been experiencing increasing difficulties in estimating the costs of software developed to new life cycle processes and capabilities. These include non-sequential and rapid-development process models; reuse-driven approaches involving commercial off the shelf (COTS) packages, reengineering, applications composition, and applications generation capabilities; object-oriented approaches supported by distributed middleware; and software process maturity initiatives.

     This paper summarizes research in deriving a baseline COCOMO 2.0 model tailored to these new forms of software development, including rationales for the model decisions. The major new modeling capabilities of COCOMO 2.0 are a tailorable family of software sizing models, involving Object Points, Function Points, and Source Lines of Code; nonlinear models for software reuse and reengineering; an exponent-driver approach for modeling relative software diseconomies of scale; and several additions, deletions, and updates to previous COCOMO effort-multiplier cost drivers. This model is serving as a framework for an extensive current data collection and analysis effort to further refine and calibrate the model’s estimation capabilities.

• USC-CSE-95-507 - Anchoring the Software Process (Barry Boehm)

  1. Barry Boehm, "Anchoring the Software Process," IEEE Software, July 1996 (pdf)

     The current proliferation of software process models provides flexibility for organizations to deal with the unavoidably wide variety of software project situations, cultures, and environments. But it weakens their defenses against some common sources of project failure, and leaves them with no common anchor points around which to plan and control. This article identifies three milestones -- Life Cycle Objectives, Life Cycle Architecture, and Initial Operational Capability -- which can serve as these common anchor points. It also discusses why the presence or absence of these three milestones or their equivalents is a critical success factor, particularly for large software projects, but for other software projects as well.

• USC-CSE-95-506 - Aids for Identifying Conflicts Among Quality Requirements (Barry Boehm, Hoh Peter In)

  1. Barry Boehm, Hoh Peter In, "Aids for Identifying Conflicts Among Quality Requirements," Proceedings, ICRE-96, and IEEE Software, March 1996 (pdf)

     One of the biggest risks in software requirements engineering is the risk of over emphasizing one quality attribute requirement (e.g., performance) at the expense of others at least as important (e.g., evolvability and portability). This paper describes an exploratory knowledge-based tool for identifying potential quality attribute risks and conflicts early in the software/system life cycle.

     The Quality Attribute Risk and Conflict Consultant (QARCC) examines the quality attribute tradeoffs involved in software architecture and process strategies (e.g., one can improve portability via a layered architecture, but usually at some cost in performance). It operates in the context of the USC-CSE WinWin system, a groupware support system for determining software and system requirements as negotiated win conditions.

• USC-CSE-95-505 - Conceptual Design Model based Requirements Analysis in the WinWin Framework for Concurrent Requirements Engineering (Prasanta Bose)

  1. Prasanta Bose, "Conceptual Design Model based Requirements Analysis in the WinWin Framework for Concurrent Requirements Engineering," International Workshop on Software Specification and Design, IWSSD, 1995 (pdf)

     The WinWin framework provides a domain independent framework for the stakeholders to collaborate and negotiate in the requirements engineering phase of the software lifecycle. Requirements engineering in the framework leads to defining a win-win requirements model expressed using a set of conceptual elements that record stakeholderUs objectives, constraints, concerns and negotiated agreements.

     A major problem confronted in the current WinWin framework is win-win requirements model analysis that lead to mapping the win-win requirements model which is primarily problem oriented to a solution-oriented requirements specification model that aids in win condition analysis and consequently negotiation.

     This paper presents a constructive and goal-directed modeling approach to aid in win-win requirements model analysis. The approach involves concurrently elaborating a high-level conceptual design model along with the win-win model creation. The design model representation makes explicit partially specified constraints that form the conceptual architectural basis of the win-win requirements model and aids in win-win requirements model analysis.

     In this paper we present the key ideas of our approach: a) defining a domain-independent ontology for conceptual modeling of high-level design and its relationship with the WinWin model b) win-win artifact based representation of analysis goals and an abstract domain independent theory that encapsulate the conditions for satisfying the goals, and c) defining capabilities of an extended WinWin support system that to aid in analysis.

• USC-CSE-95-504 - A Model for Decision Maintenance in the WinWin Collaboration Framework (Prasanta Bose)

  1. Prasanta Bose, "A Model for Decision Maintenance in the WinWin Collaboration Framework," Proceedings of The 10th Knowledge-Based Software Engineering Conference, KBSE, 1995, p. 105 (pdf)

     Cost-effective engineering and evolution of complex software must involve the different stakeholders concurrently and collaboratively. The hard problem is providing computer support for such collaborative activities. The WinWin approach being developed and experimented at the USC Center for Software Engineering provides a domain independent solution for the stakeholders to cooperate in the requirements engineering phase of the software lifecycle.

     The key ideas in the WinWin approach and its support are: i) defining a win-win process for obtaining requirements through collaboration and negotiation, ii) defining a decision rationale model using a minimal set of conceptual elements, such as win conditions, issues, options and agreements, that serves as an agreed upon ontology for collaboration and negotiation defined by the winwin process, and, iii) defining a support framework, based on manipulation of explicit representation of the decision rationale and reasoning about it.

     A major problem confronted in the WinWin framework is aiding decision coordination - coordinating the decision making activities of the stakeholders. A key element in supporting decision coordination is decision maintenance. As decisions undergo evolution, the effects of such changes on existing decision elements must be determined and the decision structure appropriately revised.

     This paper presents an approach to addressing the problem of supporting decision maintenance. The key ideas involve a) defining an extended ontology for decision rationale, that models the WinWin decision space and their states, b) formally describing a theory based on that ontology that specify conditions for states to hold, and c) defining an agent that utilizes the theory to determine revisions and coordinate with other agents to propagate revisions in a distributed support framework.

• USC-CSE-95-503 - Reasoning about the Composition of Heterogeneous Architectures (Ahmed Abd-Allah, Barry Boehm)

  1. Ahmed Abd-Allah, Barry Boehm, "Reasoning about the Composition of Heterogeneous Architectures," Qualifying Proposal (pdf)

     A persistent problem in software engineering is how to put software systems together out of smaller subsystems: the problem of software composition. The emergence of software architectures and architectural styles has focused attention on a new set of abstractions with which we can create and compose software systems. We examine the problem of providing a model for the composition of different architectural styles within software systems, i.e. the problem of composing heterogeneous architectures. We describe a model of pure styles and of their composition. We provide a disciplined approach to the process of architectural composition, and techniques for using the approach to determine architectural constraints and the conditions under which systems will fail to be composed.

• USC-CSE-95-502 - Composing Heterogeneous Software Architectures (Ahmed Abd-Allah)

  1. Ahmed Abd-Allah, "Composing Heterogeneous Software Architectures" (pdf)

     A persistent problem in computer science is how to put software systems together out of smaller subsystems, the problem of software composition. The emergence of software architectures and architectural styles has introduced a higher level of abstraction at which we can create and compose software systems. We examine the problem of providing formal semantics to the composition of different architectural styles within software systems, i.e. the problem of composing heterogeneous architectures. We describe a theory of pure styles, and a theory of their composition. We show a disciplined approach to the process of architectural composition, and how to use the approach to bring out architectural constraints and under what conditions can styles be composed.

• USC-CSE-95-501 - Exploiting Domain Architectures in Software Reuse (Cristina Gacek)

  1. Cristina Gacek, "Exploiting Domain Architectures in Software Reuse," Proceedings, ACM-SIGSOFT Symposium on Software Reusability (SSR'95), ACM Press, Seattle, WA, April 28-30, 1995, pp. 229-232 (pdf)

     This paper provides motivation towards the use of domain specific repositories and DSSA's. It shows many of the positive side-effects this usage brings about. An extension to the faceted approach to components classifi cation [Prieto-Diaz and Freeman 1987] is introduced. Our exten sion suggests a natural way of further benefiting from the use of domain specific repositories.

• USC-CSE-95-500 - On the Definition of Software System Architecture (Cristina Gacek, Ahmed Abd-Allah, Bradford Clark, Barry Boehm)

  1. Cristina Gacek, Ahmed Abd-Allah, Bradford Clark, Barry Boehm, "On the Definition of Software System Architecture," Proceedings, First International Workshop on Architectures for Software Systems, in Cooperation with the 17th International Conference on Software Engineering, D. Garlan (ed.), Seattle, WA, April 24-25, 1995, pp. 85-95 (pdf)

     Although several definitions of "software architecture" have been presented, none of them to date enable a reviewer confronted with a complex of diagrams and symbols to determine whether it is an architecture for a system or not. We present a definition of "software system architecture" which provides a set of criteria for mak ing this determination. It is based on making the architectural rationale a first-class citizen in the definition, and on requiring the rationale to ensure that the architecture's components, connections, and constraints define a system that will satisfy a set of defined stakeholder needs for the system.

• USC-CSE-95-499 - Software Process Architectures (Barry Boehm)

  1. Barry Boehm, "Software Process Architectures," Proceedings of the First International Workshop on Architectures For Software Systems, Seattle, WA (pdf)

     Beginning with the paper, "Software Processes are Software Too," [Osterweil, 1987], an attractive line of software process research has developed involving the exploitation of a duality between software products and software processes. This duality can be expressed as,

     "If a given approach (disciplined programming, requirements definition and validation, reuse, risk management, peformance modeling) is good for software products, then its process counterpart is good for software processes."

     Given that differences exist between software products and software processes (software products are executed by machines; software processes are executed by combinations of people and machines), this duality cannot be pushed too hard or applied unthinkingly. But, as seen in a number of papers in the series of International Conferences on the Software Process, this duality has provided useful insights and results in such process areas as process life-cycles [Feiler-Humphrey, 1993], process requirements [Dowson, 1993], process validation [Cook-Wolf, 1994], and process evolution [Bandinelli et al., 1994].

     This paper addresses the hypothesis, "If architectures and architecting are good for software products, then their process architecture counterparts will be good for software processes." The following sections address major software product architecture subarenas (architectural elements; architectural styles; system architectures; domain and product line architectures; and enterprise architectures), and elaborate on their software process architecture counterparts.

• USC-CSE-95-498 - Automated Method for Identifying and Prioritizing Project Risk Factors (Gregory Toth)

  1. Gregory Toth, "Automated Method for Identifying and Prioritizing Project Risk Factors," Automated Software Engineering, Volume 2, Number 3, September, 1995, pp. 231-248 (pdf)

     This paper describes an approach for automatically determining project risk factors based on answers to an interactive questionnaire. Stored knowledge of complex interrelationships is used to transform qualitative inputs into quantitative factors used to rank and compare identified risks. A tool called the Software Technology Risk Advisor is described which implements these techniques and provides a testbed for further refinement.

     Added June 25th, 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.