Senior Design Documentation Library

Transcription

1 Project Charter Department of Computer Science and Engineering The University of Texas at Arlington Taekwondo Match Management System TK Force Team Members: Richard Sherrill Robert Castillo David Odhiambo Huadong Feng Late Updated: 9 August 7:57:00 PM Project Charter

2 Project Charter Project Charter

3 Project Charter Table of Contents 1 General Organization Project Manager Project Oversight Roles and Responsibilities Project Constraints Project Assumptions Preliminary Schedule and Cost Estimates Scope Statement Introduction Product Definition Intended Audience Cost Management Plan Introduction Financial Costs Labor Costs Earned Value Management Introduction Value and Cost Additional Indicators Scope Management Plan Introduction Scope Definition Scope Management Methodology Scope Control Work Breakdown Structure Introduction Microsoft Project Plan Quality Management Plan Introduction Documentation Software Design Communications Plan August 7:57:00 PM i Table of Contents

4 Project Charter 8.1 Internal Communication External Communication Change Management Plan Purpose of Integrated Change Management Plan Roles and Responsibilities Review and Approval Process Change Identification, Documentation, Implementation and Reporting Risk Management Plan Purpose of Risk Management Plan Roles and Responsibilities Risk Identification Risk Triggers Risk Analysis Risk Severity Risk Response Planning Risk Documentation and Reporting Risk Control Procurement Management Plan Purpose of the Procurement Management Plan Roles and Responsibilities Required Project Procurements and Timing Description of Items/ Services to be acquired Project Closeout Report Purpose of Closeout Report Administrative Closure August 7:57:00 PM ii Table of Contents

5 1 General Organization 1.1 Project Manager Richard Sherrill has been selected as the Project Manager/Team Leader for the Taekwondo Match Management System by team TK Force. Richard s main responsibility is creating assignments for the team and monitoring the MS Project plan to ensure that we are meeting deadlines and staying on track. Some of his additional responsibilities is reviewing the final documents after they have been assembled, checking for errors, and working out formatting issues as well as taking on additional assignments so the team may complete deadlines on time. Richard is a Software Engineering senior and has many technical skills that are applicable to this project, but has been mainly selected for his communication skills, organization skills, and team management skills. 1.2 Project Oversight Team TK Force has developed several methods for project control and are separated under two main categories, internal and external controls Internal Controls Microsoft Project Plan: The MS Project plan created by Project Manager/Team Lead Richard Sherrill is responsible for ensuring that we meet all of our internal deadlines as well as keep track of the team s progress on the project. The MS Project plan has been solely created by Richard Sherrill and will also be maintained by Richard so that the plan maintains its integrity. In order to keep track of our progress Richard has created a separate list of assigned tasks for each team member that can be edited and updated by the appropriate team member. These files will allow Richard to appropriately update the MS Project file without each team member needing to alter the MS Project file directly. Team Meetings: Team TK Force has meetings after every class for quick updates in order to get an overview of our progress, check to see if everyone in the team is progressing as expected, and determine if any work needs to be split among other team members. The team also has major meetings on weekends in order to get input from the team and join individual assignments together. The team also maintains a high level overview of the main points that occurred during each meeting and saves these points in the team document management system. 9 August 7:57:00 PM 1 General Organization

