Improvement

            Few weeks ago my team (Pichu) had the chance to cooperate together to create an command prompt application that allows users to retrieve energy data from the Hale Aloha dorms; more information can be found about the previous project at this site Pichu. Then later on we had a chance to review another team’s application, which allowed us to learn how other people implemented and what other ways to implement the same application. More information about the team’s project that we reviewed is available here Teams.

            For this particular project we had to modify the application that we reviewed previously by adding the following three features.

·         set-baseline – sets the base energy consumption in a 24 hour period for each hour

·         monitor-power – monitors the source’s current power consumption

·         monitor-goal – monitors the power consumption to see if it met its base goal (set
                         in set-baseline)

These three features improves the existing application by modifying it into one that allows user to see actions instead of just typing in command and have the application return an message related to the command. For instance, the monitor-power command allows user to monitor the current power by having data printed in an interval (in seconds) supplied by the user. Another command that does actions is the monitor-goal, which also prints out messages to indicate if the source met its power goal base on the baseline; the baseline command sets the date to retrieve energy consumption for each hour in a 24 hour period.

            The most challenging about this time’s cooperation with my team was not communication. We were able to correct the problem this time by having more communication of checking on progress of the group and meeting at our free time. The main problem was trying to understand the code since style was different, and adhering to the original while coding the additional features. One of the rules is in software engineering is to adhere to the original when we pick up a project from the original author(s). Adhering to the original is not only about implementing the code to behave like the original; it also involves implementing the methods that would return the same type of output.

            I happen to implement the feature call set-baseline; my original idea was to return an array of 24 values of the energy consumed. However, the other classes that represented the original features returned an output of type String. Therefore, I had to adhere to the original by returning a String made up of the 24 values and split it into an array of type double in the class that processes the command (Processor).

            Besides same type of output, the other thing is the variable names. Since we want to keep it consistent with the original we had to name the variables as close to the original and make sure it is meaningful. As stated from “Elements of Java Style”, we have to use meaningful names for variables, methods and so forth.

           

            Through the course of adding the features to the application we encounter problem with both monitor-power and monitor-goal. The feature was to have the data print out continuously with each line of data being print out after certain interval (in seconds) and it quits when user presses the “Enter” button. We did try implementing to have it quit with any button but we weren’t successful. Initially the application would print out data for monitor-power and monitor-goal after we pressed “Enter”. In the end we were able to have it print out data base on the interval entered by the user.

Overall, this time the cooperation with my team has improved over these few weeks (since the very start when Team Pichu established). As mentioned before, this time we were able to meet at our own time instead of just contacting by email, phone, or Skype. Meeting up not only let us check on each other’s progress but also helped out with implementing the code. During the meeting one of my team members kept having trouble with PMD and FindBugs errors so we worked on what could be the issue. Although it took a little while, but it was worth it because team members should help each other out; helping each other is another factor in a successful team. We also checked on the progress of the team to ensure that we were meeting the deadline of each issue (decided by the team). This project not only allowed the team to learn from our communication mistakes, but also how we organize the issues at hand (e.g. who would implement which feature).