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

《软件工程项目管理思考及探索》由会员分享，可在线阅读，更多相关《软件工程项目管理思考及探索（58页珍藏版）》请在金锄头文库上搜索。

1、软件工程项目管理思考及探索软件工程项目管理思考及探索主讲人：主讲人：冯旭鹏部部 门：门：信息技术科日日 期：期：2013.10.31主要内容主要内容引言引言软件工程软件工程软件项目管理软件项目管理昆工软件项目管理思考昆工软件项目管理思考内容总结内容总结23引言引言 工作中遇到的问题工作中遇到的问题 “软件危机软件危机”现象现象软件工程软件工程4工作概述工作概述 建设“校园信息化”信息资源管理平台 建设和完善重点应用系统 .5我们所遇到的共性问题我们所遇到的共性问题 产品质量问题产品质量问题 项目进度问题项目进度问题 产品与要求相差甚远 没有提高工作效率，反而增加了繁琐的业务 一旦用户增多，性能

2、就变得非常差 交付的产品存在隐患，公司“钓鱼”，故意留下漏洞 . 公司拖拉，项目进度缓慢，而且总有各种托辞的借口与理由案例案例：教务处排课系统缺陷四六级报名系统缺陷. 公司研发人员态度差，难于沟通 出现问题时，互相扯皮 .6“软件危机软件危机”现象现象 危害严重危害严重 典型表现典型表现 伦敦地铁，司机没上车，地铁就驶离站台 丹佛机场行李系统，延期16个月，成本超出32亿美元 Ariane5，40秒爆炸，损失50亿美元 . 程序质量低下 错误频出 进度延误 费用剧增 . 软件危机软件危机 泛指在计算机软件的开发和维护过程中开发和维护过程中所遇到的一系列严重问题一系列严重问题。 软件软件危机不可

3、避免，也没有根治的途径危机不可避免，也没有根治的途径 要解决软件危机，需进行系统性的研究要解决软件危机，需进行系统性的研究 项目建设，项目建设，“知己知彼，百战不殆知己知彼，百战不殆”7利器利器 软件工程软件工程 软件工程（Software Engineering，SE） 一门集计算机科学、数学、逻辑学及管理学为一体的学科，意在通过借鉴传统工程的原则、方法，来进行软件开发的管理，从而提高软件质量、降低软件成本和改进软件性能。8软件工程软件工程 学科发展概述学科发展概述 学科知识体系学科知识体系 学科框架学科框架9软件工程发展概述软件工程发展概述 诞生诞生 定义定义 软件工程就是软件工程就是采用

4、工程的概念、原理、技术和方法采用工程的概念、原理、技术和方法来开发与维护软来开发与维护软件，把经过时间考验而证明正确的件，把经过时间考验而证明正确的管理方法和先进软件技术管理方法和先进软件技术结合起来，结合起来，运用到软件开发和维护过程中，来运用到软件开发和维护过程中，来解决软件危机解决软件危机。 思想思想 以系统性的、规范化的、可定量的过程化方法去开发和维护软件 使用经过时间考验而证明正确的管理技术 1968年，北大西洋公约组织（NATO）举办了软件工程学术会议，首次提出10软件工程知识体系软件工程知识体系含10个知识域，8个学科由软件工程协调委员会(SWECC)于2008年确立的版本。11

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

6、发过程中必须遵循的原则。过程中必须遵循的原则。12 软件工程的软件工程的“四项基本原则四项基本原则” 原则三：提供高质量的工程支持。原则三：提供高质量的工程支持。 原则二：采用合适的设计方法。原则二：采用合适的设计方法。 “工欲善其事，必先利其器”。软件工具与环境对软件过程的支持颇为重要。 软件设计中，通常要考虑软件的模块化、抽象与信息隐蔽、局部化、一致性以及适应性等特征 原则一：选取适宜的开发范型。原则一：选取适宜的开发范型。 原则四：重视软件开发过程的管理。原则四：重视软件开发过程的管理。原则四：重视软件开发过程的管理。原则四：重视软件开发过程的管理。 软件需求、硬件需求以及其他因素之间是

7、相互制约、相互影响的，经常需要权衡。必须认识需求定义的易变性必须认识需求定义的易变性，采用适宜的开发范型予以控制。 软件工程的管理，直接影响可用资源的有效利用，生产满足目标的软件产品，提高软件组织的生产能力等问题。因此，仅当软件过程得以有效管理时，才能实现有效的软件工程。13 软件生命周期软件生命周期软件生命周期软件生命周期(Systems Development Life Cycle，SDLC) 问题的定义及规划 需求分析 软件设计 程序编码 软件测试 运行维护六个阶段六个阶段14软件项目开发及管理全过程软件项目开发及管理全过程15软件项目管理流程软件项目管理流程立项阶段立项阶段项目验收阶段