6 Document Management: Team TK Force has created a Dropbox for keeping track of major documents. The entire team has viewable access to all documents and read/write access to individual assigned portions. The team designates only one person for full control to the major document External Controls Individual Status Reports: Individual status reports are reported to Mr. O Dell which will allow him to track our progress and see where the team is on an individual level. This also gives each individual member of the team a time to reflect on the work completed since the previous individual status report and reflect on what they have learned. Team Status Report: The team will also have to give team status reports in the form of presentations which allows us to inform Mr. O Dell of our progress as a team. The team status reports will include the team progress and some of our individual tasks that we have been working on. Gate Review: The team will also have gate reviews which will be a formal presentation of some of our main deliverables. The team gate reviews will allow us to communicate our main sections of the project so that we can receive feedback and refine the details of each main deliverable. 1.3 Roles and Responsibilities Team TK Force has developed preliminary roles for each member of the team. The assignment of these roles have been assigned as evenly as possible and the team has tried to distribute these roles to each team member s strengths. The team supervisor, Mike O Dell, and the project sponsor, William Sexton s roles have also been defined in correspondence with our project. Project Member Role Description Mike O Dell William Sexton Richard Sherrill Team Supervisor Project Sponsor Team Leader Documents Lead Software Design lead Oversee project progress and grade major deliverables. Provide the team with requirements for developing our project and give us feedback on what we re developing. Keep track of schedule, make team assignments, and assemble and format documents. 9 August 7:57:00 PM 2 General Organization

7 David Odhiambo Huadong Feng Robert Castillo Software developer Hardware Researcher Software developer Documents producer Database design and implementation lead Software developer Documents producer Software Implementation lead Software developer Quality assurance lead Documents producer Ensures that the software design meets the system requirements Implement software design and ensure requirements are met Research the hardware communication between Dae do equipment and software product Assist in software implementation Produce content for documents Main database designer and database developer Implement software design and ensure requirements are met Produce content for documents Ensure that the software is meeting the requirements and matching the software design Implement software design and ensure requirements are met Review deliverables and ensure that the quality is being met Produce content for documents 1.4 Project Constraints The Taekwondo Match Management System has time constraints, scheduling constraints, and resources constraints. The constraints are described as follows: The overall project lifecycle is limited to about six and a half months. 9 August 7:57:00 PM 3 General Organization

8 The schedule of team members constrains the amount of time that we can interact as a team and participate in meetings. The equipment has already been developed and we might not have a way to interface with the equipment. The project sponsor is not easily accessible. 1.5 Project Assumptions The assumptions for the Taekwondo Match Management System are as follows: The project sponsor will be able to meet and respond at times that we need. Each team member will be able to meet internal deadlines on time. Team members will be able to attend all meetings. Team will be able to receive the defense equipment we need to interface with in a timely manner. Team will be able to interface with the defense equipment in order to receive the appropriate data needed for the Taekwondo Match Management System. Team TK Force will not provide maintenance or support after December Preliminary Schedule and Cost Estimates Project Milestone Due Date SRS Draft 7/9/2013 Project Plan Draft 7/11/2013 Project Charter Draft 7/11/2013 Informal Review 7/12/2013 SRS Gate Review 7/23/2013 SRS Baseline 7/30/2013 Architectural Design Draft 8/6/2013 Project Charter Baseline 8/9/2013 Project Plan Baseline 8/9/2013 Architectural Gate Review 8/13/2013 Detail Design Review 9/25/ August 7:57:00 PM 4 General Organization

9 System Test Plan Review 10/18/2013 Project Closeout 12/6/2013 Task Preliminary Cost (Hours) System Requirements Specification 50 Project Charter 60 Project Plan 22 Task Preliminary Cost (Hours) Architecture Design Specification 42 Detailed Design Specification 120 System Test Plan 90 Product Development August 7:57:00 PM 5 General Organization

10 2 Scope Statement 2.1 Introduction The purpose of this product is to enhance the training and tracking of Taekwondo matches. The primary way of accomplishing this task is measuring the amount of forces that competitors inflict upon each other during matches. The software will keep track of these individual matches and record this required information. 2.2 Product Definition The product will contain defense equipment provided by Daedo and our software system will interface with their receivers. The system will communicate the location of hits, which will be one of two locations either head or body, and force of hits to the system in order to provide administrators of the software with useful information. The information retrieved from the defense equipment will also help in displaying a life bar to an audience. This audience display will help inform the audience which competitor is currently winning a match. 2.3 Intended Audience The intended audience for this product is our sponsor, who will be using this product in a Taekwondo gym in order to host matches and use for training purposes. Other types of users of this product are gym owners, trainers of Taekwondo, and officials who host Taekwondo tournaments. 9 August 7:57:00 PM 6 Scope Statement

