Project Management and Testing Resource Plan Resource Plan Phases - PDF document

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

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 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

Feasibility Phase 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 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! Resource Plan Actors Project Portfolio Milestones! Use Cases Use Case Diagrams Storyboards - Activities Requirements Specification Black Box Functional - Deliverables Requirements Specification Diagrams: - Class - Resources System System - Sequence Test Design - Statechart - Activity - Responsibles Test Plan Design Patterns Test Cases System System System Design Development Validation - Dates Notes and Details Signatures Design Patterns 4

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

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

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

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

Cyclic, Incremental or Evolutionary Planning 1 1 1 1 1 1 Week 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 Cycle 1 Delivery Milestones Cycle 2 Cycle 3 1. strategy 2. plan 3. requirements 4. design Iteration 1 5. implementation 6. test 7. postmortem Iteration 2 1. strategy… 1. strategy… Iteration 3 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

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

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

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

Delegation Not Urgent Urgent Delegate Do it youself! and Important follow up! Not Delegate Ignore? Important 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

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, 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 • Remember that your investor is willing to invest 5 amount of manhours (1 manyear is 1800 manhours). ”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 • Each main project activity should have a number of already spent on your initial project portfolio...). staff members allocated to the activity, with one How you plan to use the resources is up to you, but team or activity leader. should be described in your resource plan. • You will propable find that some staff members • There are licenses of Microsoft Project, which you will need to double in some functions or work with may use to produce Gantt charts etc if you so more than one activity. This means that you need to prefer. You can also use Microsoft PowerPoint or plan the work so that a staff member will not be any general purpose software to do plans allocated too much or too less. graphically. • Milestones etc should be visible in the plan. • Keep It Simple! :-) Testing... 15

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

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 HL LL Code Req Design Design Test Test Test Test Cases Cases Cases Cases Test Plan 17