网上购物系统软件项目管理大作业Word格式文档下载.docx
《网上购物系统软件项目管理大作业Word格式文档下载.docx》由会员分享,可在线阅读,更多相关《网上购物系统软件项目管理大作业Word格式文档下载.docx(26页珍藏版)》请在冰豆网上搜索。
由于甲方拥有该软件的源代码所有权,因此甲方需要承担部分维修和进一步开发的责任。
当软件需要新的功能拓展或改版升级时,由双方共同协商决定。
1.3时间地点
6月10日上午9:
00在河北省沧州市黄骅市
1.4专利成果分配
该软件是由甲方向乙方定制,甲方拥有该软件的版权,乙方不能将该软件的任何版本卖个其他客户。
软件提交时,项目源代码的所有权自动移交到甲方,乙方不得擅自对源代码进行修改。
1.5验收标准
乙方在开发过程中必须遵守ISO
12207关于软件生命周期和文档的标准。
1.6报酬计算
软件总价为2万元。
合同签订后,甲方向乙方支付1万元定金。
项目的第二个月,乙方按计划时间表完成需求分析、系统分析、设计和完成系统的基本框架后,甲方向乙方支付0.5万元。
该系统完成后,甲方进行验收测试,在签字验收后完成后,甲方向乙方支付全款。
1.7违约处理
任何一方违反本协议导致本协议无法继续履行的,违约方需赔偿守约方违约金人民币2万元,该违约金不足以弥补守约方实际损失的,违约方应赔偿守约方所有实际损失。
甲方法人代表:
乙方法人代表:
盛某某
2.生存期
针对本项目的开发特点,参考企业的生存期模型说明和软件过程体系,决定采用增量式模型如下图,理由如下:
1.网上购物系统的全部功能分成管理员和用户功能两大类,因此可以先基于通用功能作出一个最小的使用版本,再逐步添加其余的功能。
这样一来,用户可以先试用最小版本的同时,提出更多明确的需求,这有助于下一阶段的开发,大大减小了开发的风险。
2.在网上购物系统需求规格中,要求系统有可扩充性。
若使用增量模型,可以保证系统的可扩充性。
用户明确了需求的大部分,但也存在不很详尽的地方。
如:
“关于管理员档案,比照所提供资料设计,现在也没有一个成形的东西”;
资源库系统只提到“应提供一个标准的资源库解决方案。
”这样只有等到一个可用的产品出来,通过客户使用,然后进行评估,评估结果作为下一个增量的开发计划,下一个增量发布一些新增的功能和特性。
直至产生最终完善的产品。
3.“系统要求有可扩充性,可以在现有系统的基础上,通过前台就可加挂其它功能模块”。
也说明用户可能会增加新的需求。
生存期中各个阶段如下:
阶段
项目规划阶段
目标
根据合同和初步的需求分析,确定项目的规模、时间计划和资源需求
输入
合同文本,SOW
过程
项目规划,计划确认
输出
项目计划
需求分析阶段
确定客户的需求
项目计划,SOW
需求获取,需求分析,需求控制
原型系统,需求规格
设计阶段
总体系统结构设计
总体设计
系统设计说明书,数据库结构定义
增量1实现
实现系统的通用功能
详细设计,编码,代码走查,代码评审,单元测试
详细设计说明书,源代码,可运行版本--1
增量2实现
实现系统的用户管理功能
详细设计说明书,源代码,可运行版本--2
增量3实现
实现系统的商品管理功能
详细设计说明书,源代码,可运行版本--3
增量4实现
实现系统的个人信息管理功能
详细设计说明书,源代码,可运行版本--4
集成测试
通过集成环境下的软件测试
测试计划,测试用例
集成测试,系统测试
系统软件包,测试报告,产品说明书
产品提交
产品可投入使用
系统软件包
验收报告
3.需求管理
.3.1功能需求
需求概述:
目标:
“网上购物系统”主要提供物品信息和对读者基本信息的维护以及购买等功能。
该系统针对的用户是网上购物者,物品的种类和数量较多,系统需要操作方便,方便管理员对整个系统管理和用户对于购买的方便。
用户类和特征:
最终的用户是管理员和用户,管理员需要进行会员管理,更新物品信息等工作,要求具备计算机知识,如权限管理等。
购买者是普通用户,具备一定的计算机操作知识即可。
本系统相应的需求有:
(1)能够存储大量的商品信息,并方便有效的进行相应的商品数据操作和管理,这主要包括:
✓商品信息的添加、删除及修改。
✓商品信息的多关键字检索查询。
✓商品的出货、退货和资料统计。
✓订单信息管理:
查看订单清单、更新订单付款、删除订单。
(2)能够对一定数量的用户进行相应的信息存储与管理,这其中包括:
✓用户信息的登记、删除及修改。
✓用户资料,用户订单信息的统计与查询。
✓能够提供一定的安全机制,提供数据信息授权访问。
需求补充说明:
(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.任务分解
项目任务分解编码表
编码
任务名称
备注
R000