软件类人员行为标准.docx

二、行为标准
1、软件产品需求分析
序号
行为
要项
行为标准
1.1
确定市场需求
1. 收集用户需求或分配需求（系统总体分配给软件的系统需求）；
2. 与需求者一起定义、验证所收集的需求；
3. 将定义、验证后的需求按规范文档化为“软件市场需求规格说明书”；
4. 跟踪需求的需求者或需求源，及时收集他们的变更需求。

1.2
评审市场需求规格说明书
1. 审查软件市场需求规格说明书是否符合规范要求；
2. 审查软件市场需求规格说明书中定义的需求是否正确地反映了市场需求，没有错误；
3. 审查软件市场需求规格说明书中定义的需求是否完备地反映了市场需求，没有遗漏；
4. 确认软件市场需求规格说明书中定义的需求与市场需求之间的可追踪性；
5. 将评审结果详细记录在“市场需求规格说明书评审报告”中。
1.3
分析竞争对手产品
1. 分析主要竞争对手同类产品的功能实现；
2. 产生“竞争对手产品功能说明书”；
1.4
定义软件需求
1. 综合分析“软件市场需求规格说明书”和“竞争对手产品功能说明书”中定义的需求，确定它们是否满足：（1）用软件来实现是可行的、合理的；（2）已被明确的、清晰的、无歧义的表述；（3）相互一致、无矛盾；（4）可验证、可测试。
2. 鉴别出不完备的、遗漏的或多余的”软件市场需求规格说明书”和“竞争对手产品功能说明书”中定义的需求；
3. 将定义、验证后的软件需求按规范文档化为“软件需求规格说明书”。
1.5
评审软件需求规格说明书
1. 审查软件需求规格说明书是否符合规范要求；
2. 审查软件需求是否正确地反映了纳入软件配置管理的软件市场需求规格说明书中定义的需求，没有错误；
3. 审查软件需求是否完备地反映了纳入软件配置管理的软件市场需求规格说明书中定义的需求，没有遗漏；
4. 确认所有软件需求对实现纳入软件配置管理的软件市场需求规格说明书中定义的需求而言是完全必要的；
5. 确认每个软件需求的引入都不会恶化系统性能，不会使系统退化；
6. 确认所有软件需求在给定的软硬件环境下都是可实现的；
7. 确认所有软件需求之间都是一致的，没有矛盾；
8. 确认所有软件需求都是可验证的、可测试的；
9. 确认所有软件需求的陈述都是无歧义的；
10. 确认软件需求与纳入软件配置管理的软件市场需求规格说明书中定义的需求之间的可追踪性；
11. 标记出任何有问题的软件需求及相应的处理意见，并详细记录在“软件需求规格说明书评审报告”中。

2、项目计划
序号
行为要项
行为标准
2.1
制订软件开发计划
—
1. 明确软件项目的目标和约束；
2. 选定合适的软件生命周期模型；
3. 估计软件规模；
4. 估计软件的工作量和成本；
5. 对关键资源进行估计；
6. 明确资金使用计划；
7. 确定人员使用计划；
8. 参与软件测试计划的制定；
9. 鉴别和估计软件风险；
10. 确定开发进度；
11. 文档化软件开发计划。

2.2
评审软件开发计划
1. 审查文档化的软件开发计划是否符合规范要求；
2. 审查软件开发计划是否正确、完全、一致地反映了纳入软件配置管理的软件需求规格说明书；
3. 审查软件开发计划是否满足对软件项目的功能约束；
4. 审查软件开发计划是否满足对软件项目的进度、成本约束；
5. 审查软件开发计划是否满足对软件项目的资源约束；
6. 审查软件开发计划是否满足对软件项目的其它约束；
7. 审查软件开发计划中选定的软件生命周期模型是否合适；
8. 审查软件开发计划中标识的每个软件工作产品是否恰当；
9. 审查软件开发计划中对软件规模的估计是否科学合理；
10. 审查软件开发计划中对软件的工作量和成本的估计是否科学合理；
11. 审查软件开发计划中对关键资源的估计是否科学合理；
12. 审查软件开发计划中对软件风险的估计是否科学合理；
13. 审查资金使用计划是否科学合理；
14. 审查人员使用计划是否科学合理；
15. 审查软件测试计划的制定是否恰当；
16. 审查软件开发计划中的进度安排是否合理；
17. 审查软件开发计划是否切实可行；
18. 标记出软件开发计划中存在的所有问题及相应的处理意见，并详细记录在“软件开发计划评审报告”中。

