Last updated: 9.5.2001
Software Engineering Project
University of Helsinki
Department of Computer Science
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 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.
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.
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.
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.
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.
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.
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.
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.
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:
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."
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Last updated: Sunday 6.05.2001 12:10:24
Last updated: Sunday 6.05.2001 12:10:39
/project/Venice
.
However, it is unclear how to use the directory from WinNT.
Last updated: Sunday 6.05.2001 12:11:46 EEST
Last updated: Sunday 6.05.2001 12:12:57
Last updated: Sunday 06.05.2001 12:13:13
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.
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.
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 ;)
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.
Next meeting on Monday, 9th of April. No meeting on 12th and 16th of April (Easter).
Last updated: Sunday 22.04.2001 19:23:22
Last updated: Sunday 6.05.2001 12:13:59
Report generated: Wed May 9 23:55:21 2001
Project planning 64.5 h Requirements analysis 161.2 h Technical design 327.2 h Implementation 302.5 h Testing 78.0 h Finishing touches 23.8 h TOTAL 957.2 h
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 TOTAL 252.0 h
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 TOTAL 256.0 h
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 TOTAL 219.8 h
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 TOTAL 229.5 h
Version 1.0
Last updated: 19.2.2001 12:00
Version 0.1 - First draft
Version 1.0 - First approved version
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 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).
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.
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.
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.
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.
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.
[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.
Version 1.5
Last updated:
Wednesday 9.05.2001 22:49:00 EEST
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. |
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.