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


Marij Mikic-Rakic, Nenad Medvidovic, "Adaptable Architectural Middleware for Programming-in-the-Small-and-Many," ICSE 2003 (pdf)

A recent emergence of small, resource-constrained, and highly-mobile computing platforms presents numerous new challenges for software developers. We refer to development in this new setting as programming-in-the-small-and-many (Prism). This paper provides a description and evaluation of a middleware intended to support software architecture-based development in the Prism setting. The middleware, called Prism-MW, provides highly efficient and scalable implementation-level support for the key aspects of Prism application architectures. Additionally, Prism-MW is easily extensible to support different application requirements and, in fact, different architectural styles suitable for the Prism setting. Prism-MW is accompanied with design, analysis, deployment, and run-time monitoring tool support. It has been applied in a number of applications and used as an educational tool in a graduate-level embedded systems course. Recently, Prism-MW has been successfully evaluated by a major industrial organization for use in one of their key distributed embedded systems. Our experience with the middleware indicates that the principles of architecture-based software development can be successfully, and flexibly, applied in the Prism setting.

Added October 15th, 2002


Nenad Medvidovic, Paul Gruenbacher, Alexander Egyed, Barry Boehm, "Bridging Models across the Software Lifecycle," Journal of Systems and Software, Special issue: Best papers on Software Engineering from the SEKE'01 Conference, Volume 68, Issue 3, December 2003, pp. 199-215 (pdf)

Numerous notations, methodologies, and tools exist to support software system modeling. While individual models may clarify certain system aspects, the large number and heterogeneity of models may ultimately hamper the ability of stakeholders to communicate about a system. A major reason for this is the discontinuity of information across different models. In this paper, we present an approach for dealing with that discontinuity. We introduce a set of transformations to bridge models, both within and across the “upstream” activities in the software development lifecycle (specifically, requirements, architecture, and design). While the details of these transformations are dependent upon the source and destination models, they share a number of underlying characteristics. These characteristics can be used as a starting point in providing a general understanding of transformations between software models. We illustrate our approach by applying it to a large-scale system we are currently designing and implementing in collaboration with a third-party organization.

Added November 13th, 2000


Barry Boehm, "Value-Based Software Engineering," ACM SIGSOFT Software Engineering Notes, Volume 28, Issue 2, March 2003 (pdf)

Much of current software engineering practice and research is done in a value-neutral setting, in which every requirement, use case, object, and defect is treated as equally important; methods are presented and practiced as largely logical activities; and a “separation of concerns” is practiced, in which the responsibility of software engineers is confined to turning software requirements into verified code. In earlier times, when software decisions had relatively minor influences on a system’s cost, schedule, and value, the value-neutral approach was reasonably workable. But today and increasingly in the future, software has a major influence on most systems’ cost, schedule, and value; and value-neutral software decisions can seriously degrade project outcomes.

This paper presents an agenda for a discipline of Value-Based Software Engineering. It accepts the challenge of integrating value considerations into all of the existing and emerging software engineering principles and practices, and of developing an overall framework in which they compatibly reinforce each other. Example elements of this agenda include value-based requirements engineering, architecting, design and development, verification and validation, planning and control, risk management, quality management, and people management. It presents seven key elements that provide candidate foundations for value-based software engineering: Benefits Realization Analysis; Stakeholder Value Proposition Elicitation and Reconciliation; Business Case Analysis; Continuous Risk and Opportunity Management; Concurrent System and Software Engineering; Value-Based Monitoring and Control; and Change as Opportunity.

Added July 18th, 2008


Barry Boehm, Dan Port, Ye Yang, Jesal Bhuta, Chris Abts, "Composable Process Elements for Developing COTS-Based Applications," Proceedings, ISESE 2003, September/October 2003 (pdf)

Data collected from five years of developing e-service applications at USC-CSE reveals that an increasing fraction have been commercial-off-the-shelf (COTS)-Based Application (CBA) projects: from 28% in 1997 to 60% in 2001. Data from both small and large CBA projects show that CBA effort is primarily distributed among the three activities of COTS assessment, COTS tailoring, and glue code development and integration, with wide variations in their distribution across projects. We have developed a set of data-motivated composable process elements, in terms of these three activities, for developing CBA's as well an overall decision framework for applying the process elements. We present data regarding the movement towards CBA's and effort distribution among them; we then proceed to describe the decision framework and to present a real-world example showing how it operates within the WinWin Spiral process model generator to orchestrate, execute, and adapt the process elements to changing project circumstances.

