Life Cycle Plan (LCP)

Transcription

1 Life Cycle Plan (LCP) Scriptonomics Team No - 7 Team Member USC Id Role Role Aditya Holikatti holikatt@usc.edu Feasibility Engineer Software Developer Alex Miller milleram@usc.edu IIV &V Website Maintainer Anitha Neelakantan aneelaka@usc.edu Software Architect Software Developer Michael Cappuccio mcappucc@usc.edu Prototyper IIV & V Nicky Singh nickysin@usc.edu Lifecycle Planner Requirements Engineer Nikhita Reddy Gade ngade@usc.edu Project Manger Feasibility Engineer Sri Anusha veeramac@usc.edu Requirements Lifecycle Planner Veeramachineni Engineer Vaishnavi Venkatraman vvenkatr@usc.edu Operations Concept Engineer Software Architect

2 Life Cycle Plan (LCP) Version 1.0 LCP_F17a_T07_V1.1 ii Version Date: 10/10/17

3 Life Cycle Plan (LCP) Template Version 1.0 Version History Date Author Version Changes made Rationale 10/10/17 Nicky 1.0 Estimated project overall efforts and scheduled the timelines, milestones and resource section elaboration is done 10/10/17 Sri Anusha 1.0 Added Introduction, Milestones and Products, Responsibilities Initial draft for use with FCR ARB report. Initial draft for use with FCR ARB report. and Approach. 10/14/17 Nicky 1.1 Update details on transition phase LCP document to be submitted as DC package LCP_F17a_T07_V1.1 10/10/17

4 Life Cycle Plan (LCP) Version 1.0 Table of Contents Life Cycle Plan (LCP)... i Version History... iii Table of Contents... iv Table of Tables... v Table of Figures... Error! Bookmark not defined. 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 Adherence to Plan LCP_F17a_T07_V1.1 iv Version Date: 10/10/17

5 Life Cycle Plan (LCP) Template Version 1.0 Table of Tables Table 1: Artifacts Deliverables in Exploration Phase... 3 Table 2: Artifact deliverable in Exploration Phase... Error! Bookmark not defined. Table 3: Artifact deliverable in Valuation Phase... 3 Table 4: Artifact deliverable in Foundations Phase... 4 Table 5: Artifact deliverable in Development Phase... 4 Table 6: Stakeholder's Responsibilities in each phase... 6 Table 7: COCOMOII Scale Driver Table 8: COCOMOII Cost Driver Table 9: Application Count: Screens... Error! Bookmark not defined. Table 10: Application Count: Reports... Error! Bookmark not defined. Table 11: Application Count: 3GL components... Error! Bookmark not defined. Table 12: Application Point Parameters... Error! Bookmark not defined. Table 13: Construction iteration capabilities to be implemented Table 14: Construction iteration capabilities to be tested Table 15: Capabilities implemented, tested, and results LCP_F17a_T07_V1.1 10/10/17

6 1. Introduction 1.1 Purpose of the LCP The main purpose of LCP for our project is to: Provide an overview of the overall plan for the project s development. Ensure proper resource allocation. Give an idea on how to divide time and people resources to various aspect and phases of our project and ensure timely deliverable to customer. 1.2 Status of the LCP The LCP is currently at version 1.0. This is the initial version that has been created for FCR- ARB package. This version will be reviewed with the necessary stakeholders and if there are no changes to be made, the latest version of this document will be delivered to the client. 1.3 Assumptions While working on our project we have few underlying assumptions The duration of the project is 12 week during Fall Team consists of 8 members, 6 on-campus students and 2 DEN students. All team members should work on the project in Fall All team members are familiar with Incremental commitment spiral model. LCP_F17a_T07_V1.1 1 Version Date: 10/10/17

