小区物业管理系统开发计划书.docx

1、小区物业管理系统开发计划书小区物业管理系统开发计划书软件开发计划书1、概述（1）项目介绍项目中文名称：物业管理系统。项目英文名称：Property Management System。项目代号：NS/TEL-PMS-CRM。项目目的：面向社会广大的物业管理开发商，适用与一切的物业管理功能，将帮助广大的用户更好的管理，服务与业主。项目背景：CMM过程改进。客户信息：物业管理开发商。与其他系统的关系：基于BOSS的业务数据进行分析，同时又是DSS的扩展，与他们既有交叉，又有延伸。（2）范围资料维护：包括开发商的资料，物业基本资料。住房管理：包括住户入住登记，住户资料的修改和住户的变更。财产管理：包

2、括小区物业管辖内的资产、设施等管理。财务管理：包括物业管理费、小区停车费、物业维修基金、“水费、电费、煤气费”三费的收取。信息管理：小区出租、出售房屋信息发布，投诉管理。小区工作人员和保安人员的岗位人员的管理。（3）子计划软件配置管理计划；软件质量保证计划；软件测试计划；（4）项目计划的维护项目计划在下列情况下将被更新；1）项目关键问题的解决；2）需求更改导致项目进度的调整在两周或两周以上；3）项目资源需求的改变；4）新技术的引入；5）开发过程的改变；6）软件工作产品的改变；7）项目特性的改变；在项目阶段性审核时，如果更改项目计划，那么项目进度表也应作相应的更新。如果项目进度或项目特性有重大改

3、变时，项目计划的更新更改应得到SCCB认可。（5）项目特性研发初期的阶段性产品。需求部分可以确定，大部分不能马上确定。宣传推广新的CRM理念是一种概念化的产品。2、软件工作产品软件工作产品进度表工作产品名称文档标识号计划完成日期A or R* 需求需求获取/分析表NS/TEL-PMS-CRM-RM-012011-10-30A系统功能说明书NS/TEL-PMS-CRM-RM-022011-11-16A软件需求规格说明书NS/TEL-PMS-CRM-RM-032011-12-28A计划软件开发计划（SDP）NS/TEL-PMS-CRM-PP-012011-11-16A软件配置管理计划NS/TEL-

4、PMS-CRM-PP-022011-11-30A软件质量保证计划NS/TEL-PMS-CRM-PP-032011-11-30A软件测试计划NS/TEL-PMS-CRM-PP-042011-12-10A设计概要设计书NS/TEL-PMS-CRM-SD-012012-01-18A详细设计书NS/TEL-PMS-CRM-SD-022012-02-22A用户手册NS/TEL-PMS-CRM-SD-032012-02-22R数据库设计NS/TEL-PMS-CRM-SD-042012-02-22RBOSS接口规范NS/TEL-PMS-CRM-SD-052012-02-22实现源代码模块NS/TEL-PMS

5、-CRM-IMP-012012-04-12A执行代码模块NS/TEL-PMS-CRM-IMP-022012-04-12R测试确认测试方案NS/TEL-PMS-CRM-TEST-012012-01-20R集成测试方案NS/TEL-PMS-CRM-TEST-022012-02-10R单元测试用例NS/TEL-PMS-CRM-TEST-032012-03-20R单元测试记录NS/TEL-PMS-CRM-TEST-042012-04-24R单元测试报告NS/TEL-PMS-CRM-TEST-052012-04-26R集成测试记录NS/TEL-PMS-CRM-TEST-06见测试计划R集成测试报告NS/

6、TEL-PMS-CRM-TEST-07见测试计划R确认测试记录NS/TEL-PMS-CRM-TEST-08见测试计划R确认测试报告NS/TEL-PMS-CRM-TEST-09见测试计划R系统测试记录NS/TEL-PMS-CRM-TEST-10见测试计划R系统测试报告NS/TEL-PMS-CRM-TEST-11见测试计划R验收产品发布记录NS/TEL-PMS-CRM-CON-012012-05-10R软件质量总结报告NS/TEL-PMS-CRM-CON-02见SQA的计划R财务质量总结报告NS/TEL-PMS-CRM-CON-032012-05-10R项目总结报告NS/TEL-PMS-CRM-C

7、ON-042012-05-10R维护维护记录NS/TEL-PMS-CRM-MT-01A=审核，R=评审，采用审查还是评审由项目组决定。3、假设、依赖和约束假设：项目估计所用到的条件是真实的，从而得到基本准确的计划。依赖的外部条件：1）开发环境条件配备；2）开发人员如期到位；3）项目组及相关组成员受过必要的培训；4）和客户联系顺利；5）指派SCCB、PM、SQA、SCM、测试组人员。约束：NT服务器、java开发工具、EIB组件技术、数据仓库和数据挖掘技术、物业管理领域业务逻辑等。4、项目过程定义1）软件开发生命周期模型计划采用迭代W模型，如图所示：2)方法和工具本项目软件开发所使用的方法和工具

