景区自助售票系统软件项目管理计划Word格式.docx
《景区自助售票系统软件项目管理计划Word格式.docx》由会员分享，可在线阅读，更多相关《景区自助售票系统软件项目管理计划Word格式.docx（18页珍藏版）》请在冰豆网上搜索。
随着我国城市旅游业的快速发展，人们生活水平的提高，对旅游行业形象管理方面要求不断提高。
传统的人工模式已显得陈旧和落后，旅游景区的售检票系统已经不再是以前那种人工的，复杂的，工作量大的售票检票系统，而是一种电子化的新型系统。
建立旅游景区售检票系统，不仅使景区的管理水平有了提高，同时也相应地完善了旅游景区的管理制度。
这种系统极大的方便的管理员的管理和查询等操作。
为管理者提供决策支持数据，以便及时地发现问题，合理安排日常业务工作，制定新的资金投入和计划。
这种电子化工作模式避免了人工操作造成的失误，提高了工作效率和质量，从而也提高了经济效益。
“伤得起”小组计划开发的“景区售票系统”，预计可以实现景区门票的查询，购买，投诉，咨询四项基本功能供消费者使用，以及管理员的日常维护功能。
初步开发成形的系统具备基本的使用功能，初步的界面设计，使用测试案例尚不完备，具有客户端和网页版两种以供选择。
1.1.2开发目的
缓解旅游景区的售检票的人力压力，提供高效的，快节的，稳定的操作。
实现系统应具有实用性、可靠性、有效性及方便性。
软件工程实践课开发系统可以提高成员的动手能力，深刻理解软件工程的美妙之处。
1.1.3工作进度
一般软件开发时间：
第一个短周期内要完成计划和分析工作（2%--3%，10%--15%）；
第二个短周期要完成设计工作（20%--25%）；
第三个短周期基本完成开发工作（15%--20%）；
剩余时间全部投入测试工作（30%--40%）。
依据软件工程课程要求模拟的时间进程为：
时间
项目
2011年春节学期
5周
6周
7周
8周
9周
10周
11周
12周
13周
14周
15周
项目规划与准备
项目分析
项目设计
项目实施
项目试运行
项目测试
项目验收
1.1.4主要工作活动
系统开发的主要工作活动包括开发前对系统开发环境，背景和开发目的的探究，初步拟定可以实现的功能和应该具备的属性。
系统重点开发阶段为代码编写与测试，应占据大部分时间。
系统每个阶段都要进行文档的编写以及不断的跟进、更写。
小组成员有专人负责文档的维护。
系统开发最后阶段设计测试数据进行测试。
进行除错以及美化界面，增强程序的健壮性。
1.1.5关键里程碑
主要里程碑：
1、需求规格书的确定
2、系统架构的完成
3、程序测试的完成
4、系统交付使用
1.2项目交付产品
最终交付源代码、系统文件、文档资料等可供定量检查的资料。
1.2.1产品所需满足的系统需求
1．产品界面友好，操作简单。
2.及时保存信息和相关操作记录。
3.保证一定的执行效率。
4.能够实现各处的售票系统信息联动，保证最新的售票信息。
1.3SPMP的演化
文档的构建和起草由朱文龙负责；
文档的更新由朱文龙和何明刚共同完成；
按进程和各项工作实际情况适时变更文档的更新机制。
1.4参考资料
[1]《软件工程：
实践者的研究方法（第6版）》.作者：
.2007年1月.
[2]《软件工程实用教程（计算机应用技术规划教材）》.作者：
吕云翔.2011年1月.
[3]《软件工程方法与实践》.作者：
窦万峰.2009年5月.
1.5术语与缩写
尚未商议。
2.项目组织
2.1过程模型
2.1.2采用瀑布式开发模型：
2.1.2选择瀑布式模型的原因
瀑布式模型是经典的软件开发模型，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。
将划分为制定计划、需求分析、软件设计、程序编写、和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
为项目提供了按阶段划分的检查点，可以根据里程碑似的时间节点对软件工程的进程进行跟踪和验收，完成了前一阶段内容，即可关注下一阶段的工作，便于集中精力，尽量减少反复开发修复，造成工作效率的降低。
在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。
当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。
2.1.3本项目的过程模型
重要的时间节点红色字体标出！
时间
2.1.4交付的产品和标志
最终的产品交付以可实际运行的软件系统和说明文件，在课程结束前一周结束产品开发。
结束标志为用户可以正常使用系统，并基本没有错误。
并定期按用户需求和实际情况进行更新。
2.2组织结构
2.3组织接口
表1项目接口
组织
联系人
联系信息
客户：
景区
@@@
###
分包商：
<
名称>
软件质量保证
软件配置管理
……
2.4项目职责
角色
职责描述
负责人员
项目经理
领导项目团队，执行和管理项目，负责项目的交付工作
开发人员
负责具体项目进程的实施，代码的编写，程序的测试等。
表2项目职责
秘书
协调各方进行沟通和监督各项进程
3.管理过程
3.1管理目标和优先级
基本原则：
由于团队人员较少，每位成员多项分工，既要具体到程序的编写
和调试，又要有整体协调的能力。
项目经理和执行秘书负责协调客
户需求和项目进程。
各成员互相监督，高效有序的完成系统开发。
目标A：
团队的最高目标是在预定时间内完成产品的基本功能开发，并能基本可以交付客户使用。
目标B：
要按时更新文档和最好记录便于后续的维护。
目标C：
能够保证一定的系统运行效率，保证安全性。
目标D：
工作分工明确，接口衔接顺畅，经常沟通确定进程和需要解决的问题。
目标E：
提高系统性能与功能，增加系统的寿命
3.2假设、依赖关系和限制
［说明：
描述所有对项目外部的问题和事件所做的假设，以及由这些问题和事件引起的限制。
］
编号
项目外部问题
限制
1
客户要求的交付时间过早
不能够完成所有的模块开发
2
服务器数据库与软件需求不符
要改变软件数据库设计，不能及时完成软件网络部署
3
硬件器材如检票器等到货较晚
推迟硬件接口的开发，前期只能完成软件模拟
4
客户提出新的需求
开发新的组件，推迟项目交付时间
5
客户违约
终止项目进程，或寻找新的客户
6
资金链断裂
员工积极性受挫，开发进度严重受影响甚至停止
3.3风险管理
表3项目风险
风险描述
风险类型
概率
影响程度
后果
缓解策略
开发人员技术水平难以满足预期要求
产品规模
40%
灾难的
开发进程停滞
在开发的过程中不断学习
２
系统的规模预算不准确
30%
严重的
交付时间推迟，开发人员为做好长期准备
适当的精简不必要的系统设计
３
交付日期推迟
商业影响
50%
发生违约风险
经常与客户沟通
４
用户改变起初的需求
60%
轻微的
重新设计某些部分
５
缺少对开发中所使用工具的培训
开发环境
20%
可忽略的
开始阶段进度缓慢
不断进行相关的培训
６
人员变动频繁
人员
交付时间推迟，效率下降
相近的最好文本的维护，便于新进人员了解
风险
详细描述
同学们实际开发经验少，技术水品有限，不能满足需要
没有实际的开发经验，对工作量估计不准
工作效率低，没有经验，人员变动等等因素均会导致
用户随着实际工作改变一部分需求是正常的
时间紧张，人员少，没有培训人员
由于课业压力、实习外出等，某些同学可能中途退出
3.4监督和控制机制
3.4.1报告机制：
A.小组各成员每天将工作进展整理成电子文档交给文档维护员进行文档维护。
B.定期举行例会，共同探讨项目进展中的问题，并做好会议记录。
C.项目经理和执行秘书密切关注项目的各期进展，确保按时交付使用。
并确保风险在可控范围内。
3.4.2报告格式：
报告主题，时间段，发现人，报告内容，审核意见
3.4.3评审机制：
提出问题，大家共同解决。
一致通过，并做记录。
项目经理制定下一阶段工作目标和执行进程，执行秘书严格监督。
3.5人员计划
人员类型
人数
技能要求
所需培训
培训方式
C++程序员
熟悉C++编程和微软.Net平台
C++编程
小组学习
数据库程序员
熟悉SQL语句，熟练使用SQLSever2005
SQL语句
界面程序员
熟悉CSS、Photoshop、.Net平台
CSS、Photoshop、.Net平台
自学
文档维护员
熟悉使用Word及Powerpoint
Word及Powerpoint
软件测试人员
熟练使用开发工具的debug工具，有耐性
debug工具
执行秘书
较强的沟通能力，能及时调解组内以及组与组之间的矛盾
无
4.技术过程
4.1方法、工具和技术
4.1.1编程语言：
C++
4.1.2所需技术：
SqlSever2005、Windows.Net
4.1.3执行标准：
采用业内通用的方式进行文件命名、代码版式、注释等。
：
由相关的程序员交付代码，测试人员进行测试，并集体讨论合格之后即可交付。
4.2软件文档
1、设计报告初稿
在总体设计阶段，小组根据需求规格说明文档，完成软件体系结构的设计，
由组编写软件体系结构设计文档初稿，并在后续开发阶段补充和更新。
该文档由文档维护员负责维护更新。
2、测试文档
在软件开发阶段，测试人员需要编写测试规格说明文档，并在后续测试阶
段更新。
开发人员将根据测试规格说明文档建立测试环境、准备测试数据。
３.个人项目总结
由组内成员各自独立完成，对开发过程中获得的工作经验进总结。
在提
交系统时一并提交。
４.其他文档
软件开发过程中的其他文档，如开发日志（按组员意见选择公开与否），
风险报告及其处理意见等，由秘书进行整理与汇聚。
作为以后软件开发以及
交流的经验。
4.3用户文档
在更新用需求分析阶段，测试人员需要开始着手编写用户文档，并在需求
析结束后需要形成初稿；
在后续阶段不断由文档维护员户文档；
并在系统交
付阶段随着系统一起被交付。
5.工作包、进度表和预算
5.1工作包
将项目分解为工作包（活动和任务），并对工作包详细描述］
任务
活动
1.项目准备
（项目管理计划）
1.1形成项目小组
有效的组织与管理各类资源（例如人），以使项目能够在预定的范围、质量、时间和成本等约束条件下顺利交付
1.2系统方案选定
1.3制定软件项目管理计划
1.4建立配置管理环境和开发环境
2.需求分析
（需求规格说明）
2.1建立用例模型，动态、静态模型
对需求进行分析，满足业务需求、用户需求、系统需求
2.2编写需求规格说明
2.3评审需求需求规格
2.4修改需求规格说明
2.5获得开战后续工作批准
2.6需求分析工作完成
3.总体设计
（软件设计）
3.1审阅需求规格说明
分析模型，对工程进行总体设计，实现界面初步设计
3.2完成界面设计文档
3.3评审界面设计文档
3.4修改设计文档
3.5获得开战后续工作批准
3.6初步设计工作完成
4.软件开发
4.1审阅总体设计文档
代码实现软件功能的开发
4.2确定模块化或分层参数
4.3分配任务给开发团体人员
4.4编写代码
4.5开发人员测试（调试）
4.6开发工作完成
5.集成与测试
5.1模块交易
测试产品
5.2建立集成系统
5.3测试系统
5.4修改代码，完善功能
5.5重新集成测试
5.6整体测试完成
6.交付
6.1准备安装程序
交付总结
6.2系统演示
6.3递交文档、代码和产品
6.4总结经验教训
6.5交付完成
5.2依赖关系
描述工作包之间的次序关系，目的是解决这些工具包之间的互相依赖关系和对外部事件的依赖性。
待定
5.3资源需求
[说明：
提供完成项目所需的全部资源，包括人员、支持软件、计算机硬件、办公室和实验室设备以及项目资源维护需求的数目和类型等。
人员：
伤得起!
!
小组软件项目开发成员
支持软件的开发环境：
MicrosoftVisualStudio2008
MicrosoftOfficeword2010
MicrosoftOfficevisio2010
VisualAssistX
UmlStar
MYSQL5.1
AdobeDreamweaverCS5
Apache2
AdobePhotoshopCS5
AdobeIllustraterCS5
AdobeReaderX
开发地点：
凉爽的宿舍或者有空调的机房
实验设备：
个人PC机、笔记本电脑、实验室PC机
项目资源维护需求的数目和类型：
3台个人电脑
5.4预算
估算项目的工作量和成本。
分别按问题分解（LOC或FP）和过程分解估算工作量和总成本，参见课件］
STEP1：
计算未调整功能点
功能点（FunctionPoint,FP），以功能点为单位来估计软件
规模，关注五个方面的功能：
–外部输入（EI）：
用户进行添加或修改数据的UI
–外部输出（EO）：
软件为用户产生的输出UI
–外部查询（EQ）：
软件可产生的独立查询
–内部逻辑文件（ILF）：
软件修改或保存的逻辑记录集合（数据表或文件）
–外部接口（EIF）：
与其它系统进行信息交换或共享的文件
P=（a+4m+b）/6
P估算值
a乐观值
b悲观值
m可能值
FP=r×
Pr加权因子
FP总成本
STEP2：
估计调整因子
技术因素
影响值
备份与恢复
内部处理复杂度
5
数据通信
2
设计可复用代码
4
分布式处理
0
设计中的转换与安装
3
关键性能
多次安装
现有操作环境
易于变更的应用设计
联机数据输入
多屏幕输入切换
主文件联机更新
信息域值复杂度
K=0.65+0.01*（F1+F2+……+F14）=1.17
STEP3：
计算调整功能点和总成本
FP1=320*1.17=375
平均生产率（v）：
6.5FP/pm
月平均工资：
3000元
每个FP的成本（u）：
1000元
总成本（C）：
C=FP*u=375*1230=375000元
总工作量（PM）：
PM=FP/v=375/6.5=58
5.5资源分配和进度表
用甘特图（MSProject）描述项目任务,依赖关系、人员、时间段等。
进度表（GanttChart）：
人员/资源分配图：
升级会员 