景区自助售票系统软件项目管理计划.docx
《景区自助售票系统软件项目管理计划.docx》由会员分享，可在线阅读，更多相关《景区自助售票系统软件项目管理计划.docx（21页珍藏版）》请在冰豆网上搜索。
景区自助售票系统软件项目管理计划
景区自助售票系统软件项目管理计划
项目治理打算
Version1.0
[组名]伤得起！
！
！
[组长]李雷〔1080310601〕
[成员]朱文龙〔1080310608〕
何明刚〔1080310615〕
郭伟龙〔1080310621〕
本报告由小组四人共同完成
1、第一、二章由朱文龙完成
2、第三章由李雷完成
3、第四章由何明刚完成
4、第五章由郭伟龙完成
文档信息
项目名称：
[景区售票]软件系统
小组名称：
伤得起！
！
！
项目负责人：
李雷
文档负责人：
朱文龙
编制日期：
2020.04.21
版本：
Version1.0
文档分工〔姓名〕
负责内容
朱文龙
文档的要紧框架和起草、更新
何明刚
文档的更新
修改记录
日期
版本
修改说明
修改者
2020.04.21
1.0
文档的起草和构建
朱文龙
2020.6.18
1.1
3.13.25.3资源需求
李雷
2020．6.19
1.2
5.15.25.45.5
郭伟龙
2020.06.16
2.0
增加了第一章的要紧工作活动和里程碑章节；修改了第一章第一部分的部分说法。
朱文龙
名目
1.简介
1.1项目概述
1.1.1项目目标
随着我国都市旅行业的快速进展，人们生活水平的提高，对旅行行业形象治理方面要求不断提高。
传统的人工模式已显得陈旧和落后，旅行景区的售检票系统差不多不再是往常那种人工的，复杂的，工作量大的售票检票系统，而是一种电子化的新型系统。
建立旅行景区售检票系统，不仅使景区的治理水平有了提高，同时也相应地完善了旅行景区的治理制度。
这种系统极大的方便的治理员的治理和查询等操作。
为治理者提供决策支持数据，以便及时地发觉问题，合理安排日常业务工作，制定新的资金投入和打算。
这种电子化工作模式幸免了人工操作造成的失误，提高了工作效率和质量，从而也提高了经济效益。
〝伤得起〞小组打算开发的〝景区售票系统〞，估量能够实现景区门票的查询，购买，投诉，咨询四项差不多功能供消费者使用，以及治理员的日常爱护功能。
初步开发成形的系统具备差不多的使用功能，初步的界面设计，使用测试案例尚不完备，具有客户端和网页版两种以供选择。
1.1.2开发目的
缓解旅行景区的售检票的人力压力，提供高效的，快节的，稳固的操作。
实现系统应具有有用性、可靠性、有效性及方便性。
软件工程实践课开发系统能够提高成员的动手能力，深刻明白得软件工程的精妙之处。
1.1.3工作进度
一样软件开发时刻：
第一个短周期内要完成打算和分析工作〔2%--3%，10%--15%〕；
第二个短周期要完成设计工作〔20%--25%〕；
第三个短周期差不多完成开发工作〔15%--20%〕；
剩余时刻全部投入测试工作〔30%--40%〕。
依据软件工程课程要求模拟的时刻进程为：
时刻
项目
2020年春节学期
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版〕».〔美〕RogerS.Pressman.2007年1月.
[2]«软件工程有用教程（运算机应用技术规划教材）».吕云翔.2020年1月.
[3]«软件工程方法与实践».窦万峰.2020年5月.
1.5术语与缩写
尚未商量。
2.项目组织
2.1过程模型
2.1.2采纳瀑布式开发模型：
2.1.2选择瀑布式模型的缘故
瀑布式模型是经典的软件开发模型，将功能的实现与设计分开，便于分工协作，即采纳结构化的分析与设计方法将逻辑实现与物理实现分开。
将软件生命周期划分为制定打算、需求分析、软件设计、程序编写、软件测试和运行爱护等六个差不多活动，同时规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
为项目提供了按时期划分的检查点，能够依照里程碑似的时刻节点对软件工程的进程进行跟踪和验收，完成了前一时期内容，即可关注下一时期的工作，便于集中精力，尽量减少反复开发修复，造成工作效率的降低。
在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动同意上一项活动的工作结果，实施完成所需的工作内容。
当前活动的工作结果需要进行验证，假如验证通过，那么该结果作为下一项活动的输入，连续进行下一项活动，否那么返回修改。
2.1.3本项目的过程模型
重要的时刻节点红色字体标出！
时刻
项目
2020年春节学期
5周
6周
7周
8周
9周
10周
11周
12周
13周
14周
15周
项目规划与预备
项目分析
项目设计
项目实施
项目试运行
项目测试
项目验收
2.1.4交付的产品和标志
最终的产品交付以可实际运行的软件系统和说明文件，在课程终止前一周终止产品开发。
终止标志为用户能够正常使用系统，并差不多没有错误。
并定期按用户需求和实际情形进行更新。
2.2组织结构
2.3组织接口
表1项目接口
组织
联系人
联系信息
客户：
景区
@@@
###
分包商：
<名称>
@@@
###
软件质量保证
@@@
###
软件配置治理
@@@
###
……
@@@
###
2.4项目职责
角色
职责描述
负责人员
项目经理
领导项目团队，执行和治理项目，负责项目的交付工作
李雷〔1080310601〕
开发人员
负责具体项目进程的实施，代码的编写，程序的测试等。
朱文龙〔1080310608〕
李雷〔1080310601〕
郭伟龙〔1080310621〕
何明刚〔108310615〕
表2项目职责
秘书
和谐各方进行沟通和监督各项进程
朱文龙〔1080310608〕
3.治理过程
3.1治理目标和优先级
差不多原那么：
由于团队人员较少，每位成员多项分工，既要具体到程序的编写
和调试，又要有整体和谐的能力。
项目经理和执行秘书负责和谐客
户需求和项目进程。
各成员互相监督，高效有序的完成系统开发。
目标A：
团队的最高目标是在预定时刻内完成产品的差不多功能开发，并能差不多能够交付客户使用。
目标B：
要按时更新文档和最好记录便于后续的爱护。
目标C：
能够保证一定的系统运行效率，保证安全性。
目标D：
工作分工明确，接口衔接顺畅，经常沟通确定进程和需要解决的问题。
目标E：
提高系统性能与功能，增加系统的寿命
3.2假设、依靠关系和限制
［说明：
描述所有对项目外部的问题和事件所做的假设，以及由这些问题和事件引起的限制。
］
编号
项目外部问题
限制
1
客户要求的交付时刻过早
不能够完成所有的模块开发
2
服务器数据库与软件需求不符
要改变软件数据库设计，不能及时完成软件网络部署
3
硬件器材如检票器等到货较晚
推迟硬件接口的开发，前期只能完成软件模拟
4
客户提出新的需求
开发新的组件，推迟项目交付时刻
5
客户违约
终止项目进程，或查找新的客户
6
资金链断裂
职员积极性受挫，开发进度严峻受阻碍甚至停止
3.3风险治理
表3项目风险
编号
风险描述
风险类型
概率
阻碍程度
后果
缓解策略
1
开发人员技术水平难以满足预期要求
产品规模
40%
灾难的
开发进程停滞
在开发的过程中不断学习
２
系统的规模预算不准确
产品规模
30%
严峻的
交付时刻推迟，开发人员为做好长期预备
适当的精简不必要的系统设计
３
交付日期推迟
商业阻碍
50%
严峻的
发生违约风险
经常与客户沟通
４
用户改变起初的需求
产品规模
60%
轻微的
重新设计某些部分
经常与客户沟通
５
缺少对开发中所使用工具的培训
开发环境
20%
可忽略的
开始时期进度缓慢
不断进行相关的培训
６
人员变动频繁
人员
60%
严峻的
交付时刻推迟，效率下降
相近的最好文本的爱护，便于新进人员了解
风险
详细描述
1
开发人员技术水平难以满足预期要求
同学们实际开发体会少，技术水品有限，不能满足需要
２
系统的规模预算不准确
没有实际的开发体会，对工作量估量不准
３
交付日期推迟
工作效率低，没有体会，人员变动等等因素均会导致
４
用户改变起初的需求
用户随着实际工作改变一部分需求是正常的
５
缺少对开发中所使用工具的培训
时刻紧张，人员少，没有培训人员
６
人员变动频繁
由于课业压力、实习外出等，某些同学可能中途退出
3.4监督和操纵机制
3.4.1报告机制：
A.小组各成员每天将工作进展整理成电子文档交给文档爱护员进行文档爱护。
B.定期举行例会，共同探讨项目进展中的问题，并做好会议记录。
C.项目经理和执行秘书紧密关注项目的各期进展，确保按时交付使用。
并确保风险在可控范畴内。
3.4.2报告格式：
报告主题，时刻段，发觉人，报告内容，审核意见
3.4.3评审机制：
提出问题，大伙儿共同解决。
一致通过，并做记录。
项目经理制定下一时期工作目标和执行进程，执行秘书严格监督。
3.5人员打算
人员类型
人数
技能要求
所需培训
培训方式
C++程序员
3
熟悉C++编程和微软.Net平台
C++编程
小组学习
数据库程序员
3
熟悉SQL语句，熟练使用SQLSever2005
SQL语句
小组学习
界面程序员
2
熟悉CSS、Photoshop、.Net平台
CSS、Photoshop、.Net平台
自学
文档爱护员
1
熟悉使用Word及Powerpoint
Word及Powerpoint
自学
软件测试人员
2
熟练使用开发工具的debug工具，有耐性
debug工具
小组学习
执行秘书
1
较强的沟通能力，能及时调解组内以及组与组之间的矛盾
无
无
4.技术过程
4.1方法、工具和技术
4.1.1编程语言：
C++
4.1.2所需技术：
SqlSever2005、Windows.Net
4.1.3执行标准：
采纳业内通用的方式进行文件命名、代码版式、注释等。
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资源需求
[说明：
提供完成项目所需的全部资源，包括人员、支持软件、运算机硬件、办公室和实验室设备以及项目资源爱护需求的数目和类型等。
］
人员：
伤得起!
!
!
小组软件项目开发成员
支持软件的开发环境：
MicrosoftVisualStudio2020
MicrosoftOfficeword2020
MicrosoftOfficevisio2020
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：
估量调整因子
技术因素
阻碍值
技术因素
阻碍值
备份与复原
4
内部处理复杂度
5
数据通信
2
设计可复用代码
4
分布式处理
0
设计中的转换与安装
3
关键性能
4
多次安装
5
现有操作环境
3
易于变更的应用设计
5
联机数据输入
4
多屏幕输入切换
5
主文件联机更新
3
信息域值复杂度
5
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〕：
人员/资源分配图：
升级会员 