软件项目开发流程列表Word文档下载推荐.docx

软件项目开发流程列表Word文档下载推荐.docx

《软件项目开发流程列表Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《软件项目开发流程列表Word文档下载推荐.docx（14页珍藏版）》请在冰豆网上搜索。

识别配置项的内容

D．出口准则

基线已定义

1.1.4识别配置项

软件配置项（SCI）是在工程过程中产生或在工程过程中用到的任意项。

它应并入到软件产品中，因而在某种程度上它也定义了软件产品。

软件配置项可以是说明书、计算机程序、数据结构，也可以是在软件产品开发过程中用到的工具。

定义产品所有项的集合统称为软件配置。

1、系统规格说明书

2、软件项目实施计划

3、软件需求规格说明书

4、设计规格说明书（数据设计、模块设计、接口设计、对象描述）

5、源代码清单

6、测试计划和过程、测试用例和测试结果记录

7、操作和安装手册

8、可执行程序（可执行程序模块、连接模块）

9、数据库描述（模式和文件结果、初始内容）

10、用户手册

11、维护文档

12、软件工程标准

13、项目开发小节

1.1.5定义基线

基线是经过评审和批准的配置项的集合。

基线建立之后，基线内容的变更只能经由变更控制机制来实现。

基线在开发周期的不同阶段形成，并由不同的变更授权机构进行控制。

举例来讲：

客户需求基线应该在软件需求分析开始之前形成，并由配置管理委员会（CCB）控制。

另一方面，设计基线应该在所有设计完成之后形成，并由项目经理控制。

图3-1说明通常形成的某些基线。

图3-1典型的软件基线

为实施配置完整性的足够控制，项目组在策划计划过程中应确定必须建立并维护哪些基线。

表3-2列出了各种基线所包含的基本内容。

一般完整的开发项目应建立以下基线：

需求基线

✓客户需求批准后建立

✓软件需求批准后更新

✓由CCB控制

设计基线

✓概要设计和详细设计批准后建立

✓由项目经理控制

代码基线

✓初步完成软件单元编码、检查和进行单元测试后开始建立

测试基线

✓软件发放给测试时建立

可运行基线

✓系统发放给运行使用时建立

对于规模较小的项目、维护性项目、升级项目或特殊项目（如临时性项目）而言，只需使用几个基线就够了——也许少到只需一个。

当然对所有项目而言，建立基线必须得到项目经理、SCM和SQA人员的共同认可。

每项基线必须在软件配置管理计划（SCMP）中做出规定，如：

基线名称

基线内容

在生命周期中哪个阶段建立

由谁负责变更控制的批准

基线

配置项

需求

设计

代码

测试

操作

客户需求

软件需求

概要设计

程序设计文档

数据库设计文档

源代码

可执行代码

测试计划

测试用例，测试规程

开发工具

用户手册

操作手册

图3-2基线内容示例

1.1.6建立可追踪性

可追踪性是配置项及配置项各对象间相互逻辑关系的联系能力。

在软件配置管理中，可追踪性表示既能在软件配置中正向追溯下一个配置目标，也能逆向回溯前一个配置目标。

图3-3可追溯性

如图3-3所示，在软件工程中通常关注两方面的可追踪性：

定义为产品的配置项之间的关系；

定义为产品的配置项和用于验证/确认其产品正确性的配置项之间的关系。

如：

通过客户需求应能追溯到由此导出的软件需求；

同样，通过这些软件需求应能追溯到实现软件需求的设计；

类似地，通过设计应能找到用于验证正确执行的测试用例。

每个项目都应为置于严格配置管理下的受控项建立并维护一个追溯矩阵。

建立或更改配置项的操作人员负责维护该矩阵。

对于小型项目，可用电子表格这样的简单工具对矩阵的追踪性进行维护；

但对大型项目，也许需要较为成熟的配置管理工具的支持。

每个项目的可跟踪矩阵应由CM人员督促项目组的相关人员在各个阶段完成时填写，由CM人员负责汇总、发布。

具体要求如下：

客户需求阶段完成后，由客户需求的编写人员填写可跟踪矩阵的客户需求部分。

软件需求阶段完成后，由软件需求的编写人员对照可跟踪矩阵客户需求部分，填写可跟踪矩阵的软件需求部分。

概要设计阶段完成后，由概要设计的编写人员对照可跟踪矩阵软件需求部分，填写可跟踪矩阵的概要设计部分。

详细设计阶段完成后，由详细设计的编写人员对照可跟踪矩阵概要设计部分，填写可跟踪矩阵的详细设计部分。

软件编码阶段完成后，由软件编码人员对照可跟踪矩阵详细设计部分，填写可跟踪矩阵的软件编码部分。

单元测试阶段完成后，由进行单元测试的人员对照可跟踪矩阵详细设计部分，填写可跟踪矩阵的单元测试部分。

集成测试阶段完成后，由进行集成测试的人员对照可跟踪矩阵概要设计部分，填写可跟踪矩阵的集成测试部分。

系统测试阶段完成后，由进行系统测试的人员对照可跟踪矩阵软件需求部分，填写可跟踪矩阵的系统测试部分。

验收测试阶段完成后，由进行验收测试的人员对照可跟踪矩阵客户需求部分，填写可跟踪矩阵的验收测试部分。