8、项目验收阶段 判断验收时机已经成熟 验收流程的优化后续服务及维护条款项目执行阶段项目执行阶段经验总结阶段经验总结阶段 制定项目建议书、可行性分析、产品调研、承包商选择技巧 招投标方式 合同上关于风险应对及责任明晰等内容制定 工作计划 质量监管、测试方案 进度监管16软件项目管理软件项目管理 项目管理复杂性分析项目管理复杂性分析 软件开发过程模型概述软件开发过程模型概述 软件项目管理流程软件项目管理流程 各阶段需要注意的事项各阶段需要注意的事项17软件项目管理的复杂之处软件项目管理的复杂之处 软件产品是智力产品，软件项目是设计型项目软件产品是智力产品，软件项目是设计型项目 “隔行如隔山隔行如隔山

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

10、过程决定了软件建设的步骤与我们管理的方式 过程直接影响最终产品的质量 软件开发过程模型软件开发过程模型 瀑布模型 快速原型模型 增量模型 构件组装模型 螺旋模型19软件过程模型软件过程模型瀑布模型瀑布模型( (Waterfall-model) ) 思想思想 软件开发划分阶段 各阶段顺序执行 特征特征 最早的、最简单的模型 “理想化”的顺序模型 单向性，工作不可逆转 优点优点 为项目提供分阶段的检查点当前活动完成，只需关注后续活动 模板清晰 缺点缺点 抵抗“需求不断变化”能力弱。 用户最终才能见产品，增加开发风险。 开发人员常常陷入“阻塞状态” 各阶段划分完全固定，产生大量文档，增加工作量。 由

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

12、小代价、快速构建一个软件的“雏形” 根据用户反馈不断调整，最终确定产品 优点优点 开发方可快速对需求有明晰认识 能有效应对需求变化，降低风险 缺点缺点 快速建立起来的原型系统可能架构脆弱，不断修改，导致产品低下 建立快速原型的主要目的是快速获取与验证需求！建立快速原型的主要目的是快速获取与验证需求！22软件过程模型软件过程模型基于组件的开发模型基于组件的开发模型 思想：软件复用思想：软件复用 23软件过程模型软件过程模型螺旋模型螺旋模型( (Spiral Model) ) 思想思想 施工前先进行风险评估，通过后快速开发出原型，交由用户评估 沿螺旋线自内向外每旋转一圈，意味着开发出更加完善的版本

13、 特征特征 瀑布模型和快速原型模型的联合体 适用于大型复杂项目，有效控制风险 由 Boehm于1988年提出 缺点缺点 需要较高的风险评估技术 风险分析费用高，增加成本 应用较复杂24 软件过程模型使用总结软件过程模型使用总结 需求明确瀑布模型； 用户无信息系统使用经验，需求分析人员技能不足 快速原型模型 需求不确定因素多，无法提前计划 采用增量迭代和螺旋模型 资金和成本无法一次到位 增量模型，软件产品分多个版本进行发行 全新系统的开发 必须在总体设计完成后再开始增量或并行 编码人员经验较少 建议不要采用敏捷或迭代等生命周期模型 增量,迭代和原型可以综合使用,但每一次增量或迭代都必须有明确的交

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

15、理流程软件项目管理流程立项阶段立项阶段项目验收阶段项目验收阶段 判断验收时机已经成熟 验收流程的优化后续服务及维护条款项目执行阶段项目执行阶段经验总结阶段经验总结阶段 制定项目建议书、可行性分析、产品调研、承包商选择技巧 招投标方式 合同上关于风险应对及责任明晰等内容制定 工作计划 质量监管、测试方案 进度监管28立项阶段立项阶段 方向比努力更重要方向比努力更重要第一步：项目建议书第一步：项目建议书 项目背景。 意义和必要性。 未来收益预期。 规模和期限。 投资估算。 资金筹措。 其他重要意见。提交项目建议书给相关部门进行审核，提交项目建议书给相关部门进行审核，“上会上会”29第二步：项目可行

16、性分析第二步：项目可行性分析立项阶段立项阶段 需求分析需求分析。项目的背景、项目的目标、业务需求、概要设计。 技术可行性分析。 经济可行性分析。我们预算多少，硬件方面需要多少投资。 主要风险分析。 人员配置及项目实施计划人员配置及项目实施计划。 可行性研究的结论和建议。 其他重要意见。30立项阶段立项阶段需求的基本标准需求的基本标准需求管理的误区需求管理的误区 开发分析阶段，开发方与客户只需要在轮廓上达成基本一致即可，具体细节以后再填充。 软件项目需求可以持续不断地改变。实践表明，随着开发进度的推进，实现软件需求更改所需的代价呈指数形式增长。 仅仅满足目前需求即可，不考虑未来几年的状况。u准确

