软件类人员行为标准

1、22/22二、行为标准1、软件产品需求分析序号行为要项行为标准1.1确定市场需求收集用户需求或分配需求（系统总体分配给软件的系统需求）；与需求者一起定义、验证所收集的需求；将定义、验证后的需求按规范文档化为“软件市场需求规格讲明书”；跟踪需求的需求者或需求源，及时收集他们的变更需求。1.2评审市场需求规格讲明书审查软件市场需求规格讲明书是否符合规范要求；审查软件市场需求规格讲明书中定义的需求是否正确地反映了市场需求，没有错误；审查软件市场需求规格讲明书中定义的需求是否完备地反映了市场需求，没有遗漏；确认软件市场需求规格讲明书中定义的需求与市场需求之间的可追踪性；将评审结果详细记录在“市场需求规

2、格讲明书评审报告”中。1.3分析竞争对手产品分析要紧竞争对手同类产品的功能实现；产生“竞争对手产品功能讲明书”；1.4定义软件需求综合分析“软件市场需求规格讲明书”和“竞争对手产品功能讲明书”中定义的需求，确定它们是否满足：（1）用软件来实现是可行的、合理的；（2）已被明确的、清晰的、无歧义的表述；（3）相互一致、无矛盾；（4）可验证、可测试。鉴不出不完备的、遗漏的或多余的”软件市场需求规格讲明书”和“竞争对手产品功能讲明书”中定义的需求；将定义、验证后的软件需求按规范文档化为“软件需求规格讲明书”。1.5评审软件需求规格讲明书审查软件需求规格讲明书是否符合规范要求；审查软件需求是否正确地反映

3、了纳入软件配置治理的软件市场需求规格讲明书中定义的需求，没有错误；审查软件需求是否完备地反映了纳入软件配置治理的软件市场需求规格讲明书中定义的需求，没有遗漏；确认所有软件需求对实现纳入软件配置治理的软件市场需求规格讲明书中定义的需求而言是完全必要的；确认每个软件需求的引入都可不能恶化系统性能，可不能使系统退化；确认所有软件需求在给定的软硬件环境下差不多上可实现的；确认所有软件需求之间差不多上一致的，没有矛盾；确认所有软件需求差不多上可验证的、可测试的；确认所有软件需求的陈述差不多上无歧义的；确认软件需求与纳入软件配置治理的软件市场需求规格讲明书中定义的需求之间的可追踪性；标记出任何有问题的软件

4、需求及相应的处理意见，并详细记录在“软件需求规格讲明书评审报告”中。2、项目打算序号行为要项行为标准2.1制订软件开发打算明确软件项目的目标和约束；选定合适的软件生命周期模型；可能软件规模；可能软件的工作量和成本；对关键资源进行可能；明确资金使用打算；确定人员使用打算；参与软件测试打算的制定；鉴不和可能软件风险；确定开发进度；文档化软件开发打算。2.2评审软件开发打算审查文档化的软件开发打算是否符合规范要求；审查软件开发打算是否正确、完全、一致地反映了纳入软件配置治理的软件需求规格讲明书；审查软件开发打算是否满足对软件项目的功能约束；审查软件开发打算是否满足对软件项目的进度、成本约束；审查软件

5、开发打算是否满足对软件项目的资源约束；审查软件开发打算是否满足对软件项目的其它约束；审查软件开发打算中选定的软件生命周期模型是否合适；审查软件开发打算中标识的每个软件工作产品是否恰当；审查软件开发打算中对软件规模的可能是否科学合理；审查软件开发打算中对软件的工作量和成本的可能是否科学合理；审查软件开发打算中对关键资源的可能是否科学合理；审查软件开发打算中对软件风险的可能是否科学合理；审查资金使用打算是否科学合理；审查人员使用打算是否科学合理；审查软件测试打算的制定是否恰当；审查软件开发打算中的进度安排是否合理；审查软件开发打算是否切实可行；标记出软件开发打算中存在的所有问题及相应的处理意见，并

6、详细记录在“软件开发打算评审报告”中。实施项目打算序号行为要项行为标准3.1跟踪软件开发过程跟踪软件开发过程，确保软件开发是依照软件开发打算分时期进行的；跟踪所有软件工作产品的规模；跟踪项目的软件工作量；跟踪项目的软件成本；跟踪项目所用的关键资源；跟踪测试进度；跟踪软件开发进度；跟踪和操纵软件风险。3.2记录项目数据记录在软件开发不同时期软件的实际规模与可能规模；记录在软件开发不同时期软件的实际工作量与可能工作量；记录在软件开发不同时期软件的实际成本与预算成本；记录在软件开发不同时期实际岗位的设置与对岗位的需求；记录在软件开发不同时期关键资源的实际使用情况与对关键资源的需求；记录在软件开发不同

7、时期测试工作情况与打算要求；记录在软件开发不同时期软件开发的实际进度与打算进度；记录在软件开发不同时期遭遇的实际风险与可能风险。3.3修改软件开发打算当下列事件发生时，应修订软件开发打算：（1）制订软件开发打算的基础发生变化，例如，软件需求发生变更，软件项目的约束条件发生变化等；（2）软件开发的实际过程严峻偏离软件开发打算；（3）在软件项目的里程碑处。修订后的软件开发打算必须提交软件过程治理组，由软件质量保证小组进行评审，评审通过后才能用于指导后续软件开发活动。4、 总体设计序号行为要项行为标准4.1软件总体设计深入理解软件系统的需求规格讲明；深入分析软件系统的各个问题域组成元素；编制软件总体

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

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

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

