《软件是这样炼成的--软件过程管理与软件测试》 读书心得
这一册主要是简述了软件工程的改进，其实就是质量保证的方方面面过程域。
软件过程是一个为建造高质量软件所需完成的任务框架，软件过程改进包括下面四点：
- 1、软件过程定义
- 2、软件过程文档化
包括软件过程定义文档化和过程执行文档化两部分
- 3、软件过程培训
- 4、软件过程强制执行
文章摘录
- 木星（Jupiter）是太阳系八大行星中体积最大、自转最快的行星，从内向外的第五颗
... 中文名: 木星; 外文名: Jupiter; 别 称: 朱庇特、岁星; 分 类: 行星;
发现者: 伽利略
- 在配置管理系统中，基线就是配置项在其生命周期的不同时间点上通过评审而进入正式受控的一种状态，而这个过程被称为“基线化”。
每一个基线都是其下一步开发的基准。
- 影响软件质量的本质问题不是技术问题，而是管理；管理方法也不是管理的核心，管理的核心是管理意识。
- 组织评审会是，必须有评审依据。(最好有评审检查表)
- 软件质量保证的核心工作是软件开发过程保证。质量保证的本质工作是软件过程执行状态的监督，质量保证该软件开发过程中的每个过程点按照既定的质量执行，并且按照不同的评审等级进行评审。
说白了就是制定标准（过程标准、模板等），然后组织评审。
- 短视者亡，长视者兴。
- 软件过程改进的4大要素是过程定义化、文档化、培训和强制执行。
- 梳理工作流程。只有将流程梳理清楚，明确了各部门内部员工的工作职责，明确部门之间的协调关系和协调资源。
- 企业组织设计的根本目的是为了实现企业战略任务和经营目标服务的。
- 盈利合同、战略合同、战术合同。
- 个人注：合道也应该把做具体事情的考核，转化为业绩目标性的考核。
- 项目经理和部门经理侧重于工作态度和能力的考核，这些指标无法量化，只能采取评语考核的方式了，只有这样才能给予部门经理和项目经理充分的考核全力，有效管理自己的团队。量化的考核，可以是结合项目的情况进行奖励考核的时候进行！
- 经营企业和居家过日子一样，花每一分钱都要精打细算，该花的钱一点也不少花，不该花的钱一点也不多花，无效的工作不干。
- 风险识别的过程的目的是将事情的不确定性转变为明确的风险陈述，为风险分析提供依据。
- 需求评审分为：全局评审（业务中高层，项目目标、核心功能），局部评审（业务中层及一线人员，业务流程），内部评审（开发人员、分析人员）
需求评审是项目评审中最高级别的评审。
- 要充分识别客户的需求和潜在需求，需求确认非常重要，需求双方都要务实，设计实现别让需求扩大化，严格规范需求变更控制流程，别忽视需求跟踪，别忽视需求跟踪...提炼客户需求的时候，采用'往前跨半步'的方式，满足客户现在以及最近的将来可能需要的需求以满足系统的灵活性，切忌追求更加抽象化、更加完美、盲目扩大需求范围。要知道，简单是美，适用的才是最好的。
- 概要设计阶段的核心人物是确定类间关系、确定类的方法体、确定方法体的输入和输出、设计类的接口与规范，而详细设计要完成数据库的逻辑结构、物理结构和概念设计等相关内容...详细设计的设计单位是类，设计内容是方法体
- 如果是小项目，概要设计和数据库设计合并成一个文档。（小项目一般没有详细设计）
- 要分析写的文档给谁看？写文档的意义和价值！
- 软件开发过程，一般遵循以下几步执行：
1、确定软件生命周期
2、确定各里程碑
3、确定各里程碑目标
4、确定每个里程碑涉及哪些开发过程域
5、确定每个开发过程域要执行哪些活动（可剪裁）
6、确定这些活动遵循的标准、规程以及使用的模板
7、制定验收标准
- 软件质量活动包括
1、软件质量保证过程域
2、软件配置管理过程域
3、软件测试过程域
- 我认为敏捷开发适用Product而不太适用于Project。
- 个人注：管理就是轨道和信号等。在你开车走的时候，轨道就规定了你开车的路线，相关的信号灯就是随时给你反馈信息和要求。
或者说，就是工程里面的工程监理。
- 可以达不到目标，但是不能没有目标。
- 每次变更都要考虑调整（进度、成本、质量）
1、项目计划
2、成本
3、质量保证、配置管理
- 软件分层，不同层不同观点人开发，这样能保证不同层功能（服务）的可复用性...基于服务的架构，决定了编码的顺序是：创建数据库、实体Bean开发、会话Bean开发、业务逻辑开发和表示层开发，这是因为上一层是为下一层提供服务的。
- 详细设计做得好的话，程序员仅仅是“码工”了。
- 代码走查的核心任务是：规范性检查、代码BUG检查。
- 测试普遍存在的问题：
1、测试人员配比不足，最好是1:1，至少要做到4~5:1
2、测试计划及进度受制于开发计划及进度
3、测试人员和开发人员的沟通不畅，处于对立的局面
4、测试工具的应用不好，特别是自动测试工具
5、测试人员的技术不足，深层次的代码逻辑和数据库缺陷发现不了
6、测试用例没有严格的科学依据，甚至没有用例，就是‘点点测试’
- 软件测试过程的改进和优化：测试过程提升+技术提升。
- 制定计划的时候，一定要考虑冗余时间，一般来说，项目成熟度较高的项目，冗余10%~30%不等。反之，成熟度较低的话，冗余时间要设定得高一点，以防延期带来的连锁的反应。
- 测试需求分析其实在某种程度上可以取代部分用例设计工作，也就是说我们如果进行了较为详细的测试需求分析工作，测试用例就可以不用那么详细的编写了。例如上面的业务场景分析部分，只要按照业务流程直接进行测试执行是没有问题的。（个人注：其实是测试用例编写的依据，有了这些，就像编码之前的详细设计一样，基本水到渠成了。）
- 测试需求分析+业务流程分析-->用例设计
文中重要图片截图
冒烟测试的用例由测试来提供，开发执行
重点
