3 Project Proposal
According to our additional information concerning "Use Cases and the Project Plan", we also estimated
the amount of work for our project.
This includes the following steps:
- Weighting Actors
- Weighting Use Cases
- Weighting Technical Factors
- Use Case Points
- Project Estimate
Weighting Actors
In this first step, we took a look at the actors, which we've located earlier and allocated them to a
certain group, depending on the weight of the actor, which can be simple, average or complex.
Then we multiplied the number of actors in each group by a weighting factor (1, 2 or 3).
- InternetUser - complex
Reason: The InternetUser utilizes the Virtual Museum (GUI).
- Designer - complex
Reason: The Designer has to be able to modify the Virtual Museum (GUI).
- DataCollector - average
Reason: The DataCollector extends the actor Designer but he does not have to be able to modify the Virtual
Museum. He just operates with input-fields for text and file-uploads (ASCII-like).
- Scientific DataCollector - average
Reason: Extending the DataCollector, same reason as above.
- Administrator - complex
Reason: Extending the Scientific DataCollector, same reason as above. Although the addtional configuration-
and administration tasks will also be covered by HTML-based ASCII-like interfaces, the complex structure of
the tasks performed by this actor led to the decission to label it complex.
- Database - simple
Reason: The Database is only another system with a defined API.
The assumptions made above result in:
1 simple * 1 = 1
2 average * 2 = 4
3 complex * 3 = 9
Ammounting up to a total of: 14.
Weighting Use-Cases
This second step is similar to what we did with the actors. We again had 3 different groups in which the
Use Cases were devided. The decision is based on how many transactions have to be carried out in a Use Case.
- Authenticate - simple
Reason: Login and authenticate procedures are of a standardized and rather simple nature.
- Enter data - complex
Reason: As there are several different kinds of data to be entered and due to the web-based file upload that
has to be implemented this seems to be a complex use case.
- Enter scientific data - simple
Reason: Most transactions are covered by use case "Enter data". Only difference are the additional
input-fields.
- View data simple
Reason: This use case is only responsible to display the selected data.
- View museum - average
Reason: This is a more difficult task than just displaying objects. It is responsible for displaying the
museum with its floors, rooms and showcases.
- Edit museum - complex
Reason: As the designers will be able to edit the museum rather freely, it might prove to be a rather
complex task to provide them with an easy-to-use but powerfull desing interface.
- Search - average
Reason: Although there will be two differnt search functions to be implemented, this should not confront an
experienced programmer with any problems.
- CreatePublications - average
Reason: Needed to provide an easy way to export data for publication on CD-ROM or paper. The use of XML
should simplify this task.
- Administrate - average
Reason: The database-access-system will be a rather complex part of the system. Nevertheless, such
procedures are well explored and thus not too difficult to implement.
The outcome of weighting the use-cases is:
3 simple * 5 = 15
4 average * 10 = 40
2 complex * 15 = 30
Ammounting up to a total of: 85.
Adding the actor's weights this gave a total of: 99 UUCP (unadjusted use case points).
Weighting Technical Factors
TCF = Technical complexity factor.
- Distributed System
T1: 2 * 2 = 4
Reason: There will be a seperate webserver and a database server which have to interact.
- Response or throughput performance objectives
T2: 1 * 3 = 3
Reason: Speed is likely limited by human input as well as it depends on network-speed.
- End-user efficiency
T3: 1 * 5 = 5
Reason: As there are many users at a time, efficiency is important.
- Complex internal processing
T4: 1 * 1 = 1
Reason: There are hardly any complex calculations to be made in our system.
- Code must be reusalbe
T5: 1 * 4 = 4
Reason: Nice and important.
- Easy to install
T6: 0.5 * 0 = 0
Reason: As our company is responsible for "installing" the system, the user has nothing to do with that.
- Easy to use
T7: 0.5 * 5 = 2.5
Reason: Our customer wishes a system which is intuitive and easy to use.
- Portable
T8: 2 * 3 = 6
Reason: It is important for our system to be portable. Nevertheless, thinking of our software's structure, it will not be very hard to implement that way (see XML).
- Easy to change
T9: 1 * 2 = 2
Reason: Good, if customer is not satisfied with the design.
- Concurrent
T10: 1 * 5 = 5
Reason: As our system will be multi-user oriented this is an important point.
- Includes Special Security Features
T11: 1 * 5 = 5
Reason: Security is important for authentication, group-management and encrypted data-upload (e.g. a plain web-browser SSL-encryption).
- Provides direct access for third parties
T12: 1 * 5 = 5
Reason: Our system is a customer-oriented software with direct access to the database.
- Special user training facilities are required
T13: 1 * 2 = 2
Reason: Just the administrator and maybe the designer will need training.
This results in a TFactor of 44.5. Therefore our TCF = 0.6 + (0.01 * TFactor) = 1.045.
Weighting Environmental Factors
- Familiar with Rational Unified Process
F1: 1.5 * 4 = 6
Reason: As we all have already worked a long time for SE AG we are very familiar with the Rational Unified
Process.
- Application Experience
F2: 0.5 * 4 = 2
Reason: Most of the team are very experienced concerning databases and the other parts of our system.
- Object-oriented experience
F3: 1 * 5 = 5
Reason: Most of the team had excellent educational experiences.
- Lead analyst capability
F4: 0.5 * 3 = 1,5
Reason: The constant change of project-leadership may be a problem.
- Motivation
F5: 1 * 5 = 5
Reason: Our team is really eager.
- Stable Requirements
F6: 2 * 4 = 8
Reason: The customer could turn out to be a threat for the stability.
- Part-time workers
F7: -1 * 2 = -2
Reason: Mostly full time workers for this project.
- Difficult programming language
F8: -1 * 2 = -2
Reason: No final decission on the used programming lanuage has been reached yet.
This result in an EFactor of 23.5.
The environmental factor (EF) equals (1.4 + (-0.03 * 22)) giving a result of 0.695.
Conclusion
Use Case Points
Finally, we calculated the use case points (UCP).
UCP = UUCP * TCF * EF
In our case:
UCP = 99 * 1.045 * 0.695 = 71.9
Project Estimate
We used 20 man-hours per UCP giving us 1438 total man-hours which leads to about 36 weeks each 40 hours
work.
As our team consists of 5 people, each will have about 8 weeks work plus 3 weeks for team issues.
This gives about 11 weeks with 40 hours each. As we will invest about 20 hours a week for this project,
our system should be ready within 22 weeks or 5 months.
Costs
Multiplying the total man-hours by 1.000,- ATS per hour, this gives a sum of about 1.4 Mio. ATS in total.