Technical Reports
|
USC-CSE-2000-530 PDF
CrossTalk, April 2000
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 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 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 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 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
Automatically Validating Model Consistency during Refinement Alexander F. Egyed.
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
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 Document characteristics:
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:
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:
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:
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, Document characteristics:
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:
On the Role of Middleware in Architecture-Based Software Development. Nenad Medvidovic, 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:
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:
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:
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:
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 Document characteristics:
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 Document characteristics: Published in Computer Magazine, January 1999
Gaining Intellectual Control of Software Development Barry Boehm. 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
COTS Integration: Plug and Pray? Barry Boehm, Chris Abts.
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
Software Economics: A Roadmap Barry Boehm. J.Sullivan
Document characteristics: Invited Paper, ICSE 2000
Managing Software Productivity and Reuse Barry Boehm. 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 USC-CSE-2000-507 PDF Spiral Development: Experience, Principles, and Refinements Barry Boehm. 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 USC-CSE-2000-506 PDF Unifying Software Engineering and System Engineering Barry Boehm. 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:
Software Development Cost Estimation Approaches - A Survey Barry Boehm and Chris Abts,
and Sunita Chulani. 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] USC-CSE-2000-504 PDF Empirical Analysis of CASE Tool Effects on Software Development Effort Jongmoon Baik and Barry Boehm, 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: USC-CSE-2000-503 PDF A Perspective on the Economic Life Span of COTS-based Software Systems: the COTS-LIMO Model Chris Abts, 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, 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, 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, USC-CSE-2000-501 PDF COCOTS: A COTS Software Integration Lifecycle Cost Model - Model Overview and Preliminary Data Collection Findings Chris Abts,
Barry Boehm, 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: USC-CSE-2000-500 PDF Why Consider Implementation-Level Decisions in Software Architectures? Nikunj 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: Submitted to 4th International Workshop on
Software Architectures, June 2000, |
|
|
|
Copyright 1995, 1996, 1997, 1998, 1999 The
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.