Recently in our software engineering class, we were introduced to a development tool that for an open source software developer, is a godsend. The concept is a fairly simple one, where a project that a developer wants to work on and develop is open to the public to contribute and continuously add content to improve whatever application is being developed. This project management tool under the umbrella names of “Continuous Integration” and “issue driven project management” are a culmination of several tools, and together are a very powerful development engine that provides a workbench for developers to build upon a particular project. So, with our newly acquired knowledge of the Wattdepot API, we were asked to form groups with two other classmates to whether the climate of a group developed project, and build a command line interface for wattdepot using the project management tools.
As part of the development of our project, we had to create and continuously build upon an associated project page that would provide information for other developers to acquire knowledge about the project. Part of the issue driven development provides updates on the project page of who is doing what, and what has been completed. “Issues” are tasks or parts of the application that need to be coded and are assigned to members/contributors of the project. Continuous integration is the monitoring part of the development, and instead of having the developer constantly download and compile the sources, the CI server automatically does this and updates in real time when there is a compile error. As an all encompassing lesson for this portion of the semester, after completing our project with group members, we have been asked to also to a technical review of another groups project and their development using the project management tools mentioned previously. Below is my technical review of the group.
Review Question 1:
As far as functionality of the program, all of the commands appear to be working properly. The messages/prompts that appear when an error occurs are quite user friendly. The messages are clear and concise, and offer a simple explanation for why the error may have occurred. However, in the beginning of the program when it is first run, it would be helpful to offer a brief explanation to the user of what exactly this program does and possibly some initial instructions of how to enter commands and what to expect when these commands are entered. The only instructional prompt appears when the “help” command is entered, and may be confusing to a potentially less “savvy” user who may be using the program for the first time. Overall, the first prime directive has been satisfied in this section of the technical review (the system successfully accomplishes a useful task).
Review Question 2:
The associated project site for this command line interface program is well developed and has been populated with code examples and images of what the interface actually looks like. What is good about this site is that the navigation through the site has clearly been logically thought out with the user’s experience kept in mind. The links that take the user from one page to the next provides them with the appropriate resources to implement the level of development that they are looking for, whether they choose to simply run the application or choose to contribute and build upon it. There is a clear set of step by step instructions that the provided for installation and even provides download links to the appropriate software versions if needed. If there is one thing that frustrates a user or developer most, it is to read about a certain piece of software that must be installed prior to running the target program, and having to locate that particular package on the web somewhere. This site provides easy access to the software, and is fully self contained and sustainable.
Another user/developer friendly feature is that in the download section, they provide both the source and executable jar as separate files available for download. This makes the experience for a user who simply wants to run the application much more enjoyable because in order to have the program run, all they have to do is download the jar by itself; they don’t have to download all of the source files in look for the executable in that folder.
It appears that all of the commands that are entered into the system produce adequate messages and results for what is expected. When there is incorrect input or the format is not quite right, the program is able to distinguish between what type of error occurred, and the appropriate message to print to the user. For example when a completely invalid command such as “test” is entered, the interface responds with an error message of “Error: “test” is an invalid command. Please try help for a list of valid commands”. This explains to the user that they must seek out the valid commands in the help document. When the user enters a command that is close to a valid command but has the wrong format, the system responds with “Source does not exists”. This alerts the user that they are getting closer to producing a correct command, but may be entering something incorrectly. The only sort of issue that I had while testing the system was that I think the help text could have been written a little better with more clarity and detail which explains to the user the commands and how to enter them correctly. All in all, all of the bases have been covered, and the potential for loop holes of the program have been sealed. The interface satisfies the second prime directive (An external user can successfully install and use the system).
Review Question 3
The developer guide is very well written and documents each step of the process for developers who want to contribute to this project. The steps to installing the program and verifying the build are documented in a step by step process, and makes sure that the user who is intent on contributing to the project understands the rules and guidelines they must follow in order to make a productive contribution to the project. The developer guide lists the Elements of java style as its source of coding standards and even provides a link to this source so contributor can understand and follows those same coding standards. The project is also listed as being under continuous integration, and provides a link to the Jenkins server so that the developer may also monitor the status of new builds, which is important for the contributor to make sure that their contributions do not create any errors in the build. Finally, there is some brief explanation of how to generate javadocs and also directs the developed to the pre-generated javadocs contained within the source folder. A nice added touch at the end of the guide was support contact for any developer who may have some issues arise while trying to add their contribution.
The sources from svn checkout work without any problem. The build and verify built and tested the system without any errors, and generated the javadoc documentation correctly. The contents of the javadoc documentation is very well written, and explains what each function does in a clear and understandable manner. The architecture of the system supports information hiding, meaning that the structure stays is kept in tact if changes are made, say a new type of command is implemented. Each command is its own entity/class and is implemented by another class called the command class, preserving the overall structure and making each new subsequent “command class” dependent on this “parent” class.
The source files were downloaded from the developer guide page and compiled with no issues. Taking a look at the actual java code of each file confirmed the use of the java style guidelines. The code is not too difficult to follow, there is a little ambiguity of what gets passed where but that may be due to a personal perspective from working on the same program. The quality of the javadocs generated earlier are evidence of the sufficient amount of comments made on each method/function. Taking a look at the issues/update page, the work load among each member appears to be spread pretty evenly. Each member took on equivalent amounts of work, and it looks like they all took control at one point to as far as updating things and fixing problems that arose. From inspection of the continuous integration server, this group had one failed build during the whole duration of the project, which is quite a feat considering how many builds were executed. Each build had an appropriate issue associated with it, which shows the attention to detail that these members had for their project. In conclusion, this group has satisfied the third prime directive (external developer can successfully understand and enhance the system)
No comments:
Post a Comment