软件开发标准化工作流程

1目录
1 引言 (3)
1.1 编写目的 (3)
1.2 适用范围 (3)
1.3 定义 (3)
1.4 流程图 (4)
2 需求调研 (5)
2.1 概述 (5)
2.2 需求调研 (5)
2.3 注意事项 (6)
3 可行性分析 (7)
4 需求分析 (8)
4.1 概述 (9)
4.2 产物/成果 (10)
4.3 需求分析任务 (11)
4.4 需求分析方法 (11)
4.4.1 原型化 (11)
4.5 需求报告 (12)
4.6 划分需求的优先级 (13)
4.7 评审需求文档和原型 (13)
5 系统设计 (14)
5.1 概述 (14)
5.2 产物/成果 (14)
5.3 产品设计 (15)
5.3.1 概述 (15)
5.3.2 流程图 (15)
5.4 软件设计 (16)
5.4.1 概述 (16)
5.4.2 流程图 (16)
5.4.3 概要设计 (16)
5.4.3.1 数据库系统设计 (17)
5.4.4 详细设计 (19)
6 软件开发 (20)
6.1 建立项目开发团队 (20)
6.2 实施项目开发测试 (20)
6.3 工作内容 (20)
6.4 产物/成果 (21)
7 项目测试 (23)
7.1 软件测试阶段 (23)
7.2 概述 (23)
7.3 流程 (23)
7.4 软件测试准备 (24)
7.5 软件测试执行 (24)
8 内部验收 (25)
8.1 文档准备 (25)
8.2 内部验收测试 (26)
8.3 内部评审 (26)
9 项目试运行与验收 (26)
9.1 验收前的准备 (26)
9.2 用户测试 (26)
9.3 用户确认 (27)
10 项目维护 (27)
10.1 错性维护 (27)
10.2 完善性维护 (27)
11 需求变更流程 (28)
11.1 目的 (28)
11.2 适用范围 (28)
11.3 作业流程 (29)
11.4 流程描述 (29)
11.4.1 内部项目 (30)
11.4.2 外部项目 (30)
11.5 提交需求变更 (31)
11.6 审核评审 (32)
11.6.1 工作内容 (32)
11.6.2 相关角色 (32)
11.7 反馈 (33)
12 附录 (33)
12.1 附录1《软件需求说明书》 (33)
12.2 附录2《概要设计说明书》 (33)
12.3 附录3《数据库设计说明书》 (33)
12.4 附录4《详细设计说明书》 (33)
12.5 附录5《用户使用手册》 (33)
12.6 附录6《软件测试说明》 (33)
12.7 附录7《项目开发计划》 (33)
12.8 附录8《软件测试计划》 (33)
12.9 附录9《软件测试方案》 (34)
12.10 附录10《测试用例文档》 (34)
12.11 附录11《缺陷报告》 (34)
12.12 附录12《软件测试报告》 (34)
12.13 附录13《需求变更申请表》 (34)
软件开发标准化工作流程
2引言
2.1编写目的
2.2说明编写这份软件开发标准化工作流程的目的, 指出预
期的读者。

2.3合用范围
互联网开发中心所有项目。

2.4定义
列出本文献中用到的专门术语的定义、外文首字母组词的原词组。

2.5 流程图
3需求调研
3.1概述
3.2需求调研对于一个应用软件开发来说, 是一个系统开发
的开始阶段, 需求调研的质量对于一个应用软件来说, 是一个极其重要的阶段, 它的质量在一定限度上来说决定了一个软件的交付结果。

如何从客户中听取用户需求、分析用户需求就成为调研人员最重要的任务。

3.3需求调研
●总体而言, 需求调研可按照业务流程、业务规则、表单数据、贯穿系统的关系四个方向
来进行调研。

●业务规则
●各个流程、功能点等事项的办理, 都会有相关约束或条件, 那么需要对其前置条件、后
置条件、数据验证、条件判断等进行分析调研。

调研对象一般为操作员。

●表单数据
对各个功能点的业务数据、数据项、表单格式、查询条件以及其它相关数据进行明确的分析调研。

调研对象一般为操作员。

