软件开发项目技术管理规范 4 详细设计
4 详细设计
4-1：详细设计要以软件需求规格和概要设计为基础，必须保证需要实现的需求规格已经被设计，必须保证概要设计定义的所有模块已经被详细设计。
4-2：当需求规格或概要设计发生变更时，必须修订相关详细设计文档。
4-3：在详细设计文档或需求管理文档中，必须记录、验证需求、概要设计、详细设计的跟踪关系。
说明：需求、概要设计、详细设计的跟踪关系可参考建议4-1。
4-1：采用需求、子系统、模块、函数的跟踪矩阵表记录需求、概要设计、详细设计的跟踪关系。 4-4：必须保证详细设计文档和代码的一致性。当发生设计更改时，必须修订相应设计文档。 4-5：必须对重要的详细设计文档进行正规检视。
说明：参考建议4-2。
4-2：根据模块的复杂度、规模和在软件系统中的重要程度，选择重要的详细设计文档进行正规检视。在产品中，进行正规检视的详细设计文档比例要达到60%。
4-6：详细设计过程结束前，必须通过评审，并保存评审记录。 4-7：设计更改必须经过相关评审，并保存评审记录。
4-8：对详细设计文档的正规检视或评审，必须检查详细设计文档的清晰性、完备性、规范性、一致性、正确性、数据、功能性、接口、详细程度、可维护性、性能、可靠性、可测试性、可追溯性。
说明：参考建议4-3。
4-3：采用以下检查表检查详细设计文档的清晰性。
序号 问题 1 是否所有的单元和进程的设计目的都已文档化？ 2 单元设计，包括数据流、控制流、接口描述是否清楚？ 3 单元的整体功能是否描述清楚？ 4-4：采用以下检查表检查详细设计文档的完备性。
序号 问题 1 是否提供了所有程序单元的规格？
仅供内部使用
21
软件开发项目技术管理规范 4 详细设计
2 是否描述了所采用的设计标准？ 3 是否确定了单元应用的算法？（例如：PDL） 4 是否列出了单元的所有调用？ 5 是否记录了设计继承的历史和已知的风险？ 4-5：采用以下检查表检查详细设计文档的规范性。
序号 问题 1 文档是否遵从了公司的标准？ 2 单元设计是否使用了要求的方法和工具？ 4-6：采用以下检查表检查详细设计的一致性。
序号 问题 1 在单元和单元的接口中数据成员的名称是否保持一致？ 2 所有接口之间，接口和接口规格书之间是否保持一致？ 3 详细设计和概要设计文档是否能够完全描述“正在构建”的系统 4-7：采用以下检查表检查详细设计的正确性。
序号 问题 1 是否有逻辑错误？ 2 需要使用常量名称的地方是否有错误？ 3 是否所有的条件都被处理？（>,=,< ,switch case)? 4 分支所处的状态是否正确？（逻辑没有搞反） 4-8：采用以下检查表检查详细设计的数据描述。
序号 问题 1 是否所有声明的数据块都已经使用？ 2 定位于单元的数据结构是否已经描述？ 3 如果有对共享数据、文件的修改，对数据的访问是否按照正确的共享协议进行？（例如：通过信号灯同步进程） 4 是否所有的逻辑单元、事件标记、同步标记都已经定义和初始化？ 5 是否所有的变量、指针、常量都已经定义并初始化？ 4-9：采用以下检查表检查详细设计的功能性要求。
序号 问题 1 设计是否使用了指定的算法？ 2 设计是否能够满足需求和目的？ 4-10：采用以下检查表检查详细设计的接口描述。
序号 问题 1 参数表是否在数量、类型和顺序上保持一致？ 2 是否所有的输入输出都已经正确定义并检查过？ 3 所传递参数的顺序是否描述清楚？ 4 参数传递的机制是否确定？
仅供内部使用
22
软件开发项目技术管理规范 4 详细设计
5 通过接口传递的常量和变量是否与单元设计的相同？（例如，函数中定义的常量不能在所调用的子过程中被修改） 6 传入、传出函数的参数，控制标记是否都已经描述清楚。 7 是否以度量单位描述了参数的值区间，准确性和精度。 4-11：采用以下检查表检查详细设计的详细程度。
序号 问题 1 代码和文档间的展开率是否小于10：1？ 2 对模块的所有需求都已经定义？ 3 详细程度是否足够开发和维护代码？ 4-12：采用以下检查表检查详细设计的可维护性。
序号 问题 1 单元是否是高内聚和低外部耦合？（例如：单元的改变不会在内部出现不可预见的影响，同时对其他单元的影响最小？ 2 是否这种设计是复杂度最小的设计？ 3 开始部分的描述是否符合公司的要求？（例如：目的，作者，环境，非标准特性，开发历史，输入输出参数，使用的文件，数据结构，引用此单元的其他单元，注释。 4-13：采用以下检查表检查详细设计的性能。
序号 问题 1 进程是否有时间窗？ 2 是否所有的时间和空间的限制都已明确？ 4-14：采用以下检查表检查详细设计的可靠性。
序号 问题 1 初始化时是否使用了默认值，是否正确？ 2 访问内存时是否进行了边界检查，以保证地址正确？（队列，数据结构，指针，等等） 3 对输入、输出、接口和结果是否进行了错误检查？ 4 对所有错误情况都安排了有意义的消息反馈？ 5 特殊情况下的返回码是否和文档中定义的全局返回码一致？ 6 是否考虑了异常情况？ 4-15：采用以下检查表检查详细设计的可测试性。
序号 问题 1 是否每个单元都可以被测试、演示、分析或者检视，以确认满足需求。 2 设计中是否包括辅助测试的检查点？（例如：条件编译代码、断言等） 3 是否所有的逻辑都是可测的? 4 是否描述了本单元的测试驱动模块，测试用例集，测试结果? 4-16：采用以下检查表检查详细设计的可追溯性。
仅供内部使用
23
序号 软件开发项目技术管理规范 4 详细设计
问题 1 是否每一部分的设计都可以追溯到需求？ 2 是否每一个设计决策都可以追溯到效益分析？ 3 是否所有的设计决策都可以追溯到成本/效益分析？ 4 是不是描述了每个单元的详细需求？ 5 单元需求是否能够追溯到软件规格文档（SSD-1）？软件规格文档是否能够跟踪到单元需求？ 6 是否有到代码的引用或者包括代码本身？
仅供内部使用
24
软件开发项目技术管理规范
5 编码
5 编码
5-1：编码必须以设计文档为基础，必须保证所有的设计都被编码实现。当设计发生变更时，必须修改相关代码。
5-2：必须保证设计文档和代码的一致性。当代码的修改已经造成设计更改时，必须修订相应设计文档。 5-3：必须对重要的代码进行正规检视。
说明：参考建议5-1。
5-1：根据模块、函数/单元/进程的复杂度、规模和在软件系统中的重要程度，选择重要的代码进行正规检视。在产品中，进行正规检视的代码比例要达到40%。
5-4：在代码已经基线化后，对代码的更改必须通过评审，并保存评审记录。 5-5：代码必须遵守相关的XX信息JAVA编程规范。
5-6：对代码的正规检视和评审，必须依照”XX信息JAVA编程规范”的规定检查编程规范程度，并对代码符合情况进行考量。
5-7：项目编码完成后，必须提交Sonarqube平台进行静态质量检测。
仅供内部使用
25