11 3 Cost Management Plan 3.1 Introduction This section contains information on how our team will manage our costs. We will be tracking two types of cost: financial and labor. 3.2 Financial Costs As the project stands, the team will not need to spend very little, if any, money in the development of the system. The hardware components are being provided by the team s sponsor, which includes the electronic fighting equipment and the wireless receiver, which connects to any computer. However, the team is currently researching an alternate plan if the sponsor s equipment cannot be integrated with our software. If the manufacturer of the equipment proves to be uncooperative, and our team cannot determine the output of the receiver, a scaled down version of the hardware will have to be built. The cost of the components for the alternate plan is being researched at this time. 3.3 Labor Costs We have implemented a Microsoft Project plan to help team members determine how much time is allotted on a particular task. This will provide an indication of whether we are on, behind, or ahead of schedule. This plan will be primarily managed by the team leader, but all other members will have input on cost estimations. The initial estimate for the total labor cost is approximately 850 hours. This estimate is based on research on our requirements and the equipment we will be integrating with, along with assumptions for the second half of the project. This estimate may change, depending on which hardware plan we will be implementing. 9 August 7:57:00 PM 7 Cost Management Plan

12 4 Earned Value Management 4.1 Introduction To keep track of the team s progress, we will be measuring earned value. This technique will allow team TK Force to view the difference between the planned hours and actual hours spent on the project. In addition, the team will have access to the MS Project plan to view progress on individual progress, as well as team progress. 4.2 Value and Cost The earned value is determined by is determined by the budgeted cost of work performed (BCWP) and the budgeted cost of work scheduled (BCWS). When a task is 100 percent complete, the team s earned value is the same as the BCWS. When compared to the actual cost of work performed (ACWP), the result will indicate whether the team is over budget or under budget for single or multiple tasks. 4.3 Additional Indicators Calculations of the cost performance index (CPI) and schedule performance index (SPI) will provide the team with a simple way to view the status of the project at a given instance. The following calculations are how we will determine the value for both indices: CPI = BCWP / ACWP SPI = BCWP / BCWS If the CPI is greater than 1.0, the team is under the budgeted time allotted for the given task. A value less than that means, at that particular time, the team is over the budgeted time and must determine the reason. Since the CPI is an instance, the team will view the trend to give a better indication of what action needs to be taken. If the SPI is greater than 1.0, the team is ahead of schedule with deliverables. If the SPI is lower than that, it indicates that the team is behind schedule. Once again, the SPI will be viewed as the current value, as well as the trend to give the team a better indication of our position in the schedule. 9 August 7:57:00 PM 8 Earned Value Management

13 5 Scope Management Plan 5.1 Introduction The scope management plan will be used to define the scope of the whole project to avoid additional features that might have negative effects to the project. Customer has already provided the detailed requirements of the product and the acceptance criteria. The scope will be defined based on the system requirements and the acceptance criteria. This section contains an introduction to the scope definition, scope management plan and scope control. 5.2 Scope Definition From the requirements that customer has provided to us, we have decided that our scope and goal is to finish a product that can run 1 match. The additional features such as having a multimatch, Myo control will be considered as future item. They will not be the functions that will be focusing on. Since the goal of this system is to help people train in Taekwondo. We have decided that finish everything that can provide users a good run of match. 5.3 Scope Management Methodology Our Methodology is to have the customer s detailed system requirements first then starts from the biggest picture. We make decisions from the biggest picture to the little details. This will help us to avoid expanding the big picture. We decided the finished product should focus on managing single matches. Next we go into a little deeper level such as what features do we need to complete a good match. Then few functions came out of the requirements. We will rate the functions from 1 to 5, and then decide to keep the function or not. 5.4 Scope Control In order to control the scope, each team member will be working on the defining scope together to ensure that the scope definition is defined properly. Microsoft Project will clearly define tasks assigned to each team member to track the process of the project. Everyone reports directly to the team leader to avoid unexpected changes to the project. Project files will be updated immediately after creation or modification into the Dropbox folder. 9 August 7:57:00 PM 9 Scope Management Plan

