XXX公司智能停车场管理系统项目计划书.doc

一、 引言：1.1 编写目的：为了保证项目团队按时保质地完成项目目标，便于项目团队成员更好地了解项目情况，使项目工作开展的各个过程合理有序，因此以文件化的形式，把对于在项目生命周期内的工作任务范围、各项工作的任务分解、项目团队组织结构、各团队成员的工作责任、团队内外沟通协作方式、开发进度、经费预算、 项目内外环境条件、风险对策等内容做出的安排以书面的方式，作为项目团队成员以及项目干系人之间的共识与约定，项目生命周期内的所有项目活动的行动基础， 项目团队开展和检查项目工作的依据。1.2 背景：XXX智能停车场管理系统是ZZ公司与我公司合作的项目，ZZ公司为了扩大停车场规模，为了更好的为客户服务，特委托我公司为他们开发新一代智能停车场管理系统，这也是对我们公司的一个巨大挑战，这个任务主要由研发部负责开发，测试部，开发部 服务部，业务部负责其他琐碎事务。随着中国用车用户的增多，停车管理趋向机械化，智能化，因此，新的停车管理系统的开发十分必要，我公司应发挥大胆的想象力，开发新一代新颖的智能停车场管理系统。1.3 定义：列出为正确理解本计划书所用到的专门术语的定义、外文缩写词的原词及中文解释。注意尽量不要对一些业界使用的通用术语进行另外的定义，使它的含义和通用术语的惯用含义不一致。1.4 参考资料：嵌入式系统原理与设计 书籍作者：徐端全 图书出版社：北京航空航天出版社嵌入式Linux系统设计 书籍作者：郑灵翔 图书出版社：北京航空航天出版社单片机实用技术 书籍作者：邹久朋 图书出版社：北京航空航天出版社单片机嵌入式系统原理与应用实践 书籍作者：马潮 图书出版社：北京航空航天出版社单片机与嵌入式系统开发方法 书籍作者：薛涛、宫辉、曾鸣、龚光华等 图书出版社：清华大学出版社1.5 标准、条约和约定：本项目开发过程中必须遵守相应的立项建议书、项目任务书、合同、国家标准、行业标准、上级机关有关通知和实施方案、相应的技术规范等。2 项目概述：2.1 项目目标：1、近期目标：在合同规定的时间的40%时间段内要做出一个样本，并由测试部负责测试，服务部与客户交流，在客户允许的情况下投入使用，并由服务部负责统计样本出现的所有问题，并及时反馈给开发部，研发部，及时解决问题。所有的信息都由测试部负责记录，并交给项目总监。2、中期目标：通过近期目标，获得客户的要求及在实践中遇到的所有问题，并及时解决所有问题，再拓展此系统的功能，在规定时间的30%内解决。并随时和客户保持联系，随时记录解决实践中遇到的问题。3、远期目标：通过近期目标和中期的目标的实施，解决问题，满足客户的具体需求，在剩余时间里保证完美产品的开发成功。2.2 产品目标与范围：A、停车场管理系统功能要求： 满位提示及满位不读卡：停车场内车位已经停满时，通过LED显示屏提示前来的车辆，同时禁止按钮出卡，但依然保留电脑出卡功能以满足一些特殊车辆的入场要求； 一卡一车、逻辑互锁：可设置车辆不重复读卡功能，当车辆读卡后，不能再次重复读卡，必须在该车辆离开道闸并关闭通道时，后续车辆才能读卡，有效避免了固定车主重复读卡及取走临时卡的现象；车辆必须先有入场操作才能完成出场操作，一张卡不能多车进场，也不能多车出场，遵循一车一卡的逻辑互锁； 设备监控与管理：控制道闸的开、关，控制发卡机出卡；实时检测道闸的工作状态，实时检测出卡机的工作状态与存储卡片的数量，实时检测车辆检测器的工作状态以及感应线圈上是否有车辆存在，并以生动形象的方式显示； 资金安全：系统对道闸非法打开事件进行记录（如遥控开闸、手动开闸等），同时控制机会对非法开闸发出声音进行报警，使得任何一次、任何情况下的车辆进出都有据可查、可以监管，有效避免了因值班人员的疏忽或有意作弊而造成的资金流失； 临时发卡、一车一卡、取卡开闸：入口读卡机内安装自动出卡机，供临时车辆取卡停车（出卡即读），如果出卡后20秒钟内卡未被取走，出卡机会自动将卡收回出卡机内；同一临时车辆进场取卡，不论其按多少次“取卡”按钮都只出一张卡，并且必须司机将卡拿至手中后，道闸才会开启，避免了司机入场不取卡而出场无卡的麻烦； 出卡机无卡报警：入口自动出卡机内缺卡（比如卡片少于10张）或者无卡时，设置在出口处的控制主机能自动以声音或闪烁等形式报警以提示保安值班员及时续卡。 自动计费、收费：可以按次收费；也可以根据入场时间与出场时间自动计算停车时间，根据停车时间与收费标准自动计算应收费用；收费标准可以根据需要由停车场管理软件非常方便地定义并下传到控制机中；临时车辆要人工以现金形式收取停车费用外，其他车辆可以在发卡或读卡时自动收取/扣除停车费用； 信息显示：高亮度LED显示屏，即使在户外阳光下，显示的信息依然清晰可见；信息内容简明扼要，即可以给车主明确的提示，又不耽误车辆入场的时间；系统故障时可显示故障内容； 脱机、脱网运行：系统在网络或电脑出现故障的情况下，仍然能够正常工作；脱机状态下车辆进出场的记录可以保存1万条以上；当电脑与网络修复后，存在控制机中的脱机记录会自动上传到电脑中保存； 语音提示：声音提示方便周到；模拟人声清晰动听； 身份识别、权限管理（嵌套）：判别前来刷卡的车辆是否有入、出场权限，并能根据卡类（临时卡、月卡、储值卡、特殊卡等）用户可自行设置为自动开闸或确认开闸；可以设置某一车辆可以进出全部的出、入口，也可以限制该车辆只能进出其中的几个出、入口； 读卡快速、信息记录：读卡响应速度快，读卡时间0.1秒，读卡时自动记录卡类、卡号、入场时间、车牌号、车主身份、车辆款式、道闸位置、车辆位置等信息，并在电脑显示屏显示相关信息； 图像对比：通过人工图像对比系统，可以有效防止车辆被盗和常客卡、车不符现象的发生。当车辆读卡或取卡进入停车场时，该系统会对车辆进行拍摄，并将图片作为车辆入场检验的资料保存到电脑内车主的资料库中，当车辆读卡驶离停车场时，系统也会对车辆进行拍摄，并将图片作为车辆出场检验的资料保存到电脑内车主的资料库中，同时自动调出该车的入口图像对比显示，以进行准确的对比确认车辆是否正常使用，从而增强了防盗功能，是否冒用其它车辆的常客卡等； 道闸功能完善、安全防砸：自动道闸具有防抬杆、全卸荷、光电控制、带准确平衡系统等功能；有感应自控和手动按钮控制等多种控制方式；先进的数字式车辆检测系统和地感感应双重防砸系统，有效避免车辆、行人等被砸伤； 收费标准自行加载：对绝大多数的收费标准都可以通过电脑设定好后，直接加载至控制机，在系统脱机时依然能够100%确保收费准确； 卡片多种分类：可设置多种卡类，如地上、地下不同收费方式的月卡、临时卡、储值卡、免费卡等，可对不同的管理人员设定不同的管理方式及权限，对各种车辆、车型采用不同的卡类及收费标准； 系统设置：免硬件拨码方式，通过停车场管理软件简单的鼠标点击，可以轻松的进行系统设置，如有/无图像对比系统、数据保留时间、选择授权发卡的设备、收费方式、是/否满位提示、开闸方式等； 万能查询功能：可以通过一个条件或多个条件相组合，对车场使用情况、收费情况、卡片使用情况、车辆进出情况等相关资料进行查询，能对有固定车位的车场车位使用情况进行统计，并能够按照客户的要求生成报表，或方便其他系统调用的电子报表； 统计管理：提供各种统计资料以不同的报表形式输出，提供任意形式的查询并以报表形式输出；B、产品目的： 满足客户及用户的需求，使停车管理系统更人性化C、产品目标：提高工作信息报送反馈工作效率，更好地进行工作信息报送的检查监督，提高信息的及时性、汇总统计信息的准确性，减轻各级相关工作人员的劳动强度。”2.3 假设与约束：对于项目必须遵守的各种约束（时间、人员、预算、设备等）进行说明。这些内容将限制你实现什么、怎样实现、什么时候实现、成本范围等种种制约条件。假设是通过努力可以直接解决的问题，而这些问题是一定要解决才能保证项目按计划完成。如：“系统分析员必须在3天内到位”或“用户必须在8月8日前确定对需求文档进行确认”约束一般是难以解决的问题，但可以通过其他途径回避或弥补、取舍，如人力资源的约束限制，就必须牺牲进度或质量等等。假设与约束是针对比较明确会出现的情况，如果问题的出现具有不确定性，则应该在风险分析中列出，分析其出现的可能性（概率）、造成的影响、应当采取的相应措施。2.4 项目工作范围：说明为实现项目的目标需要进行那些工作。在必要时，可描述与合作单位和用户的工作分工。注意产品范围与项目工作范围的不同含义。产品范围界定：软件系统产品本身范围的特征和功能范围。工作范围界定：为了能够按时保质交付一个有特殊的特征和功能的软件系统产品所要完成的那些工作任务。产品范围的完成情况是参照客户的需求来衡量的，而项目范围的完成情况则是参照计划来检验的。这两个范围管理模型间必须要有较好的统一性，以确保项目的具体工作成果，能按特定的产品要求准时交付。2.5 应交付成果:2.5.1 需完成的软件：软件对象：源程序、数据库对象创建语句、可执行程序、支撑系统的数据库数据、配置文件、第三方模块、界面文件、界面原稿文件、声音文件、安装软件、安装软件源程序文件等等。编程语言：ARM，keiluvsion,WINCE,LIUNIX2.5.2 需提交用户的文档：需求规格说明书，帮助手册，2.5.3 须提交内部的文档：可行性分析报告，项目计划书，需求分析文档，概要设计文档，详细设计文档，测试文档2.5.4 应当提供的服务：根据合同或某重点建设工作需要，将向客户或委托单位提供的各种服务：培训、安装、维护和运行支持等2.6 项目开发环境：硬件：电脑，嵌入式开发箱，单片机，POS机.软件：J2ME，ARM嵌入式系统开发，keil uvision，wince，c+2.7 项目验收方式与依据：验收包括：交付前验收、交付后验收、试运行（初步）验收、最终验收、第三方验收、专家参与验收等等。项目验收依据：主要有标书、合同、相关标准、项目文档（最主要是需求规格说明书）。3 项目团队组织：3.1 组织结构：项目经理：主要负责与客户的交流及项目的总体开发计划经理：主要负责项目的开发，协助项目经理的工作，对项目起监督作用系统分析师：带领分析组做好每一个阶段的分析，并充分做好文档记录，为项目的设计和系统的开发做好铺垫，并及时解决分析组和设计组反映问题的，并做好有关问题的文档记录分析组：在系统分析师的带领下，做好每一阶段的分析工作构架设计师：根据分析组的分析报告，带领设计组做好项目的设计，并充分做好文档记录，为程序的开发和系统的测试做好铺垫，并及时解决研发组和测试组反映的问题，做好有关问题的文档记录.设计组：在系统分析师的带领下，做好项目的设计工作.程序设计师：根据分析组的分析报告和设计组的设计方案，带领研发组开发项目，有什么问题及时和系统分析师和构架设计师做好沟通，开发过程中做好文档记录研发组：在程序设计师的带领下做好研发工作，并做好文档记录，与测试组做好沟通，及时解决问题。软件测试师：带领测试组做好产品的测试工作，并和以上几个组和客户做好沟通，确保产品符合客户的要求，确保产品的稳定，耐用，做好文档记录测试组：在软件测试师的带领下，做好项目的开发工作.做好文档记录.3.2 人员分工：3.3 协作与沟通：项目的沟通与协作:项目开发人员与客户的沟通，项目开发人员之间的沟通和协作.沟通方式:会议、使用电话、QQ、内部邮件、外部邮件、QuickPlace、聊天室等等。其中邮件沟通应当说明主送 人、抄送人，聊天室沟通方式应当约定时间周期。协作模式：沟通，如何互相配合来共同 完成某项任务。定期的沟通一般要包括项目阶段报告、项目阶段计划、阶段会议等3.3.1 项目团队内部协作：本节说明在项目开发过程中项目团队内部的协作模式和沟通方式、频次、沟通成果记录办法等内容。3.3.2 项目接口人员：接口工作的人员即他们的职责、联系方式、沟通方式、协作模式，包括：a、负责本项目同用户的接口人员及职责：部门姓名联系方式沟通方式协作方式b、负责本项目同本企业各管理机构，如计划管理部门、合同管理部门、采购部门、质量管理部门、财务部门等的接口人员及职责： 部门姓名联系方式沟通方式协作方式c、负责本项目同分包方的接口人员及职责：部门姓名联系方式沟通方式协作方式3.3.3 项目团队外部沟通与协作模式：项目团队外部包括企业内部管理协助部门、项目委托单位、客户等等。本节说明在项目开发过程中项目团队内部与接口人员、客户沟通的方式、频次、沟通成果记录 办法等内容。明确最终用户、直接用户及其所在本企业部门名称和联系电话。明确协作开发的有关部门的名称、经理姓名、承担的工作内容以及工作实施责任人的 姓名、联系电话。确定有关的合作单位的名称、负责人姓名、承担的工作内容以及实施人的姓名、联系电话。4 实施计划：4.1 风险评估及对策：软件开发项目风险：1) 工程规模进度上的风险：规模大，规模估算不精确甚至误差很大；就规模而言，用户要求交付期、费用很紧；预料外的工作(测试未完时的现场对应等)；2) 技术上的风险：使用新的开发技术、新设备等，或是新的应用组合，没有经验；是新的行业或业务，没有经验；性能上的要求很严；3) 用户体制上的问题：用户管理不严，恐怕功能决定、验收不能顺利地完成（或者出现了延迟）；或者恐怕功能会多次变更；与用户分担开发，恐怕工程会拖延（或者出现了延迟）；用户或其他相关单位承担的工作有可能延误；4) 其它：公司人事任免，市场转向，政府干涉风险的对策：避免：排除特定危胁往往靠排除危险起源；减缓：减少风险事件的预期资金投入来减低风险发生的概率，以及减少风险事件的风险系数；吸纳：接 受一切后果，可以是积极的（如制定预防性计划来防备风险事件的发生），也可以是消极的（如某些费用超支则接受低于预期的利润）。4.2 工作流程：.瀑布模型：做概要设计，首先对项目有一个全局的设计有一下优点：1）为项目提供了按阶段划分的检查点。 2）当前一阶段完成后，您只需要去关注后续阶段。 3）可在迭代模型中应用瀑布模型。螺旋模型：根据以上分析，对项目作出详细计划.1）设计上的灵活性,可以在项目的各个阶段进行变更。 2）以小的分段来构建大型系统,使成本计算变得简单容易。 3）客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性。 4）随着项目推进,客户始终掌握项目的最新信息 , 从而他或她能够和管理层有效地交互。 5）客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。4.3 总体进度计划：需求评审：设计评审：制定软件项目进度计划可以使用一些专门的工具，最常用的是Microsoft的Project作为辅助工具，功能比较强大，比较适合于规模较大的项目，但 无法完全代替项目计划书，特别是一些主要由文字来说明的部分。小规模的项目可简便地使用EXCEL作为辅助工具。关于如何使用这些工具不在此作详细说明。制定软件项目进度计划应当考虑以下一些因素:1）对于系统需求和项目目标的掌握程度。如开始时对于系统需求和项目目标只有比较数的了解，就只能制定出比较粗的进度计划，等到需求阶段或设计阶段结束，就应该进一步细化进度计划。2）软件系统规模和项目规模，这两个不是一个概念。软件系统规模往往是从功能点的估算或其他估算方式得来的，而项目规模还要考虑对文档数量与质量的要求， 使用的开发工具、新技术、多少复用、沟通的方便程度、客户方的情况、需要遵守的标准规范等等等等。例如，完成一个大型的系统，在一定的时间内一个人或几个 人的智力和体力是承受不了的。由于软件是逻辑、智力产品，盲目增加软件开发人员并不能成比例地提高软件开发能力。相反，随着人员数量的增加，人员的组织、 协调、通信、培训和管理方面的问题将更为严重。3）软件系统复杂程度和项目复杂程度：和软件系统规模和项目规模一样，软件系统的复杂程度主要是考虑软件系统本身的功能、架构的复杂程度，而项目的复杂程 度主要是指项目团队成员的构成、项目任务的复杂程度、项目干系人的复杂程度、需求调研的难易程度，多项目情况下资源保障的情况，等等等等。软件系统的规模 与软件系统的复杂程度未必是成比例的关系；同样项目的规模与项目的复杂程度未必是成比例的关系。4）项目的工期要求，就是项目的紧急程度。有些项目规模大，却因为与顾客签订了合同，或者为了抢先占领市场，工期压缩得很紧，这时就要考虑如何更好地合理 安排进度，多增加人选多采用加班的方式是一种万不得已的选择。增加人选除了增加人的成本外必定会增加沟通的成本（熟悉项目任务所需要的时间）；加班如果处 理不好会造成情绪上的问题，也可能会因为过于忙碌而无法顾及质量，造成质量的下滑。5）项目成员的能力。这些能力包括项目经理的管理能力，系统分析员的分析能力、系统设计人员的设计能力、程序员的编码能力、测试人员的测试能力，以及企业 或项目团队激发出这些能力的能力。从另外一个角度看还有总体上对客户行业业务的熟悉程度；对于建模工具、开发工具、测试工具等技术的掌握程度；企业内部对 行业业务知识和主要技术的知识积累。4.4 项目控制计划4.4.1 质量保证计划执行质量评审活动，对过程质量进行控制。规模较大的项目应当单独编写软件开发项目质量计划。根据GB/T 12504 计算机软件质量保证计划规范，内容包括：1、 引言（本章节包括质量计划的目的、定义、参考资料）2、 管理（描述负责软件质量管理的机构、任务及其相关的职责）3、 文档（列出在该软件的开发、验证与确认以及使用与维护等阶段中需要编制的文档，并描述对文档进行评审与检查的准则）4、 标准、条例和约定（列出软件开发过程中要用到的标准、条例和约定，并列出监督和保证执行的措施）5、 评审和检查（规定所要进行的技术和管理两个方面的评审和检查工作，并编制或引用有关的评审和检查规程，以及通过与否的技术准则。至少要进行软件需求评审、概要设计评审、软件验证与确认评审、软件系统功能检查、程序和文档物理检查）6、 软件配置管理（编制有关配置管理条款，或在“4.4.4 配置管理计划”中说明，或引用按照GB/T 12505 计算机软件配置管理计划规范单独制定的文档）7、 工具、技术和方法（指明用于支持特定软件项目质量管理工作的工具、技术和方法，指出它们的目的和用途）8、媒体控制（说明保护计算机程序物理媒体的方法和设施，以免非法存取、意外损坏或自然老化）9、对供货单位的控制（供货单位包括项目承办单位、软件销售单位、软件开发单位。规定对这些供货单位进行控制的规程，从而保证项目承办单位从软件销售单位购买的、其他开发单位开发的或从开发单位现存软件库中选用的软件能满足规定的需求。）10、记录的收集、维护和保存（指明需要保存的软件质量保证活动的记录，并指出用于汇总、保护和维护这些记录的方法和设施，并指明要保存的期限）4.4.2 进度控制计划本项目的进度监控执行本企业项目管理规范，由本企业过程控制部门如质量管理部统一进行监控，并保留在监控过程中产生的日常检查记录。4.4.3 预算监控计划说明如何检查项目预算的使用情况。根据项目情况需要制定。4.4.4 配置管理计划编制有关软件配置管理的条款，或引用按照GB/T 12505单独制订配置管理计划文档。在这些条款或文档中，必须规定用于标识软件产品、控制和实现软件的修改、记录和报告修改实现的状态以及评审和检 查配置管理工作等四方面的活动。还必须规定用以维护和存储软件受控版本的方法和设施；必须规定对所发现的软件问题进行报告、追踪和解决的步骤，并指出实现 报告、追踪和解决软件问题的机构及其职责。根据GB/T 12505 计算机软件配置管理计划规范，软件配置管理计划内容如下：1 、 引言（本章节包括质量计划的目的、定义、参考资料）2、管理（描述负责软件配置管理的机构、任务、职责及其有关的接口控制。）3、 软件配置管理活动（描述配置标识、配置控制、配置状态记录与报告以及配置检查与评审等到四方面的软件配置管理活动的需求。）4、工具、技术和方法（指明为支持特定项目的软件配置管理所使用的软件工具、技术和方法，指明它们的目的，并在开发者所有权的范围内描述其用法）5、 对供货单位的控制（供货单位是指软件销售单位、软件开发单位或软件子开发单位。必须规定对这些供货单位进行控制的管理规程，从而使从软件销售单位购买的、其他开发单位开发的或从开发单位现存软件库中选用的软件能满足规定的软件配置管理需求）6、 记录的收集、维护和保存（指明要保存的软件配置管理文档，指明用于汇总、保护和维护这些文档的方法和设施，并指明要保存的期限）5 支持条件:说明为了支持本项目的完成所需要的各种条件和设施。5.1 内部支持：设备、软件支持包括客户机、服务器、网络环境、外设、通讯设备、开发工具、操作系统、数据库管理系统、测试环境，逐项列出有关到货日期、使用时间的要求。5.2 客户支持:需由客户承担的工作：完成期限：验收标准：需由客户提供的条件及提供时间：6 预算：6.1 人员成本:产品/项目团队每一个人的预计工作月数：完成本项目所需要的劳务（包括人员的数量和时间）：劳务费（包括工资、奖金、补贴、住房基金、退休养老金、医疗保险金）：6.2 设备成本:设备成本（包括：原材料费，设备购置及使用费 ）：拟购置的设备及其配置和所需的经费：拟购置的软件及其版本和所需的经费：使用的现有设备及其使用时间：6.3 其它经费预算:（1） 差旅费（旅费、出租）（含补贴）： （2） 资料费（图书费、资料费、复印费、出版费）： （3） 通信费（市话长话费、移动通信费、上网费、邮资） ：（4） 会议费（鉴定费、评审会、研讨费、外事费等） ：（5） 办公费（购买办公用品）：（6） 协作费（业务协作招待费、项目团队加班伙食费）：（7） 培训费（培训资料编写费、资料印刷费、产地费、设备费）：（8）其他（检测、外加工费、维修费、消耗品、低易品、茶话会等）：6.4 项目合计经费预算：完成本项目需要的所有经费预算（上述各项费用之和）：7 关键问题：逐项列出能够影响整个项目成败的关键问题、技术难点和风险，指出这些问题对项目成败的影响。8专题计划要点：专题计划也就是因为项目的需要在本文档之外独立建立的计划，本节说明本项目开发中需要制定的各个专题计划的要点。专题计划可能包括分合同计划、分项目计划、项目团队成员培训计划、测试计划、安全保密计划、质量保证计划、配置管理计划、用户培训计划、系统安装部署计划。