●贯穿系统的关系
3.4各个模块或科室之间的数据互换、传递以及数据共享等,
需要我们调研人员与各个模块或科室的相关负责人进行多方沟通, 拟定一个多方满意的需求调研结果。

3.5注意事项
●调研过程中, 用户说的不久, 不也许等我们所有记录之后, 再讲下一个问题。

因此, 只
能在笔记本上速记, 有时只能记录1.2个关键字。

因此, 天天调研结束之后, 当天晚上必须整理当天的调研情况, 写成一份调研日记。

整理当天的调研记录时, 还要整理出待明确的问题, 下一次再找机会与用户再沟通、确认。

●调研的各个阶段, 必须出具相关文档或文献, 比如调研计划、流程图、表单样式、报表
格式、背景图片、数据项列表、讨论记录、问题列表等。

●所有疑问必须等到明确的答复, 不能出现互相矛盾、似是而非的需求。

需准确理解客户
的讲解, 假如有问题的先做记录, 之后将整理的问题向客户询问, 得到明确的结果。

需求必须是客户接受和确认的, 不能有臆测的需求。

●要合理安排好时间和进度。

有时候客户尚有自己要做的事情, 不一定能及时相应。

所以
必须提前预约好时间, 保证整个需求调研的进度。

4能积极引导客户。

当客户出现疑虑, 而调研人员能明白且能做好客户想要的东西的时候, 调研人员能及时积极引导客户, 具体讲解我们所知道的东西, 并能让客户接受与确认。

5如遇公司有相关原型或产品, 调研人员需先具体了解公司的相关原型和产品, 根据成品, 找出本地化的差异化需求。

6可行性分析
这个阶段要回答的关键问题: “对于上一个阶段所拟定的问题有行得通的解决办法吗？”为了回答这个问题, 系统分析员需要进行一次大大压缩和简化了的系统分析和设计的过程, 也就是在较抽象的高层次上进行的分析和设计的过程。

可行性研究应当比较简短, 这个阶段的任务不是具体解决问题, 而是研究问题的范围, 探索这个问题是否值得去解, 是否有可行的解决办法。

7在问题定义阶段提出的对工程目的和规模的报告通常比较模糊。

可行性研究阶段应当导出系统的高层逻辑模型（通常用数据流图表达）, 并且在此基础上更准确、更具体地拟定工程规模和目的。

然后分析员更准确地估计系统的成本和效益, 对建议的系统进行仔细的成本／效益分析是这个阶段的重要任务之一。

8可行性研究的结果是使用部门负责人做出是否继续进行这项工程的决定的重要依据, 一般说来, 只有投资也许取得较大效益的那些工程项目才值得继续进行下去。

可行性研究以后的那些阶段将需要投入更多的人力物力。

及时中止不值得投资的工程项目, 可以避免更大的浪费。

9需求分析
9.1概述
这个阶段的任务仍然不是具体地解决问题, 而是准确地拟定“为了解决这个问题, 目的系统必须做什么”, 重要是拟定目的系统必须具有哪些功能。

用户了解他们所面对的问题, 知道必须做什么, 但是通常不能完整准确地表达出他们的规定, 更不知道如何运用计算机解决他们的问题；软件开发人员知道如何使用软件实现人们的规定, 但是对特定用户的具体规定并不完全清楚。

因此系统分析员在需求分析阶段必须和用户密切配合, 充足交流信息, 以得出通过用户确认的系统逻辑模型。

通常用数据流图、数据字典和简要的算法描述表达系统的逻辑模型。

9.2在需求分析阶段拟定的系统逻辑模型是以后设计和实现
目的系统的基础, 因此必须准确完整地体现用户的规定。

系统分析员通常都是计算机软件专家, 技术专家一般都喜欢不久着手进行具体设计, 然而, 一旦分析员开始谈论程序设计的细节, 就会脱离用户, 使他们不能继续提出他们的规定和建议。

较件工程使用的结构分析设计的方法为每个阶段都规定了特定的结束标准, 需求分析阶段必须提供完整准确的系统逻辑模型, 通过用户确认之后才干进入下一个阶段, 这就可以有效地防止和克服急于着手进行具体设计的倾向。

9.3需求分析是软件工程中的一个重要环节。