7 2. Milestones and Products 2.1 Overall Strategy Scriptonomics is following NDI/NCS Intensive Process: All the capabilities (functions) of our system are delivered by COTS/ services like Zinnia. Exploration phase Duration: 08/09/17-09/22/17 Concept: Identify operational concept, system and software requirements along with their architecture, and life cycle plan. Deliverables: Risk Defect Report, Progress Report, Project Plan, Client Interaction Report, and Win Conditions Report. Milestone: Valuation Commitment Review Strategy: One Incremental Commitment Cycle, Risk assessment analysis. Win-Win Negotiation Sessions. Valuation phase Duration: 09/19/17-10/18/17 Concept: Project operational concept, System and software Architecture, System and software requirements review. During this phase we prioritized the use cases based on high risk, we performed feasibility analysis and implemented the software prototype. Deliverables: OOAD documents, Working Prototype. Milestone: Foundations Commitment Review Strategy: One Incremental Commitment Cycle, Software Architecture review. Foundations phase Duration: 9/26/17-10/11/17 Concept: Analyze project status and plan, stabilize project progress to optimize deliverables quality, develop prototype for high risk capabilities. Deliverables: UI/UX frontend design, Draft Foundation Commitment Package Milestone: Development Commitment Review Strategy: One Incremental Commitment Cycle, Risk assessment analysis. Development phase Duration: 10/11/17-11/25/17 Concept: Core Capability Drive, Developing and implementing the full system with required features. Performing unit, integration and regression testing. Project plan, recording project progress. Deliverables: Core Capability Drive-Through Report Milestone: Transition Readiness Review Strategy: Development, Testing, Training, Deployment LCP_F17a_T07_V1.1 2 Version Date: 10/10/17

8 Transition Phase Duration 11/26/17-12/04/17 Concept: Training the maintainer after developing the system about how to use the same, Transition Readiness Review Deliverable: Transition Readiness Review Package, Project Archive Milestone: Transition Readiness Review Strategy: Training and Documentation 2.2 Project Deliverables Following are the project deliverables each phase by phase and their respective due date of expected completion: Exploration Phase Table 1: Artifacts Deliverables in Exploration Phase Artifact Due date Format Medium Client Interaction Report 09/08/2017.pdf Win Conditions Report 09/22/2017.pdf Jira Weekly Monday Jira Ticket Jira Website Risk and Defect Report Project Plan Progress Report Bi-weekly Wednesday Bi-weekly Wednesday Bi-weekly Wednesday.xls.mpp.xls Valuation Phase Table 2: Artifact deliverable in Valuation Phase Artifact Due date Format Medium Top Risk Prototype Presentation 09/29/2017.pptx LCP_F17a_T07_V1.1 3 Version Date: 10/10/17

9 Draft Foundations Commitment Package Operational Concept Description (OCD) Life Cycle Plan (LCP) Feasibility Evidence Description (FED) Prototype (PRO) System and Software Architecture Description (SSAD) Jira Risk and Defect Report Project Plan 10/11/2017.doc.pdf Weekly Monday Bi-weekly Wednesday Bi-weekly Wednesday Jira Ticket.xls.mpp Jira Website Progress Report Bi-weekly Wednesday.xls Foundations Phase Table 3: Artifact deliverable in Foundations Phase Artifact Due date Format Medium Jira Weekly Monday Jira Ticket Jira Website Risk and Defect Report Project Plan Progress Report Development Commitment Review Presentation Bi-weekly Wednesday.xls Bi-weekly.mpp Wednesday Bi-weekly.xls Wednesday 10/11/2017.pptx Development Phase Table 4: Artifact deliverable in Development Phase Artifact Due date Format Medium Jira Weekly Jira Ticket Jira Website Monday LCP_F17a_T07_V1.1 4 Version Date: 10/10/17

