software engineering institute capability maturity model (cmm)

Software Engineering InstituteCapability Maturity Model (CMM)

Capability Maturity Model (CMM)Implementation

• CMM Review

• Key Process Areas Key Practices

• Company Software Development Lifecycle/CMM Process Flow

• Lifecycle/CMM Process Documentation

• Requirements

• Design/Project Planning

• Coding/Documentation

• Build/Test/Release

Why Implement CMM?

To ensure that software projects are:

• Completed on time (meet schedule),

• Within budget,

• Built to quality standard,

• Maintainable, and

• Meet customer requirements

What Is CMM?• Use project management, process and quality

improvement methods for software development and maintenance.

• Five progressions, multiple Key Process Areas each level.

• Level 2 Key Process Areas:

• Requirements Management

• Software Quality Assurance

• Software Configuration Management

• Project Planning

• Project Tracking and Oversight

• Key Practices define if the process is being followed.

Level 2 Key Practice Focus for Key Process Areas

Management-endorsed policies reflect KPA requirements.

Project resource needs and commitments are met.

Project management / lifecycle processes are defined.

Processes are documented, practiced, and enforced.

Project metrics are collected and tracked.

New projects use experience of prior projects.

All aspects of project are inspected.

Requirements Management

• Agreement with customer

• Define software specifications, technical and nontechnical

• Resolve issues before incorporation into software project

· Ensure acceptance criteria is testable

· Provide basis for estimating, planning, performing, and tracking software project's activities throughout life cycle.

· Adjust software plans, work products, and activities to remain consistent with updated requirements.

Owned by Product ManagerOwned by Product Manager

Software Quality Assurance

Owned by Quality SystemsOwned by Quality Systems

• Provide visibility on product quality, project processes

• Review, inspect project products to verify compliance with procedures, standards

• Assess if project management activities follow CMM processes

• Provide managers with reviews, inspections, assessment results

• Assist in developing quality, software configuration management plans

• Assist in establishing software and project management standards, procedures

Software Configuration Management

• Establish, maintain product integrity throughout software life cycle

• Identify software configuration items (customer software products and items identified with or required to create software products)

• Control changes to configuration

• Maintain integrity and traceability of configuration

• Establish software baseline library and control builds/releases

• Utilize change control and configuration audit functions

Owned by Quality SystemsOwned by Quality Systems

Project Tracking and Oversight

• Provide visibility on project progress

• Enable management to act on significant deviation from plan

• Compare software size, effort, cost, schedule against estimates

• Review commitments with management at selected milestones

• Negotiate change with affected groups

• Correct problems through revising plan or improving performance

(Looking at MS Project web-based timekeeping system)

Owned by Product Manager, Development Manager, or Project ManagerOwned by Product Manager, Development Manager, or Project Manager

Project Planning

• Plan for developing software and managing project

• Develop statement of work–scope, standards, risks, constraints

• Identify work products

• Develop estimates–software, documentation size, effort, critical computer resources

• Plan project's software engineering facilities and support tools

• Establish commitments

• Define schedule

Owned by Product Manager, Development Manager, or Project ManagerOwned by Product Manager, Development Manager, or Project Manager

MS PROJECTSchedule Templates

Company Software Development Life Cycle and CMM

INCEPTION

WORD TemplatesMRD

Business CaseQuality Plan

SCM PlanChecklistsProcedures

Customer IssuesService Requests

Legend: Black--Required Red--Optional but recommended Blue--Prepared/Completed concurrently Page 1

Marketing ConceptManagement ConceptCustomer Requirement

FEASIBILITY

Business Case or MRD High Level Scope High Level Content High Level Outline

Solution Target Size/CostMS Project Schedule

Stage End Summary Report

REQUIREMENTS MANAGEMENT

Use Cases (optional, projects < one month)Requirements

Risk Management PlanQuality Plan (amend)SCM Plan (amend, CIs)Test Cases

MS Project Plan (update/status)Test Plan (initiate)Change Control Board

Level 2 Stage Status Report(Tracking & Oversight)

Stage End Summary ReportProcess Assessment

Requirements SoftwareTemplatesUse Cases

RequirementsRisk Management Plan

Issues Log

DefectManagement

SoftwareDefects

ConfigurationManagement

SoftwareStage/Project Work

Products

Marketing Product Manager Product/ProjectManager

QS/ChangeControl Board

DevelopmentManager

Product/ProjectManager

INSPECTIONS/

CHECKLISTS

CUSTOMER

APPROVAL

DEVELOPMENT

APPROVAL

DESIGN

Created xx/xx/20xx Revised xx/xx/20xx Version 1.0 Page 1

Architectural Design using Requirements Use CasesLogical DesignPhysical DesignDatabase ModelPrototypesDesign ReviewUsability Testing/Review

PROJECT PLANNING

Software Development PlanWorkBreakdown StructureEstimate: Software Size Documentation Size Critical Computer Resources Effort (resource planning)Test Plan (update)Test Cases (update)MS Project Plan (update/status)SCM Plan (update software CIs)Risk Management Plan (update)



RequirementsManagement

SoftwareTemplatesUse Cases


Issues Log

DefectsManagement

SoftwareDefects

DevelopmentManager

Concurrent


DevelopmentManager

WORDChecklistsProcedures


DevelopmentManager

EXCEL TemplatesWBS

Estimating

DefectsManagement

SoftwareDefects



Products



Products

WORD TemplatesSoftware

Development PlanTest Plan

ChecklistsProcedures

INSPECT IONS/

CHECKLISTS

