Life Cycle Plan (LCP)

Transcription

1 Life Cycle Plan (LCP) Swim Meet Sign-Up Team 03 Member Archan Dutta Swasti Sharma Rasleen Sahni Deepanshu Suneja Vibhanshu Sharma Jenny Greer Role Project Manager, Life Cycle Planner, Tester Operational Concept Engineer Feasibility Analysist, Website Maintainer Software Architect Software Prototyper IIV&V, Quality Management Focal Point, 12/03/17

2 Life Cycle Plan (LCP) Version 2.0 Version History Date Author Version Changes made Rationale 11/16/17 AD 1.1 Original template for use with LeanMBASE v1.0 Initial draft for use with LeanMBASE v1.0 12/03/17 JG 2.0 Added Section 6.2 Completed as part of TRR and final As-Built Package LCP_TRR_F17a_T03_V2.0 ii 12/03/17

3 Life Cycle Plan (LCP) Version 2.0 Table of Contents Life Cycle Plan (LCP)...i Version History... ii Table of Contents... iii Table of Tables... v Table of Figures...vi 1. Introduction Purpose of the LCP Status of the LCP Assumptions Milestones and Products Overall Strategy Project Deliverables Responsibilities Project-specific stakeholder s responsibilities Responsibilities by Phase Skills Approach Monitoring and Control Methods, Tools and Facilities Resources Iteration Plan Plan Capabilities to be implemented Capabilities to be tested Capabilities not to be tested CCD Preparation Plans Iteration Assessment Capabilities Implemented, Tested, and Results Core Capabilities Drive-Through Results Core Capabilities Drive-Through Results Adherence to Plan LCP_TRR_F17a_T03_V2.0 iii Version Date: 12/03/17

4 Life Cycle Plan (LCP) Version Transition and Support Plan Transition Plan Support Plan LCP_TRR_F17a_T03_V2.0 iv Version Date: 12/03/17

5 Life Cycle Plan (LCP) Version 2.0 Table of Tables Table 1: Artifact deliverable in Exploration Phase... 3 Table 2: Artifact deliverable in Valuation Phase... 3 Table 3: Artifact deliverable in Foundations Phase... 4 Table 4: Artifact deliverable in Development Phase... 4 Table 5: Project Specific Stakeholders... 5 Table 6: Stakeholder's Responsibilities in each phase... 5 Table 7: Stakeholder's Roles and Skills... 6 Table 8: Methods, Tools, and Facilities... 8 Table 9: COCOMOII Scale Driver... 9 Table 10: COCOMOII Estimate I Table 11: COCOMOII Estimate II Table 12: Construction iteration capabilities to be implemented Table 13: Construction iteration capabilities to be tested Table 14: Capabilities implemented, tested, and results Table 15: Capabilities Needing Demonstration at CCB LCP_TRR_F17a_T03_V2.0 v 12/03/17

6 Life Cycle Plan (LCP) Version 2.0 Table of Figures No table of figures entries found. LCP_TRR_F17a_T03_V2.0 vi 12/03/17

7 1. Introduction 1.1 Purpose of the LCP The purpose of this artifact is to: Identify the life cycle used for the project, Determine milestones in each phase of the life cycle, Establish role of each of the team members, Manage workflow and critical deadlines, Summarize the processes involved during each life cycle phase. 1.2 Status of the LCP This is the version 1.0 of Life Cycle Plan. This will be submitted with Development Commitment Package. This version will reviewed with the necessary stakeholders and the latest version will be delivered to the client. 1.3 Assumptions 1) The duration of the project is 12 weeks. The project started on 05 September 2017 and is expected to be completed by 01 December ) The team is following ARCHITECTED AGILE strategy. 3) ICSM model of software development will be used as a guideline for this project. 4) The team comprises of six members, 5 on campus and 1 off-campus, each with some experience in web development. 5) A team meeting was held at the end of each week (on a Saturday or Sunday) to review weekly progress and plan for upcoming processes. 6) The team will adhere to the Win-Win conditions as negotiated with the client during the Win-Win sessions. LCP_TRR_F17a_T03_V2.0 1 Version Date: 12/03/17

