Projectt Plan Project Name Version 0.2

Projectt Plan Project Name Version 0.2

Tampere University of Technology

Department of Pervasive Computing

TIE-13106 Project Work on Pervasive Systems

Group name/number

Project name

Project plan

Note: All texts in this document that are colored blue are instructive and should be replaced with actual text by you. They just tell what should be included in each section.

Last modified: 18.8.2016 14:57 1/10

Projectt Plan Project Name Version 0.2

Version history

Contents

1Introduction......

1.1Purpose and scope

1.2Product and environment

1.3Customer's current system......

1.4Development constraints

1.5Project constraints......

1.6Definitions, abbreviations and acronyms......

2Project organisation......

2.1Group members

2.2Customer

2.3Related organisations

3Project goals and ending/termination......

3.1Goals of the project group

3.2Goals of the customer

3.3Goals and deliverable of the project

3.4Quitting (termination) criteria of the project

3.5Ending criteria of the project

4Project management......

4.1Methods and tools

4.2Monitoring and guidance

4.3Learning and study plan

5Project iterations and timing......

5.1Iterations

5.2Iteration 1 [2, 3…N]

6Requirements......

6.1Functional requirements

6.2Quality goals (Non-functional requirements)......

6.2.1Usability goals......

6.2.2Performance goals......

6.2.3Reliability goals......

6.2.4Security goals......

6.3User interface requirements

7Test and quality assurance plan......

7.1General approach

7.2Definition of done

7.3Special testing

7.4Test documentation

8Risk management......

8.1Risk list

8.2Risk monitoring

9Open issues

10References......

APPENDIX A […Z]......

1Introduction

1.1Purpose and scope

Purpose of this document.

1.2Product and environment

Product name, purpose goals and the environment in general.

1.3Customer's current system

How they do it now

1.4Development constraints

Such as technology constraints, standards

Practices set by the customer

1.5Project constraints

Confidentiality

Licensing issues

IPRs (if already agreed in some way)

1.6Definitions, abbreviations and acronyms

ScrumAgile software development framework

UIUser interface

2Project organisation

2.1Group members

List for each: Person, Contact info, experience, knowledge, interests

2.2Customer

Role, contact info

2.3Related organisations

Customer's organisation

Other organisations

3Project goals and ending/termination

3.1Goals of the project group

These can be, for example:

• Making of a good product
• Staying in schedule
• Customer satisfaction
• Reputation enhancing
• Maximize the fee (and minimize the work).

Priority of the goals: primary goal, secondary goal, etc.

3.2Goals of the customer

Priority of the goals: primary goal, secondary goal, etc. Agreement between customer and group on what functionalities should the product have. Customer goals can be for example:

• Product must have critical functionalities A & B (Note, mostly these go to requirement specification)
• Product must be on the market for Christmas
• Quality of the product must be the best in the market

3.3Goals and deliverable of the project

Here is a brief summary of customer and project group goals fitted together, priority of goals, agreement of what functionalities should the program have.

3.4Quitting (termination) criteria of the project

Definition of situations when the project should be terminated, for example:

• Customer withdraws
• There is a better or cheaper product on the market already
• Budget or schedule is exceeded by 300%

Who is able to terminate the project? Project manager or customer?

3.5Ending criteria of the project

It is important to specify when the project ends, for example:

• Certain date is reached
• Certain state of readiness is reached – some tests are passed
• Certain amount of working hours is reached
• Certain amount of money is spent
• Customer starts to use the product
• Product is approved when the customer'swarranty period expires

Who is able to end the project?

4Project management

4.1Methods and tools

• Change management
• Tools agreed for collaboration
• Version control
• Documentation

4.2Monitoring and guidance

• Within the group
• Outside the group
• Other?

4.3Learning and study plan

• Within the group
• Training provided by the customer
• Other?

5Project iterations and timing

In here you should list all the project iterations and people related and deadlines (WHO, WHAT, WHEN)

5.1Iterations

Project is divided into iterations (sprints) that usually last 2-4 weeks. You can choose the number of them freely – use a sprint model that works for your project. From every iteration the following things are listed:

• What kind of work the iteration includes – requirement gathering, design, implementation, testing...
• Person in charge of the iteration & special tasks for members
• Procedure how the iteration should be done
• Deliverables of the iteration (e.g. document X, implemented features).

Table 5.1 below lists the deadlines for the project.

Table 5.1. Deadlines

5.2Iteration 1 [2, 3…N]

• What is done
• Who does what
• Procedures
• Work estimation
• Deliverables
• You can use a table, including a spreadsheet for these

6Requirements

6.1Functional requirements

In this Chapter you will describe the high level functional requirements of your product. Requirements are described so that the reader will understand what needs to be implemented and what the product does, so that the project’s backlog can be mapped to requirements. It is not necessary to describe functions in such a detailed level that someone else would actually be able to implement them based on this document. The detail must be such, though, that you as the developers and the customer will able to form a common understanding of what needs to be developed.

Requirements/functions should be described using, e.g. use cases, user stories or scenarios. Use separate sections for different types of functions.

6.2Quality goals (Non-functional requirements)

6.2.1Usability goals

What goals does your product have in terms of usability and user experience? What are the most critical aspects? How and when do you measure if the goals have been reached?

6.2.1.1Goal 1

6.2.1.2Goal 2

6.2.2Performance goals

6.2.3Reliability goals

6.2.4Security goals

6.3User interface requirements

If user interface design is critical for your system, briefly sketch the main views/states here. Use example pictures of views, menus and dialogs, if possible and appropriate. Use separate sections for different views. Also describe the transitions between the views and the needed interactions for that. The description should be at the level that

1) the reader will have an idea what the user interface will contain, what general design solutions are used and why, and that 2) the team can create prototypes based on it. It should not go to such level of detail that the UI could be fully implemented based on the description.

7Test and quality assurance plan

7.1General approach

Describe your general strategy for testing: how will testing be done at various levels (unit, integration, system). Are there customer acceptance tests? Will there be analytic assessments (such as usability assessment)?

Who will do there? Will there be appointed testers? Are consultants used?

7.2Definition of done

Describe when a feature or other is “done”? Is some testing or other type of validation or acceptance a requirement for that? Acceptance testing by customer?

7.3Special testing

Describe any special testing tasks that require planning. Those include usability testing, security testing, browser / hardware compatibility testing and others.

7.4Test documentation

Describe the planned ways to document tests – any additional plans, test specifications (incl. test cases), test logs / diaries and test reports.

8Risk management

This is a very important part of the project plan. Most common risks are usually related to project personnel, customer or to hardware/software.

Risks should be classified from 1 to 3 or 1 to 5 (scale should be specified carefully: is 1 the most hazardous or harmless risk)

All the possible risks in the project are considered here. Elements of risks to consider

• Possible causes
• Severity X probability = size of risk
• Signs of the risk
• Procedures how the risk can be avoided?
• Procedures how the risk can be prevented?
• Recovery if a risk materialized?

Risks worth considering:

• Customer
• Hardware/software
• Environment
• Accidents, cases of illness
• "Sudden lack of motivation among some of the project members"
• Student group size changes

8.1Risk list

List the identified risks or summary. Preferably, a separate risk list is maintained (course offers a spreadsheet tool for this).

8.2Risk monitoring

How you follow the risks? At least at the end of sprints.

9Open issues

Are there things that still need to be checked with the customer?.

10References

Kerzner, 2013. Project management: a systems approach to planning, scheduling, and Controlling, Wiley, 2013.

APPENDIX A […Z]

Include appendices as needed.

Last modified: 18.8.2016 14:57 1/10