Added June 24th, 2004


Barry Boehm, LiGuo Huang, Apurva Jain, "Reasoning About the Value of Dependability: The iDave Model," EDSER-5 Proceedings, May 2003 (pdf)

In this paper, we present a framework for reasoning about the value of information processing dependability investments called the Information Dependability Attribute Value Enhancement (iDAVE) model. We describe the overall structure of iDAVE, and illustrate its use in determining the ROI of investments in dependability for a commercial order processing system. We conclude that dynamic and adaptive value-based dependability mechanisms such as iDAVE model will become increasingly important provided evidence that dependability attribute requirement levels tend to be more emergent than pre-specifiable.

Added June 24th, 2004


Barry Boehm, Kent Beck, "Agility Through Discipline: A Debate," Computer, June 2003, pp. 44-46 (pdf)

Kent says: There are those who see agility in software development as a tradeoff, a sort of shaving of the wing spars. By giving up safety or rigor or accountability, we can go faster. From inside Extreme Programming, though, “agility or safety” or “agility or discipline” look like false dichotomies. From inside Extreme Programming, it seems that the only way to achieve the results we seek is to view the world in “both-and” terms instead of “either-or” terms. Why this disconnect?

Added June 24th, 2004


Barry Boehm, Rich Turner, "People Factors in Software Management: Lessons From Comparing Agile and Plan-Driven Methods," Crosstalk: The Journal of Defense Software Engineering, 16 (12), December 2003, pp. 4-8 (pdf)

While methodologies, management techniques, and technical approaches are valuable, a study of agile and plan-driven approaches has confirmed that the most critical success factors are much more likely to be in the realm of people factors. This paper discusses five areas where people issues can have a significant impact: staffing, culture, values, communications, and expectations management.

Added December 15th, 2003


Roshanak Roshandel, "Calculating Architectural Reliability via Modeling and Analysis," Qualification Exam Report (pdf)

Modeling and estimating software reliability during testing is useful in quantifying the quality and dependability of the developed software systems. However, such measurements applied so late in the development process leave little to be done to improve the quality of the software system in a cost-effective way. Reliability, an important dependability attribute, is defined as the probability that the system performs its intended functionality under specified design limits. We argue that reliability models must be built to estimate the system reliability throughout the development process, and specifically when exact context and execution profile of the system may be unknown, or when the implementation artifacts are not yet available. In the context of software architectures, various techniques for modeling software systems and specifying their functional properties have been developed. These techniques enable extensive analysis of the specification, but typically lack quantification. Additionally, their relation to dependability attributes of the modelled software system is unknown.

In this proposal, we present a software architecture-based approach to estimating system reliability. The approach is applicable to early stages of development when the implementation artifacts are not yet available, and exact execution profile is unknown. The uncertainty of the execution profile is modeled using stochastic processes with unknown parameters. The approach is compositional in nature: the overall reliability of the system is estimated as a function of the reliability of its constituent components and their (complex) interactions. In turn, the reliability of individual components is estimated using standard modeling and specification mechanisms of software architectures. Additionally, sensitivity analyses enabled by our reliability model prescribe defect mitigation strategies in a cost-effective manner.

Added December 15th, 2003


Nikunj R. Mehta, Nenad Medvidovic, "Alfa: A Framework for Composing Software Architectures from Architectural Primitives" (pdf)

Architectural styles represent composition patterns and constraints at the software architectural level and are targeted at families of systems with shared characteristics. They enable architectural reuse and hence can bring economy to architecture-based software development. Existing research on architectural styles provides little guidance for the systematic design and construction of architectural style elements. This paper proposes a framework, Alfa, for systematically and constructively composing “architectural primitives” to obtain elements of architectural styles. This is based on our observation that architectural styles and, indeed, software architectures share many underlying concepts that lead to architectural primitives. We have identified eight forms and nine functions as architectural primitives that reflect the syntactic and semantic characteristics of software architectures and are expressive enough to compose elements of architectural styles used in modern, distributed systems. Such an approach enables systematic construction of style-based architectures. In that direction, this paper evaluates he suitability of Alfa as an assembly language for software architectures and its suitability for composing architectural styles for network-based systems.

Added November 25th, 2003


Barry Boehm, LiGuo Huang, "Value-Based Software Engineering: Reinventing "Earned Value" Monitoring and Control," ACM SIGSOFT Software Engineering Notes, Volume 28, Issue 2, March 2003 (pdf)

