作业流程晴雨表

    是否存在专注于组织整体的开发作业和项目流程的人或者小组？
    是否存在项目开发作业的标准作业流程？
    是否存在记述顾客需求式样的文档标准？
    是否存在设计书的文档标准？
    是否不经过设计阶段而直接进入编码阶段？
    设计阶段是否实施了以设计为对象的审查？
    编码阶段是否实施了以代码为对象的审查？
    中途式样变更后，是否未经其影响范围的分析直接分配给担当者？
    是否未经单体测试直接开始综合测试？
    是否时至后才发现此前隐藏的诸多问题？
    是否无视已经发现的问题而继续推进作业？
    是否多次重复出现以前相同的错误而没有吸取教训？
    是否没有专门的测试人员而在交付之前还是由开发者自己实施测试？
    对式样需求是否确立了适当的测试项目？
    测试是否几乎没有自动化手段？
    过程改善方面是否存在可以商量和咨询的人员？
    是否鼓励各开发小组写作事后分析报告，至少能项目进程开会讨论？
    是否组织正式的活动，软件开发与质量控制流程的相关问题相互切磋？

项目配置晴雨表

    是否在发现潜在的缺陷时难以确定其对现有模型的影响范围？
    是否只有担当者知道而没有向所有成员公布缺陷的修正范围和修正方法？
    是否因为修改一个程序缺陷而引发多个新的缺陷？
    担当者是否能在任何时间对源程序做自由的变更？
    开发期间是否定期对制作过程中的文件和程序进行备份？
    是否确立了资源备份在非常时期的因应方式？
    需求式样书和设计书等正式文件是否存在“确认”手续？
    项目文档是否一直保持初的状态，即使在式样变更后仍然没有变化？
    是否在项目后期难以想起中途式样变更的“理由”？
    对于程序缺陷和式样变更，是否能追踪其修改点？
    对于开发环境目录中的旧代码是否难以判断其能否删除？
    开发文档是否会出现链接到旧版本的情况？

教育培训晴雨表

    是否描绘出现在的开发组织多年后的“风姿”？
    在组织上，是否对现在的人员实施技术性教育和培训？
    是否确立了员工教育培训的计划和目标？
    是否将技术学习视为个人任务而没有组织上的“方向”？
    项目开发人员所持有的软件开发文献的平均数量是否在1册以下？
    项目作业休息时间是否毫不涉及崭新技术方面的话题？
    项目组成员是否不知道软件工程的意思？
    是否不了解“凝聚度”、“结合度”等词汇的意思？
    是否难以说出5个以上的软件质量特性及其副特性？

项目审查晴雨表

    参与者是否了解审查的整体流程？
    是否带着目的而非盲目地实施审查作业？
    是否仅仅局限于代码审查而不顾及其他？
    审查者是否只关注形式而非实质？
    是否明确审查对象物，针对“物”而非“人”？
    是否记录审查结果并追踪缺陷修正结果？
    是否将审查的反馈结果导入下一项目中？
    审查会议是否演化成为问题解决会议？

其他

    是否采取了数据备份以及病毒防范等措施？
    对电子邮件的应对是否总是滞后？
    是否感到电子邮件的应对很繁琐？