网上购物系统-软件项目管理大作业

。合同1.1合同双方甲方：胡某某乙方：盛某某1。2供应的商品和服务供应的软件：乙方为甲方提供所需的网上购物系统提供的服务：乙方为甲方提供所需的日常维护和服务器管理.提供的文档：乙方在交付软件时提供详细的软件规格说明书和使用文档。

安装服务：乙方为甲方提供软件的安装。

公文处理：乙方负责将甲方提供的公文资料加载入系统并进行分类。

维护协议：当甲方在使用该产品时，在正常操作的情况下出现BUG或系统错误，乙方免费为甲方提供修复服务以保障软件的正常使用.当由于甲方的错误使用等非软件原因导致出现故障，乙方同样提供修复服务.由于甲方拥有该软件的源代码所有权，因此甲方需要承担部分维修和进一步开发的责任。当软件需要新的功能拓展或改版升级时，由双方共同协商决定。1.3时间地点6月10日上午9:00在河北省沧州市黄骅市1。4专利成果分配该软件是由甲方向乙方定制，甲方拥有该软件的版权，乙方不能将该软件的任何版本卖个其他客户。软件提交时，项目源代码的所有权自动移交到甲方,乙方不得擅自对源代码进行修改。1。5验收标准乙方在开发过程中必须遵守ISO

12207关于软件生命周期和文档的标准。1。6报酬计算软件总价为2万元。合同签订后，甲方向乙方支付1万元定金。项目的第二个月，乙方按计划时间表完成需求分析、系统分析、设计和完成系统的基本框架后，甲方向乙方支付0.5万元.该系统完成后,甲方进行验收测试，在签字验收后完成后，甲方向乙方支付全款。1。7违约处理任何一方违反本协议导致本协议无法继续履行的,违约方需赔偿守约方违约金人民币2万元,该违约金不足以弥补守约方实际损失的,违约方应赔偿守约方所有实际损失。甲方法人代表:胡某某乙方法人代表:盛某某生存期针对本项目的开发特点，参考企业的生存期模型说明和软件过程体系，决定采用增量式模型如下图，理由如下：

1．网上购物系统的全部功能分成管理员和用户功能两大类，因此可以先基于通用功能作出一个最小的使用版本，再逐步添加其余的功能。这样一来，用户可以先试用最小版本的同时,提出更多明确的需求，这有助于下一阶段的开发，大大减小了开发的风险。

2．在网上购物系统需求规格中，要求系统有可扩充性。若使用增量模型,可以保证系统的可扩充性。用户明确了需求的大部分，但也存在不很详尽的地方。如：“关于管理员档案，比照所提供资料设计,现在也没有一个成形的东西";资源库系统只提到“应提供一个标准的资源库解决方案。”这样只有等到一个可用的产品出来，通过客户使用，然后进行评估，评估结果作为下一个增量的开发计划，下一个增量发布一些新增的功能和特性。直至产生最终完善的产品.

3．“系统要求有可扩充性，可以在现有系统的基础上，通过前台就可加挂其它功能模块”.也说明用户可能会增加新的需求。