The Value-Based Software Engineering (VBSE) agenda described in the preceding article has the objectives of integrating value considerations into current and emerging software engineering principles and practices, and of developing an overall framework in which they compatibly reinforce each other. In this paper, we provide a case study illustrating some of the key VBSE practices, and focusing on a particular anomaly in the monitoring and control area: the “Earned Value Management System”. This is a most useful technique for monitoring and controlling the cost, schedule, and progress of a complex project. But it has absolutely nothing to say about the stakeholder value of the system being developed. The paper introduces an example order-processing software project, and shows how the use of Benefits Realization Analysis, stakeholder value proposition elicitation and reconciliation, and business case analysis provides a framework for stakeholder-earned-value monitoring and control.

Added July 18th, 2008


Donald J. Reifer, Barry Boehm, "Model Contract/Subcontract Award Fee Plan" (pdf)

This model Award Fee Plan below has been developed by USC to provide a means to reward contractors/subcontractors for using modern software engineering techniques on large software-intensive development efforts.  It identifies the following seven critical success factors for successful contractor/subcontractor performance:

1. Schedule preservation
2. Continuous integration support
3. Cost containment
4. Technical performance
5. Architecture and COTS compatibility
6. Program management
7. Risk management

This plan provides candidate evaluation scales and weights for assessing relative contractor/subcontractor performance on the seven factors.  It also provides a set of candidate operating procedures for the subcontractor evaluation and award fee process.  It is not a plug-and-play instrument.  Instead, the plan intends to provide buyers of systems with large software content with a tailorable contractual instrument that accommodates various sources of subcontract variation.  

The terms “buyer” and “supplier” are used throughout the document to convey respective roles and responsibility of the parties to this agreement.  The “buyer” refers to the organization contracting or subcontracting work to a “supplier” organization.  It is not meant to refer to the contracting officer who is responsible for managing the contract/subcontract terms and conditions.  The term “Lead System Integrator (LSI)” is used to identify the organization assigned primary integration responsibilities for the system.

Added April 22nd, 2008


Nikunj R. Mehta, Nenad Medvidovic, "Concise Composition of Architectural Styles From Architectural Primitives" (pdf)

Architectural styles represent composition patterns and constraints at the software architectural level and are targeted at families of systems with shared characteristics. They enable architectural reuse and hence can bring economy to the design of software architecture. Existing approaches support systematic description of style-based software architectures. Our approach, Alfa, focuses on the construction, instead of description, of style-based software architectures using architectural primitives. This is based on our observation that architectural styles and, indeed, software architectures share many underlying concepts that lead to architectural primitives. Previously, Alfa’s primitives were shown to be sufficient for modeling architectural styles. In this paper, we present the composition of a diverse set of styles for network-based systems using xAlfa, a systematic notation for composing styles from Alfa’s primitives. We then show that two reuse mechanisms in xAlfa, inheritance and composition, enable concise style compositions and unambiguously bring out similarities among architectural styles.

Added October 30th, 2003


Nikunj R. Mehta, Marjan Sirjani, Farhad Arbab, "Effective Modeling of Software Architectural Assemblies Using Constraint Automata," SEN-R0309, CWI, Amsterdam, October 2003 (pdf)

Alfa is a framework for the construction of software architectures and their elements from architectural primitives. In any system involving events from multiple sources, synchrony and asynchrony between events arise naturally. Support for simultaneous synchrony and asynchrony, and scalability to assemblies of large numbers of architectural primitives are central concerns for effectively modeling software architectural assemblies in Alfa. An increasingly popular formalism for event-based modeling of the behavior of software architectures, labeled transition systems (LTS), was initially chosen to model the behavior of Alfa assemblies. However, this creates an impedance mismatch with the architect’s mental model and lacks sufficient scalability. We therefore propose a formal approach to effectively model software architectural assemblies that addresses these limitations, using constraint automata. Constraint automata can be mapped to LTS thus utilizing existing techniques for analysis of behavioral properties. We evaluate the effectiveness of our approach using two application architectures assembled from Alfa’s primitives.

Added September 25th, 2003


Roshanak Roshandel, Bradley Schmerl, Nenad Medvidovic, David Garlan, Dehua Zhang, "Using Multiple Views to Model and Analyze Software Architecture: An Experience Report" (pdf)

