Technical Reports

 

 

Return to Technical Report System


USC-CSE-2000-530 PDF

Future Trends, Implications in Cost Estimation Models

Barry Boehm, Ellis Horowitz, Raymond Madachy, Chris Abts


The rapid pace of change in software technology requires everybody in the software business to continually rethink and update their practices just to stay relevant and effective. This article discusses this challenge first with respect to the USC COCOMO® II software cost modeling project, and then for software-intensive organizations in general. It then presents a series of adaptive feedback loops by which organizations can use COCOMO® II-type models to help cope with the challenges of change

CrossTalk, April 2000
added: Nov. 11, 2005


 

USC-CSE-2000-529 PDF

Safe and Simple Software Cost Analysis

Barry Boehm

There are a number of simple software cost analysis methods, but they may not always be safe. The simplest is to base your cost estimate on the typical costs or productivity rates of your previous projects. This will work well if your new project doesn’t have any cost-critical differences from your previous projects. But it won’t be safe if some critical cost-driver has changed for the worse.

 

Document characteristics: IEEE Software, September/October 2000, pp. 14-17
added: June 24, 2004 


 

USC-CSE-2000-528 PDF

Software Estimation Perspectives

Barry Boehm, Richard Fairley

How much is 68 + 73? Engineer: “It’s 141.” Short and sweet. Mathematician: “68 + 73 = 73 + 68 by the commutative law of addition.” True, but not very helpful. Accountant: “Normally it’s 141, but what are you going to use it for?”

 

Document characteristics: IEEE Software, November/December 2000, pp. 22-26
added: June 24, 2004 


 

USC-CSE-2000-527 PDF

Requirements that Handle IKIWISI, COTS, and Rapid Change

Barry Boehm

In the good old days, dealing with software requirements was relatively easy. Software requirements were the first order of business and took place before design, cost estimation, planning, or programming. Of course, it wasn’t simple.

 

Document characteristics: Computer, July 2000, pp. 99-102
added: June 24, 2004 


 

USC-CSE-2000-526 PDF

The Art of Expectations Management

Barry Boehm

One of the most valuable skills a software professional can develop, expectation management is something surprisingly few people know or practice. I’ve witnessed more than 100 stakeholder software requirement negotiations in which inflated expectations about the simplicity of the problem or ease of providing a solution have caused the most difficulty. Expectations management holds the key to providing win-win solutions to these situations.

Document characteristics: Computer, January 2000, pp. 122-124
added: June 24, 2004 


 

USC-CSE-2000-525 PDF

Spiral Development: Experience, Principles, and Refinements

Barry Boehm, edited by Wilfred J. Hansen

Spiral development is a family of software development processes characterized by repeatedly iterating a set of elemental development processes and managing risk so it is actively being reduced. This paper characterizes spiral development by enumerating a few “invariant” properties that any such process must exhibit. For each, a set of “variants” is also presented, demonstrating a range of process definitions in the spiral development family. Each invariant excludes one or more "hazardous spiral look-alike" models, which are also outlined. This report also shows how the spiral model can be used for a more cost-effective incremental commitment of funds, via an analogy of the spiral model to stud poker. An important and relatively recent innovation to the spiral model has been the introduction of anchor point milestones. The latter part of the paper describes and discusses these.

Document characteristics: Spiral Development Workshop, February 9, 2000
added: February 22, 2001 



USC-CSE-2000-524 PDF

Automatically Validating Model Consistency during Refinement

Alexander F. Egyed. USC Center for Software Engineering

Automated consistency checking between software development models still remains a complex and non-scalable problem. Current solutions are frequently only able to detect small numbers of inconsistency types, often under less than realistic assumptions. This paper introduces a new approach to consistency checking based on model trans-formation. Our approach uses transformation to translate and to interpret model information between different types of views (e.g., diagrams) in order to simplify their comparison. Transformation-based consistency checking, in the manner we use it, has never been attempted before and, as this paper will demonstrate, has significant benefits including (1) increased variety of automatically detectable inconsistencies, (2) improved scalability, (3) ability to handle incomplete, ambiguous model specifications, and (4) ability to define domain- and model-independent inconsistency rules. This paper will illustrate our approach in context of model refinement and abstraction using a complex example. Our approach is fully tool supported.

Document characteristics: Submitted to ICSE 2001
added: October 10, 2000 



USC-CSE-2000-523 PDF

Taming Architectural Evolution.

Andre van der Hoek, Marija Rakic, Roshanak Roshandel, and Nenad Medvidovic.