8、如图所示。软件开发方法与工具软件工作产品方法工具项目计划与跟踪PMMS Project 2007需求分析与设计OORational Rose 2003编码OOJBuilder5,Dreamwaver单元测试OORational Robot etc.文档WorldExcelMS Offices 2007配置MS Sourcesafe,Perforce5、任务分解描述软件任务分解和工作包，并提供进度表供项目运行、项目管理活动每周一次的评审、高级经理评审使用。项目进度表安排如下所示.项目进度安排表任务开发日期结束日期需求获取分析2011-10-222011-11-23软件开发计划2011-10-22

9、2011-11-23系统功能说明书2011-10-222011-11-23软件需求规格说明书2011-11-192011-12-28概要设计2011-12-072012-01-08用户手册2011-12-312012-01-18详细设计2012-01-042012-02-22数据库设计2012-01-042012-02-22BOSS接口规范设计2012-01-042012-02-22编码2012-02-012012-04-12单元测试2012-01-072012-04-26项目总结报告2012-04-202012-05-106、估计1）代码量估计估计方法：采用功能点估计方法并结合历史数据。编程

10、语言：Java、JavaBean、EJB、JSP、Sevlet、SQL估计过程：参考CRM项目估计文档。估计结果：代码量=1323FP;文档量=2345页；需求数=123项；2）文档大小估计软件工作产品规模估计表文档名称估计文档大（页）文档名称估计文档大小（页）需求获取/分析表50源代码模块50系统功能说明书80执行代码模块2000软件需求规格说明书100确认测试方案20软件开发计（SDP）30集成测试方案30软件配置管理计划20单元测试方案52软件质量保证计划20单元测试方案60软件测试计划23单元测试方案300概要设计书200集成测试方案21详细设计书155集成测试方案30用户手册23确认

11、测试方案20数据库设计21确认测试方案56BOSS接口规范31系统测试方案12财务总结报告20系统测试报告30项目总结报告10产品发布记录12维护记录20软件质量总结报告50合计23453)工作量估计软件开发工作量估计如下所表示。软件开发工作量估计表阶段工作量（人小时）阶段工作量（人小时）需求与计划1197.00编码1894.73分析1636.43测试2171.93设计2776.73交付316.58合计9993.404）关键计算机资源估计关键计算机资源需求如下。关键资源需求表关键项数量或说明服务器磁盘空间40G网络速度100Mb/s操作系统Windows XPCPU主频P4PC机内存1G以上7

12、、项目管理1）项目组织结构项目组织结果图 2) 角色与职责角色岗位职责如下。角色岗位职责表姓名角色和职责张三项目经理。需求分析、系统分析设计、项目管理李四软件经理。需求分析、系统分析设计、编码测试、技术支持王一系统分析员。需求分析、系统分析设计、编码测试、实施指导陈新高级程序员。技术实施、设计、编码、测试陈苗苗高级程序员。需求收集、设计、编码、测试王军编码、测试李易编码、测试陈诺编码、测试3）人员计划人员计划内容如下表示。人员设计表开发阶段起止日期人数技能等方面的要求计划2011.10.222011.11.235系统分析员2人、需求管理1人、客户联络员1人、项目策划1人需求分析2011.11.

13、192011.12.286系统分析员4人、高级程序员1人、文档与配置1人概要设计2011.12.072012.01.185系统分析员3人、高级程序员2人详细设计2011.01.042.12.02.226系统分析员1人、高级程序员5人编码2012.01.202012.04.127高级程序员3人、程序员4人单元测试2012.01.072012.04.266测试员3人、高级程序员3人、程序员2人交付2012.04.292012.05.104系统分析员1人、高级程序员1人、程序员2人4）培训设计培训设计如下表。培训计划表主题人数计划日期提供者备注软件过程培训全部10天SEPG公司内部培训数据仓库2-3

14、10天CA、SAS、BVRose、UML3-45天Oracle北京、上海等地培训编程技术5-65天系统分析专家电信领域知识全部3天高级工程师软件工程原理全部5天客户或需求专家中国移动和吉林移动公司内部5）风险管理计划影响程度：5-灾难性、4-严重、3-一般、2-轻微、1-可忽略分类：BU-商业风险、CU-客户特性风险、DE-开发环境风险、TE-人员经验风险、ST-建造技术风险、PS-产品规模风险、PU-过程风险风险计划内容如下所示。风险计划图 风险因素 类别 概率 影响 RMMM 责任人 发生阶段开发的产品不再符合公司的整体 BU 5% 5 监控 高级经理 全程商业策略 人力需求估计过低 TE

