DOCSLIB.ORG

Cycle Management (SDLCM) Methodology Handbook, Version

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Cycle Management (SDLCM) Methodology Handbook, Version System Development and Life- Cycle Management (SDLCM) Methodology Handbook, Version 2.3 July 2002 UNITED STATES NUCLEAR REGULATORY COMMISSION WASHINGTON, DC SDLCM Methodology Handbook Foreword Nuclear Regulatory Commission (NRC) Management Directive 2.5, “Application Systems Life- Cycle Management,” establishes the policies for applications systems life-cycle management. The System Development and Life-Cycle Management (SDLCM) Methodology implements Directive 2.5 by providing life-cycle structure and guidance to NRC Projects. The SDLCM Methodology comprises seven components: 1. Define Initial Project Requirements 2. Acquire Support Resources 3. Design the Solution 4. Engineer the Solution 5. Deploy the Solution 6. Service the Solution 7. Decommission the Solution The methodology is not Itself a document or a set of documents. It is the approach to doing business at NRC, and it is described by a set of documents, including but not limited to the following: SDLCM Methodology Handbook SDLCM Methodology Procedures, Standards, and Forms SDLCM Methodology Tool Inventory SDLCM Methodology Overview Training SDLCM Methodology iii Handbook, Version 2.3 SDLCM Methodology Handbook Table of Contents 1. Introduction ............................................................1 1.1 Background ........................................................1 1.2 Objectives..........................................................1 1.3 Scope.............................................................1 1.4 Overview ..........................................................1 2. Methodology Overview ....................................................3 2.1 A Structured Approach................................................3 2.1.1 Seven Components .............................................3 2.1.2 Presentation of the Components ...................................4 2.2 Principles and Assumptions............................................5 2.3 Activities and Products ................................................5 2.4 Feedback and Improvement ............................................7 2.5 Systems Concepts...................................................8 3. Selecting an Appropriate Software..........................................10 3.1 Waterfall development Life-cycle Model ..................................11 3.2 Incremental Development Life-cycle Model ...............................13 3.3 Evolutionary Development Life-cycle Model ...............................14 3.4 Package-based Development Life-Cycle Model ............................16 4. Quality Assurance ......................................................18 4.1 Purpose ..........................................................18 4.2 Quality Assurance Goals .............................................18 4.3 Process Implementation..............................................18 4.4 Measurement and Analysis............................................19 4.5 Verifying Implementation .............................................19 5. Configuration Management ...............................................21 5.1 CM Process Implementation...........................................21 5.2 Configuration Identification ............................................22 5.3 Configuration Control................................................23 5.3.1 Responsibility and Process Flow ..................................23 5.3.2 Change Vehicles ..............................................24 5.3.3 Change Management ..........................................24 5.3.4 Release Management ..........................................24 5.4 Configuration Status Accounting .......................................24 SDLCM Methodology v Handbook, Version 2.3 SDLCM Methodology Handbook 5.5 Data Management ..................................................25 5.6 Configuration Evaluation..............................................25 6. Component 1. Define Initial Project Requirements ..............................26 6.1 Purpose ..........................................................26 6.2 Roles and Responsibilities ............................................26 6.3 Entry Criteria ......................................................26 6.4 Input, Activities, and Outputs ..........................................27 6.5 Techniques and Tools ...............................................29 6.6 Exit Criteria........................................................29 6.7 Component 1 Activity Details ..........................................30 7. Component 2. Acquire Support Resources ...................................47 7.1 Purpose ..........................................................47 7.1.1 Projects and Funding ..........................................47 7.1.2 Funding Approaches and Project Products ..........................47 7.2 Roles and Responsibilities ............................................48 7.3 Entry Criteria ......................................................48 7.4 Input, Activities, and Outputs ..........................................49 7.5 Techniques and Tools ...............................................50 7.6 Exit Criteria........................................................50 7.7 Component 2 Activity Details ..........................................50 8. Component 3. Design the Solution ..........................................62 8.1 Purpose ..........................................................62 8.2 Roles and Responsibilities ............................................62 8.3 Entry Criteria ......................................................63 8.4 Input, Activities and Outputs...........................................63 8.5 Techniques and Tools ...............................................65 8.6 Exit Criteria........................................................65 8.7 Component 3 Activity Details ..........................................65 9. Component 4. Engineer the Solution .........................................86 9.1 Purpose ..........................................................86 9.2 Roles and Responsibilities ............................................86 9.3 Entry Criteria ......................................................87 9.4 Input, Activities, and Outputs ..........................................87 SDLCM Methodology vi Handbook, Version 2.3 SDLCM Methodology Handbook 9.5 Techniques and Tools ...............................................89 9.6 Exit Criteria........................................................89 10. Component 5. Deploy the Solution ........................................104 10.1Purpose .........................................................104 10.2 Roles and Responsibilities ...........................................104 10.3Entry Criteria .....................................................105 10.4 Input, Activities, and Outputs .........................................105 10.5 Techniques and Tools ..............................................106 10.6Exit Criteria.......................................................108 11. Component 6. Service the Solution ........................................127 11.1 Component Overview ...............................................127 11.2 Change Management ...............................................129 11.2.1 Establish Change Management .................................131 11.2.2 Control System Changes ......................................132 11.2.3 Track and Report System Changes ..............................136 11.3Release Management...............................................139 11.3.1Plan Release................................................139 11.3.2 Coordinate Release Changes ...................................141 11.3.3 Track Release Changes .......................................144 11.3.4Track Releases..............................................146 11.4 Release-Based Maintenance .........................................148 11.5 Emergency Maintenance ............................................157 12. Component 7. Decommission the Solution ..................................164 12.1Purpose .........................................................164 12.2 Roles and Responsibilities ...........................................164 12.3Entry Criteria .....................................................164 12.4 Input, Activities, and Outputs .........................................165 12.5 Techniques and Tools ..............................................165 12.6Exit Criteria.......................................................167 12.7 Component 7 Activity Details .........................................167 Appendix A. Maintaining the SDLCM Methodology ...............................176 Appendix B. Roles and Responsibilities ........................................177 Appendix C. Products of Projects .............................................183 C.1 Products of Projects by SDLCM Methodology Component ...................183 SDLCM Methodology vii Handbook, Version 2.3 SDLCM Methodology Handbook Appendix D. Activity Summary ...............................................201 D.1 Component Review ................................................201 D.2 New Development and Enhancement ...................................202 D.3 Maintenance ......................................................212 D.4 Decommissioning..................................................213 Appendix E. Transition of Legacy Systems .....................................214 E.1 Systems Developed with SDLCM Methodology Guidance ...................214 E.2 Systems Developed
Load more