In the world of software development everything evolves. So, then, do software architectures. Unlike source code, for which the use of a configuration management (CM) system is the predominant approach to capturing and managing evolution, approaches to capturing and managing architectural evolution span a wide range of disconnected alternatives. This paper contributes a novel architecture evolution environment, called Mae, which brings a number of these alternatives together. The environment facilitates an incremental design process in which all changes to all architectural elements are integrally captured and related. Key to the environment is a rich system model that combines architectural concepts with those from the field of CM. Not only does this system model form the basis for Mae, but in precisely capturing architectural evolution it also facilitates automated support for several innovative capabilities. This paper demonstrates three of those: the provision of design guidance at the architecture level, the use of specialized software connectors to ensure run-time reliability during
component upgrades, and the creation of component-leel patches to be applied to deployed system configurations.

Document characteristics:
added: November 13, 2000 .



USC-CSE-2000-522 PDF

Focus: A Light-Weight, Incremental Approach to Software Architecture Recovery and Evolution.

Nenad Lei Ding and Nenad Medvidovic.Boehm.

During the past decade, object-orientation (OO) has become the dominant software development methodology, accompanied by a number of modeling notations, programming languages, and development environments. OO applications of today are increasingly complex and user-driven. They are also developed more rapidly and evolved more frequently than was the case with software systems of the past. All of these factors contribute to a plethora of potential problems when maintaining and evolving an OO application. These problems are caused by architectural erosion, where the initial architecture of an application is (arbitrarily) modified to the point where its key properties no longer hold. We propose an approach, called Focus, whose goal is to enable effective evolution of such an application with minimal effort, by recovering its architecture and using it as the basis of evolution. Focus allows engineers to direct their primary attention to the part of the system that is directly impacted by the desired change; subsequent changes will incrementally uncover additional parts of the system’s architecture. We have applied Focus to four off-the-shelf applications to date. We discuss its key strengths and point out several open issues that will frame our future work.

Document characteristics:
added: November 13, 2000 



USC-CSE-2000-521 PDF

Bridging Models across the Software Lifecycle.

Nenad Medvidovic, Paul Gruenbacher, Alexander Egyed, and Barry W. Boehm

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. 

Document characteristics:
added: November 13, 2000 



USC-CSE-2000-520 PDF

Component-Based Perspective on Software Mismatch Detection and Resolution.

Alexander Egyed, Nenad Medvidovic, and Cristina Gacek.

Existing approaches to modeling software systems all too often neglect the issue of component mismatch identification and resolution. The traditional view of software development over-emphasizes synthesis at the expense of analysis - the latter frequently being seen as a problem one only needs to deal with during the integration stage towards the end of a development project. This paper discusses three software modeling and analysis techniques, all tool supported, and emphasizes the vital role analysis can play in identifying and resolving risks early on. This work also combines model based development with component based development (e.g., COTS and legacy systems) and shows how their mismatch detection capabilities complement each other in providing a more comprehensive coverage of development risks.

Document characteristics:
added: November 13, 2000 



USC-CSE-2000-519 PDF

ADL-Independent Architectural Representation in XML.

Ebru Dincel, Roshanak Roshandel, and Nenad Medvidovic

he Extensible Markup Language, XML [1], is a proper subset of the Standard Generalized Markup Language, or SGML, which has been accepted as a standard by the World Wide Web Consortium (W3C) for structuring electronic documents. However, the first and still the most widely used markup language for the web is none other than HTML, or Hypertext  markup Language. HTML’s goals are achieved by using pre-defined tags to add meaning to data. Taking this a step further, XML adds the ability to add the concept of relationships between tags, which helps in capturing the semantics of a particular domain. Such relationships are quantified in XML using the notion of Document Type Definition or DTD. DTD is a built-in feature in XML, and is used to represent metadata. This metadata describes the rules governing the relationships between elements in the XML file, or a set of constraints regarding the nesting of tags or their order. With DTD, we can specify whether stags are required or optional, and define the valid tags allowed for the particular domain of interest. Architecture Description Languages (ADLs) form a class of new and upcoming tools for designing software systems. Having an XML based representation for several ADLs could help extend their use in industry. Furthermore it would be interesting to look at several ADLs to find out their similarities and differences, and try to come up with an XML schema to describe them. For the purposes of this project, we experimented with C2, Acme, Darwin and SADL for to discover how an ADL-independent architectural representation might be accomplished in XML. Our updated DTDs, which are the result of this work, are outlined in the Appendix.

