软件工程项目管理思考及探索

1. 软件工程项目管理思考及探索 主讲人：冯旭鹏 部 门：信息技术科 日 期：2013.10.31

2. 主要内容 • 引言 • 软件工程 • 软件项目管理 • 昆工软件项目管理思考 • 内容总结 2

3. 工作中遇到的问题 • “软件危机”现象 • 《软件工程》 引言 3

4. 工作概述 • 建设“校园信息化”信息资源管理平台 • 建设和完善重点应用系统 • ...... 4

5. 我们所遇到的共性问题 • 项目进度问题 • 公司拖拉，项目进度缓慢，而且总有各种托辞的借口与理由 • 公司研发人员态度差，难于沟通 • 出现问题时，互相扯皮 • ...... 案例： 教务处排课系统缺陷 四六级报名系统缺陷 ...... • 产品质量问题 • 产品与要求相差甚远 • 没有提高工作效率，反而增加了繁琐的业务 • 一旦用户增多，性能就变得非常差 • 交付的产品存在隐患，公司“钓鱼”，故意留下漏洞 • ...... 5

6. “软件危机”现象 • 软件危机 • 泛指在计算机软件的开发和维护过程中所遇到的一系列严重问题。 • 典型表现 • 危害严重 • 伦敦地铁，司机没上车，地铁就驶离站台 • 丹佛机场行李系统，延期16个月，成本超出32亿美元 • Ariane5，40秒爆炸，损失50亿美元 • ...... • 程序质量低下 • 错误频出 • 进度延误 • 费用剧增 • ...... • 软件危机不可避免，也没有根治的途径 • 要解决软件危机，需进行系统性的研究 • 项目建设，“知己知彼，百战不殆” 6

7. 利器 ——《软件工程》 《软件工程（Software Engineering，SE）》—— 一门集计算机科学、数学、逻辑学及管理学为一体的学科，意在通过借鉴传统工程的原则、方法，来进行软件开发的管理，从而提高软件质量、降低软件成本和改进软件性能。 7

8. 软件工程 • 学科发展概述 • 学科知识体系 • 学科框架 8

9. 《软件工程》发展概述 • 定义 软件工程就是采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理方法和先进软件技术结合起来，运用到软件开发和维护过程中，来解决软件危机。 • 诞生 • 1968年，北大西洋公约组织（NATO）举办了软件工程学术会议，首次提出 • 思想 • 以系统性的、规范化的、可定量的过程化方法去开发和维护软件 • 使用经过时间考验而证明正确的管理技术 9

10. 《软件工程》知识体系 由软件工程协调委员会(SWECC)于2008年确立的版本。 含10个知识域，8个学科 10

11. 软件工程框架 • 软件工程框架可概括为：目标、过程和原则。 • 目标：生产具有正确性、可用性以及开销合宜的软件产品 • 正确性——满足用户的各项功能需求 • 可用性——软件及其使用文档方便为用户使用 • 开销合宜——软件开发及运行的各项开销能够被用户接受 • 过程：生产目标产品所需要的步骤 • 软件工程过程主要包括开发过程、运作过程、维护过程。 • 软件工程过程覆盖了需求分析、设计、实现、确认以及维护等活动。 • 原则：围绕工程设计、工程支持以及工程管理在软件开发过程中必须遵循的原则。 11

12. 软件工程的“四项基本原则” • 原则一：选取适宜的开发范型。 • 软件需求、硬件需求以及其他因素之间是相互制约、相互影响的，经常需要权衡。必须认识需求定义的易变性，采用适宜的开发范型予以控制。 • 原则二：采用合适的设计方法。 • 软件设计中，通常要考虑软件的模块化、抽象与信息隐蔽、局部化、一致性以及适应性等特征 • 原则三：提供高质量的工程支持。 • “工欲善其事，必先利其器”。软件工具与环境对软件过程的支持颇为重要。 • 原则四：重视软件开发过程的管理。 • 软件工程的管理，直接影响可用资源的有效利用，生产满足目标的软件产品，提高软件组织的生产能力等问题。因此，仅当软件过程得以有效管理时，才能实现有效的软件工程。 12

13. 软件生命周期 • 软件生命周期(Systems Development Life Cycle，SDLC) • 问题的定义及规划 • 需求分析 • 软件设计 • 程序编码 • 软件测试 • 运行维护 六个阶段 13

14. 软件项目开发及管理全过程 14