3、 实施项目计划
序号
行为要项
行为标准
3.1
跟踪软件开发过程
—
1. 跟踪软件开发过程，确保软件开发是根据软件开发计划分阶段进行的；
2. 跟踪所有软件工作产品的规模；
3. 跟踪项目的软件工作量；
4. 跟踪项目的软件成本；
5. 跟踪项目所用的关键资源；
6. 跟踪测试进度；
7. 跟踪软件开发进度；
8. 跟踪和控制软件风险。
—
3.2
记录项目数据
—
1. 记录在软件开发不同时期软件的实际规模与估计规模；
2. 记录在软件开发不同时期软件的实际工作量与估计工作量；
3. 记录在软件开发不同时期软件的实际成本与预算成本；
4. 记录在软件开发不同时期实际岗位的设置与对岗位的需求；
5. 记录在软件开发不同时期关键资源的实际使用情况与对关键资源的需求；
6. 记录在软件开发不同时期测试工作情况与计划要求；
7. 记录在软件开发不同时期软件开发的实际进度与计划进度；
8. 记录在软件开发不同时期遭遇的实际风险与估计风险。
—
3.3
修改软件开发计划
—
1. 当下列事件发生时，应修订软件开发计划：（1）制订软件开发计划的基础发生变化，例如，软件需求发生变更，软件项目的约束条件发生变化等；（2）软件开发的实际过程严重偏离软件开发计划；（3）在软件项目的里程碑处。
2. 修订后的软件开发计划必须提交软件过程管理组，由软件质量保证小组进行评审，评审通过后才能用于指导后续软件开发活动。
—

4、 总体设计

序号
行为要项
行为标准
4.1
软件总体设计
1. 深入理解软件系统的需求规格说明；
2. 深入分析软件系统的各个问题域组成元素；
3. 编制软件总体设计报告；
4.2
总体方案评审
1. 审查“软件总体方案”是否符合规范要求；
2. 审查系统分析模型是否正确地反映了纳入软件配置管理的软件需求规格说明书中定义的软件需求，没有错误和遗漏；
3. 确认系统分析模型内部是一致的，没有矛盾；
4. 确认系统分析模型的陈述是无歧义的；
5. 确认系统分析模型与纳入软件配置管理的软件需求规格说明书中定义的软件需求之间的可追踪性；
6. 标记出系统分析模型中存在的所有问题及相应的处理意见，并详细记录在“总体方案评审报告”中。
4.3
模块分析
1. 深入理解模块的规格说明；
2. 确定模块分析的总体思想；
3. 明确模块的各项规格说明与模块的问题域组成元素之间的关系；
4. 深入分析模块的各个问题域组成元素；
5. 编制模块需求分析报告。；
4.4
模块分析评审
1. 审查“模块需求分析报告”是否符合规范要求；
2. 审查模块分析模型是否正确地反映了纳入软件配置管理的软件需求规格说明书中定义的软件需求，没有错误和遗漏；
3. 确认模块分析模型内部是一致的，没有矛盾；
4. 确认模块分析模型的陈述是无歧义的；
5. 确认模块分析模型与纳入软件配置管理的软件需求规格说明书中定义的软件需求之间的可追踪性；
6. 标记出模块分析模型中存在的所有问题及相应的处理意见，并详细记录在“模块分析评审报告”中。

5、设计
序号
行为要项
行为标准
5.1
系统设计
1. 全面理解软件需求分析规格说明书；
2. 确立系统设计的总体思想；
3. 在系统分析报告基础上对系统的关键问题进行设计；
4. 确保系统设计的合理性、可实现性和可扩展性；
5. 编写系统设计说明书
5.2
系统设计评审
1. 审查系统设计说明书是否符合规范要求；
2. 审查系统设计模型是否正确地反映了纳入软件配置管理的系统分析模型，没有错误和遗漏；
3. 确认系统设计模型内部是一致的，没有矛盾；
4. 确认系统设计模型的陈述是无歧义的；
5. 确认系统设计模型是可实现的；
6. 确认系统设计模型与纳入软件配置管理的系统分析模型之间的可追踪性；
7. 标记出系统设计模型中存在的所有问题及相应的处理意见，并详细记录在“系统设计评审报告”中。
5.3
模块设计
1. 全面理解模块分析报告和系统设计报告中的模块规格说明；
2. 确立模块设计的总体思想；
3. 在模块分析报告基础上对模块的结构进行设计；
4. 设计模块的行为；
5. 确保模块设计的合理性、可实现性和可扩展性；
6. 编写模块设计说明书。
5.4
模块设计评审
1. 审查模块设计报告是否符合规范要求；
2. 审查模块设计模型是否正确地反映了纳入软件配置管理的模块分析模型，没有错误和遗漏；
3. 确认模块设计模型内部是一致的，没有矛盾；
4. 确认模块设计模型的陈述是无歧义的；
5. 确认模块设计模型是可实现的；
6. 确认模块设计模型与纳入软件配置管理的模块分析模型间可追踪性；
7. 标记出模块设计模型中存在的所有问题及相应的处理意见，并详细记录在“模块设计评审报告”中。

