Project plan | Time usage reports | Change log | Meeting minutes | Functional specification | Technical design document | Implementation document | Testing reports | User's Manual | Final report

Software Engineering Project:
Venice

UML Visualization Tool

Final report

Last updated: 9.5.2001


Software Engineering Project
University of Helsinki
Department of Computer Science

Contents

The team and the goal
Timeline
        Iterative process model
        Slow start and big requirements
        Design, design
        Coding...
        To test or not to test, that is the question
        Project plan adn time usage or Make a plan and stick to it
Achievements
        Produced documents
        Code
        What was planned and worked
        What was planned but didn't work
        What went right
        What went wrong
        What did we learn
Meetings
Individual opinions
        Sami Ilonen
        Petteri Kamppuri
        Hannu Laurila
        Antti Pietarinen

Appendix A: Meeting minutes
        Formal tracking meeting 12.02.2001
        Formal tracking meeting 19.02.2001
        Inspection of requirements 01.03.2001
        Inspection of technical design 15.03.2001
        Formal tracking meeting 05.04.2001
        Inspection of technical design 19.04.2001
        Formal tracking meeting 03.05.2001
Appendix B: Time usage report
Appendix C: First version of project plan
Appendix D: Final project plan

The team and the goal

The development team was Sami Ilonen, Petteri Kamppuri, Hannu Laurila and Antti Pietarinen. Our client was Claudio Riva at the Nokia Research Center. Jukka Paakki was the responsible instructor from the Department of Computer Science at the University of Helsinki. Petteri Kamppuri was also acting as the project manager in addition to his duties as a member of the development team.

Our goal was to create a research prototype of a software architecture visualization tool, that uses UML notation for visualization. Current tools are mostly unable to show hierarchical data and don't use UML, so the need for Venice is clear.

The team divided the task as it see fit. Quite early on each member began to specialize on particular topics. Personal preferences and expertise played a role in selecting tasks for everyone. Hannu was responsible for setting up the JAZZ system, later on others did work on the visualization too. Antti did the big part of requirement's images and GUI, Sami did ModelStorage also a lot of work for requirements. Petteri did the main application framework, excluding some commands that were done by others. Hannu was also our UNIX admin, creating our project directory structure, setting up our CVS and writing instructions so that everybody could use it.

Timeline

The project was started January 19th 2001 and was finished May 10th 2001. The project lasted almost four months. But when our slow start and all kinds of vacations and holidays are taken into account, the project was actually just over three months long.

Iterative process model

At some point when we were finalizing the first project plan an iterative process model was suggested. We felt like it could be the right thing for this, because some features might prove themselves useless or new features would be needed. These kinds of things are hard to predict before the tool could actually be used. So we chose an iterative process model with two iterations, about the maximum for a project of this lenght. We decided that we would have two milestones.

Slow start and big requirements

The beginning was somewhat slow, because our client did not have a clear vision of his needs. Those needs were finally documented in the requirements document. The process of identifying all the requirements called for an active participation of the development team. This may be a bad thing, but also a good thing. We, of course, wanted to keep the number of requirements at minimum, but the client wanted more. Then we decided that we would implement only a subset of the requirements, and that gave us a better motivation to focus on finding everything the client might dream in a tool like this. This was our real requirements phase. In the second phase we just selected which of the already specified features we would implement for Milestone 2.

Design, design

In our first design phase we built the main application architecture. Work progressed slowly, because we were quite unsure what was needed for our application to work nicely. In the end we had an architecture of somekind and it did what we wanted, at least for milestone 1.

After first milestone was completed and features for second were chosen, we started on looking at the hard things. Moving relationships seemed hard and we designed the functionality needed for those operations for a long time. Not long enough. We ran into serious trouble in the end, and were unable to finish relationship moving features. This was very unfortunate, but we did seriously underestimate the greatness of the task. We did get some extra features in, but probably not at the expense of planned features.

Coding...

First milestone was manageable. Mostly the hard part was JAZZ, and we had all the major things designed. What really helped was that we were trying things, making a prototype of our features, at the same time we designed them. That really helped the design process and payed itself back when implementing them for real.