Document characteristics:
added: November 13, 2000 



USC-CSE-2000-518 PDF

Increasing the Confidence in Off-the-Shelf Components: A Software Connector-Based Approach.

Marija Rakic, Nenad Medvidovic

The promise of component-based software development is that larger, more complex systems can be built reasonably quickly and reliably from pre-fabricated (“off-the-shelf”) building blocks. Additionally, such systems can be upgraded incrementally, simply by replacing individual components with their new versions. However, practice has shown that, while it may improve certain aspects of an existing component, a new component version frequently introduces unforeseen problems. These problems include less efficient utilization of system resources, errors in the newly introduced functionality, and even new errors in the functionality carried over from the old version. This paper presents an approach intended to alleviate such problems. Our approach is based on explicit software architectures and leverages flexible software connectors in ensuring that component versions can be added and removed in the deployed, running system. Our connectors, called multi-versioning connectors, also unintrusively collect and compare the execution statistics of the running component versions (e.g., execution time and results of invocations). We illustrate our approach with the help of an example application. 

Document characteristics:
added: November 13, 2000



USC-CSE-2000-517 PDF

On the Role of Middleware in Architecture-Based Software Development.

Nenad Medvidovic, University of Southern California

Software architectures promote development focused on modular functional building blocks (components), their interconnections (configurations), and their interactions (connectors). Since architecture-level components often contain complex functionality, it is reasonable to expect that their interactions will be complex as well. Middleware technologies such as CORBA, COM, and RMI, provide a set of predefined services for enabling component composition and interaction. However, the potential role of such services in the imple-mentations of software architectures is not well understood. Furthermore, components adhering to one mid-dleware standard cannot readily interact with those adhering to another. In order to understand the role and tradeoffs among middleware technologies in implementing architectures and enable component interoperability across middleware platforms, we have investigated a set of techniques and conducted case studies involving a particular architectural style, C2, and its implementation infrastructure. In particular, by encapsulating middleware functionality within C2’s explicit software connectors, we have been able to couple C2’s existing benefits such as component interchangeability, substrate independence, and structural guidance with new capabilities of multi-lingual, multi-process, and  distributed application development in a manner that is transparent to architects. Furthermore, we have demonstrated the utility of our connector-based approach in enabling components implemented on top of different middleware platforms to interoperate. Though several details of our approach derive from the characteristics of the C2 style, we believe that a number of lessons learned are more generally applicable. We argue that these lessons can help form a broader research agenda for coupling the modeling power of software architectures with the implementation support provided by middleware.

Document characteristics:
added: November 13, 2000 



USC-CSE-2000-516 PDF

An Architecture-Centered Approach to Software Environment Integration.

Nenad Medvidovic, Peyman Oreizy, Richard N. Taylor, Rohit Khare, and Michael Guntersdorfer.

Software architecture research has yielded a variety of powerful techniques for assisting in the design, implementation, and long-term evolution of complex, heterogeneous, distributed, multi-user applications. Since software development environments are themselves applications with these charac-teristics, it is natural to examine the effectiveness of an architectural approach to constructing and changing them. We report on our experience in creating a family of related environments in this manner. The environments encompass a range of services and include commercial off-the-shelf products as well as custom-built tools. The particular architectural approach adopted is fully reflexive: the environments are used in their own construction and evolution. We also report on some engineering experiences, in particular with our use of XML as the vehicle for supporting a common and extensible representation of architectural models, including the model of the environment itself. Generally applicable  lessons from the experience are described. 

Document characteristics:
added: November 13, 2000 



USC-CSE-2000-515 PDF

Refinement and Evolution Issues between Requirements and Product Line Architectures.

Alexander Egyed, Paul Gruenbacher, and Nenad Medvidovic.

Though acknowledged as very closely related, to a large extent re-quirements engineering and architecture modeling have been pursued independ-ently of one another, particularly in the large body of software architecture research that has emerged over the past decade. The dependencies and constraints imposed by elements of one on those of the other are not well understood. This paper identifies a number of relevant relationships we have identified in the process of trying to relate the WinWin requirements engineering approach with architecture and design-centered approaches (e.g., C2 and UML). This paper further discusses their relevance towards product line issues which currently are obscured by the fusion of roduct-specific and product-line information.

Document characteristics:
added: November 13, 2000 



USC-CSE-2000-514 PDF

Why Consider Implementation-Level Decisions in Software Architectures?

Nikunj R. Mehta, Nenad Medvidovic, and Marija Rakic.