可追踪矩阵的模板应分别放入产品工程卷各分册的模版附录中，需要在产品工程卷各分册的模版附录中增加与上级文档各项的对应关系（概要设计与软件需求的关系、详细设计与概要设计的关系，编码与详细设计的关系，测试与编码的关系等等）。

1.1.7标识方法

这里只统一文档的命名，源代码部分遵循公司的“编码规范”，以下是项目文档命名规范：

<

项目名>

V<

发布版本号>

文件种类>

_<

子系统名称>

[<

模块名称>

]

示例：

文件种类

文档名称

需求分析说明书

CPC-PDMV1.0软件需求分析说明书

软件项目计划

CPC-PDMV1.0软件项目计划

总体方案

CPC-PDMV1.0总体方案

软件模块详细说明书

CPC-PDMV1.0软件模块详细说明书

数据库设计说明书

CPC-PDMV1.0数据库设计说明书

程序配置清单

CPC-PDMV1.0程序配置清单

CPC-PDMV1.0测试计划

测试报告

CPC-PDMV1.0测试报告

CPC-PDMV1.0用户使用手册

操作维护手册

CPC-PDMV1.0操作维护手册

项目总结

CPC-PDMV1.0项目总结

1.1.8配置管理数据库

图3-4可追溯性

2代码审核

2.1目的：

提高软件质量。

2.2流程：

详细设计已完成，代码已提交，逻辑功能已部分实现，可以审核。

在项目进行初期，代码编写进行中，可以由审核人员从提交的代码中审核。

审核以编码规范（见附录4.5）和详细设计（见附录4.4）以及QA（开发过程中针对设计产生的问题与得到回答的记录，见附录4.3）为标准，以面谈或会议的方式进行。

以形成共同的开发规范为目标。

在编码与单元测试结束后，进入代码交叉审核阶段，按照计划，由开发人员互相交换所负责开发的模块，进行审核，形成审核文档，记录审核结果、修改意见。

在项目后期，根据情况，由质量控制人员，对以审核并修改过的提交成果，进一步进行审核与评估，并进一步提出意见，形成审核记录。

《复查报告》（见附录4.2）

项目进行的前、中期阶段进行，尽量在集成测试前，完成全部审核工作。

3测试

框架：

工具：

1开源商业版的Bug跟踪管理系统JIRA

网址：

2免费开源的Bug跟踪管理系统BugFree

3.1单元测试

在编码子阶段，根据详细设计用完成所需程序编写后。

根据单元测试计划进行测试，验证每一个组件的正确、可用。

由模块负责人，以测试代码的形式体现（只针对dao层），并且结合白盒测试的形式，进行功能正确性验证。

3.2集成和集成测试实施

3.2.1目的

根据产品集成策略（顺序）和制定的规程，集成和集成测试产品模块。

根据设计阶段制定的计划，将已通过单元测试的模块构建成一个完整软件结构。

按照制定的顺序进行测试，执行每个阶段的相应测试用例，以发现与接口有关的相关缺陷。

3.2.2流程图

图5集成和集成测试实施流程图

A.入口准则

集成测试用例已发布

代码模块已发布

集成和集成测试环境已搭建

B.工作产品

集成后完整的产品

所有的Bug清单（由Bug管理工具提供）

集成测试报告（见附录4.1）

C.出口准则

完整的产品已发布

Bug清单已发布

集成测试报告已发布

3.2.3子活动

1．集成某两个模块

按照选定的集成顺序，对经过单元测试的模块进行迭代集成成子系统或系统

2．验证接口的功能和性能，填写BUG单

依据集成测试用例，对集成之后的模块进行接口测试，主要考虑的方面：

功能：

数据流/控制流/信息流的发送和接收功能

各个子功能连起来，能否达到预期要求的父功能

性能：

模块间大数据量的传输正常

人机接口：

是否友好

3．程序员接收Bug清单，对打回的模块进行修改、单元测试、评审、发布

3.2.4Bug清单

作为测试人员和程序员交流的接口，Bug清单的形式可以是WEB方式或是纸件，但涉及的内容必须能让程序员读懂，能作为测试完成后进行分析的依据。

内容可以参考：

Bug序号、Bug状态、Bug级别、Bug类型、Bug来源

Bug的第一版本和当前版本

Bug的标题、报告人

Bug对应的开发人员、项目、模块、引入阶段

Bug的测试环境（操作系统、数据库等）、测试过程、内容描述

3.3系统测试

系统测试是依据需求规格验证软件产品的有效性的活动。

这个阶段是为了发现那些只有通过测试整个系统才能暴露的缺陷。

可以使用具有不同测试目的的一系列测试来验证所有系统元素都已正确集成。

3.4验收测试

使软件得以验收和客户处安装。

验收指的是由立项人、客户根据验收报告进行正式的测试，并对测试结果分析，以确定系统是否满足验收准则，当分析结果满足验收测试时。

用户接收软件。

4模板附录

4.1集成测试报告

见文档模版.rar中XXXXITcase（XXXX）.xls

4.2代码审核报告

见文档模版.rar中Review_Page.xls

4.3QA列表

见文档模版.rar中QAList.xls

4.4详细设计

见文档模版.rar中详细设计说明书规范.doc

4.5编码规范

见文档模版.rar中编码规范.doc

4.6可跟踪矩阵

见文档模版.rar中医院信息管理系统项目需求跟踪矩阵.xls

4.7Bug跟踪管理系统