Technical Standards by oROMUF

VIEWS: 5 PAGES: 25

									                          NCDPI

System Development Life-Cycle




  Author(s):      Technical Architecture Team

  Last Revised:

  Version:        1.0

  Status:         Draft

  Access:         public
                                                                                             NCDPI SDLC: Standard SDLC


REVISION HISTORY

Rev.   Revision Date     Revised By                  Description                               Filename
 #
1.0     Jan 30, 2007                    Initial Draft                       DPI-System Development Lifecycle 1.0.doc
1.1     May 8, 2007    Frank Vierling   Added Development, Transition and   DPI-System Development Lifecycle 1.1.doc
                                        Installation Plan Deliverables to
                                        Development Phase




                                                                                                                    2
                                                                                                                  NCDPI SDLC: Standard SDLC




                                                          Table of Content

REVISION HISTORY .............................................................................................................................. 2
1.      STANDARD SYSTEM LIFE-CYCLE ............................................................................................. 7
     1.1     STRATEGIC IT PLANNING.............................................................................................................. 8
        1.1.1    Technical Standards ............................................................................................................. 8
        1.1.2    Business Process Reengineering .......................................................................................... 9
        1.1.3    IT Financial Investment Management .................................................................................. 9
        1.1.4    Enterprise Architecture (EA)................................................................................................ 9
     1.2     SYSTEM PLANNING PHASE ............................................................................................................ 9
        1.2.1    System Boundary Definition ............................................................................................... 10
        1.2.2    Cost Benefit Analysis .......................................................................................................... 11
        1.2.3    Buy vs. Build Analysis ........................................................................................................ 12
        1.2.4    Configuration Management Plan ....................................................................................... 12
        1.2.5    Risk Management Plan....................................................................................................... 13
        1.2.6    System Security Plan .......................................................................................................... 13
        1.2.7    Project Management Plan .................................................................................................. 13
        1.2.8    Concept of Operations ....................................................................................................... 13
        1.2.9    Validation and Verification Plan ....................................................................................... 14
        1.2.10   System Engineering Management Plan .............................................................................. 15
        1.2.11   Procurement Plan .............................................................................................................. 15
        1.2.12   Deliverables (Summary) ..................................................................................................... 16
     1.3     REQUIREMENTS PHASE ............................................................................................................... 16
        1.3.1    Developing Use-Cases ....................................................................................................... 16
        1.3.2    Developing Test criteria ..................................................................................................... 16
        1.3.3    Interface Requirements ...................................................................................................... 16
        1.3.4    Deliverables (Summary) ..................................................................................................... 17
     1.4     DESIGN PHASE ............................................................................................................................ 17
        1.4.1    Application Design ............................................................................................................. 17
        1.4.2    Conversion-Migration-Transition Strategies ..................................................................... 17
        1.4.3    Critical Design Review....................................................................................................... 17
        1.4.4    Deliverables ....................................................................................................................... 17
     1.5     DEVELOPMENT PHASE ................................................................................................................ 18
        1.5.1    Software installation or Coding ......................................................................................... 18
        1.5.2    Deliverables ....................................................................................................................... 18
     1.6     INTEGRATION AND TEST PHASE .................................................................................................. 19
        1.6.1    Establish Test environment ................................................................................................ 19
        1.6.2    Functional/Unit Testing ..................................................................................................... 19
        1.6.3    Functional System Testing ................................................................................................. 19
        1.6.4    Systems Integration Testing ............................................................................................... 19
        1.6.5    Systems Performance Testing ............................................................................................. 19
        1.6.6    User Acceptance Testing .................................................................................................... 19
        1.6.7    Establish Test environment ................................................................................................ 19
        1.6.8    Deliverables ....................................................................................................................... 19
     1.7     DEPLOYMENT PHASE .................................................................................................................. 19
        1.7.1    Training plan execution ..................................................................................................... 19
        1.7.2    System/Application Production Installation ....................................................................... 19