是关乎软件开发
成败的重要因素。

现在软件项目中返工开销几乎占了总开发的一半, 而导致返工的重要因素是需求分析不明确。

从而引发软件开发中的一些列更改。

这些更改也许导致浪费大量资源、软件项目无法准时完毕等严重问题, 所以需求分析是软件设计和实现的基础, 是软件项目迈向成功的重中之重。

9.4产物/成果
9.5需求分析任务
9.6简言之, 需求分析的任务就是解决“做什么”的问题, 就
是根据需求调研, 全面理解用户的各项规定并准确的表达所接受的用户需求。

9.7需求分析方法
9.7.1原型化
●原型就是软件的一个初期可运营的版本, 它实现了目的系统的某些或所有功能。

原
型化方法就是尽也许快地建造一个粗糙系统, 这系统实现了目的系统的某些或者
所有功能, 但是这个系统也许在可靠性, 界面的和谐性或其他方面上存在缺陷。

建
造这样一个系统的目的是为了考察某一方面的可行性, 如算法的可行性, 技术的可
行性, 或考察是否满足用户的需求等。

如, 为了考察是否满足用户的需求, 可以用
某些软件工具快速建造一个原型系统, 这个系统只是一个界面, 然后听取用户的意
见改善这个原型。

以后的目的系统就在原型系统的基础上开发。

原型重要有三种类
型:
●探索型
●目的是要弄清楚对目的系统的规定, 拟定所希望的特性, 并探讨多种方案的可行
性。

●实验型
●用于大规模开发和实现前, 考核方案是否合适, 规格说明是否可靠。

●进化型
目的不在于改善规格说明, 而是将系统建造得易于变化, 在改善原型的过程中, 逐步将原型进化成最终系统。

在使用原型方法是有两种不同的策略。

●废弃策略
●先建造一个功能简朴并且质量规定不高的模型系统, 针对这个系统反复进行修改,
形成比较好的思想, 据此设计出比较完整, 准确, 一致, 可靠的最终系统。

系统构建
完毕后, 本来的模型系统被废弃不用。

探索型和实验型属于这种策略。

●追加策略
9.8先构造一个功能简朴并且质量规定不高的模型系统, 最
为最终系统的核心, 然后通过不断地扩充修改, 逐步追加新规定, 发展成为最终系统。

进化型属于这种策略。

9.9需求报告
需求报告及软件需求说明书, 作用在于便于用户、开发人员进行理解和交流, 反映出用户问题的结构, 可以作为软件开发工作的基础和依据, 并作为确认测试和验收的依据。

通过从客户那里获得的所有信息进行整理, 以区分业务需求及规范、功能需求、质量目的、解决办法和其他信息。

通过这些分析, 形成一份《软件需求说明书》, 此份说明书使开发人员和客户之间针对要开发的产品内容达成协议。

客户需要评审此文档, 以保证内容准确完整的表达其需求。

一份高质量的“需求说明书”有助于开发人员开发出真正需要的产品。

输出:
9.10《软件需求说明书》, 格式参照附录1《软件需求说明
书》
9.11划分需求的优先级
绝大多数项目没有足够的时间或者资源实现功能性的每个细节。

决定哪些特性是必要的, 哪些是重要的, 是需求开发的重要部分, 这只能由客户负责设定需求的优先级, 由于开发者不也许按照客户的观点决定需求优先级。

开发人员将为拟定的优先级提供有关每个需求的花费和风险的信息。

9.12在时间和资源的限制下, 关于所需特性能否完毕或者完
毕多少, 开发人员必须给出意见。

9.13评审需求文档和原型
客户评审需求文档, 是给分析人员带来反馈信息的一个机会。

假如客户人为编写的“需求分析报告”不够准去, 就有必要尽早告知分析人员并为改善提供建议。

更好的办法是先为产品开发一个原型。

这样客户就能提供更有价值的反馈信息给开发人员, 是他们更好的理解需求。

10原型并非是一个实际应用产品, 但开发人员能将其转化、扩充成功能齐全的系统。

11系统设计
制定项目计划
软件项目计划是一个用来协调所有其他计划, 以指导项目执行和控制的可操作文献。