15. 软件项目管理流程 • 制定项目建议书、可行性分析、产品调研、承包商选择技巧 • 招投标方式 • 合同上关于风险应对及责任明晰等内容制定 • 项目执行阶段 • 工作计划 • 质量监管、测试方案 • 进度监管 • 项目验收阶段 • 判断验收时机已经成熟 • 验收流程的优化 • 后续服务及维护条款 • 经验总结阶段 立项阶段 15

16. 软件项目管理 • 项目管理复杂性分析 • 软件开发过程模型概述 • 软件项目管理流程 • 各阶段需要注意的事项 16

17. 软件项目管理的复杂之处 • 软件产品是智力产品，软件项目是设计型项目 • “隔行如隔山” • 软件使用方在提业务需求时往往不能足够重视 • 需求变化频繁，变更难以控制 • 难以估算工作量 • 开发进度难以界定 • 交付成果难以明确 • 对开发人员依赖性大 • 承建商主要目的是利润，只想提供最少的功能、一定的质量，并在合理时间内完成 • 为达到更高利润，承建商可能对项目进行二次外包，管理更混乱 • …… 17

18. 软件开发过程 • 重视软件开发过程 • 过程决定了软件建设的步骤与我们管理的方式 • 过程直接影响最终产品的质量 • 软件开发过程模型 • 瀑布模型 • 快速原型模型 • 增量模型 • 构件组装模型 • 螺旋模型 18

19. 软件过程模型——瀑布模型(Waterfall-model) • 思想 • 软件开发划分阶段 • 各阶段顺序执行 —— 由 Royce 于1970年提出 • 特征 • 最早的、最简单的模型 • “理想化”的顺序模型 • 单向性，工作不可逆转 • 缺点 • 抵抗“需求不断变化”能力弱。 • 用户最终才能见产品，增加开发风险。 • 开发人员常常陷入“阻塞状态” • 各阶段划分完全固定，产生大量文档，增加工作量。 • 优点 • 为项目提供分阶段的检查点 • 当前活动完成，只需关注后续活动 • 模板清晰 19

20. 软件过程模型——增量模型(incremental model) • 思想 • 特征 • 功能拆分，每个子功能按瀑布模型开发 • 最终合并所有“增量” • 分模块开发 • 多段瀑布模型 ——举例：字处理软件 • 优点 • 抗变化能力比瀑布模型强 • 可以边开发，边应用 • 缺点 • 所有子系统合并可能“不兼容” • 对系统设计师的水平要求高 解决方法：面向接口的编程方法 适用于：小型或是交互型式的系统。大型系统的某些部分，例如用户界面。 20

21. 软件过程模型——快速原型模型(rapid prototype) • 思想 • 根据需求先较小代价、快速构建一个软件的“雏形” • 根据用户反馈不断调整，最终确定产品 • 优点 • 开发方可快速对需求有明晰认识 • 能有效应对需求变化，降低风险 • 缺点 • 快速建立起来的原型系统可能架构脆弱，不断修改，导致产品低下 —— 建立快速原型的主要目的是快速获取与验证需求！ 21

22. 软件过程模型——基于组件的开发模型 • 思想：软件复用 22

23. 软件过程模型——螺旋模型(Spiral Model) • 思想 • 施工前先进行风险评估，通过后快速开发出原型，交由用户评估 • 沿螺旋线自内向外每旋转一圈，意味着开发出更加完善的版本 —— 由 Boehm于1988年提出 • 特征 • 瀑布模型和快速原型模型的联合体 • 适用于大型复杂项目，有效控制风险 • 缺点 • 需要较高的风险评估技术 • 风险分析费用高，增加成本 • 应用较复杂 23

24. 软件过程模型使用总结 • 需求明确——瀑布模型； • 用户无信息系统使用经验，需求分析人员技能不足 —— 快速原型模型 • 需求不确定因素多，无法提前计划 —— 采用增量迭代和螺旋模型 • 资金和成本无法一次到位 —— 增量模型，软件产品分多个版本进行发行 • 全新系统的开发 —— 必须在总体设计完成后再开始增量或并行 • 编码人员经验较少 —— 建议不要采用敏捷或迭代等生命周期模型 • 增量,迭代和原型可以综合使用,但每一次增量或迭代都必须有明确的交付和出口准则 24

