网上购物系统的配置计划.docx

网上购物系统的配置计划.docx

《网上购物系统的配置计划.docx》由会员分享，可在线阅读，更多相关《网上购物系统的配置计划.docx（11页珍藏版）》请在冰豆网上搜索。

网上购物系统的配置计划

《网上购物系统》配置管理计划

1.引言

近年来，随着信息的全球化和国际互联网的普及化，越来越多的人想使用其无国界、无时间、无地域限制的便利环境来经营拓展商务。

因此，网上购物成为互联网应用的最大热点，越来越多的企业通过使用网上购物技术进行商业上的交易以减少成本。

当然，还有更多的公司想使用网络技术来架构一个虚拟的店面进行营业交易，企业与消费者通过网络完成交易，非但能使企业降低成本也可以让消费者在一个舒适的地点享受逛街与购物的乐趣。

随着网上购物风潮的扩大，将会有更多的公司连上网络进行各项业务，而不只是将公司的产品介绍的网页放在网站上供人浏览而已。

我们开发的就是基于Web的网上购物管理系统，方便个体户去市场进货。

从而节约时间和金钱。

和是一个以软件工程专业的课程为模板的管理系统,其开发主要包括数据库的建立以及前端应用程序的开发两个方面。

共分为5个主要模块，分别为管理员信息模块、会员信息模块、货物信息模块、订单信息模块和销售信息模块。

通过网络交易已经成为年轻人的爱好，甚至于遍布各个年龄段。

这样的交易平台大大加大了产品的宣传，产品的知名度以及销售效率。

所以我们针对性的设计一个网上购物商城，添加一个购物渠道，方便人们的日常生活，让客户直接认识商品，自愿购买。

2.组织及职责

在软件配置管理小组中，组内人员要互相配合、分工协作，共同担负起整个项目的软件配置管理工作。

其中组内人员的分工如下：

A．组长是总体组代表，他对有关软件配置管理的各项工作全面负责，特别要对更改建议的审批和评审负责；而且负责监督在软件配置管理工作中认真执行软件工程规范；

B．项目的专职配置管理人员孙阿娜负责检查配置更改时的质量保证措施；还有具体负责实施配置管理工作，并参与各子系统的功能配置检查和物理配置检查；

C．用户代表负责反映用户对配置管理的要求，并协助检查我们对软件配置管理计划的执行情况；

D．项目专职的配置管理人员惠小敏和水雪利协助组长开展各项软件配置管理活动，负责审查所采用的配置管理工具、技术和方法，并负责汇总、维护和保存有关软件配置管理活动的各项记录。

3.配置管理环境

由于本项目属于中小型项目,工期也不是很长,所以大家同意学SourceSafe，最终决定采用SourceSafe做为配置管理工具。

3.1目录结构

表格2:

配置库的目录结构

序号

内容

说明

路径

TCM

技术合同管理

$\prj-Shoping\TCM

RM

需求管理

$\prj-Shoping\RM

SPP

软件项目规划

$\prj-Shoping\SPP

SPTO

软件项目跟踪与管理

$\prj-Shoping\SPTO

SCM

软件配置管理

$\prj-Shoping\SCM

SQA

软件质量保证

$\prj-Shoping\SQA

SPE

软件产品工程

设计

$\prj-Shoping\SPE\DESIGN

源代码

$\prj-Shoping\SPE\SOURCECODE

目标代码

$\prj-Shoping\SPE\BUILD

测试

$\prj-Shoping\SPE\TEST

发布

$\prj-Shoping\SPE\RELEASE

3.2用户及权限

表2:

配置库的用户权限

类别

人员

权限说明

配置管理者

水雪利

负责项目配置管理，对库拥有所有权限

项目管理

孙阿娜

访问、读

质量保证人员

惠小敏

访问、读

开发人员

孙阿娜，水雪利，惠小敏，赵旭立

访问、读

高层管理

赵旭立

访问、读

4.配置管理活动

4.1配置项标识

4.1.1文档

所有为本项目编制的文档，都要符合GB8567中的规定。

软件开发负责人继续负责软件系统及其所属的各个子系统所编写的文档数目，可根据GB8567的规定作适当的剪裁。

剪裁方案由技术组提出建议，报总体组批准。

4.1.2程序

所有属于本项目的程序、分程序、模块和程序单元，都要按照由项目技术组制订，且经总体组批准的软件系统的命名约定的规定来标识。