INSPECT IONS/

CHECKLISTS

CUSTOMER

APPROVAL

TEAM

R&D

MGT

APPROVAL

CODING/DOCUMENTATION

Source Code Control (CIs)Design UpdatesApplication Run Book (start)Unit TestCode Review

Documentation:Technical Review of Document HelpSubject Matter ReviewTechnical InputHelp Application Integration

Review/Update Software Development Plan Estimate:

Software Size Documentation Size Critical Computer Resources Effort (resource planning)

SCM Plan Risk Management Plan Quality PlanTest Plan (finalize)Test Cases (finalize)MS Project Plan (update/status)SCM Status Accounting Report/Audit



RequirementsManagement Software

TemplatesUse Cases


Issues Log

DefectManagement

SoftwareDefects

DevelopmentManager

QS/Change Control Board,Development Manager



DevelopmentManager

DefectManagement

SoftwareDefects



Products



Products



Products

System Tests/ReTest for Fixes MATs FATs CRUD GATs (selected applications) RegressionApplication Run BookBuild certified for releaseDeployment to Acceptance Test


Stage End Summary ReportProject Post MortemProcess Assessment

BUILD/TEST/RELEASE

AutomatedTests


INSPECT IONS/

CHECKLISTS

INSPECT IONS/

CHECKLISTS

Requirements Stage• High Level MRD (Marketing Requirements Doc) or Business Case

• Start MS Project Schedule to capture effort

• Create Use Cases

• Develop Requirements from Use Cases

• Perform Risk Assessment / Create Risk Management Plan (Constraints, Assumptions)

• Amend Quality Plan, SCM Plan for new project

• Create Test Cases to validate/inspect Requirements

• Start Test Plan

• Create Change Control Board

• Complete Stage End Reports, Assessments

• High Level MRD (Marketing Requirements Doc) or Business Case

• Start MS Project Schedule to capture effort

• Create Use Cases

• Develop Requirements from Use Cases

• Perform Risk Assessment / Create Risk Management Plan (Constraints, Assumptions)

• Amend Quality Plan, SCM Plan for new project

• Create Test Cases to validate/inspect Requirements

• Start Test Plan

• Create Change Control Board


DOORS Requirements Management Template Layout

See remaining attribute columns on page 7. Print and tape together to see all columns.

ID Functional Requirements Use Case Number SR Number Requirement Type Source

1

1. Document History

Note: Changes to Requirements have to be reported on a periodic basis to senior management. Requirements and changes to requirements are maintained in Requirements Management software system.

3

2. Introduction

5

2.1. Document Purpose

The purpose of these requirements specifications is to define the user requirements for the [project Name]

6

2.2. Document Scope -

This document shall be used in the next phase of the Company Project Life Cycle to create the software development plan and design and testing requirements and documentation.

This Document will not contain design or testing documentation.

7

2.3. Restrictions -

No development or design shall be performed using this document without approval from the stakeholders and QS.

8

3. Overview

Requirements Template in DOORS/Checklist in WordRequirements Template in DOORS/Checklist in Word

COMPANY NAME Requirements Review Checklist

Product/Project/Development Managers: Use the Product Management portion of this Checklist to develop and internally review the Requirements. Ensure the last item in the checklist is confirmed during the User review and approval step. Boxes can only be checked if the answer is “Yes.” Requirements are not ready for inspection by QS until all boxes have been checked. Use page 4 for detailed information on how to write requirements.

Quality Systems: Use the Quality System portion of this Checklist to inspect the Requirements. The inspection can be divided among inspectors.

Product Management

General

Composition—Have all entries been spell- and grammar-checked?

Impact Internal—Does the Impact section identify all internal business areas, systems, data storage, clients, workflow and training systems affected by the proposed system or enhancement?

Impact External—Does the Impact section identify all external business areas, systems, data storage, clients, workflow and training systems affected by the proposed system or enhancement?

External Interfaces—Are all external hardware, software, and communication interfaces defined?

Impact Other Projects—Does the Impact Other Projects section identify all project and system areas where there may be duplication, diverted resources, etc.?

Performance—Have all reliability and performance objectives been listed?

Security—Have all security considerations relative to the company’s internal and external security standards been listed. (Check security document dates against configuration management records to ensure the most recent standards are used in the review.)

Operational—Have sufficient requirements been defined, such as hardware capacity, availability, platform, firewalls, operations, etc., indicating how the hardware is expected to work with and support the system so that critical computer resource needs can be estimated?

International— Have issues relative to using the system in other countries been raised and adequately addressed?

Manageable—Are the requirements specifications expressed in such a way that each item can be changed without excessive impact on other items.

Customer Needs—Is the requirements document complete, i.e., does it implement all of the known customer needs?

Correct—Has each attribute in the Requirements Specification been verified by the customer?

C:\SOFTWARE DEV\Checklists\Requirements Cklst.doc Creation Date: 07/23/20xx Version: 1.4 Page 1 Revision Date: 11/21/20xx

Software Quality Assurance Procedure in WordSoftware Quality Assurance Procedure in Word

SOFTWARE QUALITY ASSURANCE PROCEDURE

1. Introduction

1.1. Purpose

This procedure details the software development project Quality Assurance activities required to ensure a quality product is delivered to the customer.

1.2. Objectives

1. To detail when and how the Quality Plan is developed and used.

2. To describe how Quality System (QS) reviews are performed, and how corrective actions are logged and tracked to resolution.

3. To list the steps in the escalation process, used when defects to a process or work product cannot be resolved between the QS representative and project team members.

