Project Management and Testing

Size: px

Start display at page:

Download "Project Management and Testing"

Hortense Pearson
5 years ago
Views:

1 Project Management and Testing Resource Plan Resource Plan Phases and Milestones Activities and Deliverables Budget and Resources 1

2 Project Plan Project Plan Introduction - Goal Organization Phases and Milestones Activities and Deliverables Budget and Resources Releases Risk Project Portfolio Project Portfolio Project Plan Resource Plan System Requirements System Design System Test Plan Quality Plan Configuration Management 2

PROPS supporting operative managing Prestudy Phase q Tollgate (TG0) decision to start prestudy q Requirement engineering q Interviews of customer and/or

3 PROPS supporting operative managing Prestudy Phase q Tollgate (TG0) decision to start prestudy q Requirement engineering q Interviews of customer and/or product management q Analysis q Business case analysis q Customers q Competitors q Costs q Benefits q Risks q Results in an assignment for a feasibility study q TG1 3

q Tollgate (TG1) decision to start feasibility study q Requirement engineering q User-interface prototyping, specification, use cases, etc q System design q Anathomy, architecture, Implementation

Life-cycle model (prototyping, evolutionary, waterfall, etc) q Results in an assignment for an implementation project q TG2 We need to manage the artifacts!

4 q Tollgate (TG1) decision to start feasibility study q Requirement engineering q User-interface prototyping, specification, use cases, etc q System design q Anathomy, architecture, Implementation Proposals q Simulations using tools or role play q Project planning q Risk analysis q Estimation of size, effort, cost and schedule Feasibility Phase q Resources, competence, organization, etc q Life-cycle model (prototyping, evolutionary, waterfall, etc) q Results in an assignment for an implementation project q TG2 We need to manage the artifacts! Black Box Requirements System Validation Resource Plan Project Portfolio Milestones! - Activities - Deliverables System - Resources Test Actors Use Cases Use Case Diagrams Storyboards Requirements Specification Functional Specification Test Plan - Responsibles Test Cases - Dates System Development Notes and Details Signatures Design Patterns System Design Diagrams: - Class - Sequence - Statechart - Activity Design Patterns System Design 4

5 Builds Relationship Between Use Cases, Iterations and Builds Iteration 5 build 5.3 Use case 14 Use case 23 5

6 Relationship between Use Cases, Iterations and Builds 4 Iteration 5 6 Use case 7 * 5.2 build * Use case 9 * Use case 14 Use case 23 * «extends» or «includes» Final Code Build and Integration Schedule: a Banking Example baseline week 23 weekly code builds biweekly daily week 31 release 6

7 Plan evolutionary increments of the baseline! baseline week 23 weekly code builds biweekly daily week 31 Module 1 release activity task Module 2 Module 3 Integration of module into baseline Final Code Build and Integration Schedule: a Banking Example baseline week 23 weekly code builds biweekly daily week 31 tasks bank query module bank deposit module Integration of module into baseline release bank withdrawal module 7

8 Typical Day-by-Day Code Integration Process Run regression tests development 6 pm 7 am development time Confirm baseline or Freeze development revert to previous baseline weekly builds biweekly daily week 23 week 24 week 25 week 26 week 27 week 28 week 29 week 30 week 31 = overnight regression test release Resource Planning Milestones Requirements Design Risk Analysis Month 1 Month 2 Month 3 Month 4 Month Freeze requirements Karen vacation Complete testing Release to production Hal vacation To be assigned Given team size:

9 Cyclic, Incremental or Evolutionary Planning Week Milestones Iteration 1 Iteration 2 Iteration Cycle 1 Delivery Cycle 2 Cycle 3 1. strategy 2. plan 3. requirements 4. design 5. implementation 6. test 7. postmortem 1 1. strategy strategy The Variables of Project Management 1. The total cost of the project, e.g., increase expenditures 2. The capabilities of the product, e.g., subtract from a list of features 3. The quality of the product, e.g., increase the mean time between failure 4. The date on which the job is completed. e.g., reduce the schedule by 20% e.g., postpone project's completion date one month 9

10 The Window of Opportunity Quality Projekt Functionality Schedule Cost On time, within budget and meet requirements! Bullseye Figure for Project Variables Target: 100% cost Target : $70K capability duration Target : 4 defects/kloc defect density Target : 30 wks 10

11 Bullseye Figure for Project Variables Target: 100% Actual: 100% capability Target : 4 defects/kloc Actual: 1 defect/kloc cost this project defect density Target : $70K Actual: $90K duration Target : 30 wks Actual: 20 wks Coding versus Documenting 11

12 Urgent versus Important Triage in Project Management Among top items in importance? if so, place it in do at once category otherwise Ignore without substantially affecting project? if so, place it in last to do category otherwise (Do not spend decision time on this) place in middle category 12