Second milestone wasn't that nice. Many of the hardest features (meaning moving relationships) were designed inadequately, which naturally led to problems when implementing. In the end inadequate design took its casualties, and we were left with buggy features. One can only wonder that could we have made those, had we had a better design.

To test or not to test, that is the question

We had way too much code in the program, about 10.000 lines with comments included. We had plenty of Javadoc comments, but still it boils down to about 6000 tight lines of code. Our test data was also inadequate, because it was only when we got larger and better test models we began to realize something was wrong with our features. The first test model just couldn't show the bugs that came out. We really would have liked to test the program for a longer period of time.

Project plan and time usage or Make a plan and stick to it

After we had agreed on the iterative process model, we finished the project plan. We are slipping from the plan almost all the time, but only for a few days. The plan was a bit optimistic, and didn't take into account various holidays, for example. We also had to move some of our dates, because our client wasn't available on those times. On the whole, it seemed that making the documents always took more time than what we had planned.

We reached our planned total of 960 hours of work. Our time division wasn't exactly as planned. Technical design took almost 90 hours more than what we had planned. Implementation came laking some 60 hours. Testing took a little longer than what was planned. Probably the testing part was underestimated. Finishing touches was only a marginal part of the project.

A detailed view of time usage is in Appendix B.

Achievements

Produced documents

We produced all the documents we were supposed to produce. They did take some time to write, but all of them were useful. We produced:

Code

Here is an evaluation of Venice source code. SLOC count does not include comments. As can be seen, Venice as a commercial product would have cost a lot. This estimate shows that Venice would have taken around 16 months to complete. There were four developers, and we did the project in a little over three months. Surely this project had too much coding involved to be really successful.

