Project Evaluation Checklist

  • Requirements

    • Sponsor has signed off on current requirements in writing (T/F)
    • Number of "function points" (items in the requirement spec), "story cards", or some similar measure of functional requirement quantity.
    • Number of function points, story cards, etc for extra-functional requirements
    • Sponsor has signed off on the project goals for
      • Performance (T/F)
      • Reliability (T/F)
      • Security (T/F)
      • Usability (T/F)
        • Accessibility (T/F)
      • Maintainability (T/F)
  • Design

    • An architecture description (and diagram) exists and has been maintained (T/F)
    • Difficult units in the design have pseudocode (T/F)
    • The design, correctly executed, meets the requirements without much extra (T/F)
  • Implementation

    • Every human-created file in the project has copyright and license information at the top (T/F)
    • Basic coding standards (e.g. decent naming, correct indentation) have been followed throughout (T/F)
    • A standard coding style guide has been adopted and code matches it (T/F)
    • Source comments are adequate, including
      • Block comment describing each file (T/F)
      • Comment describing each non-trivial unit (T/F)
      • Adequate comments for difficult or critical sections (T/F)
      • Comments for attributing / referencing stuff used from outside the project (T/F)
    • Directory and file structure is comprehensible and navigable. (T/F)
  • V&V

    • All difficult units have adequate unit tests (T/F)
    • A regression test suite exists and is maintained (T/F)
    • System tests to verify all testable requirements exist (T/F)
    • All tests can be easily run at any time by automated means (T/F)
    • All code has been looked at by someone other than the author (T/F)
    • All difficult units have been carefully reviewed (T/F)
  • Delivery

    • A source repository will be available to the customer, containing all relevant commits (up to privacy and professionalism issues) (T/F)
    • User acceptance testing has been conducted or is built into the delivery schedule (T/F)
    • Sufficient documentation has been delivered for
      • Fresh users to be able to use the system without help (T/F)
      • Fresh developers to be able to maintain and enhance the system without help (T/F)
        • Build and test instructions are available (T/F)