图书管理系统软件项目管理大作业.doc

图书管理系统项目管理
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.2 WBS---------------------------------------------------------------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 运行环境
操作系统：Windows 2000 Server 或 Windows NT。
数据库管理系统：SQL Server。
开发工具：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.2 WBS

政府公文审批及工作通告应用程序
·项目规划
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,000 LOC
周期：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.定期向项目组报告质量活动的结果。
8.制定质量保证的过程改进计划，记录过程数据。

7.1.3质量目标
1）基于需求的测试覆盖率为100%。
2）功能测试完善
3）每个阶段评审中发现的问题都已经解决或得到适当处理。
4）产品发布时不存在严重问题以及以上的缺陷。
5）严格满足合同的要求和规格
6）用户领导满意
7.1.4质量策略
1. 控制产品的质量，及时纠正缺陷
2应该特别注意项目工作产品质量的早期评审工作，元论是质量保证还是质量控制，采取的策略都是早期预防和早期排除缺陷。
3将质量贯彻到日常的项目进展过程中；

7.2软件质量保证活动
7.2.1审计
审计(Audit) 是对过程或者产品的一次独立评估。将审核的主体与为该主体以前建立的一组规程和标准进行比较目的是确保真正的遵循了这一个过程，产生了合适的文档和精确反映实际项目的报告，可以预先规划的，也可以是临时决定的。现在讲本项目中的预先规划审计列出如下。在整个开发过程中，会根据需要插入临时决定的审计。
1. 审计软件项目计划 时间：计划结束 标准：合同要求
2. 需求规划文档 时间：需求制定 标准：需求规格说明
3. 总体设计文档 时间：总体设计制定 标准：软件项目计划
4. 详细设计文档 时间：详细设计制定 标准：软件项目计划
5. 编码规范 时间：详细设计制定 标准：软件项目计划
6. 产品代码 时间：编码结束 标准：编码规范
7. 测试文档 时间：详细设计制定 标准：企业质量要求
8. 用户手册 时间：产品提交之前 标准：项目计划和需求
将审计的结果编写审计报告及时提交。以下是制定的质量审计模版
软件质量保证审核报告

产品类别：

项目名称：

审核阶段：

审核范围：

审核标准：

审核员：

参加人员：

审核日期：

持续时间：

好的实践经验
序号
KPA
内容

发现的问题
序号
KPA
内容
严重程度

上报的不一致问题
序号
KPA
内容
状态

问题解决活动计划
状态
问题序号
解决方案
负责人
预计完成日期

注释：
1. 审核阶段：项目计划审核阶段、需求审核阶段、设计审核阶段、编码审核阶段、测试审核阶段、产品发布审核阶段
2. 审核范围：CMM KPA名称
3. 审核标准：所用的审核检查表
4. 严重程度：严重（指与项目计划中定义的过程不符合）
轻微（指活动遵循了过程，但有质量问题）

7.2.2 过程评审
项目严格按照组织定义的软件过程进行开发，过程评审的具体依据参照企业的过程规范，保证项目中的所有过程活动都在实施范围内。在每次评审之后，要对评审结果做出明确的决策并形成评审记录。评审可采取文件传阅、评审会等形式。
质量保证人员负责对项目过程迸行监督，将发现的问题和解决情况在每周的例会上通报，对没有解决的问题迸行讨论，对不能解决的问题提交高级管理者处理。
每个周末，进行一次配置管理审核，确认配置管理工作是否正常进行
7.2.3问题报告
质量保证人员对于每次审计活动发现的不符合项，应该和项目经理协商不符合项的纠正措施并预定完成日期，若和项目经理存在意见分歧，质量保证人员可以上报给高层管理者，由高层管理者决定最后的措施。同时，不符合项在项目周例会中汇报。
对不符含项，质量保证人员耍在预定完成日期内重新审计，验证不符合项的纠正情况，若超过预定完成日期1周仍然有没解决的不符合项，质量保证人员上报给高级管理者，由高级管理者决定最后的措施。
质量保证人员有独立的汇报途径，日常的汇报途径如下：
1.将发现的问题通知项目经理，协调纠正措施。
2.将项目组内不能协调的问题汇报给茼级管理者，由南级管理者协调解决。
3.将日常工作和过程数据汇报给质量经理，由其统一收集并进行统计。