它体现了对客户需求的理解, 是开展项目活动的基础, 也是软件项目跟踪与监控的依据。

拟定开发过程
根据软件项目和项目组的实际情况, 建立起一个稳定、可控的软件开发过程模型, 并按照该过程来进行软件开发。

加强过程控制
过程控制重要涉及过程管理、变更控制和配置管理。

11.1概述
11.2此阶段重要是根据需求分析的结果, 对整个软件系统进
行设计, 如系统框架设计, 数据库设计等等。

11.3产物/成果
2.组织安排本阶段的
评审
1、任务分解, 责任到人
2.细化项目计划
1、产出:
2、项目计划（具体
到各功能）1、产出:
2、界面原型
计
2.数据库设计
1、产出:
2、系统功能的技
术设计
3、数据库设计说
明书
划评审
产出:
1.项目测试估
计测试计划书
11.4产品设计
11.4.1概述
产品设计是专业的技术人员根据软件项目需求分析的结果来对整个软件系统进行定制、开发、设计的一个过程。

11.4.2流程图
11.5软件设计
11.5.1概述
11.5.2软件设计阶段重要工作可分为软件概要设计、具体设
计两个分阶段。

对于复杂限度不高、规模较小或关键性级别较低的软件, 可将概要设计和具体设计合并为一个阶段执行。

11.5.3流程图
11.5.4概要设计
在概要设计阶段, 项目组应根据软件总体框架、软件模型和软件工程实现的规定, 提出软件设计方法, 建立软件的总体结构, 划分功能模块（软件部件）, 拟定总体结构和部件间的关系, 定义各个软件功能模块的功能、数据接口和控制接口, 设计全局数据库/数据结构, 规定设计限制, 编写《概要设计说明》, 由研究室或项目组负责人审批。

对于复杂软件, 研究室或项目组应组织对软件概要设计进行评审, 以保证软件结构、全局数据结构、重要算法、模块划分、接口关系和软件模型的合理性、对的性、完整性, 与软件需求的一致性。

项目组应保持评审结果及任何须要措施的记录。

输出:
《软件概要设计说明书》（概要设计部分）,格式参照附录2《软件概要设计说明书》11.5.4.1数据库系统设计
此数据库设计可单独成册, 特别对大型的数据库应用系统, 即有一个单独的《数据库设计说明书》。

输出:
《数据库设计说明书》,格式参照附录3《数据库设计说明书》
11.5.4.1.1信息模型设计
11.5.4.1.2拟定系统信息的类型（实体或视图）, 拟定系统信息
实体的属性、关键字及实体之间的联系, 具体描述数据库和
结构设计, 数据元素及属性定义, 数据关系模式, 数据约束
和限制。

11.5.4.1.3数据库设计
11.5.4.1.3.1设计依据
11.5.4.1.3.2说明数据被访问的频度和流量, 最大数据存储量, 数据增长量,
存储时间等数据库设计依据。

11.5.4.1.3.3数据库种类及特点
11.5.4.1.3.4说明系统内应用的数据库种类、各自的特点、数量及如何实现互
联, 数据如何传递。

11.5.4.1.3.5数据库逻辑结构
11.5.4.1.3.6说明数据库概念模式向逻辑模式转换所采用的方法论及工具,
完毕数据库概念模式向逻辑模式的转换。

具体列出所使用的数据结
构中每个数据项、记录和文献的标记、定义、长度及它们之间的互相
关系。

此节内容为数据库设计的重要部分。

11.5.4.1.3.7物理结构设计
11.5.4.1.3.8列出所使用的数据结构中每个数据项的存储规定、访问方法、存
取单位和存取物理关系等。

建立系统程序员视图, 涉及: 数据在内存
中的安排, 涉及对索引区、缓冲区的设计；所使用的外存设备及外
存空间的组织, 涉及索引区、数据块的组织与划分；访问数据的方式
方法。

11.5.4.1.3.9数据库安全
11.5.4.1.3.10说明数据的共享方式, 如何保证数据的安全性及保密性。

11.5.4.1.3.11数据字典
11.5.5编写具体的数据字典。

