Technical Reports

 

 

Return to Technical Report System

 


USC-CSE-2001-513 PDF

 

Risk-Based Strategic Software Design

 

Barry Boehm, Dan Port

 

Risk consideration is a valuable assessment aid when making strategic software design decisions. Expressing development considerations in terms of risk exposures over an independent variable (e.g. time, cumulative effort, etc.) enables the quantitative assessment of typically qualitative attributes. Assuming total risk exposure is additive over individual risk exposure functions, optimal levels for the individual considerations can be identified as function of loss-magnitude and loss-probability estimates for risk sources. Such levels provide strategic trade off considerations (with respect to risk) and have proven valuable in several previous applications such as “how much testing is enough” with respect to defect removal and market window strategic risk considerations. Here we consider a similar application for making strategic design decisions in determining how much effort (or time) should be spent evaluating COTS products with respect to project cost, market window, and a multitude of COTS assessment attributes such as availability, ease of use, maturity, and vendor support.

 

Document characteristics: Economics-Driven Software Engineering Research, Toronto Canada, May 2001
added: June 24, 2004

 


USC-CSE-2001-512 PDF

 

Applying WinWin to Quality Requirements: A Case Study

 

Hoh In, Barry Boehm, Thomas Rodgers, Michael Deutsch

 

 

Document characteristics: 23rd ISCE 2001, pp. 555-564
added: June 24, 2004

 


USC-CSE-2001-511 PDF

 

EasyWinWin: A Groupware-Supported Methodology for Requirement Negotiation

 

Barry Boehm, Paul Grunbacher, Robert O. Briggs

 

EasyWinWin is a requirement definition methodology that builds on the win-win negotiation approach and leverages collaborative technology to improve the involvement and interaction of the key stakeholders. With EasyWinWin, stakeholders move through a step-by-step win-win negotiation where they collect, elaborate, and prioritize their requirements, and then surface and resolve issues.

 

Document characteristics: 8th European Software Engineering Conference (ESEC), 9th ACM SIGSOFT Symposium on The Foundations of Software Engineering (FSE-9), September 2001, pp. 320-321
added: June 24, 2004

 



USC-CSE-2001-510 PDF

 

Software Defect Reduction Top 10 List

 

Victor R. Basili, Barry Boehm

 

Recently, a National Science Foundation grant enabled us to establish the Center for Empirically Based Software Engineering. CeBASE seeks to transform software engineering as much as possible from a fad-based practice to an engineering-based practice through derivation, organization, and dissemination of empirical data on software development and evolution phenomenology. The phrase as much as possible” reflects the fact that software development must remain a people-intensive and continually changing field. We have found, however, that researchers have established objective and quantitative data, relationships, and predictive models that help software developers avoid predictable pitfalls and improve their ability to predict and control efficient software projects.

 

Document characteristics: Computer, January 2001, pp. 135-137
added: June 24, 2004

 


USC-CSE-2001-509 PDF

 

Balancing Discipline and Flexibility with The Spiral Model and MBASE

 

Barry Boehm and Daniel Port

 

This article details how the spiral model and its recent extension, Model-Based Architecting and Software Engineering (MBASE) can be used to tailor a project’s balance of discipline and flexibility via risk considerations. It also describes and rationalizes the major MBASE extensions to the spiral model – model clash avoidance, stakeholder win-win – and elaborates on the use of these extensions and risk considerations in the anchor-point milestones used in MBASE and the spiral model.

 

 

Document characteristics: CrossTalk: The Journal of Defense Software Engineering, December 2001, pp. 23-28
added: June 24, 2004

 



USC-CSE-2001-508 PDF

 

Developing Groupware for Requirements Negotiation: Lessons Learned

 

Barry Boehm, Paul Grunbacher, Robert O. Briggs

 

Defining requirements is a complex and difficult process, and defects in the process often lead to costly project failures.1 There is no complete and well-defined set of requirements waiting to be discovered in system development. Different stakeholders—users, customers, managers, domain experts, and developers—come to the project with diverse expectations and interests. Requirements emerge in a highly collaborative, interactive, and interdisciplinary negotiation process that involves heterogeneous stakeholders.

 

 


Document characteristics:
IEEE Software, May/June 2001, pp. 46-55
added: June 24, 2004

 



USC-CSE-2001-507 PDF

 

Using Service Utilization Metrics to Assess and Improve Product Line Architectures

 

Andre van der Hoek, Ebru Dincel, Nenad Medvidovic

 

