1. SUITE Systems Engineering Methodology (SEM)
Detail Training Workshop

2. Today’s Topics SEM Overview SEM Components Monitoring and Tracking
SEM Stages (partitioning the project lifecycle)
SEM Templates (documenting product requirements, design, testing, and operational requirements)
SEM Process Guides (processes for ensuring quality and that approvals are obtained)
SEM Touch Points (interfacing with other parties at the appropriate times)
Monitoring and Tracking
Additional SEM Components

3. What’s not covered in detail today
Why we are doing this – process training
Training clients – each area has its own plan
Completing each template/form in detail
How to “do” the steps (e.g., how to “do” System Design).
Focus on best/MDIT practices will come later

4. Where the SEM fits in SUITE
SUITE will provide an integrated CMMI Level 3 compliant systems development framework that encompasses:
Project Management
Systems Engineering (SEM)
Process Management
Support Processes

5. Where Does SEM Fit In SUITE?
Project
Management
Systems Engineering
SUITE
Make a puzzle of
Project Management
Systems Engineering (SEM)
Process Management
Support Processes
Support
Processes
Process
Management

6. Purpose of SEM
The Systems Engineering Methodology (SEM) provides guidance for information systems development related activities and software quality assurance practices.
The primary purpose of the SEM is to promote the development of reliable, cost-effective, computer-based solutions while making efficient use of resources.

7. Touchpoints within SEM

8. Continual Improvement of SEM
SEM Version 1.0 (initial release) was published in March 2007.
SEM version 1.4 (current release) was published in February 2010.
It is expected that the SEM will improve and mature over the next several years.
It is the responsibility of each of us to identify improvement opportunities to the methodology

9. Where do I find info about SEM?
Michigan.gov/SUITE
TechTalk – SUITE Team Site
Your Manager/Project Manager
Your local SUITE Support Team (SST)
– Routed to right responder
SUITE Team Site on TechTalk
(Collaboration Portal  EMPO  SUITE)
Understanding Templates Paul
How to complete them (logistics)
How they look – Blue text and instructions
Common Areas
Cut and Paste similar areas
Why are some fields important?
Next Steps Paul
For more info contact your manager, your agency SUITE group then

10. Stages of the SEM Planning & Initiation Requirements Definition
Functional Design
System Design
Construction
Testing
Implementation
Definition of SEM Phases
Initiation and Planning - System owner/users' needs and expectations are identified, the feasibility of the project is determined, and the Project Plan is developed.
Requirements Analysis and Design - Functional and System Requirements for an IT product are defined and documented.
Construction - Product is created from the design specifications, testing is performed on the individual coded software units/components or on a combination of coded and purchased components.
Test - Period of time in lifecycle when system components are evaluated and integrated, and product is evaluated to determine whether or not the requirements have been satisfied.
Implementation - Install software, databases, or data that comprise the product onto the hardware platform at the site(s) of operation, verify product meets design requirements and obtaining system owner's acceptance and approval of product.
Closeout - Bring closure to the activities that have been carried out in the Construction, Test and Implementation Phases.
Maintenance & Operations - supporting a software product or system after delivery to maintain operational status, correct faults, improve performance or other attributes, or adapt to a changed environment.
Retirement - Permanent removal of a system or software product from its operational environment.

11. How SEM Documentation is Organized

12. Consistent Sections For Each Stage
Description
Inputs
High Level Activities
TouchPoints
Outputs
Review Process
References
Bibliography
Stage Specific Processes

13. Understanding SEM Templates
Templates - simple and flexible
Designed for cutting, pasting and
inserting
Helpful instructions in “blue text”
Easy to add rows/sections
OK to mark some areas N/A
Important Tip – Don’t Delete the MDIT
“clippy” - includes helpful tools

14. Consistent Sections For Each Stage
Description
Inputs
High Level Activities
TouchPoints
Outputs
Review Process
References
Bibliography
Stage Specific Processes

15. New Concepts Touchpoints Process Guides Security Procurement eMichigan
Infrastructure Services
Enterprise Architecture, Solutions Engineering & Telecom
Business Continuity Planning
Process Guides
Structured Walkthrough
Testing
Stage Exit
Measurement and Analysis
System Maintenance
Process & Product Quality Assurance

16. Features of the Overview Chart
Simplest way to understand SEM
One-Stop Shopping
Detail and Big Picture Views on One Page
Hot Links to stages, templates and process guides
Highlight stages
Show “consistent sections” within each stage
“Outputs” include revised as well as final documents
Templates (blank and sample)
Process Guides
Structured Walkthrough
Stage Exits (Deliverables)

