1 Phase Implementation and Test Plan

Making your implementation plan First Steps  Consider your use case diagram and your prioritization of use cases from your design document (checked against provided list)  Use the prioritization (and provided list) to decide the priority or priorities of each use case  Modify your use case diagram to show your priorities. Janice Regan,

3 LMS partial use case diagram  Order based on importance of each use case as expressed by the user/client Calculate overdue fee Library staff Generate overdue letter …. browseResource reserveResource manageResource checkInResource checkOutResource resource patron managePatron Overdue form letter Phase 4 Phase 1 Phase 2 Phase 3

 Consider your time constraints, Decide which phases will be completed for each presentation date  Iteration 1 Client Demonstration (July 21)  20 minutes, prepare your system before meeting  Iteration 2 Client Demonstration (July 30 )  20 minutes, prepare your system before meeting  User Acceptance Test (Aug. 5-7)  60 minutes, install from code during meeting Janice Regan, Making your implementation plan Next schedule each phase

 Consider your time constraints,  Consider dates, July 21, July 30, Aug 5-7  You will be told which phases to present at each meeting,  Leave time to be sure you have fully tested the components for a phase before the meeting.  You may develop more than is needed for the presentation meeting (particularly the first two meetings) before the meeting but present only what is promised)  The system you present should be stable, it is better to miss a deadline on one promised feature than to present an unstable system. Janice Regan, Making your implementation plan Considerations in scheduling

 Divide you group into implementation phase subgroups  Divide into pairs (or a single or triple if you have an odd number of members)  Decide which use cases / classes will be developed by each pair in each phase of development.  Decide how much time to allow for each part of the implementation process, for each of the use cases / classes or groups of use cases /classes (within the duration of each phase) Janice Regan, Making a schedule: First steps

Important parts of implementation  Create implementation test plan  Create unit test plan  Implement  Code inspection  Unit testing  Integration test plan  Integration into system  Integration testing  Create System test plan  System testing  User acceptance testing (UAT for your project) Janice Regan,

8 For each group of units Overview of Implementation phase Create Class Skeletons Define Implementation Plan (+ determine subphases) Define Coding Standards For each unit Implement Methods in class/es Code review Unit test Create integration Test plan Create unit Test plans Release unit for integration Integration Testing System Testing Create system Test plan

Janice Regan, Planning using Gantt chart  The Gantt chart in the next slide illustrates the following items that you should include in a project schedule GANTT chart  Milestones:  Due dates of deliverables  Dates of important meetings (UAT, Client Meeting …)  Phases  Start and end date of each phase  Tasks (sub phases, activities)  Start and end date of each task  Tasks on critical path highlighted

Janice Regan, Project Schedule – An Example MICROSOFT PROJECT CAN BE USED TO MAKE A GANTT CHART

Janice Regan, On your Gantt chart also include  The Gantt chart in the next slide illustrates the following additional items that should be included in a project schedule GANTT chart  Tasks (activities)  Names of resources (team members) responsible for each task  Percentage of available time of resource on each task (when a resource is assigned to more than 1 task at a time)  Dependencies between tasks (does task A need to be finished before task B starts)

Janice Regan, Project Schedule – Another Example

Janice Regan, Updates to your Gantt chart  At the end of each phase of the project the Gantt chart should be updated to reflect the details of the next phase.  Some tasks may be unfinished and need to be added to the next phase  Some tasks may be finished early and need to be moved back from the next phase

Janice Regan, LMS partial use case diagram  Order based on importance of each use case as expressed by the user/client Calculate overdue fee Library staff Generate overdue letter …. browseResource reserveResource manageResource checkInResource checkOutResource resource patron managePatron Overdue form letter Phase 4 Phase 1 Phase 2 Phase 3

Janice Regan, LMS Example:  Make the test plan for first phase (or group of phases)  Implement the use cases or parts of use cases in the first phase (or group of phases)  Each pairs use cases/classes may be consider a unit  Complete code reviews of the written code, code should be reviewed by a different pair (not the pair that wrote it)  Unit test the code (run and test)  Once each unit is unit tested, integrate all units into build 1 (the build containing all use cases or parts of used cases in the first phase)  Build 1 can be tested (integration testing) by performing the checkInResource use case (function) and the checkOutResource use cases  Build 1 may be presented to the client

Janice Regan, LMS partial use case diagram  Order based on importance of each use case as expressed by the user/client Calculate overdue fee Library staff Generate overdue letter …. browseResource reserveResource manageResource checkInResource checkOutResource resource patron managePatron Overdue form letter Phase 4 Phase 1 Phase 2 Phase 3

Janice Regan, LMS Example: Phase 2 You need to consider if the parts of the classes being implemented in phase 2 are substantially independent of those implemented in phase 1  CASE A: If they are substantially different  You can produce build 2 by integrating all units developed during phase 2.  Build 2 can be developed at the same time as build 1.  When build 1 and build 2 have been individually integration tested they can be integrated together into build 3 and integration tested.

Janice Regan, LMS Example: Thread phase 2  Make the test plan for 2 nd phase (or 2 nd group of phases)  Implement the use cases or parts of use cases in the 2 nd phase (or 2 nd group of phases)  Each pairs use cases/classes may be consider a unit  Complete code reviews of the written code, code should be reviewed by a different pair (not the pair that wrote it)  Unit test the code (run and test)  Once each unit is unit tested, integrate all units into build 2 (the build containing all use cases or parts of used cases in the 2 nd phase or 2 nd group of phases)  Build 2 can be tested (integration testing) by performing the manageResource use case (function)  Build 2 can be presented to the client

Janice Regan, LMS Example: Alternate approach You need to consider if the parts of the classes being implemented in thread 2 are substantially independent of those implemented in thread 1  CASE B: If they have many interdependent components  It may be more efficient to modify build 1 by sequentially integrating the partial classes (units) produced in thread 2 into build 1.  When all units for thread two have been integrated you have produced build 2.

Janice Regan, LMS Example: Phase 2  For this case use cases in phase 2 are strongly related (coupled) to the use cases in phase 1  Many parts of phase 2 use or depend on code developed in phase 1  The phase 1 code will be used as a basis for developing the phase 2 code  Therefore development of phase 2 follows development of phase 1, they cannot be developed simultaneously  Make the test plan for 2 nd phase (or 2 nd group of phases)  Implement the use cases or parts of use cases in the 2 nd phase (or 2 nd group of phases)  Each pairs use cases/classes may be consider a unit  Units are added to phase 1 code after unit testing

Janice Regan, LMS Example: Phase 2  Complete code reviews of the written code  Again code should be reviewed by another pair before testing begins  Unit test the code (run and test)  Once each unit is unit tested, integrate all units (one unit at a time) into build 1  Intermediate builds (1.1, 1.2 …) are produced each time a new unit is integrated into the previous intermediate build. Integration testing is done at each step  Build 2 can be tested (system testing) by performing the manageResource use case (function) the checkInResource use case (function) and the checkOutResource use cases  Build 2 can be presented to the client