1.软件产品 (software products)

    1.1 大多为横向型市场 (horizontal market)而开发。使用者多为个人, 且数目任意，能力不齐
    1.2 提供的功能(features and functionalities)大多为解决某个具体应用问题或需要
    1.3 功能需求 (requirement)来自开发商的市场开发和销售队伍(marketing & sales), 或使用者对 前一代产品的回馈
    1.4 例子: 办公用软件、单功能应用软件、游戏、等等

    2. 软件系统 (software systems)
    2.1 大多为纵向型市场 (vertical market)而开发: 使用者为专门的客户的内部员工及部门团队, 数目有限, 事先可知, 且能力可专门培训
    2.2 提供的功能大多为解决客户一连串具体的商业业务或运作问题或满足客户对外服务需要
    2.3 功能需求来自客户提出的具体要求和客户业务的运作特性: 它已有的系统, 流程的局限性
    2.4 例子: 商业业务软件系统, 自动控制系统, 等

    二. 编写程序之前必须进行的工作

    了解和确证客户的使用方案(User Scenario)
    总结详细的功能需求并与用户审核确证
    功能设计通过完整的设计规范书(Design Specification)来表达
    以设计规范书为基础制定构架设计(Architecture)、开发方案(Implementation Plan)
     事先制定测试计划和软件合格的检验准则 (Exit Criteria)

    三. 开发项目的计划和管理采取来自开发团队的、从下而上的时间表的估算，避免人为的不合理猜测

     开发时间表的制定以具体的功能开发任务，并且以几天为衡量单位
     整个开发过程以间断性的里程碑来追踪
     进行周期性的进度审核，作必要的调整
     对 “功能蔓延” (Feature Creep)严格控制和管理

    四 . 开发管理

    4.1写任何程序前一定要先有设计构划书

    4.2任何复杂的系统程序要先有构架设计书
    4.2.1 对系统组件有明确的功能定义.
    4.2.2 对组件的接口的设计事先有完整的纪录.
    4.2.3 构架设计书由构架设计师或开发工程师的领导人员来撰写.
    4.2.4 构架设计书要通过项目经理和测试人员在内的审核及通过, 才能开始编写程序.

    4.3 建立程序原代码的提交库，并建立完整的原代码的提交的流程管理制度
    4.3.1原代码只允许一人改动. 改动前先要从提交库申请出原代码. 改动后再送进提交库.
    4.3.2改动完先要在开发工程师的机器上编译, 与其它组件一起运行过, 确证没有致命的缺陷后，才能送进原代码的提交库.
    4.3.4在产品发行前, 整个提交库都被锁上, 只有被批准的缺陷修补的原代码才能提交进库.

    4.4 建立原代码互审的管理制度
    每个软件开发工程师遍写的原代码都有致少一个以上的同事对程序进行审查.

    4.5 建立原代码编写的规范
    每个软件开发工程师都应按照规范进行程序设计, 包括编写的风格, 格式, 组件接口的规范, 解说词的撰写, 等等.

    五 测试管理根据设计构划书撰写测试计划

    5.1.1 测试计划要请项目经理和开发工程师一起进行审查.
    5.1.2 测试计划用列表式将所有的测试方案写下.
    5.1.3 每个具体地的测试方案都有专人执行，并记录每个测试方案的结果. 任何缺陷都记录下来.

    5.2测试与开发同步进行
    在部分组件编写完后就进行开发测试工具.

    5.3 测试计划执行中的注意事项
    5.3.1 由测试员发现的缺陷分给开发工程师修改纠错.
    5.3.2 修改完毕由测试员先进行初步质量验证 (Smoke Test), 通过后才能由开发工程师送进原代码的提交库.
    5.3.4 每次任何影响到其它组件的程序纠错改动, 不仅是经过改动的程序要重新测试, 任何可能受到影响的其它组件或程序也必须重测 (Regression Test).
    5.3.5发行前要进行全程测试 (Full Test Pass).

    5.4 测试的内容：1.确定测试的优先级别 2。函数模块 3。功能模块

    5.5 测试的结果：1.bug的数量（平均每50行就有一个）2.代码的覆盖率（代码的执行路径）

    5.6 测试不到的地方未知错误要进行出错处理

    六 实施关键

    设计在先，编码在后
    没有设计规范书就不写一行编程码
    所有的编码要有员工之间的互相审核
    所有的编码在加入整体汇编前必须在开发工程师的机器上先汇编
    “吃你自己的狗食”: 产品发行前全体团队成员要自己使用尚未完善的产品,并报告缺陷.
    专门的汇编团队负责整个产品的建造并每天进行汇编。任何造成汇编失败的编程必须写此程序的工程师立即修改纠错 (Fix Bug).
    整个公司所有团队使用统一的缺陷报告数据库工具. 但每个团队掌握控制自己的数据库. 任何问题都通过缺陷数据库来跟踪.
    被修改后已解决的缺陷 (Fixed Bug)必须由找到缺陷的人 (通常是测试人员) 验证.被修改后已解决的缺陷还必须通过再测试，验证修改的编码没有造成新的害虫.
    所有的害虫被分类成三种严重性的级别及三种修改的优先权的级别. 所有团队员工被要求必须先除级别高的害虫.
    有的团队执行 “害虫监狱” (Bug Jail)制度: 害虫数字超过 5 个以上的开发工程师在除完害虫前不准编新的功能的编码.
    所有关键性的害虫在产品发行前都要由“三国会议” (Triage Meeting – PM, Dev, QA) 讨论决定是否要除, 才能改动。
    产品发行前团队召开定时的“战前会议” (War Meeting), 由团队各领导成员审核所有的害虫.
    每次一项功能编程完成后, 团队全体成员进行 “抓虫大扫除” (Bug Bash)：每人在规定的时间内使用新的功能，将找到的害虫及时报告. 大扫除结束后抓虫的统计向全队报告.