Kevin La, Chantel Chan
a.(20 pts) A brief description of the project. Here, I’m looking for a short description: probably 1 sentence, 2-3 at most. This project is a binary clock that represents the time using base 2. There are six columns of light, ranging between 1 to 4 light units in each column, and another column of light with 2 units representing AM and PM.
b.(20 pts) a set of user stories (as a X I can Y so that Z) that describe what the current software in its current state can do. As a person, I can look at the binary clock so I can tell what time it is, with the hour, minute, and second showing.
c.(20 pts) a brief assessment of whether the software runs or not. If it runs, briefly describe what it does, The software does run, and it tells you the current standard time in binary. It also lets us change the colors of the background, and the clock with the list of colors that it provides us.
d.(20 pts) a set of user stories (at least 2, but you are encouraged to write up to 4 or more if you can, as many as you think is reasonable) about features that COULD be added to the software to make it more useful, fun, better, etc. We could add different time zones so that people are able to change between Pacific, Mountain, Central, and Eastern American times. We could also make a eye-pleasing application, because the current one looks too outdated. We are able to do this by being able to change the font, the colors of the background, and possibly the shapes of the binary clock.
e.(20 pts) An assessment of the current quality of the README.md. What information could be added to make it easier for the next generation of folks maintaining this code to use the software, and/or maintain the software? It provides a brief but efficient description of what each file does. The instructions on how to run the program are easy as well. We could put in any common errors that we ran into and document how to fix those problems if any future programmers run into that along the way. We could also tell the user there are more options and what type of improvements could still be made.
f.(20 pts) An assessment of the current state of the build.xml file. Are there targets that need descriptions? Is there old legacy JWS stuff that needs to be removed? (More on this below). There aren’t any descriptions/comments throughout the build.xml. We hope to do that in our project. No there aren’t any old legacy JWS stuff that needs to be removed.
g.(20 pts) An assessment of the current “issues”. Are there enough issues that you could earn 1000 points by working on this project? Are the issues clear in terms of what the expectations are? Yes, we believe that there are enough issues to tackle in this project so that we are able to earn 1000 points. We plan on presenting more issues along the way as well for future programmers to work on.
h.(20 pts) A list of additional issues that you may have added, if any. For each, a link to the issue is good enough. There aren’t any buggy issues within the code, but there could be more features added to the application.
i.(100 pts) Most important: an assessment of the actual code. Write a bit about how the code is organized. Are the purposes of the classes, and their methods clear? Is it obvious how the classes relate to one another? Is the code easy to read and understand? If you had to give someone else that was going to work on the code just “one screenful of text” to help that programmer get up to speed quickly, what information would you convey? The purposes of the classes and their methods are clear because each one contains comments and description about what they do. However we would say that it is not too obvious how the classes are related to one another because some files and comments make the classes seem confusing in how they work. The code is easy to read because the format and syntax follows coding standards. In addition, the variable names clearly identify what they do. If we were to give someone else the code, we would put in which classes to implement and what each of those classes would do. We would also put in any problems that we had along the way so that they could avoid them themselves.
j.(40 pts) Related to code quality, but factored out into a separate issue because it is so important: how is the test coverage? Are there JUnit tests at all? If so, how much of the project is covered by testing? Are there opportunities to expand test coverage, and if so, how would you go about it? There aren’t any JUnit tests at all, but we plan on implementing those by trying to use time zones in our tests. This is one way to expand our test coverage.