4. To explain the performance of a process assessment and how the information is used to ensure compliance with CMM requirements and process improvement.

1.3. Definitions

Development Manager: Responsible for the design, code development, testing, and defect correction of new and existing systems prior to deployment to production. May also be responsible for use cases and/or requirements.

Product Manager: Responsible for interface with internal and external customers relative to the development of use cases and requirements for new systems, for changes to systems under development, or for enhancements to systems in production. Responsible for managing the overall product direction, scope, and market timing of product releases.

Project Manager: Responsible for ensuring the project plan is developed according to written procedures. Organizes, tracks, updates, and communicates the status of a project. Maintains the balance between scope, schedule, and resources. Manages issues and their timely resolution. Advises the appropriate senior management on potential deviations in scope, schedule, and resources, and elevates unresolved issues to ensure the appropriate action plans are developed to alleviate problems. Negotiates commitment changes with affected parties and reports the results to senior management. Ensures negotiated action plans are implemented and project plans are adjusted accordingly.

Quality Manager: Responsible for ensuring that software developed and produced in the R&D organization meets the stated release criteria and development standards. Responsible for ensuring that appropriate levels of review and inspection, including testing, are accomplished for each deliverable in the software development lifecycle and that deviations are corrected as required.

C:\SOFTWARE DEV\SoftQualAssur\SQA Proc.doc Creation Date: 07/23/20xx Version: 1.4 Page 2 Revision Date: 11/21/20xx

SOFTWARE QUALITY ASSURANCE PROCEDURE

2. Procedure Description

2.1. Overview

When Quality planning and implementation of quality activities for a project includes: initial development of a Quality Plan for a system,

then amending that plan for each project related to that system,

reviewing/inspecting all project work products from requirements to system retirement,

logging defects and tracking these defects to resolution,

auditing project activities to ensure that all CMM processes are followed (Process Quality Assessment).

Quality activities also include reviewing project engineering activities, attending stage end meetings to ensure criteria for ending a stage and beginning the next stage have been met, and developing and maintaining the project’s quality metrics.

Trigger Amending the Quality Plan is begun as Use Cases are being developed. Inspections start with Use Cases.

Who The QS Manager is responsible for ensuring that all activities identified in this procedure are implemented. The QS Representative is responsible for performing these QA activities. The Product, Development, or Project Manager is responsible for reviewing QS evaluations and defect reports, taking corrective action, and resolving non-compliance issues.

Inputs Doc control #

Software Quality Assurance Policy Requirements Specifications Requirements Checklist Risk Management Plan Risk Management Plan Checklist Software Development Standards (see Project

Workbook)

Software Development Checklists (see Project Workbook)

Software Configuration Management Standards (see SCM Plan)

C:\SOFTWARE DEV\SoftQualAssur\SQA Proc.doc Creation Date: 07/23/20xx

Quality Plan Template and Checklist in WordQuality Plan Template and Checklist in Word

COMPANY NAME Quality Plan Checklist

Quality Systems: Use this Checklist to inspect the Quality Plan. Check any item that is a “Yes” or “N/A” answer. An item that is not checked is a defect. Once spelling or grammar errors are discovered, the first question does not need to be asked for remaining entries. Log the defects in the Defect Management software system. On the Defect Management software system Process tab, select Quality Plan. Note the defect in the Quality Plan document as a margin note where the defect occurred. After the inspection, return the document to the Product Manager.

Checklist

Composition—Has the Plan been spell-checked and grammar-checked?

Risks—Are the risks in the Risks to Quality, Section 4, specific to quality?

Acceptance Criteria—Are the locations of Use Cases and Requirements, Section 5.1, properly identified?

Service Goals—Have the Quality Service Goals for the customer been correctly identified in Section 5.2?

Tools—Have the quality tools been correctly identified in Section 6?

Work Products—Has the Project Exceptions Table in Section 8 been completed (or N/A entered) for the project?

Work Products—If the Project Exceptions Table in Section 8 has been completed and is not N/A, was it completed following the guidelines in Section 8?

Defect Rates—Have the expected defect detection rates been entered in Section 9?

Defect Rates—Based on your experience, are the defect detection rates in Section 9 reasonable?

Test Strategy—Has section 12 been duplicated for the project and completed correctly?

Training—Have training needs been defined in Section 13?

Comprehensive—Is the quality plan complete, correct, and unambiguous?

C:\SOFTWARE DEV\SoftQualAssur\Quality Plan Cklst.doc Creation Date: 07/23/20xx Version: 1.2 Page 2 Revision Date: 11/21/20xx

$ SYSTEM NAME $ Quality Plan

Table of Contents

REVISION HISTORY (TEMPLATE) ................................................................................ ii

REVISION HISTORY (QUALITY PLAN) ......................................................................... 1

1. THE QUALITY PLAN ............................................................................................. 4

2. QUALITY AGREEMENT ........................................................................................ 4

3. AMENDING THE QUALITY PLAN ......................................................................... 4

4. RISKS TO QUALITY .............................................................................................. 4

5. CUSTOMER REPRESENTATIVE .......................................................................... 5

5.1. Acceptance Criteria (from Use Cases and Requirements) ........................................ 5

5.2. Service Goals ............................................................................................................... 5

6. QUALITY TOOLS ................................................................................................... 5

7. QUALITY STANDARDS AND CHECKLISTS ........................................................ 5

8. QUALITY CONTROL OF MAJOR DELIVERABLES/WORK PRODUCTS ............ 6

8.1. Project Lifecycle Table ................................................................................................ 6