Software architecture provides a high-level abstraction of the structure, behavior, and properties of a software system aimed at enabling early analysis of the system and its easier implementation. Often, however, important details about a system are left to be addressed in its implementation, resulting in differences between conceptual and concrete architectures. This paper describes an approach towards bringing these two closer by making certain implementation-level decisions explicit in the architecture. Specifically, we focus on the choices made in modeling and implementing component interactions. The process is based on a taxonomy of software connectors that the authors have developed to better understand component interactions, and an architectural framework developed to support a variety of connectors.

Document characteristics:
added: November 13, 2000 



USC-CSE-2000-513 PDF

Heterogeneous Typing for Software Architectures.

Nenad Medvidovic, David S. Rosenblum, and Richard N. Taylor.

Software architectures have the potential to substantially improve the development and evolution of large, complex, multi-lingual, multi-platform, long-running systems. However, in order to achieve this potential, specific architecture-based modeling, analysis, and evolution techniques must be provided. This paper motivates and presents one such technique: a type system for software architectures, which allows flexible, controlled evolution of software components in a manner that preserves the desired architectural relationships and properties. Critical to the type system is a framework that divides the space of subtyping relationships into a small set of well defined categories. The paper also investigates the effects of large-scale development and off-the-shelf reuse on establishing type conformance between interoperating components in an architecture. An existing architecture is used as an example to illustrate a number of different applications of
the type system to architectural modeling and evolution.

Document characteristics:
added: November 13, 2000 



USC-CSE-2000-512 PDF

Modeling Software Architectures in the Unified Modeling Language. 

Nenad Medvidovic, David S. Rosenblum, Jason E. Robbins, and David F. Redmiles.

The Unified Modeling Language (UML) is a family of design notations that is rapidly becoming a de facto standard software design language. UML provides a variety of useful capabilities to the software designer, including multiple, inter-related design views, a semi-formal semantics expressed as a UML meta model, and an associated language for expressing formal logic constraints on design elements. However, UML currently lacks support for capturing and exploiting certain architectural concerns whose importance has been demonstrated through the research and practice of software architectures. In particular, UML lacks direct support for modeling and exploiting architectural styles, explicit software connectors, and local and global architectural constraints. This paper presents two strategies for supporting
such architectural concerns within UML. One strategy involves using UML “as is,” while the other incorporates useful features of existing architecture description languages (ADLs) as UML extensions. We discuss the applicability, strengths, and weaknesses of the two strategies. The strategies are applied on three ADLs that, as a whole, represent a broad cross-section of present-day ADL capabilities.

Document characteristics: Published in Computer Magazine, January 1999
added: November 13, 2000 



USC-CSE-2000-511 PDF

Gaining Intellectual Control of Software Development

Barry Boehm. USC Center for Software Engineering

Recent disruptions caused by several events have shown how thoroughly the world has come to depend on software. The rapid proliferation of the Melissa virus hinted at a dark side to the ubiquitous connectivity that supports the information-rich Internet and lets e-commerce thrive. Although the oft-predicted Y2K apocalypse failed to materialize, many software experts insist that disaster was averted only because countries around the globe spent billions to ensure their critical software would be Y2K-compliant. When denial-of-service attacks shut down some of the largest sites on the Web last February, the concerns caused by the disruptions spread far beyond the complaints of frustrated customers, affecting even the stock prices of the targeted sites..

Document characteristics: Published in IEEE Computer, May 2000
added: October 10, 2000 



USC-CSE-2000-510 PDF

COTS Integration: Plug and Pray? 

Barry Boehm, Chris Abts. USC Center for Software Engineering

For most software applications, the use of commercial off-the-shelf products has become an economic necessity. Gone are the days when upsized industry and government information technology organizations had the luxury of trying to develop—and at greater expense, maintain— their own database, network, and user-interface management infrastructure. Viable COTS products are climbing up the protocol stack, from infrastructure into application solutions in such areas as office and management support, electronic commerce, finance, logistics, manufacturing, law, and medicine. For small and large commercial companies, time-to-market pressure also exert a strong pressure toward COTS-based solutions.

Document characteristics: Published in Computer Magazine, January 1999
added: October 10, 2000 



USC-CSE-2000-509 PDF

Software Economics: A Roadmap

Barry Boehm. J.Sullivan
 

Document characteristics: Invited Paper, ICSE 2000
added: October 10, 2000 



USC-CSE-2000-508 PDF

Managing Software Productivity and Reuse

Barry Boehm. USC Center for Software Engineering