Architectural modeling and analysis is a critical phase in developing large and complex software systems. The usefulness of multiple views has likewise long been recognized. In this experience report, we explain how we used two ADLs to model a system initially described in UML. The system SCRover is designed and built in close collaboration with NASA’s Jet Propulsion Laboratory, using their Mission Data System technology. We describe (a) the processes that we used to extract architectural models from the UML description, (b) the way in which each ADL was used to model the system, (c) a classification of the architectural defects we uncovered, and (d) a comparison of the relative benefits of the two ADLs in terms of the different classes of defects they uncovered.

Added September 18th, 2003


Barry Boehm, LiGuo Huang, "Value-Based Software Engineering: A Case Study," IEEE Computer, Volume 36, Number 3, March 2003 (pdf)

The value-based approach to software development integrates value considerations into current and emerging software engineering principles and practices, while developing an overall framework in which these techniques compatibly reinforce each other.

Added April 26th, 2003


Roshanak Roshandel, Nenad Medvidovic, "Relating Software Component Models" (pdf)

A software component is typically modeled at one or more of four levels: interface, static behavior, dynamic behavior, and interaction protocol. Each of these levels helps to ensure different aspects of component compatibility and interoperability. Existing approaches to component modeling have either focused on only one of the levels (e.g., interfaces in various IDLs) or on well-understood combinations of two of the levels (e.g., interfaces and their associated pre- and post-conditions in static behavioral modeling approaches). This paper argues that, in order to accrue the true benefits of component-based software development, one may need to model components at all four levels. Before that can be possible, one needs to understand the relationships among the different models. We detail one such pair-wise relationship—between static and dynamic component models—and draw parallels between it and the remaining models.

Added March 26th, 2003


Nikunj R. Mehta, Nenad Medvidovic, "Composing Architectural Styles From Architectural Primitives," ESEC/FSE 2003 (pdf)

Architectural styles are named collections of constraints on configurations of architectural elements, and are believed to bring economies of scale in applying software architecture techniques to software development. Most research on architectural styles focuses on analyzing and observing the properties of such styles from their descriptions. However, comparatively little is known about the systematic design and construction of software architectures using architectural styles. Existing classifications bring out differences between architectural styles, but none provides a clear understanding of the similarities among a large number of styles. The basis of our research is the observation that architectural styles share many underlying concepts. These shared concepts lead to “architectural primitives” that can be systematically and constructively composed to obtain elements of architectural styles. We have identified eight forms and nine functions as architectural primitives that, in our understanding, reflect the syntactic and semantic characteristics of a large number of styles. While proving such a hypothesis is difficult in the general case, we demonstrate it within the domain of network-based styles. Partial formal models of style elements composed from these architectural primitives are also constructed and shown to be analyzable.

Added March 16th, 2003


Donald J. Reifer, Barry Boehm, Murali Gangadharan, "Estimating the Cost of Security for COTS Software," Proceedings of 2nd International Conference on COTS-Based Software Systems, February 2003 (pdf)

This paper describes enhancements being made to the University of Southern California's COnstructive COTS (COCOTS) integration cost model to address security concerns. The paper starts by summarizing the actions we have taken to enhance COCOMO II to model the impact of security on development effort and duration. It then relates the COCOMO II approach to the COCOTS estimating framework so that the enhancements proposed can be incorporated into the COCOTS model. After summarizing the team's progress in developing counterpart COCOTS security cost drivers and expert-consensus cost driver parameter values, the paper points to the steps that will be taken to validate the findings and calibrate the model.

Added February 28th, 2003


Barry Boehm, Dan Port, Ye Yang, Jesal Bhuta, "Not All CBS Are Created Equally: COTS-Intensive Project Types," Proceedings of 2nd International Conference on COTS-Based Software Systems, February 2003 (pdf)

COTS products affect development strategies and tactics, but not all CBS development efforts are equal. Based on our experiences with 20 large government and industry CBS projects assessed during our development of the COCOTS estimation model, and our hands-on experience with 52 small e-services CBS projects within USC's graduate level software engineering course, we have identified four distinct CBS activity areas: assessment intensive, tailoring intensive, glue-code intensive, and non-COTS intensive. The CBS activity type fundamentally affects the COTS related activity effort and project risks. In this work we define the three COTS activity intensive CBS types and discuss their strategic comparisons based on an empirical study of the spectrum of large and small CBS projects.

Added February 28th, 2003

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.