8.2. Production Support Lifecycle Table ........................................................................... 7

9. EXPECTED DEFECT DETECTION RATES .......................................................... 7

10. QUALITY CONTROL OF APPLICATION DEVELOPMENT PROCESS ................ 8

11. QUALITY INDICATORS ......................................................................................... 8

12. TEST STRATEGY .................................................................................................. 8

12.1. $ Project Name $ ....................................................................................................... 8

13. QUALITY TRAINING .............................................................................................. 9

14. QUALITY MILESTONES ........................................................................................ 9

15. REVIEWS ............................................................................................................. 10

16. CUSTOMER REPRESENTATIVE TABLE ........................................................... 11

APPENDIX A ................................................................................................................. 12

SQA Escalation Form .......................................................................................................... 12

Escalation Steps ................................................................................................................. 14

C:\SOFTWARE DEV\SoftQualAssur\Quality Plan Template.doc Creation Date: 07/23/20xx Version: 1.8 Page 1 Revision Date: 11/21/20xx

Software Configuration Management Plan in WordSoftware Configuration Management Plan in Word

$PROJECT or SYSTEM NAME$ SCM Plan

2.2 Configuration Identification & Control

2.2.1 Identify SCM Libraries

Completed by Product or Development Manager.

Duplicate the next line for each project or system.

The data for $ Project or System Name $ will be stored on $ ServerName $.

The directory structure in Appendix A identifies the library (Configuration Management software system VOB) and directory structure that will be allocated and used by our project or production effort. Additional directories, if any, are listed in the following table:

In the table below, identify additional directories, if any, and the reasons for them. Delete the example.

Project or System Name

Directory Name Library Identifier (VOB)

$ Project or System Name $

$ Directory Path: $ $ server\PROJ_SYSNAME\SOURCE $

The retention information is addressed in section 2.1.1, items #2 and #3.

Reference SCM Procedure, Identify SCM Libraries, Section 3.2.2.1.

2.2.2 Configuration Item Identification & Control

Completed by Product or Development Manager.

The directory structure in Appendix A identifies Configuration Item categories and Configuration Items. CI Category Descriptions are in Appendix B. All documents within each category will be under version control. Additional CI categories, if any, are identified in the table below.

Version/retention information is addressed in section 2.1.1, items #2 and #3.

New versions of CI’s are loaded to the CI library directories described in Appendix A. The version number convention our project or production effort follows is determined by Configuration Management software system rules.

Reference SCM Procedure, Configuration Item Identification and Control, section 3.2.2.2.

In the following table below, identify additional Configuration Item categories, the configuration items in each category, and the library (VOB) where they will be stored. Delete the examples.

Project or System Name

Configuration Item Categories

Configuration Items (Examples)

CI Library


$ IDE Items $ $ Item Name $ $ server\PROJ_SYSNAME\ DOCUMENTS $


$ Development Environment $

$ Item Name $ $ server\PROJ_SYSNAME\ SOURCE $

C:\SOFTWARE DEV\Software Config Mgt\SCM Plan Template.doc Creation Date: 07/23/20xx Version: 1.9 Page 7 Revision Date: 11/21/20xx

$PROJECT or SYSTEM NAME$ SCM Plan

Table of Contents

REVISION HISTORY (TEMPLATE) ....................................................................................................... ii

REVISION HISTORY (PLAN) ................................................................................................................ 1

TABLE OF CONTENTS ......................................................................................................................... 2

1. INTRODUCTION .......................................................................................................................... 4

1.1. DEFINITIONS ............................................................................................................................... 4

2. SCM ACTIVITIES ......................................................................................................................... 5

2.1. CONFIGURATION ADMINISTRATION ............................................................................................... 5

2.1.1. Project or Production Specific SCM Standards ................................................................... 5

2.1.2. SCM Plan Maintenance ...................................................................................................... 6

2.1.3. SCM Closure ...................................................................................................................... 6

2.2. CONFIGURATION IDENTIFICATION & CONTROL ............................................................................... 7

2.2.1. Identify SCM Libraries ......................................................................................................... 7

2.2.2. Configuration Item Identification & Control .......................................................................... 7

2.2.3. Configuration Item Naming Conventions............................................................................. 8

2.2.4. External Configuration Item Identification ........................................................................... 9

2.2.5. Baseline and Release Identification and Control ................................................................. 9

2.2.6. Change Request Tracking ................................................................................................ 10

2.2.7. System Dependencies ...................................................................................................... 10

2.3. CONFIGURATION STATUS ACCOUNTING ...................................................................................... 10

2.4. SCM AUDITS ............................................................................................................................ 11

2.5. CONFIGURATION RELEASE ......................................................................................................... 11

3. SCM PLAN IMPLEMENTATION ................................................................................................ 11

3.1. SCM DELIVERABLES ................................................................................................................. 11

3.2. SCM TOOLS ............................................................................................................................. 12

3.3. SCM PROJECT OR PRODUCTION SCHEDULE ............................................................................... 12

3.4. SCM EFFECTIVENESS AND EFFICIENCY METRICS ........................................................................ 12

4. REVIEWS ................................................................................................................................... 13

5. CUSTOMER REPRESENTATIVE TABLE ................................................................................. 13

APPENDIX A: CMM PROJECT STRUCTURE FOR SOURCE CONTROL ....................................... 14

APPENDIX B: CI CATEGORY DESCRIPTIONS ................................................................................ 16

C:\SOFTWARE DEV\Software Config Mgt\SCM Plan Template.doc Creation Date: 07/23/20xx Version: 1.9 Page 1 Revision Date: 11/21/20xx