Your organization can choose from three main strategies for improving its software productivity. You can work faster, using tools that automate or speed up previously labor-intensive tasks. You can work smarter, primarily through process improvements that avoid or reduce non-value-adding tasks. Or you can avoid unnecessary work by reusing software artifacts instead of custom developing each project. Which strategy will produce the highest payoff?

Document characteristics: Published in IEEE Computer, Septemer 1999
added: October 10, 2000 


USC-CSE-2000-507 PDF

Spiral Development: Experience, Principles, and Refinements

Barry Boehm. USC Center for Software Engineering

This presentation opened the USC-SEI Workshop on Spiral Development* Experience and Implementation Challenges held at USC February 9-11, 2000. The workshop brought together leading executives and practitioners with experience in transitioning to spiral development of software-intensive systems in the commercial, aerospace, and government sectors. Its objectives were to distill the participants’ experiences into a set of critical success factors for transitioning to and successfully implementing spiral development, and to identify the most important needs, opportunities, and actions to expedite organizations’ transition to successful spiral development. To provide a starting point for addressing these objectives, I tried in this talk to distill my experiences in developing and transitioning the spiral model at TRW; in using it in system acquisitions at DARPA; in trying to refine it to address problems that people have had in applying it in numerous commercial, aerospace, and government contexts; and in working with the developers of major elaborations and refinements of the spiral model such that the Software Productivity Consortium’s Evolutionary Spiral Process [SPC, 1994] and Rational, Inc’s Rational Unified Process [Royce, 1998; Kruchten 1999; Jacobson et al., 1999]. I’ve modified the presentation somewhat to reflect the experience and discussions at the Workshop.

Document characteristics: Spiral Experience Workshop February 9, 2000 
added: March 28, 2000 


USC-CSE-2000-506 PDF

Unifying Software Engineering and System Engineering

Barry Boehm. USC Center for Software Engineering

Rapid change in information technology brings with it a frequent need to undo the effects of previous culture change efforts. This process, while often challenging and frustrating, offers numerous rewards for success. Organizations can change from slow, reactive, adversarial, separated software and systems engineering processes to unified, concurrent processes. These processes better suit rapid development of dynamically changing software-intensive systems involving COTS, agent, Web, multimedia, and Internet technology.

Document characteristics:
added: October 10, 2000 



USC-CSE-2000-505 PDF

Software Development Cost Estimation Approaches - A Survey

Barry Boehm and Chris Abts, and Sunita Chulani. USC Center for Software Engineering

This paper summarizes several classes of software cost estimation models and techniques: parametric models, expertise-based techniques, learning-oriented techniques, dynamics-based models, regression-based models, and composite-Bayesian techniques for integrating expertise-based and regression-based models. Experience to date indicates that neural-net and dynamics-based techniques are less mature than the other classes of techniques, but that all classes of techniques are challenged by the rapid pace of change in software technology. The primary conclusion is that no single technique is best for all situations, and that a careful comparison of the results of several approaches is most likely to produce realistic estimates. 

Document characteristics: An extension of the work done by Sunita Chulani as part of her Qualifying Exam report in partial fulfillment of requirements of the Ph.D. program of the Computer Science department at USC [Chulani 1998] 
added: April 10, 2000 


USC-CSE-2000-504 PDF

Empirical Analysis of CASE Tool Effects on Software Development Effort

Jongmoon Baik and Barry Boehm, USC Center for Software Engineering

During the last couple of decades, CASE (Computer Aided Software Engineering) tools have played a critical role in improvement of software productivity and quality by assisting tasks in software development processes. Many initiatives in the field were pursued in the 1980’s and 1990’s to provide more effective CASE technologies and development environments. Even though the CASE field is no longer active research area, most software development teams use a huge range of CASE tools that are typically assembled over some period with the hope of productivity and quality improvements throughout the software development process. The variety and proliferation of tools in the current CASE market makes it difficult to understand what kinds of tasks are supported and how much effort can be reduced by using CASE tools. In this paper, we provide a classification of CASE tools by activity coverage in a software development lifecycle. We also report a experimental result of Bayesian analysis on CASE tool effects with a extended set of tool rating scales from COCOMO® (COnstructive COst MOdel) II with which CASE tools are effectively evaluated.

Document characteristics: 
added: March 20, 2000


USC-CSE-2000-503 PDF

A Perspective on the Economic Life Span of COTS-based Software Systems: the COTS-LIMO Model

Chris Abts, USC Center for Software Engineering