10 Risk and Defect Report Project Plan Progress Report Development Commitment Package Operational Concept Description (OCD) Life Cycle Plan (LCP) Feasibility Evidence Description (FED) Prototype (PRO) System and Software Architecture Description (SSAD) Bi-weekly Wednesday.xls Bi-weekly.mpp Wednesday Bi-weekly.xls Wednesday 10/16/2016.doc.pdf Transition Phase Table 5: Artifact deliverable in Transition Phase Artifact Due date Format Medium Draft Transition Readiness Review 11/26/2016-.doc.pdf Package Operational Concept Description (OCD) Life Cycle Plan (LCP) Feasibility Evidence Description (FED) Prototype (PRO) System and Software Architecture Description (SSAD) 12/01/2016 Transition Readiness Review Presentation 11/27/2016-.pptx Transition Readiness Review Package Operational Concept Description (OCD) Life Cycle Plan (LCP) Feasibility Evidence Description (FED) Prototype (PRO) System and Software Architecture Description (SSAD) 12/01/ /04/2017.doc.pdf LCP_F17a_T07_V1.1 5 Version Date: 10/10/17

11 3. Responsibilities 3.1 Project-specific stakeholder s responsibilities The project specific stake holder is the scriptwriter. As scriptwriters will be the end users for this App, after the prototype phase we have negotiated with the client to take feedback from the scriptwriters. 3.2 Responsibilities by Phase Table 2: Stakeholder's Responsibilities in each phase Team Member / Role Name: Tammuz Role: Client Name: Aditya Holikatti Role: Feasibility Engineer, Software Developer / Exploration Valuation Foundations Development- Construction Iteration Explain the current existing system to team Provide details about the essential features required by Scriptonomics users. -Perform risk and defect analysis based on requirements and resources available and prioritize the risks. -Explore mitigation Explain win conditions and negotiate the win-win conditions with the development team -Analyze system architecture and business workflow diagram and provide feasibility evidence Provide feedback on the prototypes developed -Conduct feasibility analysis on prototype created. Provide evidence to the client that the system will Provide feedback on finally implemented product -Analyzing if the product being developed is going in hand with the feasibility analysis report. Development- Transition Iteration Take inputs and understand how to maintain the developed system. - Verifying the product developed with the feasibility analysis report. -Deliver the product to the test team. LCP_F17a_T07_V1.1 6 Version Date: 10/10/17

12 Name: Alex Miller Role: IIV and V, Website Maintainer strategies and other alternatives. -Familiarize with Django. -Explore Django plugins suitable for the blog feature. current existing system. - Design the bare bone structure for the website. -Zero down the plugin to be used for the blog feature. -Start exploring the plugin. architecture design. -Improve the user interface of the website. -Upload documents satisfy key stakeholder requirements based on the prototype analysis. -Analyze how to integrate Zinnia plugin with the existing product. prototype design. -Upload documents -Start developing the blog feature with required functionalities. initial stages of developed product. -Upload documents developed product. -Upload documents Name: Anitha Neelakantan Role: Software Architect, Software Developer existing system -Familiarize with Django. -Explore Django plugins suitable for the blog feature. - Analyze NDI Interoperability for NDI / NCS project - Assess and evaluate NDI and NCS components -Zero down the plugin to be used for the blog feature. -Start exploring the plugin. - Evaluate progress of each module of the architecture and its ability to be embedded as the project progresses. -Analyze how to integrate Zinnia plugin with the existing product. -Evaluate progress of each module of the architecture and its ability to be embedded as the project progresses. -Start developing the blog feature with required functionalities. - Make sure the software architecture used is well documented. -Deliver the product to the test team. Name: Michael Cappuccio Role: Prototyper, IIV and V -Identify the top risks. current existing -Design the initial prototype. architecture -Make changes to the initial structure of the prototype to meet the required initial stages of developed product developed product. LCP_F17a_T07_V1.1 7 Version Date: 10/10/17