7.3测试计划
下面是本项目的测试大概计划，详细内容请查阅测试文档。
1. 基本测试
单元测试
集成测试
系统测试
测试工作安排
测试准备工作
测试用例设计

2.系统测试设计
版本兼容性测试
性能测试
恢复测试
安全性测试
压力测试
7.4质量改善
为了达到更好的质量，现在制定质量改善要求：
1软件质量活动必须经过规划
2.软件质量活动规划必须明文规定
3.质量活动必须尽早开始
4.质量小组必须独立存在
5.应该经过训练
6.必须有适当的经费
8 团队管理
团队是一定数量的个体成员组织的集合，包括自己组织的人、供应商、分包商、客户等为一个共同的目标工作，协调一致，愉快合作，最终开发出来高质量的产品。团队管理在整个项目的开发中具有十分重要的作用。
8.1项目组织结构
经过分析我们采用项目型的组织结构。结构图如下

此结构的优点：

1. 项目经理对项目可以全权负责。可以根据项目需要随意调动项目组织的内部资源或者外部资源。
2. 项目型组织的目标单一，完全以项目为中心安排工作，决策的速度得以加快，能够对客户的要求做出及时响应，项目团队精神得以充分发挥。有利于项目的顺利完成。
3. 项目经理对项目成员有全部权利，项目成员只对项目经理负责，避免了职能型项目组织下项目成员处于多重领导、无所适从的局面，项目经理是项目的真正、唯一的领导者。
4. 组织结构简单，易于操作。项目成员直接属于同一个部门，彼此之间的沟通交流简介、快速，提高了沟通效率，同时也加快了决策速度。
此结构的缺点：

1． 每一个项目型组织，资源不能共享，即使某个项目的专用资源闲置，也无法应用于另外一个同时进行的类似项目，人员、设施、设备重复配置，会造成一定程度的资源浪费。
2． 公司里各个独立的项目型组织处于相对封闭的环境之中，公司的宏观政策、方针很难做到完全、真正的贯彻实施，可能会影响公司的长远发展。
3． 在项目完成以后，项目型组织中的项目成员或者被拍到另一个项目中去，或者被解雇，对项目成员来说，缺乏一种事业上的连续性和安全感。
4． 项目之间处于一种条块分割状态，项目之间缺乏信息交流，不同的项目组很难共享知识和经验，项目成员的工作会出现忙闲不均的现象。
针对本项目的分析：
这个项目相比较软件公司开发的项目具有一定的特殊性。这是一个校园项目
由于该项目具有很大的临时性，项目组的成员也是从不同的班级集中到一起。这样的特殊性使我们的这样的项目并不具有上面列出的2,3,4所示的缺点。因此项目型组织结构利于团队的建设以及小组人员与任务的分配；另外该组织结构简单易操作，而且目标单一，特别适用于这种零散的人员调度，同时很大程度上方便了成员间整体的沟通交流，加快了决策速度。由于这个项目各模块间的耦合度较低，不需要小组间大量的信息共享；而且项目组内有着统一的交流方式（临时的网上讨论组），各项决策规定可以第一时间直接反映给项目成员。针对这是一个政府项目，用户群体是不太了解计算机的政府官员，我们的界面应该做的可能的简单实用，领导还可能随时提出一些需要用特定的技术才能够解决的需求。这样的项目组成结构，可以使我们在团队内部有稳定成员的同时，可以根据实时的需求，招聘一些有特殊技能的学生，使我们的项目能够达到锦上添花的效果。与此同时我们的项目的特殊性并没有削弱项目型的组织结构的固有特点。故我们采用项目性组织结构来进行这个项目的开发。

8.2团队沟通
为了保证团队信息的沟通制定如下沟通计划
1. 每天午饭时间项目组成员进行口头交流。。
2.         每周五的15：00-17：00召开项目周例会，
3.        及时提交问题报告，问题可以通过网络提交，项目经理会及时获取问题信息。
4. 组内成员有任何问题可以在qq群内进行非正式的讨论。

23