Total Physical Source Lines of Code (SLOC)                   = 6052
Estimated Development Effort in Person-Years (Person-Months) = 1.32 (15.89)
 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Estimated Schedule in Years (Months)                         = 0.60 (7.15)
 (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers  (Effort/Schedule)    = 2.22
Total Estimated Cost to Develop                              = $ 178910
 (average salary = $56286/year, overhead = 2.4).
Please credit this data as "generated using 'SLOCCount' by David A. Wheeler."

What was planned and worked

Most planned features actually made it to Venice. We created a software product, that visualizes architectural information using semi UML notation. The user can zoom in and out, pan and move visualization components. File handling works and many others.

What was planned but didn't work

We couldn't produce relationship moving functionality. It would be used to hide information and make it more abstract. Initial design and testing showed the feature to work. After a while we got new and better test models. Then we discovered a little bug that was easily fixed. After a while we realized couldn't work in any case. The design for the feature was bad. This happened in the last week. Then it was too late to do anything about it. The features are there, but don't work as they should in all possible combinations. They would require a great amount of rethinking to make them work.

What went right

We created nice requirements for a tool. Finding all those requirements took time, but it payed off. We could actually deliver something of an useful tool. That was really nice. We were struggling with Jazz performance, but at last meters Hannu was able to fix it. Now Venice actually performs quite well.

Our team dynamics were good. We got well together and managed to solve all our interaction problems. Our client was nice and supportive. Everyone in the team contributed equally and everyone was enthusiastic about the project. It had an interesting subject, and most of us would like to use a similar tool. Motivation naturally suffered some ups and downs, but most of the time we were motivated to do the work.

The Nokia Research Center environment was a positive experience. We had our own workstations and work space where we could do our work together as a team. Conference rooms were good and using laptops and video projectors we could use our tool and browse our documentation during the meetings.

What went wrong

Email proved to be an unoptimal way of communicating. Many times when somebody was at home working on the project, he would send tons of emails with tons of questions and nobody would answer them. Maybe IRC or something like that would have better suited our needs. Had we worked more on the NRC site, then maybe we would not have had so many communication problems. But it wasn't that nobody wanted to reply to peoples' email, it was just that there was so much of it and the questions were many times difficult to answer.

Our test models were too small and contained too little different types of data. So the operations we could do on the test models were limited. This caused us to believe our code was right, even though it wasn't.

What did we learn

Testing with realistic example data is crusial in product testing.

We all learned something. We all had our previous knowledge and could give some part of that to the other team members.

Meetings

We met twice each week (except for holidays). We had seven formal meetings of which we kept minutes. Three of those meetings were technical inspections of a document at the same time. Almost all meetings consisted of tracking our progress and addressing some pressing issues. Meeting minutes can be found in Appendix A.

Individual opinions

Sami Ilonen

The project was quite challenging. We had to learn a many things that we previously had very little knowledge. For me the perhaps the biggest challenges were XML and groupwork in general. My personal workload wasn't as expected all the way through the project. I probably wrote less codelines than rest of the group because the role of my subsystem was not as essential as we first thought.

Was the project a success? Well the software doesn't do all the things that were in the requirements, so I guess we were unsuccessful if only the technical side is considered. However, the project is definately a success if the evaluation is based on what we learned. It could even be argued that we wouldn't have learned as much if everything would have went smoothly. And even the technical side is quite close. I guess we just took a bit more than we could chew. The main problem was that in the early stages of the project we lost valuable time, because we really had no idea what we were doing. We should have had meetings more frequently.

I have nothing bad to say about the other members of our group. The client/instructor (Claudio Riva) also did a great job. The tools and support provided by NRC were OK.

Petteri Kamppuri

Well, this is a personal post mortem analysis from my point of view. First of all, I'd like to say that the job of a project manager is a tough one. This was my first try as a project manager, and can't say that I was very good at it. Of course I didn't even know about the things a project manager is supposed to do when we were starting the project, but I was eager to learn.

I don't know how much I've learned, but at least I've got the chance to try being a project manager. I did have the great pleasure of making project schedule and associated Gantt charts, trying to think what everyone should do, making decisions and generally guiding the project to the direction I wanted, including our own development environment and custom tools.

I cannot fully analyze my success or failure as a project manager, partly because I wasn't managing that much. I had almost as much responsibility on the actual development as others, and that restricted my managerial activities, maybe a bit more than what I would have wanted. On the whole, it was a nice experience for me.

The actual project was nice, too. We had a really slow start, partly because we didn't realize that we had to work hard from the beginning, and partly because our client was away a lot, and he was the only who could tell our requirements. Even after the beginning we made quite sloppy progress, but I felt that I couldn't be asking more from others than what I was doing. So partially I blame myself for being too lazy. As the manager, I felt that I should have been an example worker. I was sick for a week and that shows in the number of hours I put on the project.

After our gargantuous requirements phase, which gathered a big collection of Claudio's favourite features, we began the design phase. I think that our design phase was not as effective as it could have been. On the other hand at least I really don't have that much design experience in various software systems, and that makes designing just plain hard thing to do.

The Nokia working environment was an interesting acquaintance. This was the first time I had been a part of a really big organization and it was nice to see how things ran there.

Last I'd like to give my thanks to Claudio, for being a nice client and great instructor. As Venice was a prototype Claudio wasn't quite sure what he wanted of it, but the things cleared out during the requirements phase. He also had many valuable comments on software design. Also he (with the help of his Nokia coworkes) suggested the iterative process model, which proved to be a great success, at least in my mind.

Hannu Laurila

My main view on the project is that it was quite successful despite that we could not fix the bugs identified in the relationship moving code before the end of the project.

Great thing in the project was the motivation - there was a true need for this kind of tool and I could even imagine myself using the tool someday when trying to figure out how a particular software has been built. The project was challenging and the iterative process model was a must for the project. Both the application area and the not-so-well-documented Jazz graphics library which we used were totally new things for everyone in the group. We would have had no hope designing all the features before first 'getting in touch with the things'. So thanks to Claudio and Alessandro for suggesting iterative process model.

Project's size was a problem. For the tool to be really useful, many features had to be implemented and we wanted it to be useful. More time would have been needed for a project of this size.

I learned a lot of software project work. For me this was the first time I participated in a software project with more than 2 developers. Things had to be designed and the designs had to be communicated to others. Also the importance of testing and acquiring as much test data as possible is now clearer to me.

I have no complaining on the team. The team (including our client) was really OK and everyone carried out their tasks. We all had a similar sense of humor so there were no problems working in the team. Sometimes it was hard to express myself in English but that was natural and acceptable.

It was nice to work at NRC.

Antti Pietarinen

First two or three weeks of the project were quite slow and I had quite blurred picture about the project goals and what we were about to do during this project. But luckily it got clearer quite soon, mostly because our client was more available.

After first couple of weeks co-operation worked very well with client and he guided us quite well. We also got along very well inside the group.

My personal workload come up to expectations. According to my earlier experiences workload increaces to the end and it was the case also in this project.

Project subject differed quite a lot from the original description but turned out to be very interesting. So motivation was no problem during this project.

Our working environment in NRC was very nice and co-operation worked well as mentioned before. Project language did not bother at all. I think that we all understanded each other very well despite of different english skills.

Our software engineering group was OK. All were well motivated and workload was devided quite equally, thanks to our manager. Everyone had their own responsibilities.

Working in this kind of environment was interesting and nice experience.

Appendix A: Meeting minutes

Formal tracking meeting held on February 12th, 2001

Last updated: Sunday 6.05.2001 12:10:24

Present:

Minutes:

  1. Petteri Kamppuri opened the meeting at 09:45

  2. The following agenda was accepted for the meeting:
    1. Approval of the project plan
    2. Review of the use cases
    3. Time of next meeting

  3. Project plan approval
    The project plan was approved with changes. See appendix for list of changes.

  4. Review of the use cases
    Use cases prepared by Antti were reviewed. Use cases were found good. The following comments arised:
  5. Next formal tracking meeting will be held on Monday 19.1.2001 @ 09:00AM

  6. Petteri Kamppuri finished the meeting at 11:00

Appendix: changes to the project plan




Formal tracking meeting held on February 19th, 2001

Last updated: Sunday 6.05.2001 12:10:39

Present:

Minutes:

  1. Petteri Kamppuri opened the meeting at 09:30

  2. The following agenda was accepted for the meeting:
    1. Jukka Paakki's comments on the project
    2. Review of the requirements specification
    3. Project process tracking

  3. Jukka Paakki brought the copyright transfer agreement with him. Project members signed the agreements.

  4. Jukka Paakki gave the following comments on the project plan:
  5. Requirements specification was reviewed. Some changes were proposed and they are listed in appendix. When the changes are ready, Claudio will give final comments by email.

    All features listed in requirements specification will be listed and numbered so we can easily select which ones will be implemented in milestone 1 and which will be implemented later.

  6. Project status tracking

    Petteri told that we have now spent about 200 hours on the project and according to 20h/week plan we should have spent about 320 hours now.

  7. Next meeting
  8. Other notes

    NRC has finally created a group directory for us. It can be accessed from UNIX systems at location /project/Venice. However, it is unclear how to use the directory from WinNT.

  9. The meeting was finished at 11:45

Appendix: changes to the requirements specification




Inspection of project requirements held on March 1st, 2001

Last updated: Sunday 6.05.2001 12:11:46 EEST

Present:

Minutes:

  1. Hannu Laurila opened the meeting at 11:15.
  2. The requirements document was inspected and approved with the changes described in the appedix.
  3. Hannu Laurila closed the meeting at 13:00.

Appendix: changes to the requirements specification




Formal inspection of technical design document held on March 15th, 2001

Last updated: Sunday 6.05.2001 12:12:57

Present:

Minutes:

  1. Chairman Petteri Kamppuri opened the meeting at 11:25

  2. The following agenda was accepted for the meeting:
    1. Project tracking
    2. Claudio's GXL example
    3. Formal inspection of technical design document

  3. Project status tracking

    Petteri told that we have now spent about 400 hours on the project. According to 20h/week plan we are a little late. There is no need to worry because technical design is in good shape and coding can start after a slow start.

  4. GXL example

    Claudio introduced his GXL example. There was a problem with defining dependencies. There was discussion about the problem. Decision was that dependencies are described as edges with attributes (source,destination, type and name). This is not according to schema presented in requirement specification. Changes to schema needed. Presented example is adequate for the time being.
  5. Formal inspection

    Technical design document was inspected. Because of a lot of material in design document, it was decided that inspection will not be as thorough as it could be. Some changes was proposed and they are listed in appendix.
  6. Next meeting

  7. Other notes

    Demo applet should be put into web.

  8. The meeting was finished at 14:10

Appendix: changes to the technical design document and notes about things that need more attention




Formal tracking meeting held on April 5th, 2001

Last updated: Sunday 06.05.2001 12:13:13

Present:

Minutes:

  1. Petteri Kamppuri opened the meeting at 11:10

  2. The following agenda was accepted for the meeting:
    1. Project process tracking
    2. Review of milestone 1 build of the system
    3. Selection of features to implement for milestone 2
    4. Setting date for formal inspection of technical design document for M2

  3. Project process tracking and planning

    Schedule: Requirements for M2 should be ready today. We are on schedule, because requirements are already ready and we are now just selecting the features to implement for the second milestone.

    Testing of the product: A testing plan should be prepared for model storage and visualization subsystems. An integration testing plan should be prepared for GUI/AppModule subsystems. For model storage we can compose automatic tests.

    Documenting the system: Class descriptions will be removed from technical design document and be replaced by links to the JAVADOC documentation which includes up-to-date information on the classes. Implementation document will not duplicate description of the technical design but instead describe the build system and source code organization we are using so others can continue to work on the product.

  4. Review of milestone 1 build

    Features: Milestone 1 has more features than was planned. Features 1, 3, 12, 16, 30 and 31 from the requirements specification have been implemented.

    Performance: There are performance problems. Drawing relationship arrows and selecting elements are slow for some reason. We had a long discussion on the performance aspects and some ideas for improving the performance was proposed. However, we decided first to find a JAVA profiling tool and see where the time is spent - is it in the JAZZ library or in VENICE code. Profiling can be also included in the testing plan.

    Arrows going from component to interface should be drawn like described in the requirements document.

  5. Selection of features to implement for milestone 2

    The two most important features to implement in M2 are saving and loading the layout of the visualization. In addition to that, as many as possible of the features 2 and 4-10. They are the following:

    Client suggested also implementing feature 13 (group/ungroup) but that was considered as an editing feature which we were not supposed to implement during the project ;)

  6. Setting date for formal inspection of technical design document for M2

    Technical design phase for second milestone end on 13.4.2001. However, because of Easter, the inspection for the document will be held on 19th of April.

  7. Next meetings

    Next meeting on Monday, 9th of April. No meeting on 12th and 16th of April (Easter).

  8. The meeting was finished at 13:00