Status Meeting Template in WordStatus Meeting Template in Word

COMPANY NAME Status Meeting Agenda/Minutes

Next Meeting: $Date, Time, Next Meeting Location (city, bldg., room, Telephone and/or Conference Call #)$

Minutes are to be distributed within three days after team meeting. An agenda is due one day prior to the next meeting. Participants/Recipients:

For the agenda, complete the list of invitees/participants/recipients. Below the list, indicate who will lead the meeting and who will take minutes. When preparing minutes, asterisk the names of those in attendance and update the meeting leader list with names of persons actually fulfilling the roles.

Participants $Name of Participant$ $Name of Participant$ $Name of Participant$ Cc: $Name of cc Recipient$

(* - denotes in attendance) Leader: $Name of Participant$ leads and controls the meeting, following the agenda; Minutes: $Name of Participant$ records and distributes minutes; produces next agenda;

The following agenda structure is mandatory in order to address the requirements of each of the Key Process Areas in the CMM. Time allocations can be deleted if not used. Time allotments, if kept, may also be renegotiated and adjusted

$time allotted$ Agenda Walkthrough:

This topic is used to ensure that all attendees understand the items to be addressed. Walk-on agenda items are included as New Business. Clarifications or corrections to the minutes from the previous meeting are made.

$time allotted$ New Business: This is for new discussion items added to the Agenda.

$time allotted$ Review Open Issues:

Issue $#$: $Detail the Issue$ $Assignee$

Assignees, or Meeting Leader if “team” assignee, addresses the status of each issue. If more than one project is addressed in the Status Meeting, individual project issues should be entered in Project/Production Tracking and Oversight: under each project’s section. When preparing minutes, enter the disposition for resolved issues under the issue description.

$time allotted$ Review Open Action Items: Assignees address status of each open action item. Minutes are entered in the Action column. Update changed Date Due by striking out the old date and entering a new date below the strikeout. Change the Status as needed. Sort by Date Due and Status. The Item # is the Numbered List function. Delete the page break following this paragraph.

C:\SOFTWARE DEV\Project Tracking\Status Meeting Template.doc Creation Date: 07/23/20xx Version: 1.0 Page 2 Revision Date: 11/21/20xx

COMPANY NAME Status Meeting Agenda/Minutes

Item # Action: Assigned to Date Due Status 1. $Detail the action$ $Assignee$ $Date Due$ $New, In

Progress, Closed$

$time allotted$ Risk Management Action Plan:

The Risk Management Action Plan is reviewed in the meeting on a periodic basis to determine if it is being followed and whether it needs to be modified. If it is determined that the Plan requires a change, it is noted here and transferred to the Plan. If no changes are required since the last review, it is noted here as ‘No change’. If the changes are serious, actions must be escalated to senior management. If more than one project is addressed at the Status Meeting, rotate review of the Risk Plans. For the meetings where it is discussed, include the Risk Management Action Plan in Status Meeting Attachments and include it as a file in the e-mail.

$time allotted$ Requirements Management:

Status of changes to project requirements since the last report is reviewed. SRs (Service Requests) are changes based on service requests or new requests such as enhancements. PRs (Problem Reports) are changes based on defects with existing requirements. Activities include:

Date requirements requests/problem reports totals were compiled. Number of requests for new, or changes to, requirements or problem reports made to the scope

during this period. Number of requests for new or changes to requirements or problem reports removed (cancelled,

closed) during this period, classified by reason for removal. Number and status of the current active requirements or problem reports.

The tables below can be replaced with reports from Requirements Management software system if the same information is conveyed.

Date Added Removed Active SR Status

Rejected/Cancelled

Closed

Unassigned

Impact Assessment

Awaiting Approval

Approved (future work)

In Progress

Total Active

Date Added Removed Active PR Status Rejected/

Cancelled

Closed

Unassigned Impact

Assessment Awaiting Approval

Approved (future work)

In Progress

Total Active

For the meetings at which this is reported, note the full report on New and Removed SRs and PRs in Status Meeting Attachments and include it as a file in the e-mail.

C:\SOFTWARE DEV\Project Tracking\Status Meeting Template.doc Creation Date: 07/23/20xx Version: 1.0 Page 3 Revision Date: 11/21/20xx

Design/Project Planning StageConcurrently,

• Create Architectural, Logical, Physical Design, Data Models

• Develop Software Development Plan

• Prepare Work Breakdown Structure for Modules

• Estimate Size, Effort, Cost, Critical Computer Resources

• Update Test Plan and Test Cases

• Update MS Project Plan with WBS tasks

• Update SCM Plan with Software Configuration Items

• Update Risk Management Plan with Development Risks

• Design Review


Concurrently,

• Create Architectural, Logical, Physical Design, Data Models

• Develop Software Development Plan

• Prepare Work Breakdown Structure for Modules

• Estimate Size, Effort, Cost, Critical Computer Resources

• Update Test Plan and Test Cases

• Update MS Project Plan with WBS tasks

• Update SCM Plan with Software Configuration Items

• Update Risk Management Plan with Development Risks

• Design Review


Work Breakdown Structure (WBS) in Excel

Software Development Plan Template in Word

COMPANY NAME

[Project Name] Software Development Plan

Revision History of this SDP Note that all response boxes will expand as needed. Document Version:

Creation Date:

Creator Name : Phone #:

1.0

Document Version

Revision Date

Name and Phone # of Reviser

Revision Description

1.1

SECTION 1 – Project Purpose, Scope, and Objectives: (Describe the high-level functions addressed by the project (purpose), what is included and what is excluded in the development plan (scope), and expected short and long-term technical results (objectives).

SECTION 2 – Software Life Cycle (Identify the life cycle type that will be used for this project and any phases that will be added or deleted.)

SECTION 3 – Procedures, Methods, and Standards for Developing and/or Maintaining the Software (Identify the CMM support documents that are required for this project and any non-CMM procedures, methods and standards that will be used for developing the software. See the Software Development Plan Procedure, Input, for other document names. The following are examples.)

Software Development Plan Procedure Estimating Template Software Configuration Management Procedure Software Quality Assurance Procedure Documentation Specifications Template

SECTION 4 – Software Work Products to be Developed (Identify the work products that must be developed, e.g., process-related documentation, software design, software code units, test procedures, support tools, etc. These are the deliverables that will be managed throughout the project life cycle. Indicate who is responsible for managing each group of deliverables.) Work Product

Type (End User, Customer, Other Development Groups, Internal Use by Software Development Team)

Responsible Manager

C:\SOFTWARE DEV\Project Planning\SDP.dot Creation Date: 07/23/20xx Version: 1.0 Page 2 Revision Date: 11/21/20xx

MS Project Plan Template in MS Project

Coding/Documentation Stage

• Code

• Update Designs as needed

• Start Application Run Book

• Unit Tests

• Code Reviews

• Code

• Update Designs as needed

• Start Application Run Book

• Unit Tests

• Code Reviews

• Documentation Reviews

• Review Document Help

• Review Subject Matter

• Receive Technical Input

• Integrate Help into Application

• Documentation Reviews

• Review Document Help

• Review Subject Matter

• Receive Technical Input

• Integrate Help into Application

• Review/Update/Status

• Software Development Plan Estimates

• SCM Plan Quality Plan

• Risk Management Plan MS Project Plan

• Finalize Test Plan and Test Cases


• Review/Update/Status

• Software Development Plan Estimates

• SCM Plan Quality Plan

• Risk Management Plan MS Project Plan

• Finalize Test Plan and Test Cases


Application Run Book in Word

[Application Name] Run Book

TABLE OF CONTENTS

Revision History (Template) ............................................................................................................. 2

Revision History (Run Book) ............................................................................................................ 2

1. System Overview ................................................................................................................... 5

1.1 Application Overview.................................................................................................... 5

1.1.1 Main function ................................................................................................. 5

1.1.2 Purpose ......................................................................................................... 5

1.1.3 Project acronym ............................................................................................. 5

1.2 Business Flowchart ...................................................................................................... 5

1.3 Technical Flowchart ..................................................................................................... 5

1.4 Systems Availability ..................................................................................................... 5

1.5 Client Community ......................................................................................................... 5

1.6 Application/DataBase Error Messages ......................................................................... 6

1.7 Batch Requirements .................................................................................................... 7

1.8 Escalation and Notifications Flowchart ......................................................................... 7

2. Contact Information .............................................................................................................. 8

3. Hardware & Operating System Configuration ................................................................... 10

3.1 Hardware Configuration ............................................................................................. 10

3.2 Operating System & Support Software Loaded on System ........................................ 10

3.3 Application Security Procedures ................................................................................ 10

4. Application Installation Procedure ..................................................................................... 11

5. Upgrade/Patch Installation Procedures ............................................................................. 11

6. Network Configuration ........................................................................................................ 11

6.1 IP Address (Hard Server IP addresses) ..................................................................... 11

6.2 MODEM / Dial Up Numbers ....................................................................................... 12

6.3 Network Configuration ................................................................................................ 12

7. Load Balancer Configuration .............................................................................................. 12

7.1 Load Balance ............................................................................................................. 12

7.2 Off-line/Restored ........................................................................................................ 12

7.3 Network settings ........................................................................................................ 12

7.4 Persistence ................................................................................................................ 12

7.5 SSL (Secure Socket Layer) ........................................................................................ 13

8. Application Performance Settings ..................................................................................... 13

8.1 Web Server Settings .................................................................................................. 13

8.2 Application Server Settings ........................................................................................ 13

8.3 Database Server Settings .......................................................................................... 13 C:\SOFTWARE DEV\Software Config Mgt\Run Book Temp.doc Creation Date: 07/23/20xx Version: 1.3 Page 3 Revision Date: 11/21/20xx

[Application Name] Run Book

The Run Book is designed to contain sufficient information for IT to implement and support new systems or enhancements efficiently. Completion of the Run Book is the responsibility of the Development Manager or designee in collaboration with Marketing and IT Network Engineering Group. The Run Book should be started at the Design Stage and be completed prior to deployment.

The Run Book must be reviewed and approved by the system’s Development Manager in Production prior to release to IT. The Development Manager in Production will be responsible for reviewing and updating this document at every major enhancement or, at a minimum, every three months.

Instructions are in blue italicized text. Delete the blue text, change the color to Automatic and remove italics as each section is completed. Delete all red text instructions before distributing the document.

1. System Overview

1.1 Application Overview

1.1.1 Main function

Describe the main function of the system covered by this project.

1.1.2 Purpose

Describe the purpose of the system from both the client and the company’s perspective.

1.1.3 Project acronym

List the project’s acronym(s) and the modules to which they apply.

1.2 Business Flowchart

Create a flowchart to graph the flow of data, showing where the data comes from (input) and the ultimate use of the data (output). Identify all output reports and other uses of output. Identify all users of these reports or other output.

1.3 Technical Flowchart

Create a flowchart that mirrors the Business Flowchart but for each data element, show the physical equipment and location of that equipment. This flowchart should address the physical layout of servers, hardware process, and the technical relationship of the systems.

1.4 Systems Availability

Consult with Marketing for this information.

1.4.1 Required online availability

Define the online hours of availability that will be required to service the clients.

1.4.2 Exceptions to required online availability

Define any exceptions to the online hour requirements such as outage windows, scheduled maintenance, etc.

1.5 Client Community

Consult with Marketing for this information.

1.5.1 Client name(s) and location

Complete the table by listing the names of the clients by organization name and their addresses.

Name Address City State Zip

C:\SOFTWARE DEV\Software Config Mgt\Run Book Temp.doc Creation Date: 07/23/20xx Version: 1.3 Page 5 Revision Date: 11/21/20xx

Unit Test Specifications in Word

Specifications - Unit Testing Checklist

1. Select the test activities that apply to your development/coding situation.

2. Perform the tests in the order indicated.

3. Ensure that your code passes all tests satisfactorily before checking your code back into the version control system. Note that checking the code in and notifying the development manager that the code is complete means it will be in the next build.

4. Do not delete these instructions

STEP ACTION

1 If a Program Change: Full compile

1. To flesh out "hidden" compile errors.

2 If a Field Change:

1. Verify all actions that reference that field work correctly

2. Notify other developers responsible for system modules affected by this field

3 If Visual Basic: Passes VB_Code_Chk

1. Run at this point and run again as needed to check source code changes that occur as the result of later steps. The executable is at \\serverprod\servermod\RBN\Tools\VB_Code_Chk.exe

4 Validate all Queries on the Page or Form: Refer to Requirements, Enhancement Request, or Defect Report for validation criteria

1. Add a record

2. Add a record and cancel

3. Change a record

4. Change a record and cancel

5. Run an inquiry for a record

6. Delete a record

7. Delete a record and cancel

5 Boundary testing on controls

Note: for VB, in order of decreasing complexity, control types (generally) are: grd, tre, mov, lst, cbo, msk, txt, opt, chk. Those not mentioned should still be checked when they appear.

5a Character Fields

1. Try to enter more characters than allowed by the database field.

2. Ensure correct error handling when more characters are entered than allowed.

C:\SOFTWARE DEV\SoftQualAssur\Unit Test Cklst.doc Creation Date: 07/23/20xx Version: 1.3 Page 2 Revision Date: 11/21/20xx

Documentation Estimates in Excel

Technical Publications Development Time EstimatesIndustry standards for estimating documentation schedules apply.

Estimates will vary depending upon the writer’s experience with the product and the complexity of the information. New pages = 4 – 6 hours per page Change pages = 2 – 4 hours per page Online Help = 5 – 8 hours per topic

1. Additional factors in estimating:

{PROJECT NAME} (project being estimated)Make entries in Pages per Topics and Hours per Topic only

Topics

Pages per Topic

Hours per Page Hours Days

User's Guide 0 0Installation Guide 0 0

2. Beta Help Development EstimatesThe following table shows the estimated time required to develop/write the 1st draft of the Beta Help.Example: 50 topics at 5 hours per topic = 250 hours divide by 7 hours per day = 35.7 days round up to 36 days {PROJECT NAME} (project being estimated)

Make entries in New Topics and Hours per Topic only

New Topics

Hours per Topic Hours Days New Topics

Hours per Topic Hours Days

50 5 250 36 days 0 0

a. For a User’s Guide, factor 1 page for every three menu items. This will include new functions at the user b. For installation, assume that a new port or product update requires a change to every page of the

Note: In the time estimate tables below, one working day is equal to 7 hours of actual writing time. One hour per

Build/Test/Release Stage

• Authorize Builds

• System Tests (MATs, FATs, CRUD, GATs-selected apps)

• Document, Track, Resolve Defects

• Retest (Regression)

• Certify Build for Release

• Complete Application Run Book

• Deploy Release to Acceptance Test


• Complete Project Post-Mortem

• Authorize Builds

• System Tests (MATs, FATs, CRUD, GATs-selected apps)

• Document, Track, Resolve Defects

• Retest (Regression)

• Certify Build for Release

• Complete Application Run Book

• Deploy Release to Acceptance Test


• Complete Project Post-Mortem

Change and Release Management Procedure in Word

COMPANY NAME

CHANGE AND RELEASE MANAGEMENT PROCEDURE – PRODUCTION TABLE OF CONTENTS

Revision History ................................................................................................................................. i 1. Introduction ........................................................................................................................... 1

1.1. Purpose ....................................................................................................................... 1 1.2. Objectives .................................................................................................................... 1 1.3. Definitions .................................................................................................................... 1

2. Procedure Description .......................................................................................................... 2 2.1. Overview ...................................................................................................................... 2 2.2. Flow Chart ................................................................................................................... 3

3. Procedure Steps .................................................................................................................... 4 3.1. Service Requests ......................................................................................................... 4

3.1.1. Development (Changes to Requirements) ..................................................... 4 3.1.2. Production ..................................................................................................... 5 3.1.3. Production Quote Process ............................................................................. 5

3.2. Defect (Problem) Reports ............................................................................................ 7 3.2.1. Change Control (Quality) Board. .................................................................... 7 3.2.2. Developer Defect Activity ............................................................................... 7

3.3. Build activities .............................................................................................................. 7 3.3.1. Scheduled Build............................................................................................. 7 3.3.2. Build Notes .................................................................................................... 8 3.3.3. Emergency build ............................................................................................ 9 3.3.4. Dual Release Systems (Release 1.0, Release 1.1): .................................... 10

3.4. Test Activities ............................................................................................................. 11 3.4.1. Scheduled Release ..................................................................................... 11

3.5. Deployment ................................................................................................................ 11 3.5.1. Successful/Unsuccessful Acceptance Test .................................................. 11 3.5.2. Notification ................................................................................................... 11 3.5.3. Release Directory ........................................................................................ 12 3.5.4. Emergency Release .................................................................................... 12

Appendix A, Example: Build Notes ............................................................................................... 13 Appendix B – Updating Dual Releases (Release 1.0, Release 1.1, etc.) ...................................... 15

C:\SOFTWARE DEV\Software Config Mgt\Change and Rel Mgt Procedure.doc Creation Date: 07/23/20xx

Version: 1.1 Page ii Revision Date: 11/21/20xx

CHANGE AND RELEASE MANAGEMENT PROCEDURE – PRODUCTION 3. Procedure Steps

3.1 Service Requests (Note: Requirements Procedure references this section)

3.1.1 Development (Changes to Requirements)

Once Requirements have been approved, any change requests must be on a Service Request (SR1.0) form and/or entered in Customer Complaint software system. The SRs are sent to the project’s Product Manager.

3.1.1.1 Prioritization. All Critical / High Priority requests must include a high level sizing to enable prioritization. All other requests are presented for prioritization without sizing. SR’s are categorized as:

High Priority: The change is needed to retain or attract a specific client, it greatly reduces a company expense, or it impacts all clients and the potential workaround is costly.

Medium Priority: The change impacts multiple clients or reduces a company expense.

Low Priority: The change impacts limited clients AND there is a potentially inexpensive workaround OR it has a minimal expense reduction for the company.

3.1.1.2 Review. The Product Manager prioritizes and distributes the request to the Development or Project Manager, QS, and other stakeholders who were at the original Requirements Reviews. The recipients evaluate the request as to the affect the change will have on schedule and/or costs and as to the need and/or ability to make the change in this version of the system or a future version. Responses can be via e-mail or at a meeting, at the Product Manager’s discretion.

3.1.1.3 Agreement. If agreement to make the change in this version will affect schedule and/or change other commitments, the change must be negotiated with the affected parties and conveyed to senior management for their approval before contacting the requestor. If the change will not affect commitments, agreement to the change can be directly conveyed to the requestor.

3.1.1.4 The Product Manager is responsible for entering the change into the Requirements Management software system and updating the Customer Complaint software system report. The Development or Project Manager is responsible for making any required revisions to the Software Development Plan and the MS Project Plan resulting from this decision.

3.1.1.5 Escalation Process

All escalations MUST go through the Product Manager.

If a SR is already open, generate a new activity in the Customer Complaint software system, update the escalation field to yes, update comments, assign to PM and leave voice message and email for the Product Manager.

The Product Manager will have two working days to prioritize and distribute the escalated request to affected parties and five

C:\SOFTWARE DEV\Software Config Mgt\Change and Rel Mgt Procedure.doc Creation Date: 07/23/20xx

Version: 1.1 Page 4 Revision Date: 11/21/20xx

Build/Release Notes in Word

Build/Release Notes

SECTION 1. CHANGES INCLUDED

Changes included in Build 3.50:

3625 1 Product App Errors 6/10/20xx

3623 2 ProcessID is not saved in the tran_mast table for rolling back a process 6/10/20xx

3615 2 Inactivating a company in the company profile not working 6/09/20xx

3612 2 Interest re-calculation is incorrect on ARM 3/7 loans 6/09/20xx

3609 2 Payoff Notice incorrect amount 6/08/20xx

3601 3 Incorrect messages added to error log when processing new loans . 6/08/20xx 3578 2 Screen frozen when caps-lock is on 6/08/20xx

3562 2 Fax from the Print Dialog does not work 6/08/20xx

3541 2 Apostrophes in company names translate to code at print-out 6/08/20xx

3530 2 Primary Key violation generating calendars 6/05/20xx

3425 2 Need to be able to add a Loan Change Event in the pending mode 6/05/20xx

3407 2 Interest reset box error 6/04/20xx

Unknown changes in CoName.dll that were needed to compile (see Build Problems below)

SECTION 2. FORMS UNDER CONSTRUCTION

The following forms are under construction in Build 3.50:

NONE. All forms are now out from under construction.

SECTION 3. NEW FILES

Checkfonts.prn – This file is necessary for notice printing, and should have been included in the past, but was not until now.

CoImpVal.dll -

SECTION 4. PROBLEMS ENCOUNTERED

Date Build Module Problem Solution

The Next Steps

Training in Procedures, Templates and Checklists for all Development Staff Hands On Training for Users Relative to Risk and Requirements Processes

Apply Level 2 Processes to Pilot Projects: Minor Enhancement Pilot

Major Enhancement Pilot Major Product Upgrade Pilot or New Product Pilot

Level 2 Assessment

Begin Preparations for Level 3

Training in Procedures, Templates and Checklists for all Development Staff Hands On Training for Users Relative to Risk and Requirements Processes

Apply Level 2 Processes to Pilot Projects: Minor Enhancement Pilot

Major Enhancement Pilot Major Product Upgrade Pilot or New Product Pilot

Level 2 Assessment

Begin Preparations for Level 3

software engineering institute capability maturity model (cmm)

Documents

software size

software plans

project products

software specifications

project manager slide

project management activities

project management standards

project progress