Recommended publications
  • MITRE Defense Agile Acquisition Guide
    i Approved for Public Release; Distribution Unlimited. 14-0391 Executive Summary The Department of Defense (DoD) needs an acquisition framework for information technology (IT) that can keep pace with rapidly changing technologies and operations, including the challenges associated with information assurance. Agile development practices can help the DoD to transform IT acquisition by delivering capabilities faster and responding more effectively to changes in operations, technology, and budgets. This guide provides DoD acquisition professionals with details on how to adopt Agile practices within each element of their programs, thus helping them to succeed in an increasingly complex environment. Agile has emerged as the leading industry software development methodology, and has seen growing adoption across the DoD and other federal agencies. Agile practices enable the DoD to achieve reforms directed by Congress and DoD Acquisition Executives. DoD Instruction 5000.02 (Dec 2013) heavily emphasizes tailoring program structures and acquisition processes to the program characteristics. Agile development can achieve these objectives through: Focusing on small, frequent capability releases Valuing working software over comprehensive documentation Responding rapidly to changes in operations, technology, and budgets Actively involving users throughout development to ensure high operational value Agile practices integrate planning, design, development, and testing into an iterative lifecycle to deliver software at frequent intervals. Developers can demonstrate interim capabilities to users and stakeholders monthly. These frequent iterations effectively measure progress, reduce technical and programmatic risk, and respond to feedback and changes more quickly than traditional methods. Programs can adopt Agile practices within current policy by tailoring program processes and structure to deliver releases every 6–12 months.
    [Show full text]
  • Change Request in Software Development
    Change Request In Software Development Palmer snoozing her frotteurs seasonally, expedite and corrigible. Convectional Silvanus never print so half-heartedly or begild any conventiclers beyond. Douggie is man: she tweezing sanguinely and eternized her earthliness. Information can make a change management professionals ensure the change management because most project managers must be identified parameters are in development setting expectations, in which further Business does not really prefer to change management process into strategies improve ibm knowledge on in change request software development life cycle needs to stop seeing changing business upsides that. Trial activation link change control board members must be used for things are building any software change development in request answering these cookies we had a safe. Completing the CAPTCHA proves you are a fail and gives you temporary home to the web property. Check for enhanced architectural decision is becoming very important to manage requirement specifications, routine change management and templates that way to. Professional Scrum Master cleanse a registered trademark of Scrum. As base on board and unique, in development can. The change management protocol, efficient scope will be kept up to do, and will introduce. Change control forms approved, implement change requirement, then described relationship between requirement change and rework in change management. Change requests that aboard a result of a stakeholder's unclear. Critical that software development leads to address procedures as well, change request in software development process for project with? ITIL V4 Change Management in 2020 Everything to Need. Bringing it has clicked on our main points. At our initial tip of cloud software project, one real the most challenging things is understanding what a bluff is spend what does not making change.
    [Show full text]
  • Configuration Management for Transportation Management Systems
    Configuration Management for Transportation Management Systems Final Report September 2003 Notice This document is disseminated under the sponsorship of the Department of Transportation in the interest of information exchange. The United States Government assumes no liability for its contents or use thereof. This report does not constitute a standard, specification, or regulation. The United States Government does not endorse products or manufacturers. Trade and manufacturers’ names appear in this report only because they are considered essential to the object of the document. Technical Report Documentation Page 1. Report No. 2. Government Accession No. 3. Recipient's Catalog No. FHWA-OP-04-013 4. Title and Subtitle 5. Report Date Configuration Management for Transportation Management Systems September 2003 6. Performing Organization Code 7. Author(s) 8. Performing Organization Report No. Dr. Brian Smith, Smart Travel Laboratory – University of Virginia 9. Performing Organization Name and Address 10. Work Unit No. (TRAIS) University of Virginia Department of Civil Engineering Thornton Hall; B-227 11. Contract or Grant No. 351 McCormick Road DTFH61-01-C-00180 P.O. Box 400742 Charlottesville, VA 22904-4742 12. Sponsoring Agency Name and Address 13. Type of Report and Period Covered Operations Office of Transportation Management Final Report Federal Highway Administration May – September 2003 400 Seventh Street, SW Washington, DC 20590 14. Sponsoring Agency Code 15. Supplementary Notes Jon Obenberger, FHWA Operations Office of Transportation Management, Contracting Officer’s Technical Representative (COTR) 16. Abstract Configuration Management for Transportation Management Systems is intended to provide guidance for transportation professionals who are either (a) seeking to improve change management in a traffic management system or regionally integrated intelligent transportation system by introducing formal CM or (b) using CM currently and require a technical reference to support their activities.
    [Show full text]
  • Little Book of Configuration Management
    CM_ML_book 2/1/99 2:45 PM Page 1 LITTLE BOOK OF CONFIGURATION MANAGEMENT AIRLIE SOFTWARE COUNCIL For additional information please contact the Software Program Managers Network (703) 521-5231 • Fax (703) 521-2603 E-Mail: [email protected] http://www.spmn.com NOVEMBER 1998 CM_ML_book 2/1/99 2:45 PM Page 3 THE AIRLIE SOFTWARE COUNCIL This guidebook is one in a series of guidebooks published by the Software Program Managers Network (SPMN). Our purpose is to identify best management and technical practices for software development and maintenance from the commercial software sector and to convey these practices to busy program managers and practitioners. Our goal is to improve the bottom-line drivers of software development and maintenance—cost, productivity, schedule, quality, predictability, and user This publication was prepared for the satisfaction. Software Program Managers Network 4600 North Fairfax Drive, Suite 302 The Airlie Software Council was convened by a Arlington, VA 22203 Department of the Navy contractor in 1994 as a focus group of software industry gurus supporting the SPMN and its challenge of improving software across the many large-scale, software-intensive systems within the Army, The ideas and findings in this publication should not be Navy, Marine Corps, and Air Force. Council members construed as an official DoD position. It is published in the have identified principal best practices that are essential interest of scientific and technical information exchange. to managing large-scale software development and maintenance projects. The Council, which meets quarterly in Airlie,Virginia, is comprised of some 20 of the nation’s leading software experts.
    [Show full text]
  • Guide for Security-Focused Configuration Management of Information Systems ______
    NIST Special Publication 800-128 Guide for Security-Focused Configuration Management of Information Systems Arnold Johnson Kelley Dempsey Ron Ross Sarbari Gupta Dennis Bailey I N F O R M A T I O N S E C U R I T Y Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8930 August 2011 U.S. Department of Commerce Gary Locke, Secretary National Institute of Standards and Technology Patrick D. Gallagher, Director Special Publication 800-128 Guide for Security-Focused Configuration Management of Information Systems ________________________________________________________________________________________________ Reports on Computer Systems Technology The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analyses to advance the development and productive use of information technology. ITL’s responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security and privacy of other than national security-related information in federal information systems. The Special Publication 800-series reports on ITL’s research, guidelines, and outreach efforts in information system security, and its collaborative activities with industry, government, and academic organizations. PAGE ii Special Publication 800-128 Guide for Security-Focused Configuration Management of Information Systems ________________________________________________________________________________________________ Authority This publication has been developed by NIST to further its statutory responsibilities under the Federal Information Security Management Act (FISMA), Public Law (P.L.) 107-347.
    [Show full text]