发生了对项目小组而言不可抗拒的变化，例如公司裁员、 机构调整、产品发展战略调整等。 由项目经理向 SCCB 申请更新《项目计划》 ，SCCB 审批之后由 项目经理修改原计划，形成新的计划。具体流程见配置管理的变更 流程。
三、实施设计过程描述
步骤描述 3.1 确定技术路线 确定技术路线，确定技术路线时，在满足用户需求的前提下，需 要考虑未来系统的开发成本、维护成本、未来的延续性、扩充性等 问题。该过程产生《技术路线说明书》 。 3.1.1 技术路线研究 确定技术路线研究的内容和目标、 确定应提交的工作成果、 分配任 务，制定进度表。 在技术路线研究任务结束时，系统分析人员撰写《技术路线说明 书》 ； 3.1.2 技术路线说明评审 见评审过程 3.2 系统架构设计 系统架构设计， 完成系统体系结构层次的划分， 对系统进行分解， 确定子系统功能和子系统之间的关系，确定子系统的功能以及功能 之间的相互关系。该过程产生《架构设计说明书》 。 系统分析 人员 架构设计说明书 系统分析 人员 技术路线说明书 执行人 项目经理 输出 技术路线说明书
一、 需求开发过程描述
步骤描述 1.1 需求收集综述 项目经理制定调研计划后， 确定调研人员和用户单位的配合人员 等信息，召开需求调研启动会后，调研人员到用户单位进行需求调 研，并编写用户需求说明书，用户需求说明书需要通过外部评审（用 户参加） ，经过用户签字确认。 执行人 需求收集 人员 输出 需求调研表 需求调研计划 项目经理、 用户需求说明书
需求收集 1.1.3 编写用户需求说明书 整理《需求调研表》 ，编写《用户需求说明书》 。 人员
用户需求说明书
1.1.4 评审 用户需求说明书要经过内部和外部评审、 在外部评审的时候要求 客户签字确认。 具体见评审过程。 项目经理 进入准则 项目立项表
项目立项
项目经理、 需求分析规格说明书 1.2 需求分析 需求分析人员对用户需求进行分析，划分模块，并输出《需求分 析规格说明书》 。需求分析规格说明书需经过评审，评审通过后，进 入下一步骤。 需求分析 1.2.1 划分模块、功能、操作 根据用户为了完成一个业务而进行的多个操作划分为功能。 根据相关的耦合性比较强、联系比较紧密的几个功能的集合划分 模块。 需求分析 1.2.2 划分角色、权限 对计算机系统中的数据或者用数据表示的其它资源进行访问的 许可划分为一个权限。 一个组织或任务中的工作或位置，它代表了一种资格、权利和责 任划分为一个角色。 需求分析 1.2.3UML 图形化描述及说明 功能模块需要用例图来描述。 各个功能模块之间如果存在耦合需要多个用例图描述。 人员 人员 人员 需求分析 人员
系统分析 人员
模块设计书
编码人员
单元测试计划 单元测试用例 程序源代码
编码人员
代码审查单
编码人员
程序源代码 代码审查单
3.5 单元测试 界面开发人员对自己开发的界面进行点击式测试。 后台程序开发人员根据测试用例对自己编写的代码进行单元测 试，测试过程中的记录，自己记录并进行修改。 最后一次测试结果，将记入单元测试检查单中，以备项目经理 进行检查。 3.6 系统测试 测试人员根据项目的《需求分析规格说明书》《用户需求说明 、 书》 ，参考项目设计文档,编写测试用例，规定测试数据、测试 预期结果等，重点在功能测试，兼顾性能测试。例如：确认需 要测试的功能和不必测试功能；用户界面的确认；硬件、软件 和通信接口的确认等等。编制完成后的测试用例由项目管理部 组织有关人员进行评审，评审后进行管理。 3.6.1 测试报告 测试结束后， 测试人员对测试结果和测试过程等内容进行整理， 形成《测试分析报告》 。 3.6.2 测试评审 由测试负责人对测试的有效性、充分性进行评价，如果使用模 拟测试环境，还应评价模拟环境与现实环境的差异，并把评价结果 反馈给项目经理，确认软件是否通过测试。
3.2.1 系统分析人员确定影响系统设计的约束因素 系统分析人员确定影响系统设计的约束因素， 它包括如下两 部分： （1）需求约束。从需求文档《需求分析规格说明书》中提取需 求约束，例如： 本系统应当遵循的标准或规范 软件、硬件环境（包括运行环境和开发环境） 的约束 接口/协议的约束 用户界面的约束 软件质量的约束，如正确性、健壮性、可靠 性、效率（性能） 、易用性、清晰性、安全性、可扩展 性、兼容性、可移植性等等。 （2）隐含约束。有一些假设或依赖并没有在需求文档中明确指 出，但可能会对系统设计产生影响，系统分析人员应该尽 可能地在此处说明。例如对用户教育程度、计算机技能的 一些假设或依赖，对支撑本系统的软件硬件的假设或依赖 等。 3.2.2 确定设计策略 扩展策略。说明为了方便本系统在将来扩展功能，现 在有什么措施。 复用策略。说明本系统在当前以及将来的复用策略。 折衷策略。说明当两个目标难以同时优化时如何折衷， 例如“时－空”效率折衷，复杂性与实用性折衷。 3.2.3 系统分解设计 将系统分解为若干子系统，确定每个子系统的功能以 及子系统之间的关系。 将子系统分解为若干模块，确定每个模块的功能以及 模块之间的关系。 确定系统开发、测试、运行所需的软硬件环境。 3.2.4 撰写架构设计说明书 软件系统概述 影响设计的约束因素 设计策略 系统总体结构
系统分析 人员
系统分析 人员
系统分析 人员
系统分析 人员
架构设计说明书
子系统的结构与模块功能 开发、测试、运行所需的软硬件环境
3.2.5 架构设计评审 体系结构设计人员邀请同行专家、 开发人员对体系结构进行 正式技术评审，评审流程请参考相关文档。体系结构评审的重点 不是“对还是错”，而是“好还是差”。主要评审要素包括： 合适性。考察该体系结构是否适合于产品需求，是否 可在预定计划内实现。 系统的综合能力。例如“时－空”效率（性能，容量等） ， 可扩展性，可管理性（可维护性） ，可复用性，安全性 等等，视产品特征而定。 3.3 数据库设计 数据库设计，依据《系统需求说明书》《技术路线说明书》《架 、 、 构设计说明书》 ，深入理解客户需求，产生《数据库设计书》 。 系统分析 人员 书 数据库设计说明
3.3.1 数据库设计 数据库设计一般要经历“逻辑设计—>物理设计”等步骤，需要迭代 进行。 1）逻辑设计：数据库设计人员根据需求文档，采用面向对象的方 法发现并建立相应的数据实体，并确定实体之间的关系。 2）物理设计 设计表结构。建立数据实体到物理表的映射，一般地，实体对应于 表，实体的属性对应于表的列，实体之间的关系成为表的约束、外 键等。逻辑设计中的实体大部分可以转换成物理设计中的表，但是 它们并不一定是一一对应的。 对表结构进行规范化处理，一般的要至少遵循“第二范式”的要求； 某些情况下考虑到实现难度和效率的问题，可以依据情况灵活掌握。 3.3.2 评审 系统分析人员邀请同行们对数据库设计进行正式技术评审， 评审 流程请参考相关文档，数据库的主要评审要素包括： 正确性、完整性、一致性 安全性 “时－空”效率 3.4 模块设计 模块设计， 《系统需求分析规格说明书》 架构设计说明书》 依据 、 《 ， 参考《技术路线说明书》《数据库设计书》 、 ，充分理解用户需求，合 理的对系统进行划分，确定每个子系统的模块和功能、对用户界面、 关键接口、关键类、关键算法及其相互关系进行设计和定义，产生 《模块设计书》 。
项目经理 1.1.1 制定调研计划 在初步了解用户的项目之后， 与用户单位的项目负责人协商， 编 写调研计划。调研计划中必须列出调研的内容，调研人员和用户单 位的配合人员等信息。
需求调研计划
项目经理、 会议记录 1.1.2 召开需求调研启动会议 调研启动会议， 要求用户单位的领导以及各相关需求访谈对象参 加，沟通调研计划。 需求调研 调研的对象包括： 用户单位的决策者，主要目的是确定项目希望达到的目标或需 要解决的问题，目标要有主次之分，以便确定整个项目开发计划。 用户单位的有关领导，主要目的是收集用户单位各工作人员之 间的分工协作关系并画出活动图。获取用户单位的岗位分工和职责 说明。 用户单位的工作人员，确定工作人员的职责范围，并记录工作 人员的工作过程。 用户单位信息化建设负责人，了解用户单位的应用环境，包括 网络环境，软件环境，应用环境。并了解对系统的部署要求和应用 模式。 用户单位信息或应用主管，了解项目与其他应用系统的接口。 以上调研内容均应填写《需求调研表》 。 需 求 收集人员、 客户 需求调研表 需求收集 人员、 客户
编码人员
单元测试检查单
测试人员
测试用例
测试人员
测试报告
测试负责 人
会议记录
四、发布与试运行
步骤描述 4.1 编写客户需要的文档 通过单元测试的代码，提交测试库，准备集成测试。 由于这时开发工作临近结束，直接参与软件开发活动的人 数较少，项目经理应当安排开发人员编写各种文档，如《用 户操作手册》 《管理员手册》和客户需要的其他文档。编 、 写完成后应通过同行评审（评审参照《评审过程》进行） 或通过系统和验收测试来验证文档的正确性。验证通过后 提交基线库进行管理和控制。 4.2 用户环境部署 项目经理指定具体人员对实施的软件所需要的软件系统平台、 硬件服务平台和网络环境进行整体搭建和测试，项目经理协助具体 项目经理 软件试运行确认单 执行人 编码人员 输出 《用户操作手册》 《管理员手册》
需求分析 1.2.4 编制需求规格说明书 参照《用户需求说明书》并分析用户需求，形成需求分析规格 说明书。 根据分析结果修改用户需求说明书，最终完善需求分析规格说 明书，此过程可能需多次反复。 1.2.5 评审 见评审过程。 人员
需求分析规格说明书
二、 组织计划
步骤描述 2.1 计划编制前数据搜集 项目组筹建完毕之后，项目经理开始搜集编写开发计划的数据、 人员信息、资源信息、使用方法、工具等。 2.2 编写开发计划文档 项目经理根据上述信息，编写项目开发计划。 项目经理综合上述所有活动编写进度计划。 2.3 评审项目计划 项目经理将《项目计划》提交测试人员、项目组主要成员及合作 方相关人员评审项目计划如果《项目计划》有不合理之处，应根据评 审的意见及时修正《项目计划》 ，确保各计划之间协调一致。 计划评审通过后，项目经理转发给合作方，并通知配置管理人员 建立计划基线。 2.4 项目计划变更控制 若下列之一发生，应当变更原《项目计划》 ： 进度偏差超过了容许的误差，如 10％； 费用偏差超过了容许的误差，如 10％； 项目过程模型发生了的变化； 用户需求发生了的变化；工作量达到 20％； 部门经理 项目经理 项目经理 项目开发计划 进度计划 执行人 项目经理 输出