File: 06f17bfd-c843-4d6c-ab4b-ae8b453b2212.doc                                                                                             Page 3
                                                                                                                   NCDPI SDLC: Standard SDLC
        1.7.3    Installation Verification ..................................................................................................... 19
        1.7.4    Deliverables ....................................................................................................................... 19
     1.8     OPERATIONS/MAINTENANCE PHASE ........................................................................................... 20
        1.8.1    Identify Systems Operations ............................................................................................... 21
        1.8.2    Maintain Data/Software Administration ............................................................................ 21
        1.8.3    Problem Identification and Escalation Process ................................................................. 21
        1.8.4    User Satisfaction ................................................................................................................ 21
        1.8.5    Deliverables ....................................................................................................................... 21
     1.9     DEPOSITION PHASE ..................................................................................................................... 22
        1.9.1    Archive Data ...................................................................................................................... 22
        1.9.2    Archive Software ................................................................................................................ 22
        1.9.3    Archive System Life-Cycle Documentation ........................................................................ 22
        1.9.4    Disposition of Equipment ................................................................................................... 22
        1.9.5    Deliverables ....................................................................................................................... 22
2.      IMPLEMENTING OF THE SYSTEM LIFE-CYCLE ................................................................ 23
3.      APPENDIX ....................................................................................................................................... 24
     3.1       REFERENCES TO OTHER DOCUMENTS/STANDARDS ...................................................................... 24
     3.2       DOCUMENT TEMPLATES ............................................................................................................. 25




File: 06f17bfd-c843-4d6c-ab4b-ae8b453b2212.doc                                                                                               Page 4
                                                                NCDPI SDLC: Standard SDLC



Purpose of this Document
     This document describes the standard development life cycle at NC-DPI. The
     document in trying to address the need for:
     - documentation of systems overall,
     - a standard process which governs the development of a system or service,
     - Understanding which phase of the project has what deliverables,
     - To be able to meet the PPM-Tool requirements on the State-level to seek initial
        and subsequent approvals to go forward.




File: 06f17bfd-c843-4d6c-ab4b-ae8b453b2212.doc                                  Page 5
                                                                     NCDPI SDLC: Standard SDLC



1. Standard System Life-Cycle
     The Standard System Life-Cycle (SLC) consists of 8 different phases which
     start using the results of the Strategic IT Planning results.



           Strategic IT
            Planning




        System Planning              Requirements                              Development
                                                      Design Phase
             Phase                      Phase                                     Phase




                                                      Operations and
         Integration and
                                   Deployment Phase    Maintenance            Deposition Phase
           Test Phase
                                                         Phase



     System Planning Phase:
     This phase identified the high-level concepts and objectives of the system
     based on financial and IT-architecture goals.

     Requirements Phase:
     Primary objective is the analysis of the business needs and documentation
     of such.

     Design Phase:
     Considering interfaces to other businesses and systems the design phase
     defines the ground, components and principles used to build the solution.

     Development Phase:
     The actual implementation of the solution to either build, customize and/or
     install the solution.

     Integration and Test Phase:


File: 06f17bfd-c843-4d6c-ab4b-ae8b453b2212.doc                                       Page 7
                                                                            NCDPI SDLC: Standard SDLC


     After the implementation of the system the integration with other parts of the
     solution, existing or currently in the building process are needed to be
     docked onto the system. Testing verifies the internal and external testing
     starting preferably with individual parts of the system all the way up to the
     full integration test using all system components, interfaces, etc.

     Deployment Phase:
     Deployment, or roll-out, is the process of moving the solution into
     production. This phase is primarily process driven since all coding and
     testing has been done. The deployment phase needs to address change
     management as well as interactivity with other solutions which are in
     production. The deployment phase moves into the operations and
     maintenance phase typically after the application has been “broken-in”, is
     stable and reliable to be handed over to operations.

     Operations and Maintenance Phase:
     The operations and maintenance phase starts after the deployment and
     break-in of the system and covers the day-to-day management of the
     system. This include typical aspects of change management such as
     operating system patches, application patches, machine upgrades etc.

     Deposition Phase:
     This phase covers the process and steps required to retire a system.

1.1 Strategic IT Planning

      1.1.1 Technical Standards
      Technical standards should be met by IT systems in order to support
      integration, testing, maintenance and support but more importantly to
      support the overall technical directions and ability of the organization to
      flexibly adapt to ever-changing business needs.


                                                 Strategic IT
                                                  Planning




                                                                Technical
                                                                Standards




                           Figure 1 : Strategic IT Planning Deliverables