Formal inspection of technical design document held on April 19th, 2001

Last updated: Sunday 22.04.2001 19:23:22

Present:

Minutes:

  1. Chairman Petteri Kamppuri opened the meeting at 11:25

  2. The following agenda was accepted for the meeting:
    1. Formal inspection of technical design document

  3. Technical design was approved with changes (see. Appendix A).
  4. Petteri Kamppuri closed the meeting at 13.30.

Appendix A:




Formal tracking meeting minutes 03.05.2001

Last updated: Sunday 6.05.2001 12:13:59

Present:

Minutes:

Project progress

  1. Project should be ready on 10.05.2001
  2. Required documents:
    usermanual, testing document, requirements, project plan, design document, meeting minutes and final report.
  3. Descriptions of test programs and all test cases should be included to testing document.
  4. Project evaluations:
    "Jazz is not so good", Claudio. It has performance problems which are not solved yet. Project has been "nice experiment" of the subject.
  5. Problems:
    Usability, stability, performance.
  6. Noticed corrections:
    Add stuff to gxl-reader to accept incorrect source gxl (skip unknown things). Hiding labels by default. Packages closed by default.
  7. Other things to do:
    Moving source codes available for Claudio to NRC.

Final report

  1. Summary of the project, should include:
    Hours spent, meeting minutes (appendix), achivements to original requirements, things not done, extra features and reasons. Personal subjective evaluation of the project.

