Project Information
| Project: |
PIMS |
| Project Time-frame: |
2004-2009 |
| Attached Worksheets: |
|
| Related Documents: |
|
Project Assumptions
Process impact:
Project assumptions are the beliefs about the environment of the project
which, if false, will lead to project failure.
Recording them here will help consider whether there is sound evidence they are true.
For most assumptions, there is also a project risk that they turn out to be false.
This should be in the project's risk list.
TODO: Replace the sample text below with one or more assumptions.
- Change
- Laboratory practice will evolve.
A key assumption of the project is that it will not change faster
than the system can be revised to support it.
- NAME
- DESCRIPTION
Scope
TODO: Replace the sample text below with a clear statement of the
scope of your project. What are the high-level things that you plan
to do, and that you will not do? What are your important
simplifying assumptions? Try to guard against reasonable
misunderstandings that might arise if you did not explain the scope.
It can take the form of a paragraph, bullet list, in/out list, and/or
UML context diagram.
| In Scope |
Out of Scope |
| TBD |
TBD |
Constraints
Process impact:
This section lists the dimensions of the project in order of increasing flexibility.
First come constraints set by the project sponsor, then customer goals.
The dimensions at the bottom of the list
are the ones that the development team can adjust,
to meet the goals, within the contraints that have been set.
- Schedule
- 5 years, fixed by grant application.
- Staff
- Fixed by grant application. We may later attract partners who want additional features and make additional resources available.
- Cost
- Fixed by grant application. Mainly staff costs. We might find alternative sources for travel costs, but the budget is beleived to be correct.
- Quality
- Scientists' experimental data is their most precious asset. It is unacceptable to lose it. User-visible defects that do not in fact put data at risk
will still reduce users' confidence in the system and should be avoided.
- Scope
- The list of features wanted must be prioritised,
so that all the essential features are guaranteed to be delivered.
Deliverables
| Deliverable Name |
Description |
Delivery Date |
| Use cases |
Descriptions of planned interactions with PIMS.
Customers will prioritize them to decide the content of versions. |
Ongoing |
| Non-functional requirements |
Qualities the system must have.
A draft will be delivered for customer decision. |
TBD |
| Version 0.1 |
Proof of concept for design |
TBD |
| Other versions |
Incremental delivery of required functionality. |
Every six months |
| Defect fixes |
Repairs to baselined code. |
Ongoing |
| Help files |
Online guidance for users. |
With each version |
| User manual |
Printed description of system |
Annually |
| Maintenance documentation |
Design documentation, javadoc, and code comments. |
Ongoing |
| Tools |
Customization of software needed for development process,
incuding groupware and automatic build process. |
Dec 2004 |
Difficulty
For more detail, see Risks list.
TODO: This table helps you make an initial estimate of the difficult of your project.
In each category below, estimate the difficulty level.
| Name |
Score |
Total |
| Necessity |
4 | The system will enable some activities that were previously infeasible. |
| Failure |
3 | Loss of user's data is unacceptable. |
| Usability |
3 | Usability is important. Existing UI paradigms are suitable if applied well. |
| Team |
5 | The team are from several organisations. |
| Innovation |
3 | The development will use some techniques that are new to us. |
| Size |
4 | The development will take 10-100 developer years. |
| Schedule |
2 | The project is of fixed duration, the feature list is flexible. |
| Complexity |
2 | There are some design challenges but those components can be delivered early. |
| Customers |
5 | The project has several customers and they have little experience of commisioning software projects. |
| Life time |
5 | The deliverable is the first release of a long running product.
We have no product manager. |
| Average |
3.6 |
Greater than 3 indicates a challenging project. |
Difficulty levels:
- 1
- Straightforward, appears to be simple
- 2
- Familiar techniques will be sufficient
- 3
- Typical softare project
- 4
- Industry best practice will be required
- 5
- Innovative or exceptionally risky