13 system. design. features. prototype design. Name: Nicky Singh Role: Life Cycle Planner, Requirement Engineer -Analyze requirements and plan the project life cycle, and duration of each iteration. -Capture requirements of Scriptonomics project. -Negotiate winconditions with Client. -Plan the initial time line for each task to be performed. -Identify the efforts required for each task. -Verify the architecture design with the desired requirements. -Modify the time line plan designed initially. prototype to verify if the requirements are being satisfied at this point. -Making adjustments to the time lines of the tasks, if required. product under development if requirements for each feature have been met or not. -List the requirements which could be satisfied partially or couldn t be completed. Name: Nikhita Reddy Role: Project Manager, Feasibility Engineer -Schedule weekly team meetings and meetings with client. -Detail Project Plan -Record project progress biweekly. -Perform risk and defect analysis based on requirements and resources available and prioritize the risks. -Explore mitigation - Follow up after win win sessions - Schedule weekly team meetings and meetings with client. -Record project progress biweekly - Discuss with the client about prototype -Schedule weekly meetings -Plan for mitigating risks and debt -Record project progress biweekly. - Discuss with the client about the product implemented. -Schedule weekly meetings -Record project progress biweekly. - Facilitate handover sessions with client -Schedule weekly meetings -Record project progress biweekly. LCP_F17a_T07_V1.1 8 Version Date: 10/10/17

14 strategies and other alternatives. Name: Sri Anusha Veeramachineni Role: Requirement Engineer, Life Cycle Planner -Capture requirements of Scriptonomics project. -Negotiate winconditions with Client. -Analyze requirements and plan the project life cycle, and duration of each iteration. -Verify the architecture design with the desired requirements. -Plan the initial time line for each task to be performed. -Identify the efforts required for each task. prototype to verify if the requirements are being satisfied at this point. -Modify the time line plan designed initially. product under development if requirements for each feature have been met or not. -Making adjustments to the time lines of the tasks, if required. -List the requirements which could be satisfied partially or couldn t be completed. Name: Vaishnavi Venkatraman Role: Operational Concept Engineer, Software Developer -Identify program model. -Familiarize with Django. -Explore Django plugins suitable for the blog feature. - Explore Alternatives -Zero down the plugin to be used for the blog feature. -Start exploring the plugin. -Create Operational Concept -Analyze how to integrate Zinnia plugin with the existing product. created operational concept. -Start developing the blog feature with required functionalities. -Check if the developed system satisfies the operational concept. -Deliver the product to the test team. 3.3 Skills Team members Role Skills Anitha Neelakantan Software Architect Current skills: MS project Java, HTML5, CSS, PHP, JavaScript, Python, MySQL, Bootstrap, Angular.JS, jquery Required skills: Django knowledge LCP_F17a_T07_V1.1 9 Version Date: 10/10/17

15 Nikhita Reddy Gade Project Manager Current skills: MS project Java, HTML5, CSS, PHP, JavaScript, Python, MySQL Required skills: Django knowledge Vaishnavi Venkatraman Operational Concept Engineer Current skills: Java, HTML5, CSS, PHP, JavaScript, C/C++, MySQL, Bootstrap, jquery Required skills: Django knowledge Aditya Holikatti Feasibility Engineer Current skills: MS project Java, HTML5, CSS, PHP, JavaScript, Python, MySQL, Bootstrap, C, C++, C# Required skills: Django knowledge Sri Anusha Veeramachineni Requirements Engineer Current skills: MS project Java, HTML5, CSS, PHP, JavaScript, MySQL, Bootstrap, Angular.JS Required skills: Django knowledge Michael Cappuccio Prototyper Current skills: MS project Java, HTML5, CSS, PHP, JavaScript, Python, MySQL, C, C++ Required skills: Django knowledge, Bootstrap Alex Miller IIV&V Current skills: MS project Java, HTML5, CSS, PHP, JavaScript, Python, MySQL, Bootstrap, C, C++ Required skills: Django knowledge, CSS Nicky Singh Life Cycle Planner Current skills: MS project Java, HTML5, CSS, PHP, JavaScript, Python, MySQL, Bootstrap, C, C++ Required skills: Django knowledge, AJAX LCP_F17a_T07_V Version Date: 10/10/17

