试论软件项目管理及风险分析

试论软件项目管理及风险分析 软件项目管理的提出是在2O世纪70年代中期的美国 当时美国国防部专研究了 软件开发不能按时提交 预算超支和质量达到用户要求的原因 结果发现70 的项目 是因为管理不善引起的 而非技术原因 于是软件开发者开始逐渐重视起软件开发中 的各项管理 到了20世纪90年代中期 软件研发项日管理不善的问题仍然存在 据美 国软件工程实施现状的调查 软件研发的情况仍然很难预测 大约只有10 的项目能 够在预定的费用和进度下交付 究竟怎么样才能做好软件项目的管理及风险分析 保证项目顺利实施呢 这是个 比较复杂的问题 下面就软件项目的特点 缩合大家的经验总结 谈一点看法 1软件项目管理风险分析 软件项目管是为了使软件项目能够按照预定的成本 进度 质量顺利完成 而对 人员 产品 过程和项目进行分析和管理的活动 目的是为了让软件项目尤其是大型 项目的整个软件生命周期 从分析 设计 编码 测试 到维护全过程都能在管理者的 控制之下 以预定成本按期 按质的完成软件交付用户使用 怎样进行有效的项目管 理呢 首先我们来分析下影响软件项目的质量因素 软件项目 尤其是大型项目有二 项非常重要的因素 会影响整个项目的进度与质量 它们分别是 人 流程 与 技术 人 是项目中最难预料与掌控的一项要素 人可分成两部份 一是客户 二是开发 团队 技术 是指软件项目所使用的开发半台 主要指开发环境及开发语言 是最容 易掌握的部份 流程 是指软件开发流程或是项目流程 定义流程的目的是要掌控所有的情况 项目的最大敌人是时间及预算 这两者都是有限的 如何在有限预算内准时完成项目 可说是一项艺术 1 1 人 因素分析 人 是指客户和开发团队 其中开发团队的因素对项目影响很大 对于这方面影 响因素主要分析如下 人员技能未达到要求 在项目开始之初 我们假设项目成员都能够达到组织级的要求 但往往并不是每 个成员都能够达到要求 而且项目中每个成员的生产率差异可能很大 也给项目进度 安排造成影响 所以在项目始之初 应该对项目成员的技能进行一次总 体的评估 对于大家都欠缺的技能 应该安排统一的培训 后续需要对培训的效果 进行跟踪 对于个别人员技能欠缺的 应该单独预留自我学习时间或通过以师带徒的 方式进行培养 使其技能能够尽快达到要求 对于项目新员的工作和任务 应该加强评 审和检查 保证输出不出现大的偏差而导致后续大量的返工 对于这方影响因素主要 分析如下 项目成员责任心不强 态度决定一切 细节决定成败 对于项目过程中的各项任务 经常出现由于项目 成员责任心不强敷衍了事 导致产出的工件质量较差 引起大量返工的情况 在这种 情况下 项目更应该加强项目规范的建设 项目经理应加强同这些成员的单独沟通 加 强项目的团队建设和集体荣誉感 让项目成员感觉到做的系统是他们自己的产品 而 不是公司的项目 项目经理的项目 项目沟通问题 在软件项目中 保证项目各种角色和成员中的高效沟通是很重要的 如何建立起 快捷顺畅的沟通渠道 采用最佳的沟通方式来解决问题 必须在项目中经常强调 如 果一周的项目任务花存实际做事情上有2天 而花在沟通上却占用了3天 这时必须及 时分析和总结原因 沟通最重要的就是要在最短的时间里面 采用各种方法或工具 使交流双方或多方达成一致 项目人员流失 项目人员特别是项目关键成员在项目进行过程中的流失 对项目影响很大 对于 这种情况 应该在项目开始之初 就作为专门的风险进行跟踪 并考虑具体的应对措施 1 2 流程 因素分析 软件的开发流程般定义为 需求分析一可行性分析一概要设计一结构化设计一详细设计一编码一软件测试 一软件维护 流程 中软件项目的风险 主要体现存4个阶段 软件需求阶段 软件设计阶段 软件实现阶段和软件维护阶段 软件需求阶段 软件的开发是以用户的需求开始 在大多数情况下 用户需求要靠软件开发方诱 导 才能保证需求的完整 再以的形式形成 用户需求 这一重要的文档 需求分析更 多的是开发方确认需求的可行性和一致性的过程 在此阶段需要和用户进行广泛的 交流和确认 需求和需求分析的任何疏漏造成的损失 会在软件系 统的后续阶段被一级级地放大 因此本阶段的风险最大 软件设计阶段 设计的主要目的在于软件功能正确地反映了需求 需求的不完整和对需求分析 的不完整或者错误 在设计阶段将被成倍地放大 设计阶段的主要任务是完成系统体 系结构的定义 使之能够完成需求阶段的即定目标 另一方面也是检验需求的致性和 需求分析的完整性和正确性 设计阶段的风险主要来自于系统分析人员 分析人员存设计系统结构时过于定 制 系统的可扩展性较弱 会给后期维护带来巨大的负担和维护成本的激增 对用户 来说系统的使用比例会有明显的折扣 甚至会造成软件寿命过短 反之 软件结构的 过于灵活和通用 必然引起软件实现的难度增加 系统的复杂度上升 可靠性降低 给实 现和测试阶段带来风险 系统的稳定性也会受到影响 从另一个角度上看 用户需求 和将来软件运行环境的变化都是必然的 目前软件设计的所渭的 通用性 是否就能 很好的适应将来需求和运行环境的变化 都是需要认真折衷的 而这种折中也蕴涵着 很大的风险 设计阶段蕴涵的另一种风险来自于设计文档 文档的不健全不仅会造成实现阶 段的困难 更会在后期的测试和维护造成灾难性的后果 例如根本无法对软件系统进 行版本级 甚至是发现的简单错误都无从更正 软件实现阶段软件的实现从某种意义上讲是软件代码的生产 源代码木身也是 文档的一部分 同时它又是将来运行于计算机系统之上的实体 源代码书的规范性 可读性是该阶段的主要风险来源 规范的代码生产会把属于程序员自身个性风格的 成分引入代码的比例降到最低限度 从而减小了系统整合的风险 软件维护阶段 软件维护包含两个主要的维护阶段 一个是软件生产完毕到软件试运行阶段的 维护 这个阶段是一种实环境的测试性维护 其主要目的是发现在测试环境中不能或 末发现的问题 另一个阶段是当软件的运行不再能适应用户业务需求或是用户的运 行环境 包括硬件平台 软件环境等时进行的软件维护 具体可能是软件的版本升级 或软件移植等 1 3 技术 因素分析存软件项目开发和建设的过程中 技术因素是一个非常重要 的因素 项目组一定要本着项目的实际要求 选用合适 成熟的技术 千万不要无视项 目的实际情况选用一些虽然先进但并非项目所必须且自己又不熟悉的技术 如果项 目所要求的技术项目成员不具备或掌握不够 则需要重点关注该风险因素 2建立项目管理流程 那么如何解决这些问题呢 实际上很多模型已经给出了答案 比如RUP QoS X P等 但是大家在学习和使用这些模型的时候 往往觉得这些模型提出的概念和实施 比较难以操作 另外就是不管是RUP Q0S还是XP 既然是一个方法模型 就不可避免 要描述为一个完整的 系统化的理论模型 否则就体现不出理论的完整和逻辑的严谨 下面我们只是把以软件设计为核心的开发管理流程化 避免在频繁发生外界变化的 情况下 变被动为主动 软件项目管理除了按照既定的管理流程进行有效的控制 还要对各阶段的文档 进行标准化管理 保证文档的完整和标准化 为软件后期的维护提供有力的支持 3结束语 软件项目管理和其它的项目管理相比有相当的特殊性 首先 软件是纯知识产品 其开发进度和质量很难