Software engineering has become an important field of computer science and an active research field. Due to new trend and technology most of the software is in need of change. Any software that has crossed a decade are incapable of satisfying customer need with current technology is named legacy system. To overcome this hazard and to be cost benefited, in facing the new trends the software has to be reengineered in a benefiting way. The legacy system, otherwise called existing system has to be reengineered. In Most of the reengineering system, the legacy transformation is the process of modernizing an operational system to retain and extend the value of investment in that system. It involves both infrastructure and application modernization. The primary benefit of legacy transformation is to enhance the business process and improve functionality of business objective. Legacy transformation projects are frequently challenged, because a set of risks will threaten the project success of legacy transformation. This paper presents a set of risks and their classification. From the analysis of risks, some mitigation that helps to make the reengineering projects more beneficial is suggested.

Organizations often suffer harm from individuals who bear them no malice but whose actions unintentionally expose the organizations to risk in some way. This paper examines initial findings from research on such cases, referred to as unintentional insider threat (UIT). The goal of this paper is to inform government and industry stakeholders about the problem and its possible causes and mitigation strategies. As an initial approach to addressing the problem, we developed an operational definition for UIT, reviewed research relevant to possible causes and contributing factors, and provided examples of UIT cases and their frequencies across several categories. We conclude the paper by discussing initial recommendations on mitigation strategies and countermeasures.

: The United States Department of Defense (DoD) increasingly depends on networked software systems. One result of this dependency is an increase in attacks on both military and non-military systems as attackers look to exploit software vulnerabilities. Program acquisition offices are emphasizing information assurance to address various threats. The Defense Information Systems Agency (DISA) created the Application Security and Development Security Technical Implementation Guide (STIG) in response to DoD Directive 8500.IE, which establishes policies and assigns responsibilities for achieving DoD information assurance. That STIG provides guidance for information assurance and security throughout a program s lifecycle, and it is specified as a requirement for DoD-developed, -architected, and -administered applications and systems that are connected to DoD networks.

: Many organizations are attracted to the well-documented benefits of a software product line approach. However, special challenges surround product line acquisition in the Department of Defense. We explain some basics of software product line practice, the challenges that make product line acquisition unique, and three basic acquisition strategies. We next describe the key contractual tasks a supplier must perform and map these to an enterprise view of product line acquisition. Using this context, we explain roles and responsibilities for the organizations involved, and describe important activities and deliverables. This provides a basis for building the necessary artifacts for a successful acquisition.

Abstract : This report summarizes a U.S. Army workshop on architecture that was held at the Carnegie Mellon Software Engineering Institute (SEI) in September of 2008, under the auspices of the Army Strategic Software Improvement Program (ASSIP). The workshop organizers invited accomplished practitioners from government, academia, and industry to discuss the various "genres" of architecture: Enterprise Architecture, system of systems architecture, system architecture, and software architecture. The goal of the workshop was to clarify the relationships among the different genres, explore and identify areas of commonality and difference, and to discuss the role of the Department of Defense Architecture Framework (DoDAF) in helping to capture these architectures. After a selection of opening talks by individuals that provide overviews of each subject area, the workshop dissolved into working groups. Each group was tasked with working on a specific set of issues and summarize their conclusions for the whole workshop. The issues discussed by each group include these: What are the major activities involved in each genre? 1. What is the boundary (e.g., information flow) between architecture in one genre and architectures in the other genres? 2. What do architectures in each genre need to consider in order to be considered successful? 3. How do we capture (document) an architecture in each genre? What notations and approaches are available? What are the minimum views and information necessary to ensure the architecture documentation will be adequate to support development and to conduct an evaluation as part of an acquisition? 4. How can the DoDAF be used to represent an architecture in each genre? What are its strengths and weaknesses with respect to each genre? How could it be improved? What is the current state of the practice with respect to using the DoDAF with each genre? This report summarizes the workshop and its findings.

