软件系统项目计划书

  • 格式:doc
  • 大小:16.50 KB
  • 文档页数:6

下载文档原格式

  / 6
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

软件系统项目计划书

一、引言

1、1编写目的:制定一套软件项目实施及管理的解决方案,让公交公司的总经理能更好的认识该系统。

1、2背景:主要说明项目的来历,一些需要项目团队成员知道的相关情况。主要有以下内容:

项目名称:BUS系统,项目的委托单位:某市软件公司,项目的用户(单位):某市公交部门,广大乘客项目的任务提出者:某市市政府项目的主要承担部门:某市公交部门项目建设背景:公共交通是与人民群众生产生活息息相关的重要基础设施。公共交通系统作为城市交通的主体,在满足广大市民出行、确保城市交通稳定运行中发挥着重要作用。“公交优先”已经成为从中央到地方各级政府的共识。优先发展城市公共交通是提高交通资源利用效率,缓解交通拥堵的重要手段。系统与机构的关系:公交部门可以使用该系统,更条理地调度交通,采用信息技术实现公交运营调度智能化,提高公交服务的质量,满足社会需要。

1、3定义:遗撒是指车辆上的东西掉到了路面上,对后面的车辆造成影响。调度就是指调度员对运行车辆碰到一些情况的对应措施。甩站就是指运行的公交车辆到了该停的车站不停车,直接通过。虚开班次是指车辆报告自己开的班次大于实际所开班

次,这种行为可不太好。胎压异常是指车辆的轮胎压力异常,处于需要维修的状态

1、4参考资料:列出本计划书中所引用的及相关的文件资料和标准的作者、标题、编号、发表日期和出版单位,必要时说明得到这些文件资料和标准的途径。本节与下一节的“标准、条约和约定”互为补充,注意“参考资料”未必作为“标准、条约和约定”,因为“参考”的不一定是“必须遵守”的。

1、5标准、条约和约定:GB/T13702-1992 计算机软件分类与代码 GB/T20918-xx 信息技术软件生存周期过程风险管理

GB/T19003-xx 软件工程 GB/T19001-2000GB/T15538-1995 软件工程标准分类法 GB/T9386-xx 计算机软件测试文档编制规范 GB /T9385-xx 计算机软件需求规格说明规范 GB/T15532-xx 计算机软件测试规范 GB/T18221-2000 信息技术程序设计语言环境与系统软件接口独立于语言的数据类型 GB/T11457-xx 信息技术软件工程术语 GB8567-xx计算机软件文档编制规范

二、项目概述

2、1项目目标:BUS系统主要实现目标是实现公交运营调度的智能化、信息化,通过该系统来代替以往手工调度存在的弊端。

2、2产品目标与范围:系统的主要功能是实现车况、路况、客流的实时监控,通过监控数据实现公交车辆的灵活调度。该系统有五类角色:乘客,乘务员,调度员,业务员和管理员。乘客

主要是通过查询页面来查询乘车线路;乘务员采集车辆位置、车速、车况、车辆载客(客流)等数据并入系统,调度员根据采集的这些信息发出调度指令,乘务员执行调度指令;业务员可以生成各种报表;管理员则可以对各个人的权限进行增删改查的操作。

2、3假设与约束:BUS系统开发时间为xx、4、1XXX 需求顾问XXX 技术专家XXX项目组:项目负责人马经理各部门联系人

3、2人员分工:开发组:

开发经理小刘(负责开发组日常工作和数据库)组员小张(负责测试系统)组员赵经理(负责管理技术文档编写工作)组员小邓(负责技术文档编写)项目管理组:

项目经理—反映各部门业务需求和部门用户意见

3、3协作与沟通:文档组向开发组和测试组挖掘技术信息,写到技术文档中。测试组在开发过程中就介入到开发组中来,和开发人员共同完成本系统的开发任务。管理层给大家分配任务,并督促大家完成。开发组和需求顾问需要深入了解客户需求,通过需求分析明确定义系统的功能,再把设计和开发任务下达到各个小组负责人和组员,然后在规定的时间把产品交给高校,形成一种良性循环。

3、3、1项目团队内部协作:文档组向开发组和测试组挖掘技术信息,写到技术文档中。测试组在开发过程中就介入到开发组

中来,和开发人员共同完成本系统的开发任务。管理层给大家分配任务,并督促大家完成。

3、3、2项目团队外部沟通与协作模式:开发组和需求顾问需要深入了解客户需求,通过需求分析明确定义系统的功能,再把设计和开发任务下达到各个小组负责人和组员,然后在规定的时间把产品交给高校,形成一种良性循环。

四、实施计划

4、1风险评估及对策:客户需求会经常变更,影响项目的进度。可以加班并延长需求调研时间,也可以严格控制需求变更来防止这类现象出现。至于人员流动问题,可以招聘技术人员作为长期任务,加强沟通,及时了解人员开发动态。并从外部招聘有此类工作经验的技术人员。资金不足,可以请实习学生参与一部分辅助工作,降低开发成本,也可以与客户商量,去掉不必要的需求,降低工作量,减少开发时间。

4、2项目时间管理:项目进度由总经理和各组经理负责,把总体工作计划分配到每个月,进而分配到每一天,每个人。项目启动:三月份完成。由项目经理和技术专家负责。需求分析:四月份完成,由需求顾问完成。系统与测试设计:五月份和六月份完成。其中概要设计由开发经理在五月份完成,详细设计由开发经理在六月份完成。测试策略由测试经理在五月份完成,测试计划由测试经理在六月份完成。编码与测试执行:从七月初到一月初完成,其中制定编码规范由开发经理在七月中旬完成,确定测

试需求由测试经理在七月中旬完成。编码的时间比较长一点,由开发工程师从七月中旬到一月初完成,单元测试由开发工程师从八月份到一月初完成,编写测试用例由测试工程师从七月中旬到一月初完成。执行测试由测试工程师在一月份完成。测试评估与系统部署:在二月份完成。其中测试评估由测试经理在二月中旬完成,制定部署方案由开发经理在二月中下旬完成。

4、3质量管理计划:质量管理由项目经理牵头,测试经理通过负责软件测试工作保证软件质量。对每个开发阶段的阶段性成果都进行评审或者测试,以保证软件产品的质量。需求分析阶段:项目经理在3月31号进行需求评审。系统与测试设计阶段:在4月30号进行概要设计评审制定测试策略评审,在5月31号进行详细设计评审和制定测试计划评审,在6月5号进行制定编码规范评审。测试经理在6月9号进行测试需求评审,在8月1号和9月1号进行代码审查,在11月1号进行单元测试报告评审和测试用例评审,在12月1号进行缺陷报告评审。测试评估与系统部署阶段:在12月15号测试经理进行测试评估报告评审,开发经理进行部署方案评审。软件质量出现问题的话,按以下流程解决:

1、发现问题,找出问题的责任人

2、通知问题责任人限期修改

3、问题责任人修改问题

4、问题责任人将修改后的内容反馈给发现问题的人员