14 6 Work Breakdown Structure 6.1 Introduction Team TK Force has several major categories that make up the project, which will span two semesters: Senior Design I and Senior Design II. The major categories at this time are Project Start, Requirements Definition, Planning and Estimating, Product Architecture, Detailed Design, Product Development, and Test Plan. At this time, these are the categories we plan to focus on. As the plan progresses, the plan may be broken down into more logical sections to make the work plan clearer for team members. 6.2 Microsoft Project Plan The current plan only covers up to Product Architecture, and will be updated, once the information is available. Also, the plan will change if we have to use our backup hardware plan. WBS Task Name Planned Start Planned Finish Planned Value 1 SENIOR DESIGN I Tue 6/18/13 Mon 8/12/ hrs 1.1 PROJECT START Tue 6/18/13 Wed 6/19/ hrs Team Introduction Tue 6/18/13 Tue 6/18/ hrs Work Schedule Tue 6/18/13 Tue 6/18/ hrs Pick Lab Cubicle Tue 6/18/13 Wed 6/19/ hrs 1.2 REQUIREMENTS DEFINITION Sat 6/22/13 Tue 7/30/ hrs Requirements Gathering Sat 6/22/13 Sat 6/29/ hrs Develop Initial Requirements Sat 6/22/13 Sat 6/22/ hrs Refine Requirements from Sponsor Tue 6/25/13 Tue 6/25/ hrs Official Requirements Definitions Sat 6/29/13 Sat 6/29/ hrs Develop Initial SRS Document Fri 7/5/13 Mon 7/8/ hrs SRS Draft Sun 7/7/13 Mon 7/8/ hrs Compile SRS Draft Mon 7/8/13 Mon 7/8/ hrs SRS Final Document Sun 7/14/13 Tue 7/30/ hrs Integrate Changes from Instructor Sun 7/14/13 Sun 7/21/ hrs Integrate Changes from Peer Review Sun 7/14/13 Sun 7/21/ hrs Integrate Changes from Gate Review Tue 7/23/13 Tue 7/30/ hrs 1.3 PLANNING AND ESTIMATING Sat 6/29/13 Fri 8/9/ hrs 9 August 7:57:00 PM 10 Work Breakdown Structure

15 1.3.1 Develop Project Charter Sun 7/7/13 Thu 7/11/ hrs Project Charter Draft Sun 7/7/13 Thu 7/11/ hrs General Organization Sun 7/7/13 Thu 7/11/ hrs Scope Statement Sun 7/7/13 Thu 7/11/ hrs Cost Management Sun 7/7/13 Thu 7/11/ hrs Earned Value Sun 7/7/13 Thu 7/11/ hrs Scope Management Sun 7/7/13 Thu 7/11/ hrs Work Breakdown Sun 7/7/13 Thu 7/11/ hrs Quality Management Sun 7/7/13 Thu 7/11/ hrs Communications Sun 7/7/13 Thu 7/11/ hrs Change Management Sun 7/7/13 Thu 7/11/ hrs Risk Management Sun 7/7/13 Thu 7/11/ hrs Procurement Management Plan Sun 7/7/13 Thu 7/11/ hrs Project Closeout Report Sun 7/7/13 Thu 7/11/ hrs Product Charter Final Document Tue 7/9/13 Fri 8/9/ hrs Integrate Recommended Changes Tue 7/9/13 Fri 8/9/ hrs General Organization Thu 8/8/13 Thu 8/8/ hrs Scope Statement Thu 8/8/13 Thu 8/8/ hrs Cost Management Thu 8/8/13 Thu 8/8/ hrs Earned Value Tue 7/30/13 Thu 8/8/ hrs Scope Management Thu 8/8/13 Thu 8/8/ hrs Work Breakdown Tue 7/30/13 Thu 8/8/ hrs Quality Management Thu 8/8/13 Thu 8/8/ hrs Communications Thu 8/8/13 Thu 8/8/ hrs Change Management Fri 8/9/13 Fri 8/9/ hrs Risk Management Fri 8/9/13 Fri 8/9/ hrs Procurement Management Plan Thu 8/8/13 Thu 8/8/ hrs Project Closeout Report Fri 8/9/13 Fri 8/9/ hrs MS Project Plan Sat 6/29/13 Fri 8/9/ hrs Draft Sat 6/29/13 Thu 7/11/ hrs Baseline Thu 7/11/13 Fri 8/9/ hrs 1.4 PRODUCT ARCHITECTURE Fri 7/26/13 Mon 8/12/ hrs Architecture Research Fri 7/26/13 Sat 8/3/ hrs ADS Draft Thu 8/1/13 Thu 8/8/ hrs Introduction Thu 8/1/13 Thu 8/8/ hrs Meta-Architecture and Layers Thu 8/1/13 Thu 8/8/ hrs Architecture Layers (Detailed) Sat 8/3/13 Thu 8/8/ hrs Relationship Mapping Wed 8/7/13 Thu 8/8/ hrs Requirements Mapping Thu 8/1/13 Thu 8/8/ hrs Operating System Dependencies Thu 8/1/13 Thu 8/8/ hrs Testing Considerations Thu 8/1/13 Thu 8/8/ hrs 9 August 7:57:00 PM 11 Work Breakdown Structure