: Department of Defense (DoD) acquisition programs routinely acquire systems that are highly software reliant. With the increasing functionality and complexity of these systems, software problems often contribute to schedule slippages, cost overruns, and system deficiencies. As a result, DoD acquisition organizations need to take proactive measures to reduce software acquisition risk. They cannot afford to just perform perfunctory reviews during software development and wait until after system delivery to determine whether key performance parameters (KPPs) and other acquisition/mission drivers that are important to stakeholders will be achieved. Since the architectural design of a system and its software has a major influence on whether a system achieves its KPPs (and other acquisition/mission drivers), conducting an architecture evaluation is an effective means for reducing software acquisition risk. The evaluation involves the active participation of key stakeholders and focuses on identifying risks (and overarching risk themes) that can affect the architecture's ability to accommodate the system's quality attribute requirements (e.g., performance, safety, and security). Satisfying these quality attribute requirements is key to satisfying KPPs and other stakeholder-specific acquisition/mission drivers. This technical note describes a proactive means for incorporating such a software architecture evaluation (in collaboration with the development contractor) early in the contract performance phase of a DoD system acquisition. The proven means that is described revolves around a sample Software Architecture Evaluation Plan that a DoD program office can easily customize and use in its own Request for Proposal (RFP)/contract. The sample plan covers all aspects-that is, the who, why, when, where, and how-of the government's approach to conducting a software architecture evaluation during an acquisition.

Abstract : The Army Strategic Software Improvement Program (ASSIP) is a multiyear effort targeted at improving the way in which the Army acquires software-intensive systems. The ASSIP has funded a number of programs, in conjunction with the Carnegie Mellon (R) Software Engineering Institute (SEI), to conduct software architecture evaluations using the Architecture Tradeoff Analysis Method(R) (ATAM(R)). Additionally, in cases when a system's architecture did not exist or was not ready to evaluate, the ASSIP sponsored Quality Attribute Workshops (QAWs). During the period of this effort, several other programs funded their own ATAM evaluations and QAWs. The goal of this study was to determine the benefits associated with using the ATAM and QAW. This special report describes the results of a study of the impact that the ATAM evaluations and QAWs had on Army programs. All 12 programs that used the ATAM and/or QAW responded to a questionnaire whose objective was to determine the impact of the experience in terms of the quality of the system, the practices of the involved program office, stakeholders, and suppliers, and the overall value of the engagement. The data gathered confirms that the use of ATAM-based architecture evaluations and QAWs are generally beneficial to system acquisitions and suggests that maximal benefit is achievable only if architecture-centric practices are built into the acquisition process.

THIS MATERIAL OF CARNEGIE MELLON UNIVERSITY AND ITS SOFTWARE ENGINEERING INSTITUTE IS FURNISHED ON AN “AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT.

ix 1 A Workshop on Architecture Genres for the U.S. Army 1 1.1 Background 1 1.2 Workshop Purpose 1 1.3 Workshop Participants 1 1.4 About This Workshop 2 1.5 Organization of This Report 4 2 Presentation Summaries 5 2.1 Enterprise Architecture―Carol Wortman, U.S. Army CIO/G-6 5 2.2 System of Systems Architecture―Judith Dahmann, Senior Principal Systems Engineer, Center for Acquisition and Systems Analysis, MITRE Corporation 7 2.3 System Architecture―Mark Maier, System Architect/Engineer, The Aerospace Corporation 13 2.4 Software Architecture―Mark Klein, Head, SEI Software Architecture Technology Initiative 17 2.5 Summary of DoDAF Presentations 19 3 Working Group Summaries 27 3.1 Overview 27 3.2 Enterprise Architecture Working Group 27 3.3 SoS Architecture Working Group 31 3.4 System Architecture Working Group 38 3.5 Software Architecture Working Group 44 4 Synthesis of Workshop Findings 51 4.1 What are the Major Activities Involved in Each Genre? 51 4.2 What is the Boundary between the Genres? 52 4.3 What Do Architectures in each Genre Need to Consider in Order to be Considered Successful? 54 4.4 How Do We document an Architecture in Each Genre? 54 4.5 How Can the DoDAF be Used 55 5 Conclusions and Future Work 57 Appendix Acronyms and Abbreviations 59

: The goal of the United States Army Strategic Software Improvement Program is to dramatically improve the acquisition of software-intensive systems. One of the initiatives undertaken by the program is to begin building a level of technical expertise in modern software architecture practices within the Army acquisition community. This report describes the Software Architecture Initiative of the Army Strategic Software Improvement Program. Results to date are encouraging and serve as a guide for other acquisition organizations seeking to strengthen their technical competencies.