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
1
Phases and Milestones Budget and Resources
Resource Plan
Activities and Deliverables
2
Introduction - Goal Organization Phases and Milestones Budget and Resources Risk Releases
Project Plan
Activities and Deliverables Project Plan System Requirements System Design Quality Plan Resource Plan Configuration Management
Project Portfolio
System Test Plan
…
3
managing
supporting
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
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 q Resources, competence, organization, etc q Life-cycle model (prototyping, evolutionary, waterfall, etc) q Results in an assignment for an implementation project
q TG2
Black Box Requirements System Design System Development System Test System Validation Functional Specification
Actors Use Cases Use Case Diagrams Storyboards Requirements Specification Test Plan Test Cases Diagrams:
Design Patterns System Design Notes and Details Signatures Design Patterns
Resource Plan Project Portfolio
5
Builds Relationship Between Use Cases, Iterations and Builds
6
Relationship between Use Cases, Iterations and Builds
*
* * «extends» or «includes» *
Final Code Build and Integration Schedule: a Banking Example week 31 week 23
release baseline
7
week 31 week 23
release Module 1 Module 2 Module 3 Integration
into baseline baseline
activity task
Final Code Build and Integration Schedule: a Banking Example week 31 week 23
release bank query module bank deposit module bank withdrawal module Integration
into baseline tasks baseline
8
Typical Day-by-Day Code Integration Process
week 25 week 26 week 27 week 28 week 29 week 30 week 31 week 24 week 23
release = overnight regression test development 6 pm 7 am Run regression tests time development Freeze development Confirm baseline or revert to previous baseline
Month 1 1 2 3 4 Month 2 1 2 3 4 Month 3 1 2 3 4 Month 4 1 2 3 4 Month 5 1 2 3 4 Milestones
Release to production Complete testing
Requirements Design
Freeze requirements
Risk Analysis 2 2 2 3 2 2 4 2 2 2 1 1 1 4 4 4 3 3 4 4 4 4 4 3 3 4 4 4 4 4 3 3 4 4 4 4 4 4 4 4 4 4 4 4 4 Given team size:
To be assigned
4
Hal vacation Karen vacation
9
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
Milestones Delivery
Iteration 1 Iteration 2
Cycle 1 Week 1 Cycle 2 Cycle 3 1 1 1 1 1 Iteration 3
10
Projekt Schedule Cost Quality Functionality
On time, within budget and meet requirements!
11
12
13
Do it youself! Delegate Ignore? Delegate and follow up! Important Not Important Not Urgent Urgent 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
unless you are told explicitly to leave other important tasks to focus
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.
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
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.
15
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.
stop date (it's ok to say 'month1' or 'day30' instead
amount of manhours (1 manyear is 1800 manhours).
staff members allocated to the activity, with one team or activity leader.
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.
”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.
may use to produce Gantt charts etc if you so
any general purpose software to do plans graphically.
16
loss
Development Overview Requirements Architecture System code
loss loss loss of information
Interface specs Detailed design Function code Module (e.g., package) code
loss loss
Customer OK?
17
Golden Rules of Testing
Test Plan
Sys Req HL Design LL Design Code Test Cases Test Cases Test Cases Test Cases 1h 800h 80h 8h
18
Artifacts and Roles for Integration Testing
Test engineer Component engineer Integration tester System tester Use-case model Test case Test procedure Test evaluation Test plan Test component
. . . . . . . . . . . . . . . . . . responsible for . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defect management
Testing: The Big Picture Methods Combinations of methods in class Packages
Use-cases & System Functions
Function Module Module combination 2. Integration tests 3. System tests 1. Unit tests
19
Elaboration
Unified Process
Inception Construction Transition Requirements Analysis Design Implemen- tation Test
Prelim. iterations Iter. #m Iter. #m+1 Integration tests Iter. #1 Iter. #n Iter. #n+1 …..
Unit tests
Iter. #k ….. System tests
Black-box Testing Black box … requirements Actual output compared with required
20
White-box Testing
White box …design elements Confirmation
behavior Black-, Gray-, & White-box Testing Black box … requirements Actual output compared with required output White box Gray box … requirements & key design elements
Input determined by...
Result
…design elements Confirmation
behavior As for black- and white box testing
21
Covering Every Statement is Not Sufficient u>1 and v==0 x = x/u u==2 or x>0 ++x No Yes Code attempt to implement flowchart if ( (u>1) && (v==0) ) (1) x = x/u; (2) if ( (u==2) || (x>3) ) (3) ++x; (4) u=2, v=0 and x=3
However, line (3) is wrong No Yes Required program Testing Ranges: Elementary Cases
(“illegal”)
Minimize what you need to test
22
Perform Method Testing 1/2
(a black box test based on the unit’s requirements)
(black box)
(black box)
(statement coverage)
(decision coverage)
Perform Method Testing 2/2
23
Subject product to large amounts of input.
Measure user reaction (e.g., score 1-10).
Measure speed under various circumstances.
Configure to various hardware / software
e.g., measure set-up time.
e.g., measure adaptation time.
Measure up-time over extended period. Types of System Tests 1
Subject to compromise attempts.
Measure usage of RAM and disk space etc.
Install under various circumstances.
Force activities that take the application down.
Service application under various situations.
Subject to extreme data & event traffic Types of System Tests 2
24
Key Attributes for Usability Testing
How easily can users enter, navigate & exit?
How quickly does the application allow the user to accomplish specified goals?
Degree to which the number of required steps for selected functionality is minimal
How easy is the product to understand and use with documentation and help?
Alpha- and Beta- Releases
Alpha Beta
25
Roadmap for the Transition Iterations
– Complete the procedures of a method or tool.
– predetermine percent of each & how to calculate – e.g., “95% statement coverage”
– predetermine rate with given severity level – e.g., “2 medium severity defects or less per 100 hours of
– (if possible) computed from a percentage of remaining defects – predetermine percent – e.g., “95% of estimated existing defects found ” Stopping Criteria
26
Target: 95% Stopping Criteria: Graphical Representation
time
Percentage tested or found %
Stopping Criteria: Graphical Representation
Error detection rate Errors found per 1000 hrs Target: <= 7 per1000 hrs for 4 weeks
time
27
ANSI/IEEE 829-1983 Software Test Documentation
items under test, scope, approach, resources, schedule, personnel
items to be tested, the approach, the plan in detail
sets of inputs and events
steps for setting up and executing the test cases
items under test, physical location of results, person responsible for transmitting
chronological record, physical location of test, tester name
documentation of any event
requires further investigation
summarizes the above
28
Project Plan System Requirements System Design Quality Plan Resource Plan Configuration Management
Project Portfolio
System Test Plan
…
29
30
Range of cost estimates after conceptualization phase, based on actual cost of $1
$1 Design $1 Implementation $1 Integration/Test $1 Requirements analysis $1 Conceptualization phase
Range of cost estimates after requirements analysis phase
25c $4