16 4. Approach 4.1 Monitoring and Control The core approach we are using for the monitoring and controlling our project progress and making sure it stays on its expected path is: Team meeting: We reevaluate our project plan each week in our team meeting and any additional requirement changes we are coming across our captured in our plan with expected due date. Bi-weekly project plan: We incrementally work on our bi weekly progress report too to identify our possible expected risk and their mitigation plan which team is prepared with in case they are required. Weekly client meetings: Monday meeting with the client to discuss any requirement changes and to show the client the project progress. Jira: Documentation of the work done by the team. Git: Repository to maintain the progress of source code Closed Loop Feedback Control Team meetings: We have team meetings at least twice a week. WhatsApp Messenger: A WhatsApp group was created for communication among the team members. Slack: Various communication channels were created for each discussion, to keep track with the discussion. Trello board: To keep track on the tasks to be accomplished, tasks completed, tasks to be tested etc. Skype: To communicate with the DEN students. important notifications amongst the team and client. Jira: Log work done and the progress of each work Reviews Types of reviews used by the team: Peer review: Weekly team meetings are held to review each team members work done for that week and each member gives his/her feedback and suggestions. Client Meetings: Weekly meetings with the client to get the feedback on the progress of the implementation. Shared folder on Google Drive: All the documents prepared are uploaded on google drive for the team to view and edit changes. LCP_F17a_T07_V Version Date: 10/10/17

17 4.2 Methods, Tools and Facilities Tools Usage Provider MS Project Bi-weekly reports and project documents Microsoft, USC Winbook Capture win conditions and prioritize them USC Slack Discuss project related issue, schedule team meeting and Slack share documents Project Store main information about project, and keep all the USC Website documents. Visual paradigm UML Diagram, Work Flow Visual paradigm Bootstrap Used to design better UI for the website Open Source Github A version control system Github Proto.io Used to create project prototype design Proto.io Zinnia Used to create the blog Django Jira To log time and effort spent on each task of the project by different members of the team USC LCP_F17a_T07_V Version Date: 10/10/17

18 5. Resources Below is the required information to estimate the software cost of our overall project: Estimated CSCI577a Effort: 8 team members at 16 hrs/week for 12 weeks Total estimated effort: 16 hrs/week x 8 members x 12 weeks = 1536 hours Budget information: $ 0 Project duration: 12 weeks Component modules in your development project: User Template, Admin Template Programming language/ Tools used: Zinnia, Bootstrap., HTML, CSS Table 3: COCOMOII Scale Driver -Template Scale Driver Value Rationale Precedentedness Low Team members don t not have previous experience or (PREC) knowledge about Django, zinnia and their integration and Development Flexibility (FLEX) Architecture/Risk Resolutions (RESL) Team Cohesion (TEAM) Process Maturity (PMAT) Medium High Low Nominal use, hence lack of domain knowledge. Project requirements are open to team s suggestion and client is flexible and accept team s input if they help in getting better results. Team s initial major risk was lack of domain knowledge with the use Django and COTS integration for blog page development. Teams approach to mitigate both of mentioned risk was to Buying information and conducting informal prototyping. Team has scheduled weekly meetings for project progress discussion and to discuss on risks and their mitigation plan, but is experiencing difficult in keeping up with it. Team use slack as main source of offline communication. Team approach for the overall project is icsm guidelines and team is very consistent with its use. LCP_F17a_T07_V Version Date: 10/10/17

19 Figure 1: Scale Factors-Template Table 4: COCOMOII Cost Driver - Template Cost Driver Value Rationale Rely High This is one of the core module of overall project, as it provides the skeleton for blog page users DATA Low This require more testing because client require intuitive UI and this is only achieved through lot of feedback and testing with critical stakeholders. CPLX Medium This module has a medium complexity as it requires understanding of zinnia and creating program with it. RUSE High This module has high reusability as a basic template for user, admin or any other persona remain same. DOCU Medium For project we will only need to document the changes and development that we are doing with zinnia. TIME High This value is high because it s first time for team to use this plugin so getting accustomed to it, needs time plus client expect high rate of progress. STOR Low Storage constraint for project is limited to kbs for now. PVOL Low Project doesn t include any complex hardware and software platform ACAP High Team has good understanding of customers requirement and expectation PCAP High Developers have good experience with bootstrap but needed to work on their understanding of Django and its plugin which is critical in nature. APEX Low Few people in team have not much experience with bootstrap PLEX Nominal Platforms required for this module development are not much complexed or advanced. LCP_F17a_T07_V Version Date: 10/10/17