11、书。5.4模块设计评审审查模块设计报告是否符合规范要求；审查模块设计模型是否正确地反映了纳入软件配置治理的模块分析模型，没有错误和遗漏；确认模块设计模型内部是一致的，没有矛盾；确认模块设计模型的陈述是无歧义的；确认模块设计模型是可实现的；确认模块设计模型与纳入软件配置治理的模块分析模型间可追踪性；标记出模块设计模型中存在的所有问题及相应的处理意见，并详细记录在“模块设计评审报告”中。实现序号行为要项行为标准6.1系统级实现在系统设计讲明书基础上对系统的主体结构进行程序编码，建立各模块可用的系统构架和接口；程序编写、调试和架构测试，完成系统设计所要求的指标；编写系统实现讲明书，提交源代码和程序。

12、；6.2模块级实现在模块设计讲明书基础上对系统的各个模块进行程序编码；程序编写、调试，完成模块设计所要求的指标；编写模块实现讲明书，提交源代码和程序。；6.3单元测试以模块设计讲明书为依据，审查模块实现讲明书，看是否存在实现上的错误或遗漏；确定测试目标；确定测试方案和测试打算；设计测试程序和测试用例；依据模块设计讲明书，确定采纳测试程序和测试用例进行测试时应产生的预期结果；用测试程序和测试用例进行测试，记录测试结果；将测试结果与预期结果进行比较和分析，并将分析结果文档化。6.4集成测试以系统设计讲明书为依据，审查系统实现讲明书，看是否存在实现上的错误或遗漏；确定测试目标；确定测试方案和测试打算

13、；设计测试程序和测试用例；依据系统设计讲明书，确定采纳测试程序和测试用例进行测试时应产生的预期结果；用测试程序和测试用例进行测试，记录测试结果；将测试结果与预期结果进行比较和分析，并将分析结果文档化。6.5系统测试以软件需求规格讲明书为依据，确定测试目标；确定测试方案和测试打算；设计测试程序和测试用例；依据软件需求规格讲明书，确定采纳测试程序和测试用例进行测试时应产生的预期结果；用测试程序和测试用例进行测试，记录测试结果；将测试结果与预期结果进行比较和分析，并将分析结果文档化。项目总结序号行为要项行为标准7.1总结开发成果提取实际软件产品的功能特征、性能特征和质量属性；将实际进度与原定打算进行

14、对比，明确讲明实际进度是否与打算进度吻合。，如不吻合，应讲明实际进度是提早了依旧延迟了，分析要紧缘故；统计实际软件产品的规模和所耗工时；总结开发经费使用情况。7.2对开发工作进行评价统计实际生产效率，包括文档的生产效率和代码的生产效率；统计测试中检查出来的以每千条语句中的错误语句数度量的错误发生率；评价开发中使用的技术、方法和工具；分析开发中出现的错误的缘故；统计产品交付后发觉的问题及排错所耗费的人力物力。7.3总结经验教训总结开发工作中最要紧的经验与教训；对今后的项目开发工作提出建议。8、变更操纵序号行为要项行为标准8.1提出变更请求所有软件变更请求均应按规定的方式提出；依照产生变更请求的缘

15、故，假如是问题，则讲明产生问题的应用模式、配置、及出现问题的现象以及其他有关材料；假如是改进，则要提出一份修改讲明书，列出所希望的修改；假如是新需求，则对新需求进行详细描述；按照软件维护时期的变更操纵过程的要求填写软件变更状态报告相应部分8.2评估变更请求评估过程应该保持中立性，尽量考虑项目当前的资源情况，在市场压力和项目开发治理之间予以均衡。；8.3变更请求决策变更操纵者组织某个或一些变更评估者对软件变更请求进行评估；变更操纵者依照评估结果做出是否实现该变更的决策并填写软件变更状态报告；若评估通过则交给相应的变更实现负责人；若不通过，则讲明驳回的缘故。；8.4变更方案论证变更实现负责人组织变

16、更实现者对变更请求进行分析，若变更请求不可行，则填写软件变更状态报告，并讲明缘故，通知变更操纵者；若变更可行，变更实现负责人及变更实现者者依照变更请求对实现方案进行描述；变更实现负责人将变更实现方案提交变更操纵者进行方案论证，一旦方案论证过程中发觉了问题，就及时对方案进行修正，直到论证通过。；8.5变更实现变更实现者依照制定的变更实现方案进行实现，并进行严格的测试；假如所做修改对相关的工作（比如用户文档、测试等）会带来阻碍，必须通知这些相关部门和人员。当变更实现完毕时，填写软件变更状态报告相应部分，并交给变更操纵者进行验证。；8.6变更验证变更验证者应对实现者对变更的实现进行严格认确实评阅，需要的时候进行面对面的讨论，保证软件修改可不能对系统造成显示的破坏，并在软件变更状态报告中填写验证讲明。8.7变更验证操纵变更操纵者组织某个或一些变更验证者对变更实现进行验证，并填写软件变更状态报告相应部分；变更操纵者依照变更