Project demo

  1. 12:00 10.05.2001. Present: Raine Kauppinen (Paakki invites), Jukka Paakki, Claudio Riva, Antti Pietarinen, Hannu Laurila, Sami Ilonen, Petteri Kamppuri.
  2. All documents and code should be ready. Final report in paper (3 copies).

Appendix B: Time usage report

Time usage report

Report generated: Wed May 9 23:55:21 2001

Total

Project planning 64.5 h
Requirements analysis161.2 h
Technical design327.2 h
Implementation302.5 h
Testing 78.0 h
Finishing touches 23.8 h
TOTAL957.2 h

Antti Pietarinen

Project planning 11.0 h
Requirements analysis 52.0 h
Technical design 75.0 h
Implementation 86.5 h
Testing 24.5 h
Finishing touches 3.0 h
TOTAL252.0 h

Hannu Laurila

Project planning 14.5 h
Requirements analysis 29.0 h
Technical design 93.0 h
Implementation 90.0 h
Testing 20.5 h
Finishing touches 9.0 h
TOTAL256.0 h

Petteri Kamppuri

Project planning 20.0 h
Requirements analysis 32.2 h
Technical design 76.2 h
Implementation 58.5 h
Testing 21.0 h
Finishing touches 11.8 h
TOTAL219.8 h

