工具评估标准

该网页由OWASP中文项目组维护，以帮助OWASP中文项目的领导人和项目参与人员，依据《2.0版评估标准》（Assessment Criteria v2.0），在项目发布以前，对项目开发的工具进行评估.

工具Alpha发布的标准
评估前的检查列表：
 * 1) 该项发布涉及的项目是否至少包含“项目Wiki最少页数内容”信息？
 * 2) 你的工具是否符合一个免费且开源许可证？（参见Guidelines for OWASP Projects的“项目许可”部分）
 * 3) 源代码和文档是否在在线项目提供方中提供下载？（比如：Google Code或Sourceforge网站）
 * 4) 是否有能用的代码？

工具Beta发布的标准
评估前的检查列表：
 * 1) 在Alpha发布中，“评估前检查列表”中的项目是否完成？
 * 2) 是否有一个安装文件或者独立运行文件？
 * 3) 在OWASP项目wiki网页中是否有用户文档？
 * 4) 是否有“关于”选项或其他类似“帮助”选项，以例举：
 * 5) 项目发布名称
 * 6) 简短的描述
 * 7) 项目发布领导人和联系方式（比如Email）
 * 8) 项目发布贡献人员（如果有的话）
 * 9) 项目发布许可证
 * 10) 项目发布赞助方（如果有的话）
 * 11) 发布状态以及以“X年X月”为格式的评估时间，比如：2009年3月
 * 12) 连接至OWASP项目网页的链接
 * 13) 是否记录了如何将源代码编译建立成工具，以及包括如何从提供代码下载的地方获得源文件？
 * 14) 工具的文档是否和源代码存放在相同的地方？

审核人员检查项目:
 * 1) 是否提供了一个安装文件并简单易用？该安装文件有多么接近于一个完全自动化的安装文件？
 * 2) 终端用户文档在OWASP的wiki网页里是否提供，并且完整和相关？
 * 3) 工具是否含有一个“关于”选项或其他类似“帮助”的选项，以使终端用户对工具的状态有一个大致了解？这些信息是否立马可用并且容易找到？
 * 4) 建立源文件的文档是否提供了重要的信息和细节，以使用户可以建立工具？是否有充足的细节信息提供给目标用户？是否有一些特殊领域的知识被假设或者没有提供？
 * 5) 工具的文档是否和源文件一同提供，并且能否很容易就被一个新的工具使用者发现？

工具稳定发布的标准
评估前的检查列表：
 * 1) 在Alpha和Beta发布中，“评估前检查列表”中的项目是否全部完成？
 * 2) 工具是否包括建立工具的文档？
 * 3) 工具是否包括安装脚本以自动安装？
 * 4) 是否有一个可以公共访问的bug跟踪系统？
 * 5) 工具已有的一些缺陷是否被记录？

审核人员检查项目:
 * 1) 在Beta发布中，审核人员需检查的项目是否都已完成？如果在前一评估阶段没有达到，则必须完成.
 * 2) 工具是否实质性的解决了当初认为需解决的应用程序的安全问题？
 * 3) 工具是否简单易用？
 * 4) 文档是否满足了工具使用者的需求并且很容易被找到？
 * 5) 安装脚本是否按照预期那样运行？你是否可以建立工具？目标是“点击一次”就完成所有的安装.
 * 6) bug跟踪系统是否可用？其是否和源代码放置在相同的地方？（比如：Google Code, Sourceforge）
 * 7) 你是否发现到一些没有被项目发布领导记录的工具限制或缺点？
 * 8) 假设在你的工作中有使用该工具的需要，那么你是否会考虑在你的日常工作中使用它？你是否会将该工具推荐给这一领域中的其他人？为什么会？为什么不会？
 * 9) 如果有的话，缺失哪部分会使这个工具更加有用？缺失的部分，是否会将文档的发布降为Beta等级？