17. Detailed walkthrough of the handout
Important points include
Interrelationships
Up front reviews save time
Client involvement/sign offs
Structured walkthroughs
Telecom, AE, Security and Procurement involvement

18. Initiation and Planning Stage Description:
First lifecycle stage
Project Management Methodology (PMM) and SEM are tightly integrated.
Most outputs are PMM documents - Participation of the business client is critical !
Business Case
Project Charter
Project Plan
Quality Management Plan.
Two SEM documents are started
Software Configuration Management Plan
Maintenance Plan 
This is the first stage in the lifecycle of an information systems engineering project. Project Management Methodology (PMM) and System Engineering Methodology are tightly integrated. It is imperative that the project manager ensures participation of the business client in the creation of the PMM documents.
The majority of the outputs produced during this stage are Project Management Methodology (PMM) documents, such as the Business Case, the Project Charter, the Project Plan and the Quality Management Plan. The SEM Software Configuration Management Plan and the Maintenance Plan are initiated during this stage.
This stage involves development of a Software Configuration Management Plan (SEM) to track and control work products and a Quality Management Plan (PMM) to assure the production and operation of high quality products on schedule, within budget, and within the constraints specified by the system owner and user.

19. Initiation and Planning Stage Inputs:
Requirements identified in project related materials, (e.g., a business case)
Related project initiation materials

20. Initiation and Planning Stage High Level Activities:
3.1 Develop Software Configuration Management Plan
3.2 Develop Maintenance Plan