生存期中各个阶段如下：阶段项目规划阶段目标根据合同和初步的需求分析，确定项目的规模、时间计划和资源需求输入合同文本,SOW过程项目规划,计划确认输出项目计划阶段需求分析阶段目标确定客户的需求输入项目计划，SOW过程需求获取,需求分析，需求控制输出原型系统，需求规格阶段设计阶段目标总体系统结构设计输入原型系统,需求规格过程总体设计输出系统设计说明书，数据库结构定义阶段增量1实现目标实现系统的通用功能输入系统设计说明书，数据库结构定义过程详细设计，编码，代码走查，代码评审，单元测试输出详细设计说明书，源代码,可运行版本—-1阶段增量2实现目标实现系统的用户管理功能输入系统设计说明书,数据库结构定义过程详细设计，编码，代码走查，代码评审，单元测试输出详细设计说明书，源代码,可运行版本--2阶段增量3实现目标实现系统的商品管理功能输入系统设计说明书,数据库结构定义过程详细设计，编码，代码走查,代码评审，单元测试输出详细设计说明书,源代码，可运行版本-—3阶段增量4实现目标实现系统的个人信息管理功能输入系统设计说明书，数据库结构定义过程详细设计，编码，代码走查,代码评审，单元测试输出详细设计说明书，源代码，可运行版本—-4阶段集成测试目标通过集成环境下的软件测试输入测试计划,测试用例过程集成测试，系统测试输出系统软件包，测试报告,产品说明书阶段产品提交目标产品可投入使用输入系统软件包过程产品提交输出验收报告3.需求管理。3。1功能需求需求概述：目标：“网上购物系统”主要提供物品信息和对读者基本信息的维护以及购买等功能。该系统针对的用户是网上购物者，物品的种类和数量较多，系统需要操作方便，方便管理员对整个系统管理和用户对于购买的方便。用户类和特征:最终的用户是管理员和用户，管理员需要进行会员管理，更新物品信息等工作，要求具备计算机知识，如权限管理等。购买者是普通用户，具备一定的计算机操作知识即可。本系统相应的需求有：(1）能够存储大量的商品信息,并方便有效的进行相应的商品数据操作和管理，这主要包括：商品信息的添加、删除及修改。商品信息的多关键字检索查询。商品的出货、退货和资料统计。订单信息管理：查看订单清单、更新订单付款、删除订单。能够对一定数量的用户进行相应的信息存储与管理,这其中包括:用户信息的登记、删除及修改。用户资料，用户订单信息的统计与查询。能够提供一定的安全机制，提供数据信息授权访问。需求补充说明：（1)数据保存:需要长期保存在数据库的数据有：物品信息:物品的基本信息；用户信息：用户的基本信息；下单信息：物品的订单信息；帐号信息:管理员和用户的登录帐号；（2）系统用户：管理员、购物者。管理员:对物品和用户数据可执行添加、修改、删除以及查询等操作.用户：可查询物品，查看商品详细情况,商品选购以及查询与本人相关的订单信息。3。2确定用例用例描述了一个完整的系统事件流程,其重点在于执行者与系统之间的交互而不是内在的系统活动，并对执行者产生有价值的可观测结果。确定用例可以通过提出以下问题得到：–参与者需要从系统中获得什么功能？参与者需要做什么？–参与者读取、产生、删除、修改或存储系统的某些信息吗?–系统中发生事件需要通知参与者吗？参与者需要通知系统某件事情吗？–系统的输入/输出信息是什么？这些信息从哪儿来到哪儿去?–采用什么实现方法满足某些特殊要求？用例图3.3用例文档用例图不能提供用例所具有的全部信息,因此需要使用文字描述那些不能放映在图形上的信息。1。物品信息的维护用例用例名：物品信息的维护参与执行者：管理员入口条件：管理员已经登陆到该系统中.事件流：当有新物品入库时，管理员在录入页面输入物品的信息，点击提交按钮，系统将物品的信息保存到数据库中；当某一种物品的信息需要修改时，管理员通过输入查询条件，搜索出该物品时，点击修改按钮,系统在可编辑状态显示物品的当前信息,管理员修改具体信息，点击保存按钮，系统将更新数据库中该物品的信息,反之,则不进行任何操作。出口条件:系统将数据库中的信息进行相应的操作：添加物品信息时，将新的物品信息保存在数据库中；修改物品信息时，将数据库中该物品的信息做相应的更新操作。异常事件：在物品进行修改时，先查出需要进行处理的物品记录，如果数据库中不错在符合条件的记录,查询无结果时，则无法进行修改操作。2。用户信息的维护用例用例名：会员信息的维护参与执行者：管理员入口条件：管理员已经登陆到该系统中。事件流：当有新的会员时，管理员在录入页面输入会员的信息，点击提交按钮，系统将会员的信息保存到数据库中;当某一会员的信息需要修改时,会员通过输入查询条件，搜索出该信息时，点击修改按钮,系统在可编辑状态显示当前信息，会员修改具体信息,点击保存按钮，系统将更新数据库中该会员的信息，反之，则不进行任何操作。出口条件：系统将数据库中的会员信息进行相应的操作:添加会员信息时，将新的会员信息保存在数据库中；修改会员信息时，将数据库中该会员的信息做相应的更新操作.异常事件:在进行修改会员信息时，先查出需要进行处理的会员记录，如果数据库中不错在符合条件的记录,查询无结果时，则无法进行修改操作。3。物品信息的查询用例用例名：物品信息的查询参与执行者：管理员、购物者入口条件:无事件流:通过交互界面输入查询条件(如物品名，产地名等）搜索物品记录。出口条件:若有符合条件的物品信息,则系统显示这些物品信息。否则系统提示用户重新输入查询条件.4。会员信息的查询用例用例名：会员信息的查询参与执行者：管理员入口条件：用户已经登陆到该系统中。事件流:通过查询界面输入查询条件(如会员ID,会员名称等)搜索待会员记录.出口条件：若有符合条件的会员信息，则系统显示会员信息。否则系统提示用户重新输入查询条件.5。查询个人基本信息用例用例名:查询个人基本信息参与执行者：会员入口条件：用户已经登陆到该系统中。事件流:点击查询个人基本信息按钮。出口条件：系统显示会员本人信息.6。查询个人订单信息用例用例名:查询个人订单信息参与执行者：会员入口条件:用户已经登陆到该系统中。事件流：点击查询个人订单信息按钮.出口条件:系统显示读者的订单信息。7.下单用例用例名：下单参与执行者：管理员、会员入口条件：管理员已经登陆到该系统中。事件流：管理员在下单页面，输入物品编号和会员ID,点击保存。出口条件：系统将这条下单记录保存到数据库中.异常事件：如果该物品未入库，数据库中不存在该物品编号，提示“该物品没有库存”;如果数据库中不存在该会员ID，也相应的做出提示.8.退货用例用例名：退货参与执行者：管理员、会员入口条件：管理员已经登陆到该系统中.事件流：管理员在退货页面,输入物品编号，点击退货.出口条件：系统将记录数据库中这条退货记录。异常事件：如果该物品退货时间已过期，提示“该物品不能退货”.9。口令管理用例用例名：口令管理参与执行者：管理员、会员入口条件:会员已经登陆到该系统中。事件流:用户点击“修改密码”按钮,在口令修改页面输入新的密码，点击保存按钮。出口条件：数据库中的密码被修改成最新的密码。3。4非功能需求3.4.1性能需求网上购物系统的使用者是管理员和购物者。对于管理员的管理工作，性能要求不是很严格，但需要方便物品信息更新等操作。对于购物者的物品下单、查询等功能,对性能要求较高，一般需要达到并发数200以上。3.4。2安全性需求由于网上购物系统的商品量会非常大，所有在对这些商品添加和查询时要保证速度。在对物品下单过程中又要保证事务的完整性.对于整个系统，需要完整的权限控制,防止某些人恶意的攻击系统，修改原始记录。同时对于数据库中的数据需要定时备份,防止系统数据丢失。此外，系统要求用户在登陆时需要身份验证。3.4.3故障处理在正常情况下，应不出错。一旦发生意外，比如掉电、网络不通等，应保证系统数据不会丢失。4。任务分解项目任务分解编码表编码任务名称备注R000000需求讨论初步确定需求P000000软件规划制定项目计划P100000项目规划P200000计划评审M000000需求开发细化需求M100000用户界面设计M200000用户需求评审M300000修改需求、界面M400000编写需求说明M500000需求验证D000000设计完成项目设计工作D100000概要设计D200000数据库ER图编制、建库D300000设计评审C000000实施实际开发C100000用户管理C100100用户注册C100200用户注销C100300账号登陆C100400个人信息管理C200000物品管理C200100更新物品信息C200200删除过期物品信息C200300查看物品信息C300000会员管理C300100新增会员C300200删除注销会员C300300查看现有会员C300310查看会员信息C300320查看会员购物信息C400000界面实现C500000整合T000000测试对项目进行测试T100000功能模块测试T200000系统集成测试T300000环境测设V000000部署发布并交付5.项目估算5.1直接成本由于涉及到的小组成员没有实际开发的经验，在薪酬结算方面没有可供参照的标准,因此在这里采用统一的￥100。00人天。任务名称工时成本估算网上购物系统10人天￥15100。00需求讨论2＊2人天￥400。00软件规划6＊2人天￥1200.00需求开发6＊4人天￥2400.00设计4＊4人天￥1600。00实施6*13人天￥7800。00测试3＊5人天￥1500.00部署2＊1人天￥200。005。2间接成本任务名称工时成本估算设备损耗31工作日￥800。00其他费用31工作日￥200.00总计￥1000。005。3网上购物系统总成本任务名称工时成本估算网上购物系统总成本31工作日￥16100。00进度计划项目进度管理控制是对项目在实施阶段的作业程序和作业时间进行规划、实施、检查、调查等一系列活动的总称，即在项目实施过程中,按照已经核准的进度计划,采用科学的方法定期追踪和检验项目的实际进度情况，并参照项目先期进度计划,找出两者之间的偏差，并对产生偏差的各种因素及影响工期的程度进行分析与评估；而后组织、指导、协调和监督监理单位及相关单位三方，帮助其及时采取有效措施调整项目进度,使工期在计划执行中不断循环往复，直至该项目按合同约定的工期如期完工，或在保证项目质量和不增加原先预算的条件下,使该项目提前完工并交付使用。项目进度计划：任务代码工期开始时间结束时间资源个人微薄系统31工作日2016-6—152016—7—15R0000002工作日2016-6-152016-6—162人P0000002工作日2016-6—172016-6-18全体开发人员P1000001工作日2016—6—172016—6-172人P2000001工作日2016—6—182016—6—18全体开发人员M0000004工作日2016—6—192016-6—22全体开发人员M1000001工作日2016-6-192016-6-191人M2000001工作日2016-6—192016-6-192人M3000001工作日2016-6—202016-6-201人M4000001工作日2016-6-212016—6—211人M5000001工作日2016—6—222016—6—22全体开发人员D0000004工作日2016-6-232016-6—26全体开发人员D1000002工作日2016—6—232016—6-24全体开发人员D2000001工作日2016—6—252016—6—25全体开发人员D3000001工作日2016-6-262016—6-26全体开发人员C00000013工作日2016—6-272016-7—9全体开发人员C1000006工作日2016—6—272016-7—2全体开发人员C1001004工作日2016-6-272016—6—30全体开发人员C1002002工作日2016-7-12016—7—2全体开发人员C1003004工作日2016—6—272016-6-30全体开发人员C1004002工作日2016—7—12016—7—2全体开发人员C20000011工作日2016—6-272016-7—7全体开发人员C2001005工作日2016-7-12016—7—5全体开发人员C2002005工作日2016-7-12016—7-5全体开发人员C2003003工作日2016—7—62016—7-8全体开发人员C3000008工作日2016-7—12016—7-8全体开发人员C3001005工作日2016—7—12016—7-5全体开发人员C3002005工作日2016—7-12016-7-5全体开发人员C3003003工作日2016—7—62016-7—8全体开发人员C3003103工作日2016-7-62016—7—8全体开发人员C3003203工作日2016-7—62016—7—8全体开发人员C40000012工作日2016-6-272016-7-8全体开发人员C5000001工作日2016-7-92016—7-9全体开发人员T0000005工作日2016-7—102016-7—14全体开发人员T1000003工作日2016-7-102016-7-12全体开发人员T2000001工作日2016-7—132016-7-13全体开发人员T3000001工作日2016—7-142016—7-14全体开发人员V0000001工作日2016-7-152016—7—15全体开发人员7.质量计划7。1组织机构在项目实施期间成立项目质量保证组织，该组织由质量保证人员和项目负责人组成，项目负责人负责质量监督工作及项目进展过程中各环节的质量把关，开发负责人负责质量控制的工作，质量保证人员负责质量保证的工作。7.2职责7。2。1项目负责人的职责

1.评审质量计划。

2。与质量保证人员一起协商不符合项问题的纠正措施，并安排资源实施纠正措施。

3.定期或事件驱动地评审质量保证活动和结果。7。2。1质量保证人员的职责

1.负责项目实施过程中对项目实施情况进行监督，包括对项目实施过程和工作产品进行监督检查.

2.实施项目组成员的质量保证培训。

3。制定质量保证计划。4．按计划实施审计活动,依照质量保证计划执行评审/审计，并记录执行中发现的不符合项。

5.对不符合问题提交不符合项报告，跟踪并验证纠正措施的执行情况。

6。对项目内不能解决的不符合项问超；向高层管理提交报告。

7。向项目经理报告项目质量工作状况和质量度量结果，定期向项目组报告质量活动的结果.

8.制定质量保证的过程改进计划,记录过程数据.7。3质量目标1。基于需求的测试覆盖率为100％。2。功能测试完善

3.每个阶段评审中发现的问题都已经解决或得到适当处理。

4.产品发布时不存在严重问题以及以上的缺陷。

5.严格满足合同的要求和规格

6。用户领导满意

质量计划标准项目具体描述计划实际缺陷排除率（缺陷数/页）需求检查4

系统总体设计检查2

缺陷排除率（缺陷数/KLOC)详细设计复核30

