Reengineering Center. Carnegie Mellon University. Pittsburgh, PA

Save this PDF as:
 WORD  PNG  TXT  JPG

Size: px
Start display at page:

Download "Reengineering Center. Carnegie Mellon University. Pittsburgh, PA 15213-3890. E-mail: fstilley,dbsg@sei.cmu.edu"

Transcription

1 Perspectives on Legacy System Reengineering Reengineering Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA Copyright c 1995 Software Engineering Institute D R A F T Version 0.3

2 Abstract One of the goals of modern software engineering is to move towards a paradigm of evolutionary systems. In this model, the articial distinction between development and maintenance is replaced by the notion of continous evolution of the subject system. While this notion holds much promise for future systems, there is one major stumbling block on the road to its wide-spread acceptance and use: the existing base of legacy systems. Reengineering oers an approach to migrating a legacy system towards an evolvable system in a disciplined manner. The process of reengineering may be viewed as applying engineering principles to an existing system in order for it to meet new requirements. However, in order to be successful, reengineering requires insights from a number of dierent perspectives. This document outlines current issues and trends in reengineering from several perspectives. These include an engineering perspective, a system perspective, a software perspective, a managerial perspective, an evolutionary perspective, and a maintenance perspective. While not exhaustive, these viewpoints serve as a framework for placing reengineering in the context of evolutionary systems. Keywords: legacy systems, program understanding, reengineering, reverse engineering, software evolution.

3 To Dilbert. \A deadline has a wonderful way of focusing the mind." Professor Moriarty, Ship in a Bottle, Star Trek: The Next Generation. i

4 Contents Abstract Contents ii List of gures viii List of tables ix 1 Introduction Evolutionary systems : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : The need to reengineer : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Legacy systems : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Reengineering : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Related issues : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Outline : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 4 2 An engineering perspective Introduction : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Reengineering as constrained problem solving : : : : : : : : : : : : : : : : : : : : : : A reengineering framework : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : The current system state : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 8 ii

5 2.3.2 The desired system state : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : System understanding : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Evolutionary migration path : : : : : : : : : : : : : : : : : : : : : : : : : : : Summary : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Summary : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 14 3 A system perspective Introduction : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : A reengineering process framework : : : : : : : : : : : : : : : : : : : : : : : : : : : : Issue assessment : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Decision analysis : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Solution development : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : System transition : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Process improvement : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Summary : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 26 4 A software perspective Introduction : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Denition and context : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Program understanding : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Cognitive models and the understanding process : : : : : : : : : : : : : : : : Reverse engineering : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Redocumentation : : : : : : : : : : : : : : : : : : : : : : : : : : : : Structural redocumentation : : : : : : : : : : : : : : : : : : : : : : : Design recovery : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 33 iii

6 4.3.3 Approaches : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Program analysis : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Plan recognition : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Concept assignment : : : : : : : : : : : : : : : : : : : : : : : : : : : Remarks : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Summary : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Software evolution : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Summary : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 40 5 A managerial perspective Introduction : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Setting goals : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Typical project goals : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Establishing the critical success factors : : : : : : : : : : : : : : : : : : : : : : Setting realistic expectations : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Benets : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Establishing a business case : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Developing a reengineering plan : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Why : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : What : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : How : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : When : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Where and who : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : How much : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : What if : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 49 iv

7 5.6 Determining organizational readiness for reengineering : : : : : : : : : : : : : : : : : Capability assessment : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Training needs : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Application usage survey : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Application life cycle prognoses : : : : : : : : : : : : : : : : : : : : : : : : : : Technology trends : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Functional requirements : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Environmental context : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Operational deployment considerations : : : : : : : : : : : : : : : : : : : : : : Managing organizational change : : : : : : : : : : : : : : : : : : : : : : : : : Change agents : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Sponsors : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Champions : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Participants : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Key elements involved in managing change : : : : : : : : : : : : : : Summary : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 57 6 An evolutionary perspective System evolution and evolutionary systems : : : : : : : : : : : : : : : : : : : : : : : A paradigm shift to continuous evolution : : : : : : : : : : : : : : : : : : : : Systems built to support the paradigm shift : : : : : : : : : : : : : : : : : : : Critical Needs for Evolutionary Systems : : : : : : : : : : : : : : : : : : : : : Developing the right software : : : : : : : : : : : : : : : : : : : : : : Developing the software right : : : : : : : : : : : : : : : : : : : : : : Developing the software rapidly and aordably : : : : : : : : : : : : 63 v

8 Evolving systems to meet changing user needs : : : : : : : : : : : : Turning legacy systems into evolutionary systems reengineering for evolution The need for evolutionary systems : : : : : : : : : : : : : : : : : : : : : : : : : : : : Myths and realities of the current paradigm : : : : : : : : : : : : : : : : : : : Fullling software's promised role : : : : : : : : : : : : : : : : : : : : : : : : : The vision of evolution : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : The central role of architecture : : : : : : : : : : : : : : : : : : : : : : : : : : Information-rich systems : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Predictability and rapid composition : : : : : : : : : : : : : : : : : : : : : : : Organizational and lifecycle implications : : : : : : : : : : : : : : : : : : : : : Staged binding of solutions : : : : : : : : : : : : : : : : : : : : : : : : : : : : Technical underpinnings : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Evolutionary environments : : : : : : : : : : : : : : : : : : : : : : : : : : : : Information infrastructure : : : : : : : : : : : : : : : : : : : : : : : Megaprogramming and delayed binding : : : : : : : : : : : : : : : : Very high level languages : : : : : : : : : : : : : : : : : : : Component reuse : : : : : : : : : : : : : : : : : : : : : : : Delayed binding : : : : : : : : : : : : : : : : : : : : : : : : Megaprogramming successes : : : : : : : : : : : : : : : : : Rationale capture and dependency tracking : : : : : : : : : : : : : : : : : : : Predictable, assured evolution : : : : : : : : : : : : : : : : : : : : : : : : : : : Modeling / architecture application domains and solutions : : : : Analysis and prediction : : : : : : : : : : : : : : : : : : : : : : : : : Incremental adaptation : : : : : : : : : : : : : : : : : : : : : : : : : 78 vi

9 6.5 Summary : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 78 7 A maintenance perspective Introduction : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Categories of maintenance activities : : : : : : : : : : : : : : : : : : : : : : : : : : : Rationale for a focus on program comprehension : : : : : : : : : : : : : : : : Cognitive strategies in program comprehension : : : : : : : : : : : : : : : : : : : : : Knowledge necessary for program comprehension : : : : : : : : : : : : : : : : Toward a general model of program comprehension : : : : : : : : : : : : : : : Bottom-up model : : : : : : : : : : : : : : : : : : : : : : : : : : : : Situation model : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Top-down model : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Strategies of experts and novices : : : : : : : : : : : : : : : : : : : : : : : : : Program comprehension and tools : : : : : : : : : : : : : : : : : : : : : : : : : : : : Static analysis techniques : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Support for program comprehension : : : : : : : : : : : : : : : : : : Maintenance workbenches : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Support for program comprehension : : : : : : : : : : : : : : : : : : Debugging : : : : : : : : : : : : : : : : : : : : : : : : : : : Filtering : : : : : : : : : : : : : : : : : : : : : : : : : : : : Navigation : : : : : : : : : : : : : : : : : : : : : : : : : : : Slicing and dicing tools : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Support for program comprehension : : : : : : : : : : : : : : : : : : Integrated forward and reverse engineering tools : : : : : : : : : : : : : : : : Support for program comprehension : : : : : : : : : : : : : : : : : :100 vii

10 Identication of analysis and design level abstractions : : : Relating high level abstractions to domain concepts : : : : Identifying design decisions : : : : : : : : : : : : : : : : : : Documentation centered approaches : : : : : : : : : : : : : : : : : : : : : : : A summary of what we know : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Program comprehension involves multiple strategies : : : : : : : : : : : : : : Tool support is primarily directed toward the program model : : : : : : : : : Information about maintenance tactics is important : : : : : : : : : : : : : : Maintainers prefer toolkits : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Better ltering of information is needed : : : : : : : : : : : : : : : : : : : : : Sophisticated tools are not necessary for run-of-the-mill problems : : : : : : : Actual problems require a mix of tool support : : : : : : : : : : : : : : : : : Tools do not oer signicant help for the hardest problems : : : : : : : : : : Tools do not help the maintainer remember : : : : : : : : : : : : : : : : : : : Software undergoing maintenance does not t the mold supported by common maintenance support tools : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Toward an ideal maintenance toolkit : : : : : : : : : : : : : : : : : : : : : : : Summary : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :117 A Case studies and lessons learned 124 viii