File: 06f17bfd-c843-4d6c-ab4b-ae8b453b2212.doc                                              Page 8
                                                              NCDPI SDLC: Standard SDLC


      1.1.2 Business Process Reengineering
     The success of an IT solution is directly proportional to the simplicity of the
     business process which the IT system needs to model. Every effort towards
     simplifying the business process increases the chance of success of the
     system. Therefore during the strategic IT planning phase business process
     modeling and analysis should be used to understand the complexity of the
     business process and how people to interact in a collaborative fashion to
     achieve a common and agreed business goal.
     Businesses normally don’t like a process re-engineering of their key
     processes but such processes have evolved over many years and are
     normally very complex to model. In many cases such business processes
     do only exist in people head. I.e.: “After I have done this activity and
     received an email from XYZ I can sum up the differences and enter them
     into the budged system so that the LEA can do their planning activity”.
     Within the Strategic It Planning considerable time should be spent to
     document the business process using business modeling tools which give a
     high-level view of the business process complexity, interactions between
     departments and other systems, decisions, timeline, etc.



      1.1.3 IT Financial Investment Management
     <TBD: Joe D. might be able to help here>


      1.1.4 Enterprise Architecture (EA)
      Common platforms, common skill requirements, common interfaces for
      sharing data, common standards for being able to select from a variety of
      vendors, etc. are all important aspects of a homogenous IT environment
      which is used for hosting the system. The goal of EA is to create and
      maintain a commonly use infrastructure based on sharing services.
      Ken:
      - diagrams required for assessment/documentation
      - security: Security aspects of the application, diagrams, templates,
         certification, etc
      - data integration interface specifications,



1.2 System Planning Phase




File: 06f17bfd-c843-4d6c-ab4b-ae8b453b2212.doc                                Page 9
                                                                                             NCDPI SDLC: Standard SDLC


      The System Planning Phase defines the overall business, financial and
      technology implications of providing the solution. In most cases these
      document do have much more business related context than technical
      context. Overall objective of this phase is to make a Go-No go decisions.


                                                          System Planning
                                                               Phase




                                        System Boundary
                                           Document                           Cost Benefit
                                                                               Analysis

                      Risk Management
                            Plan
                                                                                                    Concept of
                                                                                                    Operations

                                            Project
                                        Management Plan                      Configuration
                                                                            Management Plan

                      System Security
                           Plan
                                                                                                   Validation and
                                                                                                    Verification
                                            System
                                          Engineering
                                        Management Plan                     Procurement Plan




                               Figure 2: System Planning Deliverables




      1.2.1 System Boundary Definition
      The System Boundary Document (SBD) provides guidance on how to
      establish the boundaries of an information technology (IT) project. It
      records management decisions to mitigate and to accept a level of risk in
      the business, technological and project management environments.
      System development projects frequently experience cost overruns and
      schedule slippages due to a variety of reasons, including changing
      requirements and poor resource and schedule estimating. While
      requirements, schedule and resource changes will occur at times, these
      changes must be managed and controlled. Documented system
      boundaries are a tool for the management to use to provide this control.
      The SBD is applicable to all IT projects. The SBD captures the business
      functions, goals and objectives that the IT project will satisfy. It also
      captures critical success factors, assumptions and constraints for the IT
      project as well as performance measures that provide criteria to judge
      whether the IT satisfied the business goals and objectives. The SBD shall


File: 06f17bfd-c843-4d6c-ab4b-ae8b453b2212.doc                                                                   Page 10
                                                                NCDPI SDLC: Standard SDLC


       be approved by Financial Service, the Business (DPI department) and
       Technology Services.


       1.2.2 Cost Benefit Analysis
       In the initial planning phase a cost-benefit analysis needs to be conducted
       to evaluate the value of implementing the system. Together with the
       business TS staff needs to engage in determining the value based on
       agreed-upon evaluation criteria.

     Criterion                                  Aspect of Evaluation
Data access time             How fast can data be presented, searched, etc.
                             compared to the manual activities?
Timeliness of Data           How timely can data be presented to the business and
                             how does this impact the business positively?
Data accuracy                How many system users do access and review the data
                             and therefore validate its accuracy?
Manual effort                How much manual effort, measured in time, is being used
                             in the current process and how fast can the new system
                             be?