16 1.4.3 ADS Final Fri 8/9/13 Mon 8/12/ hrs Integrate Changes Fri 8/9/13 Mon 8/12/ hrs 2 SENIOR DESIGN II Thu 8/22/13 Mon 12/2/ hrs 2.1 DETAILED DESIGN Thu 8/22/13 Wed 9/25/ hrs 2.2 TEST PLAN Thu 9/26/13 Fri 10/18/ hrs 2.3 PRODUCT DEVELOPMENT Fri 10/18/13 Mon 12/2/ hrs 3 MEETINGS Tue 6/18/13 Sat 8/10/ hrs 3.1 Team Meeting Tue 6/18/13 Tue 6/18/ hrs 3.2 Team Meeting Sat 6/22/13 Sat 6/22/ hrs 3.3 Team Meeting Sat 6/29/13 Sat 6/29/ hrs 3.4 Team Meeting Fri 7/5/13 Fri 7/5/ hrs 3.5 Team Meeting Sat 7/6/13 Sat 7/6/ hrs 3.6 Team Meeting Sun 7/7/13 Sun 7/7/ hrs 3.7 Team Meeting Tue 7/9/13 Tue 7/9/ hrs 3.8 Team Meeting Tue 7/16/13 Tue 7/16/ hrs 3.9 Team Meeting Sat 7/20/13 Sat 7/20/ hrs 3.10 Team Meeting Thu 8/1/13 Thu 8/1/ hrs 3.11 Team Meeting Sat 8/3/13 Sat 8/3/ hrs 3.12 Team Meeting Sat 8/10/13 Sat 8/10/ hrs 4 RESEARCH Sun 7/14/13 Wed 8/28/ hrs 4.1 Hardware Research Sun 7/14/13 Wed 8/28/ hrs Daedo Equipment Initial Test Sun 7/14/13 Sat 7/20/ hrs Daedo Equipment Team Test Tue 8/13/13 Wed 8/28/ hrs 4.2 Software Research Tue 8/13/13 Wed 8/28/ hrs Programming Languages Tue 8/13/13 Wed 8/28/ hrs Daedo Software Tue 8/13/13 Wed 8/28/ hrs 9 August 7:57:00 PM 12 Work Breakdown Structure

