|
风险评估 产品规模风险：规模越大风险越大 估算产品规模方法 产品规模估算信任度 产品规模与以前产品规模平局值的偏差 产品用户数 复用软件数量 产品需求变更量 需求风险：确定需求时都面临不确定性，早期尽量确认需求。 对产品缺少清晰的认识 对产品需求缺少认同 在做需求分析过程中客户参与不够 没有优先需求 由于不确定的需要导致新的市场 不断变化需求 缺少有效的需求变化管理过程 对需求的变化缺少相关分析 相关性风险：外部环境或因素的相关性产生的 客户供应条目或信息 交互成员或交互团体依赖性 内部或外部转包商的关系 经验丰富人员的可得性 项目的复用性 技术风险 缺乏培训 对方法、工具和技术理解的不够 应用领域的经验不足 对新的技术和开发方法应用不熟悉 管理风险 计划和任务定义不够充分 对实际项目状态不了解 项目所有者和决策者分不清 不切实际的承诺 不能与员工之间的进行充分地沟通 安全风险 软件产品本身是属于创造性的产品，产品本身的核心技术保密非常重要。 在软件这方 面的安全意识比较淡薄，对软件产品的开发主要注重技术本身，而忽略了专利的保护。 软件行业的技术人员流动是很普遍的现象，随着技术人员的流失、变更，很能会导致产品和新技术的泄密，致使我们的软件产品被它公司窃取，导致项目失败。 软件方面关于知识产权的认定目前还没有明确的一个行业规范。 规避风险方式 以开发方诱导能保证需求的完整，使需求与客户的真实期望高度一致。编写《用户需求》文档，避免疏漏造成的损失在软件系统的后续阶段被逐步地放大。 设立监督制度，项目开发中任何较大的决定都必须有客户参与进行的，在该项目中项目监督由项目开发中的质量监督组来实施。 需求变更需要经过统一的负责人提出,并且要用户需求的审核领导认可,需求变更应该是定期而不是随时的提出,而且开发方应该做好详细的记录,让客户了解需求变更的实际情况。 适当控制系统的复杂程度有利于降低开发的风险。过于简单的系统结构，对用户来使用比例会有明显的折扣，过于灵活和通用，必然引起软件实现的难度增加。 重视系统可维护性，科学的解决，不断对软件系统进行版本升级，在确保可维护性的前提下逐步扩展系统。 设定应急计划，每个开发计划都至少应该设定一个应急预案去应对出现突发情况和不可遇知的风险。 成本预算 成本预算方式 自上而下的预算方法 依据上层、中层项目管理人员的管理经验进行判断，对构成项目整体成本的子项目成本进行估计，并把这些判断估计的结果传递给低一层的管理人员 依次传递直最低一层。 存在问题 上层的管理人员根据他们的经验进行的费用估计分解到下层时，可能会出现下层人员认为上层的估计不足以完成相应任务的情况。 下层人员不一定会表达出自己的真实观点，不一定会和上层管理人员进行理智地讨论，从而得出更为合理的预算分配方案。 下层人员等待上层管理者自行发现问题并予以纠正，这样往往会给项目带来诸多问题。 自上而下更适用于项目启动的前期，与真实费用相差在30% ~ 70%之间，以最大限度容纳客户对未来产品要求所产生的变更。 自下而上的预算方法 运用WBS（Work Breakdown Structure，工作分解结构）对项目的所有工作任务的时间和预算进行仔细考察。 预算方法要求全面考虑所有涉及到的工作任务，更适用于项目的初期与中期，它能准备地评估项目的成本，与真实费用相差在5% ~ 10%之间。 注解 WBS： WBS是面向提交成果对项目的分解，从提交成果的列表可以确定每个提交成果需要执行的活动。 Scrum会对WBS进一步细化，把一个迭代分解为一个或多个的工作包，再把工作包分解为细小的开发任务（一般开发任务的开发周期在15个工作小时以内）。 确定项目支出 ：总体计算成本预算有多种计算方式综合计算开发成本： 零基数预算 ： 成本预算初期的使用零基数的计算原则。不可通过上一年总体费用+20%的方式计算新一年成本 软硬件成本 物品成本 ：例如服务器，维护，机房租金等 计算时要考虑硬件使用时长，维护人员素质，供应商质量 是否有第三方人员介入 软件许可成本 ：大型正版授权软件 外包成本：例如视频 短信 等子项目是可以考虑外包的形式完成，降低开发成本，缩短开发时间 人力资源成本：计算人力资源成本时应该使用以最高和最低的工作效率估算平均效率的方式，计算出人力资源的平均成本。 维护保养成本 客户沟通 售前注意事项：对产品的推销不应该过分承诺，有附加承诺,一定要以文本形式记录，让实施项目经理知晓并传达给项目组成员。 需求识别阶段 文本沟通：以文本记录的方式建立需要分析书，并要求客户审核需求分析书，以达到需要分析与客户的真实期望高度一致的结果。 业务逻辑沟通：提倡以草图或者可视信息化的方式进行, 针对不同层面的企业用户提供最适合的操作界面，抓住需求重点,客户方领导所关注的创新类和实用类需求。 需求变更的规范化管理 ：需求变更必须由统一的负责人提出，由用户需求的审核领导者认可。需求变更的提出应该是定期，开发方做好详细的文本记录,让客户了解需求变更的实际情况和开发方的成本代价。 方案制定阶段 与客户共同制定一个以前期明确的需求、双方的资源、项目开始的阶段、实施的时间约定、项目费用限制等为基础的具有可操作性的项目计划,从本阶段开始争取客户全面参与项目的管理，并以双方的共同利益考虑项目实施的具体计划与风险规避。 项目实施阶段 软件项目团队与客户共同领导项目的实施。项目团队应实时评估客户满意度，并通过持续改进的方式提高客户满意度，要求客户参加必要的培训，在必要时检查项目产品。出现需求变更前，主动沟通交流，使客户充分了解项目的每个环节,以及变更带来的影响,减少需求变更。如果出现客户需求变更，与客户一起共同解决由变更引起的成本、进度、质量变化。 项目结束阶段 项目成果的移交，并把系统交付给维护人员，帮助客户实现商务目标，结清各种款项。完成这些工作后应该进行项目评估，审核此项目的成果并总结项目经验。 注解 ： 软件项目中四种客户角色 明确最终使用部门和用户 ， 了解他们现有的工作方式，让用户知道项目的目标，了解项目解决部分现有工作问题，绝对不是全部困难，控制好项目范围。 明确需求的提出者，他们要能够代表最终客户群体。提出产品需求的客户具有一定的技术、业务能力和权威，能够真正代表最终客户团队的意愿和想法，能够用IT语言描述问题和需求，以利于双方的沟通、协作，避免产生歧义。 明确做需求确认的中层领导。软件开发项目是解决实际生产或者管理问题，也是领导系统建设的具体实现，做需求确认既要了解高层领导的系统建设要点和方向,又要谙熟具体业务和生产管理实际。 要明确谁来对成品提意见。项目验收环节,是项目的收尾环节，根据实践总结，由需求提出人和确认人来做项目的验收工作,能够促进项目的顺利完成,避免延期。 需求分析 需求分析过程 需求开发：对开发前期的管理，与客房的沟通过程，包括：需求获取、需求分析、编写需求和需求验证。 需求管理：就是软件项目开发过程中控制和维持需求约定的活动。包括：变更控制、版本控制、需求跟踪、需求状态跟踪。 需求层次 ：业务需求、用户需求、功能需求、非功能需求 需求开发阶段重点 业务对象 ： 项目完成后具体的使用对象 业务流程 ： 了解业务逻辑 清楚知道软件模块的职能 细化流程 分析业务逻辑 性能需求 ： 注意客户对所开发软件的技术性能指标，包括每个功能的响应时间，上传下载的速率等 环境需求 ： 软件平台运行时所处环境的要求。 硬件方面：机型、外部设备、数据通信接口 软件方面：系统软件，包括操作系统、网络软件、数据库管理系统方面 使用方面：使用人员素养，是否具备专业水准。 可靠性需求 ：开发软件在投入运行后发生故障的概率，应该按实际的运行环境提出要求。 用户界面需求 ：就是要好看和酷炫科技感 资源使用需求 ：开发的软件在运行时和开发时所需要的各种资源。包括设备资源 （服务器 网络环境 ）人员资源 ：技术顾问 等 软件成本消耗和开发进度需求 ：据合同规定，对软件开发的进度和各步骤的费用提出要求，作为开发管理的依据。 开发项目需求 ：预估系统可能达到的目标。 需求分析任务 ：借助于当前系统的逻辑模型导出目标系统的逻辑模型。 确定对系统的综合需求（功能、性能、运行、扩充需求） 制作产品需求文档(PRD) 分析系统的数据需求（概念模型、数据字典、规范化） 导出目标系统的详细的逻辑模型（数据流图、数据字典、主要功能描述） 开发原形系统 从PRD提取编制软件需求规格说明书（SRS） 【注解】SRS格式 引言 系统概述（项目背景、系统目标、核心业务流程） 术语说明 系统结构（架构图、功能图） 主体功能与业务逻辑（重点） 接口需求（内部、外部接口、第三方接口） 网络总体设计（拓扑网络、主机、组网） 运行环境（Linux、Windows、IIS、 WebLogic、Tomcat、OLAP、OLTP、JDK 8.0 、.NETFramework 4.0等） 程序设计【此部分需要兄弟自己了解，我也不够明白】 设计原则 SRP单一职责链 ：每个类都应该只负责做一件事。 OCP开封闭合原则：软件的实体（类、模块、函数等）应该是可以扩展的，但是不可修改的。 LSP替换原则 ： 子类必须能替换他们的基类型。 DIP依赖倒置原则 ：高层模块不应该依赖于低层模块，二者都应该依赖于接口与抽象类。抽象不应该依赖于细节，细节应依赖于对象。 ISP接口隔离原则 ：不应该强迫客户依赖于并未使用的接口，而应该把胖接口分离。 实现UML建模 根据SRS（软件需求说明书）等实现用况建模 实现业务顺序图，整理好开发顺序，确认模块之间的关联 建立类图，根据用况图建立对象之间的关联 绘制活动图、实现协作图、状态图 开发管理 建立项目计划 设计总体架构 ：针对系统的实际需求，采用适当且成熟的框架结构 控制可扩展度 ： 扩展度过大，将提高系统的复杂程度，延长开发时间； 扩展度过低，会直接影响系统的二次开发与维护。 控制系统的可扩展性，能提高开发效率，降低系统维护的难度。 建立基础设施 ：合理分配部署软、硬件等基础设施所需要的时间与成本 划分开发任务 利用WBS（Work Breakdown Structure，工作分解结构）对可交付结果进行分类与划分。 每个项目都能划分为多个不同阶段，每个阶段分为多个工作包（Work Package），工作包是WBS里最小的可交付结果，最后从工作包中分解出开发任务列表。 部署开发进度 一个项目应该按进度划分为多个开发阶段，每个阶段的开发周期一般在30~60个工作日以内。 此阶段内与客户举行协商会议，制定产品路线图，在开发过程中客户积极参与并提出反馈意见。 把该时段内的开发任务按照开发难度，依赖性，重要性等多方条件划分为多个迭代周期。 Scrum 敏捷软件开发原则中，应该把每个迭代任务进一步细分为多个开发任务列表，开发时间应该控制在15个工作小时以内，超出15个工作小时，应该把开发任务再度细化。 开发任务建议应该由组员自主选择，而不要使用强制分配的方式。 测试项目成果 ： 每个工作包都应该同步部署测试工作，提高项目的质量。 出错BUG，由测试人员以文本方式记录，向开发人员展示错误所在，让开发人员及时进行修改。 管理开发团队 组建团队 按照工作任务与项目时间的前提条件建立团队，按团队职责分配人员8-12人 分配开发任务 每个迭代周期内（一般是15~30个工作日），应该把每个工作包进一步细分为多个开发任务，开发任务分配给组员各自负责，开发时间应该控制在15个工作小时以内，超出要考虑细化。 监督开发进度 在迭代的前期举行一次会议，让组员了解开发的进展及流程，并以自主选择的方式分配开发任务。 组员汇报昨天已完成的开发任务，当天将要做的任务，与开发过程中所遇到的问题。 每周末举行一次例行会议，交待总体进程。 系统测试 对每个已完成的工作包进行适时的测试，保证系统质量与性能。 解决开发中所遇到的问题 对开发人员进行前期培训，可适当按工作能力分配任务 当遇到问题时在当天的即时提出，并在15个工作小时内解决所遇到的问题。 监管产品质量 质量需要，计划、设计而并非审查的。项目初期，与QA部门进行协商，以正式文档的方式，决定质量策略和标准。 在开发过程中使用TDD（测试驱动开发）的模式，提高开发质量。测试以文本方式记录bug，与开发人员共同工作，把缺陷演示给开发人员，以提高修改的效率。 每个迭代进行一次产品效果的演示，从客户、使用者、高层领导中收集反馈信息。在团队内部举行评审会议，分析测试结果，了解产品性能。 修改项目计划 产品需求识别阶段，以文档形式记录产品功能与开发流程，在开发计划需要修改时，与客户共同探讨，让其了解计划修改对项目进度所造成的影响。 项目计划修改由统一的负责人提出，由用户需求的审核领导者认可。 需求变更的提出应该是定期而不是随时的。 计划的变更应该做好详细的文本记录，了解需求变更的实际情况和为之所付出的成本代价。 产品交付 项目的后期审核 ： 项目进行后期的审核，分析项目成果、项目团队的效率、可交付产品的价值，以此审核结果可作为项目管理经验总结的一部分。 质量评审： 项目交给相关的“质量保证”（QA）部门进行质量评审，请典型用户感受产品的质量。 项目的最终交付 项目的前期会订立项目交付的协议，项目交付方式分为非正式验收与正式验收两种。 项目完成后会先进行非正式验收，让客户体会项目的质量，提出反馈意见， 客户肯定产品质量，以书面协议的形式进行正式的产品验收。 项目的最终报告 最初引进项目时的初期项目视图 对该项目的价值评估及支持性信息 项目的范围 项目的开发流程及WBS 项目的会议记录 项目变更的报告及变更的理由 与项目相关的沟通过程文件 项目的审核报告与客户验收报告 项目成员的表现报告 项目的最终成果 | 
收藏
淘帖
踩