Processing Time              How much faster and how much more efficiently can the
                             business process using the new system. This is normally
                             measured by activities per time, transactions per time,
                             contracts per time, etc.
Customer Service             How much better can the business serve its customers
                             and what are the monetary and non-monetary
                             measurements?
Cost                         What are the various cost elements for the system?
                             (Development, management, maintenance, licensing,
                             support, training, etc.)

       This is only an example of a set of criteria which should be identified prior
       to conducting the cost-benefit analysis. The summary of the cost-benefit
       analysis balances all cost elements against the benefits of the system.
       The business needs to be fully aware and support this analysis. This
       analysis provides the rationale for the system and sets first boundaries of
       the scope of the implementation.




File: 06f17bfd-c843-4d6c-ab4b-ae8b453b2212.doc                                Page 11
                                                             NCDPI SDLC: Standard SDLC


      1.2.3 Buy vs. Build Analysis
      Before technology teams embark on developing a system using a custom-
      coding approach the requirements and the cost benefit analysis should be
      used to determine if such system is already available in the market space.
      An argument can always be made that the specific solution the customer is
      requesting has not been implemented yet and that maybe true in almost all
      cases. But the purpose of standard software is not to provide that level of
      service. The question is how close can the existing solution meet the
      requirements, technically and business wise, and what gap needs to be
      bridged with customization vs. implementing the solution from scratch.
      The benefits of a vendor providing the system are numerous:
             o Vendor needs to maintain the compliance requirements of the
                application.
             o Vendor needs to patch failing functionality.
             o Vendor needs to keep pace with new technology components
                such as databases, operating systems, etc.
             o Vendor needs to maintain the system documentation when
                changes are being implemented.
             o Vendor or related partners can provide professional service.


      1.2.4 Configuration Management Plan
      In the early planning phase every IT plan all configuration items need to be
      identified and baselined. The configuration management plan will list all
      items which need to be put under change management control, version,
      etc. The baseline includes all aspects of change management of the
      system which include, people, processes and required documentation to
      maintain the configuration. Of particular interest is also the Interface
      Management which needs to establish clear acceptance criteria and
      agreements to maintain the interfaces of the system interacting with other
      systems and therefore other support team. The goal of this document is to
      establish full configuration status accountability to be able to track every
      change in the system over its lifespan across all components which require
      change control.
      In addition the document includes the various aspects of the configuration:
      - Libraries
      - Automation tools
      - Version Control
      - Media/Source Code/Patch/Fix management
      - Build Management in case the application can be compiled.
      - Documentation management defining who is responsible for what
          document


File: 06f17bfd-c843-4d6c-ab4b-ae8b453b2212.doc                             Page 12
                                                              NCDPI SDLC: Standard SDLC




      1.2.5 Risk Management Plan
      The Risk Management Plan (RMP) is tracking risks in a risk identification
      list which is a critical facet of successful system development
      management. The risk identification list is used from the beginning of the
      project and is a major source of input for the risk assessment activity.
      The project management plan and the risk identification list are inputs to
      the risk assessment. Categorize the risks as internal or external risks.
      Internal risks are those that you can control. External risks are events over
      which you have no direct control.
      The risk action plan addresses each identified risk and determines the
      agreed-upon action to mitigate or address the risk properly.

      1.2.6 System Security Plan
      To carry out its wide ranging responsibilities, the Department of Public
      Instruction (DPI), employees and managers have access to diverse and
      complex information technology (IT) systems which include mainframe
      central processing facilities, local and wide area networks running various
      platforms, and telecommunications systems to include communication
      equipment. The various business functions within the DPI depend on the
      confidentiality, integrity, and availability of these systems and their data.
      This document identified the system, the level of sensitivity, management
      controls to govern the access of the system from internal and external
      accounts as well as the operational and technical controls.


      1.2.7 Project Management Plan
      This should strictly follow the PMP methodology based on a break-down
      structure of tasks and activities, associated resources and their capacity,
      timely tracking of progress of tasks and issues resolution, etc.


      1.2.8 Concept of Operations
      The Concept of Operations (CONOPS) document is a high-level
      requirements document that provides a mechanism for users to describe
      their expectations of the system. The CONOPS is used as input to the
      development of formal testable system and software requirements
      specifications.
      The objective of the CONOPS is to capture the results of the conceptual
      analysis process. During this process, the characteristics of the proposed


