This post concludes the trilogy to Issue Driven Project Management or IDPM (see Part I: Make No Assumptions and Part II: A Technical Review for Your Thoughts). This time around, we were given only three commands to implement and thus, less time to complete the project; nevertheless, this did not stop this project from being a challenging one. From Parts I and II, we have already established that IDPM was difficult enough as is to put into practice. But here, we were given the challenge of building three new features into the code base belonging to the team whose system we, Team Pichu, had reviewed.
For the project, the three commands we had to implement were set-baseline, monitor-power, and monitor-goal (the project specifications describe them in more detail). The set-baseline command takes a given date and stores the power consumed for each of the 24 hours in that day. The monitor-power command continuously outputs the current power consumption for a given source at specified intervals in seconds. And the last command, monitor-goal, outputs the current power and states whether or not it is meeting its power conservation goal, as set by the user-specified goal and a prior call to set-baseline. Fortunately, we were able to successfully implement all three commands, but at the cost of a late submission on my part.
Many issues arose during development, including the usage of two Java objects that were new to us: Timer and TimerTask. A Timer object may start and stop multiple TimerTask objects, running each one once or at specified intervals. Before I could work on monitor-goal, our team had to make sure that monitor-power was working first, since monitor-goal builds upon it. It was odd that for each interval, over 5 of the same values for the power consumed would show up. Ultimately, we learned to use Timer's schedule method instead of scheduleAtFixedRate and not to call TimerTask's run method, since Timer's schedule method already calls run once.
The monitor-goal command took me a lot longer to implement than expected. One of the challenges I faced was how to implement the check for each hour without having to hardcode all 24 if-else blocks (and a simple extra whitespace had me debugging for another hour). In the end, I chose to go with the if-else blocks only because I was pressed for time. Perhaps if I had had more time to think about it, I could have implemented it in a different manner. Due to the fact that final projects for other classes took up much of my time, I made working on Version 2 a lot more difficult for me than it should have been. Initially, I had thought I could improve upon the original code base and fix a few bugs with the error-handling, but since that wasn't a priority and time was out of hand, I had to drop it as an invalid issue. It is rather surprising that we weren't required to fix the original code base created by the team whose system we reviewed. Nevertheless, I anticipate that the opposite is true as an industry best practice.
Group communication between all members of the team, this time around, however, was much, much better. We all got back to each other within a day or right away, even if it was to say that we couldn't work on the project at the moment. While communication was a lot better, I learned that it alone wasn't enough to move the project along at an appropriate pace. Motivation, physical and emotional drain, and time management issues are also strong factors that can affect the overall quality of a software project. Overall, despite possible incurred costs, I believe that the quality of our implementation of new functionality to an existing system was quite decent. It could have been better, but then again, software engineering is a full-time job, and as full-time students, there had to a tradeoff. In relation to the Three Prime Directives of Software Engineering as elaborated on in Part II, the system we first reviewed and then improved upon definitely completes a successful task and is easy enough for the user to download, install, and use. And although the code structure could be improved to streamline the addition of new features, it was moderately simple for a developer to improve upon the system.
No comments:
Post a Comment