详细设计检查10

代码复核65

代码检查20

编译20

单元测试15

系统集成5

系统测试5

7。4质量策略1。

控制产品的质量，及时纠正缺陷

2应该特别注意项目工作产品质量的早期评审工作，元论是质量保证还是质量控制，采取的策略都是早期预防和早期排除缺陷。3将质量贯彻到日常的项目进展过程中；7。5软件质量保证活动质量保证的主要活动包括过程评审和产品审计。过程评审和产品审计的目的是为了确保在项目进展过程的各个阶段和各个方面采取各项措施来保证和提高提交给用户的产品质量。7.5.1审计时间标准审计软件项目计划审计软件项目计划计划结束合同要求需求规划文档需求制定需求规格说明总体设计文档总体设计制定软件项目计划详细设计文档详细设计制定软件项目计划编码规范详细设计制定软件项目计划产品代码编码结束编码规范测试文档详细设计制定企业质量要求用户手册产品提交之前项目计划和需求风险计划风险是指在项目进行过程中可能发生的事件，这些事件将会对项目按预期时间，资源和预算完成产生重大影响。风险管理的目标是在潜在问题发作以前就标志它们，这样就可以在生命周期中可以适时地计划和启用风险处理活动。8。1风险种类8。1.1资金风险资金是否到位.是否有预算限制使得系统必须以固定的成本交付,否则将被取消.成本估算是否准确。8。1。2人员风险是否可以获得足够的项目工作人员.他们是否具备合适的技能和经验。开发人员和管理层之间关系不佳，导致决策缓慢，影响全局;③缺乏激励措施，士气低下，降低了生产能力。没有找到项目急需的具有特定技能的人.8.1。3时间风险时间表制定得是否现实。对交付日期的要求有多严格。3.是否有时间“把工作做好”。8.1.4技术风险技术是否已经过证明。重复使用目标是否合理。工件必须要使用一次后才能被重复使用。构件可能要在若干次发布后才能变得稳定，以致无需重大变更即可复用。需求中的事务量是否合理.事务比率的估计值是否可靠？这些估计是否过于乐观。数据量是否合理？当前可用的框架是否能够保存这些数据，或者，如果需求使您相信工作站或部门系统将成为设计的一部分，那么是否能够在这些地方合理地保存数据。是否有特殊或苛刻的技术需求。成功是否依赖于新的或未经试验的产品、服务或技术?是否依赖于新的或未被证明的硬件、软件或技术。对于与其他系统（包括企业以外的系统）的接口是否存在外部依赖性?是否存在必需的接口或必须创建它们。是否存在极不灵活的可用性和安全性需求（例如“系统必须永远不出现故障")。系统的用户是否对正在开发的系统类型没有经验。应用程序的大小或复杂性，或者技术的新颖性是否导致了风险的增加.是否存在对国家语言支持的需求.是否可能设计、实施和运行该系统？某些系统只由于太大或太复杂而无法正常工作。8.1。5进度风险功能是否无限追加。计划是否过于乐观。是否缺乏计划。在压力下是否放弃计划。是否追赶计划。8.2风险控制1。实施和跟踪风险管理计划，保证风险计划的执行，评估削减风险的有效性。