6、 实现
序号
行为要项
行为标准
6.1
系统级
实现
1. 在系统设计说明书基础上对系统的主体结构进行程序编码，建立各模块可用的系统构架和接口；
2. 程序编写、调试和架构测试，完成系统设计所要求的指标；
3. 编写系统实现说明书，提交源代码和程序。；
6.2
模块级
实现
1. 在模块设计说明书基础上对系统的各个模块进行程序编码；
2. 程序编写、调试，完成模块设计所要求的指标；
3. 编写模块实现说明书，提交源代码和程序。；
6.3
单元测试
1. 以模块设计说明书为依据，审查模块实现说明书，看是否存在实现上的错误或遗漏；
2. 确定测试目标；
3. 确定测试方案和测试计划；
4. 设计测试程序和测试用例；
5. 依据模块设计说明书，确定采用测试程序和测试用例进行测试时应产生的预期结果；
6. 用测试程序和测试用例进行测试，记录测试结果；
7. 将测试结果与预期结果进行比较和分析，并将分析结果文档化。
6.4
集成测试
1. 以系统设计说明书为依据，审查系统实现说明书，看是否存在实现上的错误或遗漏；
2. 确定测试目标；
3. 确定测试方案和测试计划；
4. 设计测试程序和测试用例；
5. 依据系统设计说明书，确定采用测试程序和测试用例进行测试时应产生的预期结果；
6. 用测试程序和测试用例进行测试，记录测试结果；
7. 将测试结果与预期结果进行比较和分析，并将分析结果文档化。
6.5
系统测试
—
— 以软件需求规格说明书为依据，确定测试目标；
— 确定测试方案和测试计划；
— 设计测试程序和测试用例；
— 依据软件需求规格说明书，确定采用测试程序和测试用例进行测试时应产生的预期结果；
— 用测试程序和测试用例进行测试，记录测试结果；
— 将测试结果与预期结果进行比较和分析，并将分析结果文档化。
—

7、 项目总结
序号
行为要项
行为标准
7.1
总结开发成果
—
1. 提取实际软件产品的功能特征、性能特征和质量属性；
2. 将实际进度与原定计划进行对比，明确说明实际进度是否与计划进度吻合。，如不吻合，应说明实际进度是提前了还是延迟了，分析主要原因；
3. 统计实际软件产品的规模和所耗工时；
4. 总结开发经费使用情况。

7.2
对开发工作进行评价

1. 统计实际生产效率，包括文档的生产效率和代码的生产效率；
2. 统计测试中检查出来的以每千条语句中的错误语句数度量的错误发生率；
3. 评价开发中使用的技术、方法和工具；
4. 分析开发中出现的错误的原因；
5. 统计产品交付后发现的问题及排错所耗费的人力物力。

7.3
总结经验教训

1. 总结开发工作中最主要的经验与教训；
2. 对今后的项目开发工作提出建议。

8、变更控制
序号
行为要项
行为标准
8.1
提出变更请求
1. 所有软件变更请求均应按规定的方式提出；
2. 根据产生变更请求的原因，如果是问题，则说明产生问题的应用模式、配置、及出现问题的现象以及其他有关材料；如果是改进，则要提出一份修改说明书，列出所希望的修改；如果是新需求，则对新需求进行详细描述；
3. 按照《软件维护阶段的变更控制过程》的要求填写《软件变更状态报告》相应部分
8.2
评估变更请求
1. 评估过程应该保持中立性，尽量考虑项目当前的资源情况，在市场压力和项目开发管理之间予以均衡。；
8.3
变更请求决策
1. 变更控制者组织某个或一些变更评估者对软件变更请求进行评估；
2. 变更控制者根据评估结果做出是否实现该变更的决策并填写《软件变更状态报告》；
3. 若评估通过则交给相应的变更实现负责人；若不通过，则说明驳回的原因。；
8.4
变更方案论证
1. 变更实现负责人组织变更实现者对变更请求进行分析，若变更请求不可行，则填写《软件变更状态报告》，并说明原因，通知变更控制者；
2. 若变更可行，变更实现负责人及变更实现者者根据变更请求对实现方案进行描述；
3. 变更实现负责人将变更实现方案提交变更控制者进行方案论证，一旦方案论证过程中发现了问题，就及时对方案进行修正，直到论证通过。；
8.5
变更实现
1. 变更实现者根据制定的变更实现方案进行实现，并进行严格的测试；
2. 如果所做修改对相关的工作（比如用户文档、测试等）会带来影响，必须通知这些相关部门和人员。
3. 当变更实现完毕时，填写《软件变更状态报告》相应部分，并交给变更控制者进行验证。；
8.6
变更验证
1. 变更验证者应对实现者对变更的实现进行严格认真的评阅，需要的时候进行面对面的讨论，保证软件修改不会对系统造成显示的破坏，并在《软件变更状态报告》中填写验证说明。
8.7
变更验证控制
1. 变更控制者组织某个或一些变更验证者对变更实现进行验证，并填写《软件变更状态报告》相应部分；
2. 变更控制者根据变更验证的结果，填写《软件变更状态报告》；
3. 若验证通过，则变更控制者通知管理员将要修改的文件权限放开，并通知变更实现者准备提交相应修改；若不通过，则在《软件变更状态报告》中写明理由，让变更实现者重新修改。
8.8
变更提交
1. 变更实现者在管理员的通知下，将所修改文件提交到服务器上。
8.9
变更结束
1. 变更控制者填写最后意见，结束后交软件过程管理部归档，并将该变更的整个处理过程汇报给项目经理，总结经验，同时可放到公共文件夹中公布给整个项目组；
2. 变更控制者通知管理员编译相应的版本，并进行版本控制，然后交由测试部进行测试.