- set-baseline [tower | lounge] [date]
This command defines [date] as the "baseline" day for [tower | lounge]. [date] is an optional argument in YYYY-MM-DD format and defaults to yesterday. When this command is executed, the system should obtain and save the amount of energy used during each of the 24 hours of that day for the given tower or lounge.
- monitor-power [tower | lounge] [interval]
This command prints out a timestamp and the current power for [tower | lounge] every [interval] seconds. [interval] is an optional integer greater than 0 and defaults to 10 seconds. Entering any character (such as a carriage return) stops this monitoring process and returns the user to the command loop.
- monitor-goal [tower | lounge] goal interval
This command prints out a timestamp, the current power being consumed by the [tower | lounge], and whether or not the lounge is meeting its power conservation goal. [goal] is an integer between 1 and 99. It defines the percentage reduction from the baseline for this [tower | lounge] at this point in time. [interval] is an integer greater than 0.
These three commands were successfully implemented, however many difficulties were had during this process. The main difficulty our group had was using cycuc's system, since we were not familiar with their code, we first had to understand what exactly does what. Perhaps there is a little bias on our part since our group structured the CLI project a certain way, but cycuc's structure of their CLI was confusing. What ended up happening was that, we made changes to portions of their code so that we could successfully implement the three new commands. We implemented all the functionalities asked and also fixed some of the bugs left over by cycuc in this current system. As with the last project, we used the Issue Driven Project Management (IDPM) principals during this project. This time we were experienced with IDPM and things went along very smoothly. Our email exchange for this implementation reached close to 100. This was close to the number of emails we sent out for our CLI system. Similar to the last project I felt that most of the principals we had done successfully. We had a very good means of communications, all of us used the build tools available to aid our development and our system adheres to all relavent coding standards.
Keeping the three prime directives in mind;
1. Does the system accomplish a useful task?
Yes, the implemented commands give meaningful data in relation to WattDepot
2. Can an external user successfully install and use the system?
Yes, the most current version is located in the downloads page of cycuc's google code page. The userguide pages located in the wiki also has detailed instructions on how to use the system.
3. Can an external developer successfully understand and enhance the system?
cycuc has left a developers guide in the wiki page for information on enhancing the system. What we had done to modify cycuc's code was to document the system further by expanding the comments within the code.
What I feel we learned from taking over another group's system is that to fully enhance the system on hand you must know exactly what each line of code does. The difficulties we faced was understanding the structure of the code. We all have our own ways of thinking. In essence through this project I developed my software engineering skills and skillset.
These three commands were successfully implemented, however many difficulties were had during this process. The main difficulty our group had was using cycuc's system, since we were not familiar with their code, we first had to understand what exactly does what. Perhaps there is a little bias on our part since our group structured the CLI project a certain way, but cycuc's structure of their CLI was confusing. What ended up happening was that, we made changes to portions of their code so that we could successfully implement the three new commands. We implemented all the functionalities asked and also fixed some of the bugs left over by cycuc in this current system. As with the last project, we used the Issue Driven Project Management (IDPM) principals during this project. This time we were experienced with IDPM and things went along very smoothly. Our email exchange for this implementation reached close to 100. This was close to the number of emails we sent out for our CLI system. Similar to the last project I felt that most of the principals we had done successfully. We had a very good means of communications, all of us used the build tools available to aid our development and our system adheres to all relavent coding standards.
Keeping the three prime directives in mind;
1. Does the system accomplish a useful task?
Yes, the implemented commands give meaningful data in relation to WattDepot
2. Can an external user successfully install and use the system?
Yes, the most current version is located in the downloads page of cycuc's google code page. The userguide pages located in the wiki also has detailed instructions on how to use the system.
3. Can an external developer successfully understand and enhance the system?
cycuc has left a developers guide in the wiki page for information on enhancing the system. What we had done to modify cycuc's code was to document the system further by expanding the comments within the code.
What I feel we learned from taking over another group's system is that to fully enhance the system on hand you must know exactly what each line of code does. The difficulties we faced was understanding the structure of the code. We all have our own ways of thinking. In essence through this project I developed my software engineering skills and skillset.
0 comments:
Post a Comment