13 Delegation Urgent Not Urgent Important Do it youself! Delegate and follow up! Not Important Delegate Ignore? Look after your own interests - but be a team player. You are a valuable resource in the company, and sometimes it is important to delegate tasks. However, don't delegate things that you find urgent and important - make sure you take responsibility and show initiative. However, protect yourself from small annoying tasks, unless you are told explicitly to leave other important tasks to focus on it. Even if we might not like it there is an hierarchy at work and you are studying a higher education and will be highly qualified (and well paid) and I'm guessing you will have trainees or other subordinates that are less paid and who can take on things you don't want to do. 13

14 If you are currently having a full workload (40 hours / week) don't accept additional work without letting the person know that this will delay your other projects. Make sure that your boss is alright with the delay and added cost before accepting a task. There is no shame in admitting that you are already working 100%. Swedish companies today actually try to avoid having people work overtime, at least in the IT sector. The reason is that a person in sick-leave is of no use for the development, it's better to keep developers healthy and happy. That's also why they will ask you about your leisure activities in a job interview - they want to know that you have a way to relieve stress etc. after work so that you can remain healthy at work. More on Project Management Project in Software Enginnering Or, most of the other 4th year projects! Dedicated Project Management courses at IES etc. Read them! 14

Assignment 6 Resource Plan The resource plan should include information on which main project phases and activities that are planned (further requirements analysis, software architecture design,

Each main project activity should have a start and stop date (it's ok to say 'month1' or 'day30' instead of a real date, it may actually be preferable).

Each main project activity should have a number of staff members allocated to the activity, with one team or activity leader.

15 Assignment 6 Resource Plan The resource plan should include information on which main project phases and activities that are planned (further requirements analysis, software architecture design, testing, etc) for the rest of the project and the amount of resources that are planned for each activity. It should also be expressed when these activies are planned to be active. Each main project activity should have a start and stop date (it's ok to say 'month1' or 'day30' instead of a real date, it may actually be preferable). Each main project activity should have a planned amount of manhours (1 manyear is 1800 manhours). Each main project activity should have a number of staff members allocated to the activity, with one team or activity leader. You will propable find that some staff members will need to double in some functions or work with more than one activity. This means that you need to plan the work so that a staff member will not be allocated too much or too less. Milestones etc should be visible in the plan. Remember that your investor is willing to invest 5 manyears in the development of the company s first system, so the plan should not exceed that ammount of work (note that 5 manmonths are already spent on your initial project portfolio...). How you plan to use the resources is up to you, but should be described in your resource plan. There are licenses of Microsoft Project, which you may use to produce Gantt charts etc if you so prefer. You can also use Microsoft PowerPoint or any general purpose software to do plans graphically. Keep It Simple! :-) Testing... 15

16 Now Testing! Unit Testing Black Box Testing White Box Testing Test Coverage Integration Testing System Testing Development Overview Requirements Architecture loss loss loss of information loss Customer Detailed design loss Function code Interface specs loss OK? Module (e.g., package) code System code 16

17 Golden Rules of Testing Goal of testing: maximize the number and severity of defects found per dollar spent thus: test early Limits of testing: Testing can only determine the presence of defects, never their absence use proofs of correctness to establish absence Testing 1h 8h 80h 800h $ Sys Req HL Design LL Design Code Test Cases Test Cases Test Cases Test Cases Test Plan 17

18 Artifacts and Roles for Integration Testing Test engineer Component engineer Integration System tester tester responsible for Use-case model Test plan Test case Test procedure Test evaluation Test component r Defect management Testing: The Big Picture 3. System tests 2. Integration tests 1. Unit tests Module combination Module Function Use-cases & System Functions Packages of classes Combinations of methods in class Methods 18

19 Unified Process Inception Elaboration Construction Transition Requirements Analysis Design Implementation Test Unit tests Integration tests System tests Prelim. iterations Iter. #1 Iter. #n Iter. #n+1.. Iter. #m Iter. #m+1.. Iter. #k Black-box Testing Input determined by... requirements Black box Result Actual output compared with required 19

20 White-box Testing Input determined by... Result design elements White box Confirmation of expected behavior Input determined by... requirements requirements & key design elements Black box Gray box Black-, Gray-, & White-box Testing Result Actual output compared with required output As for blackand white box testing design elements White box Confirmation of expected behavior 20

21 Covering Every Statement is Not Sufficient Required program Code attempt to implement flowchart u>1 and v==0 No Yes x = x/u if ( (u>1) && (v==0) ) (1) x = x/u; (2) if ( (u==2) (x>3) ) (3) ++x; (4) u==2 or x>0 No Yes ++x u=2, v=0 and x=3 executes every line (1) - (4) gives the correct output x= 2.5 However, line (3) is wrong Testing Ranges: Elementary Cases 1. within range 2. at the boundaries of the range 3. outside the range ( illegal ) range Minimize what you need to test or you will never stop testing! 21

22 Perform Method Testing 1/2 1. Verify operation at normal parameter values (a black box test based on the unit s requirements) 2. Verify operation at limit parameter values (black box) 3. Verify operation outside parameter values (black box) 4. Ensure that all instructions execute (statement coverage) 5. Check all paths, including both sides of all branches (decision coverage) 6. Check the use of all called objects 7. Verify the handling of all data structures 8. Verify the handling of all files Perform Method Testing 2/2 9. Check normal termination of all loops (part of a correctness proof) 10. Check abnormal termination of all loops 11. Check normal termination of all recursions 12. Check abnormal termination of all recursions 13. Verify the handling of all error conditions 14. Check timing and synchronization 15. Verify all hardware dependencies 22

23 Volume Subject product to large amounts of input. Usability Measure user reaction (e.g., score 1-10). Performance Measure speed under various circumstances. Configuration Configure to various hardware / software e.g., measure set-up time. Compatibility -- with other designated applications e.g., measure adaptation time. Reliability / Availability Measure up-time over extended period. Types of System Tests 1 Security Subject to compromise attempts. e.g., measure average time to break in. Resource usage Measure usage of RAM and disk space etc. Install-abililty Install under various circumstances. measure time to install. Recoverability Force activities that take the application down. measure time to recover Serviceabililty Service application under various situations. measure time to service Load / Stress Subject to extreme data & event traffic Types of System Tests 2 23

24 Key Attributes for Usability Testing Accessibility How easily can users enter, navigate & exit? e.g., measure by average time taken to... Responsiveness How quickly does the application allow the user to accomplish specified goals? e.g., measure by average time taken Efficiency Degree to which the number of required steps for selected functionality is minimal minimal deduced in theory e.g., measure by minimal time / average time Comprehensibility How easy is the product to understand and use with documentation and help? e.g., measure time taken for standard queries Alpha- and Beta- Releases Alpha Beta In-house and highly trusted users Multiplies testing Previews customer reaction Benefits third-party developers Forestalls competition Selected customers Multiplies testing activity Gets customer reaction 24

25 Roadmap for the Transition Iterations 1. Plan alpha and beta testing. Define population Plan defect collection Identify stopping criteria 2. Conduct alpha testing. 3. Conduct beta testing. Prepare Distribute & install Carry out (users / customers) Gather defect reports Observe stopping criteria Correct defects Stopping Criteria Completing a particular test methodology Complete the procedures of a method or tool. Estimated percent coverage for each category predetermine percent of each & how to calculate e.g., 95% statement coverage Error detection rate predetermine rate with given severity level e.g., 2 medium severity defects or less per 100 hours of operation Total number of errors found (if possible) computed from a percentage of remaining defects predetermine percent e.g., 95% of estimated existing defects found 25

26 Stopping Criteria: Graphical Representation Percentage tested or found % Target: 95% time Stopping Criteria: Graphical Representation Errors found per 1000 hrs Error detection rate time Target: <= 7 per1000 hrs for 4 weeks 26

27 ANSI/IEEE Software Test Documentation 1. Introduction 2. Test plan items under test, scope, approach, resources, schedule, personnel 3. Test design items to be tested, the approach, the plan in detail 4. Test cases sets of inputs and events 5. Test procedures steps for setting up and executing the test cases 6. Test item transmittal report items under test, physical location of results, person responsible for transmitting 7. Test log chronological record, physical location of test, tester name 8. Test incident report documentation of any event occurring during testing which requires further investigation 9. Test summary report summarizes the above This is how far you will go in D7025E! 27

28 Project Portfolio Project Portfolio Project Plan Resource Plan System Requirements System Design System Test Plan Quality Plan Configuration Management Quiz #2 Next Quiz will be on Friday 27/9 Will cover lecture 6 to 9 (Design patterns and Project Management). 28

29 Cancelled 23/9, 30/9, 9/10, 18/10 Added Software Testing (27/9) Cancelled/added lectures User Interaction Design and Rapid Prototyping (2/10) Top Tips summary and Presentation Techniques (11/10 That s all folks! Thanks for your attention! 29

30 Range of Errors in Estimating Eventual Cost $4 Range of cost estimates after conceptualization phase, based on actual cost of $1 Conceptualization phase $1 25c Range of cost estimates after requirements analysis phase Requirements analysis $1 Design $1 Implementation $1 Integration/Test $1 30

1. Can you explain the PDCA cycle and where testing fits in?

1. Can you explain the PDCA cycle and where testing fits in? Software testing is an important part of the software development process. In normal software development there are four important steps, also