Sami Ilonen

Project planning 19.0 h
Requirements analysis 48.0 h
Technical design 83.0 h
Implementation 67.5 h
Testing 12.0 h
Finishing touches 0.0 h
TOTAL229.5 h

Appendix C: First version of project plan

Project Plan

Version 1.0
Last updated: 19.2.2001 12:00

Version history

Version 0.1 - First draft

Version 1.0 - First approved version

Members

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

General description

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.

Implementetation environment

We will use a Java applet (Java version 1.3) for the implementation. The applet requires 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).

Subcomponents

The whole reverse-engineering visualization system can be broken into different subcomponents. These are:

Process model

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.

Schedule

We will have a tight, but realistic schedule, which we will follow.

Gantt chart of project schedule

Milestones

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 review of the document produced in that phase.

Milestone 1

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.

Milestone 2

10.5.2001 Whole project ready.

Estimated time usage

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:

Time usage chart

Documents

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.

Versioning scheme

Each version of the project is kept in a separate directory. We won't be having any fancier versioning scheme or system, such as CVS. When a new version is released, the whole project directory, including documents, source code, web pages etc, is copied to a new one which is clearly labeled with the new version number and date. The directory can be zipped to conserve disk space and make it harder to use old files accidentally. This is important, and this practice must be followed.

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.

Meetings

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.

Inspections

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.

Coding conventions

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:

Risks

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.

References

Below is links for related material.

Status report

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.

[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.

Appendix D: Final project plan

Project Plan

Version 1.5
Last updated: Wednesday 9.05.2001 22:49:00 EEST

Version history

Date Version Modifier Comments
25.01.2001 Version 0.1 Petteri Kamppuri First draft
19.02.2001 Version 1.0 Petteri Kamppuri First approved version
24.02.2001 Version 1.1 Petteri Kamppuri Added final report and user's manual to documents list. Also revised schedule to contain inspections and set dates to those inspections.
05.03.2001 Version 1.2 Petteri Kamppuri Moved technical design inspection to be held three days later, 15.3.2001.
17.03.2001 Version 1.3 Petteri Kamppuri Added status report entry after technical design inspection.
25.03.2001 Version 1.4 Petteri Kamppuri Added mention about the CVS system we use.
05.04.2001 Version 1.5 Petteri Kamppuri Updated project status.

Members

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

General description

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.

Implementation environment

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).

Subcomponents

The whole reverse-engineering visualization system can be broken into different subcomponents. These are:

Process model

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.

Schedule

We will have a tight, but realistic schedule, which we will follow.

Gantt chart of project schedule

Inspections

Inspections will be held 01.03.2001 (for the requirements) and 15.03.2001 (for the technical design).

Milestones

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

Milestone 1

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.

Milestone 2

10.5.2001 Whole project ready.

Estimated time usage

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:

Time usage chart

Documents

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.

Versioning scheme

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.

Meetings

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.

Inspections

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.

Coding conventions

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:

Risks

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.

References

Below is links for related material.

Status report

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.