4.1.3各类基线

所有属于本项目及其各子系统的各类基线，首先要按照任务书、软件需求规格说明书的规定确定其技术内容，然后按照软件系统的上述命名约定的规定来标识。

4.1.4工具、技术和方法

在软件的开发过程中，与软件配置有关的工具有软件测试工具、软件配置管理工具、文档辅助生成工具与图形编辑工具等到三种。

A．软件测试工具：

它支持用C语言编写的模块的静态分析、结构测试与功能测试。

主要功能为：

协助测试人员判断程序结构与变量使用情况是否有错；给测试人员提供模块语句覆盖C0和分支覆盖率C1的值、并显示未覆盖语句和未覆盖分支的号码及其分支谓词，给出不同测试用例有效性的表格；同时提出功能测试的有效情况，并协助组织最终交付给用户的有效测试用例的集合。

B．软件配置管理工具：

它支持用户对源代码清单的更新管理以及对重新编译与连接的代码的自动组织；支持用户在不同文档相关内容之间进行相互检索并确定同一文档某一内容在本文档中的涉及范围；同时还应支持软件配置管理小组对软件配置更改进行科学的管理。

C．文档辅助生成工具与图形编辑工具：

它主要协助用户绘制描述程序流程与结构的DFD图与SC图、绘制描述软件功能（输入、输出关系）的曲线以及绘制描述系统特性的一些其他图形，同时还可生成若干与软件文档编制大纲适应的文档模板。

用户利用这个工具的正文与图形编辑功能以及上述辅助功能，可以比较方便地产生清晰悦目的文档，也有利于对文档进行更改，这有助于提高文档的编制质量。

有关这些工具的详细需求可参阅这三项工具的需求规格说明书中的规定。

4.2配置控制

软件配置的更改管理适用于本项目的所有文档和代码，其中包括本项目的各个运行软件，也包括为本项目专门开发的支持软件。

配置控制的要点如下：

A．修改批准权限；对本项目各个子系统及其专用支持软件的功能基线、指派基线、产品基线及其集成系统的任何修改（称为A类修改），都必须通过项目配置管理小组讨论，并必须经总体组批准；对本项目各个子系统及其专用支持软件的其他阶段产品的任何修改（称为B类修改），都必须通过本项目各个子系统的配置管理人员审查，并经项目的软件配置管理小组与各个子系统负责人的共同批准并报项目总体组备案。

B．修改审批程序：

上述两类修改的审批程序如表1。

C．修改控制工具：

修改控制工具是协助软件配置管理人员进行配置控制的有效手段。

4.1.2主要配置项如下：

表3配置项列表

类型

主要配置项

标识符

预计正式发表时间

技术合同

《合同》

QTD-School-TCM-Contract-V1.0

2014-3-24

SOW

QTD-School-TCM-SOW-V1.0

2003-3-24

计划

《项目计划》

QTD-School-SPP-PP-V1.0

2014-3-24

《质量保证计划》

QTD-School-SPP-SQA-V1.0

2014-3-24

《配置管理计划》

QTD-School-SPP-SCM-V1.0

2014-3-25

需求

《需求规格说明书》

QTD–School-RM-SRS--V1.0

2014-3-27

用户DEMO

QTD–School-RM-Demo--V1.0

2014-3-28

设计

《总体设计说明书》

QTD-School-Design-HL-V1.0

2014-4-3

《数据库设计》

QTD-School-Design-DB-V1.0

2014-4-5

《详细设计说明书》

QTD-School-Design-LL-V1.0

2014-4-10

《设计术语及规范》

QTD-School-Design-STD-V1.0

2014-4-11

编程

源程序

QTD-School-Code-ModuleName-V1.0

2014-4-12

编码规则

QTD-School-Code-STD-V1.0

2014-4-12

测试

《测试计划》

QTD-School-Test-Plan-V1.0

2014-4-13

《测试用例》

QTD-School-Test-Case-V1.0

2014-4-13

《测试报告》

QTD-School-Test-Report-V1.0

2014-4-13

提交

运行产品

QTD-School-Product-Exe-V1.0

2014-4-20

《验收报告》

QTD-School-Product-Repoort-V1.0

2014-4-25

《用户手册》

QTD-School-Product-Manual-V1.0

2014-5-10

4.1.3项目基线

