Final Report Template

The point of this document is to take a step back as a software engineer and evaluate and communicate what you have achieved and learned. It serves as a post mortem for you project.  You should report not only where you are now, but also how you got there and what was learned. Your customer should participate in the content of this document as well as reviewing it to ensure that they help define what was achieved and share their lessons learned as well. This report will be the historical reference for what was accomplished in your project.

Project Summary and Lessons Learned

Restate, BRIEFLY, the original objectives and requirements for the project. Explain how they evolved or changed over the course of the project. Summarize the technical challenges and choices that were made during the course of the project. List the key lessons learned. What, if anything would you do differently? List the achievement and successes of the project both technical and for customers and users. Include an architecture diagram or two to show in detail the deployment of the system and its various components or packages.  List recommendations for evolving the system in future releases.

Impact Assessment Report

This report is to show that you have taken into account the potential impact of the system you are building, beyond the narrow definition of requirements that was agreed to with your customer, in a manner that would be expected of someone who has been licensed as a professional engineer (P. Eng.).  As graduates of a certified software engineering program you will be eligible to apply for the P. Eng. Designation (see http://www.peo.on.ca for details). Your report should assess the following:

Legal Issues – Are there any applicable laws or legislation that will be relevant to the use and/or the construction of the system you are building?  How have you addressed them?

Standards – What technical standards are relevant to the software system you have built?  How have you ensured conformance?  These could be government standards, industry standards, or even just conventions that are followed in the market for your system.  Be sure to clearly identify what type of standard you are talking about and who is the relevant authority for the standard.

Liability Issues – What is the potential for liability either to yourself or your customer or users of the system, if it is misused or has flaws?

Societal Issues – What is the potential for this system to be beneficial or detrimental to society as a whole?  What have you done to address the potentially detrimental use?

User Community – What impact will this system have on the intended user community?  Have you taken steps to safeguard the interests of that community?

Financial Impact – Have the financial costs of deploying and supporting the system been fully evaluated for yourself, the customer, users, and society as a whole?

Quality Assurance Report

List in detail the tests you ran for your final test run, and the results of those tests. Identify for each test, the requirements, use cases or features it is intended to cover. Summarize the results of the test, and if possible correlate them to the requirements and objectives for the project.  This should include the current status of bug fixing.  How many bugs have been logged over the course of your project, how many still remain to be fixed.  Hand in at least one more additional QA report from a previous checkpoint to that show the progress you have made recently.  Ideally, I would actually see a series of QA reports reflecting that you had regularly scheduled test runs during the implementation phase of your project.

System Documentation

Your system should be completely functional and deployed to its users. You should put together a demonstration that highlights all the key features of the system AND shows why they are useful. Take screen shots from a live demonstration and put them in a document along with text that explains what is going on, and would be in sufficient detail so that a user could follow through the document to do the demonstration themselves.  If you are releasing documentation to your customer please identify each piece of documentation (e.g. user guides, build documentation, design documents etc.) and its purpose.  Please do include a copy of your documents with your final report (but it is not required).

Member Contributions

Summarize what each member of the team contributed to the project, ideally with reference to specific deliverables and/or milestones. If you feel one or more members of the team deserve special recognition for a significant contribution or achievement please identify them and describe the contribution or achievement.  Please note: such arrangements must be discussed and approved by me in advance.  Preferably, this should be done no later than by the delivery of your design report.