17 7 Quality Management Plan 7.1 Introduction Quality management plan will help our team to ensure that we can stay on the track of making a product with good quality. This includes the quality control of the documentations, planning and the product. With the quality management plan, the product will satisfy the needs of customer, perform well after it has been delivered and less trouble on the maintenance and update in the future. 7.2 Documentation All of the documents will be divided into 4 sections and assign to each team member. We will have a meeting about how to divide the documents and who to assign every time when we need to work on a document. Then one team member will be on charge of assemble the divided the documents make them into a final version. During the process, all the files will be uploaded into the Dropbox folder. So the team member can keep on track of how everyone is doing in their part of documentation. To avoid ambiguity, no changes can be made after a file has been uploaded. If a change needs to be made, a new file with the version number will be added into the file name. After the final version has been completed and uploaded into the Dropbox folder, every team member will read the final document though to make sure there is no error. 7.3 Software All the software and functions will be tested under different inputs and conditions to ensure the stability of the software. The customer will be testing the software every time we complete a function to make sure that the software satisfies the needs of the customer and the user interface is friendly to non-technical users. Code will be written as modules to allow ease of testing before and after integration. Any changes to the code will be well documented. 7.4 Design The customer will be stay informed during the period of design the product. We will use a large amount of time to discuss the design within the team and getting feedback from the customer. We will use Waterfall and Agile method for our development. 9 August 7:57:00 PM 13 Quality Management Plan

18 8 Communications Plan 8.1 Internal Communication Team Meeting We will have short meetings after class to communicate with each other to keep each other updated of how the work is going. We will also have 3 hours long meetings on Saturday. Attendance is required since these are the only free time we have in common. If a team member cannot attend, he should inform each team member before the meeting time. During the long meetings, we will be working on the planning and the work that we have to work on together such as making decisions, design, etc We will be mainly using s to communicate outside of school. Team member should set up the receiver on their smartphones and check s at least every day. s will be used to inform everyone about meetings, and every other formal event Dropbox We will be using Dropbox to share files with every team member. No changes can be made after a file has been uploaded. A team member will be on charge with sorting and organizing the files in the Dropbox folder Text Messages/Call Whenever we need an immediate response from any team member, text messages or phone calls will be using to communicate. Also a text message will be sent to remind everyone whenever anyone sent a team External Communication We will be mainly using s to communicate with our sponsor, any files or questions will be asked through . s will be easier for our team to keep on track with what information our sponsor has provided to us Skype We will be having video chatting with our sponsor to discuss longer problems such making decisions on design and getting feedbacks. 9 August 7:57:00 PM 14 Communications Plan

19 9 Change Management Plan 9.1 Purpose of Integrated Change Management Plan The purpose of this integrated Change Management plan is to figure out how manage any changes that occur during the process of making the product. A dynamic process like this has to have a system in which we already plan on any changes that might occur and how to plan to manage them. Integrated change management is good for the group because there has to be a guideline in which we will use to deal with changes. We plan to have an Editable Change Document that has to be filled by the team or sponsor in case of any in case of any identification of the Changes. Such changes include when the sponsor might want to add more requirements or we decide that it is not feasible to implement a certain requirements for any reason such as lack of time or it being very expensive. 9.2 Roles and Responsibilities Project Sponsor- William Sexton will inform us beforehand of any changes that might occur in the duration of the project. In case he has a change, he will fill out the Change Form and submit it to the team members. Project Manager- Richard Sherrill is also the team leader. He will review any submitted changes that are introduced and will combine them for the whole group to discuss. Once changes are approved by the group, he will assign a team member to work on it. Project Team- The team will discuss any changes and provide input on if they will approve or reject any changes. The whole team will be responsible for implementing the changes that are assigned by the project leader. Other Stakeholders- Mr. O Dell will provide advice on how to deal with any changes. 9.3 Review and Approval Process Changes will come from the project team and the sponsor. The changes are discussed upon and decision to approve or disapprove will come from the team members since we are the actual people who are working on it. If any changes cannot be complete before the end of the project, they will be rejected. Some changes might be too costly beyond the budget provided by the school. In case of that, then we will have to ask the sponsor to provide funds or we might shop around for a cheaper deal. 9 August 7:57:00 PM 15 Change Management Plan