在SourceSafe中基线由LABEL标识，字母必须为大写。

基线管理由项目执行负责人确认，SCCB授权，由配置管理员执行。

表4:

基线发布计划：

基线名称/标识符

基线所包含的主要配置项

预计建立时间

需求

《需求规格说明书》、用户DEMO

2003-3-24

总体设计

《总体设计说明书》、《数据库设计》

2003-4-3

项目实现

软件源代码、编码规则

2003-6-14

系统测试

《测试用例》、《测试报告》

2003-6-20

4.1.5配置项的版本管理

配置项可能包含的分支从逻辑上可以划分成4个不同功能的分支，让它们分别对应4类工作空间。

●        主干分支

●        私有分支

●        小组分支

●        集成分支

上面定义的四类工作空间（分支）由项目执行负责人统一管理，根据各开发阶段的实际情况定制相应的版本选取规则，来保证开发活动的正常运作。

在变更发生时，应及时做好基线的推进。

对配置项的版本管理在不同分支而策略不同：

主干分支

系统缺省自动建立的物理分支——主干分支（/main），BASELINE均以LABEL方式出现在主干分支上。

私有分支

如果多个开发工程师维护一个配置项时建议建立自己的私有分支。

配置管理员对其基本不予管理，如个别私有空间上的版本树过于冗余，将对其冗余版本进行限制。

小组分支

如果出现小组共同开发该配置项，该分支可视为项目组内部分组的私有空间，存放代码开发过程中的版本分支，由项目组内部控制。

集成分支

集成测试时在主干分支的特定版本（由LABEL标识清晰）上建立集成分支，测试工作在集成分支上完成。

私有分支和小组分支均为可选，必要时建立。

4.2变更管理

变更管理的流程是：

1）     由请求者提交变更请求，变更控制委员会召开复审会议对变更请求进行复审，以确定该请求是否为有效请求。

典型的变更请求管理有需求变更管理、缺陷追踪等。

2）     配置管理者收到基线修改请求后,在配置库中生成与此配置项相关的波及关系表

3）     配置管理者将基线波及关系表提交给SCCB,由SCCB确定是否需要修改,如果需要修改,SCCB应根据波及关系表,确定需要修改的具体文件,并在波及分析表中标识出来.

4）     配置管理者按照出库程序从配置库中取出需要修改的文件

5）     项目人员将修改后的文件提交给配置管理者

6）     配置管理者将修改后的配置项按入库程序放入配置库

7）     配置管理者按SCCB标识出的修改文件,由波及关系表生成基线变更记录表,并按入库程序放入配置库

4.3配置状态统计

利用软件问题报告单和软件修改报告单对项目子系统及其支持软件的配置状态进行追踪。

对软件问题报告单和软件修改报告单的追踪应由软件配置管理工具自动实现，用户可通过该软件系统对其进行查询。

为跟踪工作产品基线，配置管理者需收集下列信息：

●        基线类型

●        工作产品名称

●        配置项名称／标识符

●        版本号

●        更改日期／时间

●        更改请求列表

●        需要更改的配置项

●        当前状态

●        当前状态发生日期

项目组每周提交配置项清单及其当前版本。

配置管理人员每半个月提交变更请求的状态统计。

5.配置管理报表及其格式

5.1软件问题报告单（SPR）

在系统的运行与维护阶段对软件产品的任何修改建议，或在软件开发的任一阶段中对前面各个阶段的阶段产品的任何修改建议，都应填入软件软件问题报告单。

软件问题报告单位的格式见表1。

5.1.1配置管理人员填写内容

表中A、B、C、P和状态等项目是由负责修改控制的配置管理人员填写的。

表中其他各项即D、E、F、G、H、I、K、N和O各项是由发现问题的人或申请配置管理的人填写的，他可能还要填写J、L和M三项内容。

前四项内容的意义如下：

A是由配置管理人员确定的登记号，一般按报告问题的先后顺序编号；

B是由配置管理人员登记问题报告的日期；

C是发现软件问题的日期；

P是填写若干补充信息和修改建议。

关于配置管理七种状态的含义在下面解释。

5.1.2配置管理状态

状态一栏分成七种情况，现分别说明如下：