8 2. Milestones and Products 2.1 Overall Strategy The team is adhering to the strategy of ARCHITECTED AGILE for this project. The rationale behind using NDI is as follows: PDF extraction using Apache PDFbox. MySQL to facilitate information storage, retrieval, updating. PHP to develop the website. Hence, most of the core capabilities can be performed using Architected Agile Exploration phase Duration: 09/05/17-09/20/17 Concept: The team was formed and met the client to get overall details about the project. The team also had its first Win-Win negotiation with the client. Deliverables: Team Website, Program Model Milestone: None Strategy: One Incremental Commitment Cycle Valuations phase Duration: 09/21/17-09/30/17 Concept: The team began to evaluate the tasks to be performed. The team also had its second Win-Win negotiation with the client. Based on this negotiation, the requirements were understood, finalized and prioritized. The development started to look for appropriate technologies for the project. In this phase, the Software Prototyper, Feasibility Analyst, Life Cycle Planner and Operational Concepts Engineer did majority of the work. Deliverables: WinBook, Prototypes, Milestone: Prototype Presentation Strategy: One Incremental Commitment Cycle Foundations phase Duration: 10/01/17-10/07/17 Concept: The team started with the design of the project. This includes UML diagrams such as Use Case diagram, Sequence diagram, Class diagram etc. Each member also performed tasks specific to their roles especially the Software Architect, Software Prototyper and Feasibility Analyst. The technologies were also finalized : PHP, MySQL, Apache PDFbox. Deliverables: Risk and Defect Reports, Project Plan, Progress Report in Bi- Weekly Assignment, UML diagrams. Milestone: None Strategy: One Incremental Commitment Cycle LCP_TRR_F17a_T03_V2.0 2 Version Date: 12/03/17

9 Development phase Duration: 10/08/17- Currently in Progress Concept: The team started developing the system. The team successfully performed the following tasks: Database Creation PDF Extraction Website Landing page Head Coach post-login page Head Coach PDF upload functionality Parent post-login webpage Deliverables: Website, Risk and Defect Reports, Project Plan, Progress Report in Bi-Weekly Assignment, UML Diagrams, Technical Debt Reports, Development Commitment Review Package Milestones: Architecture Review Board Presentation, Development Commitment Review Package Strategy: One Incremental Commitment Cycle 2.2 Project Deliverables Exploration Phase Table 1: Artifact deliverable in Exploration Phase Artifact Due date Format Medium Team Website 09/13/2017 Website Link Soft copy Program Model 09/13/2006.doc,.pdf Soft copy Valuation Phase Table 2: Artifact deliverable in Valuation Phase Artifact Due date Format Medium Prototype 09/29/2017 Proto.io File (HTMLand PDF) Soft Copy WinBook 09/22/2017 Webpage on WinBook Soft Copy LCP_TRR_F17a_T03_V2.0 3 Version Date: 12/03/17

10 2.2.3 Foundations Phase Table 3: Artifact deliverable in Foundations Phase Artifact Due date Format Medium Risk and Defect Report 10/04/2017.xls Soft Copy & 09/20/2017 Project Plan 10/18/2017 & 10/04/2017 & 09/20/2017.mpp Soft Copy Development Phase Table 4: Artifact deliverable in Development Phase Artifact Due date Format Medium Risk and Defect 10/18/2017.xls Soft Copy Report Project Plan 10/18/2017.mpp Soft Copy Progress Report 10/18/2017.xls Soft Copy Development Commitment Review Package 10/16/2017 doc,.pdf Soft Copy LCP_TRR_F17a_T03_V2.0 4 Version Date: 12/03/17