11 List of Figures 2.1 Reengineering as constrained problem solving : : : : : : : : : : : : : : : : : : : : : : Creating system understanding : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Representing system understanding : : : : : : : : : : : : : : : : : : : : : : : : : : : : Engineering technology base : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : System evolution : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : A systems perspective of reengineering : : : : : : : : : : : : : : : : : : : : : : : : : : A reengineering process framework : : : : : : : : : : : : : : : : : : : : : : : : : : : : Issue assessment : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Decision analysis : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Solution development : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : System transition : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Process improvement : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Reverse engineering classication axes : : : : : : : : : : : : : : : : : : : : : : : : : : 34 ix

12 List of Tables 4.1 Reverse engineering approaches and pattern abstraction levels : : : : : : : : : : : : : Objective measures of project success : : : : : : : : : : : : : : : : : : : : : : : : : : Process Frequency (adapted from [von Mayrhauser 94]) : : : : : : : : : : : : : : : : Information Needs for \Read block in sequence" (adapted from [von Mayrhauser 94]) 91 x

13 Acknowledgements Numerous people contributed to this document. The engineering perspectives chapter is based on a technical report by Peter Feiler [Fei93]. The evolutionary perspective chapter is based on material originally written by Doug Waugh. The maintenance perspective chapter is based on a special report written by Ed Morris. Walter Lamia provided input on several perspectives. xi

14 Chapter 1 Introduction \Too many large organizations are mired in their IS sins of the past. Over 30 years of centralized, mainframe-oriented development together with system and application development models, underlying hardware and software technologies, user interface paradigmns, and other attibutes of ISs have brought most multinational companies, all levels of government organizations, and even a sizeable port of smaller organizations to a collective crisis point." Brodie & Stonebraker, Migrating Legacy Systems [BS95] 1.1 Evolutionary systems Until recently, most software was developed under the assumption that it would be maintained for a period of time and at some point replaced with a new system. As budgets have become tighter, as the use of COTS products has increased, and as the base of legacy systems has broadened, it has become more important to design and develop systems for continuous evolution. An emerging paradigm for evolution includes: early user involvement, use of currently available software assets, families of solutions, and the use of a single incremental approach toevolving a system. In order to implement the changing paradigm, it is often necessary to update, rehost, or otherwise change legacy systems. Reengineering enables the understanding and transformation of legacy assets. 1