1表示软件问题报告正被评审，已确定采取什么行动；2表示软件问题报告已由指定的开发人员去进行维护工作；3表示修改已经完成、测试好，正准备释放给主程序库；4表示主程序库已经更新，主程序库修改的重新测试尚未完成；5表示已经进行了复测，但发现问题仍然存在；6表示已经进行了复测，已经顺利完成所做的修改，软件问题报告单被关闭（维护已完成）；7表示留待以后关闭，因问题不是可重产生的，或者是属于产品改善方面的，或者只具有很低的优先级等等。

5.1.3配置管理申请人员填写的内容

在软件问题报告单中，属于配置管理申请人填写的各项内容的意义如下：

D、E两项是项目和子项目的名称，F是该子项目的代号，这应按配置标识的规定来命名代号；

阶段名和报告人的姓名、住址和电话等的含义是显而易见的；

G表示问题属于哪一方面的，是程序的问题还是例行程序的问题，是数据库的问题还是文档的问题，是功能性修改还是性能改进性修改问题，也可能是它们的某种组合；

H表示子例行程序/子系统，即要指出出现问题的子例行程序名字，如果不知是哪个子例行程序，可标出子系统名，总之，尽可能给出细节；

I是修订版本号，指出出现问题的子例行程序版本号；

J是媒体，表示包含有问题的子例行程序的主程序库存储媒体的标识符；

K是数据库，表示当发现问题时所使用的数据库标识符；

L是文档号，表示有错误的文档的编号；

M表示出现错误的主要测试实例的标识符；

N是硬件，表示发现问题时所使用的计算机系统的标识；

O是问题描述/影响，填写问题征候的详细描述，如果可能则写明实际问题所在，还要给出该问题对将来测试、界面软件和文档等的影响。

5.2软件修改报告单（SCR）

对软件产品或其阶段产品的任何修改，都必须经过评审、批准后才能重新投入运行或作为阶段产品释放。

这一过程用软件修改报告单（softwarechangereport）给以记录。

软件修改报告单的格式表2。

当收到了软件问题报告单之后，配置管理人员便填写软件修改报告单。

软件修改报告单要指出修改类型、修改策略和配置状态，它是供配置控制小组进行审批的修改申请报告。

表中各项内容的意义如下：

A是登记号，它是配置修改小组收到软件修改报告单时所作的编号；

B是配置管理人员登记软件修改报告单的日期；

C是已经准备好软件修改报告单、可以对它进行评审的时间；

D、E和F的意义与软件问题报告单中的D、E和F的意义相同；

G填写被处理的软件问题报告单的编号，如该编号中提出的问题只是部分解决，则在填写时要在该编号后附以字母P（Part表示部分之意）；

H指出是程序修改、文档更新、数据库修改还是它们的组合，如果仅是指出用户文档的缺陷则在解释处作上记号；

I是修改的详细描述，如果是文档更新，则要列出文档更新通知单的编号；如果是数据库修改，则要列出数据库修改申请的标识号；

J是批准人，经批准人签字、批准后才能进行修改；

K是语句类型，程序修改中涉及到的语句类型包括：

输入/输出语句类、计算语句类、逻辑控制语句类、数据处理语句类（如数据传送、存放语句）；

L是程序名，指被修改注程序、文档或数据库注名字。

如果只要求软件修改报告单做解释性工作，则注重复软件问题报告单给出的名字；

M指当前注版本/修订本标识；

N指修改后的新版本/修订本标识；

O指数据库，如果申请数据库修改，这里给出数据库的标识符；

P是数据库修改申请号DBCR；

Q指文档，即如果要求文档修改，则在这里给出文档的名字；

R是文档更新通知单编号DUT；

S表示修改是否已经测试，指出已对修改做了哪些测试，如单元、子系统、组装、确认和运行测试等，并注明测试成功与否；

T指出在软件问题报告单中给出的问题描述是否准确，并回答是或否；

U是问题注释，准确地重新叙述要修改的问题；

V指明问题来自哪里，如系统设计规格说明书、软件需求规格说明书、概要设计说明书、详细设计说明书、数据库、源程序等；

W说明完成修改所需要的资源估计，即所需要的人月数和计算机终端时数；

X指出所要进行修改的类型，由执行修改的人最后填写。

修改类型主要有适应性修改、改进性修改以及计算错误、逻辑错误、输入和输出错误、接口错误、数据库错误、文档错误以及配置错误等的修改；

Y是提出对软件问题进行修改的人员或单位；

Z是完成软件问题修改的人员或单位。