人们常常采用“拿来主义”的方法来完成体系“设计”，就是拿别人的成套模板改改来用。我从前在某企业时，曾有一位顾问师负责给写质量手册，当我阅读时发现，竟有一半的部门和角色那个企业根本没有！这是“拿来主义”的极致。那么体系设计有没有方法？
通过软件过程改进，得以构建一套系统的工程化管理体系（以下简称SEMP），该体系是以文档形式来体现的，这些文档分三类，其关系如下：
SEMP体系文档关系
体系设计过程中，应依次采取三种不同的设计方法：概要设计、详细设计、度量设计。
分别输出三类文档：总体文档、过程文档、支持文档。
总体文档描述描述系统总体，指出系统设计依据、总体目标、方针、策略和系统概貌描述；在ISO9000中称为质量手册；过程文件描述具体的活动、谁、什么时候、做什么事，这是系统的主体部分；支持文档的种类非常多，提供具体的方法、规范、模板和工具。比如“JAVA编码规范”、“配置管理工具使用指南”、“项目开发计划模板”。
概要设计
体系的概要设计要完成如下任务：，
Ø 总体方案概述：简述实施方案
Ø 总体策略：自底向上还是自顶向下，一步走还是分步到达
Ø 远景目标：在比较长的一个期限内，比如1-2年，达到什么样的状态
Ø 阶段目标：分解段实施，每阶段的目标
² 第一阶段
² 第二阶段
Ø 设计依据
Ø 流程概述：设计哪些流程？各流程完成什么活动的简要叙述，各流程的相互关系
Ø 生命周期：流程相对与项目生命周期、产品生命周期的关系
Ø 度量系统：度量需要达到的总体目标，源数据的获取、处理、报告、周期、角色。
Ø 文档图例：体系特别是过程文件的图例说明
Ø 责任矩阵：体系的面向角色的职责分解
Ø 体系文件清单：体系各层次文件的名录汇总
关于SPI策略选择已有专述论及，（参见《软件过程改进总体策略选择》）
总体文档不仅仅明确了系统设计的总体，而且还可以极大方便使用者快速把握系统概貌。需要特别一提的是责任矩阵，过程文件通常是以过程为中心描述的，各角色的职责分散在不同的过程文件中，这样难以获得具体角色在体系中究竟何时何地做何事的信息。在总体文档中设置责任矩阵，此问题将迎刃而解。
在此阶段，将选择和裁减有关知识域构成体系设计的理论依据。
可利用的知识域——
Ø CMM：能力成熟度模型，由美国卡内基梅隆大学软件工程研究所提出
Ø ISO9000：国际标准，不只适用于软件
Ø SEBOK：软件工程知识体系
Ø PMBOK：项目管理知识体系，美国项目管理协会提出
Ø PSP：个体软件过程
Ø TSP：小组软件过程
Ø P-CMM：人力资源能力成熟度模型
Ø Best practice：介于理论和实践之间的结合层，经验性的知识，散布与各种著作和报道中
上述知识域多数自成完整系统，要想不拘泥于上述体系，希望获得更灵活设计，需要设计者对上述体系都有着深入的掌握。尤其要对CMM、ISO9000、项目管理知识体系的相互关系进行透彻解析，这些已经有专门的文章论述，在此不赘述。
设计需要考虑的三个关键要素是：诊断识别出的组织的实际需求、组织的资源能力、管理基础和成熟度。
大多数情况下，以下要素是优先需要被重视的：
Ø 配置管理
Ø 项目计划
进一步扩展后可能会包括：
Ø 项目跟踪和监控
Ø 项目启动
Ø 项目收尾
再扩展：
Ø 软件质量保障
Ø 同行评审
Ø 培训。。。。。。
在实际情况中，存在很多复杂情况，缺乏基本软件工程的企业可能需要在实施配置管理的同时实施基本软件工程甚至软件技术，避免配置管理的垃圾进垃圾出问题。不少软件企业的部门一级没有足够权利，造成对SPI的推进乏力，可能需要先解决责权明晰这个基本问题。
样例：体系概要设计输出（部分）
文章来源于领测软件测试网 https://www.ltesting.net/