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

网上购物系统配置管理计划1.引言近年来，随着信息的全球化和国际互联网的普及化，越来越多的人想使用其无国界、无时间、无地域限制的便利环境来经营拓展商务。因此，网上购物成为互联网应用的最大热点，越来越多的企业通过使用网上购物技术进行商业上的交易以减少成本。当然，还有更多的公司想使用网络技术来架构一个虚拟的店面进行营业交易，企业与消费者通过网络完成交易，非但能使企业降低成本也可以让消费者在一个舒适的地点享受逛街与购物的乐趣。随着网上购物风潮的扩大，将会有更多的公司连上网络进行各项业务，而不只是将公司的产品介绍的网页放在网站上供人浏览而已。 我们开发的就是基于Web的网上购物管理系统，方便个体户去市场进货。从而节约时间和金钱。和是一个以软件工程专业的课程为模板的管理系统,其开发主要包括数据库的建立以及前端应用程序的开发两个方面。共分为5个主要模块，分别为管理员信息模块、会员信息模块、货物信息模块、订单信息模块和销售信息模块。通过网络交易已经成为年轻人的爱好，甚至于遍布各个年龄段。这样的交易平台大大加大了产品的宣传，产品的知名度以及销售效率。所以我们针对性的设计一个网上购物商城，添加一个购物渠道，方便人们的日常生活，让客户直接认识商品，自愿购买。2. 组织及职责在软件配置管理小组中，组内人员要互相配合、分工协作，共同担负起整个项目的软件配置管理工作。其中组内人员的分工如下：A 组长是总体组代表，他对有关软件配置管理的各项工作全面负责，特别要对更改建议的审批和评审负责；而且负责监督在软件配置管理工作中认真执行软件工程规范；B 项目的专职配置管理人员孙阿娜负责检查配置更改时的质量保证措施；还有具体负责实施配置管理工作，并参与各子系统的功能配置检查和物理配置检查； C用户代表负责反映用户对配置管理的要求，并协助检查我们对软件配置管理计划的执行情况；D 项目专职的配置管理人员惠小敏和水雪利协助组长开展各项软件配置管理活动，负责审查所采用的配置管理工具、技术和方法，并负责汇总、维护和保存有关软件配置管理活动的各项记录。3.配置管理环境由于本项目属于中小型项目,工期也不是很长,所以大家同意学SourceSafe，最终决定采用SourceSafe做为配置管理工具。3.1目录结构表格 2:配置库的目录结构序号内容说明路径TCM技术合同管理$prj-Shoping TCMRM需求管理$prj- Shoping RMSPP软件项目规划$prj- Shoping SPPSPTO软件项目跟踪与管理$prj- Shoping SPTOSCM软件配置管理$prj- Shoping SCMSQA软件质量保证$prj- Shoping SQASPE软件产品工程设计$prj- Shoping SPEDESIGN源代码$prj- Shoping SPESOURCECODE目标代码$prj- Shoping SPEBUILD测试$prj- Shoping SPETEST发布$prj- Shoping SPERELEASE3.2 用户及权限表2:配置库的用户权限类别人员权限说明配置管理者水雪利负责项目配置管理，对库拥有所有权限项目管理孙阿娜访问、读质量保证人员惠小敏访问、读开发人员孙阿娜，水雪利，惠小敏，赵旭立访问、读高层管理赵旭立访问、读4.配置管理活动4.1 配置项标识4.1.1 文档所有为本项目编制的文档，都要符合GB 8567中的规定。软件开发负责人继续负责软件系统及其所属的各个子系统所编写的文档数目，可根据GB 8567的规定作适当的剪裁。剪裁方案由技术组提出建议，报总体组批准。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.02014-3-24SOWQTD-School-TCM-SOW-V1.02003-3-24计划项目计划QTD-School-SPP-PP-V1.02014-3-24质量保证计划QTD-School-SPP-SQA-V1.02014-3-24配置管理计划QTD-School-SPP-SCM-V1.02014-3-25需求需求规格说明书QTDSchool-RM-SRS-V1.02014-3-27用户DEMOQTDSchool-RM-Demo-V1.02014-3-28设计总体设计说明书QTD-School-Design-HL-V1.02014-4-3数据库设计QTD-School-Design-DB-V1.02014-4-5详细设计说明书QTD-School-Design-LL-V1.02014-4-10设计术语及规范QTD-School-Design-STD-V1.02014-4-11编程源程序QTD-School-Code-ModuleName-V1.02014-4-12编码规则QTD-School-Code-STD-V1.02014-4-12测试测试计划QTD-School-Test-Plan-V1.02014-4-13测试用例QTD-School-Test-Case-V1.02014-4-13测试报告QTD-School-Test-Report-V1.02014-4-13提交运行产品QTD-School-Product-Exe-V1.02014-4-20验收报告QTD-School-Product-Repoort-V1.02014-4-25用户手册QTD-School-Product-Manual-V1.02014-5-104.1.3 项目基线在SourceSafe中基线由LABEL标识，字母必须为大写。基线管理由项目执行负责人确认，SCCB授权，由配置管理员执行。表4:基线发布计划：基线名称/标识符基线所包含的主要配置项预计建立时间需求需求规格说明书、用户DEMO2003-3-24总体设计总体设计说明书、数据库设计2003-4-3项目实现软件源代码、编码规则2003-6-14系统测试测试用例、测试报告2003-6-204.1.5 配置项的版本管理配置项可能包含的分支从逻辑上可以划分成4个不同功能的分支，让它们分别对应4类工作空间。l 主干分支l 私有分支l 小组分支l 集成分支上面定义的四类工作空间（分支）由项目执行负责人统一管理，根据各开发阶段的实际情况定制相应的版本选取规则，来保证开发活动的正常运作。在变更发生时，应及时做好基线的推进。对配置项的版本管理在不同分支而策略不同：主干分支系统缺省自动建立的物理分支主干分支（/main），BASELINE均以LABEL方式出现在主干分支上。私有分支如果多个开发工程师维护一个配置项时建议建立自己的私有分支。配置管理员对其基本不予管理，如个别私有空间上的版本树过于冗余，将对其冗余版本进行限制。小组分支如果出现小组共同开发该配置项，该分支可视为项目组内部分组的私有空间，存放代码开发过程中的版本分支，由项目组内部控制。集成分支集成测试时在主干分支的特定版本（由LABEL标识清晰）上建立集成分支，测试工作在集成分支上完成。私有分支和小组分支均为可选，必要时建立。4.2 变更管理变更管理的流程是：1) 由请求者提交变更请求，变更控制委员会召开复审会议对变更请求进行复审，以确定该请求是否为有效请求。典型的变更请求管理有需求变更管理、缺陷追踪等。2) 配置管理者收到基线修改请求后,在配置库中生成与此配置项相关的波及关系表3) 配置管理者将基线波及关系表提交给SCCB,由SCCB确定是否需要修改,如果需要修改, SCCB应根据波及关系表,确定需要修改的具体文件,并在波及分析表中标识出来.4) 配置管理者按照出库程序从配置库中取出需要修改的文件5) 项目人员将修改后的文件提交给配置管理者6) 配置管理者将修改后的配置项按入库程序放入配置库7) 配置管理者按SCCB标识出的修改文件,由波及关系表生成基线变更记录表,并按入库程序放入配置库4.3 配置状态统计利用软件问题报告单和软件修改报告单对项目子系统及其支持软件的配置状态进行追踪。对软件问题报告单和软件修改报告单的追踪应由软件配置管理工具自动实现，用户可通过该软件系统对其进行查询。为跟踪工作产品基线，配置管理者需收集下列信息：l 基线类型l 工作产品名称l 配置项名称标识符l 版本号l 更改日期时间l 更改请求列表l 需要更改的配置项l 当前状态l 当前状态发生日期项目组每周提交配置项清单及其当前版本。配置管理人员每半个月提交变更请求的状态统计。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）对软件产品或其阶段产品的任何修改，都必须经过评审、批准后才能重新投入运行或作为阶段产品释放。这一过程用软件修改报告单（software change report）给以记录。软件修改报告单的格式表2。当收到了软件问题报告单之后，配置管理人员便填写软件修改报告单。软件修改报告单要指出修改类型、修改策略和配置状态，它是供配置控制小组进行审批的修改申请报告。表中各项内容的意义如下：A是登记号，它是配置修改小组收到软件修改报告单时所作的编号；B是配置管理人员登记软件修改报告单的日期；C是已经准备好软件修改报告单、可以对它进行评审的时间；D、E和F的意义与软件问题报告单中的D、E和F的意义相同；G填写被处理的软件问题报告单的编号，如该编号中提出的问题只是部分解决，则在填写时要在该编号后附以字母P（Part表示部分之意）；H指出是程序修改、文档更新、数据库修改还是它们的组合，如