(a)Project description: This project involves methods that the encrypts strings using different ciphers such as shift or affine. The program can also decrypt encrypted strings respectively.
(b)User stories: As a student, I can encrypt my password so that my password is less vulnerable. As a user, I can chain different ciphers so that I can encrypt stored data in multiple layers. As a user, I can send encrypted secret messages to my friends so that only we can decrypt the message. As a user, I can decrypt messages so that I can solve mysteries.
(c)Brief assessment: Shift cipher: Shift cipher works when we tested it. It shifts the characters in a string by integer provided in the key. However, the shift cipher does not work with spaces. Affine cipher: Affine cipher works when we ran it through the terminal. The method takes two integers as keys where each integer is separated by a space and it multiplies each character's place in the alphabet by the first integer and shifts the characters of the new value by the second integer. Vigenere cipher: Vigenere cipher works when tested. It takes a string as a key and shifts each character of the plaintext by the key's characters. If the plaintext is shorter than the key, the shifting will only be up to the plaintext's length. If the key is shorter than the plaintext, the key will loop around and repeat itself e.g. abc will be abcabcabc for a long plaintext. Bifid cipher: It looks like it works. It keeps 25 character long key 'square' mapped to a coordinate plane of x and y in the range of positive 1 through 5. The first result is a set of two rows of numbers. The first row corresponds to the y coordinate and the second row of numbers correspond to the x coordinate. They are then concatenated groups of 5 and new coordinates are made and converted to a encrypted output.
(d)Assessment of README.md: For each cipher, there should be an example to show how they work. We should put the key concepts in bold to find the ciphers more easily. There should also be bullet points for the list of ciphers. An example should be shown in the instructional area as well. Currently the readme has enough information for a user to be able to use the program as intended.
(e)Assessment of build.xml: The build.xml file looks very simple and so the target list is limited to the basics: compile, run, javadoc, and test. Each of the targets are self-explanatory and so comments for them are unnecessary. We did not find any old JWS legacy code that needed to be removed so the build.xml file does not need much changing unless changes the project requires next implementation in the build.xml.
(f)Assessment of current "issues": There are 8 issues that are relatively feasible and yet require enough attention that we believe it's reasonable enough to earn 1000 points. After reading through the issues, we found that each issues and expectations were clearly conveyed.
(g)Additional issues: link: #24
(h)Assessment of the code: Looking at the code and the README.md, we could see how the code reflects on the method of encryption. The way the code was organized and commented clearly displayed the purpose of each method within the .java file. Though the code is not hard to understand, it does take a while to comprehend the exact functions of each method like any other foreign code. If we were to give a block of text on how to quckly understand the project, we would include the basic idea of the project and where to get started with the code. A brief explanation of each cipher and how to refine the methods for each cipher will allow the programmer to understand how the previous group approached the project and continue from where they left off.
(i)Test coverage: After looking through the test files, the test coverage was adequate and they all implement the JUnit testing package. However, we feel like the tests did not cover all borderline test cases like texts with spaces in between or texts with punctuation. As a base project, we think that the tests are a good checkpoint for anyone to start the project but they should keep in mind extreme test cases that could be implemented along the way like the ones mentioned. Ways to start thinking about the extreme cases in terms of string inputs could be placing illegal characters before, after and in the middle of texts and putting those inputs in the tests. Furthermore, if the methods implement spacing, more tests cases will need to accommodate to those changes. Overall, the test cases were good but could be broader.