Final Report Project Name Version 0.2

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

Final Report

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: 2.2.2017 10:09 1/12

Final Report Project Name Version 0.2

Version history

Contents

1Introduction

1.1Purpose of the report

1.2Definitions, abbreviations and acronyms

2Project organisation

2.1Group

2.2Customer

2.3Other stakeholders

3Product

3.1Purpose

3.2Environment

3.3Third party components and licenses

3.4Restrictions and limitations

3.5Deliverables and outcomes

3.6Product rights (IPRs)

3.7Product backlog

4Project management

4.1Communication

4.2Process description

4.3Process lifecycle used......

4.4Methods and tools used

4.5Quality management......

4.6Other

5Working hours

6Testing and product quality......

6.1General description of testing......

6.2Low level testing (unit and integration testing)......

6.3High-level testing (system testing)......

6.4List of relevant defects......

6.5Conclusions on product’s quality......

7Risks and problems

7.1Foreseen risks

7.2Risks not foreseen

7.3Issues

8Rejected ideas and further development

8.1Rejected ideas

8.2Further development

9Lessons learned

10Concluding remarks from the project......

11Comments about the course

12Statistics

13References

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

1 Introduction

1.1 Purpose of the report

Why was this document made and to whom.

This document should describe how the project finally turned out, what it produced, how it performed and what the team learned from it.

1.2 Definitions, abbreviations and acronyms

ScrumAgile software development framework

UIUser interface

2 Project organisation

2.1 Group

Members, contact information.

2.2 Customer

2.3 Other stakeholders

E.g., TUT course personnel, end user organization, consultants, external test groups.

3 Product

3.1 Purpose

Brief description of the product characteristics: what in general was meant to be developed?

3.2 Environment

What is the environment: is the product an independent piece of software or part of a larger system?

Outline of the technologies that are used in the product – what is their purpose, how are they used.

3.3 Third party components and licenses

Are third party components used, if so what? What kind of licenses do they have?

3.4 Restrictions and limitations

E.g., is some functionality left out for some reason.

3.5 Deliverables and outcomes

Actual product (delivered in what format, to whom, when).

List any of these: Component and medias, binaries and sources files, installation packages, instructions, other documents, quality records, test scripts.

Also describe state of the product and actions necessary to take it into production use or to commercialize it.

Documents made (name, when returned, who was responsible, to whom). Remember to list both the documents required by the course and those only required by the customer. A table for listing documents is below for an example

Table 3.1. Documents.

Total amount of source code (LOC / SLOC):

Totally reused X % (code used as is):

Partially reused Y % (modified code):

Number of classes and methods:

Number of views / main windows:

3.6 Product rights (IPRs)

Who has the rights to the product and its future development? Describe the division of right (may be different for different components).

3.7 Product backlog

Put implemented product backlog here.

4 Project management

4.1 Communication

Describe the number of various kinds of communication between parties.

• Meetings

With customer:

Within the group:

Others? (e.g. course personnel, end users):

• Skype/IRC other real-time communication, with customer/within group:
• Project highlights (how many returned, when, to whom):
• Issue tracking activities:
• Others (email, social media tools etc.):

4.2 Process description

4.3 Process lifecycle used

Description of the timeline of the project. How did the project go on? What happened in the iterations in practice? Draw a simple timeline of the project from start to end. You may have parallel timelines for each member of the group, if it is easier. Mark on the timeline what happened and when. Include in the timeline actions such as requirements gathering, coding, integration, testing, quality management. The timeline may show what tasks are dependent of each other, what was done parallel, how has the project progressed. Make sure to clearly mark the start and finish of each iteration. The idea is just to see how the project progressed, not to draw any complex graphs.

4.4 Methods and tools used

Describe the following shortly. Include version numbers to tools.

• Development environment:
• Design tools:
• Programming languages:
• Integration system / engine:
• Tools used for collaboration?
• Version control:
• Documentation:
• Backlog and task lists:
• Backup policy and tools:
• Change management:
• Testing:
• Project management tools:
• Communication tools:

4.5 Quality management

Describe how quality was managed in the project – for example reviews, inspections. Note that there is a separate testing plan, so don’t write hear the details that are in that.

4.6 Other

Put your fully updated burn-up chart here.

Put your sprint plan & implemented item tables here.

Other things about project management that you would like to mention.

5 Working hours

