软件项目工程处理规范设计.doc

.疾病管理平台软件开发管理规范生效日期：2016.2.19 受控编号：文件编号： BD-jsgf002 版次：Ver1.0 修改状态：总页数 30 正文 28 附录 0编制：李杰 审核：王怀锋 批准：付光伟山东诺安诺泰信息系统有限公司.软件开发行为规范为了把公司已经发布的软件开发过程规范有效地运作于产品开发活动中，把各种规范“逐步形成工程师的作业规范”，特制定本软件开发行为规范，以达到过程控制的目的。与软件开发相关的所有人员，包括各级经理和工程师都必须遵守本软件开发行为规范。对违反规范的开发行为，必须按照有关管理规定进行处罚。本软件开发行为规范的内容包括：软件需求分析、软件项目计划、概要设计、详细设计、编码、需求管理、配置管理、软件质量保证、数据度量和分析等。 本软件开发行为规范，采用以下的术语描述： 规则：在软件开发过程中强制必须遵守的行为规范。 建议：软件开发过程中必须加以考虑的行为规范。 说明：对此规则或建议进行必要的解释。 示例：对此规则或建议从正或反两个方面给出例子。本软件开发过程行为规范由研究技术管理处负责解释和维护。.目 录1 软件需求分析 52 软件项目计划 93 概要设计 114 详细设计 145 编码 186 需求管理 197 软件配置管理 218 软件质量保证 239 数据度量和分析 25.1 软件需求分析1-1：软件需求分析必须在产品需求规格的基础上进行，并保证完全实现产品需求规格的定义。1-2：当产品的需求规格发生变更时，必须修订软件需求规格文档。软件需求规格的变更必须经过评审，并保存评审记录。1-3：必须对软件需求规格文档进行正规检视。1-4：软件需求分析过程活动结束前，必须经过评审，并保存评审记录。1-5：在对软件需求规格文档的正规检视或评审时，必须检查软件需求规格文档中需求的清晰性、完备性、兼容性、一致性、正确性、可行性、易修改性、健壮性、易追溯性、易理解性、易测试性和可验证性、性能、功能、接口、数据、可维护性等内容。说明：参考建议1-1到1-16。1-1：采用以下检查表检查软件需求规格文档中需求的清晰性。序号 问题1 所有定义、实现方法是否清楚地表达了用户的原始要求？2 在功能实现过程、方法和技术要求的描述上，是否没有背离了功能的实际要求？3 是否没有不能理解或造成误解的描述 ？1-2：采用以下检查表检查软件需求规格文档中需求的完备性。序号 问题1 需求定义中是否包含了有关文件（指质量手册、质量计划以及其它有关文件）种所规定的需求定义所应该包含的所有内容？2 需求定义是否包含了有关功能、性能、限制、目标、质量等方面的所有需求？3 功能性需求是否覆盖了所有非正常情况的处理？4 是否对各种操作模式（如正常、非正常、有干扰等）下的环境条件都作了规定？5 是否对所有功能与时间因素有关的方面都作了考虑？6 是否标识出了所有与时间因素有关的功能？它们的时间准则是否都说明了？时间准则的最大、最小执行时间是否都定义了？7 是否标识并定义了在将来可能会变化的需求？8 是否定义了系统所有的输入？9 是否标识清楚了系统输入的来源？10 是否标识出了系统的输出？.11 是否说明了系统输入、输出的类型？12 是否说明了系统输入、输出的值域、单位、格式等？13 是否说明了如何进行系统输入的合法性检查？14 是否定义了系统输入、输出的精度？15 是否定义了系统性能的各个方面？16 在不同负载情况下，是否规定了系统的处理能力？17 在不同情况下，是否规定了系统的响应时间？18 是否充分定义了关于人机界面的需求？19 是否对需求定义进行了可行性分析和相关文件（资料）是否已归档？20 是否对影响需求实现的因素进行了调查，调查结果是否已归档？21 是否有经济效益分析，分析结果是否已归档？22 是否详细描述了有关硬件、软件、操作人员、操作过程等方面的安全性？23 是否评估了本项目对用户、其它系统、环境的影响特性？24 是否按完成时间、重要性对系统功能、外部接口、性能进行了优先排序？1-3：采用以下检查表检查软件需求规格文档中需求的兼容性。序号 问题1 界面需求是否使软硬件系统具有兼容性？2 需求定义的文档是否满足项目文档编写标准？在矛盾时，是否有适当的标准可供选择？1-4：采用以下检查表检查软件需求规格文档中需求的一致性。序号 问题1 各个需求之间是否一致？是否有冲突和矛盾？2 所规定的模型、算法和数值方法是否相容？3 是否使用了标准的术语和定义形式？4 需求是否与其软硬件操作环境相容？5 是否说明了软件对其系统和环境的影响？6 是否说明了环境对软件的影响？7 所采用的技术是否与用户要求的技术一致？1-5：采用以下检查表检查软件需求规格文档中需求的正确性。序号 问题1 需求定义是否满足标准的要求？2 算法和规则是否有科技文献或其它文献作为基础？3 是否定义了对在错误、风险分析中所标识出的各种故障模式和错误类型所需的反应？4 是否参照了有关的标准？5 是否对每一个需求都给出了理由？理由是否充分？6 对设计和实现的限制是否都有论证？1-6：采用以下检查表检查软件需求规格文档中需求的可行性。.序号 问题1 需求定义是否使软件的设计、实现、操作和维护都可行？2 所规定的模型、数值方法和算法是否对待解决问题合适？是否能够在相应的限制条件下实现？3 是否能够达到关于质量的要求？1-7：采用以下检查表检查软件需求规格文档中需求的易修改性。序号 问题1 对需求定义的描述是否易于修改（如是否采用良好的结构和交叉引用表等）？2 是否有冗余的信息？是否一个需求被定义了多次？1-8：采用以下检查表检查软件需求规格文档中需求的健壮性。序号 问题1 是否有容错的需求？1-9：采用以下检查表检查软件需求规格文档中需求的易追溯性。序号 问题1 是否可从上一阶段的文档中找到需求定义中的相应内容？2 需求定义是否明确地表明前阶段中提出的有关需求和设计限制都已被覆盖了？3 需求定义是否便于向后继开发阶段查找信息1-10：采用以下检查表检查软件需求规格文档中需求的易理解性。序号 问题1 是否每一个需求都只有一种解释？2 功能性需求是否以模块方式描述的？是否明确地标识出了其功能？3 是否有术语定义一览表？4 是否使用了形式化或半形式化的语言？5 语言是否有歧义性？6 需求定义中是否只包含了必须的实现细节而不包含不必要的实现细节？是否过分细致了？7 需求定义是否足够清楚和明确使其能够作为开发设计规约和功能性测试数据的基础？8 需求定义的描述是否将对程序的需求和所提供的其它信息分离开来了？1-11：采用以下检查表检查软件需求规格文档中需求的易测试性和可验证性。序号 问题1 需求是否可以验证（即是否可以检验软件是否满足了需求）？2 是否对每一个需求都指定了验证过程？3 数学函数的定义是否使用了精确定义的语法和语义符号？1-12：采用以下检查表检查软件需求规格文档中的性能需求描述。序号 问题.是否精确的描述了所有的性能需求和可容忍的性能降低程度？对每一个性能应包含两方面的内容：1 a. 在最坏情况的执行结果 2 b. 本性能失效后，对系统产生的影响1-13：采用以下检查表检查软件需求规格文档中功能需求描述。序号 问题1 是否清楚、明确地描述了所有的功能？2 所有已描述的功能是否是必须的？是否能满足任务书或系统目标的要求？1-14：采用以下检查表检查软件需求规格文档中的接口需求描述。序号 问题1 是否清楚地定义了所有的接口？3 所有接口是否必须？各接口间的关系是否一致、正确？1-15：采用以下检查表检查软件需求规格文档中的数据需求描述。序号 问题1 在某异常数据（如条件、标志等）下，是否有真正没有考虑到的结果？2 对异常数据产生的结果是否作了精确的描述？1-16：采用以下检查表检查软件需求规格文档中的可维护性需求描述。序号 问题1 需求定义中是否包括了可行的系统维护方法？2 软件系统间的关系是否是松耦合的（即能否保证在对某部分修改后，产生最小的连锁效应）？.2 软件项目计划2-1：软件项目计划必须以产品/软件的需求规格为基础。当发生需求更改时，必须修订软件开发计划。说明：软件项目计划必须依据需求规格进行制定。项目计划中的工作产品和工作任务应保证能完全实现需求规格的定义。当需求更改时，必须考虑需求更改的相关性，修订相应软件开发计划。2-1：制定软件项目计划的活动制定，必须遵守 “软件项目计划规范 ”。2-2：软件经理对软件项目计划的制定和结果负责。2-3：软件经理和相关参与软件项目计划的制定和评审的人员，在参与计划制定之前必须经过软件工程和软件项目计划制定流程的培训。2-2：对于软件项目计划中各项工作产品和工作任务，必须进行规模和工作量的软件估计，并在软件项目计划文档中记录估计的方法和估计数据。说明：参考建议2-4到2-8。2-4：可以使用 PERT统计估计、专家判定平均法、经验类比估计、公式计算等方法，或以上方法的组合，进行软件估计。示例：PERT 统计估计和经验类比估计的结合PERT统计估计值 (最大估计4×期望估计最小估计/ 6估计记录如下：工作产品任务最大估计 期望估计(根据经验类比获得)最小估计 PERT估计规模 工作量 规模 工作量 规模 工作量 规模 工作量XX版本（增加XX特性话统模块概要设计文档页数:45;增加、修改模块设计数目:1212天 文档页数:42;增加、修改模块设计数目:1010天 文档页数:30;增加、修改模块设计数目:55天 文档页数:41;增加、修改模块设计数目:109.5天期望估计值是根据XX版本的话统模块设计的数据获得。.2-5：对某项工作产品和任务的软件，同时采用两种或以上的方法进行估计，以避免一种方法的偏差。2-6：尽量采用历史经验数据进行软件估计。2-7：参照 “软件估计指导书 ”进行软件估计。2-8：软件估计对应项目的任务分解结构进行。说明：软件估计对于项目的任务分解结构对应得越清晰、越细致，相应的估计越准确。2-9：在 “软件项目计划 ”中必须包括项目管理活动的计划。2-10：在 “软件项目计划 ”中包括软件重用计划。包括重用软件部件的计划和开发可重用软件部件的计划。2-11： 在 “软件项目计划 ”包括人员的培训计划。说明：项目人员计划包括需要的人员类型、数量和技术等级的要求，相关人员的开始工作时间、工作周期、接受培训的计划等。2-12：对软件项目进行风险分析与评估。说明：可能存在的风险领域含：需求的不明确和变更、外部的限制与对外的依赖、人力资源的到位情况、人力资源的技术等级满足要求状况、技术问题等。对风险的分析与评估实践包括：从已知的情况推导出潜在风险；对风险进行分析，得出：潜在风险可能引发的问题的影响、潜在风险发生的可能性大小、风险发生的时间段等；排列风险的重点次序；对风险记录成文件（属于软件项目计划中的一部分）；风险经受风险影响人审核，并取得他的同意；根据需要，在开发过程中对风险文档进行维护和修订。2-3：对应工作任务，制定项目的文档计划。2-4：软件项目计划中应该包括正规检视活动计划、软件质量保证计划、软件配置管理计划。软件质量保证计划和软件配置管理计划可以和软件项目计划在同一份文档中，也可以分开为三份文档。.说明：参考建议2-13。2-13:软件质量保证计划和软件配置管理计划作为独立的计划文档。2-14：软件项目计划必须是整个项目开发过程的计划，包括测试。2-15：测试经理对照整个开发计划建立软件验证与确认计划。软件验证与确认计划可作为独立的计划文档。2-5：必须对项目工作进行分解，确定项目的工作任务，任务的责任人、资源要求、时间要求、项目的进度。2-6：必须分析任务之间的依赖性，确定并明确标识项目的关键路径。2-7：“软件项目计划”必须按照文档模板的要求编写。项目组可根据项目的实际情况，对文档模板中的内容进行裁减。项目组对文档模板内容的裁减必须得到上级管理部门（包括产品计划处、软件工程组SEPG）的审核批准。2-8：软件项目计划必须经过评审。说明：参考建议2-16，。2-16：软件项目计划的评审采用以下检查表。序号 问题1 软件项目计划是否完全反映（对应）“软件需求说明书”里的需求？2 软件项目计划是否有开发方法的说明？3 软件项目计划是否有资源需求的说明？4 软件项目计划是否包含风险管理计划？5 软件项目计划是否包含了版本发布的机制？6 软件项目计划是否标识了所有必须的培训计划？7 软件项目计划是否标识了所有内部和外部的传递关系？8 软件项目计划是否标明了项目的依赖关系？9 软件项目计划是否标明了角色和职责？10 软件项目计划是否标明了汇报的机制？11 软件项目计划是否说明了跟踪和监控机制？12 软件项目计划是否包含“软件质量保证计划”和“软件配置管理计划”？13 软件项目计划是否包含项目开发使用的工具？14 软件项目计划是否包含项目的各里程碑的说明？15 进度中是否标明了软件项目计划的关键路径？