|
Technical Reports
USC-CSE-2001-514
Barry Boehm, Dan Port, "Educating Software Engineering Students to Manage Risk," Proceedings of the 23rd International Conference on Software Engineering, Toronto, Canada, May 12-19, 2001, pp. 591-600 (pdf)
In 1996, USC switched its core two-semester software engineering course from a hypothetical-project, homework-and-exam course based on the Bloom taxonomy of educational objectives (knowledge, comprehension, application, analysis, synthesis, evaluation). The revised course is a real-client team-project course based on the CRESST model of learning objectives (content understanding, problem solving, collaboration, communication, and self-regulation). We used the CRESST cognitive demands analysis to determine the necessary student skills required for software risk management and the other major project activities, and have been refining the approach over the last four years of experience, including revised versions for one-semester undergraduate and graduate project course at Columbia.
This paper summarizes our experiences in evolving the risk management aspects of the project course. These have helped us mature more general techniques such as risk-driven specifications, domain specific simplifier and complicator lists, and the schedule as an independent variable (SSIV) process model. The largely positive results in terms of review padfail rates, client evaluations, product adoption rates, and hiring manager feedback are summarized as well.
Added July 18th, 2008
USC-CSE-2001-513
Barry Boehm, Dan Port, "Risk-Based Strategic Software Design," Economics-Driven Software Engineering Research, Toronto, Canada, May 2001 (pdf)
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.
Added June 24th, 2004
USC-CSE-2001-512
Hoh Peter In, Barry Boehm, Thomas Rodgers, Michael Deutsch, "Applying WinWin to Quality Requirements: A Case Study," 23rd ISCE, 2001, pp. 555-564 (pdf)
This paper describes the application of the WinWin paradigm to identify and resolve conflicts in a series of real-client, student-developer digital library projects. The paper is based on a case study of the statistical analysis of 15 projects and an in-depth analysis of one representative project. These analyses focus on the conflict resolution process, stakeholders' roles and their relationships to quality artificats, and tool effectiveness.
Added June 24th, 2004
USC-CSE-2001-511
Barry Boehm, Paul Grunbacher, Robert O. Briggs, "EasyWinWin: A Groupware-Supported Methodology for Requirement Negotiation," 8th European Software Engineering Conference (ESEC), 9th ACM SIGSOFT Symposium on The Foundations of Software Engineering (FSE-9), September 2001, pp. 320-321 (pdf)
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.
Added June 24th, 2004
USC-CSE-2001-510
Victor R. Basili, Barry Boehm, "Software Defect Reduction Top 10 List," Computer, January 2001, pp. 135-137 (pdf)
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.
Added June 24th, 2004
USC-CSE-2001-509
Barry Boehm, Dan Port, "Balancing Discipline and Flexibility with The Spiral Model and MBASE," CrossTalk: The Journal of Defense Software Engineering, December 2001, pp. 23-28 (pdf)
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
USC-CSE-2001-508
Barry Boehm, Paul Grunbacher, Robert O. Briggs, "Developing Groupware for Requirements Negotiation: Lessons Learned," IEEE Software, May/June 2001, pp. 46-55 (pdf)
Defining requirements is a complex and difficult process, and defects in the process often lead to costly project failures. 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.
Added June 24, 2004
USC-CSE-2001-507
Andre van der Hoek, Ebru Dincel, Nenad Medvidovic, "Using Service Utilization Metrics to Assess and Improve Product Line Architectures," Proceedings of the 6th Ground System Architectures Workshop (GSAW 2002), El Segundo, CA, March 2002 (pdf)
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.
Added March 14th, 2001
USC-CSE-2001-506
Nenad Medvidovic, Marija Mikic-Rakic, "Architectural Support for programming in the Many" (pdf)
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.
Added March 14th, 2001
USC-CSE-2001-505
Barry Boehm, "Early Experiences in Software Economics," Software Pioneers: Contributions to Software Engineering, Springer-Verlag, 2002, pp. 632-640 (pdf)
It took me a while to appreciate software economics.
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 dollars an hour, and I want you to act accordingly."
Added May 5th, 2001
USC-CSE-2001-504
Victor Basili, Barry Boehm, "COTS-Based Systems Top 10 List," Computer, Volume 34, Number 5, May, 2001, pp. 91-93 (pdf)
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 characteristics: 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 customer; more than a few copies).
Added May 15th, 2001
USC-CSE-2001-503
Barry Boehm, Victor Basili, "The CeBASE Framework for Strategic Software Development and Evolution" (pdf)
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.
Added May 15th, 2001
USC-CSE-2001-502
Barry Boehm, A. Winsor Brown, "Mastering Rapid Delivery and Change with The SAIV Process Model," Proceedings, ESCOM 2001, April 2001, pp. 147-156 (pdf)
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.
Added February 22nd, 2001
USC-CSE-2001-501
Barry Boehm, Wilfred J. Hansen, "Understanding the Spiral Model as a Tool for Evolutionary Acquisition," CrossTalk, May 2001 (pdf)
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 [DoD00]: "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."
Added February 22nd, 2001
USC-CSE-2001-500
Barry Boehm, Dan Port, Mohammed Al-Said, "Avoiding the Software Model-Clash Spiderweb," Computer, Volume 33, Issue 11, November 2000, pp. 120-122 (pdf)
Analysts frequently describe troubled projects with the tarpit metaphor used o 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.
Added May 15th, 2001
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.
|
|