• Report estimated working hours
• Per iteration
• Per person
• Report realized working hours
• Per task
• Per iteration
• Per person
• If you have estimated working hours by task and iteration, you may give estimated hours first in one table and then realized hours (example table 5.1) in another
• If tables get really big, you can turn them horizontally on a new page

Table 5.1. Example table: Realized working hours in person-hours by task

Table 5.2. Example table: Realized working hours in person-hours by person and task

Table 5.3 Example table: total working hours by person by iteration

6 Testing and product quality

6.1 General description of testing

Describe briefly your team’s approach to testing. How did you do it at various phases of the project? Did you use test automation or exploratory testing? Who did the testing? What were the testing environments and arrangements like? What test data was used? How did the project customer or other parties participate in testing?

6.2 Low level testing (unit and integration testing)

Describe how your code was tested in unit testing and integration testing and similar low-level activities. Describe any deficiencies in testing, for example components that were not unit tested. Include the test cases used as an attachment (test code as attachment or for example a zip file).

6.3 High-level testing (system testing)

Describe here how the product requirements – either expressed of implicit, functional and non-functional – were tested. Concentrate on those requirements that a) provide the most value to the customers, b) have the biggest associated risk to the customer.

6.3.1 Functional requirements

Describe how the functional requirements were tested, usually on user interface or system level. List the requirements that were not tested. Note that this section can be structured by “requirements”, use cases or user stories based on how your project handled the requirements. Include as an attachment listings of test cases and / or test logs or any detailed other information of how the testing had been carried out. Also include any reports that would describe test coverage or issues that the customer (or an auditor) would like to see as a proof that the testing was carried out properly.

6.3.2 Non-functional requirements

Describe briefly how you tested the non-functional requirements or otherwise assured the quality of those (for example any usability or security analyses / assessments). List any essential non-functional requirements that were not tested or otherwise assured. Add any additional information, such as usability test reports, as attachment. For information security, include description of the competence of the person(s) who did the testing or analysis and any special tools used.

User experience and usability

Information security

Performance

(Add other requirement classes as needed)

6.4 List of relevant defects

List the relevant defects or deficiencies in the product and their severity. Mark especially the defects that cause the product to be unsuitable for production use. You may include full defect reports or a full defect list as attachment if such are available. List the most severe problems first.

6.5 Conclusions on product’s quality

Give a conclusion on the product’s quality based on the testing and other means of evaluation. Is the product error-free enough for production? Is it sufficiently secure? Should some form of additional testing be done during the final productisation before releasing to market or production use?

7 Risks and problems

7.1 Foreseen risks

Include your risk list here or include it as attachment and give a reference to it.

7.2 Risks not foreseen

Tell about surprises that really caught you out. Listing those is important for learning.

7.3 Issues

List of issues, when raised, when resolved, how did they affect the process. These may be technical issues, and other problems that you have not documented as risks.

8 Rejected ideas and further development

8.1 Rejected ideas

What approaches were considered during the project but rejected? Why?

Were there third party components that you thought of using (or even tried for a while) but did not use in the end? Why?

8.2 Further development

How could the product be further developed?

List ideas that you had but didn’t have time to implement now (or were left out for some other reason. What was the idea and who did it come from?

9 Lessons learned

Experiences from the project.

• What did you learn?
• What went well? What did you get compliments for during the project?
• What things turned out easy that were thought to be difficult?

What could be done better next time?

• Technical solutions
• Project management
• Used tools
• Problem solving
• Communication

Within group

With customer

10 Concluding remarks from the project

Your short summary – how did you feel about it?

11 Comments about the course

Your feedback is important for developing the course. Note that comments will not affect your grade!

• Good aspects – more of what?
• Bad aspects – take away what?
• Anything new that should be covered?
• Other comments?

Thank you for the feedback!

12 Statistics

The statistics of the project will be printed out and shared in final presentations and the sauna party. In this Chapter you must fit on one page the following information (formatting is up to you):

• Name of group
• Size of group
• Name of customer
• Name of project
• Status of project
• Technologies used for implementation
• A bar chart of the weekly working hours per group
• A table of realized working hours / task /iteration (essentially Table 5.1)
• Lines of code (self-made/ reused) (LOC/SLOC)
• Number of classes and methods
• Number of revisions in version control
• If you have used some measurements/metrics, show how it has evolved during the project

13 References

APPENDIX A […Z]

Include appendices as needed.

Last modified: 2.2.2017 10:09 1/12