The use of commercial-of-the-shelf (COTS) components is becoming ever more prevalent in the creation of large software systems. The rationale usually cited for this trend is that by using COTS components, immediate short-term gains in direct development effort & schedule are possible—admittedly, often as a trade-off for a more complicated long-term post-deployment maintenance environment. Even so, the conventional wisdom is that generally, the more of the system that can be built using COTS components, the better. Anecdotal evidence recently gathered while conducting data collection interviews for the COCOTS COTS integration cost model suggests, however, that there may be diminishing returns in trying to maximize the use of COTS components in a system development. Beyond a certain point, an increase in the number of COTS components in a system may actually reduce the system's overall economic life span rather than increase it. This paper discusses why this may be true, at least in some cases, and proposes a new economic COTS life span model, COTS-LIMO, as a way of possibly examining these effects. As of this writing, the suggestion being made here that increasing the number of COTS components in a system ultimately produces diminishing returns can only be called a hypothesis. But if proven true, even in some cases, then this could have significant implications for current policy decisions being made by governments and organizations encouraging an ever expanding use of COTS components in software system developments. 

Document characteristics: Submitted to the Workshop on Continuing Collaborations for Successful COTS Development, ICSE2000, June 4-5, 2000, Limerick, Ireland.
added: March 8, 2000


USC-CSE-2000-502 PDF

Empirical Observations on COTS Software Integration Effort Based on the Initial COCOTS Calibration Database (temporarily unavailable)

Chris Abts, Barry Boehm, USC Center for Software Engineering
Elizabeth Bailey Clark, Software Metrics, Inc.

As the use of commercial-of-the-shelf (COTS) components becomes ever more prevalent in the creation of large software systems, the need for the ability to reasonably predict the true lifetime cost of using such software components grows accordingly. This paper presents empirically-based findings about the effort associated with activities found to be significant in the development of systems using COTS components. The findings are based upon data collected for the purpose of calibrating the COCOTS COTS software integration cost model, an extension to the COCOMO® II cost model designed to capture costs COCOMO® does not. A brief overview of COCOTS is presented to put the data in perspective, including its relation to COCOMO® II. A set of histograms is then shown summarizing the effort data collected to date. The paper concludes with some observations suggested by an examination of that calibration data.

Document characteristics: Submitted to the Workshop on Continuing Collaborations for Successful COTS Development, ICSE2000, June 4-5, 2000, Limerick, Ireland.
added: March 8, 2000 


USC-CSE-2000-501 PDF

COCOTS: A COTS Software Integration Lifecycle Cost Model - Model Overview and Preliminary Data Collection Findings

Chris Abts, Barry Boehm, USC Center for Software Engineering
Elizabeth Bailey Clark, Software Metrics, Inc.

As the use of commercial-of-the-shelf (COTS) components becomes ever more prevalent in the creation of large software systems, the need for the ability to reasonably predict the true lifetime cost of using such software components grows accordingly. In using COTS components, immediate short-term gains in direct development effort & schedule are possible, but usually as a trade-off for a more complicated long-term post-deployment maintenance environment. In addition, there are risks associated with COTS software separate from those of creating components from scratch. These unique risks can further complicate the development and post-deployment situations. This paper discusses a model being developed as an extension of the COCOMO® II cost model. COCOTS attempts to predict the lifecycle costs of using COTS components by capturing the more significant COTS risks in its modeling parameters. The current state of the model is presented, along with some preliminary findings suggested by an analysis of calibration data collected to date. The paper concludes with a discussion of the on-going effort to further refine the accuracy and scope of COCOTS.

Document characteristics: 
added: March 8, 2000 


USC-CSE-2000-500 PDF

Why Consider Implementation-Level Decisions in Software Architectures?

Nikunj Mehta, Nenad Medvidovic and Marija Rakic. USC Center for Software Engineering

Software architecture provides a high-level abstraction of the structure, behavior, and properties of a software system aimed at enabling early analysis of the system and its easier implementation. Often, however, important details about a system are left to be addressed in its implementation, resulting in differences between conceptual and concrete architectures. This paper describes an approach towards bringing these two closer by making certain implementation-level decisions explicit in the architecture. Specifically, we focus on the choices made in modeling and implementing component interactions. The process is based on a taxonomy of software connectors that the authors have developed to better understand component interactions, and an architectural framework developed to support a variety of connectors.

Document characteristics: Submitted to 4th International Workshop on Software Architectures, June 2000, Limerick, Ireland.
added: February 26, 2000 

 

Return to Technical Report System

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.