11 3. Responsibilities 3.1 Project-specific stakeholder s responsibilities Table 5: Project Specific Stakeholders STAKEHOLDERS Head Coach Parents Davey Lam Archan Dutta Deepanshu Suneja Jenny Greer Rasleen Sahni Swasti Sharma Vibhanshu Sharma RO LES Users Users Client, Maintainer, Treasurer Project Manager, Life Cycle Planner Software Architect, Developer IIV & V, Quality Focal Point Feasibility Analyst, Developer Operational Concepts Engineer, Developer Software Prototyper, Developer 3.2 Responsibilities by Phase Table 6: Stakeholder's Responsibilities in each phase Name: Archan Dutta Role: Project Manager, LCP, Name: Swasti Sharma Role: Operational Concepts Engineer, Developer Exploration Valuation Foundations Development- Construction Iteration Determine Team Strengths, Weaknesses, Understand the project and assign roles. Understand the requirements well. Interact with the client during the Win- Win negotiations to obtain the Primary Responsibility Obtain and Clarify the requirements. Communicate the requirements to the team. Organize regular meetings Attend regular team meetings and. Identify capability goals, develop benefit chain diagram, and the business Primary Responsibility Identify the process/strategy. Work with the Feasibility Analyst to identify risks. Keep transparency within the team and assign tasks to each member. Also, organize regular team meetings. Make sure that the team understands the requirements well and that the prototypes conform to the requirements Primary Responsibility Track team s progress. Provide the team the necessary resources. Have a solid plan via Microsoft Project Plan. Schedule regular team meetings. As a developer, work on PDF extraction and integrate it with the website. Development- Transition Iteration Primary Responsibility Get feedback from the client based on the current product and communicate the required improvements to the development team. Keep track of progress via team meetings As a developer, ensure that the PDF extraction works perfectly with the website. LCP_TRR_F17a_T03_V2.0 5 Version Date: 12/03/17

12 Name: Rasleen Sahni Role: Feasibility Analyst, Developer Name: Deepanshu Suneja Role: Software Architect, Developer Name: Vibhanshu Sharma Role: Software Prototyper, Developer Name: Jenny Greer Role: IIV & V, Quality Focal Point requirements. Be a part of Win-Win negotiations. Understand the requirements well. Be a part of Win-Win negotiations. Understand the requirements well. Attend Client Meetings and understand the requirements well. Keep connected with the Project Manager via regular meetings. Attend Client Meetings and understand the requirements well. workflow. Research Several technologies such as MySQL, Oracle, PHP, Node.js, Java, Apache PDfbox to identify the best technologies for the project. Develop the UML diagrams for system design. Share the diagrams with the team during team meetings for improvements. Evaluate the risk items based on Win- Win negotiations. Communicate with the project manager and discuss methods of quality control. Perform Feasibility Analysis on each of the high risk prototypes. Communicate with the protoyper regards to high risk items. Attend regular team meetings and communicate the system design to the team. As a developer, work with the prototyper to do PDF extraction Work the Feasibility Analyst to prototype the Risk items first. Keep track of the team s progress. Attend the weekly team meetings. Provide peer review for each of the system design elements. As a developer, develop UI for the website. Conform to the system design. As a developer, develop UI for the website. Conform to the system design. After prototyping high risk items, remove the bugs and integrate the prototypes to start creating the actual product. Check Github, JIRA so that the team maintains quality of the product. Check the website for all test cases. As a developer, ensure that the UI/UX of the website conforms to the Win-Win agreements As a developer, ensure that the UI/UX of the website conforms to the Win-Win agreements. Constant communication with the project manager. Also work with the development team to create the website. Verify that the website conforms to the requirements of the client. 3.3 Skills Table 7: Stakeholder's Roles and Skills Team members Role Skills Archan Dutta Project Manager, Life Cycle Planner Team Management, Life Cycle Planning, HTML, Javascript, MySQL, COCOMO II, Solid Swasti Sharma Operational Concepts Engineer understanding of requirements. PHP, MySQL, Requirements Engineering, Knowledge of Business Flow and Benefit Chain Diagrams, Solid understanding of requirements. LCP_TRR_F17a_T03_V2.0 6 Version Date: 12/03/17

