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

About us
Tech. Report
TR by Author
List of Affiliates
Private Area
Other Resources

Technical Reports


Gregory Toth, "Software Technology Risk Advisor," Automated Software Engineering, Springer Netherlands, Volume 2, Number 3, September, 1995, pp. 231-248 (pdf)

This paper describes the Software Technology Risk Advisor (STRA), a knowledge-based software engineering tool that provides assistance in identifying and managing software technology risks. The STRA contains a knowledge base of software product and process needs, satisfying capabilities, and capability maturity factors. After a user ranks the importance of relevant needs to his or her project, the STRA automatically infers risk areas by evaluating disparities between project needs and technology maturities. Identified risks are quantitatively prioritized and the user is given risk reduction advice and rationale for each conclusion. This paper presents methods used in the STRA, along with discussions of knowledge acquisition, experimental results, current status, and related work.


Gregory Bolcer, "User Interface Design Assistance for Large-Scale Software Development," Automated Software Engineering, Springer Netherlands, Volume 2, Number 3, September, 1995, pp. 203-217 (pdf)

The User Interface Design Assistant (UIDA) addresses the specific design problems of style and integration consistency throughout the user interface development process and aids in the automated feedback and evaluation of a system's graphical user interface according to knowledge-based rules and project specific design examples. The UIDA system is able to quickly identify inconsistent style guide interpretations and UI design decisions resulting from distributed development of multiple UI sub-systems. This case arises when each sub-system conforms to the general style guide rules, but when integrated together, may appear inconsistent.


Barry Boehm, Prasanta Bose, "Critical Success Factors for Knowledge Based Software Engineering Applications," Automated Software Engineering, Springer Netherlands, Volume 2, Number 3, September, 1995, pp. 193-202 (pdf)

Ten prototype knowledge based software engineering (KBSE) applications were recently developed in a USC graduate course. These were expert-system applications falling into the Activity Coordination portion of the KBSA paradigm [Green et. al.,1983] rather than into the automatic program generation portion. The KBSE development guidelines for the prototypes included the primary critical success factor (CSF) heuristics cited in such references as [Waterman, 1986], [Jackson, 1990], and [Kelly, 1991] for identifying potentially successful expert systems applications. The resulting applications could be grouped into three categories, as follows:

i) Knowledge based process assistance
ii) Knowledge based software architecture and reuse assistance


Barry Boehm, Ming June Lee, Prasanta Bose, Ellis Horowitz, "Software Requirements Negotiation and Renegotiation Aids: A Theory-W Based Spiral Approach," 17th International Conference on Software Engineering (ICSE'95), ICSE, 1995, p. 243 (pdf)

A major problem in requirements engineering is obtaining requirements that address the concerns of multiple stakeholders. An approach to such a problem is the Theory-W based Spiral Model. One key element of this model is stakeholder collaboration and negotiation to obtain win-win requirements. This paper focuses on the problem of developing a support system for such a model. In particular, it identifies needs and capabilities required to address the problem of negotiation and renegotiation that arises when the model is applied to incremental requirements engineering. The paper formulates elements of the support system, called WinWin, for providing such capabilities. These elements were determined by experimenting with versions of WinWin and understanding their merits and deficiencies. The key elements of WinWin are described and their use in incremental requirements engineering are demonstrated, using an example renegotiation scenario from the domain of software engineering environments for satellite ground stations.


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.


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.


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.


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.


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.


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.


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.


Barry Boehm, "Software Process Architectures," Proceedings of the First International Workshop on Architectures For Software Systems, Seattle, WA, 1995 (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.


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.