铁路售票管理系统项目计划书_第1页
铁路售票管理系统项目计划书_第2页
铁路售票管理系统项目计划书_第3页
铁路售票管理系统项目计划书_第4页
铁路售票管理系统项目计划书_第5页
已阅读5页,还剩2页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

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

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论