对数据库设计中涉及到的
各种项目, 如数据项、记录、系、文卷模式、子模式等一般要建立起数据字典, 以说明它们的标记符、同义名及有关信息
11.5.6具体设计
在具体设计阶段, 项目组应对概要设计中产生的软件部件进行方法和过程描述, 对程序单元内部细节(算法模型、数据结构、具体接口信息等)进行设计, 为源代码提供必要的说明, 并编写《软件具体设计说明》, 由研究室或项目组负责人审批。

具体设计过程中开始编制《软件测试计划》初稿。

研究室或项目组应组织对具体设计说明进行评审（顾客参与）, 以保证程序单元功能、控制结构、数据结构和算法模型的对的性、合理性, 程序单元接口的明确性、一致性。

项目组应保持评审结果及任何须要措施的记录。

输出:
《软件具体设计说明书》（具体设计部分）格式参照附录4《软件具体设计说明书》
12软件开发
12.1建立项目开发团队
12.2依据业务需求开发任务书中, 对项目完毕时间、费用的规定, 确认项目开发团队人员
数量, 明确项目经理, 建立以项目经理为项目负责人的开发团队。

团队组建完毕后, 项目经理组织团队人员进行交流学习和互相熟悉, 说明项目任务、目的、规模、人员组成、规章制度和行为准则, 个人岗位和责任, 建立团队与外界的初步联系及互相关系, 确立团队的权限, 建立团队的绩效管理机制, 争取公司各方面支持, 根据团员特点分派职责, 收集有关项目信息。

12.3实行项目开发测试
①依据公司软件项目设计开发制度规定和软件项目管理规范, 按照需求实现方案为
项目具体开发做好准备。

②技术人员在项目实现方案框架下
③根据项目实际规定准备好开发环境和测试环境;
④程序员编写程序代码, 测试人员设计测试方案和应用案例;
⑤是对需求实现功能说明书和测试计划、测试案例进行评审;
⑥撰写测试问题报告, 改正软件Bug;
⑦按照规定定期提交相关的项目管理信息资料。

12.4工作内容
软件实现阶段的重要工作是根据软件设计结果, 进行软件代码编制、调试、代码审查和程序单元测试, 验证程序单元与设计说明的一致性。

本阶段的代码审查和单元测试应以开发
人员自查自测为主。

实现过程中应规定编码实现规则、编程语言、数据结构、命名约定和注释规则等并遵守这些规则；尽也许使用辅助设计工具；尽也许地重用已有的软件实现规范、实现方法、代码片段、数据结构、标准函数等。

进行规范化编程, 采用统一的编码风格；实现过程中应全面考虑软件测试工作；充足地考虑到软件的可维护性。

软件实现过程中, 项目组应组织程序调试、代码自查和程序单元自测, 重要涉及对软件各功能模块编码的对的性、程序设计准则的符合性、程序单元测试过程与结果的合理性和对的性以及测试辅助程序的合理性和充足性进行审查和验证, 以保证交付测试的软件与软件设计说明完全符合。

与外部存在多系统交联时, 需要组织或参与联合调试实验, 以验证接口的对的性。

软件实现阶段应开始编写《用户使用手册》和《软件测试说明》文档。

输出:
12.51.《用户使用手册》, 格式参照附录5《用户使用手册》12.62、《软件测试说明》, 格式参照附录6《软件测试说明》12.7产物/成果
13项目测试
13.1软件测试阶段
13.2概述
13.3软件的错误是不可避免的, 所以必须通过严格的测试。

通过对本软件的测试, 尽也许的发现软件中的错误, 借以减少系统内部各模块的逻辑, 功能上的缺陷和错误, 保证每个单元能对的地实现其预期的功能。

检测和排除子系统（或系统）结构或相应程序结构上的错误, 使所有的系统单元配合合适, 整体的性能和功能完整。

并且使组装好的软件的功能与需求保持一致。

13.4流程
13.5软件测试准备
测试组从软件需求分析阶段开始介入, 对需求进行分析, 风险分析, 测试范围等等。

即开始编制软件的测试计划, 在软件概要设计、具体设计和编程实现的过程中逐步完善, 最终形成《软件测试计划》, 并组织测试计划评审。

软件测试计划完毕后开始编写相关测试方案, 编写测试用例, 搭建测试环境。

