By Mitch on Friday 17 August 2012, 17:33 - Templates - Permalink
I've already posted a long list of templates on this blog. You can find them on the templates repository page.
There are templates for big projects, with one or more templates for every phase of a software development project. And there is the all-in-one template for very simple projects. This list lacks templates for simple projects that deserve more than a single document.
Here are the three templates:
- Software Development Management
- Software Specifications and Conception
- Software Verification and Tests
The advantage of this list is to have multiple specification conception and tests phases. The management template is filled at the beginning of the project. The Specification and Conception template is filled and updated each time these artifacts change. And the tests template is filled during each tests phase. They fit simple to middle size projects:
- Project timeline of 1 year
- Team of 4 developers
- Simple architecture (standalone or client-server)
They don't contain the risk management data. They shall remain in the dedicated templates: Risk management plan and risk analysis report.
More templates on my templates repository page.
Please, feel free to give me feedback on my e-mail email@example.com
I share this template with the conditions of CC-BY-NC-ND license.
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 France License.
Thanks for your post.
What are your thoughts on what a Validation Report should look like?
I can't think of any differences to the Verification Report template you have posted, except of course it contains the validation activities instead of verification ones. ie system and user acceptance tests.
I also think it is a good idea to refer to the Verification report in the validation report.
IMHO, the documentation needed for validation should more than that. You can make a reference to
-a verification tests report
-a validation tests report: same template as the verification, with the characteristics you mentionned
-and a validation review report , where company managers / QA-RA managers / end-users / doctors should validate the device.
It implies that a validation review shall be planned at the end of all tests (including clinical tests, if any) to ensure that the device is validated.
If your software is embedded in a hardware medical device, then the validation is for the whole thing software + hardware. So the validation can happen only after system (hard+soft) tests.
If our software is standalone, then the validation is for the software itself.