25. “哪种过程模型更好用？” • 比较 • 瀑布模型 • 增量模型 • 快速原型模型 • 螺旋模型 • 瀑布模型最简单，但抗需求变化能力最弱 • 增量模型分模块开发，子系统集成怕不兼容 • 快速原型模型能最快实现需求一致性 • 螺旋模型一般只有大型公司或大型项目采用 不要太在乎学术上的“先进”与“落后”，适用的就最好。 我们最常见的系统都是采用增量模型、快速原型模型来开发。 当前对软件研发过程质量的评判主要是以SEI（Software Engineering Institute） 颁布的CMMI（Capability Maturity Model Integration）作为研发标准。 25

26. 软件项目管理流程 • 制定项目建议书、可行性分析、产品调研、承包商选择技巧 • 招投标方式 • 合同上关于风险应对及责任明晰等内容制定 • 项目执行阶段 • 工作计划 • 质量监管、测试方案 • 进度监管 • 项目验收阶段 • 判断验收时机已经成熟 • 验收流程的优化 • 后续服务及维护条款 • 经验总结阶段 立项阶段 26

27. 立项阶段 ——方向比努力更重要 • 第一步：项目建议书 • 项目背景。 • 意义和必要性。 • 未来收益预期。 • 规模和期限。 • 投资估算。 • 资金筹措。 • 其他重要意见。 提交项目建议书给相关部门进行审核，“上会” 28

28. 立项阶段 • 需求分析。项目的背景、项目的目标、业务需求、概要设计。 • 技术可行性分析。 • 经济可行性分析。我们预算多少，硬件方面需要多少投资。 • 主要风险分析。 • 人员配置及项目实施计划。 • 可行性研究的结论和建议。 • 其他重要意见。 第二步：项目可行性分析 29

29. 立项阶段 • 需求的基本标准 • 完整、正确 • 可行、必要 • 划分优先级 • 无二义性、可验证 • 对部分重要需求进行追踪 • 坚持需求的审查 • 准确界定系统的目标和范围 • 需求管理的误区 • 开发分析阶段，开发方与客户只需要在轮廓上达成基本一致即可，具体细节以后再填充。 • 软件项目需求可以持续不断地改变。——实践表明，随着开发进度的推进，实现软件需求更改所需的代价呈指数形式增长。 • 仅仅满足目前需求即可，不考虑未来几年的状况。 30

30. 立项阶段 • 选择软件供应商考虑因素 • 技术——开发能力如何？技术方案是否满意？ • 管理——内部组织是否混乱？ • 进度—— 开发进度是否可以接受？ • 经验—— 是否有相关领域、相似产品的开发经验、以前开发的产品质量如何？ • 诚信度 ——信誉、口碑如何？采用“一票否决制” • 资质——是否取得业界认可证书（如ISO9000质量认证、CMM认证），证书等级 • 后续服务——能否提供较好的开发及维护服务 • 经济实用性——性价比如何？ • 其他因素——比如地理位置等 CMM五个等级 31

31. 立项阶段 • 第三步：专家组评审《可行性分析报告》 专门的技术人员、软件最终使用者涉及到的相关利益主体。 案例：教务处排课系统对多媒体教室管理带来的影响。 • 考虑到后续开发过程中进度、质量等方面的干扰因素，制定规章条例。 • 尽可能提前预估风险，制定应对方案。 • 第五步：项目启动仪式——“磨刀不误砍柴工”。 • 不仅仅是形式，启动是为了形成一个良好的沟通体系，让所有项目人员都理解项目重要性，同时明晰职责，保障项目管理的畅通。 第四步：合同签署，明晰管理章程。 32

32. 项目策划阶段 • 软件项目主管的任务——“排兵布阵” • 工作量估计。 • 寻找关键路径。通过定义各任务之间的依赖关系，计算出项目中的关键路径，帮助区分任务的轻重缓急，合理安排和调整资源，从而保证项目的整体进度。 33

36. 项目执行阶段 • 项目负责人的任务 进度、成本、质量、风险、人力资源等等。 • 进度、成本、质量——对立统一关系 • 进度快就要增加投资，而项目提前使用却又可能及早提高收益。 • 进度快，质量也许就不能保证；质量严格控制，则有可能影响进度；质量严格控制不至返工，又会加快进度。 • “脱离成本，不谈质量”。 成本除了资金成本，还有人力成本，资金少，就多付出些汗水。 目标：进度快、投资省、质量好。 37

37. 项目执行阶段——进度管理(1) • 里程碑 ——做完、没做完，没有第三种状态 • 甘特图 进度的描述 39

38. 甘特图示例 40

39. 项目执行阶段——进度管理(2) • 影响进度的主要因素 • 错估了项目特点及实现条件。 • 项目参与者工作错误。 • 不可预见事件发生。 面对进度延迟，我们该怎么做呢？——分析主客观原因，对症下药！ 41