17、界定系统的目标和范围准确界定系统的目标和范围 完整、正确 可行、必要 划分优先级 无二义性、可验证坚持需求的审查坚持需求的审查对部分重要需求进行追踪对部分重要需求进行追踪31立项阶段立项阶段 技术技术 开发能力如何？技术方案是否满意？ 管理管理 内部组织是否混乱？ 进度进度 开发进度是否可以接受？ 经验经验 是否有相关领域、相似产品的开发经验、以前开发的产品质量如何？ 诚信度诚信度 信誉、口碑如何？采用“一票否决制” 资质资质是否取得业界认可证书（如ISO9000质量认证、CMM认证），证书等级后续服务后续服务能否提供较好的开发及维护服务 经济实用性经济实用性性价比如何？ 其他因素其他因素比如

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

19、可能提前预估风险，制定应对方案。33项目策划阶段项目策划阶段 工作量估计工作量估计。 寻找寻找关键路径关键路径。通过定义各任务之间的依赖关系，计算出项目中的关键路径，帮助区分任务的轻重缓急，合理安排和调整资源，从而保证项目的整体进度。软件项目主管的任务软件项目主管的任务“排兵布阵排兵布阵”37目标：进度快、投资省、质量好。目标：进度快、投资省、质量好。项目执行阶段项目执行阶段 进度快就要增加投资，而项目提前使用却又可能及早提高收益。 进度快，质量也许就不能保证；质量严格控制，则有可能影响进度；质量严格控制不至返工，又会加快进度。 “脱离成本，不谈质量”。项目负责人的任务项目负责人的任务进度、成

20、本、质量、风险、人力资源等等。进度、成本、质量进度、成本、质量对立统一对立统一关系关系成本除了资金成本，还有人力成本，资金少，就多付出些汗水。项目执行阶段项目执行阶段进度管理进度管理(1)(1)39进度的描述进度的描述 里程碑 做完、没做完，没有第三种状态 甘特图40甘特图示例甘特图示例项目执行阶段项目执行阶段进度管理进度管理(2)(2)41影响进度的主要因素影响进度的主要因素 错估了项目特点及实现条件。 项目参与者工作错误。 不可预见事件发生。面对进度延迟，我们该怎么做呢？分析主客观原因，对症下药！项目执行阶段项目执行阶段进度管理进度管理(3)(3)42客观原因客观原因 进度计划不合理，过于

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

22、巧 延迟如果不补救，就会呈加速度扩展。 如果没有很好的办法，那就辛苦一点，最笨的办法是“紧盯”。 “防患于未然”，影响进度的许多因素，我们争取在立项时就要充分考虑到。项目执行阶段项目执行阶段质量管理质量管理(1)(1)44软件质量度量因素软件质量度量因素 正确性正确性精确地满足需求的程度 健壮性健壮性容错能力，恢复能力 可靠性可靠性误差累积、代码缺陷，突然不正常 性能性能“时间-空间”效率，速度快、占用资源少 易用性易用性用户友好性 清晰性清晰性使用文档详实、易懂 可扩展性可扩展性适应变化的能力，模块化功能改进项目执行阶段项目执行阶段质量管理质量管理( (2 2) )45棘手的棘手的问题问题

23、大多数公司不认真关注质量，只想尽快通过“验收”。 “钓鱼”现象存在。如何保证质量？如何保证质量？3大原则大原则 缺陷预防。“零缺陷管理”，“质量是做出来的，不是测出来的”。 重在过程。每个阶段都要严格组织，责任到人，多层把关。 严格审查。“测试驱动开发”，并发数，压力测试等等。作为甲方，我们作为甲方，我们需要需要注意注意 分阶段质量把控 验收时结合业务进行多种手段的测试。 “试行期”要尽量发现更多问题。项目验收项目验收阶段阶段(1)(1)46验收前提验收前提 完成合同要求的全部内容。 在“试运行”期间已完成对软件系统的严格测试（白盒、黑盒）。 准备好相关的开发文档和产品文档。 准备好软件安装和

24、验收的部署环境。 相关使用人员的培训工作完成。验收内容验收内容 功能检测。 质量鉴定。 资料评审。 后续维护工作的一些协商。可以内部先拟定一个详细的验收计划可以内部先拟定一个详细的验收计划项目验收项目验收阶段阶段(2)(2)47验收流程验收流程验收报告验收报告 验收小组拟定。 基本情况的各项审核。 一些相关的合理性建议。 初审。 复审。项目总结项目总结阶段阶段48项目实施过程回顾项目实施过程回顾 工作或过程的扼要评价 问题的跟踪情况 变更的管理 突发事件和突发冲突的处理从经验中学习从经验中学习 一定要实事求是！ 着眼点要准确，分析要深入！ 不要回避、隐瞒问题和矛盾！ 要有主次之分，条理要清晰。

