Download 7 Risk management plan

HELSINKI UNIVERSITY OF TECHNOLOGY
T-76.115 SOFTWARE PROJECT
AUTUMN 2003
3.7.2017
ROADRUNNERS - PROJECT PLAN
565344943
Page 1 of 34
RoadRunners
HELSINKI UNIVERSITY OF TECHNOLOGY
T-76.115 SOFTWARE PROJECT
AUTUMN 2003
3.7.2017
Change history
Version
Description
Author
Date
0.01
Document created
Männistö
5.10.03
0.02
Document's content added 12.10.03
Männistö & Räisänen
12.10.03
0.03
Document's content added 12.10.03
Männistö & Räisänen
13.10.03
0.04
Document's content added 12.10.03
Männistö & Räisänen
17.10.03
0.05
Document's content added 12.10.03
Männistö & Räisänen
19.10.03
Männistö
21.10.03
Männistö & Räisänen
22.10.03
0.06
0.07
565344943
Risk management and standards added
Some parts are fixed according to customer's comment
Chapter 5.1.1 and 6 updated, chapters 8 and 9 added
Page 2 of 34
RoadRunners
HELSINKI UNIVERSITY OF TECHNOLOGY
T-76.115 SOFTWARE PROJECT
AUTUMN 2003
3.7.2017
Table of contents
1
2
3
4
5
INTRODUCTION ................................................................................................................... 5
1.1
PURPOSE AND SCOPE OF PROJECT ............................................................................................... 5
1.2
THE SYSTEM AND ENVIRONMENT ................................................................................................. 5
1.3
RIGHTS TO PROJECT OUTCOME ................................................................................................... 5
1.4
TERMINOLOGY AND DEFINITION. ................................................................................................. 6
STAKEHOLDERS AND STAFFING .......................................................................................... 7
2.1
PROJECT GROUP ................................................................................................................... 7
2.2
OTHER STAKEHOLDERS ......................................................................................................... 11
GOALS AND END CRITERIA ................................................................................................ 12
3.1
GOALS OF THE CUSTOMER ...................................................................................................... 12
3.2
GOALS OF THE PROJECT GROUP ................................................................................................ 14
3.3
PROJECT ABORT CRITERIA ...................................................................................................... 15
3.4
PROJECT END CRITERIA ......................................................................................................... 15
RESOURCES AND BUDGET .................................................................................................. 15
4.1
PERSONNEL ...................................................................................................................... 15
4.2
MATERIALS ....................................................................................................................... 16
4.3
BUDGET .......................................................................................................................... 16
WORK PRACTICES AND TOOLS .......................................................................................... 16
5.1
6
PRACTICES ....................................................................................................................... 16
5.1.1
Test approach .......................................................................................................... 16
5.1.2
Iterative development............................................................................................... 17
5.1.3
Iteration planning..................................................................................................... 17
5.1.4
Time reporting ......................................................................................................... 17
5.1.5
Defect tracking ........................................................................................................ 17
5.1.6
Documenting and document delivery .......................................................................... 18
5.1.7
Project review .......................................................................................................... 19
5.1.8
Requirements prioritization ........................................................................................ 19
5.1.9
Requirements management ....................................................................................... 19
5.1.10
Use cases ............................................................................................................. 19
5.1.11
Version control ..................................................................................................... 19
5.1.12
Coding convention ................................................................................................. 19
5.1.13
Testing ................................................................................................................ 20
5.1.14
Peer testing .......................................................................................................... 20
5.1.15
Personal SE assignments summary ......................................................................... 20
5.2
TOOLS ............................................................................................................................ 21
5.3
STANDARDS ...................................................................................................................... 21
PHASING ........................................................................................................................... 22
6.1
OVERVIEW ....................................................................................................................... 22
6.2
PROJECT PLANNING ............................................................................................................. 23
565344943
Page 3 of 34
RoadRunners
HELSINKI UNIVERSITY OF TECHNOLOGY
T-76.115 SOFTWARE PROJECT
AUTUMN 2003
7
8
3.7.2017
6.3
IMPLEMENTATION 1 ............................................................................................................. 24
6.4
IMPLEMENTATION 2 ............................................................................................................. 26
6.5
IMPLEMENTATION 3 ............................................................................................................. 28
6.6
DELIVERY ........................................................................................................................ 30
RISK MANAGEMENT PLAN.................................................................................................. 31
7.1
RISK MANAGEMENT PRACTICES ................................................................................................ 31
7.2
RISKS ............................................................................................................................ 32
REFERENCES ...................................................................................................................... 34
565344943
Page 4 of 34
RoadRunners
HELSINKI UNIVERSITY OF TECHNOLOGY
T-76.115 SOFTWARE PROJECT
AUTUMN 2003
3.7.2017
1 Introduction
This document is the project plan for a project "Roadmapping tool". This project is one of the projects
done during the course “T-76.115 Software Project” term 2003-2004 at the Helsinki University of
Technology (HUT) Computer Science department.
This project is done by a seven-person group of course participants to a real customer, SoberIT. A Mentor
has been appointed by the course for this project to guide the project group and to act as a sponsor for
the project. Project group and stakeholders are presented in chapter 2.
1.1 Purpose and scope of project
The purpose of this project is to develop Roadmapping tool for software development organizations.
Project's customer is SoberIT from Helsinki University of Technology. Project is part of customer's own
CORE research project which purpose is to develop systematic practices for Finnish software development
organizations so that they can cost-efficiently involve stakeholders to develop products that satisfy
customer and user needs.
1.2 The system and environment
The system to be developed is a Roadmapping tool, which is used as a stand-alone program in Sun Java
1.4.2 environment
1.3 Rights to project outcome
The customer and project group can continue development of the project outcome individually after this
project.
565344943
Page 5 of 34
RoadRunners
HELSINKI UNIVERSITY OF TECHNOLOGY
T-76.115 SOFTWARE PROJECT
AUTUMN 2003
3.7.2017
1.4 Terminology and definition.
Abbreviation
Definition
HUT
Helsinki University of Technology
CORE
Competitive Advantage through Stakeholder-Driven Requirements Engineering
SoberIT
Software Business and Engineering Institute
PSEA
Personal Software Engineering Assignment
GUI
Graphical User Interface
Term
565344943
Definition
Page 6 of 34
RoadRunners
HELSINKI UNIVERSITY OF TECHNOLOGY
T-76.115 SOFTWARE PROJECT
AUTUMN 2003
3.7.2017
2 Stakeholders and staffing
Project's stakeholders and staff can be found in Figure 1.
Petri Noponen
Account Mngr
Reetta Räisänen
User Interface Mngr
Cemo Timucin
Mentor
Tero Kojo
Customer
SoberIT
Kirsi Männistö
Project Manager
Jouko Koski
Technical Advisor
SoberIT
Jussi Katajala
System Architect
Juha Välimäki
Documentation Mngr
Tomi Koskinen
Programmer Mngr
Saiki Tanabe
Process Mngr
Figure 1. Project organization chart.
2.1 Project group
Name
Kirsi Männistö
Role
Project manager: Responsible for the project as a whole, maintaining schedule and
successful work distribution. The project plan, progress reports, and the final
report are the project manager's responsibility.
Phone number
040 5388 257
E-mail
[email protected]
Study background
- Bachelor of Science in Telecommunication (Turku Polytechnic 2002)
- Computer science (HUT, started at 2002)
Work background
2 years as software engineer
Interests
Test automation on system test level
Skills
Testing, Java, C++, User Experience, CVS
565344943
Page 7 of 34
RoadRunners
HELSINKI UNIVERSITY OF TECHNOLOGY
T-76.115 SOFTWARE PROJECT
AUTUMN 2003
3.7.2017
Name
Reetta Räisänen
Role
User interface manager: Responsible for UI design and testing, possibly also
implementation, together with the customer, technical advisor and potentially a
group participating in the user interface design course at HUT. Chief responsibility
of the user's manual.
Phone number
040 5359 078
E-mail
[email protected]
Study background
- Engineer in Information Technology (Kajaani Polytechnic 2001)
- Computer science (HUT, started at 2002)
Work background
3 years as software engineer
Interests
Meeting practices
Skills
Testing, Java, C, User Experience, VSS
Name
Jussi Katajala
Role
System architect: Chief responsibility of the system's technical design, including
architecture, interfaces, and tools used. Usually defines the test plan.
Phone number
040 5827 368
E-mail
[email protected]
Study background
-Datanomi (Kouvola Business Institute, 1995)
-B.Eng. in Telecommunications (Mikkeli Polytechnic, 2000)
-Computer science (HUT, started at 2002)
Work background
-3 years as software engineer
-2 years as design team leader
Interest
Design patterns
Skills
UML, C++, Real-time systems, OSE, TTCN, Java
565344943
Page 8 of 34
RoadRunners
HELSINKI UNIVERSITY OF TECHNOLOGY
T-76.115 SOFTWARE PROJECT
AUTUMN 2003
3.7.2017
Name
Petri Noponen
Role
Account manager: Responsible for the results of the requirement elicitation
together with the customer. Ensures that the remaining members of the group
have sufficient understanding of the customer's needs throughout the project.
Phone number
0400 430 457
E-mail
[email protected]
Study background
- Computer engineering (Technical institute of Espoo - Vantaa 1993)
- Information engineering (Polytechnic of Helsinki 2002)
- Computer science (HUT, started at 2002)
Work background
1 year as microchips and computers testing
4 years as integration testing of GSM network
3 years as operating and maintenance of telecom networks
1 year as technical support for telecom network
Interest
Integration of services and systems
Skills
Integration Testing, TNSDL, C, Java
Name
Juha Välimäki
Role
Documentation manager: Chief responsibility of document quality and of
composing and delivering final document versions from the document parts written
by others.
Phone number
0400 934 069
E-mail
[email protected]
Study background
-Bachelor of Science, Electronics and information technology. (Vaasa Polytechnic
2000)
- Computer science (HUT, started at 2002)
Work background
4 years as software engineer
Interest
Communication practices
Skills
Java, C/C++, project control, User Experience, Testing
565344943
Page 9 of 34
RoadRunners
HELSINKI UNIVERSITY OF TECHNOLOGY
T-76.115 SOFTWARE PROJECT
AUTUMN 2003
3.7.2017
Name
Saiki Tanabe
Role
Process manager: Chief responsibility of the processes used in the project, and
their relevant tools.
Phone number
040 8230 704
E-mail
[email protected]
Study background
- Software Engineer (Stadia 2001)
- Computer Science (HUT, started at 2001)
Work background
3 1/2 as Software Engineer
Interest
- Software Architecture
- Quality and delivery
Skills
- C++, Java, Testing, Configuration management
Name
Tomi Koskinen
Role
Programmer manager: Chief responsibility of module implementation, related
tools, and testing. Writes test and defect reports. Chief responsibility of
programming.
Phone number
040 7593 612
E-mail
[email protected]
Study background
- Engineer (Lahti Polytechnic 2002)
- Computer science (HUT, started at 2002)
Work background
4 years as software engineer
Interest
Software architecture and design, programming, user-interface design
Skills
Testing, Java, C++, User Experience, CVS
565344943
Page 10 of 34
RoadRunners
HELSINKI UNIVERSITY OF TECHNOLOGY
T-76.115 SOFTWARE PROJECT
AUTUMN 2003
3.7.2017
2.2 Other stakeholders
Stakeholders of this project are presented in tables below.
Name
Tero Kojo
Role
Customer
Phone number
(09) 4516 079
E-mail
[email protected]
Name
Jouko Koski
Role
Technical advisor
Phone number
(09) 4516 223
E-mail
[email protected]
Name
Cemo Timucin
Role
Mentor
Phone number
050 5481 535
E-mail
[email protected]
565344943
Page 11 of 34
RoadRunners
HELSINKI UNIVERSITY OF TECHNOLOGY
T-76.115 SOFTWARE PROJECT
AUTUMN 2003
3.7.2017
3 Goals and end criteria
This chapter describes goals of customer and project group in a general level.
3.1 Goals of the customer
Customer's goal is to make a Roadmapping tool, which helps customers to develop business-planning
process for different products. Business planning process includes creation, launch, life cycle and
management of product family. Roadmapping tool should ease defining markets and customers of
product and offer an effective tool for communicating on every organizational level. Product management
is defined to be final grade to use Roadmapping tool for design purposes. Other personnel can use tool
for viewing roadmaps. In the other words there are two different tools: one for designing and one for
viewing roadmaps.
System should be able to communicate effectively to all layers of user groups to all directions. E.g.
product development should be aware of resources at production.
Corporate management
Production management
Communication flow
Product management
Financial management
Marketing management
ETC.
Figure 2. Communication flow at customer organization.
565344943
Page 12 of 34
RoadRunners
HELSINKI UNIVERSITY OF TECHNOLOGY
T-76.115 SOFTWARE PROJECT
AUTUMN 2003
3.7.2017
Table 1 Top-10 goals of the customer
Goal
Verification criteria
1. Usability
User without experience has no difficulties to use this program.
2. Easy to install
Customer can install and start work with the program by using manual.
3. Reliability
95 % of all test cases are passed.
4. Functional program
Program fills its expectation and customer is able to demonstrate it further.
5. Program can be in drawing
User can use program for editing and also just for reviewing.
mode and in review mode
6. Different layers can be
User can add, edit and remove layers with Roadmapping tool.
defined.
7. Portability of program's
User can easily transfer output to the other program (for example to
output
PowerPoint)
8. Analyzing and categorizing of
Items can be grouped together for better categorizing.
information
9. Performance
Using program does not require new equipment or hardware for customer.
10. Possibility to add links to the Link to the other documents can be created and opened.
other documents
565344943
Page 13 of 34
RoadRunners
HELSINKI UNIVERSITY OF TECHNOLOGY
T-76.115 SOFTWARE PROJECT
AUTUMN 2003
3.7.2017
3.2 Goals of the project group
The group's goals are defined in Table 2. in priority order
Table 2 Goals of the project group
Goals of the project group
Deliver valuable tool for Roadmapping in schedule
Passing the course with grade 3 or higher
Learn more about SW projects
Develop communicational skills
Test driven implementation (Module testing for critical parts/components)
Good design and architecture
Easy to use software
Learn more about Java
Below is presented project group's most important learning goals on this course.
Table 3 Personal learning goals
Member
Personal learning goal
Kirsi Männistö
Project management
Reetta Räisänen
Testing process
Jussi Katajala
Design patterns and Java
Petri Noponen
Project documentation
Juha Välimäki
Project managing/Project process. Communicational skills
Tomi Koskinen
Group communication
Saiki Tanabe
Software architecture and developing with multiple programmers
565344943
Page 14 of 34
RoadRunners
HELSINKI UNIVERSITY OF TECHNOLOGY
T-76.115 SOFTWARE PROJECT
AUTUMN 2003
3.7.2017
3.3 Project abort criteria
Project has to be aborted if one of the following statements occurs:

More than one member leaves the group in the middle of the course. If leaving occurs during last
phase of project that does not matter.

Average point received for two first evaluations is less than 2.
Decision of aborting the project will be made together with stakeholders and members of project. All
participants need to be present when making aborting decision.
3.4 Project end criteria
Project ends when final demo is hold, which is at latest 7.4.2004.
4 Resources and budget
This chapter presents the planned resources and budget for the project.
4.1 Personnel
Every member has 190 work hours in this project. These hours are divided in five phases: Project
planning (PP), Implementation1 (I1), Implementation2 (I2), Implementation3 (I3) and Delivery (DE).
Lengths of these phases vary from 3 to 6 weeks. Estimates of the hours of each group member are
presented in Table 4.
Table 4 Planned effort - hours to be spent on project
Phase
Kirsi
Reetta
Jussi
Petri
Juha
Tomi
Saiki
Total
PP
80,5
61,5
50,5
57,5
45,5
45,5
48,5
389,5
I1
31
41
39
36
42
34
41
264
I2
27
46
43
39
42
42
39
278
I3
29
36
52
51
54
59
56
337
DE
22,5
5,5
5,5
6,5
6,5
9,5
5,5
61,5
Total
190
190
190
190
190
190
190
1330
565344943
Page 15 of 34
RoadRunners
HELSINKI UNIVERSITY OF TECHNOLOGY
T-76.115 SOFTWARE PROJECT
AUTUMN 2003
3.7.2017
4.2 Materials
Every group member has own computer so any additional hardware resources are not needed. Also
customer does not require any special software or hardware during project.
4.3 Budget
Each member of the group invests 190 hours in the project.
5 Work practices and tools
This chapter lists all practices and tools used in the project. Each chosen issue and its application to the
project is listed and documented here.
5.1 Practices
This chapter describes work practices used in this project.
5.1.1 Test approach
This chapter describes test approach in general level. The actual test plan is done in phase IM1.
The purpose of testing is to ensure that Roadmapping tool fulfils all the specified requirements. Tests are
based on accepted requirement specification document. During the project following tests are performed:

Inspections

Unit / module testing

Integration testing

System testing

Acceptance testing
Test techniques to be used in this project are:





Black box testing
White box testing
Performance testing
Negative and positive testing
Usability testing
565344943
Page 16 of 34
RoadRunners
HELSINKI UNIVERSITY OF TECHNOLOGY
T-76.115 SOFTWARE PROJECT
AUTUMN 2003
3.7.2017
All the found defects will be priorized and added to Bugzilla-program. Developers write unit tests their
own code at the same time as actual code is written. Developers also test, that their own code can be
build before checking it in to the version control.
Chief programmer is responsible of testing. He makes sure that all planned tests are executed and
passed before end of the project.
Four different documents are generated in the each iteration (excluding PP phase): Test report, test
session charter, general test charter and test case specification. Test cases are grouped into prioritized
test suites by use cases.
5.1.2 Iterative development
In each iteration, where the goal is to implement a set of use cases (I1, I2 and I3), the group refines the
requirements (analysis), design, programs and tests the selected set of use cases.
5.1.3 Iteration planning
The each iteration is planned in detail in the end of the previous iteration. Project manager enters tasks
to the Trapoli tool.
5.1.4 Time reporting
The group members report working hours using the Trapoli time reporting tool. Reporting is done on a
daily to ensure that the information is of real use, reliable and up-to-date considering the time invested
in entering it.
5.1.5 Defect tracking
The group keeps track of problems and defects found in Roadmapping tool. Tomi Koskinen as chief
programmer decides which reports will be implemented, in what order, and to whom each report returns
for testing. Bugzilla tool is used for defect tracking in this project.
565344943
Page 17 of 34
RoadRunners
HELSINKI UNIVERSITY OF TECHNOLOGY
T-76.115 SOFTWARE PROJECT
AUTUMN 2003
3.7.2017
5.1.6 Documenting and document delivery
The group writes certain documents and deliver them to the steering group at the end of the each phase
using delivery system. Documents are in pdf-format. Documents to be delivered are listed below in Table
5.
Table 5 Delivered documents in phases.
Phase
Documents
Project planning
Project plan
Requirements document
Progress report
Implementation 1
Updated project plan
Updated requirements document
Technical specification (at least architectural specification on a general level)
Test cases
Test report and test log
Progress report
Implementation 2
Updated project plan
Updated requirements document
Updated technical specification
Updated test cases
Test report and test log
User's manual
Progress report
Implementation 3
Updated project plan
Updated requirements document
Updated technical specification
Updated test cases
Test report and test log
Peer test plans (plans prepared for the peer testing group and plans prepared by the
peer testing group)
Peer test reports (report made by the peer testing group and report made for the
peer testing group)
Updated user's manual
Progress report
Delivery
Final report
Test report and log (if necessary)
Final versions of all documents produced during the project
565344943
Page 18 of 34
RoadRunners
HELSINKI UNIVERSITY OF TECHNOLOGY
T-76.115 SOFTWARE PROJECT
AUTUMN 2003
3.7.2017
5.1.7 Project review
The group must present project progress at project reviews at the end of the each iteration. During
project five reviews will be hold. First four have almost same agendas: Checking of project status,
presenting of work practices and substance and introducing of plans for next iteration. Also steering
group's comments and questions are handled. The last project review is final demonstration and sales
pitch, project evaluation and steering group's comments and questions will be presented there.
5.1.8 Requirements prioritization
Use cases are prioritized to make sure the most essential functionality can be delivered to the customer.
Prioritization is done based on this document's chapter 3.1.
5.1.9 Requirements management
Requirements are defined in co-operation with the customer and documented in the requirements
document. The status of each requirement is tracked during the project and changes to requirements will
be documented. The customer will do acceptation.
5.1.10
Use cases
Use cases are used to document the external functions of the system. Use cases are described in
requirement specification.
5.1.11
Version control
The group uses a version control tool to manage different project files. Tool to be used is CVS (WinCVS
as GUI). Convention to use in this project is unreserved checkouts with watch features (See Saiki
Tanabe's PSEA: Configuration management).
5.1.12
Coding convention
The written code follows Sun Java Coding Conventions. English is used in coding and commenting.
565344943
Page 19 of 34
RoadRunners
HELSINKI UNIVERSITY OF TECHNOLOGY
T-76.115 SOFTWARE PROJECT
AUTUMN 2003
5.1.13
3.7.2017
Testing
The group plans, executes and reports testing in each implementation iteration.
5.1.14
Peer testing
The group provides Roadmapping tool to a peer group for testing as well as tests the peer group's system
during the I3 iteration.
5.1.15
Personal SE assignments summary
In Table 6 is described each group member's Personal SE assignment.
Table 6 Personal SE assignments
Practice
Communication practices
Test-driven development
Responsible
Usage
Juha Välimäki
PP-DE
Kirsi Männistö
I1-I3
Meeting practices
Reetta Räisänen PP-DE
Design patterns
Jussi Katajala
I1-I3
Documentation practices
Petri Noponen
PP-DE
Configuration management Saiki Tanabe
PP-DE
Architectural design
I1-I3
565344943
Tomi Koskinen
Page 20 of 34
RoadRunners
HELSINKI UNIVERSITY OF TECHNOLOGY
T-76.115 SOFTWARE PROJECT
AUTUMN 2003
3.7.2017
5.2 Tools
Tools to be used in this project are defined in Table 7.
Table 7 Tools to be used.
Tool
Description
MS Office 2000/XP
Documentation
MS Project 2000
Project planning and organization
Rational Rose 2001.03
Design and architecture
Visio 2000
Design and architecture
Eclipse 2.1.0
Implementation
Bugzilla
Bug reporting
JUnit 3.8.1
Unit testing
CVS/ WinCVS 1.3.13.1 Beta Configuration management
Trapoli
Hour reporting
5.3 Standards
Project use javadoc as documentation convention in implementation. Javadoc documentation can be
found in http://java.sun.com/j2se/javadoc/writingdoccomments/index.html/.
565344943
Page 21 of 34
RoadRunners
HELSINKI UNIVERSITY OF TECHNOLOGY
T-76.115 SOFTWARE PROJECT
AUTUMN 2003
3.7.2017
6 Phasing
This chapter presents the phasing of the project. It lists the iterations' primary goals and deliverables,
tasks and effort estimates, and critical dates during the iterations. The iterations follow the course
schedule.
At the end of the each iteration, the next iteration's goals and deliverables are planned and documented
here.
The specific tasks of the next iteration are also planned, once the goals and deliverables have been
defined. Also the project planning iteration is planned, as soon as possible after the start of the project.
The planned detailed tasks for each iteration are created in Trapoli and copied here as a summary.
6.1 Overview
Table 8 Important dates
Date
Iteration/Event
23.9. - 30.10.2003 (~4 weeks)
PROJECT PLANNING
27.10.2003
Delivery (PP)
30.10.2003
Project Review (PP)
31.10. - 4.12.2003 (5 weeks)
IMPLEMENTATION 1
1.12.2003
Delivery (IM1)
4.12.2003
Project Review (IM1)
5.12.2003 - 12.2.2004 (10 weeks) IMPLEMENTATION 2
9.2.2004
Delivery (IM2)
12.2.2004
Project Review (IM2)
13.2. - 18.3.2004 (5 weeks)
IMPLEMENTATION 3
8.3.2004
Deliver system to peer group for testing
15.03.2004
Delivery (IM3)
18.03.2004
Project Review (IM3)
19.3.2004 - 7.4.2004 (3 weeks)
DELIVERY
5.4.2004
Delivery (DE)
7.4.2004
Final demo (DE)
26.4.2004
Quality award ceremony
565344943
Page 22 of 34
RoadRunners
HELSINKI UNIVERSITY OF TECHNOLOGY
T-76.115 SOFTWARE PROJECT
AUTUMN 2003
3.7.2017
6.2 Project Planning
Goals of Project Planning phase are organizing the project, specifying goals, analyzing risks, selecting
work practices and tools, planning supporting actions and dividing the project into smaller iterations and
scheduling these. Also customer relationship is created in this phase.
Deliverables in this phase are:

Project plan

Requirements specification document

Progress report (slideshow)
Tasks planned to this phase are described in Table 9.
Table 9 Tasks planned in this phase:
Type
Task
Hours
GE
Lecture
87,5
PM
Write the project plan
58
GE
Meetings (status/mentor/customer) 70
PM
Personal SE practice
21
PM
Define project goals
7
PM
Adopt tool: CVS
12
PM
Adopt tool: Messenger
14
PM
Write progress report
2
PM
Project review and preparation
21
PM
Plan the next iteration
2
DS
Req. elicitation and analysis
10
DS
Req. documentation
53
DS
Study domain Roadmapping
7
PM
Start and organize project
5
PM
Plan work methods and tools
10
PM
Other project management
1
PM
Inspection
9
565344943
Page 23 of 34
RoadRunners
HELSINKI UNIVERSITY OF TECHNOLOGY
T-76.115 SOFTWARE PROJECT
AUTUMN 2003
3.7.2017
6.3 Implementation 1
A goal of this phase is to produce design core architecture. This iteration concentrates on implementing
and testing the baseline architecture of the system.
Deliverables in this phase are:

Implemented use cases/core architectural parts:
o
Will be defined later
Documents:

Updated project plan

Updated requirements document

Technical specification (core architecture)

Test case specifications

Test report

Progress report (slideshow)
Tasks planned to this phase are described in Table 10.
565344943
Page 24 of 34
RoadRunners
HELSINKI UNIVERSITY OF TECHNOLOGY
T-76.115 SOFTWARE PROJECT
AUTUMN 2003
3.7.2017
Table 10 Tasks planned in IM1 phase:
Type
Task
Hours
DS
Architectural design
24
DS
Write/update tech. specs
35
GE
Meetings (status/mentor/customer) 60
IM
Core architecture
35
IM
Use Case User Interface
15
PM
Plan work methods and tools
2
PM
Personal SE practice
21
PM
Plan the next iteration
2
PM
Project review and preparation
9
PM
Write progress report
5
PM
Risk management
4
TE
Prepare testing
29
TE
Execute and report tests
9
DS
Req. documentation
1
PM
Inspection
7
PM
Other project management
5
PM
Write the project plan
1
565344943
Page 25 of 34
RoadRunners
HELSINKI UNIVERSITY OF TECHNOLOGY
T-76.115 SOFTWARE PROJECT
AUTUMN 2003
3.7.2017
6.4 Implementation 2
In this iteration more use cases are implemented on top of the baseline architecture. At the end of this
iteration the system is delivered to the customer to get feedback on it.
An initial version of the user's manual is written and later updated as the project progresses. The content
and format of the user's manual are agreed on with the customer. Before the end of the iteration the
groups discusses the arrangements concerning peer testing with each other.
Deliverables in this phase are:

Implemented use cases/core architectural parts:
o
Will be defined later
Documents in this phase:


Updated project plan
Updated requirements document

Updated technical specification

Updated test cases

Test report and test log

User's manual

Progress report
Tasks planned to this phase are described in Table 11.
565344943
Page 26 of 34
RoadRunners
HELSINKI UNIVERSITY OF TECHNOLOGY
T-76.115 SOFTWARE PROJECT
AUTUMN 2003
3.7.2017
Table 11 Tasks planned in IM2 phase:
Type
Task
Hours
DS
Write/update tech. specs
18
GE
Meetings (status/mentor/customer) 60
IM
Write/update User manual
5
IM
Use Case User Interface
10
IM
Use Case Y
40
IM
Use Case Z
35
PM
Plan work methods and tools
2
PM
Personal SE practice
21
PM
Plan the next iteration
2
PM
Project review and preparation
21
PM
Write progress report
5
PM
Other project management
1
PM
Inspection
7
PM
Write the project plan
1
PM
Risk management
4
TE
Execute and report tests
23
TE
Prepare testing
23
565344943
Page 27 of 34
RoadRunners
HELSINKI UNIVERSITY OF TECHNOLOGY
T-76.115 SOFTWARE PROJECT
AUTUMN 2003
3.7.2017
6.5 Implementation 3
This iteration is similar to the previous one, but a couple of weeks are reserved for system testing, fixing
major bugs and for peer testing towards the end of the iteration. The system is ready, not counting some
known minor bugs, when delivered to the peer-testing group.
Deliverables in this phase are:

Implemented use cases/core architectural parts:
o
Will be defined later
Documents in this phase:


Updated project plan
Updated requirements document

Updated technical specification

Updated test cases

Test report and test log

Peer test plans (plans prepared for the peer testing group and plans prepared by the peer testing
group)

Peer test reports (report made by the peer testing group and report made for the peer testing
group)

Updated user's manual

Progress report
Tasks planned to this phase are described in Table 12.
565344943
Page 28 of 34
RoadRunners
HELSINKI UNIVERSITY OF TECHNOLOGY
T-76.115 SOFTWARE PROJECT
AUTUMN 2003
3.7.2017
Table 12 Tasks planned in IM3 phase:
Type
Task
Hours
DS
Write/update tech. specs
18
GE
Meetings (status/mentor/customer) 70
IM
Write/update User manual
10
IM
Use Case User Interface
5
IM
Use Case Y
40
IM
Use Case Z
35
PM
Plan work methods and tools
2
PM
Personal SE practice
21
PM
Plan the next iteration
1
PM
Project review and preparation
21
PM
Write progress report
5
PM
Other project management
4
PM
Inspection
7
PM
Write project plan
1
PM
Risk management
4
TE
Execute and report tests
24
TE
Prepare testing
39
TE
Execute and report peer tests
30
565344943
Page 29 of 34
RoadRunners
HELSINKI UNIVERSITY OF TECHNOLOGY
T-76.115 SOFTWARE PROJECT
AUTUMN 2003
3.7.2017
6.6 Delivery
In the delivery iteration, the system is finalized into a condition in which it can be delivered to the
customer, and the project is ended. Projects wrap up with a final meeting with all the stakeholders to
ensure all parties are aware that the project has reached its end, as has the project group's work.
Deliverables in this phase are:

Implemented use cases/core architectural parts:
o
Will be defined later


Documents in this phase: Final report
Test report and log (if necessary)

Final versions of all documents produced during the project
Tasks planned to this phase are described in Table 13.
Table 13 Tasks planned in DE phase:
Type
Task
GE
Meetings(status/mentor/customer) 14
GE
Final review and demo
19
PM
Personal SE practice
10,5
PM
Other project management
1
PM
Inspection
2
PM
Write final report
15
565344943
Hours
Page 30 of 34
RoadRunners
HELSINKI UNIVERSITY OF TECHNOLOGY
T-76.115 SOFTWARE PROJECT
AUTUMN 2003
3.7.2017
7 Risk management plan
7.1 Risk management practices
The following persons do the risk management:

Jussi Katajala

Kirsi Männistö

Reetta Räisänen

Petri Noponen
Risk management group (RMG) meets every second week either in a separate meeting or in connection
with other project related meetings. In these meetings the existing risks are evaluated. Potential new
risks will be identified in these meetings with the methods described in the course T-76.633 (Affinity
Grouping Technique, Riskit Analysis Graphs, Risk Statements and Risk Information Forms).
All members of the project group are responsible for informing the RMG about new risks they find. This
can be done either by informing the project manager or by informing the person who maintains the risk
list.
RMG can assign risk related responsibility and action points to any member of the team. If the assigned
person is not a member of the RMG, then project manager must inform the responsible person as soon
as possible about the responsibility.
RMG maintains the risk list in MS Excel-format. Risk management data collection is done with this list.
The risk list is made available in the CVS and also on the project web page. Jussi Katajala maintains the
risk list. The initial risk list is in the chapter 7.2. Risk list in the chapter 7.2 will not be updated after the
Project plan is approved.
If the risk is not valid anymore, then the risk is marked as obsolete. If risk realizes, then it is marked as
realized. If the realized risk threatens the project timetable or project outcome, then a member of RMG
must inform the customer and mentor about it. Risks are never removed from the risk list; they are kept
on the list until the project ends. Risk list is used for risk related reports.
565344943
Page 31 of 34
RoadRunners
HELSINKI UNIVERSITY OF TECHNOLOGY
T-76.115 SOFTWARE PROJECT
AUTUMN 2003
3.7.2017
7.2 Risks
Table 14 Risks
ID
Description
Risk factors
Risk event
Effects
Controlling
Responsible
actions
001 Customer
1. Too little
Requirements are
Project outcome
a) More
Kirsi Männistö is
requirements communication with
not detailed enough
does not satisfy
communication
responsible for
are too vague the customer about
or faulty.
the customer.
with customer
communication
and do not
the requirements.
Implementation
Course grade will
about the
towards the customer.
stabilize
2. Project subject is
cannot be started or
be low or course
requirements.
Other project members
enough
unknown to the
implementation is
will not be passed
b) Requirements
are responsible for
before I1.
project members.
done wrongly.
at all.
reviewed by
actively obtaining
customer and
information needed for
mentor.
writing the
requirements and for
reviewing the
requirements.
002 Distributed
Development is
development done:
003 Java competence
SW developed by
SW does not
a) Communication Juha Välimäki and Kirsi
between project
different people
function correctly
-In different places
cannot be
or doesn’t work at members must be the communication
-In different times.
integrated.
all. Course grade
enhanced.
practices. Saiki Tanabe
-In different
Something is
will be low or
b) A way of
for defining CVS
environments.
done twice or not at
course will not be
creating a stable
related methods.
Lot of
all.
passed at all.
SW version from
communication
CVS must be
channels needed.
defined.
Männistö for enhancing
Java-competence
Implementation is
SW does not have a) Identify persons All project members
varies among the
slowed down or
required
halted.
functionality or SW competence within seeking actively
is distributed project members.
unevenly
with good Java-
are responsible for
cannot be
or outside the
assistance if they have
implemented in
group and ask
problems in the
time.
them for help.
implementation.
b) Obtain Javabooks that can be
used for learning.
004 New tools
Project members
Implementation is
SW does not have Identify persons
All project members
must use tools (CVS, slowed down or
required
are responsible for
Trapoli etc.) they
functionality or SW about the tools
seeking actively
cannot be
assistance if they have
halted by tool
might not be familiar problems. Worstwith.
565344943
with knowledge
within or outside
case scenario is that implemented in
the group and ask problems with the tool.
deliverables
time. Other
them for help.
(documents, source
deliverables (e.g.
Page 32 of 34
All project members
are responsible for
RoadRunners
HELSINKI UNIVERSITY OF TECHNOLOGY
T-76.115 SOFTWARE PROJECT
AUTUMN 2003
3.7.2017
code etc.) are
documents and
assisting persons with
corrupted or
time reports)
tool problems.
destroyed.
cannot be
delivered.
005 Timetable
Because all project
Project member
Project member
a) Redistribute
All project members
members are
must go on a
cannot finish his
work, which
are responsible for
working, project
business trip or must tasks in time.
means bigger
informing the project
work can be done
work late.
workload for
manager about
mainly after business
others.
timetable related
hours.
b) Replanning of
problems. Project
the timetables.
manager is responsible
Might not be
for defining the
possible.
controlling action to be
used.
565344943
Page 33 of 34
RoadRunners
HELSINKI UNIVERSITY OF TECHNOLOGY
T-76.115 SOFTWARE PROJECT
AUTUMN 2003
3.7.2017
8 References
[1]
SoberIT. CORE. 2003. (http://www.soberit.hut.fi/core/)
[2]
How to write Java Doc Comments for JavadocTM Tool. 2003.
(http://java.sun.com/j2se/javadoc/writingdoccomments/index.html/
[3]
PSEA: Configuration management. Saiki Tanabe. (Configuration management.doc)
565344943
Page 34 of 34
RoadRunners