20 LTEX Low Team have not worked before with Django and zinnia PCON Nominal Team members with maintainer responsibility will need to be regular with information updates. TOOL High Module need to be integrated with underlying blog functionality. SITE Medium All developers working on this module are located locally. Figure 2: EAF- Template Table 5: COCOMOII Scale Driver - User side functionality Scale Driver Value Rationale Precedentedness (PREC) Low Lack of domain knowledge of Django causes this value to be low for our team. Development Flexibility (FLEX) Medium Client is flexible to accept teams input for development method. Architecture/Risk Resolutions (RESL) Medium Team s initial major risk was lack of domain knowledge with the use Django development. Teams approach to mitigate both of mentioned risk was to Buying information and conducting informal prototyping. LCP_F17a_T07_V Version Date: 10/10/17

21 Team Cohesion (TEAM) Process Maturity (PMAT) Low Medium Team has scheduled meeting setup but is struggling to stick to the schedule Team is consistent with use of ICSM guidelines. Figure 3: Scale Factors- User side functionality Table 6: COCOMOII Cost Driver - User side functionality Cost Driver Value Rationale Rely High It s a core module to provide all user side functionality with blog page. DATA Low This module requires large amount of testing to ensure all user specific features are delivered and are functioning as expected. CPLX High The team is in between evaluating the cots and tools we can use in integration with Django to create this module. RUSE Medium This module has medium reusability because its development is specific to user functionality requirement. DOCU Medium For project, we will only need to document the development that we will be doing with Django and other cots. TIME High This value is high because it s first time for team to use this plugin so getting accustomed to it, needs time plus client expect high rate of progress. STOR Medium Storage constraint for project is limited to mbs for now. PVOL Low Project doesn t include any complex hardware and software platform ACAP High Team has good understanding of user functionality requirements. LCP_F17a_T07_V Version Date: 10/10/17

22 PCAP High Developers have good experience with bootstrap but needed to work on their understanding of Django. APEX Low Few people in team have not much experience with bootstrap PLEX Nominal Platforms required for this module development are not much complexed or advanced. LTEX Low Team have not worked before with Django. PCON Medium Team members with maintainer responsibility will need to be regular with information updates for user functionalities. TOOL High Module need to be integrated with underlying blog functionality. SITE Medium All developers working on this module are located locally. Figure 4: EAF- user-side fun Table 7: COCOMOII Scale Driver - Admin side functionality Scale Driver Value Rationale Precedentedness (PREC) Low Lack of domain knowledge of Django causes this value to be low for our team. Development High Development flexibility for admin side functionality LCP_F17a_T07_V Version Date: 10/10/17

23 Flexibility (FLEX) Architecture/Risk Resolutions (RESL) Team Cohesion (TEAM) Process Maturity (PMAT) Medium Low Medium module is very limited for team. Buying information and conducting informal prototyping would be our prime action as Team s initial major risk was lack of domain knowledge with the use Django. Team has scheduled meeting setup but is struggling to stick to the schedule Team is consistent with use of ICSM guidelines for following process. Figure 5: Scale Factors- Admin side functionality Table 8: COCOMOII Cost Driver - Admin side functionality Cost Driver Value Rationale Rely High It s a core module to provide all admin side functionality with blog page, including functionality like publishing, removing post etc. DATA Low This module requires large amount of testing to ensure all user specific features are delivered and are functioning as expected. CPLX High The team is in between evaluating the cots and tools we can use in integration with Django to create this module. RUSE Low This module has low reusability because admin is a single type persona and functionality specific to it won t be much of user to any other user persona we might have to add in later stage. DOCU Medium For project, we will only need to document the development that we will be doing with Django and other cots. TIME High This value is high because it s first time for team to use this plugin so getting accustomed to it, needs time plus LCP_F17a_T07_V Version Date: 10/10/17