21. Initiation and Planning Stage Touchpoints:
Contracts and Procurement
Assignment of a Contract Liaison if procuring goods or services
Completion on DIT-0153 Bid Information Sheet if procuring goods or services
Enterprise Architecture (EA)
Review relevant EA materials (e.g., roadmaps, solution patterns)
Develop EA Solution Assessment for each alternative (refer to Appendix C for assistance in developing the EA Solution Assessment.
Security
Notify your Security Liaison of project initiation
Review MDIT and Agency Security Policies
Initiate Security Plan & Assessment, including Data Classification and System Criticality sections
Other
Initiate Business Continuity Planning process (DMB has a website for this purpose.)

22. Initiation and Planning Stage Outputs:
SEM Templates:
Software Configuration Management Plan (initial)
Maintenance Plan (initial)
PMM Templates:
Business Case
Concept Document (i.e., Feasibility Study)
Project Charter
Project Plan (includes Quality Management Plan)
Security Plan & Assessment (initial)
Other Outputs:
Enterprise Architecture (EA) Solution Assessment for each potential solution option (initial)
Business Continuity Plan (initial)

23. Requirements Definition Stage Description:
Develop mutual understanding between business owner/users and project team about the requirements for the project.
Analyze business needs and translate into formal requirements.
Approved Requirements Specification = initial baseline for product design
Approved Requirements Specification = reference for determining whether the completed product performs as the system owner requested and expected.
All system requirements, (e.g., software, hardware, performance, functional, infrastructure, etc.) should be included.
Plan testing activities to validate product performance.
The primary goal of this stage is to develop a basis of mutual understanding between the business owner/users and the project team about the requirements for the project. The result of this understanding is an approved Requirements Specification that becomes the initial baseline for product design and a reference for determining whether the completed product performs as the system owner requested and expected. All system requirements, (e.g., software, hardware, performance, functional, infrastructure, etc.) should be included.
This stage involves analysis of the business owner/users' business processes and needs, translation of those processes and needs into formal requirements, and planning the testing activities to validate the performance of the product.

24. Requirements Definition Stage Inputs:
SEM Templates:
Software Configuration Management Plan
Maintenance Plan
PMM Templates:
Business Case
Concept Document (i.e., Feasibility Study)
Project Charter (Statement of business objectives)
Project Plan (includes Quality Management Plan)
Security Plan & Assessment
Other Inputs:
Enterprise Architecture (EA) Solution Assessment for each potential solution option

25. Requirements Definition Stage High Level Activities:
4.1 Requirements Management
4.2 Select Requirements Analysis Technique
4.3 Define System Requirements
4.4 Compile/Document System Requirements
4.5 Develop System Test Requirements
4.6 Develop Acceptance Test Requirements
4.7 Establish Functional Baseline

26. Requirements Definition Stage Touchpoints:
Contracts and Procurement
Completion of DIT-0015a, if procuring commodities (e.g., servers, software)
Completion of DIT-0015b (including Statement of Work and Requirements Traceability Matrix), if procuring services (e.g., project management, application developers)
Utilize the services of the assigned Contract Liaison, if procuring services
Enterprise Architecture (EA)
Use relevant EA materials (e.g., roadmaps, solution patterns) while developing Technical Requirements
Revise/complete EA Solution Assessment for each alternative
Refer to the EA TechTalk portal site
Infrastructure Services
When EA Solution is complete and approved, prepare Infrastructure Services Request (ISR), and begin Hosting Solution document
Security
Review MDIT and Agency security policies
Review State and Federal laws and regulations
Begin Infrastructure/Network and Data Flow Diagram

27. Requirements Definition Stage Outputs:
SEM Templates:
Requirements Specification (initial)
Requirements Traceability Matrix (initial)
Maintenance Plan (revised)
Software Configuration Management Plan (revised)
PMM Templates:
Project Plan (revised)
Security Plan & Assessment (revised)
Other Outputs:
Application Hosting document (initial)
Business Continuity Plan (revised)
EA Solution Assessment (final)
Infrastructure Services Request (final)

28. Functional Design Stage Description:
Maps the "what to do" of the Requirements Specification into the "how to do it" of the design specifications.
Define product structure from a functional viewpoint.
Describe logical system flow, data organization, system inputs and outputs, processing rules, and operational characteristics of the product from the user's point of view.
Define and document product functions to obtain system owner and users understanding and approval.
Define and document product functions to the level of detail necessary to build the system design.  .
The functional design process maps the "what to do" of the Requirements Specification into the "how to do it" of the design specifications. During this stage, the overall structure of the product is defined from a functional viewpoint. The functional design describes the logical system flow, data organization, system inputs and outputs, processing rules, and operational characteristics of the product from the user's point of view. The functional design is not concerned with the software or hardware that will support the operation of the product or the physical organization of the data or the programs that will accept the input data, execute the processing rules, and produce the required output.
The focus is on the functions and structure of the components that comprise the product. The goal of this stage is to define and document the functions of the product to the extent necessary to obtain the system owner and users understanding and approval and to the level of detail necessary to build the system design.
Prototyping of system functions can be helpful in communicating the design specifications to the system owner and users. Prototypes can be used to simulate one function, a module, or the entire product. Prototyping is also useful in the transition from the functional design to the system design.

29. Functional Design Stage Inputs:
SEM Templates:
Maintenance Plan
Requirements Specification
Requirements Traceability Matrix
Software Configuration Management Plan
PMM Templates:
Project Plan
Quality Management Plan
Security Plan & Assessment
Other Inputs:
Business Continuity Plan
MDIT Hosting Solution Document

30. Functional Design Stage High Level Activities:
5.1 Determine System Structure
5.2 Design Content of System Inputs and Outputs
5.3 Design User Interface
5.4 Design System Interfaces
5.5 Design System Security Controls
5.6 Build Logical Model
5.7 Build Data Model
5.8 Develop Functional Design
5.9 Select System Architecture

31. Functional Design Stage Touchpoints:
Contracts and Procurement
Contract liaison involvement in the process, if contract issues arise
Infrastructure Services
Review and complete Hosting Solution document
Security
Review MDIT and Agency security policies
Review State and Federal laws and regulations
Review existing or propose new security controls
Conduct preliminary risk analysis
Revise Infrastructure/Network and Data Flow Diagram

32. Functional Design Stage Outputs:
SEM Templates:
Functional Design Document (final)
Maintenance Plan (revised)
Requirements Specification (final)
Requirements Traceability Matrix (revised)
Software Configuration Management Plan (revised)
PMM Templates:
Project Plan (revised)
Security Plan & Assessment (revised)
Other Outputs:
Business Continuity Plan (revised)
Data Dictionary (final)
MDIT Hosting Solution Document (final)

33. System Design Stage Description:
Translate the user-oriented Functional Design into a set of technical, computer-oriented system design specifications.
Design the data structure and processes to the level of detail necessary to plan and execute the Construction and Implementation Stages.
Produce general module specifications that define what each module is to do, but not how the module is to be coded.
Provide a blueprint for the coding of individual modules and programs.
The goal of this stage is to translate the user-oriented functional design specifications into a set of technical, computer-oriented system design specifications; and to design the data structure and processes to the level of detail necessary to plan and execute the Construction and Implementation Stages. General module specifications should be produced to define what each module is to do, but not how the module is to be coded. Effort focuses on specifying individual routines and data structures while holding constant the structure and interfaces developed in the previous stage. Each module and data structure is considered individually during detailed design with emphasis placed on the description of internal and procedural details. The primary work product of this stage is a system design that provides a blueprint for the coding of individual modules and programs.

34. System Design Stage Inputs:
SEM Templates:
Functional Design document
Maintenance Plan
Requirements Specification
Requirements Traceability Matrix
Software Configuration Management Plan
PMM Templates:
Project Plan
Quality Management Plan
Security Plan & Assessment
Other Inputs:
Data Dictionary

35. System Design Stage High Level Activities:
6.1 Design Specifications for Modules
6.2 Design Physical Model and Database Structure
6.3 Develop Integration Test Considerations
6.4 Develop System Test Considerations
6.5 Develop Conversion Plan
6.6 Develop System Design
6.7 Develop Program Specifications

36. System Design Stage Touchpoints:
Contracts and Procurement
Contract Liaison involvement if contract issues arise
Enterprise Architecture (EA)
Request exceptions as required
Complete EA Solution Assessment for the chosen solution and submit to EA for review/approval
Infrastructure Services
Technical and Data Center Services Solutions Engineer involvement in completion of Hosting Solution document
Infrastructure Specialist involvement in establishing the construction environment
Security
Review MDIT and Agency Security Policies
Review State and Federal Laws and Regulations
Revise Network Diagram and Data Flow Diagrams
Review Final Risk Analysis with OES recommended security controls

37. System Design Stage Outputs:
SEM Templates:
Conversion Plan (initial)
Maintenance Plan (revised)
Requirements Traceability Matrix (revised)
Software Configuration Management Plan (final)
System Design Document (final)
Test Plan (initial)
Test Reports (initial)
PMM Templates:
Project Plan (revised)
Security Plan & Assessment (revised)

38. Construction Stage Description:
Translate System Design into a language the computer can understand and execute.
Construction involves coding, validation and unit testing by a developer.
Install hardware or software procured to support the construction effort.
Develop plans for installation of the operating environment hardware and software.
Design a training program and create a Training Plan.
Produce operating documentation for installing, operating, and supporting the product through its lifecycle.

39. Construction Stage Inputs:
SEM Templates:
Conversion Plan
Functional Design Document
Maintenance Plan
Requirements Specification
Requirements Traceability Matrix
System Design Document
Test Plan
Test Reports
PMM Templates:
Project Plan
Quality Management Plan
Security Plan & Assessment
Other Inputs:
Data Dictionary

40. Construction Stage High Level Activities:
7.1 Establish Development Environment
7.2 Develop Programs
7.3 Conduct Unit Testing
7.4 Establish Development Baselines
7.5 Plan Transition to Operational Status
7.6 Generate Operating Documentation
7.7 Develop Training Plan
7.8 Develop Installation Plan

41. Construction Stage Touchpoints:
Contracts and Procurement
Contract Liaison involvement if contract issues arise
Infrastructure Services
Infrastructure Specialist involvement in establishing hosting environments
Security
Finalize Network and Data Flow diagrams

42. Construction Stage Outputs:
SEM Templates:
Conversion Plan (revised)
Installation Plan (initial)
Maintenance Plan (revised)
Requirements Traceability Matrix (revised)
Test Plan (final)
Test Approach and Reports (revised)
Training Plan (initial)
Transition Plan (initial)
PMM Templates:
Project Plan (revised)
Security Plan & Assessment (revised)
Other Outputs:
Development baselines
Operating Documentation
Users Manual
Developer's Reference Manual
Project Test File
System units and modules

43. Testing Stage Description:
Testing activities focus on interfaces between and among components of the product, such as functional correctness, system stability, overall system operability, system security, privacy and sensitive information control, and system performance requirements.
Integrate components and conduct Integration Testing to determine whether the product meets predetermined functionality, performance, quality, interface, and security requirements.
Once the product is fully integrated, conduct System Testing to validate that the product will operate in its intended environment, satisfies all user requirements, and is supported with complete and accurate operating documentation.
After successful System Testing, conduct User Acceptance Testing (UAT) to identify any final product adjustments before implementation.
Testing activities focus on interfaces between and among components of the product, such as functional correctness, system stability, overall system operability, system security, privacy and sensitive information control, and system performance requirements (e.g., reliability, maintainability, and availability). Testing performed incrementally provides feedback on quality, errors, and design weaknesses early in the integration process.
In this stage, components are integrated and tested to determine whether the product meets predetermined functionality, performance, quality, interface, and security requirements. Once the product is fully integrated, system testing is conducted to validate that the product will operate in its intended environment, satisfies all user requirements, and is supported with complete and accurate operating documentation. User Acceptance Testing (UAT) follows System Testing, and solicits feedback from users to make any final adjustments to the programming before releasing the product for implementation.

44. Testing Stage Inputs: SEM Templates: PMM Templates: Other Inputs:
Conversion Plan
Installation Plan
Maintenance Plan
Requirements Specification
Requirements Traceability Matrix
Test Plan
Integration testing (component to component)
Performance testing (load, stress, etc.)
System testing (end to end)
User acceptance testing (UAT)
Test Reports
Integration test reports
Performance test report
System test reports
User Acceptance test reports
Transition Plan
Training Plan
PMM Templates:
Project Plan
Quality Management Plan
Security Plan & Assessment
Other Inputs:
Development Baselines
Operating Documentation
Users Manual
Developer's Reference Manual
Project Test File
Software Modules

45. Testing Stage High Level Activities:
8.1 Conduct Integration Testing
8.2 Conduct System Testing
8.3 Conduct User Acceptance Testing

46. Testing Stage Touchpoints:
Contracts and Procurement
Contract Liaison involvement if contract issues arise
Infrastructure Services
Infrastructure Specialist involvement as documented in the Infrastructure Services Request (ISR)
Security
Include application testing for security controls

47. Testing Stage Outputs:
SEM Templates:
Conversion Plan (revised, if needed)
Installation Plan (final)
Maintenance Plan (revised)
Requirements Traceability Matrix (final)
Test Approach and Reports (final)
Integration test reports
Performance test report
System test reports
User Acceptance test reports
Training Plan (final)
Transition Plan (revised)
PMM Templates:
Project Plan (revised)
Security Plan & Assessment (revised)
Other Outputs:
Operating Documents (final)
Users Manual
Developer's Reference Manual

48. Implementation Stage Description:
Implementation of the product is initiated after all application testing has been successfully completed.
This stage involves the activities required to install the software, databases, or data that comprise the product onto the hardware platform at the site(s) of operation.
User training may be required to complete the implementation process. A description of the training necessary for developers, testers, users, and operations staff is provided in the Training Plan.
implementation of the product is initiated after all application testing has been successfully completed. This stage involves the activities required to install the software, databases, or data that comprise the product onto the hardware platform at the site(s) of operation. The activities associated with this stage should be performed each time the product is installed at a production site.
User training may be required to complete the implementation process. A description of the training necessary for developers, testers, users, and operations staff is provided in the Training Plan

49. Implementation Stage Inputs:
SEM Templates:
Conversion Plan
Installation Plan
Maintenance Plan
Training Plan
Transition Plan
PMM Templates:
Project Plan
Quality Management Plan
Security Plan & Assessment
Other Inputs:
Operating Documents
Users Manual
Developer's Reference Manual

50. Implementation Stage High Level Activities:
9.1 Perform Installation Activities
9.2 Conduct Installation Tests
9.3 Transition to Operational Status

51. Implementation Stage Touchpoints:
None!

52. Implementation Stage Outputs:
SEM Templates:
Conversion Plan (final)
Maintenance Plan (final)
Transition Plan (final)
PMM Templates:
Project Plan (final)
Post Implementation Evaluation Report (PIER) (final)
Security Plan & Assessment (final)
Other Outputs:
Converted data or system files
Installation Test materials
Operating documents
Operational software product

53. Detailed walkthrough of the handout
Important points include
Interrelationships
Up front reviews save time
Client involvement/sign offs
Structured walkthroughs
Telecom, AE, Security and Procurement involvement

54. Template Exercise/Break
Review the blank template and completed sample for “Software Configuration Management Plan”
In small groups
Discuss how the form should be completed
Captain (person w/lightest shirt) to report out on:
How did it feel to use the new process?
How is it the same or different from the process you follow today or have used in the past?
What do you need to make it a success?
What are the differences between the client and MDIT roles?
Complete the assignment and take a break w/in 25 minutes.

55. Detailed walkthrough of the handout
Important points include
Interrelationships
Up front reviews save time
Client involvement/sign offs
Structured walkthroughs
Telecom, AE, Security and Procurement involvement

56. Process Guides SEM Structured Walkthrough Process Guide
Defect Tracking Log (DIT-0186)
Structured Walkthrough Meeting Record (DIT-0187)
SEM Stage Exit Process Guide
Stage Exit Approvals (DIT-0189)
Measurement and Analysis Process Manual
Project Metrics Collection (DIT-0188)
Systems Maintenance Guidebook
System Maintenance Document (SEM-0931)

57. Why are we doing this? Consistent, standard, repeatable processes
Collection of best practices
Identify defects before they get to production
Decrease cost
Increase productivity and quality
Improve communication
Improve on-time and on-budget delivery our clients
Avoid late engagement from stakeholders

58. SEM Processes
Structured Walkthrough Process Guide A guide to assist the project team with a formal process on how to ensure a deliverable is complete and of acceptable quality. A Structured Walkthrough is required for every major project deliverable. Stage Exit Process Guide A guide to assist the project team on how to transition from one SEM stage to the next. Required before moving to the next stage (e.g., Requirements Definition to Functional Design).

59. Structured Walkthrough Process
A structured walkthrough is an organized procedure for a group of peers to review and discuss the technical aspects of software development work products.
“The number of errors in production systems decreases by as much as 90% in organizations that use walkthroughs diligently.”

60. Structured Walkthrough Process
Major Objectives
Find errors & omissions as early as possible
Improve the quality of the product
Templates
Defect Tracking Log (DIT-0186)
Structured Walkthrough Meeting Record (DIT-0187)

61. Structured Walkthrough Roles
Author
Presenter
Moderator
Reviewers
Scribe
The Author of the work product is responsible for requesting the walkthrough when a meaningful portion of the product has been developed and is free from casual errors (e.g., spelling errors). The author attends the walkthrough as an observer and answers reviewer's general questions. The author is not a reviewer.
The Presenter usually develops the agenda for the walkthrough and presents the work product being reviewed. The presenter should be familiar with the work product and be a member of the project team.
The Moderator facilitates the walkthrough session, ensures that the walkthrough agenda is followed, and encourages the participation of all reviewers. The moderator may also be the scribe.
The Reviewers evaluate the work product to determine if it is technically accurate. The reviewers also assess whether the project guidelines or standards are being followed, the project requirements are met, and the product is properly prepared.
The Scribe takes notes during the walkthrough. The scribe records the errors identified and any other technical comments, suggestions, and unresolved questions. The scribe should not be a reviewer.

62. When is a Structured Walkthrough (SWT) Required?
On all major stage exit deliverables
(see SWT Process Guide page 18+)
Initiation and Planning Stage:
Project Plan
Security Plan & Assessment
Software Configuration Management Plan
Maintenance Plan, if needed
Requirements Definition Stage:
Requirements Specification Document
Requirements Traceability Matrix
Etc…

63. Stage Exit Process Major Objectives Template
Obtains approval by designated individuals to continue with the project and move forward into the next stage of development.
Indicates that all documents related to that stage have been approved and that there are no outstanding issues.
Template
Stage Exit Approvals (DIT-0189)

64. Stage Exit Documentation

65. Stage Exit Participants
Systems Engineering Team
System Owner/Sponsors)
Client point of contact (POC)
Software Quality Assurance (SQA)
Enterprise Architecture (EA)
Office of Enterprise Security (OES)
Infrastructure Services (IS)
Others, as appropriate

66. What Do I Need to Actually Do
Follow the overview documents
Complete the Templates for the Stage
Complete the Structured Walkthrough
Obtain “Sign-Offs” on all templates
Complete the Stage Exit when all areas sign off
Use SEM Process for Continuous Improvement

67. Monitoring and Tracking
Monthly reporting on SEM implementation
Validation that Stage Exit documents are complete
Validation that Stage Exit documents conform to the Software Configuration Management Plan
SUITE Core Team and Sponsors review reports and feedback on SEM usage

68. Metrics Collection Process
Major Objective
Capture, report, and use data to constantly improve SUITE processes
Template
Project Metrics Collection (DIT-0188)

69. Systems Maintenance Process
Major Objectives
Provide consistent and reliable documentation for small changes (up to 200 hours)
Achieve efficiencies by “bundling” maintenance requests into regularly scheduled releases
Template
System Maintenance Document (SEM-0931)

70. Detailed walkthrough of the handout
Important points include
Interrelationships
Up front reviews save time
Client involvement/sign offs
Structured walkthroughs
Telecom, AE, Security and Procurement involvement

71. QUESTIONS?