13 Team members Role Skills Rasleen Sahni Feasibility Analyst HTML, CSS, BootStrap, Javascript, Risk Analysis Deepanshu Suneja Vibhanshu Sharma Jenny Greers Software Architect Software Prototyper Quality Focal Point, IIV & V Knowledge of System Design Principles, UML diagrams, HTML, CSS, PHP, MySQL, Solid understanding of requirements. HTML, CSS, PHP, MySQL, Prototyping tools such as Proto.io Testing, Quality Control and Management, Solid understanding of requirements. LCP_TRR_F17a_T03_V2.0 7 Version Date: 12/03/17

14 4. Approach 4.1 Monitoring and Control To ensure that each of the team members is committed and accountable to their assigned tasks, the following steps were employed: Quality Management: 1. Research on methodologies and comparison with existing similar systems. 2. Weekly meetings to review and demonstrate the status of the assigned work. 3. Set deadlines for each task so that the team member is committed to completing the task. 4. Verification and Validation by team especially by our IIV&V. Configuration Management: 1. GitHub for version control. 2. Adhering to the Win-Win negotiations and constant feedback from the client Closed Loop Feedback Control The team communicates via WhatsApp group. The reports are shared via Google Docs/Slides/Sheets. Off-campus student was contacted via the Google Hangouts, Text, , Phone Calls Reviews Peer Review: Architecture Review Board: Client Evaluation: 4.2 Methods, Tools and Facilities Table 8: Methods, Tools, and Facilities Tools Usage Provider MySQL Database Open Source PHP Backend Open Source Apache PDF extractions Open source PDFbox Visual UML Diagram Visual Paradigm Paradigm Proto.io Prototyping Labs Division of SNQ Digital WinBook Store Win-Win agreements USC AngularJS Frontend Open Source LCP_TRR_F17a_T03_V2.0 8 Version Date: 12/03/17

15 Tools Usage Provider JIRA Keep track of work. Also assign tasks to each Atlassian member COCOMO A tool to estimate time, estimate schedule of the project USC 5. Resources Identify the following information in order to estimate the software cost: - Estimated CSCI577a Effort : 6 team members at 13 hrs/week for 12 weeks - Total estimated effort: 936 hours - Budget information: $0 - Project duration: 12 weeks - Component modules in your development project: Database Module, PDF Extraction Module, User Interface Module - Programming language used: PHP, JavaScript, HTML, CSS, SQL Scale Driver Table 9: COCOMOII Scale Driver Scale Driver Value Rationale PREC Several Event Registration Systems already exist FLEX The requirements are specific to the swimming organization and therefore most of them must be completed. RESL Very Based on ICSM, risk mitigation is essential. This has been done by prototyping the risks. PMAT Based on Yes CMM Questionaire TEAM Very Weekly meetings, Daily communication via s, messages, highly cooperative team LCP_TRR_F17a_T03_V2.0 9 Version Date: 12/03/17

16 5.1.2 Cost Driver RELY DATA DOCU CPLX RUSE TIME STOR Database Module PDF Extraction Module User Interface Module If the website fails working If the website fails working If the website fails working the expected way, parents the expected way, parents the expected way, parents will have to spend more time will have to spend more will have to spend more to sign up their kids for time to sign up their kids time to sign up their kids for events by going to the for events by going to the events by going to the Swimming Association. Swimming Association. Swimming Association. There will not be There will not be There will not be severe severe financial loss. severe financial financial loss. The product s D/P ratio is in the range (10,100). The documentation provides good information about the future plan of the project, the priority of tasks and the required analysis of life cycle and feasibility more than it is required. The data management operations are not that complex. The system is specific to the swimming association as the pdf format is fixed. The system will fail to work if the PDF format changes. Less than 50% use of available execution time. Less than 50% use of available storage. loss. The product s D/P ratio is in the range (10,100). The documentation provides good information about the future plan of the project, the priority of tasks and the required analysis of life cycle and feasibility more than it is required. The pdf extraction operations are not that complex. The system is specific to the swimming association as the pdf format is fixed. The system will fail to work if the PDF format changes. Less than 50% use of available execution time. Less than 50% use of available storage. The product s D/P ratio is in the range (10,100). The documentation provides good information about the future plan of the project, the priority of tasks and the required analysis of life cycle and feasibility more than it is required. The user interface operations are not that complex. The system is specific to the swimming association as the pdf format is fixed. The system will fail to work if the PDF format changes. Less than 50% use of available execution time. Less than 50% use of available storage. LCP_TRR_F17a_T03_V Version Date: 12/03/17

