图书管理系统 软件项目管理大作业.docx
《图书管理系统 软件项目管理大作业.docx》由会员分享，可在线阅读，更多相关《图书管理系统 软件项目管理大作业.docx（27页珍藏版）》请在冰豆网上搜索。
图书管理系统软件项目管理大作业
图书管理系统项目管理
2016年6月22日
1．合同管理------------------------------------------------------------------2
2．生存期--------------------------------------------------------------------4
3．需求管理
3.1软件需求管理过程---------------------------------------------------5
3.1需求概述---------------------------------------------------5
3.2目标--------------------------------------------------------5
3.4功能需求--------------------------------------------------5
3.8编写用例文档----------------------------------------------7
4．任务分解---------------------------------------------------11
4.1任务清单-----------------------------------------------------------11
4.2WBS---------------------------------------------------------------14
5．规模估算---------------------------------------------------11
6．项目计划----------------------------------------------------15
7．质量计划----------------------------------------------------16
7.1项目经理的职责---------------------------------------------------16
7.2软件项目质量保证活动----------------------------------------------17
7.3测试计划-------------------------------------------------------------19
7.4质量改善------------------------------------------------------------20
8．团队管理---------------------------------------------------21
8.1项目组织结构------------------------------------------------------22
8.2团队沟通管理------------------------------------------------------23
1合同
合同书
项目名称：
图书管理系统项目管理
委托单位（甲方）：
Bit金融商务大学
承担单位（乙方）：
中国软件有限责任公司
研究起止日期：
2016年3月至2016年6月
中国软件有限责任公司
2016年3月21日填
项目名称：
图书管理系统项目管理
甲方（合同专用章）乙方（合同专用章）
合同签订日期：
2016年3月21日
依据《中华人民共和国合同法》的规定，甲乙双方经友好协商，签定以下合同。
双方申明，双方都已理解并认可了本合同的所有内容，同意承担各自应承担的权利和义务，忠实地履行本合同。
第一条本合同软件开发项目的价格、工作进度与安排。
（一）软件设计与制作的项目价格项目价格（元）简要说明
策划创意费5000元为图书馆建立网站树立企业形象，展现互联网独特的优势与特点。
并可以根据企业的市场和经营管理策略特别策划并提供整套的EC解决方案。
首页设计与制作1500元访问者登陆图书馆网站的首先索引页，以图书馆识别系统为设计基准，兼顾易用性与导引性原则，体现图书馆整体形象特征。
图书馆功能的设计与制作费8000元根据乙方的要求设计图书馆功能。
以符合网站整体风格及体现内容特色为设计基准，兼顾功能性与内容导航特征。
内部制作800元根据网站整体设计风格，依据不同频道/栏目模板进行个性化设计与制作。
英语版500按照网站整体设计模板进行不同语种转换。
小计15800元
（二）该项目的进度安排
预计于3月22日开始设计，首页设计与制作，图书馆功能设计与制作将于4月20日完成。
内部制作以及英语版于5月2号完成。
到六月1号完成整个软件的调试工作。
第二条合同履行期限按照附件规定的工作进度决定，经双方协商一致，可以延长该期限。
第三条甲方应向乙方提供必要的资料和方便条件，协助配合乙方进行软件的开发、调试、安装及实施。
第四条双方的基本权利和基本义务甲方的权利和义务根据本合同项目的实际需要和乙方的要求提供协助，并提供有关的资料，报表及文档等，甲方保证所提供的所有资料完整、真实、合法。
按本合同约定支付软件开发费用。
甲方有权在软件验收之日起一年内，要求乙方对验收完毕的软件模块出现的非人为因素造成的错误及故障，进行免费维护。
乙方的权利和义务：
按照甲方提供的材料按时完成本合同规定的软件开发工作。
可以根据甲方的要求帮助甲方举办培训和技术咨询，具体的操作方式及费用双方另行签署协议确认。
依合同收取软件开发费用。
乙方有义务在软件验收之日起一年内，对验收完毕的软件模块出现的非人为因素造成的错误及故障，进行免费维护。
第五条甲方在一年的免费维护期之后，需要乙方对软件模块进行维护时，乙方可根据情况酌情优惠收取模块维护费用。
第六条甲方同意按双方约定的付款方式和时间及时向乙方支付合同费用，以及提供其他必要的帮助。
第七条本合同涉及的相关程序、文件源码的版权属乙方所有，但乙方授予甲方使用权。
未经乙方许可，甲方不得公布文件源码，不得复制、传播、出售或者许可他人使用乙方作品及其程序等。
乙方可以在业务范围内使用这些作品。
第八条甲方不能按时支付合同费用，导致的工期延误，其责任由甲方承担。
第九条双方当事人应当保守在履行本合同过程中获知的对方商业秘密。
第十条双方应本着诚实信用的原则履行本合同。
任何一方在履行中采用欺诈、胁迫或者暴力的手段，另一方可以解除本合同并有权要求对方赔偿损失。
任何一方在履行中发现或者有证据表明对方已经、正在或将要违约，可以终止履行本合同，但应及时通知对方。
若对方继续不履行、履行不当或者违反本合同，该方可以解除本合同并要求对方赔偿损失。
第十一条本合同签订后，经双方当事人协商一致，可以对本合同有关条款进行变更或者补充但应当以书面形式确认。
上述文件一经签署，即具有法律效力并成为本合同的有效组成部分。
第十二条本合同附件为本合同不可分割的一部分，与合同正文具有同等法律效力。
第十三条任意一方欲提前解除本合同，应提前通知对方。
甲方提前解除合同的，无权要求乙方返还预付费用并应对乙方遭受的损失承担赔偿责任；乙方无故解除合同的，应双倍返还上述费用。
本合同其他条款对合同的解除另有约定的，从其约定。
第十四条任何一方违反本合同，给对方造成损失的，还应赔偿损失。
第十五条订立本合同所依据的客观情况发生重大变化，致使本合同无法履行的，经双方协商同意，可以变更本合同相关内容或者终止合同的履行。
第十六条双方当事人对本合同的订立、解释、履行、效力等发生争议的，应友好协商解决；协商不成的，双方同意向仲裁委员会提交仲裁并接受其仲裁规则。
动漫软件
第十七条本合同经由双方授权代表签字，自签订之日起生效。
第十八条本合同一式两份，双方当事人各执一份，具有同等法律效力。
甲方（盖章）：
___√______乙方（盖章）：
___√______
法人代表（签字）：
_Jim________法人代表（签字）：
_Jack________
___2016___年__3__月__22__日____2016_____年__3__月__22__日
2生存周期模型
当有一个稳定产品定义和很容易被理解的技术解决方案时，纯瀑布模型特别合适。
当你对一个定义很的版本进行维护或将一个产品移植到一个新的平台上，瀑布模型也特别合适。
对于那些容易理解单很复杂的项目，采用纯瀑布模型比较合适，因为可以用顺序方法处理问题，质量需求高于成本需求和进度需求的时候，它尤为出色。
当开发队伍的技术力量比较弱或者缺乏经验时，瀑布模型更为合适。
所以本图书管理系统采用瀑布模型。
维护
3需求规格说明书
3.1需求概述
3.2目标
“图书管理系统”主要提供图书信息和读者基本信息的维护以及借阅等功能。
该系统针对的用户是单个中小型图书室，藏书的种类和数量较少，系统需要操作方便，方便管理员对整个系统管理和学生借阅书的方便。
3.3用户类和特征
最终的用户是图书管理员和读者，图书管理员需要进行用户的创建、修改和删除等工作，要求具备计算机知识，如权限管理等。
读者是普通用户，具备一定的计算机操作知识即可。
3.3运行环境
操作系统：
Windows2000Server或WindowsNT。
数据库管理系统：
SQLServer。
开发工具：
Eclipse。
软件平台：
Tomcat。
客户端软件选择的具体说明：
web浏览器。
3.4功能需求
本系统相应的需求有：
（1）能够存储一定数量的图书信息,并方便有效的进行相应的书籍数据操作和管理，这主要包括：
图书信息的录入、删除及修改。
图书信息的多关键字检索查询。
图书的出借、返还和资料统计。
（2）能够对一定数量的读者进行相应的信息存储与管理，这其中包括：
读者信息的登记、删除及修改。
读者资料的统计与查询。
能够提供一定的安全机制，提供数据信息授权访问。
管理员
学生
修改读者信息
修改图书信息
办理借阅
查询图书信息
查询图书信息
关系数据库
3.5需求补充说明：
（1）数据保存：
需要长期保存在数据库的数据有：
图书信息：
图书的基本信息；
读者信息：
读者的基本信息；
借阅信息：
图书的借阅信息；
帐号信息：
图书管理员和读者的登录帐号；
（2）系统用户：
图书管理员、读者。
图书管理员：
对图书和读者数据可执行添加、修改、删除以及查询等操作。
读者：
可查询图书以及查询与本人相关的借阅信息。
3.6确定执行者
执行者是与系统交互的外部实体，它既可以是人员也可以是外部系统或硬件设备。
确定执行者可以通过提出以下问题得到：
–谁使用系统的主要功能？
–谁需要系统的支持以完成日常工作任务？
–谁从系统获取信息？
–谁负责维护和管理系统以保证其正常运行？
–系统需要应付（处理）哪些外部硬件设备？
–系统需要和哪些外部系统交互？
在本例中，可以确定“图书管理员”和“读者”为系统的执行者。
“图书管理员”负责使用系统的主要功能，“读者”从系统中获取所需的信息。
3.7确定用例
用例描述了一个完整的系统事件流程，其重点在于执行者与系统之间的交互而不是内在的系统活动，并对执行者产生有价值的可观测结果。
确定用例可以通过提出以下问题得到：
–参与者需要从系统中获得什么功能？
参与者需要做什么？
–参与者读取、产生、删除、修改或存储系统的某些信息吗？
–系统中发生事件需要通知参与者吗？
参与者需要通知系统某件事情吗？
–系统的输入/输出信息是什么？
这些信息从哪儿来到哪儿去？
–采用什么实现方法满足某些特殊要求？
本例中我们通过一定的调研和分析得到的“图书管理系统”的用例图，如图3.1所示。
图3.1用例图
3.8编写用例文档
用例图不能提供用例所具有的全部信息，因此需要使用文字描述那些不能放映在图形上的信息。
用例文档是关于执行者与系统如何交互的规格说明，要求清晰明确，没有二义性。
在描述用例时，应该只注重外部能力，不涉及内部细节。
下面给出本例中的用例文档。
（1）.图书信息的维护用例
用例名：
图书信息的维护
参与执行者：
图书管理员
入口条件：
图书管理员已经登陆到该系统中。
事件流：
当有新书入库时，图书管理员在录入页面输入书的信息，点击提交按钮，系统将书的信息保存到数据库中；当某一本图书的信息需要修改时，图书管理员通过输入查询条件，搜索出该书时，点击修改按钮，系统在可编辑状态显示图书的当前信息，图书管理员修改具体信息，点击保存按钮，系统将更新数据库中该书的信息；当需要删除一个或多个图书时，图书管理员查找到需要删除的图书记录，点击删除按钮，系统提示“确实要删除？
”对话框，当管理员选择“是”，系统将删除数据库中相应图书的信息，反之，则不进行任何操作。
出口条件：
系统将数据库中的信息进行相应的操作：
添加图书信息时，将新的图书信息保存在数据库中；修改图书信息时，将数据库中该图书的信息做相应的更新操作；删除图书信息时，则删除数据库中的相应图书记录。
异常事件：
在图书进行修改和删除时，先查出需要进行处理的图书记录，如果数据库中不错在符合条件的记录，查询无结果时，则无法进行修改和删除操作。
（2）.读者信息的维护用例
用例名：
读者信息的维护
参与执行者：
图书管理员
入口条件：
图书管理员已经登陆到该系统中。
事件流：
当有新的读者时，图书管理员在录入页面输入读者的信息，点击提交按钮，系统将读者的信息保存到数据库中；当某一本读者的信息需要修改时，读者管理员通过输入查询条件，搜索出该读者信息时，点击修改按钮，系统在可编辑状态显示读者的当前信息，读者管理员修改具体信息，点击保存按钮，系统将更新数据库中该读者的信息；当需要删除一个或多个读者时，图书管理员查找到需要删除的读者记录，点击删除按钮，系统提示“确实要删除？
”对话框，当管理员选择“是”，系统将删除数据库中该图书的信息，反之，则不进行任何操作。
出口条件：
系统将数据库中的读者信息进行相应的操作：
添加读者信息时，将新的读者信息保存在数据库中；修改读者信息时，将数据库中该读者的信息做相应的更新操作；删除读者信息时，则删除数据库中的相应读者记录。
异常事件：
在进行修改和删除读者信息时，先查出需要进行处理的读者记录，如果数据库中不错在符合条件的记录，查询无结果时，则无法进行修改和删除操作。
（3）.图书信息的查询用例
用例名：
图书信息的查询
参与执行者：
图书管理员、读者
入口条件：
无
事件流：
通过交互界面输入查询条件（如书名，作者名等）搜索图书记录。
出口条件：
若有符合条件的课程信息，则系统显示这些图书信息。
否则系统提示用户重新输入查询条件。
（4）.读者信息的查询用例
用例名：
读者信息的查询
参与执行者：
图书管理员
入口条件：
用户已经登陆到该系统中。
事件流：
通过查询界面输入查询条件（如读者证，读者姓名等）搜索待读者记录。
出口条件：
若有符合条件的读者信息，则系统显示读者信息。
否则系统提示用户重新输入查询条件。
（5）.查询个人基本信息用例
用例名：
查询个人基本信息
参与执行者：
读者
入口条件：
用户已经登陆到该系统中。
事件流：
点击查询个人基本信息按钮。
出口条件：
系统显示读者本人信息。
（6）.查询个人借阅信息用例
用例名：
查询个人借阅信息
参与执行者：
读者
入口条件：
用户已经登陆到该系统中。
事件流：
点击查询个人借阅信息按钮。
出口条件：
系统显示读者的借阅信息。
（7）.借书用例
用例名：
借书
参与执行者：
图书管理员、读者
入口条件：
图书管理员已经登陆到该系统中。
事件流：
图书管理员在借书页面，输入图书编号和读者证号，点击保存。
出口条件：
系统将这条借书记录保存到数据库中。
异常事件：
如果该图书未入库，数据库中不存在该图书编号，提示“该书未入库”；如果数据库中不存在该读者证号，也相应的做出提示。
（8）.还书用例
用例名：
还书
参与执行者：
图书管理员、读者
入口条件：
图书管理员已经登陆到该系统中。
事件流：
图书管理员在还书页面，输入图书编号，点击还书。
出口条件：
系统将删除数据库中这条借书记录。
异常事件：
如果数据库中不存在这本书的借阅记录，提示“非本馆借出的图书”,如果该书已过期，也相应的做出提示。
9.口令管理用例
用例名：
口令管理
参与执行者：
图书管理员、读者
入口条件：
用户已经登陆到该系统中。
事件流：
用户点击“修改密码”按钮，在口令修改页面输入新的密码，点击保存按钮。
出口条件：
数据库中的密码被修改成最新的密码。
3.9.非功能需求
3.9.1性能需求
图书管理系统的使用者是图书管理员和在校学生。
对于图书管理员的管理工作，性能要求不是很严格，但需要方便图书入库等操作。
对于学生的图书借阅、查询等功能，对性能要求较高，一般需要达到并发数200以上。
3.9.2安全性需求
由于图书管理系统的图书量会非常大，所有在对这些图书导入和查询时要保证速度。
在图书借阅过程中又要保证事务的完整性。
对于整个系统，需要完整的权限控制，防止某些人恶意的攻击系统，修改原始记录。
同时对于数据库中的数据需要定时备份，防止系统数据丢失。
此外，系统要求用户在登陆时需要身份验证。
3.10.故障处理
在正常情况下，应不出错。
一旦发生意外，比如掉电、网络不通等，应保证系统数据不会丢失。
4项目任务分解
4.1任务清单
4.1.1功能分解清单
1．图书管理系统
1.1图书借出管理
1.1.1图书的借出
1.1.2处理图书信息，包括书名、作者和出版社等
1.1.3图书借出信息记录，借出时间，借书者的信息。
1.1.4界面
1.1.5单元测试
1.2图书归还管理
1.2.1图书的归还。
1.2.2图书信息：
书名，作者，出版社等
1.2.3图书归还信息记录，归还时间，读者信息
1.2.4界面
1.2.5单元测试
1.3读者信息管理
1.3.1读者信息的编辑功能
1.3.2读者信息的添加删除功能
1.3.3界面
1.3.4单元测试
1.4管理员登陆
1.4.1管理员信息编辑
1.4.2界面
1.4.3单元测试
1.5前台欢迎及读者登陆界面
1.5.1界面
4.2WBS
政府公文审批及工作通告应用程序
·项目规划
1.合同签署
1.1需求分析报告&项目初步规划
1.2项目建议书
1.3合同草案
2.计划编制
2.1时间表
3.确认计划
·需求分析
1.需求开发
1.1需求探索
2.需求管理
2.1需求规格说明书
3.系统测试计划编制
·总体设计
1.策略确定
2.开发标准确定（具体分配方式见任务清单）
3.架构设计（具体分配方式见任务清单）
4.集成测试计划编制
·详细设计
1.接口设计（具体分配方式见任务清单）
2.模块设计（具体分配方式见任务清单）
3.单元测试计划编制
·实现
1.编码（具体分配方式见任务清单）
2.代码复核
3.单元测试
·测试
1.集成测试
2.系统测试
3.测试总额
4.缺陷跟踪
5.手册编写
5．项目估算
项目规模估算使用Delphi法进行估算，具体步骤如下：
协调人向小组成员提供项目规格和估计表格；
协调人召集小组讨论与规模相关的因素；
小组成员匿名填写迭代表格；
协调人整理出一个估计总结，以迭代表的形式返回各成员；
协调人召集小组会，讨论较大的估计差异；
成员复查估计总结并在迭代表上提交另一个匿名估计；
重复4-6，直到达到一个最低和最高估计的一致。
附Delphi法规模估计迭代表。
Delphi法规模估计迭代表
项目名称：
估计日期：
估计者：
估计轮次：
结果：
代码行（LOC）
周期（月）
工作量（人月）
费用（元）
理由：
项目规模估算
经过小组内部讨论得出项目规模估算如下：
项目名称：
《个人微薄系统》
规模预测：
代码行：
17,000LOC
周期：
3月
工作量：
6人月
费用：
￥7600元
项目进度估算
任务
完成时间
负责人
资源
备注
需求讨论
2016.4.5
于冬
2开发人员参与
项目规划
2016.4.18
Jim
全体人员参与
需求确定
2016.4.22
Jack
全体人员参与
设计
2016.5.28
Lucy
3开发人员参与
项目实施
2016.6.9
Black
全体人员参与
有待细化
测试
2016.6.14
James
3开发人员参与
部署
2016.6.15
Green
2开发人员参与
交付
2016.6.20
Tom
项目执行期间可根据实际完成情况申请延期。
附延期申请表。
项目名称：
项目代号：
项目所处阶段：
第阶段（）
申请时间：
年月日
原计划时间：
年月日
申请延期至：
年月日
申请延期的理由（逐条列出）：
申请人签字：
项目经理意见
不同意延迟，理由：
同意延迟至：
年月日
签字：
项目成本估算
声明
由于涉及到的小组成员没有实际开发的经验，在薪酬结算方面没有可供参照的标准，因此在这里采用统一的￥30.00人天。
成本估算
任务名称
工时
成本估算
个人微薄系统
152人天
￥7600.00
设备损耗
31工作日
￥1000.00
需求讨论
2*2人天
￥120.00
软件规划
6*2人天
￥360.00
需求开发
6*4人天
￥720.00
设计
4*4人天
￥480.00
实施
6*13人天
￥2340.00
测试
3*5人天
￥450.00
部署
2*1人天
￥60.00
6项目计划
描述
任务
前导任务
时间/月
项目规划
A
无
0.3
需求分析
B
无
0.2
总体设计
C
A，B
0.3
详细设计
D
A，B
0.5
编码
E
C，D
1
测试
F
E
0.2
7软件项目的质量计划
7.1项目经理的职责
1.评审质量计划。
2.与质量保证人员一起协商不符合项问题的纠正措施，并安排资源实施纠正措施。
3.定期或事件驱动地评审质量保证活动和结果。
7.1.2质量保证人员的职责
1.负责项目实施过程中对项目实施情况进行监督，包括对项目实施过程和工作产品进行监督检查。
2.实施项目组成员的质量保证培训。
3.制定质量保证计划。
4．按计划实施审计活动，依照质量保证计划执行评审/审计，并记录执行中发现的不符合项。
5.对不符合问题提交不符合项报告，跟踪并验证纠正措施的执行情况。
6.对项目内不能解决的不符合项问超；向高层管理提交报告。
7.向项目经理报告项目质量工作状况和质量度量结果。
8.定期向项目组报告质量活动的
升级会员 