Tool Assessment Criteria

This is a DRAFT page still under review by the Global Projects Committee

This page is maintained by the Global Projects Committee to help assist Project Leaders with information about successfully running an OWASP Project. It will be updated from time to time, and changes will be discussed and announced on the OWASP-Leaders list.

Alpha Quality Tool Criteria

Pre-Assessment Checklist:

1. Is your tool licensed under an open source license? (see Project Licensing section of the Guidelines for OWASP Projects)
2. Is the Project Identification template on the project complete and accurate?
3. Is the source code and any documentation available in an online project site? (e.g. Google Code or Sourceforge site)
4. Is there an OWASP mail list for the project?
5. Is there a statement of the application security issue the tool addresses on the OWASP project page?

Beta Quality Tool Criteria

Pre-Assessment Checklist:

1. Is there an installer or stand-alone executable?
2. Is there user documentation on the OWASP project wiki page?
3. Is there an "About box" or similar help item which lists:
   1. Project Name
   2. Short Description
   3. Project Lead and contact information (e.g. email address)
   4. Project Contributors (if any)
   5. License
   6. Project Sponsors (if any)
   7. Release status and date assessed as Month-Year e.g. March 2009
   8. Link to OWASP Project Page
4. Is there documentation on how to build the tool from source including obtaining the source from the code repository?
5. Is the tool documentation stored in the same repository as the source code?
6. Are the Alpha pre-assessment items complete?

Reviewer Action Items:

1. Is an installer for the tool available and easy to use? How close does it reach the goal of a fully automated installer?
2. Is the end user documentation complete, relevant and presented on the OWASP wiki page?
3. Does the tool have an “About box” or similar help item which allows the end user to get an overview of the state of this tool? Is this information readily available and easy to find?
4. Does the documentation on building the source provide the necessary information and detail to allow someone to build the tool? Is there sufficient detail and information for the target user? Is there any domain specific knowledge that is assumed and not provided?
5. Is the tool's documentation available with the source code and would it readily discoverable by a new user of the tool?

Release Quality Tool Criteria

Pre-Assessment Checklist:

1. Does the tool include documentation built into the tool?
2. Does the tool include build scripts to automate builds?
3. Is there a publicly accessible bug tracking system?
4. Have any limitations of the tool been documented?
5. Is there a conference style presentation that describes the tool in at least 3 slides?
6. Is there a one sheet overview document about the project?
7. Are the Alpha and Beta pre-assessment items complete?

Reviewer Action Items:

1. Does the tool substantially address the application security issues it was created to solve?
2. Is the tool reasonably easy to use?
3. Does the documentation meet the needs of the tool users and is easily found?
4. Do the build scripts work as expected? Can you build the tool? The goal is a “One-click” build.
5. Is the bug tracking system usable? Is it hosted at the same place as the source code? (e.g. Google Code, Sourceforge)
6. Have you noted any limitations of the tool that are not already documented by the project lead.
7. Have all the Beta Reviewer Action Items been completed? These will need to be completed if they have not already occurred during a previous assessment.