40. 项目执行阶段——进度管理(3) • 应对措施 • 进度计划不合理，过于理想化等 • 任务定义过于复杂、过度定义、超出范围 • 测试太多错误而延迟 • 意外发生(比如停电、开发人员生病等) • 使用方需求变更 ——重新定义进度计划 ——重新定义任务，舍弃过难技术问题 ——万不可为了赶进度而降低测试标准！ ——按风险管理中制定的应急措施处理 ——核心/关键功能的里程碑事件定义 • 主观原因 • 应对措施 ——生活原因？多多沟通、绩效考核 ——有针对性地进行经验交流和培训 ——依赖性强的任务合并！ ——“用人不疑、疑人不用” • 开发人员没有全神贯注于自己的工作。 • 开发人员不恰当的工作方式。 • 任务定义依赖性强，人员工作之间扯皮。 • 项目经理过多干预开发人员工作。 客观原因 42

41. 项目执行阶段——进度管理(4) • 延迟如果不补救，就会呈加速度扩展。 • 如果没有很好的办法，那就辛苦一点，最笨的办法是“紧盯”。 • “防患于未然”，影响进度的许多因素，我们争取在立项时就要充分考虑到。 技巧 43

42. 项目执行阶段——质量管理(1) • 正确性——精确地满足需求的程度 • 健壮性——容错能力，恢复能力 • 可靠性——误差累积、代码缺陷，突然不正常 • 性能——“时间-空间”效率，速度快、占用资源少 • 易用性——用户友好性 • 清晰性——使用文档详实、易懂 • 可扩展性——适应变化的能力，模块化功能改进 软件质量度量因素 44

43. 项目执行阶段——质量管理(2) • 大多数公司不认真关注质量，只想尽快通过“验收”。 • “钓鱼”现象存在。 • 如何保证质量？——3大原则 • 缺陷预防。“零缺陷管理”，“质量是做出来的，不是测出来的”。 • 重在过程。每个阶段都要严格组织，责任到人，多层把关。 • 严格审查。“测试驱动开发”，并发数，压力测试等等。 • 作为甲方，我们需要注意 • 分阶段质量把控 • 验收时结合业务进行多种手段的测试。 • “试行期”要尽量发现更多问题。 棘手的问题 45

44. 项目验收阶段(1) • 完成合同要求的全部内容。 • 在“试运行”期间已完成对软件系统的严格测试（白盒、黑盒）。 • 准备好相关的开发文档和产品文档。 • 准备好软件安装和验收的部署环境。 • 相关使用人员的培训工作完成。 • 验收内容 可以内部先拟定一个详细的验收计划 • 功能检测。 • 质量鉴定。 • 资料评审。 • 后续维护工作的一些协商。 验收前提 46

45. 项目验收阶段(2) • 验收流程 • 初审。 • 复审。 • 验收报告 • 验收小组拟定。 • 基本情况的各项审核。 • 一些相关的合理性建议。 47

46. 项目总结阶段 • 工作或过程的扼要评价 • 问题的跟踪情况 • 变更的管理 • 突发事件和突发冲突的处理 项目总结交流会 • 从经验中学习 • 一定要实事求是！ • 着眼点要准确，分析要深入！ • 不要回避、隐瞒问题和矛盾！ • 要有主次之分，条理要清晰。 • 经验教训汇总 • 棘手难题汇总，如何应对展开讨论 • 各抒己见，分享体会 • 一些改进和建议方案的汇总 项目实施过程回顾 48

47. 昆工软件项目管理思考 昆工软件项目立项流程图 每个环节都注意哪些 49

49. 立项阶段(1) • 重视项目的可行性分析 • 需求分析格外重要，要尽可能丰富地收集业务方的实际需求 • 技术可行性、经济可行性等方面要客观考量 • 可能遇到的风险问题要及早预期 • 多参照相关利益人征集项目建设意见 • 选取合适的项目建设方式 • 成熟产品修改？定制开发？优劣利害对比 • 选择合适的软件开发过程 51

50. 立项阶段(2) • 考量软件承包商或开发团队所关注的因素 • 技术、管理、进度、 经验、诚信度、资质、 后续服务、经济实用性 • 其他因素 • 合同签署，明晰管理章程 • 尽量考虑开发过程中进度、质量等方面的干扰因素，制定规章条例 • 尽可能提前预估风险，制定应对方案。 • 项目启动仪式——建立良好的沟通渠道 52