17 PVOL ACAP PCAP PCON AEXP LTEX PEXP Database Module PDF Extraction Module User Interface Module The operations performed The Pdf extraction module The user interface creation on database to create table, operations to extract and operations are not complex. insert and retrieve data are parse data are not complex. The platform will not not complex. The platform The platform will not change much. will not change much. change much. The team members have high database analysis and design ability, high efficiency and thoroughness The team members have high programmer capability for database systems. The module s personnel turnover is around 95% leading to low personnel continuity. The project team has high level of experience in working with databases. The project team has high level experience of using MySQL. The project team has high understanding of use of powerful platforms for database management. The team members have high pdf extraction module s analysis and design ability, high efficiency and thoroughness The team members have low programmer capability for PHP. The module s personnel turnover is around 95% leading to low personnel continuity. The project team has low level of experience in working with PHP and Apache PDFBox used for this module. The project team has low level experience of using PHP and Apache PDFBox. The project team has low understanding of use of more powerful platforms for pdf extraction and parsing The team members have high user interface s analysis and design ability, high efficiency and thoroughness The team members have high programmer capability for frontend technologies The module s personnel turnover is around 95% leading to low personnel continuity. The project team has medium level of experience in working with HTML, CSS, Bootstrap. The project team has high level experience of working with HTML, CSS, JavaScript. The project team has high understanding of use of powerful platforms for user interface development and management. LCP_TRR_F17a_T03_V Version Date: 12/03/17

18 TOOL SITE SCED Database Module PDF Extraction Module User Interface Module The project has low use pf The project has low use software tools for pdf pf software tools for user extraction module. interface module. The project has low use pf software tools for database module. The multisite development effects are significant. The schedule constraint imposed on project team developing the database module is not significant. The multisite development effects are not significant. The schedule constraint imposed on project team developing the pdf extraction module is not significant. The multisite development effects are not significant. The schedule constraint imposed on project team developing the user interface module is not significant COCOMO II Estimate Table 10: COCOMOII Estimate I Table 11: COCOMOII Estimate II The estimate provided by the COCOMO (using the pessimistic estimate) is 152 hours/pm * 12.8 = hours. Our estimate is 936 hours. Hence, the estimate of the COCOMO is very different from the team s estimate. LCP_TRR_F17a_T03_V Version Date: 12/03/17

19 6. Iteration Plan 6.1 Plan Based on the requirements and schedule, the team plans to finish the project in two iterations. The first iteration will focus on -Risk items as they should be prioritized and prototyped first (Based on ICSM model). The high-risk items include PDF Extraction and UI/UX for the users. The second iteration will focus on building the core capabilities of the system. The main focus of this iteration would be on the Backend. The Frontend will also be refined in this iteration. After the development phase, the team will perform rigorous testing. The project will be handed over to the client and the website will be deployed on the server. The maintainer will be responsible for two major tasks: 1. Update the Database. 2. Teach the Head-Coach (and Parents, if possible) on how to use the website Capabilities to be implemented Most of the capabilities belong to one of the two users: Parent (denoted by P) Head-Coach (denoted by HC) Table 12: Construction iteration capabilities to be implemented ID Capability Description Priority Iteration 1 P: Login Authentication for Parent est 1 2 HC: Login Authentication for Head est 1 Coach 3 HC: Upload PDF Upload the PDF for the est 1 Swim Meet. This PDF contains information about the events 4 HC: PDF Extraction Use Apache PDFbox to est 1 extract information from the uploaded PDF 5 HC: Set Deadline Choose a date after which 1 Signups will not be allowed 6 HC: Add Event Head Coach can add a event that was not present in the PDF or due to some Medium 2 LCP_TRR_F17a_T03_V Version Date: 12/03/17

