Tài liệu Module 7: Release Milestone pdf

Module 7: Release Milestone THIS PAGE LEFT INTENTIONALLY BLANK 0RGXOH#:=#5HOHDVH#0LOHVWRQH# # :²6 2EMHFWLYHV At the end of this module, you will be able to „ Understand the infrastructure development process „ Prepare for deployment „ Perform effective solution testing „ Use change control processes „ Perform a pilot At the end of this module, you will be able to define and understand the infrastructure development process and what it takes to prepare for deployment of a wide variety of technologies Specifically, this module presents concepts and processes necessary to take the vision, functional specification, and plans from previous milestones and develop what is necessary for the deploying phase ahead :²7# # 0RGXOH#:=#5HOHDVH#0LOHVWRQH /HVVRQV Lessons Principles and Concepts Developing Phase Outline Validating the Technology Developing the Proof of Concept Performing Preproduction Testing Performing Pilot Testing 0RGXOH#:=#5HOHDVH#0LOHVWRQH# /HVVRQ#4=#3ULQFLSOHV#DQG#&RQFHSWV Lesson 1: Principles and Concepts The principles behind the developing phase and how they enable you to achieve the release milestone # :²8 :²9# # 0RGXOH#:=#5HOHDVH#0LOHVWRQH 5LVN#$VVHVVPHQW „ Perform as an ongoing activity „ Develop contingency plans based on known risks and their level of impact „ Escalate high-impact risks to the external audience Risk assessment is an important ongoing activity It is not an event Risks affect everything from planning, schedules, and communications, to development activity itself Identify and communicate risks to the team periodically 0RGXOH#:=#5HOHDVH#0LOHVWRQH# # :²: &KDQJH#&RQWURO „ Provides central access for all project-related material „ Ensures that development and testing efforts are not lost „ Allows for rollback if errors are made in subsequent versions „ Divides the development process into manageable parts Change control allows you to track, capture, and document changes to the solution as development progresses Change control enables the team to break the development process into manageable parts, mitigate problems, and fall back to the last known good configuration if the mitigation fails The project team must be able to determine the who, what, why, where, when, and how of proposed changes The team must be able to assess the risk and impact of the change and have a mechanism for tracking the changes that have been implemented By using change control, the test team knows that the components of the build won’t change during the testing process In other words, for any given build, the environment is contained (unchanged) versus dynamic (changing constantly) :²;# # 0RGXOH#:=#5HOHDVH#0LOHVWRQH 7HVWLQJ „ Makes known all issues that team must resolve „ Validates against the functional specification „ Performs regression testing (whether the solution breaks anything in the existing environment) „ Determines whether the solution requires supplemental components (updated drivers, dynamic-link libraries, or service packs) „ Captures user behavior to test against unstated expectations The testing team is responsible for making all issues known It is then up to the team to resolve those issues and communicate the resolution back to testing This is done so that the issue-tracking system that testing maintains can be updated to reflect the current state of the build Is this solution built according to the functional specification? That is the question that the test team is trying to answer when it validates the solution against the functional specification Regression testing is used to make sure that the current build of the solution does not break what is already there Testing is vital to the success of the project If the team is to deploy the element to 40,000 workstations, for example, one issue resolved in the lab saves 40,000 problems after deployment 0RGXOH#:=#5HOHDVH#0LOHVWRQH# # :²< ,VVXH07UDFNLQJ#3URFHVV Identify Issues and Record Them Move Forward Review Issues Each Day Resolve Issues Testing documents the issues as it finds them The testing team member should add an issue to the issue-tracking mechanism with an estimation of the severity of that issue and a description of the steps that it takes to reproduce it The development lead prioritizes the issue using a scale of to 4, with being the worst and being a trivial issue Then the lead assigns it to the developer responsible for that feature for resolution The worst possible issue is one with a severity of and a priority of This is an issue that crashes the solution and must be tracked down and resolved The information the tester documents during the issue-tracking process is invaluable to the training and support staff It shows them the history of the solution, the problems encountered during development, and the resolutions :²43# # 0RGXOH#:=#5HOHDVH#0LOHVWRQH 3URMHFW#&RPPXQLFDWLRQV Identify key audiences and messages Prepare users, management, support, and administrators for what will come, when, and why Improve chance of success by increasing project support Set expectations by discussing the good and bad elements Communications during the development phase is more nebulous than in other phases because so much depends on the complexity of the project, organization dynamics, and so on A review of best practices found the following: „ The communications plan must remain flexible It will almost always change because of various circumstances surrounding the project „ The project team should continually review the plan and raise issues to key stakeholders, who will have the most input into changes in the plan „ If the communications plan has been fully developed, project communications is a simple matter of telling targeted groups what they need to hear, when they need to hear it For example, during piloting you will deal only with pilot issues and only communicate them to people affected by the pilot, rather than to the entire enterprise „ The team should continually track the effectiveness of the communications, which amounts to a scaled-down project review after each major communication :²5;# # 0RGXOH#:=#5HOHDVH#0LOHVWRQH THIS PAGE LEFT INTENTIONALLY BLANK 0RGXOH#:=#5HOHDVH#0LOHVWRQH# /HVVRQ#8=#3HUIRUPLQJ#3UHSURGXFWLRQ#7HVWLQJ Lesson 5: Performing Preproduction Testing The process for confirming that the solution will integrate into the production environment # :²5< :²63# # 0RGXOH#:=#5HOHDVH#0LOHVWRQH 3UHSURGXFWLRQ#7HVW#&RPSOHWH#,QWHULP#0LOHVWRQH „ Test as much of the entire solution as practical prior to pilot test „ Evaluate against success criteria „ Complete site preparation checklist and procedures „ Complete implementation procedures, scripts, load sets, and checklists „ Complete „ Resolve training material support and issue problems The preproduction test complete interim milestone is not complete until the team ensures that everything developed to deploy the solution is fully tested and ready 0RGXOH#:=#5HOHDVH#0LOHVWRQH# # :²64 ,QVWDOODWLRQ#3URFHGXUHV#DQG#6FULSWV „ Automate the deployment effort, where practical „ Avoid or reduce the possibility of human error during deployment „ Provide troubleshooting and problemresolution guidelines (for future milestones, training, and support) „ Provide backup and recovery or fallback procedures as called for in the business continuation plan Installation procedures and scripts will help you automate the deployment effort for greater efficiency The degree to which you will be able to automate a given process will depend in great part on the number of times the team will perform the process and on the skill and/or knowledge of those involved :²65# # 0RGXOH#:=#5HOHDVH#0LOHVWRQH 7UDLQLQJ „ Review the constraints of the training and deployment plan „ Reevaluate risk and refine the training plan „ Develop supplemental material (cheat sheets and frequently asked questions) „ Create, validate, and acquire (when applicable) courseware „ Develop training preparation checklist „ The training and deployment plans often define constraints on the actual training material For example, the deployment plan may allow only a single day of training on the technology „ The training plan may be modified to reflect changes made during development „ The technical development staff and pilot participants can provide insight for supplemental course material, like frequently asked questions (FAQs) and resolutions for common problems „ The training staff may identify and evaluate various off-the-shelf courseware that fits within the constraints of the deployment and plan For example, the user education team members may have to incorporate supplemental material to suit the individual project, while condensing a three-day course into one or two days to fit the schedule „ Develop a checklist to set up the training facility and ensure the availability of all materials necessary for training 0RGXOH#:=#5HOHDVH#0LOHVWRQH# # :²66 &KHFNOLVWV#DQG#7HPSODWHV Identify „ Users „ Equipment to be validated „ Accessibility issues „ Staging area „ Delivery checklist „ Training of trainers „ Localization „ Top issues 10 risks and how to avoid them Checklists and templates ensure consistency and completeness and can be used to signify the successful completion of various steps during deployment :²67# # 0RGXOH#:=#5HOHDVH#0LOHVWRQH 2SHUDWLRQV#3URFHGXUHV „ Maintenance procedures „ Client/desktop „ Server „ Enterprise „ Disaster recovery and new site installation (after deployment) „ Performance and fault monitoring „ Support and troubleshooting „ Backup and restore procedures „ Maintenance procedures include proper “feeding and care” of client (software or hardware residing on the user desktop), server (hardware or software residing on servers), and enterprise components (including networking components, master databases, legacy systems, gateways, hubs, and so on) „ The operational documentation should include instructions on disaster recovery and new site installation, including reinstalling the technologies and restoring from backups These instructions should also include information necessary to build a site from scratch „ Performance and fault-monitoring procedures explain what those monitoring the new technology should be aware of, and pay close attention to, both when the technology is being deployed and after it is in full production „ Any support or troubleshooting items that are identified during development should be included in this During deployment, further items may be identified and included later 0RGXOH#:=#5HOHDVH#0LOHVWRQH# /HVVRQ#9=#3HUIRUPLQJ#3LORW#7HVWLQJ Lesson 6: Performing Pilot Testing How to conduct the “dress rehearsal” # :²68 :²69# # 0RGXOH#:=#5HOHDVH#0LOHVWRQH 3LORW#&RPSOHWH#,QWHULP#0LOHVWRQH „ Test the solution in the production environment „ Maintain a zero-defect mindset „ Successfully „ Document „ Have complete the pilot issues, resolutions, and work-arounds a support and issue-resolution process in place „ Test the process as a rehearsal for deployment „ The pilot complete interim milestone is not complete until the team ensures that the proposed solution is viable in the production environment and every component of the solution is ready for deployment „ The core MSF principle of zero-defect mindset should be practiced throughout development, but the team should pay special attention to it during this interim milestone This is the last opportunity the team will have to resolve issues before deployment begins „ Prior to beginning a pilot, the team and the pilot participants must clearly identify and agree upon the success criteria of the pilot These should map back to the success criteria for the development effort „ Any issues identified during the pilot must be resolved either by further development, by documenting resolutions and work-arounds for the installation teams and production support staff, or by incorporating them as supplemental material in training courses „ Before the pilot is started, a support structure and issue-resolution process must be in place This may require that support staff be trained The procedures used for issue resolution during a pilot may vary significantly from those used during deployment and when in full production „ In order to determine if your deployment process will work, it is necessary to implement a trial run or a rehearsal of all the elements of the deployment so that you may identify issues prior to the actual deployment It is easier and less costly to fix these items during the pilot 0RGXOH#:=#5HOHDVH#0LOHVWRQH# # :²6: 3UHSDULQJ#WKH#3LORW „ Define pilot success criteria (to assure an end to testing) „ Identify appropriate location „ Confirm pilot users (appropriately small sampling) and communicate with them „ Implement feedback process to capture issues „ Success criteria should be mapped back to the objectives for development Before beginning the pilot, those criteria should be shared with the pilot participants Each participant must understand those criteria, and their role and responsibilities Success criteria should be specific, objective, and measurable; otherwise, success will be left to the subjective opinions of the pilot participants It’s far too late to identify new requirements at this point in the process However, if a mission-critical element was not identified earlier or has not been incorporated, it’s better to identify it now than to deploy a nonviable solution to production „ The location or business unit that will be involved in the pilot should have been identified during the planning phase This may be modified based upon project constraints „ Make sure this group, and the management of these users, is aware of the current pilot schedule „ Ensure that there is an easy way for the team to capture issues identified during the pilot and that users are participating A best practice is to offer an incentive to users for participating, perhaps even a contest (a prize to the participant reporting the most issues) Make sure any incentives are designed to reward the behavior desired for a successful pilot :²6;# # 0RGXOH#:=#5HOHDVH#0LOHVWRQH 3HUIRUPLQJ#WKH#3LORW „ Test implementation procedures and scripts „ Track and resolve issues „ Perform „ Test and test recovery strategy entire implementation process „ Site preparation checklist „ Deployment strategy „ Draft courseware for user training „ If at all possible, have a person outside the development or testing team perform the installation with oversight from development Developers and testers have performed these procedures routinely throughout the development process An outsider can help identify overlooked issues „ Every identified issue must be captured and added, just as all issues were tracked throughout development „ If part of the development effort includes fallback or recovery procedures as stated in the business continuation plan, the pilot team must force a failure and recover from it to ensure that the recovery procedures work Because this is being performed in a production environment, users and administrators must be aware of the possible risks and be careful to take appropriate precautions (for example, back up immediately before forced failure) „ Don’t leave out anything This should follow the flow and steps of an actual deployment It is the last time to identify issues and resolve them 0RGXOH#:=#5HOHDVH#0LOHVWRQH# # :²6< /HDUQLQJ#IURP#WKH#3LORW „ Identify risks „ Develop frequently asked questions for training „ Identify frequently experienced user errors „ Gain buy-in and support from pilot users „ Document and resolve issues „ Determine if success criteria were met „ Determine if a repilot or return to previous phase or interim milestone is necessary „ More risks are often identified during this milestone because it is the first time the solution has been introduced into a production environment „ As actual users identify problems and issues, these should be captured by production support staff and possibly be included in supplemental training material „ Pilot users are a critical, uncontrolled part of communications The best, most positive communications can be ruined by negative comments from pilot participants Make sure pilot users are aware that they are part of the project and play a role in its success Keep them happy and involved „ Any issues identified during the pilot must be documented and resolved before the major milestone is met „ Was the pilot successful? Does the solution meet the success criteria? These questions should be taken seriously because the answers may indicate a need to return to a previous milestone or that the solution is ready for deployment „ Were enough issues and risks identified that require further development and a repilot? Were issues identified that brought serious doubt to the success of the project? If so, the team should consider returning to a previous milestone :²73# # 0RGXOH#:=#5HOHDVH#0LOHVWRQH 7UDQVLWLRQLQJ#WR#WKH#'HSOR\LQJ#3KDVH „ Incorporate „ Baseline feedback from pilot all deliverables required for deployment „ Transfer issue-tracking data identified during development „ Ensure all testing issues are known to the team „ Conduct a milestone review This is a list of some of the tasks that must be completed before the project can move past the release milestone You may need to add tasks to this list depending on the nature of your project or organization 0RGXOH#:=#5HOHDVH#0LOHVWRQH# 6XPPDU\ „ What are the components of a solution developed during the infrastructure development process? „ What interim milestones are required to achieve the release milestone? „ What should you accomplish during solution testing? „ What are the benefits of a user-requirements walkthrough? Summary # :²74 0RGXOH#:=#5HOHDVH#0LOHVWRQH# THIS PAGE INTENTIONALLY LEFT BLANK # :²75 ... issues are known to the team „ Conduct a milestone review This is a list of some of the tasks that must be completed before the project can move past the release milestone You may need to add tasks... developed during the infrastructure development process? „ What interim milestones are required to achieve the release milestone? „ What should you accomplish during solution testing? „ What... the milestones and deliverables that must be achieved # :²46 :²47# # 0RGXOH#:=#5HOHDVH#0LOHVWRQH 7KH#&XOPLQDWLRQ#RI#''HYHORSLQJ Deployment Complete EN G IN VI DE NG NI Agreement on Y O IO S PL Release