We have updated the content of our program. To access the current Software Engineering curriculum visit curriculum.turing.edu.
Enigma - Evaluation Rubric
| Above Expectations | Meets Expectations | Below Expectations | Well Below Expectations | |
|---|---|---|---|---|
| Functionality | Cracking method and command line interface successfully implemented | Enigma Class with encrypt and decrypt methods successfully implemented. Encrypt/decrypt command line interfaces successfully implemented | One of the following are not successfully implemented: Enigma#encrypt, Enigma#decrypt, command line interfaces | Two or more of the following are not successfully implemented: Enigma#encrypt, Enigma#decrypt, command line interfaces |
| Object Oriented Programming | Students have implemented either inheritance or at least one module in a logical manner. Students can speak as to how/why inheritance and modules made sense for the given implementations, why they improve the organization of the code, and the distinction between the two. | Project is broken into logical components that are appropriately encapsulated. No classes are unreasonably small or large, or contain knowledge/information/behavior that they shouldn’t know about. Student can articulate the single responsibilities of the various components. | Students can clearly identify the responsibility of each class that they created and the methods that they wrote. Students are able to describe why they have organized their code in the way they did. Project may have too many or too few classes, or include knowledge/information/behavior that isn’t necessary for a given class to know. Student cannot articulate single responsiblities, or code does not demonstrate adherence to the described single responsiblities. | Students have difficulty explaining the reason they have organized their code in the way that they did. They may have few files that seem to be doing the vast majority of the work in the project, and have not drawn clear lines between the responsibilities of different classes they have created. |
| Ruby Conventions and Mechanics | Classes, methods, and variables are well named so that they clearly communicate their purpose. Code is all properly indented and syntax is consistent. No methods are longer than 10 lines long. Most enumerables/data structures chosen are the most efficient tool for a given job, and students can speak as to why those enumerables/data structures were chosen. | Code is mostly properly indented, spaced, and lines are not excessively long. Class, method, variable, and file names follow convention. Some enumerables/data structures chosen are the most efficient tool for a given job, and students can speak as to why those enumerables/data structures were chosen. At least one hash is implemented in a way that makes logical sense. | Code demonstrates some proper indenting and spacing. Class, method, variable, and file names inconsistently follow convention. Few enumerables/data structures chosen are the most efficient tool for a given job. Students may not be able to speak as to why those enumerables/data structures were chosen. No hashes are implemented, or are implemented in an inappropriate use case. | Code is not properly indented and spaced and lines are excessively long. Class, method, variable, and file names do not follow convention |
| Test Driven Development | Mocks and/or stubs are used appropriately to ensure two or more of the following: testing is more robust (i.e., testing methods that might not otherwise be tested due to factors like randomness or user input), testing is more efficient, or that classes can be tested without relying on functionality from other classes. Students are able to speak as to how mocks and/or stubs are fulfilling the above conditions. Test coverage metrics show 100% coverage. | Every method is tested at both the unit and integration level, and completely verify expected behavior (i.e., if a single method does 3 things, all 3 things are explicitly tested). Obvious edge cases are addressed. git history demonstrates students are writing tests before implementation code. Test coverage metrics show coverage at 99% or greater. | Every method is not tested, expected behavior is partially tested, and/or no edge cases are addressed. git history does not demonstrate students are writing tests before implementation code. | Test coverage is below 90% and/or less than half of the methods in any given class are untested or have tests that don’t verify expected behavior. |
| Version Control | Minimum 40 commits and 4 pull requests. All pull requests include related and logical chunks of functionality, and are named and documented to clearly communicate the purpose of the pull request. No commits include multiple pieces of functionality. | Minimum 30 commits and 3 pull requests. More than half of your pull requests include related and logical chunks of functionality, and are named and documented to clearly communicate the purpose of the pull request. No more than 3 commits include multiple pieces of functionality. | Minimum 20 commits and 2 pull requests. At least half of your pull requests include related and logical chunks of functionality, and are named and documented to clearly communicate the purpose of the pull request. No more than 5 commits include multiple pieces of functionality. | Less than 20 commits or 2 pull requests. Less than half of your pull requests include related and logical chunks of functionality, and are named and documented to clearly communicate the purpose of the pull request. More than 5 commits include multiple pieces of functionality. |
