ILibrary interface) to query additional libraries. When they add the locations of these external library classes to the XML file, they will be able to use the program to query the additional libraries as well. Of course, previous functionalities such as sorting, filtering results by due date, and periodic email alerts, are still offered.
Group Process
We divided up the project into various issues and each worked on some issues. For the most part, we worked separately, although there were some times when we worked together. For example, I worked with Daniel Arakaki and Daniel Tian on the first version of the Configuration Manager, and I worked with Jeho on the second version. We tried to meet as a group every Monday, Wednesday and Friday, although not all members were able to attend each meeting. During these meetings, we checked in on our progress and worked individually together--that way, if we had any questions, we could get some immediate feedback. We also discussed the project using instant messaging and email.
Software Metrics
Below: Cumulative Member Dev Time. I am the red-orange line.
Below: Cumulative Member Commits. I am the green line.
Some of the Hackystat statistics make it look like I did dramatically more work than the rest of my team. While I certainly did put a lot of time and effort into this project, I think the statistics are a bit exaggerated. For example, I am sure I did not work on the project for 9.3 hours on the first day. My commit figures are inflated because I did the initial upload of the DueDates-Blue system (on which this system is based), and also because I renamed some packages and moved some files, which had a ripple effect and changed many other files. Also, the Hackystat statistics do not account for people working on the wikis or using an external editor to work on the HTML/CSS. Further, Jeho's Hackystat sensor was not working for the first week.
Is our project healthy? It's healthy enough, I think. In any group project, in the "real" world or especially in a classroom setting, there will always be some team members who do more work than others. People have different schedules and work habits, different commitments on their time, and different levels of interest and motiviation. It would be naive to think that each member would contribute equally. I just happened to have more time than some for this project.
While the value of continuous integration is undoubted (I cannot imagine trying to share code between four people), I wonder about the concrete applications of software metrics. If the statistics show that a project is "unhealthy", will that really change anything, or is it just telling you what you already know? Will it change the group dynamic? Will managers adjust the team? What about the circumstances surround the statistics that the metrics do not measure? I guess the question is, what is to be done with these data?
Problems and Improvements
In terms of coding, there were no significant problems. Getting the forms to submit all the appropriate data was a little bit tricky, especially since the Wicket API documentation is not very informative, and often the examples I found online were either too introductory or missing the key part. After I figured out how the data models should work, however, it was pretty straightforward.
We could have worked better as a group. In a two-person group, it was much easier to coordinate and divide up the work. For this larger group, some members started late, and sometimes they would say they would do something and it would take a lot longer than expected. If every meeting attended each meeting, we could have kept on track better, which in turn would have enabled us to divide up the work better.
One thing I noticed about myself is that, while I generally knew what to do and how to do it, sometimes I had trouble communicating my ideas to my teammates in words, and I found it much easier to just show them. I think I need to practice these skills more by working on more group projects.
No comments:
Post a Comment