Metrics have long been used in software engineering to measure, evaluate, and improve software products and processes. Many metrics have been developed and their subsequent use in different settings has led to varying levels of success. Software architecture is a discipline in which few metrics have been applied, a surprising fact given the important role that software architecture plays in software development. Software product line architectures represent one area of software architecture in which metrics can be of especially great use. The critical importance of the structure defined by a product line architecture requires that its properties be meaningfully assessed and that informed architectural decisions be made to guide its evolution. In this paper, we present several novel metrics that we have designed to address this issue. These metrics are based on the concept of service utilization and are designed to take into account the context in which individual architectural elements are placed. We show the utility of the metrics by applying them in a case study involving a digital library product line architecture. In doing so, we demonstrate how the metrics illustrate deficiencies that, when addressed, improve the overall structural quality of the product line architecture.

 


Document characteristics:
added: March 14, 2002

 



USC-CSE-2001-506 PDF

 

Architectural Support for programming in the Many

 

Nenad Medvidovic, Marija Mikic-Rakic

 

Over the past several decades software researchers and practitioners have proposed various approaches, techniques, and tools for developing large-scale software systems. The results of these efforts have been characterized as programming-in-the-large (PitL). A new set of challenges has arisen with the emergence of inexpensive, small, heterogeneous, resource-constrained, possibly embedded, highly-distributed, and highly-mobile computing platforms. We refer to software development in this new setting as programming-in-the-many (PitM). This paper presents an approach intended to address the challenges of PitM. The centerpiece of our approach is a software architectural style with explicit support for the needs of PitM applications: selfawareness, distribution, heterogeneity, dynamism, mobility, and disconnected operation. The style is accompanied by a set of implementation, deployment, and runtime evolution tools targeted to a variety of traditional (i.e., desktop) and mobile computing platforms. Our approach has been successfully applied on a number of applications. While several issues pertaining to PitM remain areas of future work, our experience to date has been very positive.

 


Document characteristics:
added: March 14, 2002

 



USC-CSE-2001-504 PDF

 

COTS-Based Systems Top 10 List

 

Victor Basili, Barry Boehm

 

In the January 2001 issue of Computer (pp. 135-137), we published the Software Defect Reduction Top 10 List—one of two foci pursued by the National Science Foundation-sponsored Center for Empirically Based Software Engineering (CeBASE).

COTS-based systems (CBS) provide the other CeBASE focus. For our intent, COTS software has the following char-acteristics: The buyer has no access to the source code; the vendor controls its development; and it has a nontrivial installed base (that is, more than one cus-tomer; more than a few copies).

 

Document characteristics:
added: May 15, 2001

 



USC-CSE-2001-503 PDF

 

The CeBASE Framework for Strategic Software Development and Evolution

 

Barry Boehm, Victor Basili

 

One of the challenges highlighted in the EDSER-3 Call for Papers is for a symmetric approach to cost, risk, benefit, and opportunity modeling and management. This position paper offers the CeBASE Method as a response to this challenge. It is the result of an effort by the CeBASE principals at USC and U. of Maryland to reconcile their various models of software phenomenology into a common framework for pursuing empirical software engineering research and for organizing the results into a useful experience base.

 

Document characteristics:
added: May 15, 2001

 



USC-CSE-2001-502 PDF

 

Mastering Rapid Delivery and Change with The SAIV Process Model

 

Barry Boehm, A. Winsor Brown

 

Ensuring on time, within-budget delivery is increasingly difficulty in the information technology (IT) field because of the increasingly rapid rate of requirement volatility of IT systems under development. This paper describes the Model-Based (System) Architecting and Software Engineering (MBASE)’s Schedule as Independent Variable (SAIV) approach to this problem, and illustrates the nature of the solution with examples.

 

Document characteristics:

 



USC-CSE-2001-501 PDF

Understanding the Spiral Model as a Tool for Evolutionary Acquisition

Barry Boehm, Wilfred J. Hansen

 

Since its original publication [Boehm 88], the spiral development model has been used successfully in many defense and commercial projects. To extend this base of success the Department of Defense (DoD) has recently rewritten the defense acquisition regulations to incorporate"evolutionary acquisition," an acquisition strategy designed to mesh well with spiral development. In particular, DoD Instruction 5000.2 subdivides acquisition [DoD 00]: "There are two ... approaches, evolutionary and single step to full capability. An evolutionary approach is preferred. … [In this] approach, the ultimate capability delivered to the user is divided into two or more blocks, with increasing increments of capability."…

 

Document characteristics: Submitted to ICSE 2001
added: February 22, 2001



USC-CSE-2001-500 PDF

Avoiding the Software Model-Clash Spiderweb

Barry Boehm,  Dan Port, Mohammed, Al-Said

Analysts frequently describe troubled projects with the tarpit metaphor used so effectively in Fred Brooks’s The Mythical Man-Month (2nd ed., Addison-Wesley, Reading, Mass., 1995). We have found a similarly effective metaphor: Think of a troubled software project as an insect caught in a spiderweb of sticky constraints, trying desperately to break free before the spider arrives to feed.

Document characteristics:
added: May 15, 2001

 

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.