20 ID Capability Description Priority Iteration reason the event was not extracted from the PDF. 7 HC: Edit Event Head Coach can edit Medium 2 information about the events if change is required or information was not correctly obtained during extraction. 8 P: Event Signup Parent can sign up his/her kid est 2 9 P:View Eligible Events Only for the swimming event Parent can see only the events that their kid is qualified for 10 HC: View All Meet Events After Upload PDF, the Head Coach can see all the events 10 HC: Edit Signups Head Coach can change the Signups made by the parent. 11 Cross-Browser Website should run on Compatibility Browsers like Firefox, 13 Cross-Device Compatibility 14 P: View Payment Amount 15 P: View Payee Information Chrome, IE, Safari. Website should run as desired on mobile and desktop Based on the cost of Sign ups, Parents can see how much he/she has to pay. Parent can see information about where to send the check 16c Concurrent User Login Multiple User can access the website at the same time 17 Generate Report Generate a pdf and csv file of swimmers signed up for event Capabilities to be tested Table 13: Construction iteration capabilities to be tested est 2 1 est 2 Medium 2 Medium 2 Medium 2 2 Medium 1 2 ID Capability Description Priority Iteration 1 P: Login Authentication for Parent est 1 2 HC: Login Authentication for Head est 1 Coach 3 HC: Upload PDF Upload the PDF for the Swim Meet. This PDF est 1 LCP_TRR_F17a_T03_V Version Date: 12/03/17

21 ID Capability Description Priority Iteration contains information about the events 4 HC: PDF Extraction Use Apache PDFbox to est 1 extract information from the uploaded PDF 5 HC: Set Deadline Choose a date after which 1 Signups will not be allowed 6 HC: Add Event Head Coach can add a event Medium 2 that was not present in the PDF or due to some reason the event was not extracted from the PDF. 7 HC: Edit Event Head Coach can edit Medium 2 information about the events if change is required or information was not correctly obtained during extraction. 8 P: Event Signup Parent can sign up his/her kid est 2 for the swimming event 9 P:View Eligible Parent can see only the events est 2 Events Only that their kid is qualified for 10 HC: View All Meet After Upload PDF, the Head 1 Events Coach can see all the events 10 HC: Edit Signups Head Coach can change the est 2 11 Cross-Browser Compatibility 13 Cross-Device Compatibility 14 P: View Payment Amount 15 P: View Payee Information Signups made by the parent. Website should run on Browsers like Firefox, Chrome, IE, Safari. Website should run as desired on mobile and desktop Based on the cost of Sign ups, Parents can see how much he/she has to pay Parent can see information about where to send the check. 16 Concurrent User Login Multiple Users can access the website at the same time 17 Generate Report Generate a pdf and csv file of swimmers signed up for event Medium 2 Medium 2 Medium 2 2 Medium 1 2 LCP_TRR_F17a_T03_V Version Date: 12/03/17

