Version 1.5
Last updated:
Wednesday 9.05.2001 22:49:00 EEST
Clients | ||
Claudio Riva | claudio.riva@nokia.com | |
Antti-Pekka Tuovinen | antti-pekka.tuovinen@nokia.com | |
Team members | ||
Petteri Kamppuri | petteri.kamppuri@helsinki.fi (Project manager) | +358 50 3317 961 |
Sami Ilonen | sami.ilonen@iki.fi | +358 50 309 5533 |
Hannu Laurila | hannu.laurila@japo.fi | +358 50 592 6400 |
Antti Pietarinen | antti.pietarinen@helsinki.fi | +358 50 548 2230 |
Supervisors | ||
Jukka Paakki | jukka.paakki@cs.helsinki.fi | |
Raine Kauppinen | raine.kauppinen@cs.helsinki.fi |
Our goal is to produce a web based viewing system for reverse-engineering data. The system is composed of two components: an application for modifying and creating layout and an applet for viewing the data. The data is read from XML based GXL files and is shown in UML notation. The viewer can filter out unneeded parts of the charts and focus on particular subsystems, view hierarchical componets and the relations between the components.
We will use a Java (Java version 1.3) for the implementation. The applet version will require a plugin that gives a web browser the capability to show Java 1.3 applets. The applet must work in at least one Windows-based browser (preferably Internet Explorer or Netscape).
The whole reverse-engineering visualization system can be broken into different subcomponents. These are:
We will use an iterative and incremental process model, which also could be classified as a spiral model. The first stage we will gather all the requirements for this project. After that we will analyze them and with the customer select a few use cases which we will implement in the first iteration. When we reach milestone 1, the customer can review the current system and select few more use cases which will then be implemented in the second iteration.
We will have a tight, but realistic schedule, which we will follow.
Inspections will be held 01.03.2001 (for the requirements) and 15.03.2001 (for the technical design).
All major dates set in the schedule are checkpoints. But we do have two major milestones in the project. At the end of each phase, we will have an formal tracking meeting where the document produced in that phase will be reviewed. After that the document can be accepted, accepted with changes or rejected and it must be modified and go through the formal review again
31.3.2001 At this point we will deliver the prototype system. We have some number of use cases implemented in the system. After that we will reconsider and analyze the system, and implement more use cases.
10.5.2001 Whole project ready.
This project should take about 240 hours per person. That adds up to a total of 960 hours. The time is divided into different tasks like this:
Documents produced in this project are shown in the list below.
The documents will be stored centrally at a group directory provided by the Department of Computer Science. The URL to this directory is http://www.cs.Helsinki.FI/group/venice/.
Testing plan is produced as a part of the technical design document in both of the design phases.
Even though we were not supposed to use CVS, we still did decide to use it for source code. All other files are kept normally within the project directory structure. Once in a while the project manager (or any other project member) can make a snapshot of the whole project directory as a backup. The directory can be zipped to conserve disk space and make it harder to use old files accidentally.
We have a change log, that everyone can update. That is a place to write things about the changes done and lessons learned. The change log is updated as often as possible and sensible, but always when a new version of the project is created.
We have regular meetings twice a week, mondays 9-11 and thursdays 11-13. These meetings will be kept at Nokia Research Center, if not specified otherwise.
Also there are formal tracking meetings once in two weeks. We will keep minutes of these meetings. Each meeting has an agenda, a chairman and a secretary.
We'll have two inspections, one for the functional specification and another for the technical design document. We will keep detailed minutes of these meetings.
These conventions may not be a part of a project plan. They are listed here, however, and may be placed somewhere else where they are more appropriate. We will use standard JavaDoc comments to comment our code. This allows us to generate documentation from the code automatically. Other conventions are:
At this moment we have a couple of risks. First risk is that the project gets too big, and we won't have time to implement it. Also, there is the risk that our incremental process model fails, and we cannot deliver the program as planned. It is always a risk when one changes the requirements in the middle of a project.
Other normal risks are people getting ill and maybe the customer changing demands in the middle of the project. We can't help people getting ill, but we can try to figure out what the client really needs in the beginning of the project so there wouldn't be any need to change the requirements in the middle of the project.
Below is links for related material.
This section is for reporting the progress of our project. This section is updated after each formal tracking meeting, and includes things suchs as the current status, being late, on time or ahead of schedule and maybe things we've learned or the difficulties we must face.
[22.4.2001] Inspection of the technical design went quite nicely. We had even had some pseudo code to back our design plans. This was something we didn't have for Milestone 1. Unfortunately our testing hasn't been very formal. Testing just has been something every coder normally does when coding. I'm beginning to wonder if we are ever going to make our goal of 240 hours per person or a total of 960 hours. On the other hand, I don't know if I really care if we can't meet that goal. Usefulness of the program is the main goal. Mostly we have to cut on implementation, but I think design is unaffected. Because design is good, even other people can implement the missing features.
[5.4.2001] We are running quite fine in the schedule. Time usage has a tilt toward requirements and design as opposed to the planned implementation. I think that this is just good, because it reflects the fact that we have really been designing and thinking, not just coding like crazy. Hopefully this will show in the final product. Testing has been almost non-existent, which we must fix. Also we are facing some serious performance problems, because Jazz is not living up to expectations. We knew it was slow even before we commited ourselves to it, so now one can just wonder why did we do it. I hope profiling will reveal some performance bottlenecks we can fix. Overall, I'm really happy now, that we have Milestone 1 ready, with almost everything planned. Now is a good time to do some cleaning and documenting, and the look forward to Milestone 2. This iterative process model seems to be good for semi-experimental projects like this one.
[17.3.2001] Inspection (see Minutes) for the technical design went not so smoothly. We found the design document to be incomplete and sometimes just plain stupid or wrong. These things must be fixed. The project is on schedule, sort of. Depends on the way of counting. If looked strictly from the 20 h/week point of view, then we are behind schedule. But if looked by what is written in the project plan then we are doing just fine. Anyways, not too much to complain there. Everything is quite fine, and I believe we will build a fine system.
[5.3.2001] Requirements inspection went smoothly while the project manager was sick. The requirements got accepted with changes, and those changes are mostly done now. We had to move the technical document's inspection later, because our client isn't available at the original date.
[19.2.2001] Project plan received some comments from Jukka Paakki. They will be addressed. Requirements are quite ready lacking some minor details. We should have a list of all features and the ones we are going to implement in milestone 1 and a sketch of the technical design by next monday.
[13.2.2001] Project plan has now been approved. We have been slow at start, but our client hasn't been available as much as we would have wanted. Requirements have to be ready for next monday, that will keep us quite busy.