15 CHAPTER 1. INTRODUCTION The need to reengineer The need to reengineer may be motivated by the desire to utilize more cost eective hardware or software platforms, to reduce the cost of software maintenance, to add signicant new functionality, or several other reasons. The goal of reengineering existing assets is to be more ecient than totally new development. Of particular technical interest are developments in the area of program understanding and system design recovery from legacy artifacts such as source code. This is a signicant problem in a wide array of application areas, where maintenance practices have failed to keep design and architectural documents (where they even exist) synchronous with changes to the running code. There is one major stumbling block on the road to evolutionary systems: the existing base of legacy systems. 1.3 Legacy systems Evolving over a numberofyears, legacy systems embody substantial corporate knowledge, including requirements, design decisions, and business rules. However, as the number of large systems 1 being built from scratch diminishes, the number of legacy systems in use grows accordingly. In order to eectively use these assets, it is important todevelop a systematic strategy for the continued evolution of currently elded systems to meet changing mission, technology and user needs. However, knowledge of the business rules and technical decisions is often embedded in the code. Such knowledge is dicult to recover after many years of operation, evolution, and personnel change. The software portion of a legacy system may have been written 10{25 years ago, developed using (what may now be viewed as) archaic and ad-hoc methodologies, and subjected to prolonged and sometimes dramatic (even traumatic) maintenance. The result is a legacy system that lacks the ability toevolve to meet ever-changing demands in a cost-eective manner. Reengineering oers an approach to migrating a legacy system towards an evolvable system. 1 The systems discussed in this document are software intensive: software constitutes a `signicant' portion of their realization. Unless otherwise noted, the term \system" implies \software system."

16 CHAPTER 1. INTRODUCTION Reengineering There are many denitions of reengineering, usually referring to the software portions of a system. The denition used in this document is: Reengineering is the systematic transformation of an existing system into a new form to realize quality improvements in operation, system capability, functionality, performance, or evolvability at a lower cost, schedule, or risk to the customer. This denition emphasizes that the focus of reengineering is on improving existing systems with a greater return on investment (ROI) than could be obtained through a new development eort. If reengineering isn't less costly, can't be accomplished in a shorter time frame, isn't less risky, or doesn't oer better value to the customer, then a new development eort should be considered. Subsequent chapters of this document will provide rened denitions that are more applicable to subareas of legacy system reengineering. Reengineering is closely related to maintenance, which is dened by ANSI/IEEE as \the modication of a software product after devlivery to correct faults, to improve performance or other attributes, or to adapt the product to a changed environment" [?]. By placing reengineering on a continuum with maintenance and new development, the true nature of reengineering becomes apparent. Maintenance entails making corrective, perfective, and adaptive changes to software, while development focuses on implementing new capabilities, adding functionality, or making substantial improvements typically by using new computer resources and incorporating new software technologies. Reengineering spans the gap between these two activities and exhibits characteristics of both. Since these activities are not precisely bounded, there may be signicant overlap. 1.5 Related issues Due to the breadth of reengineering topics, a number of issues are not covered here. The focus of this document is primarily on technical aspects of reengineering. However, economic and acquisition aspects play as important a role in the successful improvement of the capability to reengineer legacy systems. The cost of incremental change to a legacy system needs to be reduced. Criteria for deciding on the need for reengineering range from heuristics such as age of code and excessive maintenance personnel training cost (as found in a 1983 NIST document) to parameterized cost models (see [ISST 92, Santa Barbara 92]). Improvement in this cost is anticipated by investing more than the minimal

17 CHAPTER 1. INTRODUCTION 4 amount into reecting the requested change. The additional investment would go into improving the way the system has been engineered with the result of smaller incremental cost in the future. If several legacy systems have to be reengineered, their similarities can be captured in a common reusable architecture, treating them as a family of systems rather than isolated point solutions. The cost models for reengineering, together with better understanding of the eectiveness of dierent engineering techniques, will allow software engineers to make reasonable engineering tradeos as they choose a particular evolutionary reengineering strategy for a legacy system. Engineering eectiveness is inuenced by howwell an organization is able to manage its engineering process and improve its engineering capability. SEI has provided leadership for government and industry to improve these organizational software process capabilities through work on the Capability Maturity Model (CMM) and its use as an assessment and improvement tool. In the context of this paper we assume that the reader understands the relevance of such capabilities for an organization's ability to systematically, eciently, and eectively reengineer legacy systems.for further discussion of these and other inhibitors to successful transition of improved software engineering practice see the work done on transition models by SEI and others [Przybylinski 91; Leonard-Barton 88]. Successful improvement of legacy systems through reengineering also requires attention to improvements in the acquisition process and to legal concerns. The Joint Logistics Commanders Joint Policy Coordinating Group on Computer Resources Management has produced a Software Reengineering Assessment Handbook (SRAH) which addresses a number of the economic and decision making issues. 1.6 Outline The following chapters provide a set of perspectives on reengineering. These perspectives will serve to provide an overview of some of the major issues and trends in the eld. These perspectives will raise a number of issues, and provide references and pointers to sources for additional information. Chapter 2 provides an engineering perspective outlines the engineering issues which are faced with a legacy system. Since a current system already exists, reengineering is faced with a set of constraints and is constrained problem solving.reengineering also represents an opportunity to develop a long range plan for the evolution of the system and to develop the foundation for the evolution of a family of systems. Chapter 3 provides a systems perspective describes a full-spectrum decision analysis framework for the full set of activities that constitute a reengineering project. Five generic types of systems el-

18 CHAPTER 1. INTRODUCTION 5 ements forming the total system to be reengineered are identied, including the operational system, the operational support system, the logistical support systems, the system integration and testbed facilities, and the software development and maintenance facilities. Five project phases for decision making are also outlined, including: issue assessment, decision analysis, solution development, system transition, and eort evaluation. Chapter 4 provides a software perspective provides an overview of software reengineering, and outlines the context within which software reengineering activities take place. This perspective focuses on program understanding, and it develops an approach for classifying reverse engineering approaches. Chapter 5 provides a managerial perspective outlines the unique challenges which reengineering provides for planning and organizational change. The perspective outlines the analysis of the current system issues, goals, measurement factors, and plan components which are unique to reengineering. It also discusses the organizational issues which need to be addressed for a successful reengineering project. Chapter 6 provides an evolutionary perspective. It discusses the implications of a paradigm shift toward a model of evolving systems over a long period of time rather than replacing systems with new development. It discusses the implications of this shift, such as the central role of architecture, the need for rich system documentation, predictability, late binding, and organizational requirements. Chapter 7 provides a maintenance perspective discusses maintenance activities, cognitive strategies in program comprehension, and tool support for maintenance.

19 Chapter 2 An engineering perspective \Software engineering is somewhat like an art in that it begins with the identication of an objective and ends with a product that fullls it. The artist's goal is to produce awork of aesthetic value; the software engineer's purpose is to solve a problem using software." Bruce Blum Software Engineering A Holistic View [Blu92] 2.1 Introduction This chapter views legacy system reengineering as an engineering problem. Reengineering is dened as constrained problem solving. A framework which encompasses the major components of a reengineering activity is presented. The current reengineering state-of-the-practice of softwareintensive systems is summarized. 2.2 Reengineering as constrained problem solving The objective of applying reengineering technology to the problem of legacy systems is to facilitate the disciplined evolution of the system from its current state to a new (desired) state. This objective may be realized if one views reengineering as an engineering problem [Fei93]. The American Heritage dictionary (2nd edition) denes engineering as \the application of scientic and mathematical principles to practical ends." One might then reasonably dene software engineering as 6

20 CHAPTER 2. AN ENGINEERING PERSPECTIVE 7 System Understanding Plan Current System System Evolution Desired System Figure 2.1: Reengineering as constrained problem solving \the application of scientic and mathematical principles to practical ends in the software domain." It is in this context that reengineering is placed. In essence, engineering can be viewed as a problem solving activity. As illustrated in Figure 2.1, problem solving involves an understanding of the problem (i.e., a clear understanding of the root causes in terms of its existing state), an understanding of the desired state, and a path (plan) to evolve from the current state to the desired state. The salient dierence between engineering and reengineering as problem solving activities is that, with reengineering, a solution the legacy system already exists and must be considered when developing (evolving) a solution to the new problem. The legacy system imposes certain restrictions on the problem solving activity that might not otherwise exist in a completely new engineering eort. Thus, reengineering can be viewed as constrained problem solving. 2.3 A reengineering framework A framework can be created which views reengineering from an engineering and problem-soving perspective. As with all problem-solving activities, components of the framework include: the current solution; the desired solution;

21 CHAPTER 2. AN ENGINEERING PERSPECTIVE 8 a migration path; The current state reects properties of the existing system and the process by which the system is engineered (developed and maintained). Reengineering is undertaken when a subset of those properties is undesirable, reecting the problem to be solved. System understanding reects the process of creating and maintaining an understanding of a system (through elicitation, capture, and analysis). System evolution represents the engineering activity of migrating the existing system to the desired state. Based on an understanding of the current and desired system state and available (re)engineering technology, an analysis making engineering tradeos by considering technical, management, and economic risks and constraints results in a (re)engineering plan. During the execution of this plan (i.e., the actual evolution of the system through engineering activity), the plans may be reassessed taking into consideration changes in the context (e.g., technical changes such as promising new technol- ogies or economic changes such as budget reductions or increases) The current system state Reengineering is initiated when the current system is no longer evolvable in its current state in a cost-eective manner. The root causes for this fall into two categories: management of the engineering process and the engineering process itself. Management of the engineering process is addressed by process-improvement technologies, such as the Capability Maturity Model (CMM) [?], and will not be elaborated here. The second category represents technology root causes (i.e., the engineering process, methods, and tools). Reengineering is considered when existing legacy systems enjoy properties worth preserving. They are already deployed and have usually undergone signicant scrutiny by their users. A long history of maintenance has resulted in \stress-hardened" code and a wealth of test and validation capabilities. Nonfunctional properties such as performance and accuracy have been ne-tuned. System history exists in the form of original designers, current and past maintainers, and (potentially) in bug reports and change order records. However, the same history of maintenance that stress-hardened the system causes a problem: the system becomes \brittle" and increasingly resitant tochange. The technology root causes to this brittleness can can manifest themselves in a number of ways. The programmaning langauge used in the system's implementation may lack many of the features of more modern ones, such as support for data abstraction, modularity, information hiding, concurrency support, data modeling capabilities, and so on. Assumptions about the application environment mayhave been hardcoded in the implementation. Examples include assuming a point solution including xed number and types of real-world objects. The computing environment mayhaveevolved through several gen-

22 CHAPTER 2. AN ENGINEERING PERSPECTIVE 9 erations. For example, early hardware platforms were memory-limited, resulting in a number of sometimes (in today's view) convoluted implementation \tricks," such asoverlay, instruction reuse, and cryptic user interaction. Little operating system support was assumed. More modren computing environments typically consist of COTS standard operating systems, DBMSs, window systems, networking support, and are geared toward a high degree of interactiveness and \user-friendliness." Some of the root causes and their implications may be understood by some experts, but are not documented and available to the majority of software engineers. Information about legacy systems is often quite sparse, usually limited to the source code and/or executable, perhaps operations manual, and people maintaining the system. System representations such as architectural and design descriptions reecting the application domain and the implementation approach may never have been created or documented; the documentation (and sometimes even the source code) is out of date. This lack of up-to-date documentation causes problems when migrating the current system to its new desired state The desired system state The desired system state is a combination of properties of the existing system to be maintained, properties expected of a system as part of state-of-the-art software engineering practice and implementation technology, and properties that have their roots in changing environments and are reected in the system history, but may not have been explicitly expressed by the system user. Examples of maintained properties are functionality, performance, and accuracy. Examples of properties resulting from best practice software engineering and implementation technology include portability, modularity, structure, readability, testability, data independence, documented system understanding, openness (open system), interoperability, and seamless integration. Properties that address continuous change and provide exibility include localization of information regarding certain dierent types of change in both the application domain and the implementation, introduction of virtual machine abstractions, and parameterization (dynamic as well as generation technology), COTS, and reuse of components. Properties that encourage reuse of existing engineering knowhow include the existence of domain models, domain-independent software architectural principles, domain-specic architectures, and adaptable components. The desired system state may be known to system users, system maintainers, original system builders, and best software engineering practice experts. The customer (user) may not necessarily be aware of all the potentially desired properties and may only be willing and able to in- invest in some. Some desired properties can be provided with proven technology, while others depend on emerging technology whose maturity for practical application has not been demonstrated. In

23 CHAPTER 2. AN ENGINEERING PERSPECTIVE 10 System Artifacts Source code Manuals Operational system System Experts Developers Maintainers Users System History Error log Change orders System Understanding Figure 2.2: Creating system understanding any case, the desired system state can only be achieved by rst understanding the existing legacy system System understanding The current state of an existing system and its desired state represent an understanding of the system. This understanding is based on artifacts of the existing system; knowledge and experience with the system as it may exist in users', maintainers', and original builders' heads; and documented system history in the form of bug reports and change records. Figure 2.2 illustrates potential sources of information for creating system understanding. The artifacts are source code, manuals, and the executing system. The knowledge and experience with the system include understanding of engineering decisions, rationale, and possible or considered alternatives, as well as undocumented history and (typically nonfunctional) properties such as performance, robustness, and work-arounds. History provides insight into robustness of system components, types, and frequency of changes in the implementation and its environment. The capture, representation, currency, and accessibility of system understanding is a big challenge. As illustrated in Figure 2.3, a central component of system understanding is the system design record that document system representations at dierent levels of abstraction. This is complemented with rationale for design decisions, the software engineering process and methods used, and the evolution history.

24 CHAPTER 2. AN ENGINEERING PERSPECTIVE 11 System Design Record Domain Performance Reliability Models Architecture Design Implementation Rationale Process History Figure 2.3: Representing system understanding These representations are models of the system. Models reect views of the system focusing on certain aspects with dierent degrees of detail. The purpose of a model is to present a view that is understandable. This is accomplished by the model capturing those abstractions that are relevant from a particular perspective. Some models focus on architectural issues while other models focus on data representation, behavioral, reliability and performance aspects of a system. Examples of models include domain models, domain-specic architectures, and real-time timing models. Models have dierent degrees of formality and may have the ability to be executed. The models may reect designs (the notation they are expressed in needs to be transformed into executable implementations), or they may be executable and capture all the desired user functionality and can act as prototype implementations, which can be made more robust or ecient through reimplementation (transformation into a modeling notation that more appropriately satises the need). As more than one system is considered, models can show their similarities and dierences. Systems can be grouped into families. Some models focus on information about the application domain (domain models) while others focus on the implementation architecture. Domain models and domain-independent architectural modeling principles are combined to create domain-specic architectures. Those architectures are populated with components and adapted to the particular application needs. The result is a technology base of models that can be (re)used for a number of systems, leveraging existing engineering know-how. Domain analysis and architectural analysis contribute to the population of this technology base, while application engineering can get adapted to utilizing these models. This process is illustrated in Figure 2.4. Furthermore, the technology

25 CHAPTER 2. AN ENGINEERING PERSPECTIVE 12 base can be expanded by the emergence of new modeling concepts. While some models represent the executing system itself, other models reect constraints the system must satisfy. Those are models used to validate desired system behavior. Assertions validated in design reviews or verication, or translated into test suites and test data validating the behavior of the running system, are examples of such models. When reengineering a legacy system, such test and validation models exist and have stood the test of time. They can be leveraged for verication and validation of the desired system. Depending on the particular migration path to the desired system, alternatives to full regression testing may be considered. One example is validation of functional equivalence at a certain level of abstraction through comparison of event traces [Bri90]. Engineering decisions, rationale, and alternatives complement these models. They maybe captured through an elicitation process. The models together with the engineering knowledge are known in other engineering disciplines as experience modules. In this idealized view of system understanding, the amount of engineering information available to the engineer grows tremendously, resulting in information overload. In order to cope with this situation an intelligent intermediary (intelligent engineering assistant or engineering associate) will become essential to the successful utilization of the system understanding. Technologies that are potential contributors to this notion of intelligent assistant include case-based reasoning and intelligent tutoring. Such technologies can aid system understanding and help the engineer form a migration path for the legacy system Evolutionary migration path The understanding of the system, both the current and the desired system state, is the technical basis for determining the particular reengineering strategy to be chosen. It requires analysis, considering alternatives, and making engineering tradeos. Such a technical engineering analysis consists of two major components: choosing the degree of legacy leverage (what can be taken over and what has to be newly created), and choosing the approach for migrating over to the desired system, (how tointroduce the changes into the system). Rarely is any single approach appropriate by itself, but engineering tradeos need to be considered. The ability to utilize (recycle) as much as possible of the existing system in the process of evolving to the desired system may be termed legacy leverage. Both the existing and the desired system can be described in terms of a collection of models. For the legacy system, code exists. Other models may have to be derived from the code or other information sources. Certain abstractions

26 CHAPTER 2. AN ENGINEERING PERSPECTIVE 13 may not exist in the legacy system or may reect undesirable properties. The goal is to eliminate undesirable properties while at the same time introduce desirable properties. Choices have tobe made as to which legacy system models to ignore, which ones to transform, and which ones to leave intact. This is illustrated in Figure 2.5. The choices are driven by the understanding of the legacy and desired system properties as well as their reection in the dierent models. In concrete terms, this means that in some cases undesirable properties of legacy systems can be eliminated by massaging the code or transforming the data representation, while in other cases a new architecture or data model has to be developed and only a few system components can be translated into the new implementation language. The change can be introduced in a numberofways. The following are three classic approaches, although hybrid approaches are possible: New This approach ignores the exsiting legacy system as a solution. The desired system is newly developed, separate from the legacy system (although parts of the legacy system may be recycled). Once completed, the new system is put into operation and the old system is shut down. Incremental This approach incrementally phases out pieces of the legacy system. The architecture of the desired system may be created and a skeleton implementation developed. A mapping between the data representation of the current and desired system, implemented as a twoway transformation lter, allows the skeleton desired system to run as a shadow of the \live" legacy system. Parts of the desired system implementation are completed and incrementally added to the skeleton. Evolutionary This approach evolves the current system towards the desired system by phasing in new features over time. The legacy system code may be restructured to introduce modularity and partitioning. Desired system properties are incrementally introduced into the current system resulting in an incremental evolution of both the architecture and the system components. Validation of the desired system can utilize existing testing capabilities. Validation can be decomposed into verifying that the desired system still provides equivalent functionality and detection of bugs in the reimplementation. Risk analysis plays an important role in determining the evolutionary migration path from the current to the desired system. The choice of the particular reengineering strategy is aected by the risks inherent in alternative approaches and the ability to mitigate these risks. Some of the risks to consider include:

27 CHAPTER 2. AN ENGINEERING PERSPECTIVE 14 the cost, time, and eort of reengineering; the maturity level of technology inserted into the system; the ability to eliminate or reduce undesirable system properties; the impact of system changes on performance and robustness; and the impact of the deployment of the reengineered system; Summary Reengineering is an engineering activity that involves system understanding and evolution through application of appropriate engineering practices. It may viewed as constrained problem solving. The framework outlined in this section does not promote particular techniques but accommodates emerging technologies as they mature. 2.4 Summary A reengineering framework was described in which reengineering is seen as an engineering problem with constraints. A reengineering process framework was outlined. It can be used to guide the motivation, planning, and decision-making aspects of reengineering along with structuring the software practices and supporting technologies for implementing the full spectrum of reengineering activities. Since the process framework corresponds to the current state of practice in reengineering, it more closely reects what can best be described as \opportunistic" reengineering practices. It is expected that future renements of the process framework will produce a more advanced \forward-looking" reengineering framework. It will reect a model-based software engineering approach to reengineering based on an evolutionary systems development paradigm. The state-of-the-pratice was summarized. Because of the complexity of the total set of reengineering issues, the engineering framework and process framework presented in this chapter can serve as a guide for more detailed investigations of activities within the reengineering processes. Specic models can be developed to focus on selected aspects of the total reengineering eort, such as software reengineering, risk assessment, decision-making, design recovery, adaptation of reuse components, or organizational readiness for operational deployment. These topics are the subject of subsequent chapters of this document.

28 CHAPTER 2. AN ENGINEERING PERSPECTIVE 15 Technology Base Technology Experience Modules Domain models Domain-specific architectures Model Base Architectural principles Components Rationale Process Experience History System Understanding Plan Plan Current System System Evolution Desired System Figure 2.4: Engineering technology base

29 CHAPTER 2. AN ENGINEERING PERSPECTIVE 16 Architecture Design Code Current System Desired System Figure 2.5: System evolution

30 Chapter 3 A system perspective \As an essential enabler in reengineering, modern information technology has an importance to the reengineering process that is dicult to overstate. But companies need to beware of thinking that technology is the only essential element in reengineering." Hammer & Champy, Reengineering the Corporation [HC93] 3.1 Introduction This chapter provides an overview of reengineering from a system perspective. A framework which views reengineering as an engineering problem-solving activity is presented. A reengineering process framework is described that provides a unifying structure for the full spectrum of activities compromising a reengineering project. The current reengineering state-of-the-practice of software-intensive systems is summarized. 3.2 A reengineering process framework This section describes a unifying structure a process framework for the full spectrum of activities that constitute a reengineering project. Part of the framework's usefulness is as a reference model for planning a reengineering project and for identifying, describing, understanding, assessing, or evaluating the technical, managerial, and project-related factors that characterize reengineering eorts. The framework can serve as a tool for planning, implementing, and assessing reengineering projects. It also provides a context for establishing common terminology and nomenclature to 17

31 CHAPTER 3. A SYSTEM PERSPECTIVE 18 Reengineering of the TOTAL SYSTEM Business and Oganizational Goals & Objectives Customer Needs & Requirements Reengineering Project Direction Reengineer the Operational System SYSTEM TRANSITION ISSUE ASSESSMENT PROCESS IMPROVEMENT Software Development & Maintenance Facilities System Integration & Testbed Facilities Logistical Support Systems Operational Support Systems Operational System DECISION ANALYSIS Reengineered System Legacy System Assets SOLUTION DEVELOPMENT Figure 3.1: A systems perspective of reengineering describe reengineering activities, a basis for more detailed investigations of specic activities within the reengineering process, and as a mechanism for reporting and presenting reengineering \lessons learned." Reengineering is often incorrectly treated as being synonymous with software reengineering; its true scope is broader. In system reengineering it is important to understand that the operational system is only one part of the total legacy environment. Although the software (of the legacy system) is often the focal point of reengineering eorts, it alone is only one element of the complete system that must be considered when reengineering. Any of the system elements has the potential to be a signicant cost driver, technology problem, or management concern. Accordingly, this document emphasizes a total system's perspective as an essential rst step toward ensuring a successful reengineering eort. The elements forming the total system environment are shown in Figure??. The ve generic types of system elements that should be carefully considered when reengineering can be characterized as follows: Operational system The operationally deployed system that typically is the focal point of the reengineering eort and comprises the core functionality of the online system that is currently in operational use. Operational support system(s) The other ancillary online systems that interface or communi-

Software development process

Software development process OpenStax-CNX module: m14619 1 Software development process Trung Hung VO This work is produced by OpenStax-CNX and licensed under the Creative Commons Attribution License 2.0 Abstract A software development

More information

Design Specification for IEEE Std 1471 Recommended Practice for Architectural Description IEEE Architecture Working Group 0 Motivation

Design Specification for IEEE Std 1471 Recommended Practice for Architectural Description IEEE Architecture Working Group 0 Motivation Design Specification for IEEE Std 1471 Recommended Practice for Architectural Description IEEE Architecture Working Group 0 Motivation Despite significant efforts to improve engineering practices and technologies,

More information

Questions? Assignment. Techniques for Gathering Requirements. Gathering and Analysing Requirements

Questions? Assignment. Techniques for Gathering Requirements. Gathering and Analysing Requirements Questions? Assignment Why is proper project management important? What is goal of domain analysis? What is the difference between functional and non- functional requirements? Why is it important for requirements

More information

Development. Boston MA 02114 Murray Hill, NJ 07974 [CMU/SEI-95-SR-024]. A rational design process should address. software reuse.

Development. Boston MA 02114 Murray Hill, NJ 07974 [CMU/SEI-95-SR-024]. A rational design process should address. software reuse. Session 5: Key Techniques and Process Aspects for Product Line Development Nancy S. Staudenmayer Dewayne E. Perry Sloan School Software Production Research Massachusetts Institute of Technology Bell Laboratories

More information

Karunya University Dept. of Information Technology

Karunya University Dept. of Information Technology PART A Questions 1. Mention any two software process models. 2. Define risk management. 3. What is a module? 4. What do you mean by requirement process? 5. Define integration testing. 6. State the main

More information

Quotes from Object-Oriented Software Construction

Quotes from Object-Oriented Software Construction Quotes from Object-Oriented Software Construction Bertrand Meyer Prentice-Hall, 1988 Preface, p. xiv We study the object-oriented approach as a set of principles, methods and tools which can be instrumental

More information

Software Engineering. So#ware Processes

Software Engineering. So#ware Processes Software Engineering So#ware Processes 1 The software process A structured set of activities required to develop a software system. Many different software processes but all involve: Specification defining

More information

Introduction to software architecture

Introduction to software architecture Learning Unit 1 Introduction to software architecture Contents Introduction............................................... 7 1.1 What is software architecture?................................. 7 1.1.1

More information

Partnering for Project Success: Project Manager and Business Analyst Collaboration

Partnering for Project Success: Project Manager and Business Analyst Collaboration Partnering for Project Success: Project Manager and Business Analyst Collaboration By Barbara Carkenord, CBAP, Chris Cartwright, PMP, Robin Grace, CBAP, Larry Goldsmith, PMP, Elizabeth Larson, PMP, CBAP,

More information

Angel G. Jordan University Professor Emeritus Provost Emeritus Carnegie Mellon University Founder, Software Engineering Institute

Angel G. Jordan University Professor Emeritus Provost Emeritus Carnegie Mellon University Founder, Software Engineering Institute The Importance of Software Process Management for Software Quality, Testing and Industry Development Presented at the China s Software Quality, Testing and Industry Development Strategy Seminar Beijing

More information

Software Engineering/Courses Description Introduction to Software Engineering Credit Hours: 3 Prerequisite: 0306211(Computer Programming 2).

Software Engineering/Courses Description Introduction to Software Engineering Credit Hours: 3 Prerequisite: 0306211(Computer Programming 2). 0305203 0305280 0305301 0305302 Software Engineering/Courses Description Introduction to Software Engineering Prerequisite: 0306211(Computer Programming 2). This course introduces students to the problems

More information

CDC UNIFIED PROCESS JOB AID

CDC UNIFIED PROCESS JOB AID CDC UNIFIED PROCESS JOB AID Independent Verification & Validation Activities Document Purpose This Job Aid is a brief document listing the items to be noted, checked, remembered, and delivered when completing

More information

The Software Process. The Unified Process (Cont.) The Unified Process (Cont.)

The Software Process. The Unified Process (Cont.) The Unified Process (Cont.) The Software Process Xiaojun Qi 1 The Unified Process Until recently, three of the most successful object-oriented methodologies were Booch smethod Jacobson s Objectory Rumbaugh s OMT (Object Modeling

More information

CATALOG DESCRIPTION OF COURSES Offered by the department of Software Engineering

CATALOG DESCRIPTION OF COURSES Offered by the department of Software Engineering CATALOG DESCRIPTION OF COURSES Offered by the department of Software Engineering SE 201 Introduction to Software Engineering 3(3, 0, 1) Credits: 3 (3, 0, 1). Prerequisite: None. This course introduces

More information

Reaching CMM Levels 2 and 3 with the Rational Unified Process

Reaching CMM Levels 2 and 3 with the Rational Unified Process Reaching CMM Levels 2 and 3 with the Rational Unified Process Rational Software White Paper TP174 Table of Contents INTRODUCTION... 1 LEVEL-2, REPEATABLE... 3 Requirements Management... 3 Software Project

More information

NSF Workshop: High Priority Research Areas on Integrated Sensor, Control and Platform Modeling for Smart Manufacturing

NSF Workshop: High Priority Research Areas on Integrated Sensor, Control and Platform Modeling for Smart Manufacturing NSF Workshop: High Priority Research Areas on Integrated Sensor, Control and Platform Modeling for Smart Manufacturing Purpose of the Workshop In October 2014, the President s Council of Advisors on Science

More information

A Comparison of SOA Methodologies Analysis & Design Phases

A Comparison of SOA Methodologies Analysis & Design Phases 202 A Comparison of SOA Methodologies Analysis & Design Phases Sandra SVANIDZAITĖ Institute of Mathematics and Informatics, Vilnius University Abstract. Service oriented computing is a new software engineering

More information

The Phios Whole Product Solution Methodology

The Phios Whole Product Solution Methodology Phios Corporation White Paper The Phios Whole Product Solution Methodology Norm Kashdan Phios Chief Technology Officer 2010 Phios Corporation Page 1 1 Introduction The senior staff at Phios has several

More information

Integrating A Software Product Line Strategy with a Product Production Strategy: A Case Study. Abstract. Introduction

Integrating A Software Product Line Strategy with a Product Production Strategy: A Case Study. Abstract. Introduction Integrating A oftware Product Line trategy with a Product Production trategy: A Case tudy John D. McGregor Clemson University Luminary oftware, LLC johnmc@lumsoft.com Melissa L. Russ Luminary oftware,

More information

A Componentware Methodology based on Process Patterns Klaus Bergner, Andreas Rausch Marc Sihling, Alexander Vilbig Institut fur Informatik Technische Universitat Munchen D-80290 Munchen http://www4.informatik.tu-muenchen.de

More information

Fundamentals of Measurements

Fundamentals of Measurements Objective Software Project Measurements Slide 1 Fundamentals of Measurements Educational Objective: To review the fundamentals of software measurement, to illustrate that measurement plays a central role

More information

Guidelines for Developing a Product Line Concept of Operations

Guidelines for Developing a Product Line Concept of Operations Guidelines for Developing a Product Line Concept of Operations Sholom Cohen August 1999 TECHNICAL REPORT CMU/SEI-99-TR-008 ESC-TR-99-008 Pittsburgh, PA 15213-3890 Guidelines for Developing a Product Line

More information

IT Owes Much to PMOs

IT Owes Much to PMOs IT Owes Much to PMOs Doing More with Less Doing more with less is the mantra of IT organizations reuse and productivity, and nowhere recently have these principles been more effectively applied than in

More information

Applying 4+1 View Architecture with UML 2. White Paper

Applying 4+1 View Architecture with UML 2. White Paper Applying 4+1 View Architecture with UML 2 White Paper Copyright 2007 FCGSS, all rights reserved. www.fcgss.com Introduction Unified Modeling Language (UML) has been available since 1997, and UML 2 was

More information

Introduction to SOA governance and service lifecycle management.

Introduction to SOA governance and service lifecycle management. -oriented architecture White paper March 2009 Introduction to SOA governance and Best practices for development and deployment Bill Brown, executive IT architect, worldwide SOA governance SGMM lead, SOA

More information

A Glossary of Project Management Terms

A Glossary of Project Management Terms OpenStax-CNX module: m31434 1 A Glossary of Project Management Terms Merrie Barron, PMP, CSM Andrew R. Barron This work is produced by OpenStax-CNX and licensed under the Creative Commons Attribution License

More information

programming languages, programming language standards and compiler validation

programming languages, programming language standards and compiler validation Software Quality Issues when choosing a Programming Language C.J.Burgess Department of Computer Science, University of Bristol, Bristol, BS8 1TR, England Abstract For high quality software, an important

More information

Your guide to DevOps. Bring developers, IT, and the latest tools together to create a smarter, leaner, more successful coding machine

Your guide to DevOps. Bring developers, IT, and the latest tools together to create a smarter, leaner, more successful coding machine Your guide to DevOps Bring developers, IT, and the latest tools together to create a smarter, leaner, more successful coding machine Introduction The move to DevOps involves more than new processes and

More information

SOFTWARE DEVELOPMENT STANDARD FOR SPACECRAFT

SOFTWARE DEVELOPMENT STANDARD FOR SPACECRAFT SOFTWARE DEVELOPMENT STANDARD FOR SPACECRAFT Mar 31, 2014 Japan Aerospace Exploration Agency This is an English translation of JERG-2-610. Whenever there is anything ambiguous in this document, the original

More information

A Variability Viewpoint for Enterprise Software Systems

A Variability Viewpoint for Enterprise Software Systems 2012 Joint Working Conference on Software Architecture & 6th European Conference on Software Architecture A Variability Viewpoint for Enterprise Software Systems Matthias Galster University of Groningen,

More information

Avaya Strategic Communications. Consulting. A Strong Foundation for Superior Business Results. Table of Contents. Taking Business Vision to Reality

Avaya Strategic Communications. Consulting. A Strong Foundation for Superior Business Results. Table of Contents. Taking Business Vision to Reality Avaya Strategic Communications Consulting Table of Contents Taking Business Vision to Reality... 1 Section 1: The Technology Contribution Challenge..... 1 Section 2: A Systematic Approach for Ensuring

More information

French Scheme CSPN to CC Evaluation

French Scheme CSPN to CC Evaluation French Scheme CSPN to CC Evaluation Antoine COUTANT ITSEF AMOSSYS 4 bis allée du bâtiment 35000 Rennes antoine.coutant@amossys.fr Abstract. Since 2008, French certication body created a new scheme for

More information

A Guide to Open Source Transformation Services. How and Why Organizations are Making the Move to Open Source

A Guide to Open Source Transformation Services. How and Why Organizations are Making the Move to Open Source A Guide to Open Source Transformation Services How and Why Organizations are Making the Move to Open Source A fter decades of relying on commercial off-the-shelf software (COTS), thousands are moving to

More information

Systems Development Life Cycle (SDLC)

Systems Development Life Cycle (SDLC) DEPARTMENT OF BUDGET & MANAGEMENT (SDLC) Volume 1 Introduction to the SDLC August 2006 Table of Contents Introduction... 3 Overview... 4 Page 2 of 17 INTRODUCTION 1.0 STRUCTURE The SDLC Manual consists

More information

OSI Solution Architecture Framework

OSI Solution Architecture Framework OSI Solution Architecture Framework Enterprise Service Center April 2008 California Health and Human Services Agency Revision History REVISION HISTORY REVISION/WORKSITE # DATE OF RELEASE OWNER SUMMARY

More information

The Role of the Software Architect

The Role of the Software Architect IBM Software Group The Role of the Software Architect Peter Eeles peter.eeles@uk.ibm.com 2004 IBM Corporation Agenda Architecture Architect Architecting Requirements Analysis and design Implementation

More information

To introduce software process models To describe three generic process models and when they may be used

To introduce software process models To describe three generic process models and when they may be used Software Processes Objectives To introduce software process models To describe three generic process models and when they may be used To describe outline process models for requirements engineering, software

More information

Plan-Driven Methodologies

Plan-Driven Methodologies Plan-Driven Methodologies The traditional way to develop software Based on system engineering and quality disciplines (process improvement) Standards developed from DoD & industry to make process fit a

More information

A B C. Decomposition I Y

A B C. Decomposition I Y Software Development byevolution 3 Shaoying Liu Department of Computer Science Faculty of Information Sciences Hiroshima City University, Japan Email: shaoying@cs.hiroshima-cu.ac.jp Introduction Software

More information

FRAUNHOFER INSTITUTE FOR EXPERIMENTAL SOFTWARE ENGINEERING IESE VARIATION MANAGEMENT: USER EXPERIENCE FOR EFFICIENCY IN PROVIDING SOLUTIONS

FRAUNHOFER INSTITUTE FOR EXPERIMENTAL SOFTWARE ENGINEERING IESE VARIATION MANAGEMENT: USER EXPERIENCE FOR EFFICIENCY IN PROVIDING SOLUTIONS FRAUNHOFER INSTITUTE FOR EXPERIMENTAL SOFTWARE ENGINEERING IESE VARIATION MANAGEMENT: USER EXPERIENCE FOR EFFICIENCY IN PROVIDING BUSINESS CUSTOMIZED APPLICATIONS SOLUTIONS 2 Do you need to develop variation-rich

More information

Strategic Program Management

Strategic Program Management Governance Assessment Organizational Change Management Strategic Program Management Continuous Improvement Framework Processes Strategy Strategic Program Management Bob Prieto Published by Construction

More information

The Capability Maturity Model for Software, Version 1.1

The Capability Maturity Model for Software, Version 1.1 The Capability Maturity Model for Software, Version 1.1 Mark C. Paulk xxx 1998 Carnegie Mellon University Pittsburgh, PA 15213-3890 Sponsored by the U.S. Department of Defense. 1997 by Carnegie Mellon

More information

Software Engineering in a Nutshell

Software Engineering in a Nutshell Overview of Software Engineering Principles 1 Software Engineering in a Nutshell Development of software systems whose size/ complexity warrants a team or teams of engineers multi-person construction of

More information

CS 389 Software Engineering. Lecture 2 Chapter 2 Software Processes. Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed.

CS 389 Software Engineering. Lecture 2 Chapter 2 Software Processes. Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed. CS 389 Software Engineering Lecture 2 Chapter 2 Software Processes Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed. Topics covered Software process models Process activities Coping

More information

IEEE SESC Architecture Planning Group: Action Plan

IEEE SESC Architecture Planning Group: Action Plan IEEE SESC Architecture Planning Group: Action Plan Foreward The definition and application of architectural concepts is an important part of the development of software systems engineering products. The

More information

Managing Variability in Software Architectures 1 Felix Bachmann*

Managing Variability in Software Architectures 1 Felix Bachmann* Managing Variability in Software Architectures Felix Bachmann* Carnegie Bosch Institute Carnegie Mellon University Pittsburgh, Pa 523, USA fb@sei.cmu.edu Len Bass Software Engineering Institute Carnegie

More information

CHAPTER 1 INTRODUCTION

CHAPTER 1 INTRODUCTION CHAPTER 1 INTRODUCTION 1.1 Background This thesis describes a multi-agent based architecture for an intelligent assistant system for use in software project planning. The research explored the role of

More information

Certified Software Quality Engineer (CSQE) Body of Knowledge

Certified Software Quality Engineer (CSQE) Body of Knowledge Certified Software Quality Engineer (CSQE) Body of Knowledge The topics in this Body of Knowledge include additional detail in the form of subtext explanations and the cognitive level at which the questions

More information

Software Life Cycle Processes

Software Life Cycle Processes Software Life Cycle Processes Objective: Establish a work plan to coordinate effectively a set of tasks. Improves software quality. Allows us to manage projects more easily. Status of projects is more

More information

Introduction to software architecture

Introduction to software architecture Open Learning Universiteit Unit 1 Learning Unit 1 Introduction to software architecture Contents Introduction............................................... 7 1.1 What is softwarearchitecture?.................................

More information

STA GROUP BUSINESS ARCHITECTURE. The following pages are an overview of STA s Business Architecture practice and its offerings.

STA GROUP BUSINESS ARCHITECTURE. The following pages are an overview of STA s Business Architecture practice and its offerings. STA GROUP BUSINESS ARCHITECTURE The following pages are an overview of STA s Business Architecture practice and its offerings. Business Architecture Offerings STA Group s Business Architecture Practice

More information

Understanding SOA Migration Using a Conceptual Framework

Understanding SOA Migration Using a Conceptual Framework Understanding SOA Migration Using a Conceptual Framework Maryam Razavian and Patricia Lago Department of Computer Science, VU University Amsterdam, the Netherlands m.razavian@few.vu.nl, patricia@cs.vu.nl

More information

Software Quality Factors OOA, OOD, and OOP Object-oriented techniques enhance key external and internal software quality factors, e.g., 1. External (v

Software Quality Factors OOA, OOD, and OOP Object-oriented techniques enhance key external and internal software quality factors, e.g., 1. External (v Object-Oriented Design and Programming Deja Vu? In the past: Structured = Good Overview of Object-Oriented Design Principles and Techniques Today: Object-Oriented = Good e.g., Douglas C. Schmidt www.cs.wustl.edu/schmidt/

More information

CREDENTIALS & CERTIFICATIONS 2015

CREDENTIALS & CERTIFICATIONS 2015 THE COMMUNITY FOR TECHNOLOGY LEADERS www.computer.org CREDENTIALS & CERTIFICATIONS 2015 KEYS TO PROFESSIONAL SUCCESS CONTENTS SWEBOK KNOWLEDGE AREA CERTIFICATES Software Requirements 3 Software Design

More information

Migrating Within the Cloud, SaaS to SaaS

Migrating Within the Cloud, SaaS to SaaS Migrating Within the Cloud, SaaS to SaaS A Real World Experience COLLABORATIVE WHITEPAPER SERIES COLLABORATIVE WHITE PAPER SERIES: Migrating Within the Cloud, SaaS to SaaS How do you know when a technology

More information

Business Intelligence COE. Defining the Role and Purpose of BI Center of Excellence

Business Intelligence COE. Defining the Role and Purpose of BI Center of Excellence Business Intelligence COE Defining the Role and Purpose of BI Center of Excellence Definition and Purpose Organizations across all industries continue to invest in technological solutions to improve and

More information

3.4.1 Definitions of Enterprise Architecture

3.4.1 Definitions of Enterprise Architecture 32 3 Positioning Enterprise Architecture Fig. 3.7 Applications for enterprise architecture Solution architecture Use enterprise architecture to create the high level design of an actual step in the enterprise

More information

Lecture 8 About Quality and Quality Management Systems

Lecture 8 About Quality and Quality Management Systems Lecture 8 About Quality and Quality Management Systems Kari Systä 10.03.2014 10.03.2014 TIE-21100/21106; K.Systä 1 Content of today s lecture Two weeks ago we discussed about testing and inspections, that

More information

SOA + BPM = Agile Integrated Tax Systems. Hemant Sharma CTO, State and Local Government

SOA + BPM = Agile Integrated Tax Systems. Hemant Sharma CTO, State and Local Government SOA + BPM = Agile Integrated Tax Systems Hemant Sharma CTO, State and Local Government Nothing Endures But Change 2 Defining Agility It is the ability of an organization to recognize change and respond

More information

STAND THE. Data Center Optimization. Q&A with an Industry Leader

STAND THE. Data Center Optimization. Q&A with an Industry Leader Q&A with an Industry Leader Government is faced with exploding demand to provide services to end users, be they ordinary citizens or war fighters. The data center is a primary resource that overworked

More information

Appendix B Data Quality Dimensions

Appendix B Data Quality Dimensions Appendix B Data Quality Dimensions Purpose Dimensions of data quality are fundamental to understanding how to improve data. This appendix summarizes, in chronological order of publication, three foundational

More information

Software Engineering. Software Processes. Based on Software Engineering, 7 th Edition by Ian Sommerville

Software Engineering. Software Processes. Based on Software Engineering, 7 th Edition by Ian Sommerville Software Engineering Software Processes Based on Software Engineering, 7 th Edition by Ian Sommerville Objectives To introduce software process models To describe three generic process models and when

More information

SYSTEMS AND SOFTWARE REQUIREMENTS SPECIFICATION (SSRS) TEMPLATE. Version A.4, January 2014 FOREWORD DOCUMENT CONVENTIONS

SYSTEMS AND SOFTWARE REQUIREMENTS SPECIFICATION (SSRS) TEMPLATE. Version A.4, January 2014 FOREWORD DOCUMENT CONVENTIONS SYSTEMS AND SOFTWARE REQUIREMENTS SPECIFICATION (SSRS) TEMPLATE Version A.4, January 2014 FOREWORD This document was written to provide software development projects with a template for generating a System

More information

BCS THE CHARTERED INSTITUTE FOR IT. BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 6 Professional Graduate Diploma in IT SOFTWARE ENGINEERING 2

BCS THE CHARTERED INSTITUTE FOR IT. BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 6 Professional Graduate Diploma in IT SOFTWARE ENGINEERING 2 BCS THE CHARTERED INSTITUTE FOR IT BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 6 Professional Graduate Diploma in IT SOFTWARE ENGINEERING 2 EXAMINERS REPORT Friday 2 nd October 2015 Answer any THREE

More information

WHITE PAPER: STRATEGIC IMPACT PILLARS FOR EFFICIENT MIGRATION TO CLOUD COMPUTING IN GOVERNMENT

WHITE PAPER: STRATEGIC IMPACT PILLARS FOR EFFICIENT MIGRATION TO CLOUD COMPUTING IN GOVERNMENT WHITE PAPER: STRATEGIC IMPACT PILLARS FOR EFFICIENT MIGRATION TO CLOUD COMPUTING IN GOVERNMENT IntelliDyne, LLC MARCH 2012 STRATEGIC IMPACT PILLARS FOR EFFICIENT MIGRATION TO CLOUD COMPUTING IN GOVERNMENT

More information

Domain-specific Engineering

Domain-specific Engineering Domain-specific Engineering Grady H. Campbell, Jr. Prosperity Heights Software 8457 Van Court Annandale, VA 22003 1 703 573 3139 GradyCampbell@acm.org ABSTRACT The development of software today is a craft

More information

a new generation software test automation framework - CIVIM

a new generation software test automation framework - CIVIM a new generation software test automation framework - CIVIM Software Testing is the last phase in software development lifecycle which has high impact on the quality of the final product delivered to the

More information

JOURNAL OF OBJECT TECHNOLOGY

JOURNAL OF OBJECT TECHNOLOGY JOURNAL OF OBJECT TECHNOLOGY Online at www.jot.fm. Published by ETH Zurich, Chair of Software Engineering JOT, 2006 Vol. 5. No. 8, November-December 2006 Requirements Engineering Tasks Donald Firesmith,

More information

JOURNAL OF OBJECT TECHNOLOGY

JOURNAL OF OBJECT TECHNOLOGY JOURNAL OF OBJECT TECHNOLOGY Online at http://www.jot.fm. Published by ETH Zurich, Chair of Software Engineering JOT, 2007 Vol. 6, No. 1, January-February 2007 CM Configuration Change Management John D.

More information

M 1: Management Overview. The Open Group. The Open Group Architecture Framework (TOGAF 9.1) Certification Level 1 and Level 2. Objectives.

M 1: Management Overview. The Open Group. The Open Group Architecture Framework (TOGAF 9.1) Certification Level 1 and Level 2. Objectives. M 1: Management Overview Agenda The Open Group The Open Group Architecture Framework (TOGAF 9.1) Certification Level 1 and Level 2 Architecture Forum Mission Stakeholders and Value What is an Enterprise?

More information

Software Re-engineering

Software Re-engineering Software Re-engineering Prepared By: Dr. Linda H. Rosenberg Engineering Section head Software Assurance Technology Center Unisys Federal Systems 301-286-0087 Linda.Rosenberg@gsfc.nasa.gov Accepted By:

More information

Adopting Service Oriented Architecture increases the flexibility of your enterprise

Adopting Service Oriented Architecture increases the flexibility of your enterprise Adopting Service Oriented Architecture increases the flexibility of your enterprise Shireesh Jayashetty, Pradeep Kumar M Introduction Information Technology (IT) systems lasted longer earlier. Organization

More information

CHAPTER 5: Implications

CHAPTER 5: Implications CHAPTER 5: Implications This chapter will provide a brief summary of the study, relate the findings to prior research, and suggest possible directions for future studies. Summary of the study The goal

More information

Information paper. Best Practice for Successful Implementation of ISO 20022 for Financial Institutions

Information paper. Best Practice for Successful Implementation of ISO 20022 for Financial Institutions Information paper Best Practice for Successful Implementation of ISO 20022 for Financial Institutions Contents Executive summary...3 The ISO 20022 standard...3 Growth of ISO 20022 adoption...4 Adoption

More information

A SOFTWARE REVERSE ENGINEERING METHODOLOGY FOR LEGACY MODERNIZATION

A SOFTWARE REVERSE ENGINEERING METHODOLOGY FOR LEGACY MODERNIZATION A SOFTWARE REVERSE ENGINEERING METHODOLOGY FOR LEGACY MODERNIZATION Oladipo Onaolapo Francisca 1 and Anigbogu Sylvanus Okwudili 2 1, 2 Department of Computer Science, Nnamdi Azikiwe University, Awka, Nigeria.

More information

White Paper Case Study: How Collaboration Platforms Support the ITIL Best Practices Standard

White Paper Case Study: How Collaboration Platforms Support the ITIL Best Practices Standard White Paper Case Study: How Collaboration Platforms Support the ITIL Best Practices Standard Abstract: This white paper outlines the ITIL industry best practices methodology and discusses the methods in

More information

Procurement Programmes & Projects P3M3 v2.1 Self-Assessment Instructions and Questionnaire. P3M3 Project Management Self-Assessment

Procurement Programmes & Projects P3M3 v2.1 Self-Assessment Instructions and Questionnaire. P3M3 Project Management Self-Assessment Procurement Programmes & Projects P3M3 v2.1 Self-Assessment Instructions and Questionnaire P3M3 Project Management Self-Assessment Contents Introduction 3 User Guidance 4 P3M3 Self-Assessment Questionnaire

More information

Chapter 3 - Information Systems Development 1

Chapter 3 - Information Systems Development 1 Chapter Three Information System Development C H A P T E R 3 INFORMATION SYSTEMS DEVELOPMENT Describe the motivation for a system development process in terms of the Capability Maturity Model (CMM) for

More information

Using Requirements Traceability Links At Runtime A Position Paper

Using Requirements Traceability Links At Runtime A Position Paper Using Requirements Traceability Links At Runtime A Position Paper Alexander Delater, Barbara Paech University of Heidelberg, Institute of omputer Science Im Neuenheimer Feld 326, 69120 Heidelberg, Germany

More information

Software maintenance. Software Maintenance. Fundamental problems. Maintenance activities. Lehman/Belady model of evolution. Topics

Software maintenance. Software Maintenance. Fundamental problems. Maintenance activities. Lehman/Belady model of evolution. Topics Software maintenance Software Maintenance Key problems/issues Historical models and data Program Defined in IEEE Standard 1219 as: The modification of a software product after delivery to correct faults,

More information

Introduction to the. David Garlan and Dewayne Perry. For example, the box and line diagrams and explanatory

Introduction to the. David Garlan and Dewayne Perry. For example, the box and line diagrams and explanatory 1 Introduction to the Special Issue on Software Architecture David Garlan and Dewayne Perry I. What is software architecture? A critical aspect of the design for any large software system is its gross

More information

Business Architecture Guild Body of Knowledge Handbook 2.0

Business Architecture Guild Body of Knowledge Handbook 2.0 Guild Body of Knowledge Handbook 2.0 ------------------------ Section 1: Introduction The Guild has made this Introduction section of its Body of Knowledge Handbook 2.0 ( Handbook ) publicly available

More information

NASCIO EA Development Tool-Kit Solution Architecture. Version 3.0

NASCIO EA Development Tool-Kit Solution Architecture. Version 3.0 NASCIO EA Development Tool-Kit Solution Architecture Version 3.0 October 2004 TABLE OF CONTENTS SOLUTION ARCHITECTURE...1 Introduction...1 Benefits...3 Link to Implementation Planning...4 Definitions...5

More information

W H I T E P A P E R E n a b l i n g D a t a c e n t e r A u t o mation with Virtualized Infrastructure

W H I T E P A P E R E n a b l i n g D a t a c e n t e r A u t o mation with Virtualized Infrastructure W H I T E P A P E R E n a b l i n g D a t a c e n t e r A u t o mation with Virtualized Infrastructure Sponsored by: VMware Tim Grieser August 2008 IDC OPINION Global Headquarters: 5 Speen Street Framingham,

More information

Evaluating Data Warehousing Methodologies: Objectives and Criteria

Evaluating Data Warehousing Methodologies: Objectives and Criteria Evaluating Data Warehousing Methodologies: Objectives and Criteria by Dr. James Thomann and David L. Wells With each new technical discipline, Information Technology (IT) practitioners seek guidance for

More information

Fourth generation techniques (4GT)

Fourth generation techniques (4GT) Fourth generation techniques (4GT) The term fourth generation techniques (4GT) encompasses a broad array of software tools that have one thing in common. Each enables the software engineer to specify some

More information

ENTERPRISE ARCHITECTUE OFFICE

ENTERPRISE ARCHITECTUE OFFICE ENTERPRISE ARCHITECTUE OFFICE Date: 12/8/2010 Enterprise Architecture Guiding Principles 1 Global Architecture Principles 1.1 GA1: Statewide Focus 1.1.1 Principle Architecture decisions will be made based

More information

Microsoft Dynamics AX 2012 A New Generation in ERP

Microsoft Dynamics AX 2012 A New Generation in ERP A New Generation in ERP Mike Ehrenberg Technical Fellow Microsoft Corporation April 2011 Microsoft Dynamics AX 2012 is not just the next release of a great product. It is, in fact, a generational shift

More information

Risk Management Framework

Risk Management Framework Risk Management Framework Christopher J. Alberts Audrey J. Dorofee August 2010 TECHNICAL REPORT CMU/SEI-2010-TR-017 ESC-TR-2010-017 Acquisition Support Program Unlimited distribution subject to the copyright.

More information

Requirements engineering

Requirements engineering Learning Unit 2 Requirements engineering Contents Introduction............................................... 21 2.1 Important concepts........................................ 21 2.1.1 Stakeholders and

More information

Increasing Development Knowledge with EPFC

Increasing Development Knowledge with EPFC The Eclipse Process Framework Composer Increasing Development Knowledge with EPFC Are all your developers on the same page? Are they all using the best practices and the same best practices for agile,

More information

Improving Software Development Economics Part II: Reducing Software Product Complexity and Improving Software Processes

Improving Software Development Economics Part II: Reducing Software Product Complexity and Improving Software Processes Improving Software Development Economics Part II: Reducing Software Product Complexity and Improving Software Processes by Walker Royce Vice President and General Manager Strategic Services Rational Software

More information

Object-Oriented Systems Analysis and Design

Object-Oriented Systems Analysis and Design Object-Oriented Systems Analysis and Design Noushin Ashrafi Professor of Information System University of Massachusetts-Boston Hessam Ashrafi Software Architect Pearson Education International CONTENTS

More information

Modular Safety Cases

Modular Safety Cases Modular Safety Cases Facilitating Incremental Upgrade to Military Capability by Managing the Complexity of Safety Assurance Executive Summary Maintaining military capability at state of the art levels,

More information

University of Calgary Schulich School of Engineering Department of Electrical and Computer Engineering

University of Calgary Schulich School of Engineering Department of Electrical and Computer Engineering University of Calgary Schulich School of Engineering Department of Electrical and Computer Engineering Research Area: Software Engineering Thesis Topics proposed by Dr. Dietmar Pfahl, Assistant Professor

More information

JOURNAL OF OBJECT TECHNOLOGY

JOURNAL OF OBJECT TECHNOLOGY JOURNAL OF OBJECT TECHNOLOGY Online at www.jot.fm. Published by ETH Zurich, Chair of Software Engineering JOT, 2008 Vol. 7, No. 6, July-August 2008 Aligning IT to Business Through Architecture Mahesh H.

More information

Assessing Your Information Technology Organization

Assessing Your Information Technology Organization Assessing Your Information Technology Organization Are you running it like a business? By: James Murray, Partner Trey Robinson, Director Copyright 2009 by ScottMadden, Inc. All rights reserved. Assessing

More information

Renaissance: A Method to Support Software System Evolution

Renaissance: A Method to Support Software System Evolution Renaissance: A Method to Support Software System Evolution Ian Warren and Jane Ransom Computing Department Lancaster University Lancaster, LA1 4YR, UK Email iw bjr@comp.lancs.ac.uk Abstract Legacy s are

More information

Siemens PLM Software: Building Automotive Leadership

Siemens PLM Software: Building Automotive Leadership Siemens PLM Software: Building Automotive Leadership CIMdata Commentary Key takeaways: In the automotive industry, PLM is a critical, extended-enterprise business solution Siemens PLM Software has extensive

More information

BUSINESS RULES AND GAP ANALYSIS

BUSINESS RULES AND GAP ANALYSIS Leading the Evolution WHITE PAPER BUSINESS RULES AND GAP ANALYSIS Discovery and management of business rules avoids business disruptions WHITE PAPER BUSINESS RULES AND GAP ANALYSIS Business Situation More

More information