22 6.1.3 Capabilities not to be tested All the capabilities mentioned above must be tested. Most of these capabilities are mentioned have been negotiated in the Win-Win negotiations and mentioned the Winbook. Rigorous Testing of all the capabilities is required to ensure that website can handle nominal and off- nominal cases CCD Preparation Plans The Core Capability Drive would involve hands-on product testing by the client. The major goals of the development team are: Accurate Event extraction from the PDF Head Coach can view/add/edit the events. Parent can Sign-up their kids for the events. The above mentioned goals will also undergo testing so that the client can have seamless experience (as much as possible). 6.2 Iteration Assessment Capabilities Implemented, Tested, and Results Table 14: Capabilities implemented, tested, and results ID Capability Test Case Test Results If fail, why? 1 P: Login TC-02 Pass 2 HC: Login TC-03 Pass 3 HC: Upload PDF TC-01 Pass 4 HC: PDF Extraction TC-01 Pass 5 HC: Set Deadline TC-03 Pass 6 HC: Add Event TC-03 Pass 7 HC: Edit Event TC-03 Pass 8 P: Event Signup TC-02 Pass 9 P:View Eligible Events TC-02 Pass Only 10 HC: View All Meet Events TC-03 Pass 10 HC: Edit Signups TC-03 Pass 11 Cross-Browser TC-04 Pass Compatibility 13 Cross-Device Compatibility TC-04 Pass 14 P: View Payment Amount TC-02 Pass 15 P: View Payee TC-02 Pass Information 16 Concurrent User Login TC-04 Pass 17 Generate Report TC-03 Pass LCP_TRR_F17a_T03_V Version Date: 12/03/17

23 6.2.2 Core Capabilities Drive-Through Results The Core Capabilities Drive (CCD) through was very successful. During the CCD, capability related to uploading pdf, parent and head coach login, and parent and head coach pages. The ability to generate a report was not completed yet and it was not demonstrated. Specific details about capabilities demonstrated are in the following table. Table 15: Capabilities Needing Demonstration at CCB ID Capability Demonstrated 1 P: Login Yes 2 HC: Login Yes 3 HC: Upload PDF Yes 4 HC: PDF Extraction Yes 5 HC: Set Deadline Yes 6 HC: Add Event Yes 7 HC: Edit Event Yes 8 P: Event Signup Yes 9 P:View Eligible Events Only Yes 10 HC: View All Meet Events Yes 10 HC: Edit Signups Yes 11 Cross-Browser Compatibility No 13 Cross-Device Compatibility No 14 P: View Payment Amount Yes 15 P: View Payee Information Yes 16 Concurrent User Login No 17 Generate Report No Core Capabilities Drive-Through Results Positive Feedback Overall the customer was excited about functionality implemented so far. The client indicated that he liked the Uploading pdf functionality and how the information was displayed to the customer. He was excited to see how easy it was to select swim events. He indicated that he liked how quickly and easily individual swim events could be selected and added to the cart Improvements needed/suggested Feedback provided was that the SwimMeetSignUp website/program needed additional user feedback indications when errors occurred. Such as problems with PDF loading or not extracting all the data. It was recommended that we look at off nominal cases to account for those items. Other feedback we received was related to website usability. Increased simplification and improved usability was also requested. LCP_TRR_F17a_T03_V Version Date: 12/03/17

24 Changes to be considered Changes we were asked to consider was related to usability. We received suggestions on the coloring and layout of the webpage design. It was also recommended that we consider how the pages will look when they are resized. It was also recommended that we focus on getting the implementation for working with mobile devices completed Risks The primary risk coming out of the CCD was related to scheduling. That there would not be enough time to complete all the essential functionality in the remaining timeframe. If we are unable to complete the report generation portion of the tool, then the rest of the website effectivity will be reduced. 6.3 Adherence to Plan The first iteration was very successful for the team. We were able to stay on schedule and complete the necessary activities. However, the second iteration was not as successful. We have struggled to complete all the capability in the required schedule which is driven by this being a 1 semester class. To avoid this mistake in the future, recommend improving software estimates and saying no to functionality that we cannot knowingly get in. 7 Transition and Support Plan 7.1 Transition Plan The transition plan for the SwimMeetSignup is to make sure rigorous testing is performed before handing this over to the client. When the software package is delivered the client it is important that it will be maintainable. To help with maintainability we are going to improve code readability by adding additional comments. We will also be providing a technical and user manual. The team also plans to provide some training to the client for future maintenance. 7.1 Support Plan As this is a school based project we will not be able to provide long term support for this program. As part of the transition plan, we intended to help the client get this set up on his computer and working with his servers. Support beyond this initial setup will be difficult. However, hopefully the technical manual will provide enough information for the client to fix small problems. LCP_TRR_F17a_T03_V Version Date: 12/03/17