公交运营调度系统系统项目计划书任务素材文档格式.docx
- 文档编号:21851022
- 上传时间:2023-02-01
- 格式:DOCX
- 页数:17
- 大小:21.29KB
公交运营调度系统系统项目计划书任务素材文档格式.docx
《公交运营调度系统系统项目计划书任务素材文档格式.docx》由会员分享,可在线阅读,更多相关《公交运营调度系统系统项目计划书任务素材文档格式.docx(17页珍藏版)》请在冰豆网上搜索。
ScenariosBusSys(2010_06_03)
(1).docx—公交调度系统开发团队所整理的需求功能文档
标准、条约和约定
本项目遵从以下标准:
GB/T13702-1992计算机软件分类与代码
GB/T20918-2007信息技术软件生存周期过程风险管理
GB/T19003-2008软件工程GB/T19001-2000
GB/T15538-1995软件工程标准分类法
GB/T9386-2008计算机软件测试文档编制规范
GB/T9385-2008计算机软件需求规格说明规范
GB/T15532-2008计算机软件测试规范
GB/T18221-2000信息技术程序设计语言环境与系统软件接口独立于语言的数据类型
GB/T11457-2006信息技术软件工程术语
GB8567-2006计算机软件文档编制规范
2项目概述
项目目标
本项目是为公交公司开发一套运营调度管理系统,用信息化手段代替原有的手工调度模式。
产品目标与范围
本项目产品的目标是实现公交运营调度的智能化、信息化,通过该系统来代替以往手工调度存在的弊端。
系统的主要功能是实现车况、路况、客流的实时监控,通过监控数据实现公交车辆的灵活调度。
该系统有五类角色:
乘客,乘务员,调度员,业务员和管理员。
其中乘客主要是通过查询页面来查询乘车线路;
系统自动采集车辆位置、车速、车况、车辆载客(客流)等数据,,调度员根据采集的这些信息发出调度指令,乘务员执行调度指令;
业务员可以生成各种报表;
管理员则可以对各个人的权限进行增删改查的操作。
假设与约束
本项目的开发时间为—开发人员人数:
6人
技术文档写作人员人数:
3人
测试人员人数:
2人
开发经费预算:
200万元人民币
设备:
2台PCServer服务器
项目工作范围
为了使本系统成功上线,需要在在之前完成本系统的开发与测试,并写提交相关的技术文档。
通过与客户的沟通,及时获得客户的最新需求,以便于本系统的完善。
应交付成果
2.5.1需完成的软件
公交运营调度系统软件
2.5.2需提交用户的文档
安装维护手册、使用手册
2.5.3需提交内部的文档
需求规格说明书,概要设计说明书,详细设计说明书,源代码清单、代码接口说明、测试策略、测试计划、系统测试用例、缺陷报告、最终测试结果报告。
2.5.4需提供的服务
将向客户提供一次集中培训和辅导,一年之内的系统维护。
项目开发环境
硬件环境:
PCServer服务器,人手一台PC机,
软件环境:
Tomcat+Maven+JDK+MySQL+Eclipse及插件
网络环境:
100M及以上速率局域网,TCP/IP协议
项目验收方式与依据
项目验收将采取三方验收的方式进行:
客户方,开发方和监理方。
通过考察系统的使用情况,用户的反馈以及专家的意见,形成共同意见并共同签署验收报告,标志着验收工作告一段落。
3项目团队组织
组织结构
项目团队分为开发组,测试组,文档组和项目管理组。
其中开发组需要对软件开发所用到的Java语言和数据库技术特别擅长,能够在开发组组长的带领下,在规定的时间内迅速完成软件开发工作。
测试组需要在开发过程中就开始参与进来,开展测试工作,并且在开发完成后还要继续测试工作,知道软件交付使用。
测试组需要有广阔的思维来设计测试用例,然后细心的测试,发现Bug。
文档组需要对软件开发和测试流程相当熟悉并且有扎实的写作工作,能够配合其他团队编写出项目开发过程的全部文档。
项目管理组需要擅长把握公司的整体运作,包括识人用人,接单,推广产品,激发员工积极性等一系列工作。
人员分工
(1)开发方
开发组:
开发经理—孙经理(负责技术难点)
组长—小刘(负责开发组日常工作和数据库)
组员—小齐(负责系统开发)
--小马(负责系统开发)
--小赵(美工)
--小奚(实习)
测试组:
测试经理:
XXX(负责带领测试团队完成整个系统的测试工作)
组员—小张(负责测试系统)
组员—小王(负责测试系统)
文档组:
经理—赵经理(负责管理技术文档编写工作)
组员—小罗(负责技术文档编写)
组员—小邓(负责技术文档编写)
项目管理组:
项目经理—XXX(负责全面管理项目的开发工作)
需求顾问——XXX(负责需求分析工作)
技术专家——XXX(负责项目的可行性分析以及项目中重大技术问题的决策)
(2)客户方
客户方相应地也成立了项目组,由一个项目负责人和多个业务部门联系人组成。
项目负责人——XXX(客户方为此项目指定的负责人,代表客户方做出决策)
各部门联系人——反映各部门业务需求和部门用户意见
协作与沟通
3.3.1内部协作
文档组向开发组和测试组挖掘技术信息,写到技术文档中。
测试组在开发过程中就介入到开发组中来,和开发人员共同完成本系统的开发任务。
管理层给大家分配任务,并督促大家完成。
3.3.2外部沟通
在与客户的沟通中,开发组和需求顾问需要深入了解客户需求,通过需求分析明确定义系统的功能,再把设计和开发任务下达到各个小组负责人和组员,然后在规定的时间把产品交给高校,形成一种良性循环。
4实施计划
风险评估及对策
本项目的主要风险是开发人员对客户需求中的公交运营调度业务不熟悉,另外,在人员、资金、时间、技术等方面都存在风险。
每个风险的可能性,对风险分析如下表所示。
序号
输入
风险事件
可能性
影响
风险值
采取措施
1
客户需求
需求不明确、需求变化
70%
60%
35%
1.加班,延长需求调研时间
2.严格控制需求的变化
2
历史项目信息
开发人员流动
30%
50%
15%
1.招聘技术人员作为长期任务
2.加强沟通,及时了解人员开发动态。
3.从外部招聘有此类工作经验的技术人员
3
合同
开发资金有限
20%
10%
1、请实习学生参与一部分辅助工作,降低开发成本
2、与客户商量,去掉不必要的需求,降低工作量,减少开发时间
项目时间管理计划
项目进度由总经理和各组经理负责,把总体工作计划分配到每个月,进而分配到每一天,每个人,如果在上班时间没有完成,在晚上加班的时候必须完成天计划。
只有确保每天的天计划完成,才能确保总体工作计划顺利完成。
开发计划与人员分工如下图所示。
时间
阶段任务
人员
分工
月
4
5
6
7
8
9
10月
11月
12月
项目启动与计划
项目经理技术专家
需求分析
需求顾问
系统与测试设计
系统概要设计
开发经理
系统详细设计
制定测试策略
测试经理
制定测试计划
编码与测试执行
制定编码规范
确定测试需求
编码
开发工程师
单元测试
编写测试用例
测试工程师
执行测试
测试评估与系统部署
测试评估
制定部署方案
质量管理计划
质量管理由项目经理牵头,测试经理通过负责软件测试工作保证软件质量。
对每个开发阶段的阶段性成果都进行评审或者测试,以保证软件产品的质量。
质量管理时间进度与人员分工如下:
执行时间
3.
31
4.
30
5.
需求评审
项目经理
系统概要设计评审
系统详细设计评审
制定测试策略评审
制定测试计划评审
制定编码规范评审
测试需求评审
代码审查
单元测试报告评审
测试用例评审
缺陷报告评审
测试评估报告评审
部署方案评审
在质量管理计划中,为了保证软件质量管理中队出现的问题的管理,还需要定义问题跟踪流程。
流程如下:
(1)发现问题,找出问题的责任人
(2)通知问题责任人限期修改
(3)问题责任人修改问题
(4)问题责任人将修改后的内容反馈给发现问题的人员
(5)发现问题的质量管理人员对有问题的部分进行重新检验,确认问题得到修改。
(6)如果发现问题没有修改,将通知问题责任人继续修改,直到问题得到解决
成本管理计划
通过计算每人月工资以及一些项目日常开销,可以算出项目的月成本,然后通过计算可以得到在规定时间内的所需资金数,必须让所需资金数小于等于项目预算。
资金预算表(单位:
万元)
阶段资金预算
10
20
40
系统维护
50
配置管理计划
采用专用的版本管理工具进行软件版本的控制。
(1)人员与职责
版本控制管理者:
开发经理职责:
制定版本控制流程
(2)确定版本库的用户权限
管理者:
负责版本管理、对版本库拥有全部权限
开发人员:
CheckinCheckout
测试人员:
读
(3)定义配置项(版本控制项)及其标识
系统项目计划
系统需求说明
系统概要设计
系统详细设计
测试策略
测试计划
测试用例
编码规范
源代码
缺陷报告
测试最终结果报告
(4)定义项目基线(略)
(5)定义配置项的版本管理策略
按照4类不同功能的分支进行:
主干分支
私有分支
小组分支
集成分支
(6)定义变更管理流程(略)
采购计划
在项目初期需要采购PCServer服务器两台和10台PC机,以便使用。
5文档历史
版本
修改内容
修改日期
修改人
审阅人
原始版本
2010-9-7
Bruce
Andy
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 公交 运营 调度 系统 项目 计划书 任务 素材