File: 06f17bfd-c843-4d6c-ab4b-ae8b453b2212.doc                              Page 13
                                                              NCDPI SDLC: Standard SDLC


      system (from the user's perspective) and the operational environment in
      which it needs to function are identified. Both of these aspects, the
      system's functionality and its operational environment, are equally
      important.

      The CONOPS has the following characteristics:
       Describes the envisioned system
       Identifies the various classes of users
       Identifies the different modes of operation
       Clarifies vague and conflicting needs among users
       Prioritizes the desired and optional needs of the users
       Supports the decision-making process that determines whether a
          system should be developed
       Serves as the basis for the Functional Requirements Document (FRD)
      The outline of the CONOPS is shown at the end of this appendix. The
      following paragraphs list the specific instructions for the subsections of the
      outline.


      1.2.9 Validation and Verification Plan
      Software verification and validation (V&V) is an aid in determining that the
      software requirements are implemented correctly and completely and are
      traceable to system requirements. It helps to ensure that those system
      functions controlled by software are secure, reliable, and maintainable.
      Software V&V is conducted throughout the planning, development and
      maintenance of software systems.

      This plan helps to ensure that system functions controlled by software are
      secure, reliable, and maintainable. It uses a structured approach to analyze
      and test the software. It evaluates software against its requirements for
      quality attributes such as performance. Software V&V is conducted
      throughout the planning, development, and maintenance of software
      systems.
      The major objective of the software V&V process is to determine that the
      software performs its intended functions correctly, ensure that it performs
      no unintended functions, and provide information about its quality and
      reliability. Software V&V evaluates how well the software is meeting its
      technical requirements and its safety, security and reliability objectives
      relative to the system. It also helps to ensure that software requirements
      are not in conflict with any standards or requirements applicable to other
      system components.



File: 06f17bfd-c843-4d6c-ab4b-ae8b453b2212.doc                              Page 14
                                                               NCDPI SDLC: Standard SDLC


      During later phases of the life-cycle of the project, deliverables such as test
      plan, test results etc. are part of the overall project V&V documentation.


      1.2.10 System Engineering Management Plan
      The System Engineering Management Plan describes the system
      engineering process to be applied to the project and assigns specific
      organizational responsibilities for the technical effort, to include contracted
      or subcontracted technical tasks. This section also details or references
      technical processes and procedures to be applied to the effort. Where
      these processes or procedures are developed as part of the project, the
      need dates and development schedule should be shown.


      1.2.11 Procurement Plan
      A Project Procurement Plan is an indispensable component of the Project
      Plan. It is required when the decision to purchase Information Technology
      (IT) has been made by the Project Team (section 3.1). Agencies are
      expected to use procurement planning as an opportunity to evaluate/review
      the entire procurement process so that sound judgments and decision
      making will facilitate the success of the overall project. Statewide
      procurement will be evaluating IT Request for Proposals (RFP’s) for
      compliance to North Carolina Procedures. They will follow the criteria
      established by legislation and published on the “IT-procurement” web site
      (see section 1.1). The Project Procurement Plan described herein is
      designed to facilitate the procurement of IT products and services.
      Although this document addresses the guidelines for procuring IT goods
      and services for approved projects with a total cost of ownership of over
      $100k (through the use of an RFP / RFQ), Project Managers and their
      project teams should use this document as a guide to build a Procurement
      Plan that is tailored for any sized project and results in the best value for
      the state.




File: 06f17bfd-c843-4d6c-ab4b-ae8b453b2212.doc                               Page 15
                                                       NCDPI SDLC: Standard SDLC


      1.2.12 Deliverables (Summary)

      1.2.12.1 System Boundary Document

      1.2.12.2 Cost Benefit Analysis

      1.2.12.3 Risk Management Plan

      1.2.12.4 System Security Plan

      1.2.12.5 Project Management Plan

      1.2.12.6 Configuration Management Plan

      1.2.12.7 Concept of Operations

      1.2.12.8 Validation and Verification Plan

      1.2.12.9 System Engineering Management Plan

      1.2.12.10 Procurement Plan




1.3 Requirements Phase
      Main Objective: Translate the business requirements into System
      Requirements. This process uses modeling techniques to decompose the
      rather complex business requirements and translate them into more
      simplified and system related models and processes.

      1.3.1 Developing Use-Cases

      1.3.2 Developing Test criteria

      1.3.3 Interface Requirements




File: 06f17bfd-c843-4d6c-ab4b-ae8b453b2212.doc                       Page 16
                                                           NCDPI SDLC: Standard SDLC


      1.3.4 Deliverables (Summary)

      1.3.4.1 Functional Requirements Document

      1.3.4.2 Test and Evaluation Plan

      1.3.4.3 Interface Control Document




1.4 Design Phase

      1.4.1 Application Design
      1.4.2 Conversion-Migration-Transition Strategies
      1.4.3 Critical Design Review
      1.4.4 Deliverables

      1.4.4.1 System Design Document

      1.4.4.2 System Security Risk Assessment

      1.4.4.3 Implementation Plan

      1.4.4.4 Conversion Plan

      1.4.4.5 Interface Control Document

      1.4.4.6 System Administration Manual

       1.4.4.7 Maintenance Manual
      The Maintenance Manual provides maintenance personnel with the
      information necessary to maintain the system effectively. The manual
      provides the definition of the software support environment, the roles and
      responsibilities of maintenance personnel, and the regular activities
      essential to the support and maintenance of program modules, job
      streams, and database structures. In addition to the items identified for
      inclusion in the Maintenance Manual, additional information may be
      provided to facilitate the maintenance and modification of the system.
      Appendices to document various maintenance procedures, standards, or
      other essential information may be added to this document as needed.


File: 06f17bfd-c843-4d6c-ab4b-ae8b453b2212.doc                           Page 17
                                                   NCDPI SDLC: Standard SDLC


      1.4.4.8 User Manual

      1.4.4.9 User and Operators Training Plan




1.5 Development Phase
      1.5.1 Software installation or Coding
      1.5.2 Deliverables

      1.5.2.1 Software Development Plan

      1.5.2.2 System/Application Software

      1.5.2.3 Contingency Plan

      1.5.2.4 Test Files and Test Data

      1.5.2.5 Integration Configuration Document

      1.5.2.6 Software Transition Plan

      1.5.2.7 Software Installation Plan




File: 06f17bfd-c843-4d6c-ab4b-ae8b453b2212.doc                   Page 18
                                                          NCDPI SDLC: Standard SDLC


1.6 Integration and Test Phase
      1.6.1 Establish Test environment
      1.6.2 Functional/Unit Testing
      1.6.3 Functional System Testing
      1.6.4 Systems Integration Testing
      1.6.5 Systems Performance Testing
      1.6.6 User Acceptance Testing
      1.6.7 Establish Test environment
      1.6.8 Deliverables

      1.6.8.1 Test Analysis Document

      1.6.8.2 Test Problem Report

      1.6.8.3 System/Application Security Certification

      1.6.8.4 Integration Configuration Document

      1.6.8.5 User Acceptance Signoff

1.7 Deployment Phase
      1.7.1 Training plan execution
      1.7.2 System/Application Production Installation
      1.7.3 Installation Verification
      1.7.4 Deliverables

      1.7.4.1 Change Implementation Process

      1.7.4.2 Version Description Document

      1.7.4.3 Production Configuration Management Document

      1.7.4.4 Post-Deployment Review

      1.7.4.5 Software Vault Check-in and Confirmation




File: 06f17bfd-c843-4d6c-ab4b-ae8b453b2212.doc                          Page 19
                                                                     NCDPI SDLC: Standard SDLC


1.8 Operations/Maintenance Phase

      After the deployment and initial break-in phase of the system the
      operations and maintenance phase starts. This phase is primarily driven
      by:

              Patches and Fixes of the System on all system levels
              Day-to-day monitoring of the system – health-checks
              Audit and log file reviews
              Some forensic activities to determine instructions, cyber and internal
               system attacks
              Study of service desk measurements such as Priority one tickets
               and resolution time
              Larger maintenance activities such as end-of-year runs and data
               consolidation
              Research and analysis of hardware and software components as
               part of the evergreen process in technology
              Etc.

      There are key documents which support these activities which are created
      in previous phases of the system as part of the design, implementation,
      test and deployment. Such documents need to be reviewed and
      understood by operational personnel. The new documents created in this
      phase of the project are:
                 Document                            Purpose of the document
        Maintenance Manual:               Describes system maintenance procedures
                                          such as deploying fixes, monitoring log files
                                          etc.
        Operations Manual:                Day-to-Day batch runs, diagnostic procedures,
                                          error messages and problem resolution, etc.
        System Administration             Setup and configuration of the system,
        Manual:                           maintenance schedule, account management,
                                          system backup procedures, etc.




File: 06f17bfd-c843-4d6c-ab4b-ae8b453b2212.doc                                     Page 20
                                                                                      NCDPI SDLC: Standard SDLC



                                                 Operations and
                                                  Maintenance
                                                    Phase



                              Maintenance
                                Manual
                                                                  Operations Manual




                               System
                             Administration
                               Manual




      1.8.1 Identify Systems Operations
      1.8.2 Maintain Data/Software Administration
      1.8.3 Problem Identification and Escalation Process
      1.8.4 User Satisfaction
      1.8.5 Deliverables

       1.8.5.1 System Operations Manual
      The System Operations Manual provides computer control personnel and
      computer operators with a detailed operational description of the
      information system and its associated environments, such as machine
      room operations and procedures.


      1.8.5.2 User Satisfaction Review




File: 06f17bfd-c843-4d6c-ab4b-ae8b453b2212.doc                                                      Page 21
                                                          NCDPI SDLC: Standard SDLC


1.9 Deposition Phase
      1.9.1 Archive Data
      1.9.2 Archive Software
      1.9.3 Archive System Life-Cycle Documentation
      1.9.4 Disposition of Equipment
      1.9.5 Deliverables

      1.9.5.1 Archived Data, Files, Software, Documentation




File: 06f17bfd-c843-4d6c-ab4b-ae8b453b2212.doc                          Page 22
                                                                                                       NCDPI SDLC: Standard SDLC



2. Implementing of the System Life-Cycle
      The implementation of the System Life Cycle will take multiple years.
      For new projects the implementation of the SDLC can start beginning with
      the System Planning Phase and progress throughout every phase of the
      project. As the project progresses the document templates can be
      reviewed, revised to be fully applicable to the project.

      For existing project we have to consider another strategy: The associated
      risk of the system is less the non existence of a design document but more
      the issue that operations and maintenance does not have adequate
      documentation to work with. Therefore the better approach would be to
      start at the end of the standard life cycle and work towards the System
      Planning Phase. How far back the documentation should be generated
      needs to be decided on a case by case basis.

                                                        For new Projects

                                                                                                       Operations and
             System       Requirements                    Development   Integration and   Deployment                    Deposition
                                         Design Phase                                                   Maintenance
         Planning Phase      Phase                          Phase         Test Phase        Phase                        Phase
                                                                                                          Phase




                                                        For existing Projects




File: 06f17bfd-c843-4d6c-ab4b-ae8b453b2212.doc                                                                             Page 23
                                                                                                     NCDPI SDLC: Standard SDLC

3. Appendix

3.1 References to other documents/standards

               Standard                                                                  Reference Document
1. Java Coding Standards                         http://java.sun.com/docs/codeconv/ from April 20, 1999.
2. Statewide Technical Architecture              http://www.ncsta.gov/
3. Statewide Information Security                http://www.scio.state.nc.us/SITPoliciesAndStandards/Statewide_Information_Security_Manual.a
Manual
4. Security Standards and Policies               http://www.scio.state.nc.us/sitPolicies_List.asp?Other Security Standards and Policies
5. Old Policy to New Security Policy             http://www.scio.state.nc.us/documents/docs_Active/Statewide             Information     Se
crosswalk                                        Manual/crosswalk.pdf
6. Statewide IT Glossary                         http://www.scio.state.nc.us/documents/docs_Active/Statewide Information Security Manual/Glo
                                                 of Terms.pdf




File: 06f17bfd-c843-4d6c-ab4b-ae8b453b2212.doc                                Page 24
                                                           NCDPI SDLC: Standard SDLC



3.2 Document Templates




File: 06f17bfd-c843-4d6c-ab4b-ae8b453b2212.doc   Page 25

								
To top