The current proliferation of software process models provides flexibility for organizations to deal with the unavoidably wide variety of software project situations, cultures, and environments. But it weakens their defenses against some common sources of project failure, and leaves them with no common anchor points around which to plan and control. This article identifies three milestones -- Life Cycle Objectives, Life Cycle Architecture, and Initial Operational Capability -- which can serve as these common anchor points. It also discusses why these particular three milestones or their equivalents are success-critical, particularly for large software projects, but for other software projects as well. 1. Introduction For a few golden moments in the mid-1970's, it appeared that the software field had found a sequence of common anchor points: a set of milestones around which people could plan, organize, monitor, and control their projects. These were the milestones in the waterfall model...

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. 1

Current processes and support systems for software requirements determination and analysis often neglect critical needs of important classes of stakeholders and limit themselves to concerns of the developers, users and customers. Besides developers, customers, and users, these stakeholders can include maintainers, interfacers, testers, product line managers, and sometimes members of the general public. This paper describes the results to date in researching and prototyping a Next Generation Process Model (NGPM) and support system (NGPSS) which directly addresses these issues. The NGPM emphasizes collaborative processes, involving all of the significant constituents with a stake in the software product. Its conceptual basis is a set of Theory W (win-win) extensions to the Spiral Model of software development. The Next-Generation Process Support System (NGPSS) is a groupware-oriented support capability for the NGPM. It enables an approach for collaborative win-condition elicitation and r...

Abstract not found

The development of complex software systems is a complex and lengthy activity that involves the participation and collaboration of many stakeholders (e.g. customers, users, analysts, designers, and developers). This results in many partial models of the developing system. These models can be inconsistent with each other since they describe the system from different perspectives and reflect the views of the stakeholders involved in their construction. Inconsistent software models can have negative and positive effects in the software development life-cycle. On the negative side, inconsistencies can delay and increase the cost of system development; do not guarantee some properties of the system, such as safety and reliability; and generate difficulties on system maintenance. On the positive side, inconsistencies can facilitate identification of some aspects of the system that need further analysis, assist with the specification of alternatives for the development of the system, and support elicitation of information about it. The software engineering community has proposed many techniques and methods to support the management of inconsistencies in various software models. In this paper, we present a survey of these techniques and methods. The survey is organized according to a conceptual framework which views inconsistency management as a process composed of six activities. These activities are the detection of overlaps, detection of inconsistencies, diagnosis of inconsistencies, handling of inconsistencies, tracking of inconsistencies, and specification and application of a management policy for inconsistencies. This paper also presents the main contributions of the research work that has been conducted to support each of the above activities and identifies the issues which are still open to further research. 1.

George Santayana's statement, "Those who cannot remember the past are condemned to repeat it, " is only half true. The past also includes successful histories. If you haven't been made aware of them, you're often condemned not to repeat their successes. In a rapidly expanding field such as software engineering, this happens a lot. Extensive studies of many software projects such as the Standish Reports offer convincing evidence that many projects fail to repeat past successes. This paper tries to identify at least some of the major past software experiences that were well worth repeating, and some that were not. It also tries to identify underlying phenomena influencing the evolution of software engineering practices that have at least helped the author appreciate how our field has gotten to where it has been and where it is. A counterpart Santayana-like statement about the past and future might say, "In an era of rapid change, those who repeat the past are condemned to a bleak future. " (Think about the dinosaurs, and think carefully about software engineering maturity models that emphasize repeatability.) This paper also tries to identify some of the major sources of change that will affect software engineering practices in the next couple of decades, and identifies some strategies for assessing and adapting to these sources of change. It also makes some first steps towards distinguishing relatively timeless software engineering principles that are risky not to repeat, and conditions of change under which aging practices will become increasingly risky to repeat.

Abstract not found

One of the biggest risks in software requirements engineering is the risk of overemphasizing one quality attribute requirement (e.g., performance) at the expense of others at least as important (e.g., evolvability and portability). This paper describes an exploratory knowledge-based tool for identifying potential conflicts among quality attributes early in the software/system life cycle. The Quality Attribute Risk and Conflict Consultant (QARCC) examines the quality attribute tradeoffs involved in software architecture and process strategies (e.g., one can improve portability via a layered architecture, but usually at some cost in performance). It operates in the context of the USC-CSE WinWin system, a groupware support system for determining software and system requirements as negotiated win conditions. Keywords: Software requirements engineering, Software quality, WinWin, Spiral Model, Software Architectures, Concurrent engineering, Software risk analysis, Knowledge based software en...

This paper focuses on the important challeng within market-driven RE of how to com ine information from different marketsegetb6 and make a trade-off etween their priorities. In particular, the paper focuses on the visualisation ofdisagxbAjj8 etween stakeholders and differences in the satisfaction with a certain priority decision. A num er of charts are proposed, which are intended to e used as decision support when determining what to implement in thecoming release of a software package The presented work is conducted in the context of an industrial case study, which is a follow-up on the study reportedRegrte et al. [6]. One of the mainchallengb identified inRegLxj et al. [6] was to relate the Requirements Eng (2001) 6:51--62 # 2001 Springer-Verlag London Limited Requirements Engirement Correspondence andoffpri4 requests to: B.Regj9x6 Department of Communication Systems, Lund University ofTechnologL Box 118, SE-221 00 Lund, Sweden. Email: bjorn.regIbAU85bgLUBbgg continuous prioritisation ofincoming requirements to a long98Ub product strateg for arang of market segketbx An important issue here is how to incorporate the expertise from marketing departments and the visions of top-level managlbjx in the prioritisation process. This paper focuses on how to elevate a prioritisation strateg (e.gg [10,11]), bymaking differences in the priorities of the various marketsegetbx explicit. The presented case study is conducted as part of an improvementprogveme for a specific industrial RE process forpackag5 software, called REPEAT (Requirements Engementsb Process atTelelogAIj which is enacted by the Swedish CASE-tool vendorTelelogj AB -- a company with 450 employees (January 2000), more than 7000 users worldwide, and a revenue for 1999 of 318 million SEK (increase from 178 mil...

We are applying the stakeholder win-win approach to software engineering education. The key stakeholders we are trying to simultaneously satisfy are the students; the industry recipients of our graduates; the software engineering community as parties interested in improved practices; and ourselves as instructors and teaching assistants. In order to satisfy the objectives or win conditions of these stakeholders, we formed a strategic alliance with the University of Southern California Libraries to have software engineering student teams work with Library clients to define, develop, and transition USC digital library applications into operational use. This adds another set of key stakeholders: the Library clients of our class projects. This paper summarizes our experience in developing, conducting, and iterating the course. It concludes by evaluating the degree to which we have been able to meet the stakeholder-determined course objectives.