2.针对一个预测的风险事实上是否发生了，确保针对某个风险而制定的风险消除步骤正在合理使用。3。监视剩余的风险和识别新的风险.4.收集可用于将来的风险分析信息.8.2。1风险的化解避免风险（即：不要做冒险的活动）将风险从系统的一部分转移到另一部分（可能对于系统的其他部分此风险不会发生或发生时影响不大）购买关于风险的信息（例如：做实验性项目，请咨询专家等）消除风险的根源接受风险（如果风险后果较小，而处理它可能代价很大，滚动处理可能是最有效的途径)发布风险(将风险发布给相关涉众，如：管理者、市场人员、客户{特别注意策略}）8。3风险监控周例会检查风险在周工作例会上，项目经理需要跟踪项目的风险。根据风险列表，逐一分析前10大风险,确认已经风险状态是否“发生”或“关闭”；如果风险发生则启动“风险应急计划"或项目组协商解决办法,必要时PM请求相关高级管理者解决已发生的风险，并且PM负责在风险管理计划中将此条风险标示为“发生"。如果风险已经消除，则PM负责在风险管理计划中将此条风险标示为“关闭”。统计每项风险的停留时间（周数)。9。团队管理团队是一定数量的个体成员组织的集合,包括自己组织的人、供应商、分包商、客户等为一个共同的目标工作，协调一致，愉快合作,最终开发出来高质量的产品。产品负责人在进行团队管理时要以团队成员为本，从团队成员的角度去思考问题，这样可以很快增强团队凝聚力和团队的效率。其具体意义可以表现在以下几个方面：①是保证按时、按质交付项目的前提;②有利于开发出高质量的软件；③有利于充分发挥每位成员的特长和创造性；④有利于提高团队成员的积极性、主动性;⑤