|
Technical Reports
USC-CSE-2000-531
Bradford Clark, "Quantifying the Effects of Process Improvement on Effort," IEEE Software, Volume 17, Issue 6, November 2000, pp. 65-70 (pdf)
When organizations make many improvements concurrently, software project managers have no way of determining how much improvement is due to process maturity versus other factors. Using a 161-project sample, the article isolates the effects on effort of process maturity versus other effects, concluding that an increase of one process maturity level can reduce development effort by 4% to 11%.
Added July 18th, 2008
USC-CSE-2000-530
Barry Boehm, Ellis Horowitz, Raymond Madachy, Chris Abts, "Future Trends, Implications in Cost Estimation Models," CrossTalk, April 2000 (pdf)
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.
Added November 11th, 2005
USC-CSE-2000-529
Barry Boehm, "Safe and Simple Software Cost Analysis," IEEE Software, September/October 2000, pp. 14-17 (pdf)
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.
Added June 24th, 2004
USC-CSE-2000-528
Barry Boehm, Richard Fairley, "Software Estimation Perspectives," IEEE Software, November/December 2000, pp. 22-26 (pdf)
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?”
Added June 24th, 2004
USC-CSE-2000-527
Barry Boehm, "Requirements that Handle IKIWISI, COTS, and Rapid Change," Computer, July 2000, pp. 99-102 (pdf)
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.
Added June 24th, 2004
USC-CSE-2000-526
Barry Boehm, "The Art of Expectations Management," Computer, January 2000, pp. 122-124 (pdf)
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.
Added June 24th, 2004
USC-CSE-2000-525
Barry Boehm, "Spiral Development: Experience, Principles, and Refinements," Spiral Development Workshop, edited by Wilfred J. Hansen, February 9, 2000 (pdf)
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.
Added February 22nd, 2001
USC-CSE-2000-524
Alexander F. Egyed, "Automatically Validating Model Consistency During Refinement," submitted to ICSE 2001 (pdf)
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.
Added October 10th, 2000
USC-CSE-2000-523
Andre van der Hoek, Marija Mikic-Rakic, Roshanak Roshandel, Nenad Medvidovic, "Taming Architectural Evolution," Foundations of Software Engineering, Proceedings of the 8th European software engineering conference held jointly with 9th ACM SIGSOFT international symposium on Foundations of software engineering, Session: Architecture, Vienna, Austria, 2001, pp. 1-10 (pdf)
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.
Added November 13th, 2000
USC-CSE-2000-522
Lei Ding, Nenad Medvidovic, Barry Boehm, "Focus: A Light-Weight, Incremental Approach to Software Architecture Recovery and Evolution," Proceedings of the 2001 Working IEEE/IFIP Conference on Software Architectures (WICSA-2), Amsterdam, the Netherlands, August 27-29, 2001, pp. 191-200 (pdf)
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.
Added November 13th, 2000
USC-CSE-2000-521
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
USC-CSE-2000-520
Alexander Egyed, Nenad Medvidovic, Cristina Gacek, "Component-Based Perspective on Software Mismatch Detection and Resolution," IEE Proceedings - Software Engineering, Volume 147, Number 6, December 2000, pp. 225-236 (pdf)
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.
Added November 13th, 2000
USC-CSE-2000-519
Ebru Dincel, Roshanak Roshandel, Nenad Medvidovic, "ADL-Independent Architectural Representation in XML," Proceedings of the 2001 Symposium on Software Reusability (SSR 2001), Toronto, Canada, May 17-19, 2001, pp. 11-18 (pdf)
The 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.
Added November 13th, 2000
USC-CSE-2000-518
Marija Mikic-Rakic, Nenad Medvidovic, "Increasing the Confidence in Off-the-Shelf Components: A Software Connector-Based Approach," Proceedings of the 2001 Symposium on Software Reusability (SSR 2001), Toronto, Canada, May 17-19, 2001, pp. 11-18 (pdf)
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.
Added November 13th, 2000
USC-CSE-2000-517
Nenad Medvidovic, "On the Role of Middleware in Architecture-Based Software Development," ACM International Conference Proceeding Series, Proceedings of the 14th international conference on Software engineering and knowledge engineering, SESSION: Component-based software engineering, Ischia, Italy, Volume 27, 2002, pp. 299-306 (pdf)
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.
Added November 13th, 2000
USC-CSE-2000-516
Nenad Medvidovic, Peyman Oreizy, Richard N. Taylor, Rohi Khare, Michael Guntersdorfer, "An Architecture-Centered Approach to Software Environment Integration" (pdf)
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.
Added November 13th, 2000
USC-CSE-2000-515
Alexander Egyed, Paul Gruenbacher, Nenad Medvidovic, "Refinement and Evolution Issues between Requirements and Product Line Architectures" (pdf)
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.
Added November 13th, 2000
USC-CSE-2000-514
Nikunj R. Mehta, Nenad Medvidovic, Marija Mikic-Rakic, "Why Consider Implementation-Level Decisions in Software Architectures?" submitted to 4th International Workshop on Software Architectures, Limerick, Ireland, June 2000 (pdf)
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.
Added November 13th, 2000
USC-CSE-2000-513
Nenad Medvidovic, David S. Rosenblum, Richard N. Taylor, "Heterogeneous Typing for Software Architectures," submitted to ACM Transactions on Software Engineering and Methodology, 1999 (pdf)
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.
Added November 13th, 2000
USC-CSE-2000-512
Nenad Medvidovic, David S. Rosenblum, Jason E. Robbins, David F. Redmiles, "Modeling Software Architectures in the Unified Modeling Language," IEEE Computer, January 1999 (pdf)
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.
Added November 13th, 2000
USC-CSE-2000-511
Barry Boehm, Victor R. Basili, "Gaining Intellectual Control of Software Development," IEEE Computer, Volume 33, Number 5, May 2000, pp. 27-33 (pdf)
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.
Added October 10th, 2000
USC-CSE-2000-510
Barry Boehm, Chris Abts, "COTS Integration: Plug and Pray?" Computer, Volume 32, Number 1, January 1999, pp. 135-138 (pdf)
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.
Added October 10th, 2000
USC-CSE-2000-509
Barry Boehm, Kevin J. Sullivan, "Software Economics: A Roadmap," Proceedings of the Conference on The Future of Software Engineering, ICSE 2000, Limerick, Ireland, 2000, pp. 319-343 (pdf, doc)
The fundamental goal of all good design and engineering is to create maximal value added for any given investment. There are many dimensions in which value can be assessed, from monetary profit to the solution of social problems. The benefits sought are often domain-specific, yet the logic is the same: design is an investment activity. Software economics is the field that seeks to enable significant improvements in software design and engineering through economic reasoning about product, process, program, and portfolio and policy issues. We summarize the state of the art and identify shortfalls in existing knowledge. Past work focuses largely on costs, not on benefits, thus not on value added; nor are current technical software design criteria linked clearly to value creation. We present a roadmap for research emphasizing the need for a strategic investment approach to software engineering. We discuss how software economics can lead to fundamental improvements in software design and engineering, in theory and practice.
Added October 10th, 2000
USC-CSE-2000-508
Barry Boehm, "Managing Software Productivity and Reuse," Computer, Volume 32, Issue 9, September 1999, pp. 111-113 (pdf)
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?
Added October 10th, 2000
USC-CSE-2000-507
Barry Boehm, "Spiral Development: Experience, Principles, and Refinements," Spiral Experience Workshop, February 9, 2000 (pdf)
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.
Added March 28th, 2000
USC-CSE-2000-506
Barry Boehm, "Unifying Software Engineering and System Engineering," Computer, Volume 3, Number 3, March 2000, pp. 114-116 (pdf)
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.
Added October 10th, 2000
USC-CSE-2000-505
Barry Boehm, Chris Abts, Sunita Chulani, "Software Development Cost Estimation Approaches - A Survey," Qualifying Exam Report (Sunita Chulani) (pdf)
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.
Added April 10th, 2000
USC-CSE-2000-504
Jongmoon Baik, Barry Boehm, "Empirical Analysis of CASE Tool Effects on Software Development Effort," ACIS International Journal of Computer & Information Science, Volume 1, Issue 1, Winter 2000, pp. 1-10 (pdf)
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.
Added March 20th, 2000
USC-CSE-2000-503
Chris Abts, "A Perspective on the Economic Life Span of COTS-based Software Systems: the COTS-LIMO Model," submitted to the Workshop on Continuing Collaborations for Successful COTS Development, ICSE 2000, Limerick, Ireland, June 4-5, 2000 (pdf)
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.
Added March 8th, 2000
USC-CSE-2000-502
Chris Abts, Barry Boehm, Elizabeth Bailey Clark, "Empirical Observations on COTS Software Integration Effort Based on the Initial COCOTS Calibration Database," Proceedings of the Twenty-Fifth Annual Software Engineering Workshop (SEW 25), NASA/Goddard Space Flight Center, 2000 (pdf)
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.
Added March 8th, 2000
USC-CSE-2000-501
Chris Abts, Barry Boehm, Elizabeth Bailey Clark, "COCOTS: A COTS Software Integration Lifecycle Cost Model - Model Overview and Preliminary Data Collection Findings," Proceedings ESCOM-SCOPE 2000 Conference, Munich, Germany, April 18-20, 2000, pp. 325-333 (pdf)
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.
Added March 8th, 2000
USC-CSE-2000-500
Barry Boehm, Chris Abts, Jongmoon Baik, A. Winsor Brown, Sunita Chulani, Bradford Clark, Ellis Horowitz, Ray Madachy, Donald J. Reifer, Bert Steece, "USC COCOMO II.2000" (pdf)
This manual presents two models, the Post-Architecture and Early Design models. These two models are used in the development of Application Generator, System Integration, or Infrastructure developments [Boehm et al. 2000]. The Post-Architecture is a detailed model that is used once the project is ready to develop and sustain a fielded system. The system should have a life-cycle architecture package, which provides detailed information on cost driver inputs, and enables more accurate cost estimates. The Early Design model is a high-level model that is used to explore of architectural alternatives or incremental development strategies. This level of detail is consistent with the general level of information available and the general level of estimation accuracy needed.
The Post-Architecture and Early Design models use the same approach for product sizing (including reuse) and for scale factors. These will be presented first. Then, the Post-Architecture model will be explained followed by the Early Design model.
Added September 8th, 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.
|
|
