Detail Training PowerPoint Slide Deck

  • 1,038 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,038
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
19
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Make a puzzle of Project Management Systems Engineering (SEM) Process Management Support Processes
  • 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
  • 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.
  • 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
  • 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
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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
  • 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.
  • 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
  • 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

Transcript

  • 1. SUITE SEM Implementation Detail Training Workshop
  • 2. Today’s Topics
    • SEM / SEM Express Overview
    • SEM Components
      • 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 own plan
    • Completing each template/form in detail
    • How to “do” the steps e.g. how to “do” System Design. SEM formalizes/documents current approaches.
    • 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?
      • Systems Engineering
    SUITE
      • Project Management
      • Support Processes
      • Process Management
  • 6. SEM Overview
  • 7. 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.
  • 8. SEM Express
    • SEM Express offers guidance for small and straight-forward systems development projects. The intent of SEM Express is to provide an abbreviated methodology that ensures all necessary processes are performed and documented.
    • In general, the definition of “straight-forward” includes projects that:
    • Continue to operate in the existing infrastructure environment and do not involve procurement of additional infrastructure components;
    • Utilize existing resources and do not procure services (except when contractors are utilized as part of a multi-project initiative);
    • Are developed for a single agency;
    • Can be implemented without formal user training;
    • Have little to no risk associated with them; and
    • Have a low degree of exposure
  • 9. Touchpoints within SEM
  • 10. Continual Improvement of SEM
    • SEM Version 1.0 is the initial release of MDITs Systems Engineering Methodology (formerly referred to as the Systems Development Life Cycle or SDLC).
    • It is expected that the SEM will improve and mature over the next several years, with much of that improvement expected in the next 6-12 months.
    • It is the responsibility of each of us to identify improvement opportunities to the methodology
  • 11. Who Can I Contact About SEM?
    • Michigan.gov/SUITE
    • Your Manager/Project Manager
    • Local IO Core team and SEM Champion(s)
    • [email_address] – Routed to right responder
    • SEM Change Form MDIT 0181
    www.michigan.gov /suite SUITE Team Room on TechTalk (Projects –> MDIT –> SUITE)
  • 12. Stages of the SEM
    • SEM
    • Initiation and Planning
    • Requirements Definition
    • Functional Design
    • Systems Design
    • Construction
    • Testing
    • Implementation
    • SEM Express
    • Initiation, Requirements and Design
    • Construction and Testing
    • Implementation
  • 13. How SEM Documentation is Organized
  • 14. Consistent Sections For Each Stage
    • Description
    • Inputs
    • High Level Activities
    • TouchPoints
    • Outputs
    • Review Process
    • References
    • Bibliography
    • Stage Specific Processes
  • 15. Consistent Sections For Each Stage
    • Description
    • Inputs
    • High Level Activities
    • TouchPoints
    • Outputs
    • Review Process
    • References
    • Bibliography
    • Stage Specific Processes
  • 16. 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
  • 17. Consistent Sections For Each Stage
    • Description
    • Inputs
    • High Level Activities
    • TouchPoints
    • Outputs
    • Review Process
    • References
    • Bibliography
    • Stage Specific Processes
  • 18. New Concepts
    • Touchpoints
      • Security
      • Procurement
      • Infrastructure Services
        • Enterprise Architecture, Solutions Engineering & Telecom
      • Business Continuity Planning
    • Process Guides
      • Structured Walkthrough
      • Stage Exit
  • 19. 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 Walk Though
      • Stage Exits (Deliverables)
        • Available at www.michigan.gov/suite --> SEM
  • 20. SEM and SEM Express
  • 21.  
  • 22.  
  • 23. 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 
    •  
  • 24. Stages of the SEM
    • SEM
    • Initiation and Planning
    • Requirements Definition
    • Functional Design
    • Systems Design
    • Construction
    • Testing
    • Implementation
    • SEM Express
    • Initiation, Requirements and Design
    • Construction and Testing
    • Implementation
  • 25. Initiation and Planning Stage Inputs:
    • Requirements identified in project related materials, (e.g., a business case)
    • Related project initiation materials
  • 26. Initiation and Planning Stage High Level Activities:
    • 3.1 Develop Software Configuration Management Plan
    • 3.2 Develop Maintenance Plan
  • 27. 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, including Data Classification and System Criticality sections
    • Other
      • Initiate Business Continuity Planning process (DMB has a website for this purpose.)
  • 28. 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)
    • Other Outputs:
      • Security Plan ( initial )
      • Enterprise Architecture (EA) Solution Assessment for each potential solution option ( initial )
      • Business Continuity Plan ( initial )
  • 29. 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.
  • 30. 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)
    • Other Inputs:
      • Security Plan
      • Enterprise Architecture (EA) Solution Assessment for each potential solution option
  • 31. 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
  • 32. 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
  • 33. Requirements Definition Stage Outputs:
    • SEM Templates:
      • Requirements Specification (initial)
      • Requirements Management Checklist
      • Requirements Traceability Matrix (initial)
      • Maintenance Plan (revised)
      • Software Configuration Management Plan (revised)
    • PMM Templates:
      • Project Plan (revised)
    • Other Outputs:
      • Security Plan (revised)
      • Application Hosting document (initial)
      • Business Continuity Plan (revised)
      • EA Solution Assessment (final)
      • Infrastructure Services Request ( final )
  • 34. 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.
    •   .
  • 35. Functional Design Stage Inputs:
    • SEM Templates:
      • Maintenance Plan
      • Requirements Specification
      • Requirements Traceability Matrix
      • Software Configuration Management Plan
    • PMM Templates:
      • Project Plan
      • Quality Management Plan
    • Other Inputs:
      • Security Plan
      • Business Continuity Plan
      • MDIT Hosting Solution Document
  • 36. 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
  • 37. 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
  • 38. 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 )
    • Other Outputs:
      • Security Plan ( revised )
      • Business Continuity Plan (revised)
      • Data Dictionary ( final )
      • MDIT Hosting Solution Document ( final )
  • 39. 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.
  • 40. 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
    • Other Inputs:
      • Security Plan
      • Data Dictionary
  • 41. System Design Stage High Level Activities:
    • 6.1 Design Specifications for Modules
    • 6.2Design 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
  • 42. 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
  • 43. System Design Stage Outputs:
    • SEM Templates:
      • Conversion Plan ( initial )
      • Maintenance Plan ( revised )
      • Requirements Traceability Matrix (revised)
      • Software Configuration Management Plan ( final )
      • Software Testing Checklist ( final )
      • System Design Checklist ( final )
      • System Design Document ( final )
      • Test Plan (initial)
      • Test Reports ( initial )
    • Other Templates:
      • Project Plan (revised)
      • Security Plan ( revised )
  • 44. 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.
  • 45. Stages of the SEM
    • SEM
    • Initiation and Planning
    • Requirements Definition
    • Functional Design
    • Systems Design
    • Construction
    • Testing
    • Implementation
    • SEM Express
    • Initiation, Requirements and Design
    • Construction and Testing
    • Implementation
  • 46. 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
    • Other Inputs:
      • Security Plan
      • Data Dictionary
  • 47. 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
  • 48. 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
  • 49. Construction Stage Outputs:
    • SEM Templates:
      • Conversion Plan ( revised )
      • Installation Plan ( initial )
      • Maintenance Plan ( revised )
      • Requirements Traceability Matrix (revised)
      • Test Plan ( final )
      • Test Reports ( revised )
      • Training Checklist ( final )
      • Training Plan ( initial )
      • Transition Plan ( initial )
    • PMM Templates:
      • Project Plan (revised)
    • Other Outputs:
      • Security Plan ( revised )
      • Development baselines
      • Operating Documentation
        • Users Manual
        • Developer's Reference Manual
      • Project Test File
      • System units and modules
  • 50. 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.
  • 51. Testing Stage Inputs:
    • SEM Templates:
      • 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
    • Other Inputs:
      • Security Plan
      • Development Baselines
      • Operating Documentation
        • Users Manual
        • Developer's Reference Manual
      • Project Test File
      • Software Modules
  • 52. Testing Stage High Level Activities:
    • 8.1 Conduct Integration Testing
    • 8.2 Conduct System Testing
    • 8.3 Conduct User Acceptance Testing
  • 53. 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
  • 54. Testing Stage Outputs:
    • SEM Templates:
      • Error Reporting and Tracking Checklist ( final )
      • Integration and System Testing Checklist ( final )
      • Pre-acceptance Checklist ( final )
      • Testing Package Checklist ( final )
      • User Acceptance Checklist ( final )
        • Conversion Plan (revised, if needed)
        • Installation Plan (final)
        • Maintenance Plan (revised)
        • Requirements Traceability Matrix (final)
        • Test 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)
    • Other Outputs:
      • Security Plan (revised)
      • Operating Documents (final)
        • Users Manual
        • Developer's Reference Manual
  • 55. 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.
  • 56. Stages of the SEM
    • SEM
    • Initiation and Planning
    • Requirements Definition
    • Functional Design
    • Systems Design
    • Construction
    • Testing
    • Implementation
    • SEM Express
    • Initiation, Requirements and Design
    • Construction and Testing
    • Implementation
  • 57. Implementation Stage Inputs:
    • SEM Templates:
      • Conversion Plan
      • Installation Plan
      • Maintenance Plan
      • Training Plan
      • Transition Plan
    • PMM Templates:
      • Project Plan
      • Quality Management Plan
    • Other Inputs:
      • Security Plan
      • Operating Documents
        • Users Manual
        • Developer's Reference Manual
  • 58. Implementation Stage High Level Activities:
    • 9.1 Perform Installation Activities
    • 9.2 Conduct Installation Tests
    • 9.3 Transition to Operational Status
  • 59. Implementation Stage Touchpoints:
    • Contracts and Procurement
      • Contract Liaison involvement to close out all open contracts and/or purchase orders related to this systems development effort
    • Security
      • Work with the MDIT Security Liaison to finalize and get final signoff of the Security Plan (DIT-0170)
    • Other
      • Finalize the Business Continuity Planning process.
  • 60. 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 )
    • Other Outputs:
      • Security Plan ( final )
      • Converted data or system files
      • Installation Test materials
      • Operating documents
      • Operational software product
  • 61.  
  • 62. SEM Tailoring
    • The intent of SEM tailoring guidelines, found in SEM Chapter 2 , is to provide flexibility in utilizing SEM components in the systems development process. The focus here is to ensure that adequate processes are used for each of the various types of systems engineering initiatives – “using the right tool for the job.”
  • 63. Template Exercise/Break
    • Review the blank and completed template for “Requirements”
    • In small groups
      • Discuss how the form should be completed
    • Captain” (person w/lightest shirt) to report out on
      • How it felt using the new process
      • How is it the same/different
      • What do they need to make it a success
      • Difference between Clients role and MDIT role
      • Complete assignment and take break w/in 25 min
  • 64. Process Guides
  • 65. 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
  • 66. SEM Processes (linked) 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).
  • 67. Structured Walkthrough Process Guide
  • 68. Structured Walkthrough Process Guide
    • 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.”
  • 69. Structured Walkthrough Process Guide
    • The major objectives
      • Find errors & omissions as early as possible
      • Improve the quality of the product
    • Structured Walkthrough Meeting Record
    • Structured Walkthrough Management Summary Report.
  • 70. Structured Walkthrough Roles Detailed /Definitions in Notes
    • Author
    • Presenter
    • Moderator
    • Reviewers
    • Scribe
  • 71. 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
        • Software Configuration Management Plan
        • Maintenance Plan, if needed
      • Requirements Definition Stage:
        • Requirements Specification Document
        • Requirements Traceability Matrix
        • Security Plan
      • Etc…
  • 72. Stage Exit Process Guide
  • 73. Stage Exit Documentation
  • 74. Stage Exit Process Guide
    • Assists the project team with the Exit Approval Process.
    • Assists the project team in securing the approval by designated individuals to continue with the project and move forward into the next stage of development.
    • The Exit Approval indicates that all documents related to that stage have been approved and that there are no outstanding issues.
    • Stage Exit Position Response Form
  • 75. Stage Exit Participants
    • Systems Engineering Team
    • System Owner/Sponsor's)
    • Client point of contact (POC)
    • Software Quality Assurance (SQA)
    • Enterprise Architecture (EA)
    • Office of Enterprise Security (OES)
    • Infrastructure Services (IS)
    • Others, as appropriate
  • 76. 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
  • 77. Monitoring and Tracking
    • Bi-weekly 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 reviews reports and feedback on SEM usage
  • 78. Additional SEM Components
  • 79. SEM Systems Maintenance Guidebook
    • Offers guidance on system maintenance, including a section on Release Management
    • Refers the user back to existing SEM / SEM Express documents (templates) for the purposes of updating the documents (such as the Requirements Specification document)
  • 80. Additional SEM Workshops
    • Software Configuration Management
    • Requirements Gathering
    • Estimating
    • Structured Walkthrough & Stage Exit Processes
    • Security Plan
  • 81. Thoughts? - Questions?
    • During Implementation
    • Michigan.gov/SUITE
    • Your Manager/Project Manager
    • Local IO Core team and SEM Champion(s)
    • [email_address] – Routed to right responder
      • Software Engineering Process Group)
    • SEM Change Form MDIT 0181
    www.michigan.gov /suite SUITE Team Room on TechTalk (Projects –> MDIT –> SUITE)
  • 82.  
  • 83. Handouts
    • SEM Trifold
    • Slides as handouts – Print 4 or 6 per page double sided / stapled
    • Template and Sample for Requirements
    • SEM Template JobAid
    • SEM Express (19 pages – includes SEM Express Overview Diagram)