如何区别两个合同评审阶段：
建议草案评审。这个阶段评审最终建议草案及其基础：顾客的需求文档，顾客对需求的详细解释，费用与资源评估，同合伙商和分包商已有的合同等。
合同草案评审。这个阶段在后续谈判其达成的理解和建议的基础上评审合同草案。

每个合同评审阶段的目标：
建议草案评审目标如下：

• 已经考察了完成项目的替代途径。
• 已经明确顾客与软件公司之间关系的正式方面。
• 开发风险的识别。
• 已经充分估计项目资源和进度。
• 对公司完成项目的能力的考察。
• 合伙商和分包商参与的确定。
• 专有权利的确定和保护。

合同草案评审目标如下：

• 合同草案中没有留下未澄清的问题
• 在建议之后达成的所有理解正确的文档化。
• 没有将任何“新“的更改，补充或者遗漏放到合同草案中。

为进行正确的重大合同评审，应当遵守下列指南：

• 合同评审应该是建议编制进度安排的一部分。
• 合同评审因该有一个小组执行。
• 应当制定合同评审组的组长。

一些小的对内项目也应该进行合同评审：
在内部顾客和内部开发者之间维持的松散关系增加了项目失败的可能性。这种倾向可通过确定草案编制的适当规程和应用针对外部合同评审的相同指南而降低。

McCall的因素模型将所有软件需求按照11个软件质量因素分类。这11个因素被分为如下三个类别--产品运行，产品校正和产品转移：
1。产品运行因素：正确性，可靠性，效率，完整性，实用性。
2。产品校正因素：可维护性，灵活性，可测试性。
3。产品转移因素：可移植性，可重用性，互操作性。

20世纪80年代出现了两个因素模型，被认为是McCall经典因素模型的替代物，他们是：

• Evans和Marciniak因素模型

• Deutsch 和 Willis因素模型

这些替代物建议给McCall模型增加5个因素。其中两个非常类似于McCall模型的两个因素，其余三个因素是新的：

• 两个模型都增加了可验证性因素

• Deutsch 和 Willis模型增加了安全性和可管理性因素

对于SQA系统部件的分类有如下：

• 项目前质量部件
• 项目生命周期质量部件
• 基础设施错误防护与改进部件
• 软件质量管理部件
• 标准化，认证与SQA系统评估部件
• SQA的组织--人的部件

另外，影响SQA部件使用的主要考虑是：

• 机构的考虑

1， 软件开发主顾的类型
2，软件维护主顾的类型
3， 软件产品的范围
4， 机构的规模
5， 同进行相关项目的其他机构的合作程度与性质
6， 优化目标

• 项目与维护服务的考虑

1， 复杂性和困难的等级
2， 关于项目技术的经验等级
3， 在新项目中软件重用的程度

• 专业人员的考虑

1， 专业资格
2， 对项目组成员熟悉的程度

软件质量保证,首先必须有概念的定义,什么是软件?什么是软件质量?什么是软件质量保证?

• 软件---IEEE定义:

软件是计算机程序,规程以及可能的相关文档和运行计算机系统需要的数据.

也就是说,包含计算机程序,规程,文档和软件系统运行所必需的数据四个部分.

• 软件错误,软件故障和软件失效的关系:

软件错误是指由于程序分析员,程序员或者软件开发组其他成员造成的语法,逻辑或者其他错误,部分或者全部不正确的代码段
软件故障是再特定应用期间导致软件不正确功能的软件错误
只有再软件故障激活被激活的时候,即用户试图使用故障的特定软件段时,他才变成软件失效

软件开发过程中产生的错误中只有部分会变成软件故障,而再这些故障中又只有部分转变成软件失效

• 软件错误的9种产生原因

1. 需求的不完善定义
2. 客户-开发者通信失效
3. 对软件需求的故意偏离
4. 逻辑错误设计
5. 编码错误
6. 不符合文档编制于编码规定
7. 测试过程的不足
8. 规程错误
9. 文档编制错误

• 软件质量--IEEE定义

软件质量是
1. 系统,部件或者过程满足规定需求的程度.
2.系统,部件或者过程满足顾客或者用户需要或期望的程度

另外的关于软件质量的定义:
符合明确陈述的功能和性能需求,明确文档化了的开发标准和所有专业开发软件预期的隐含特征(有点拗口,呵呵)

• 软件质量保证--IEEE定义:

软件质量保证是:
1. 一种有计划的,系统化的行动模式,他是为项目或者产品符合已有技术需求提供充分信任所必需的.
2. 设计用来评价开发或者制造产品的过程的一组活动.与质量控制有区别.

然而,这和实际的软件质量保证有些偏离,首先:
SQA不应局限与开发过程
SQA行动不应局限与功能需求的技术方面,而应该包含同进度和预算有关的活动.
基于这个考虑,有一个SQA的扩展定义:

软件质量保证是:一个有系统的,有计划的行动集合,他是为提供软件产品的软件开发过程与维护过程符合其已建立的技术需求以及跟上计划安排与在预算限制之内进行的管理上的需求的充分信任所必需的.

最近一周正在苦读机械工业的<软件质量保证>,试图从理论上加深对软件质量,软件测试的理解.



以后会陆续推出这类的读书笔记,也算给自己一个任务和交代,不能为了获取一点点的知识而去死读一本书.

必须读一本,消化一本; 读一本,就要有所收获.

是为序.