您位于: 首页 OWASP项目 采用的项目评估标准 工具评估标准

工具评估标准

工具Alpha发布的标准

评估前的检查列表:

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

工具Beta发布的标准

评估前的检查列表:

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


审核人员检查项目:

  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等级?