铁路售票管理系统项目计划书.docx
- 文档编号:24323707
- 上传时间:2023-05-26
- 格式:DOCX
- 页数:7
- 大小:17.83KB
铁路售票管理系统项目计划书.docx
《铁路售票管理系统项目计划书.docx》由会员分享,可在线阅读,更多相关《铁路售票管理系统项目计划书.docx(7页珍藏版)》请在冰豆网上搜索。
铁路售票管理系统项目计划书
软件工程课程设计报告
专业班级:
信息与计算科学0901班
项目名称:
铁路售票管理系统
项目组长:
成员:
2012.1.5
铁路售票管理系统项目计划书
铁路售票管理系统项目计划书
1.1编写目的
本文档是根据铁路售票管理系统项目的初步需求,并对项目的各项需求进行全面分析之后,做出的软件开发计划,可供支持项目组内部及信息技术部内部的研发工作。
1.2背景
项目名称:
铁路售票管理系统
开发单位:
信心与计算科学0901班
开发日期:
2011.12.4——2012.1.4
1.3定义
术语名称
含义
C/S
客户端/服务端结构
最终用户
系统开发后的最终使用者
一般用户
需购买火车票进行业务的人群即旅客
售票员
车站及代售点的所有售票员
系统管理员
具有对不同用户进行管理,输入用户的各种信息、管理用户权限、
维护数据库等权限的用户
1.4参考资料
【1】《软件工程概论》郑人杰马素霞等编著机械工业出版社2010
【2】《软件工程——理论,方法与实践》孙家广主编刘强编著高等教育出版社2006
【3】《软件工工程-理论与实践》ShariLawrencePfleeger编著高等教育出版社2010
2项目概述
2.1工作内容
实现列车及车票信息查询、登录系统及信息管理、车票的销售与退票列车及车票管理等子系统的流程化管理。
主要完成以下系统:
1:
列车及车票信息查询子系统2:
登录系统及信息管理子系统3:
车票的销售与退票子系统4:
列车及车票管理子系统。
并提交相关文档。
2.2主要参加人员
成员
角色
职责
孙峰
组长、主程序员
领导项目团队、执行和管理团队。
负责软件设计和编写代码。
并撰写软件设计报告。
文晋孟
程序员、文档维护员
整理、撰写需求分析报告。
参与软件设计与代码开发。
魏刚
程序员、开发人员
。
赵林
软件测试员
主要负责软件代码测试和用户测试、并撰写测试文档。
2.3产品
2.3.1程序
软件名称:
铁路售票管理系统
编程语言:
C++
存储方式:
光盘
2.3.2文件
铁路售票管理系统,及用户帮助文档。
2.3.3服务
向用户提供的各项服务,如培训安装、维护和运行支持等。
2.4完成项目的最迟期限
完成项目的最迟期限:
2012.1.4
3实施计划
3.1工作任务的分解与人员分工
孙峰组长、主程序员领导项目团队、执行和管理团队。
负责软件设计和编写代码。
并撰写软件设计报告负责子系统1。
文晋孟程序员、文档维护员整理、撰写需求分析报告。
参与软件设计与代码开发
负责子系统2.
魏刚程序员、开发人员整理软件设计报告告。
参与软件设计与代码开发
负责子系统3
赵林软件测试员主要负责软件代码测试和用户测试、并撰写测试文档
负责子系统4
子系统:
1:
列车及车票信息查询子系统2:
登录系统及信息管理子系统3:
车票的销售与退票子系统4:
列车及车票管理子系统
3.2接口人员
负责接口工作的人员及的职责:
a.负责本项目同用户的接口人员:
赵林
b.负责本项目同本单位各管理机构:
孙峰
3.3进度
准备工作:
时间:
第1天到第2天
关键工期:
项目管理计划初稿发布
需求分析:
时间:
第3天到第6天
关键工期:
需求规格说明书初稿的发布
系统设计:
时间:
第7天到第14天
关键工期:
系统设计初稿的发布
源代码开发与测试:
时间:
第15到第24天
关键工期:
编码开发与测试
系统集成:
时间:
第25到27天
关键工期:
整个系统的成功测试
软件交付:
时间:
第28到30天
关键工期:
整个系统能成功且稳定的运行
3.4需交付的文档
1.软件项目管理计划
该文档由组长完成,介绍项目的整个管理过程。
该文档在软件设计需求分析初级阶段完成,后续阶段由文档维护员进行相应的更新。
2.需求规格说明初稿
在需求分析阶段,由全体小组成员采集分析用户的需求,并在例会上作出决策,有文档维护员撰写整理需求规格说明初稿,并在后续各个阶段进行需求变更的更新。
3.设计报告初稿
在总体设计阶段,小组根据需求规格说明文档,完成软件体系结构的设计,由组长编写软件体系结构设计文档初稿,并在后续开发阶段补充和更新。
该文档由文档维护员负责维护更新。
4.测试文档
在软件开发阶段,测试人员需要编写测试规格说明文档,并在后续测试阶段更新。
开发人员将根据测试规格说明文档建立测试环境、准备测试数据。
6.个人项目总结
由组内成员各自独立完成,对开发过程中获得的工作经验进行总结。
在提交系统时一并提交。
7.其他文档
软件开发过程中的其他文档,如开发日志(按组员意见选择公开与否),风险报告及其处理意见等,由秘书进行整理与汇聚。
作为以后软件开发以及交流的经验。
3.5项目沟通管理
报告机制:
1.要求各组员以周为单位记录工作进展,形成开发日志,并以电子文档的形式提交给秘书进行整理,最后由文档维护员进行维护。
2.每周例会上各位组员积极对当前的开发工作进行积极的评审和建言,由组长做最后的作口头总结,由秘书主持会议并记录和整理会议的内容。
文档维护员修改和维护相应的文档。
并交由小组进行会议评审并给出意见。
3.小组成员都要密切监控风险状态,发现风险后提交风险报告。
由秘书定期提交风险报告。
必要时将突发风险通知所有组员,并由组长做出临时处理决定。
然后在该周的例会上由小组成员共同讨论对风险的处理意见。
并形成风险处理的日志做为以后的经验。
4.在项目进行的过程当中,组员之间应该多进行各种形式的非正式沟通,以使沟通更加的方便、快捷。
报告格式:
报告主题,时间段,发现人,报告内容,审核意见
评审机制:
每周例会上小组讨论形成一致意见后并,并邀请团长和其他组长参加评议。
对于重大的风险处即为通过,相关负责人针对改进意见开展下一周工作,严格执行例会上所制定的决策。
小组会议持续评估其成效。
每一项目阶段结束之前(里程碑前后),组织一次阶段评审会,评估整个阶段的工作效率和成果质量。
尽量与项目例会合理意见,应该由团长及其他组长组成评审团对处理意见进行审议和评估。
并以评审团的决议作为重要参考来制定决策。
4支持条件
本小组的团队组织结构为主程序员式组织结构;编程语言为C++;采用面向对象的分析设计方法;利用VisualStudio2005平台作为开发平台;使用SqlSever2000作为数据库管理系统图;并采用统一的C++标准的文件命名方式、代码版式、注释等编码规范;编码人员对代码进行严格检查后再进行代码编译;测试人员根据测试文档进行单元测试;最后实现软件的交付。
开发环境:
Sqlsever2000VisualStudio2005
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 铁路 售票 管理 系统 项目 计划书