15、 50% 4 监控 项目经理 详细设计与编码没有得到预算或人力上的保证 BU 50% 4 监控 项目经理 全程与BOSS开发组之间无法协调 DE 20% 4 缓解 高级经理 设计阶段复用程度低于计划 PS 65% 3 风险 软件经理 编码阶段规模估算可能和实际差别很大 PS 60% 3 监控 项目经理 设计阶段 缺少对工具的培训 DE 50% 3 缓解 项目经理 编码阶段测试和编码的具体监控难以落实 PU 40% 3 监控 项目经理 编码阶段四层结构新技术的尝试可能导致 技术力量不够 ST 30% 3 缓解 软件经理 设计编码参与人员的流动 TE 30% 3 缓解 项目经理 全程数据仓库新技术

16、的尝试不能保证 成功 ST 20% 3 缓解 项目经理 分析设计OO分析和设计新技术的尝试可能 与传统的过程冲突 ST 20% 3 缓解 项目经理 分析设计交付期限将被紧缩 BU 10% 3 监控 项目经理 全程开发人员工作的短时中断 PU 90% 2 计划 项目经理 全程与住户之间无法沟通 CU 90% 2 缓解 项目经理 需求、分析产品创建和使用的数据库很大 PS 80% 2 监控 项目经理 测试交付用户需求发生较大的改变 PS 65% 2 计划 项目经理 分析之后测试工具的欠缺不能保证测试的 效率 DE 50% 2 缓解 项目经理 测试交付交付期限不能保证产品的完整性 BU 50% 2

17、监控 项目经理 设计编码 风险因素 类别 概率 影响 RMMM 责任人 发生阶段 技术达不到预期的效果 ST 50% 2 监控 项目经理 设计开发人员不能严格遵守过程规范 PU 50% 2 监控 项目经理 全程合作者或合作关系的重大变化 DE 40% 2 缓解 高级经理 全程参与人员缺乏经验 TE 40% 2 缓解 高级经理 全程最终用户可能抵制该系统 BU 10% 1 缓解 项目经理 交付维护 6）项目技术变更管理参照组织的技术变更管理计划，具体制定本项目的技术变更管理计划，如下图所示。技术变更管理计划表新技术评估期试用期推广期EJB技术2011.11.122011.12.192011.12

18、.1OOA、OOD技术2011.102011.112011.12数据仓库技术2011.112011.122012.17）进度跟踪（1）项目会议项目会议计划采用周例会与随机会议相结合的方式。会议组织者：一般由项目经理或软件经理负责组织并实施。项目会议的时间或频度：周例会每周一次，每次定于星期五下午4：00左右。随机会议根据情况临时确定。项目会议只要内容：周例会原则上市本周工作报告和讨论问题解决方法，以及下周工作安排，随机会议视情况而定。会议记录分发的方式和范围：电子文档记录，项目经理存档并抄送部门秘书。（2）项目里程牌项目里程牌内容如下表所示。项目里程牌表里程碑时间工作产品控制时间范围变更措施计

19、划阶段完成2011.11.231、项目计划2、需求说明1-2周1、尽量避免变更，提前监控、延迟不要超过1周分析阶段完成2011.12.281、需求规格说明书1周设计阶段完成2012.2.221、概要设计书2、详细设计书3、数据库4、用户手册5、BOSS接口规范1周编码完成2012.4.121、源代码模块2、可执行模块3、程序库1周测试完成2012.4.261、单元测试报告2、项目总结报告1周（3）项目数据统计与分析按照数据采集表收集各个阶段所有相关数据，项目计划数据，开发工作量，进度与成本数据，人员数据，评审数据，测试数据，计划变更数据等。统计分析，确定项目状态及所采取的改进工作措施。（4）其

20、他跟踪项其他跟踪内容如下表所示。项目跟踪表序号跟踪项跟踪方法负责人1数据仓库合作效果定期交流监督项目经理2资产流失客户跟踪高级经理3工程和管理开销监控高级经理8、移交标准贯穿整个项目，必须在项目进行到下一阶段前达到所确定的标准，最后阶段是把产品移交给客户。1）集成测试移交标准必须在集成级得测试之前到达本移交标准。（1）提供完善可靠可供测试用的可执行文件及相关文档。（2）单元测试报告。（3）概要设计文档。（4）数据库设计文档。2）系统测试移交标准（1）提供完整可供测试用的可执行文件及相关文档。（2）系统需求规范说明书。（3）用户手册。（4）测试计划和测试方案。（5）单元测试报告。（6）集成测试报告。3）发布标准（1）完整的且版本一致的可执行程序（2）用户手册