测试用例完毕后进行评审, 冒烟测试用例覆盖率必须达成100%, 系统测试用例达成95%, 输出:
1)《软件测试计划》, 格式参照附录8《软件测试计划》；
2)《软件测试说明》（含测试用例和测试程序）, 格式参照附录6《软件测试说明》；
3)《软件测试方案》, 格式参照附录9《软件测试方案》；
13.64)《测试用例文档》, 格式参照附录10《测试用例文档》；
13.7软件测试执行
测试人员依据《测试用例》进行软件测试, 对发现的错误进入缺陷管理流程, 并进行回归测试以验证修改的对的性。

测试结束后, 测试人员应编写《缺陷报告》, 及《软件测试报告》。

在测试阶段的后期, 组织《软件测试报告》评审, 重要对软件测试方法、测试过程和测试结果的有效性和对的性进行审查和评价。

项目组应保持评审结果及任何须要措施的记录。

输出:
《缺陷报告》, 格式参照附录11《缺陷报告》；
《软件测试报告》, 格式参照附录12《软件测试报告》。

14内部验收
14.1项目完毕集成测试和系统测试后进行项目内部验收, 重
要有三个环节:
14.2文档准备
项目经理提交内部验收计划、项目开发总结报告、产品发布清单；财务主管提交项目财务预算报告。

14.3内部验收测试
14.4内部验收测试的测试内容与方法虽然与系统测试基本相
同, 但应站在用户验收的角度进行, 由于它是试运营的基础, 通过这一步, 为用户验收作充足的准备。

14.5内部评审
15对提交的所有文档及测试结果进行内部评审, 完毕项目开发总结报告。

16项目试运营与验收
16.1试运营与用户验收阶段的重要任务是, 使所有的工作产
品得到用户的确认。

重要工作有:
16.2验收前的准备
16.3项目经理负责检查产品的完整性, 涉及文档、介质和中
间产品等, 以保证现场实行的成功；负责应用软件的现场安装调试, 完毕安装调试总结报告；负责制定用户验收计划, 并得到客户的确认。

16.4用户测试
16.5用户进行验收测试和系统试运营, 进行文档和系统的移
交。

16.6用户确认
17项目经理负责与客户协调, 协助用户进行项目验收, 形成用户验收报告。

18项目维护
18.1错性维护
18.2由于前期的测试不也许暴露软件系统中所有潜在的和隐
含的错误, 诊断和改正这些错误的过程。

18.3完善性维护
19在软件正常使用过程中, 用户还会不断地提出新的需求, 为了满足用户新的需求而增长软件功能的活动称为完善性维护。

假如需求变更很大, 那完善性维护将转变为软件新版本的开发。

系统维护的宗旨就是提高客户对软件产品的满意度。

保证系统的正常运营是系统维护的主线目的。

20需求变更流程
20.1目的
指导项目部、软件部、质量部、测试部对产品的软件变更需求（简称CR）进行控制和管理, 规范相应的作业流程, 具体地定义了各流程环节中状态、角色和动作。

明确流程中各角色的职责
规范软件缺陷的变更过程
20.2合用范围
所有项目的软件变更需求控制管理。

20.3 作业流程
项目需求已确认，项目
计划已制定
在项目过程中，项目干系人提出需求变更
判断需求变更是否必
要？
不进行需求变更
否判断是需求变更还是新
需求
停止现在正进行的实现，重新分析需求，设计，实
现。

更新开发计划
新需求是否紧急
新需求，且不不影响现有
在下一项目
实现
否
加入当前项目，更新开发计划，增加新需求工作量
是
需求变更，且影响现有
在下一项目启动前，可持续此类需求变更
20.4 流程描述
1. 项目需求拟定, 项目计划确认后。

在项目的任何阶段, 如有任何需求变动发起。

2. 判断是否有必要做需求变更？
3. 如拟定需要需求变更, 评估是否对项目现有设计或实现有影响？
4．假如有影响: 暂停设计或实现, 考虑新需求, 重新需求分析, 设计, 实现, 修改项目计划。

5. 假如没有影响: 评估新需求是否紧急？需要加入当前项目, 或在下一项目实现？。