25、项目总结交流会项目总结交流会 经验教训汇总 棘手难题汇总，如何应对展开讨论 各抒己见，分享体会 一些改进和建议方案的汇总49昆工软件项目管理思考昆工软件项目管理思考 昆工软件项目立项流程图昆工软件项目立项流程图 每个环节都注意哪些每个环节都注意哪些立项阶段立项阶段(1)(1)51 成熟产品修改？定制开发？优劣利害对比成熟产品修改？定制开发？优劣利害对比 选择选择合适的软件开发过程合适的软件开发过程l重视项目的可行性分析重视项目的可行性分析需求分析格外重要，要尽可能丰富地收集业务方的实际需求需求分析格外重要，要尽可能丰富地收集业务方的实际需求技术可行性、经济可行性等方面要技术可行性、经济可行性等

26、方面要客观客观考量考量 可能遇到的风险问题要及早预期可能遇到的风险问题要及早预期多参照相关利益人征集项目建设意见多参照相关利益人征集项目建设意见u选取合适的项目建设方式选取合适的项目建设方式立项阶段立项阶段(2)(2)52l考量软件承包商或开发团队所关注的因素考量软件承包商或开发团队所关注的因素 尽量考虑开发过程中进度、质量等方面的干扰因素，制定规章条例尽量考虑开发过程中进度、质量等方面的干扰因素，制定规章条例尽可能提前预估风险，制定应对方案。尽可能提前预估风险，制定应对方案。u合同签署，明晰管理章程合同签署，明晰管理章程技术、管理、进度、技术、管理、进度、 经验、诚信度、资质、经验、诚信度、

27、资质、 后续服务、经济实用性后续服务、经济实用性其他因素其他因素l项目启动仪式项目启动仪式建立良好的沟通渠道建立良好的沟通渠道项目建设阶段项目建设阶段(1)(1)53l详实准确的需求分析详实准确的需求分析u尽可能准确界定系统的目标和范围尽可能准确界定系统的目标和范围标准：完整、正确、可行、必要、划分优先级、无二义性、可验证标准：完整、正确、可行、必要、划分优先级、无二义性、可验证发现问题及时沟通，坚持需求审查发现问题及时沟通，坚持需求审查对部分重要需求制定跟踪对部分重要需求制定跟踪u加强沟通加强沟通 结合自身的专业技术知识与开发人员多加强交流沟通结合自身的专业技术知识与开发人员多加强交流沟通

28、互相学习互相学习项目建设阶段项目建设阶段(2)(2)54l进度管理进度管理u质量管理质量管理可能影响进度的风险因素要在可能影响进度的风险因素要在立项时就尽可能考虑到立项时就尽可能考虑到，规定解决方案，规定解决方案项目实施过程中，从专业技术的角度，借助于里程碑等方法，尽可能项目实施过程中，从专业技术的角度，借助于里程碑等方法，尽可能详实地去把握项目进度详实地去把握项目进度进度出现延迟时，要认真分析相应的主客观原因，对症下药进度出现延迟时，要认真分析相应的主客观原因，对症下药 “质量是做出来的，不是测出来的质量是做出来的，不是测出来的”，要加强质量缺陷预防，要加强质量缺陷预防 重在过程管理，各阶段

29、进行严格审查重在过程管理，各阶段进行严格审查 设定软件设定软件“试行期试行期”，通过实践检验发现质量问题，通过实践检验发现质量问题 从专业技术角度分析可能存在的质量隐患，尽量避免从专业技术角度分析可能存在的质量隐患，尽量避免“公司钓鱼公司钓鱼”项目验收阶段项目验收阶段55l认真调研，准确判断验收时机是否成熟认真调研，准确判断验收时机是否成熟u验收流程的优化验收流程的优化 是否已经满足了合同要求的全部内容 是否进行了认真的白盒、黑盒测试，发现的问题是否已全部解决 软件安装和部署是否运行完成，运行稳定 相关使用人员的培训工作已经完成 内部先拟定比较详实的验收方案 初步验收、复审验收u验收内容验收内容 软件功能、性能、质量是否达标 操作文档、部署资料是否齐全u后续服务的一些洽谈后续服务的一些洽谈56项目总结阶段项目总结阶段 问题跟踪情况总结 突发事件应对情况的总结从经验中学习从经验中学习 经验教训汇总 实事求是 不回避、隐瞒问题和矛盾l认真回顾项目的实施过程认真回顾项目的实施过程u召开项目总结交流会召开项目总结交流会57报告内容总结报告内容总结软件危机软件危机 VS VS 软件工程软件工程软件开发过程软件开发过程软件项目管理软件项目管理昆工软件项目管理方案昆工软件项目管理方案 感谢各位老师！感谢各位老师！恳请不吝指正！恳请不吝指正！