20 Identify Change If sponsor introduced the change Group leader Introduces the change to the group members Change is discussed with the Sponsor If change cannot be implemented If group accepts the change If change Cannot be implemented Group members discuss the change Group members implement the change Change politely rejected End of Change 9.4 Change Identification, Documentation, Implementation and Reporting Changes go through a formal process. There is a Change Tracking Document that is to be used to keep track of changes and a form to fill out to explain the changes fully. The process of working on a change is that team members and sponsor will fill out an editable document which will be ed to all of us. The changes will be discussed on during Saturday meeting. If the changes are urgent, we will call for a prompt meeting. The reports from what we discussed on the changes will be documented and kept for records. If the changes are accepted, they will be implemented. 9 August 7:57:00 PM 16 Change Management Plan

21 NAME DATE CHANGE REQUEST FORM Nature of change Personal Opinion on change Team opinion on change 9 August 7:57:00 PM 17 Change Management Plan

22 10 Risk Management Plan 10.1 Purpose of Risk Management Plan In regards to our project risk is an unexpected event or condition that could have a negative effect on a project. Anything that will delay or prevent us from completing our project can be considered as a risk. A Risk Management plan is a plan on how to manage all the risks associated with the project. A risk management plan is the process of how to identify and handle any risks that will arise to make a negative impact in regards to our project. This project is of a great magnitude and we as students need it for our career experience. Identifying potential risks is good for our project because it reduces potential risks and helps us reduce them Roles and Responsibilities Project Manager: Richard Sherrill will provide input on the risks that may arise. He assigns the risks to the various team members to review. He compiles all the Risk Management Forms and brings them up for review during team meetings. Project Team: The team members provide input on the unforeseen risks by filling out the Risk Management Form. They handle the risks that may arise as assigned by the group leader and discuss the risks during team meetings. Also, they will do research on how to minimize risks and provide input on how to minimize or eliminate risks. Project Stakeholders: William Sexton will be updated on the risks and how the risks are managed, and will address any risks he may know. Risk Manager: At the moment there is no Risk manager because we all provide input on how to manage the risks Risk Identification There will be a formal process on how to identify risks. During the course of the project, each team member will be responsible for identifying and analyzing risks. The problem will be documented in detail and submitted to the team leader, so that it can be brought up during the next team meeting. In case it is an urgent problem, an emergency meeting will be called Risk Triggers Some of the risk triggers that may arise include: Sponsor pulling out of project Expensive hardware and software in case sponsor pulls out Team members missing important meetings Failure of equipment 9 August 7:57:00 PM 18 Risk Management Plan

23 Faulty Architecture design 10.5 Risk Analysis The whole team analyzes the risks so that they can be assessed as a percentage of reduction in performance. The member who identifies a risk will document it and will discuss with the rest of the team members Risk Probability in % Days lost Sponsor pulling out of project Expensive hardware and software in case sponsor pulls out Team members missing important meetings Time / Risk Exposure in days Failure of equipment Faulty Architecture design Other Risks Total Risk Severity Below is the impact/probability chart which is called the risk severity grid. Each risk that may arise is identified and the responsible action on how to contain it described. The Risks are classified as High, Low or Medium and a system to avoid, plan or mitigate described as a response. Risk Priority Strategy Responsible Action Trigger Sponsor pulling out of project Expensive hardware and High Mitigate Keep the sponsor interested by maintaining constant communication and demonstrating trust. Medium Avoid Do a lot of research of our back up plan so as to be able Poor communication and not maintaining interest of the sponsor. Lack of proper research for a backup plan 9 August 7:57:00 PM 19 Risk Management Plan