24 client expect high rate of progress. STOR Low Storage constraint for project is limited to kbs for now. PVOL Low Project doesn t include any complex hardware and software platform ACAP High Team has good understanding of Admin functionality requirements, and they are set in goals and are not susceptible to frequent changes. PCAP High Developers have good experience with bootstrap but needed to work on their understanding of Django. APEX Low Few people in team have not much experience with bootstrap PLEX Nominal Platforms required for this module development are not much complexed or advanced. LTEX Low Team have not worked before with Django. PCON Low Team members with maintainer responsibility will need not to update information for admin functionalities regularly. TOOL High Module need to be integrated with underlying blog functionality. SITE Medium All developers working on this module are located locally. Figure 6: EAF- Admin-side fun LCP_F17a_T07_V Version Date: 10/10/17

25 6. Iteration Plan 6.1 Plan << Provide a high-level overview of the content of the given iteration. Indicate which Life cycle milestones will be addressed. >> Capabilities to be implemented << For the milestone identified above, identify the capabilities that will be implemented in the upcoming iteration. Identify the features, requirements or use cases that are being developed (implemented, tested, etc.) for this iteration. Each component should be accounted for in at least one iteration. All requirements should be implemented and tested (or re-negotiated) by the completion of all the iterations. Be mindful of implementation dependencies. Document complex dependencies and communicate them to the appropriate development staff. >> Table 5: Construction iteration capabilities to be implemented ID Capability Description Priority Iteration < ID > < Capability > < comments > <value> <value> Capabilities to be tested << For the milestone identified above, identify the capabilities that will be tested in the upcoming iteration. Identify the software features and combinations of software features to be tested this iteration. This may also include non-functional requirements or extra-functional requirements, such as performance, portability, and so forth. Additionally you may need to test every requirement listed in the WinWin Agreements DC package, non-requirement component features such as COTS capabilities and quality, API functionality, etc. >> Table 6: Construction iteration capabilities to be tested ID Capability Description Priority Iteration < ID > < Capability > < comments > <value> <value> LCP_F17a_T07_V Version Date: 10/10/17

26 6.1.3 Capabilities not to be tested << Identify notable features, and significant combinations of features, which will not be tested this iteration and why (e.g. a given feature uses a feature which will be implemented in following iteration). >> CCD Preparation Plans << Identify the clients and other users who will be involved in the Core Capability Drivethrough, the usage scenarios that it will support, and the specific CCD preparation plans and milestones. These may include - user context-setting - site preparation dry runs, - feedback forms, and - CCD risk management plans. >> 6.2 Iteration Assessment Capabilities Implemented, Tested, and Results << Describes, in brief, the capabilities that were implemented and the test results. The capabilities implemented and tested do not necessarily need to match the ones listed in section 6.1 because some capabilities may have been pushed to the next iteration. >> Table 7: Capabilities implemented, tested, and results ID Capability Test Case Test Results If fail, why? < ID > < Capability > < TC-XX > Pass/Fail < comments > Core Capabilities Drive-Through Results << Briefly summarize the feedback you received from your client(s). You need to be specific enough to cover the critical capabilities or scenarios that were discussed, demoed, or shown. Your descriptions MUST, but not limited to, cover the following areas: Positive feedbacks Improvements needed/suggested Changes to be considered (Reprioritized capabilities, requirements, GUI, etc.) Risks (New risks introduced, risks mitigated, etc.) Note: Make sure to be specific to the capabilities shown/demonstrated/driven-through. Simply stating that the clients liked the capabilities is not sufficient. >> LCP_F17a_T07_V Version Date: 10/10/17

27 6.3 Adherence to Plan << Describe how well the iteration ran according to plan. Was it on budget and on time? Is there any uncertainty in the Software Development Status? Provide some insight to avoid mistakes for future iterations. >> LCP_F17a_T07_V Version Date: 10/10/17