工具评估标准
工具Alpha发布的标准
评估前的检查列表：
- 该项发布涉及的项目是否至少包含“项目Wiki最少页数内容”信息？
- 你的工具是否符合一个免费且开源许可证？（参见Guidelines for OWASP Projects的“项目许可”部分）
- 源代码和文档是否在在线项目提供方中提供下载？（比如：Google Code或Sourceforge网站）
- 是否有能用的代码？
工具Beta发布的标准
评估前的检查列表：
- 在Alpha发布中，评估前的检查列表中的项目是否完成？
- 是否有一个安装文件或者独立运行文件？
- 在OWASP项目wiki网页中是否有用户文档？
- 是否有“关于”选项或其他类似“帮助”选项，以例举：
- 项目发布名称
- 简短的描述
- 项目发布领导人和联系方式（比如Email）
- 项目发布贡献人员（如果有的话）
- 项目发布许可证
- 项目发布赞助方（如果有的话）
- 发布状态以及以“X年X月”为格式的评估时间，比如：2009年3月
- 连接至OWASP项目网页的链接
- 是否记录了如何将源代码编译建立成工具，以及包括如何从提供代码下载的地方获得源文件？
- 工具的文档是否和源代码存放在相同的地方？
审核人员检查项目:
- 是否提供了一个安装文件并简单易用？该安装文件有多么接近于一个完全自动化的安装文件？
- 终端用户文档在OWASP的wiki网页里是否提供，并且完整和相关？
- 工具是否含有一个“关于”选项或其他类似“帮助”的选项，以使终端用户对工具的状态有一个大致了解？这些信息是否立马可用并且容易找到？
- 建立源文件的文档是否提供了重要的信息和细节，以使用户可以建立工具？是否有充足的细节信息提供给目标用户？是否有一些特殊领域的知识被假设或者没有提供？
- 工具的文档是否和源文件一同提供，并且能否很容易就被一个新的工具使用者发现？
工具稳定发布的标准
评估前的检查列表：
- 在Alpha和Beta发布中，“评估前检查列表”中的项目是否全部完成？
- 工具是否包括建立工具的文档？
- 工具是否包括安装脚本以自动安装？
- 是否有一个可以公共访问的bug跟踪系统？
- 工具已有的一些缺陷是否被记录？
审核人员检查项目:
- 在Beta发布中，审核人员需检查的项目是否都已完成？如果在前一评估阶段没有达到，则必须完成。
- 工具是否实质性的解决了当初认为需解决的应用程序的安全问题？
- 工具是否简单易用？
- 文档是否满足了工具使用者的需求并且很容易被找到？
- 安装脚本是否按照预期那样运行？你是否可以建立工具？目标是“点击一次”就完成所有的安装。
- bug跟踪系统是否可用？其是否和源代码放置在相同的地方？（比如：Google Code, Sourceforge）
- 你是否发现到一些没有被项目发布领导记录的工具限制或缺点？
- 假设在你的工作中有使用该工具的需要，那么你是否会考虑在你的日常工作中使用它？你是否会将该工具推荐给这一领域中的其他人？为什么会？为什么不会？
- 如果有的话，缺失哪部分会使这个工具更加有用？缺失的部分，是否会将文档的发布降为Beta等级？