24 software in case sponsor pulls out Team members missing important meetings to be self-sufficient with a cheaper useful alternative Low Avoid Keep involving members through constant communications and reminders of meeting times Lack of proper planning of meeting times Failure of equipment Faulty Architecture design Low Plan Constantly doing research on how the equipment should work High Avoid Plan the Architecture in advance after researching on how the equipment should perform Other Risks High Avoid Keep researching on how the equipment should work to be able to come up with unforeseen risks Not doing enough research Lack of Research Not engaging each other enough to have a lot of knowledge on the product 10.7 Risk Response Planning The team will need to use several methods to address any risks faced in the project. To properly respond to the risks, the team will need to research all areas of the project to minimize any technological hurdles. Risks that do not fall under technology will be addressed through proper communication with team members, the instructor, and the team s sponsor Risk Documentation and Reporting The risks will be submitted to each member for review and the team leader will introduce them during meetings and the appropriate action will be undertaken. The risks will be distributed among each team member through , drop box or through meetings. Risk Identification Form Name of Submitting member Nature of Risk 9 August 7:57:00 PM 20 Risk Management Plan

25 Opinion Team Discussion on the Risk Conclusion 10.9 Risk Control Information on the Risks that have been dealt with are stored in a Risk Management Folder in the Drop Box Account. New Risks are constantly introduced during meetings and through . All risks have to be discussed and not dismissed as unimportant. 9 August 7:57:00 PM 21 Risk Management Plan

26 11 Procurement Management Plan 11.1 Purpose of the Procurement Management Plan The procurement management plan will be useful in ensuring that the team has a set plan for purchasing or seeking external expertise in areas unfamiliar to the team. This plan will set standards for determining if external consultation is necessary and for guaranteeing that the team can and will purchase the best suitable products that, if needed, best suit our needs Roles and Responsibilities Project Sponsor: The project sponsor will have the opportunity to purchase products that he would like integrated into the project. The sponsor will be the primary user of the system and therefore can purchase would he would like to use. Project Manager: The project manager will be responsible for final approval for any products that the team would like to purchase. The project manager will also be responsible for bringing these purchase requests to the project supervisor. Project Team: The project team will determine the types of products that we need to purchase. Each member of the team will be responsible for researching these products in order to get the correct products for the best price Required Project Procurements and Timing The procurements phase has been assumed to begin immediately after the System Requirements Specifications draft has been finished. The start of this phase is necessary because of the teams need to ensure that we have all the necessary parts in order to begin our development starting August or September Description of Items/ Services to be acquired The current system is still evolving and the team is researching what parts or services may be needed for this system. 9 August 7:57:00 PM 22 Procurement Management Plan

27 12 Project Closeout Report 12.1 Purpose of Closeout Report When we complete this project charter, a close out report will be produced. The purpose of this report is to insure that personnel, contract, administrative, and financial issues are resolved, that documents are archived, and lessons learned are captured Administrative Closure Were the objectives of the project met? The report shall make sure that the objectives are met. The report determines that what we had done what we had planned in the system requirements specification. We have to document every objective that we have is completed Archiving Project Artifacts The documents will be collected and saved on drop box. The following documents will be saved for future reference: Financial records Cost and schedule performance reports and records Quality data Images MS Project file Correspondence Meeting Notes Status Reports Issue and Action Log Risk Log Contract Files Change Requests Technical documents Acceptance records Lessons Learned The lessons that we have learned so far is that we have to document everything that we are working on. It is important to keep a log of whatever we do so that we do not diverge from 9 August 7:57:00 PM 23 Project Closeout Report

28 our main objectives. We also learned that documenting and planning helps us to get a better understanding on our project Plans for Post Implementation Review (PIR) Our post implementation review is to make sure that our objectives were met. The sponsor and the instructor will review our final product and make sure completed the project to their satisfaction. In addition, our final grade will reflect on how successful we were in our project Final Customer Acceptance Our final customer acceptance is to be able to satisfy the sponsor, the instructor, and the team. Every stakeholder will review the project and its documentation Financial Records The financial records and invoices will be presented to the instructor. The records will be saved by each individual team member, as well as the university Final Project Performance Report At the conclusion of the project, a final project performance report will be created to summarize the project s scope management, schedule performance, cost performance, quality achievements, and a review of the risk containment performance. This report will also address the reasons for cost or schedule variances. 9 August 7:57:00 PM 24 Project Closeout Report