软件项目管理计划

软件项目管理计划 [景区售票]软件系统 项目管理计划 Version 1.0 [组名]伤得起！！！ [组长] 李雷（1080310601） [成员] 朱文龙（1080310608） 何明刚（1080310615） 郭伟龙（1080310621） 本报告由小组四人共同完成 1、​ 第一、二章由朱文龙完成 2、​ 第三章由李雷完成 3、​ 第四章由何明刚完成 4、​ 第五章由郭伟龙完成 文档信息 项目名称：[景区售票]软件系统 小组名称：伤得起！！！ 项目负责人：李雷 文档负责人：朱文龙 编制日期：2011.04.21 版本：Version 1.0 文档分工（姓名） 负责内容 朱文龙 文档的主要框架和起草、更新 何明刚 文档的更新 修改记录 日期 版本 修改说明 修改者 2011.04.21 1.0 文档的起草和构建 朱文龙 2011.6.18 1.1 3.1 3.2 5.3 资源需求 李雷 2011．6.19 1.2 5.1 5.2 5.4 5.5 郭伟龙 朱文龙 目录 TOC \o "1-3" \h \z \u 1. 简介 4 1.1 项目概述 4 1.2 项目交付产品 4 1.3 SPMP 的演化 4 1.4 参考资料 4 1.5 术语与缩写 4 2. 项目组织 5 2.1 过程模型 5 2.2 组织结构 5 2.3 组织接口 5 2.4 项目职责 5 3.管理过程 7 3.1 管理目标和优先级 7 3.2 假设、依赖关系和限制 7 3.3 风险管理 7 3.4 监督和控制机制 7 3.5 人员计划 8 4. 技术过程 9 4.1 方法 快递客服问题件处理详细方法山木方法pdf计算方法pdf华与华方法下载八字理论方法下载 、工具和技术 9 4.2 软件文档 9 4.3 用户文档 9 4.4 项目支持功能 9 5.工作包、进度表和预算 10 5.1 工作包 10 5.2 依赖关系 10 5.3 资源需求 10 5.4 预算 10 5.5 资源分配和进度表 10 1. 简介 1.1 项目概述 1.1.1 项目目标 随着我国城市旅游业的快速发展，人们生活水平的提高，对旅游行业形象管理方面要求不断提高。传统的人工模式已显得陈旧和落后，旅游景区的售检票系统已经不再是以前那种人工的，复杂的，工作量大的售票检票系统，而是一种电子化的新型系统。 建立旅游景区售检票系统，不仅使景区的管理水平有了提高，同时也相应地完善了旅游景区的 管理制度 档案管理制度下载食品安全管理制度下载三类维修管理制度下载财务管理制度免费下载安全设施管理制度下载 。这种系统极大的方便的管理员的管理和查询等操作。为管理者提供决策支持数据，以便及时地发现问题，合理安排日常业务工作，制定新的资金投入和计划。这种电子化工作模式避免了人工操作造成的失误，提高了工作效率和质量，从而也提高了经济效益。 “伤得起”小组计划开发的“景区售票系统”，预计可以实现景区门票的查询，购买，投诉，咨询四项基本功能供消费者使用，以及管理员的日常维护功能。 初步开发成形的系统具备基本的使用功能，初步的界面设计，使用测试案例尚不完备，具有客户端和网页版两种以供选择。 1.1.2 开发目的 缓解旅游景区的售检票的人力压力，提供高效的，快节的，稳定的操作。实现系统应具有实用性、可靠性、有效性及方便性。 软件工程实践课开发系统可以提高成员的动手能力，深刻理解软件工程的美妙之处。 1.1.3 工作进度 一般软件开发时间： 第一个短周期内要完成计划和 分析 定性数据统计分析pdf销售业绩分析模板建筑结构震害分析销售进度分析表京东商城竞争战略分析 工作（2%--3%，10%--15%）； 第二个短周期要完成设计工作（20%--25%）； 第三个短周期基本完成开发工作（15%--20%）； 剩余时间全部投入测试工作（30%--40%）。 依据软件工程课程要求模拟的时间进程为： 时间 项目 2011年春节学期 5周 6周 7周 8周 9周 10周 11周 12周 13周 14周 15周 项目规划与准备 项目分析 项目设计 项目实施 项目试运行 项目测试 项目验收 1.1.4 主要工作活动 系统开发的主要工作活动包括开发前对系统开发环境，背景和开发目的的探究，初步拟定可以实现的功能和应该具备的属性。 系统重点开发阶段为代码编写与测试，应占据大部分时间。 系统每个阶段都要进行文档的编写以及不断的跟进、更写。小组成员有专人负责文档的维护。 系统开发最后阶段设计测试数据进行测试。进行除错以及美化界面，增强程序的健壮性。 1.1.5 关键里程碑 主要里程碑： 1、​ 需求规格书的确定 2、​ 系统架构的完成 3、​ 程序测试的完成 4、​ 系统交付使用 1.2 项目交付产品 最终交付源代码、系统文件、文档资料等可供定量检查的资料。 1.2.1 产品所需满足的系统需求 1．产品界面友好，操作简单。 2. 及时保存信息和相关操作记录。 3. 保证一定的执行效率。 4. 能够实现各处的售票系统信息联动，保证最新的售票信息。 1.3 SPMP 的演化 文档的构建和起草由朱文龙负责； 文档的更新由朱文龙和何明刚共同完成； 按进程和各项工作实际情况适时变更文档的更新机制。 1.4 参考资料 [1]《软件工程：实践者的研究方法（第6版）》.作者：（美）Roger S.Pressman.2007年1月. [2]《软件工程实用教程(计算机应用技术规划教材)》. 作者：吕云翔. 2011年1月. [3]《软件工程方法与实践》.作者：窦万峰.2009年5月. 1.5 术语与缩写 尚未商议。 2. 项目组织 2.1 过程模型 2.1.2 采用瀑布式开发模型： 2.1.2选择瀑布式模型的原因 瀑布式模型是经典的软件开发模型，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。 为项目提供了按阶段划分的检查点，可以根据里程碑似的时间节点对软件工程的进程进行跟踪和验收，完成了前一阶段内容，即可关注下一阶段的工作，便于集中精力，尽量减少反复开发修复，造成工作效率的降低。 在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。 2.1.3 本项目的过程模型 重要的时间节点红色字体标出！ 时间 项目 2011年春节学期 5周 6周 7周 8周 9周 10周 11周 12周 13周 14周 15周 项目规划与准备 项目分析 项目设计 项目实施 项目试运行 项目测试 项目验收 2.1.4 交付的产品和标志 最终的产品交付以可实际运行的软件系统和说明文件，在课程结束前一周结束产品开发。 结束标志为用户可以正常使用系统，并基本没有错误。并定期按用户需求和实际情况进行更新。 2.2 组织结构 2.3 组织接口 表 1 项目接口 组织 联系人 联系信息 客户：景区 @@@ ### 分包商：<名称> @@@ ### 软件质量保证 @@@ ### 软件配置管理 @@@ ### …… @@@ ### 2.4 项目职责 角色 职责描述 负责人员 项目经理 领导项目团队，执行和管理项目，负责项目的交付工作 李雷（1080310601） 开发人员 负责具体项目进程的实施，代码的编写，程序的测试等。 朱文龙（1080310608） 李雷（1080310601） 郭伟龙（1080310621） 何明刚（108310615） 表 2 项目职责 秘书 协调各方进行沟通和监督各项进程 朱文龙（1080310608） 3.管理过程 3.1 管理目标和优先级 基本原则：由于团队人员较少，每位成员多项分工，既要具体到程序的编写 和调试，又要有整体协调的能力。项目经理和执行秘书负责协调客 户需求和项目进程。各成员互相监督，高效有序的完成系统开发。 目标 A：团队的最高目标是在预定时间内完成产品的基本功能开发，并能基本可以交付客户使用。 目标 B：要按时更新文档和最好记录便于后续的维护。 目标 C：能够保证一定的系统运行效率，保证安全性。 目标D：工作分工明确，接口衔接顺畅，经常沟通确定进程和需要解决的问题。 目标E：提高系统性能与功能，增加系统的寿命 3.2 假设、依赖关系和限制 ［说明：描述所有对项目外部的问题和事件所做的假设，以及由这些问题和事件引起的限制。］ 编号 项目外部问题 限制 1 客户要求的交付时间过早 不能够完成所有的模块开发 2 服务器数据库与软件需求不符 要改变软件数据库设计，不能及时完成软件网络部署 3 硬件器材如检票器等到货较晚 推迟硬件接口的开发，前期只能完成软件模拟 4 客户提出新的需求 开发新的组件，推迟项目交付时间 5 客户违约 终止项目进程，或寻找新的客户 6 资金链断裂 员工积极性受挫，开发进度严重受影响甚至停止 3.3 风险管理 表 3 项目风险 编号 风险描述 风险类型 概率 影响程度 后果 缓解策略 1 开发人员技术水平难以满足预期要求 产品规模 40% 灾难的 开发进程停滞 在开发的过程中不断学习 ２ 系统的规模预算不准确 产品规模 30% 严重的 交付时间推迟，开发人员为做好长期准备 适当的精简不必要的系统设计 ３ 交付日期推迟 商业影响 50% 严重的 发生违约风险 经常与客户沟通 ４ 用户改变起初的需求 产品规模 60% 轻微的 重新设计某些部分 经常与客户沟通 ５ 缺少对开发中所使用工具的培训 开发环境 20% 可忽略的 开始阶段进度缓慢 不断进行相关的培训 ６ 人员变动频繁 人员 60% 严重的 交付时间推迟，效率下降 相近的最好文本的维护，便于新进人员了解 风险 详细描述 1 开发人员技术水平难以满足预期要求 同学们实际开发经验少，技术水品有限，不能满足需要 ２ 系统的规模预算不准确 没有实际的开发经验，对工作量估计不准 ３ 交付日期推迟 工作效率低，没有经验，人员变动等等因素均会导致 ４ 用户改变起初的需求 用户随着实际工作改变一部分需求是正常的 ５ 缺少对开发中所使用工具的培训 时间紧张，人员少，没有培训人员 ６ 人员变动频繁 由于课业压力、实习外出等，某些同学可能中途退出 3.4 监督和控制机制 3.4.1 报告机制： A.​ 小组各成员每天将工作进展整理成电子文档交给文档维护员进行文档维护。 B.​ 定期举行例会，共同探讨项目进展中的问题，并做好会议记录。 C.​ 项目经理和执行秘书密切关注项目的各期进展，确保按时交付使用。并确保风险在可控范围内。 3.4.2 报告格式： 报告主题，时间段，发现人，报告内容，审核意见 3.4.3 评审机制： 提出问题，大家共同解决。一致通过，并做记录。项目经理制定下一阶段工作目标和执行进程，执行秘书严格监督。 3.5 人员计划 人员类型 人数 技能要求 所需培训 培训方式 C++程序员 3 熟悉C++编程和微软.Net平台 C++编程 小组学习 数据库程序员 3 熟悉SQL语句，熟练使用SQL Sever 2005 SQL语句 小组学习 界面程序员 2 熟悉CSS、Photoshop、.Net平台 CSS、Photoshop、.Net平台 自学 文档维护员 1 熟悉使用Word及Powerpoint Word及Powerpoint 自学 软件测试人员 2 熟练使用开发工具的debug工具，有耐性 debug工具 小组学习 执行秘书 1 较强的沟通能力，能及时调解组内以及组与组之间的矛盾 无 无 4. 技术过程 4.1 方法、工具和技术 4.1.1编程语言：C++ 4.1.2所需技术：SqlSever 2005、Windows .Net 4.1.3执行标准：采用业内通用的方式进行文件命名、代码版式、注释等。 4.1.3软件的交付过程：由相关的程序员交付代码，测试人员进行测试，并集体讨论合格之后即可交付。 4.2​ 软件文档 1、设计报告初稿 在总体设计阶段，小组根据需求规格说明文档，完成软件体系结构的设计， 由组编写软件体系结构设计文档初稿，并在后续开发阶段补充和更新。 该文档由文档维护员负责维护更新。 2、 测试文档 在软件开发阶段，测试人员需要编写测试规格说明文档，并在后续测试阶 段更新。开发人员将根据测试规格说明文档建立测试环境、准备测试数据。 ３. 个人项目总结 由组内成员各自独立完成，对开发过程中获得的工作经验进总结。在提 交系统时一并提交。 ４. 其他文档 软件开发过程中的其他文档，如开发日志（按组员意见选择公开与否）， 风险报告及其处理意见等，由秘书进行整理与汇聚。作为以后软件开发以及 交流的经验。 4.3 用户文档 在更新用需求分析阶段，测试人员需要开始着手编写用户文档，并在需求 析结束后需要形成初稿；在后续阶段不断由文档维护员户文档；并在系统交 付阶段随着系统一起被交付。 5.工作包、进度表和预算 5.1 工作包 ［说明：将项目分解为工作包（活动和任务），并对工作包详细描述］ 任务 活动 详细描述 1.​ 项目准备 (项目管理计划) 1.1 形成项目小组 有效的组织与管理各类资源(例如人)，以使项目能够在预定的范围、质量、时间和成本等约束条件下顺利交付 1.2 系统 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 选定 1.3 制定软件项目管理计划 1.4 建立配置管理环境和开发环境 1.​ 需求分析 （需求规格说明） 2.1 建立用例模型，动态、静态模型 对需求进行分析，满足业务需求、用户需求、系统需求 2.2 编写需求规格说明 2.3 评审需求需求规格 2.4 修改需求规格说明 2.5 获得开战后续工作批准 2.6 需求分析工作完成 1.​ 总体设计 （软件设计） 3.1 审阅需求规格说明 分析模型，对工程进行总体设计，实现界面初步设计 3.2 完成界面设计文档 3.3 评审界面设计文档 3.4 修改设计文档 3.5 获得开战后续工作批准 3.6 初步设计工作完成 1.​ 软件开发 4.1 审阅总体设计文档 代码实现软件功能的开发 4.2 确定模块化或分层参数 4.3 分配任务给开发团体人员 4.4 编写代码 4.5 开发人员测试（调试） 4.6 开发工作完成 1.​ 集成与测试 5.1 模块交易 测试产品 5.2 建立集成系统 5.3 测试系统 5.4 修改代码，完善功能 5.5 重新集成测试 5.6​ 整体测试完成 1.​ 交付 6.1 准备安装程序 交付总结 6.2 系统演示 6.3 递交文档、代码和产品 6.4 总结经验教训 6.5 交付完成 5.2 依赖关系 ［说明：描述工作包之间的次序关系，目的是解决这些工具包之间的互相依赖关系和对外部事件的依赖性。］ 待定 5.3 资源需求 [ 说明：提供完成项目所需的全部资源，包括人员、支持软件、计算机硬件、办公室和实验室设备以及项目资源维护需求的数目和类型等。］ 人员：伤得起!!!小组软件项目开发成员 支持软件的开发环境： Microsoft Visual Studio 2008 Microsoft Office word 2010 Microsoft Office visio 2010 Visual Assist X UmlStar MYSQL5.1 Adobe Dreamweaver CS5 Apache2 Adobe Photoshop CS5 Adobe Illustrater CS5 Adobe Reader X 开发地点：凉爽的宿舍或者有空调的机房 实验设备：个人PC 机、笔记本电脑、实验室PC 机 项目资源维护需求的数目和类型：3台个人电脑 5.4 预算 ［说明：估算项目的工作量和成本。分别按问题分解（LOC或FP）和过程分解估算工作量和总成本，参见 课件 超市陈列培训课件免费下载搭石ppt课件免费下载公安保密教育课件下载病媒生物防治课件 可下载高中数学必修四课件打包下载 ］ STEP 1：计算未调整功能点 功能点(Function Point, FP)，以功能点为单位来估计软件 规模，关注五个方面的功能： – 外部输入(EI)：用户进行添加或修改数据的UI – 外部输出(EO)：软件为用户产生的输出UI – 外部查询(EQ)：软件可产生的独立查询 – 内部逻辑文件(ILF)：软件修改或保存的逻辑记录集合(数据表或文件) – 外部接口(EIF)：与其它系统进行信息交换或共享的文件 P = (a+4m+b)/6 P 估算值 a 乐观值 b 悲观值 m 可能值 FP = r ×P r 加权因子 FP 总成本 STEP 2：估计调整因子 技术因素 影响值 技术因素 影响值 备份与恢复 4 内部处理复杂度 5 数据通信 2 设计可复用代码 4 分布式处理 0 设计中的转换与安装 3 关键性能 4 多次安装 5 现有操作环境 3 易于变更的应用设计 5 联机数据输入 4 多屏幕输入切换 5 主文件联机更新 3 信息域值复杂度 5 K = 0.65 + 0.01*(F1+F2+… …+F14) = 1.17 STEP 3：计算调整功能点和总成本 FP 1 = 320 * 1.17 = 375 平均生产率(v)：6.5FP/pm 月平均工资：3000元 每个FP的成本(u)：1000元 总成本(C)：C=FP*u=375*1230=375000元 总工作量(PM)：PM=FP/v=375/6.5=58 5.5 资源分配和进度表 ［说明：用甘特图（MS Project）描述项目任务,依赖关系、人员、时间段等。］ 进度表（Gantt Chart）： 人员/资源分配图：