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

软件工程项目管理思考及探索主讲人：冯旭鹏部门：信息技术科日期：2013.10.31软件工程项目管理思考及探索主讲人：冯旭鹏主要内容引言软件工程软件项目管理昆工软件项目管理思考内容总结2主要内容引言23引言工作中遇到的问题

“软件危机”现象《软件工程》3引言工作中遇到的问题4工作概述建设“校园信息化”信息资源管理平台建设和完善重点应用系统......4工作概述建设“校园信息化”信息资源管理平台5我们所遇到的共性问题产品质量问题

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

典型表现

伦敦地铁，司机没上车，地铁就驶离站台丹佛机场行李系统，延期16个月，成本超出32亿美元Ariane5，40秒爆炸，损失50亿美元......

程序质量低下错误频出进度延误费用剧增......软件危机泛指在计算机软件的开发和维护过程中所遇到的一系列严重问题。软件危机不可避免，也没有根治的途径

要解决软件危机，需进行系统性的研究项目建设，“知己知彼，百战不殆”6“软件危机”现象危害严重典型表现伦7利器——《软件工程》

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

学科知识体系

学科框架8软件工程学科发展概述9《软件工程》发展概述

诞生

定义

软件工程就是采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理方法和先进软件技术结合起来，运用到软件开发和维护过程中，来解决软件危机。思想以系统性的、规范化的、可定量的过程化方法去开发和维护软件使用经过时间考验而证明正确的管理技术

1968年，北大西洋公约组织（NATO）举办了软件工程学术会议，首次提出9《软件工程》发展概述诞生定义10《软件工程》知识体系含10个知识域，8个学科由软件工程协调委员会(SWECC)于2008年确立的版本。10《软件工程》知识体系含10个知识域，8个学科由软件工程协11软件工程框架

过程：生产目标产品所需要的步骤

目标：生产具有正确性、可用性以及开销合宜的软件产品

软件工程过程主要包括开发过程、运作过程、维护过程。软件工程过程覆盖了需求分析、设计、实现、确认以及维护等活动。正确性——满足用户的各项功能需求可用性——软件及其使用文档方便为用户使用开销合宜——软件开发及运行的各项开销能够被用户接受

软件工程框架可概括为：目标、过程和原则。

原则：围绕工程设计、工程支持以及工程管理在软件开发过程中必须遵循的原则。11软件工程框架过程：生产目标产品所需要的步骤目12软件工程的“四项基本原则”

原则三：提供高质量的工程支持。

原则二：采用合适的设计方法。“工欲善其事，必先利其器”。软件工具与环境对软件过程的支持颇为重要。软件设计中，通常要考虑软件的模块化、抽象与信息隐蔽、局部化、一致性以及适应性等特征

原则一：选取适宜的开发范型。

原则四：重视软件开发过程的管理。

软件需求、硬件需求以及其他因素之间是相互制约、相互影响的，经常需要权衡。必须认识需求定义的易变性，采用适宜的开发范型予以控制。软件工程的管理，直接影响可用资源的有效利用，生产满足目标的软件产品，提高软件组织的生产能力等问题。因此，仅当软件过程得以有效管理时，才能实现有效的软件工程。12软件工程的“四项基本原则”原则三：提供高质量的工程支13软件生命周期软件生命周期(SystemsDevelopmentLifeCycle，SDLC)

问题的定义及规划需求分析软件设计程序编码软件测试运行维护六个阶段13软件生命周期软件生命周期(SystemsDevelo14软件项目开发及管理全过程14软件项目开发及管理全过程15软件项目管理流程立项阶段项目验收阶段判断验收时机已经成熟验收流程的优化后续服务及维护条款项目执行阶段经验总结阶段

制定项目建议书、可行性分析、产品调研、承包商选择技巧招投标方式

合同上关于风险应对及责任明晰等内容制定

工作计划质量监管、测试方案

进度监管15软件项目管理流程立项阶段项目验收阶段判断验收时机已经成16软件项目管理项目管理复杂性分析

软件开发过程模型概述

软件项目管理流程

各阶段需要注意的事项16软件项目管理项目管理复杂性分析17软件项目管理的复杂之处

软件产品是智力产品，软件项目是设计型项目

“隔行如隔山”软件使用方在提业务需求时往往不能足够重视需求变化频繁，变更难以控制难以估算工作量

开发进度难以界定交付成果难以明确

对开发人员依赖性大

承建商主要目的是利润，只想提供最少的功能、一定的质量，并在合理时间内完成

为达到更高利润，承建商可能对项目进行二次外包，管理更混乱

……17软件项目管理的复杂之处软件产品是智力产品，软件项目是设18软件开发过程

重视软件开发过程

过程决定了软件建设的步骤与我们管理的方式

过程直接影响最终产品的质量软件开发过程模型瀑布模型快速原型模型增量模型构件组装模型螺旋模型18软件开发过程重视软件开发过程过程决定了19软件过程模型——瀑布模型(Waterfall-model)

思想

软件开发划分阶段各阶段顺序执行

特征

最早的、最简单的模型“理想化”的顺序模型单向性，工作不可逆转

优点

为项目提供分阶段的检查点当前活动完成，只需关注后续活动模板清晰

缺点

抵抗“需求不断变化”能力弱。用户最终才能见产品，增加开发风险。开发人员常常陷入“阻塞状态”各阶段划分完全固定，产生大量文档，增加工作量。——由Royce于1970年提出19软件过程模型——瀑布模型(Waterfall-model20软件过程模型——增量模型(incrementalmodel)

思想

功能拆分，每个子功能按瀑布模型开发最终合并所有“增量”

特征

分模块开发多段瀑布模型

优点

抗变化能力比瀑布模型强可以边开发，边应用

缺点

所有子系统合并可能“不兼容”对系统设计师的水平要求高——举例：字处理软件解决方法：面向接口的编程方法适用于：小型或是交互型式的系统。大型系统的某些部分，例如用户界面。20软件过程模型——增量模型(incrementalmod21软件过程模型——快速原型模型(rapidprototype)

思想

根据需求先较小代价、快速构建一个软件的“雏形”根据用户反馈不断调整，最终确定产品

优点

开发方可快速对需求有明晰认识能有效应对需求变化，降低风险

缺点

快速建立起来的原型系统可能架构脆弱，不断修改，导致产品低下——建立快速原型的主要目的是快速获取与验证需求！21软件过程模型——快速原型模型(rapidprototy22软件过程模型——基于组件的开发模型

思想：软件复用

22软件过程模型——基于组件的开发模型思想：软件复用23软件过程模型——螺旋模型(SpiralModel)

思想

施工前先进行风险评估，通过后快速开发出原型，交由用户评估沿螺旋线自内向外每旋转一圈，意味着开发出更加完善的版本

特征

瀑布模型和快速原型模型的联合体适用于大型复杂项目，有效控制风险——由Boehm于1988年提出

缺点

需要较高的风险评估技术风险分析费用高，增加成本应用较复杂23软件过程模型——螺旋模型(SpiralModel)思24软件过程模型使用总结

需求明确——瀑布模型；

用户无信息系统使用经验，需求分析人员技能不足——快速原型模型

需求不确定因素多，无法提前计划——采用增量迭代和螺旋模型资金和成本无法一次到位——增量模型，软件产品分多个版本进行发行全新系统的开发——必须在总体设计完成后再开始增量或并行编码人员经验较少——建议不要采用敏捷或迭代等生命周期模型

增量,迭代和原型可以综合使用,但每一次增量或迭代都必须有明确的交付和出口准则24软件过程模型使用总结需求明确——瀑布模型；25“哪种过程模型更好用？”

比较

瀑布模型最简单，但抗需求变化能力最弱增量模型分模块开发，子系统集成怕不兼容快速原型模型能最快实现需求一致性螺旋模型一般只有大型公司或大型项目采用不要太在乎学术上的“先进”与“落后”，适用的就最好。瀑布模型

增量模型快速原型模型螺旋模型我们最常见的系统都是采用增量模型、快速原型模型来开发。当前对软件研发过程质量的评判主要是以SEI（SoftwareEngineeringInstitute）颁布的CMMI（CapabilityMaturityModelIntegration）作为研发标准。25“哪种过程模型更好用？”比较瀑布模型最简单，但抗26软件项目管理流程立项阶段项目验收阶段判断验收时机已经成熟验收流程的优化后续服务及维护条款项目执行阶段经验总结阶段

制定项目建议书、可行性分析、产品调研、承包商选择技巧招投标方式

合同上关于风险应对及责任明晰等内容制定

工作计划质量监管、测试方案

进度监管26软件项目管理流程立项阶段项目验收阶段判断验收时机已经成软件工程项目管理思考及探索课件28立项阶段——方向比努力更重要第一步：项目建议书

项目背景。

意义和必要性。

未来收益预期。

规模和期限。

投资估算。

资金筹措。

其他重要意见。提交项目建议书给相关部门进行审核，“上会”28立项阶段——方向比努力更重要第一步：项目建议书项目背29第二步：项目可行性分析立项阶段

需求分析。项目的背景、项目的目标、业务需求、概要设计。

技术可行性分析。

经济可行性分析。我们预算多少，硬件方面需要多少投资。

主要风险分析。

人员配置及项目实施计划。

可行性研究的结论和建议。

其他重要意见。29第二步：项目可行性分析立项阶段需求分析。项目的背景、项30立项阶段需求的基本标准需求管理的误区

开发分析阶段，开发方与客户只需要在轮廓上达成基本一致即可，具体细节以后再填充。软件项目需求可以持续不断地改变。——实践表明，随着开发进度的推进，实现软件需求更改所需的代价呈指数形式增长。

仅仅满足目前需求即可，不考虑未来几年的状况。准确界定系统的目标和范围完整、正确

可行、必要

划分优先级

无二义性、可验证坚持需求的审查对部分重要需求进行追踪30立项阶段需求的基本标准需求管理的误区开发分析阶段，开发31立项阶段

技术

——开发能力如何？技术方案是否满意？

管理

——内部组织是否混乱？

进度——开发进度是否可以接受？

经验——是否有相关领域、相似产品的开发经验、以前开发的产品质量如何？

诚信度——信誉、口碑如何？采用“一票否决制”

资质——是否取得业界认可证书（如ISO9000质量认证、CMM认证），证书等级后续服务——能否提供较好的开发及维护服务经济实用性——性价比如何？

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

尽可能提前预估风险，制定应对方案。32第四步：合同签署，明晰管理章程。立项阶段第三步：专家组评33项目策划阶段

工作量估计。

寻找关键路径。通过定义各任务之间的依赖关系，计算出项目中的关键路径，帮助区分任务的轻重缓急，合理安排和调整资源，从而保证项目的整体进度。软件项目主管的任务——“排兵布阵”33项目策划阶段工作量估计。软件项目主管的任务——“排兵布软件工程项目管理思考及探索课件软件工程项目管理思考及探索课件软件工程项目管理思考及探索课件37目标：进度快、投资省、质量好。项目执行阶段进度快就要增加投资，而项目提前使用却又可能及早提高收益。

进度快，质量也许就不能保证；质量严格控制，则有可能影响进度；质量严格控制不至返工，又会加快进度。“脱离成本，不谈质量”。项目负责人的任务进度、成本、质量、风险、人力资源等等。进度、成本、质量——对立统一关系成本除了资金成本，还有人力成本，资金少，就多付出些汗水。37目标：进度快、投资省、质量好。项目执行阶段进度快就要增3838项目执行阶段——进度管理(1)39进度的描述里程碑——做完、没做完，没有第三种状态甘特图项目执行阶段——进度管理(1)39进度的描述里程碑——做40甘特图示例40甘特图示例项目执行阶段——进度管理(2)41影响进度的主要因素错估了项目特点及实现条件。项目参与者工作错误。不可预见事件发生。面对进度延迟，我们该怎么做呢？——分析主客观原因，对症下药！项目执行阶段——进度管理(2)41影响进度的主要因素错估了项目执行阶段——进度管理(3)42客观原因进度计划不合理，过于理想化等任务定义过于复杂、过度定义、超出范围测试太多错误而延迟意外发生(比如停电、开发人员生病等)

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

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

正确性——精确地满足需求的程度

健壮性——容错能力，恢复能力

可靠性——误差累积、代码缺陷，突然不正常

性能——“时间-空间”效率，速度快、占用资源少

易用性——用户友好性

清晰性——使用文档详实、易懂

可扩展性——适应变化的能力，模块化功能改进项目执行阶段——质量管理(1)44软件质量度量因素正确性项目执行阶段——质量管理(2)45棘手的问题大多数公司不认真关注质量，只想尽快通过“验收”。“钓鱼”现象存在。如何保证质量？——3大原则缺陷预防。“零缺陷管理”，“质量是做出来的，不是测出来的”。重在过程。每个阶段都要严格组织，责任到人，多层把关。严格审查。“测试驱动开发”，并发数，压力测试等等。作为甲方，我们需要注意分阶段质量把控

验收时结合业务进行多种手段的测试。“试行期”要尽量发现更多问题。项目执行阶段——质量管理(2)45棘手的问题大多数公司不认项目验收阶段(1)46验收前提完成合同要求的全部内容。在“试运行”期间已完成对软件系统的严格测试（白盒、黑盒）。准备好相关的开发文档和产品文档。准备好软件安装和验收的部署环境。相关使用人员的培训工作完成。验收内容功能检测。质量鉴定。资料评审。

后续维护工作的一些协商。可以内部先拟定一个详细的验收计划项目验收阶段(1)46验收前提完成合同要求的全部内容。验收项目验收阶段(2)47验收流程验收报告验收小组拟定。基本情况的各项审核。一些相关的合理性建议。初审。复审。项目验收阶段(2)47验收流程验收报告验收小组拟定。初审项目总结阶段48项目实施过程回顾工作或过程的扼要评价问题的跟踪情况变更的管理突发事件和突发冲突的处理从经验中学习一定要实事求是！着眼点要准确，分析要深入！不要回避、隐瞒问题和矛盾！要有主次之分，条理要清晰。项目总结交流会经验教训汇总棘手难题汇总，如何应对展开讨论各抒己见，分享体会一些改进和建议方案的汇总项目总结阶段48项目实施过程回顾工作或过程的扼要评价从经验49昆工软件项目管理思考昆工软件项目立项流程图

每个环节都注意哪些49昆工软件项目管理思考昆工软件项目立项流程图软件工程项目管理思考及探索课件立项阶段(1)51成熟产品修改？定制开发？优劣利害对比选择合适的软件开发过程重视项目的可行性分析需求分析格外重要，要尽可能丰富地收集业务方的实际需求技术可行性、经济可行性等方面要客观考量

可能遇到的风险问题要及早预期多参照相关利益人征集项目建设意见选取合适的项目建设方式立项阶段(1)51成熟产品修改？定制开发？优劣利害对比重视立项阶段(2)52考量软件承包商或开发团队所关注的因素尽量考虑开发过程中进度、质量等方面的干扰因素，制定规章条例尽可能提前预估风险，制定应对方案。合同签署，明晰管理章程技术、管理、进度、经验、诚信度、资质、后续服务、经济实用性其他因素项目启动仪式——建立良好的沟通渠道立项阶段(2)52考量软件承包商或开发团队所关注的因素尽量项目建设阶段(1)53详实准确的需求分析尽可能准确界定系统的目标和范围标准：完整、正确、可行、必要、划分优先级、无二义性、可验证发现问题及时沟通，坚持需求审查对部分重要需求制定跟踪加强沟通结合自身的专业技术知识与开发人员多加强交流沟通

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

设定软件“试行期”，通过实践检验发现质量问题

从专业技术角度分析可能存在的质量隐患，尽量避免“公司钓鱼”项目建设阶段(2)54进度管理质量管理可能影响进度的风险因素项目验收阶段55认真调研，准确判断验收时机是否成熟验收流程的优化是否已经满足了合同要求的全部内容是否进行了认真的白盒、黑盒测试，发现的问题是否已全部解决软件安装和部署是否运行完成，运行稳定相关使用人员的培训工作已经完成

内部先拟定比较详实的验收方案

初步验收、复审验收验收内容

软件功能、性能、质量是否达标

操作文档、部署资料是否齐全后续服务的一些洽谈项目验收阶段55认真调研，准确判断验收时机是否成熟验收流程的56项目总结阶段问题跟踪情况总结突发事件应对情况的总结从经验中学习经验教训汇总实事求是不回避、隐瞒问题和矛盾认真回顾项目的实施过程召开项目总结交流会56项目总结阶段问题跟踪情况总结从经验中学习经验教训汇总57报告内容总结软件危机VS软件工程软件开发过程软件项目管理昆工软件项目管理方案57报告内容总结软件危机VS软件工程感谢各位老师！恳请不吝指正！感谢各位老师！软件工程项目管理思考及探索主讲人：冯旭鹏部门：信息技术科日期：2013.10.31软件工程项目管理思考及探索主讲人：冯旭鹏主要内容引言软件工程软件项目管理昆工软件项目管理思考内容总结60主要内容引言261引言工作中遇到的问题

“软件危机”现象《软件工程》3引言工作中遇到的问题62工作概述建设“校园信息化”信息资源管理平台建设和完善重点应用系统......4工作概述建设“校园信息化”信息资源管理平台63我们所遇到的共性问题产品质量问题

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

典型表现

伦敦地铁，司机没上车，地铁就驶离站台丹佛机场行李系统，延期16个月，成本超出32亿美元Ariane5，40秒爆炸，损失50亿美元......

程序质量低下错误频出进度延误费用剧增......软件危机泛指在计算机软件的开发和维护过程中所遇到的一系列严重问题。软件危机不可避免，也没有根治的途径

要解决软件危机，需进行系统性的研究项目建设，“知己知彼，百战不殆”6“软件危机”现象危害严重典型表现伦65利器——《软件工程》

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

学科知识体系

学科框架8软件工程学科发展概述67《软件工程》发展概述

诞生

定义

软件工程就是采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理方法和先进软件技术结合起来，运用到软件开发和维护过程中，来解决软件危机。思想以系统性的、规范化的、可定量的过程化方法去开发和维护软件使用经过时间考验而证明正确的管理技术

1968年，北大西洋公约组织（NATO）举办了软件工程学术会议，首次提出9《软件工程》发展概述诞生定义68《软件工程》知识体系含10个知识域，8个学科由软件工程协调委员会(SWECC)于2008年确立的版本。10《软件工程》知识体系含10个知识域，8个学科由软件工程协69软件工程框架

过程：生产目标产品所需要的步骤

目标：生产具有正确性、可用性以及开销合宜的软件产品

软件工程过程主要包括开发过程、运作过程、维护过程。软件工程过程覆盖了需求分析、设计、实现、确认以及维护等活动。正确性——满足用户的各项功能需求可用性——软件及其使用文档方便为用户使用开销合宜——软件开发及运行的各项开销能够被用户接受

软件工程框架可概括为：目标、过程和原则。

原则：围绕工程设计、工程支持以及工程管理在软件开发过程中必须遵循的原则。11软件工程框架过程：生产目标产品所需要的步骤目70软件工程的“四项基本原则”

原则三：提供高质量的工程支持。

原则二：采用合适的设计方法。“工欲善其事，必先利其器”。软件工具与环境对软件过程的支持颇为重要。软件设计中，通常要考虑软件的模块化、抽象与信息隐蔽、局部化、一致性以及适应性等特征

原则一：选取适宜的开发范型。

原则四：重视软件开发过程的管理。

软件需求、硬件需求以及其他因素之间是相互制约、相互影响的，经常需要权衡。必须认识需求定义的易变性，采用适宜的开发范型予以控制。软件工程的管理，直接影响可用资源的有效利用，生产满足目标的软件产品，提高软件组织的生产能力等问题。因此，仅当软件过程得以有效管理时，才能实现有效的软件工程。12软件工程的“四项基本原则”原则三：提供高质量的工程支71软件生命周期软件生命周期(SystemsDevelopmentLifeCycle，SDLC)

问题的定义及规划需求分析软件设计程序编码软件测试运行维护六个阶段13软件生命周期软件生命周期(SystemsDevelo72软件项目开发及管理全过程14软件项目开发及管理全过程73软件项目管理流程立项阶段项目验收阶段判断验收时机已经成熟验收流程的优化后续服务及维护条款项目执行阶段经验总结阶段

制定项目建议书、可行性分析、产品调研、承包商选择技巧招投标方式

合同上关于风险应对及责任明晰等内容制定

工作计划质量监管、测试方案

进度监管15软件项目管理流程立项阶段项目验收阶段判断验收时机已经成74软件项目管理项目管理复杂性分析

软件开发过程模型概述

软件项目管理流程

各阶段需要注意的事项16软件项目管理项目管理复杂性分析75软件项目管理的复杂之处

软件产品是智力产品，软件项目是设计型项目

“隔行如隔山”软件使用方在提业务需求时往往不能足够重视需求变化频繁，变更难以控制难以估算工作量

开发进度难以界定交付成果难以明确

对开发人员依赖性大

承建商主要目的是利润，只想提供最少的功能、一定的质量，并在合理时间内完成

为达到更高利润，承建商可能对项目进行二次外包，管理更混乱

……17软件项目管理的复杂之处软件产品是智力产品，软件项目是设76软件开发过程

重视软件开发过程

过程决定了软件建设的步骤与我们管理的方式

过程直接影响最终产品的质量软件开发过程模型瀑布模型快速原型模型增量模型构件组装模型螺旋模型18软件开发过程重视软件开发过程过程决定了77软件过程模型——瀑布模型(Waterfall-model)

思想

软件开发划分阶段各阶段顺序执行

特征

最早的、最简单的模型“理想化”的顺序模型单向性，工作不可逆转

优点

为项目提供分阶段的检查点当前活动完成，只需关注后续活动模板清晰

缺点

抵抗“需求不断变化”能力弱。用户最终才能见产品，增加开发风险。开发人员常常陷入“阻塞状态”各阶段划分完全固定，产生大量文档，增加工作量。——由Royce于1970年提出19软件过程模型——瀑布模型(Waterfall-model78软件过程模型——增量模型(incrementalmodel)

思想

功能拆分，每个子功能按瀑布模型开发最终合并所有“增量”

特征

分模块开发多段瀑布模型

优点

抗变化能力比瀑布模型强可以边开发，边应用

缺点

所有子系统合并可能“不兼容”对系统设计师的水平要求高——举例：字处理软件解决方法：面向接口的编程方法适用于：小型或是交互型式的系统。大型系统的某些部分，例如用户界面。20软件过程模型——增量模型(incrementalmod79软件过程模型——快速原型模型(rapidprototype)

思想

根据需求先较小代价、快速构建一个软件的“雏形”根据用户反馈不断调整，最终确定产品

优点

开发方可快速对需求有明晰认识能有效应对需求变化，降低风险

缺点

快速建立起来的原型系统可能架构脆弱，不断修改，导致产品低下——建立快速原型的主要目的是快速获取与验证需求！21软件过程模型——快速原型模型(rapidprototy80软件过程模型——基于组件的开发模型

思想：软件复用

22软件过程模型——基于组件的开发模型思想：软件复用81软件过程模型——螺旋模型(SpiralModel)

思想

施工前先进行风险评估，通过后快速开发出原型，交由用户评估沿螺旋线自内向外每旋转一圈，意味着开发出更加完善的版本

特征

瀑布模型和快速原型模型的联合体适用于大型复杂项目，有效控制风险——由Boehm于1988年提出

缺点

需要较高的风险评估技术风险分析费用高，增加成本应用较复杂23软件过程模型——螺旋模型(SpiralModel)思82软件过程模型使用总结

需求明确——瀑布模型；

用户无信息系统使用经验，需求分析人员技能不足——快速原型模型

需求不确定因素多，无法提前计划——采用增量迭代和螺旋模型资金和成本无法一次到位——增量模型，软件产品分多个版本进行发行全新系统的开发——必须在总体设计完成后再开始增量或并行编码人员经验较少——建议不要采用敏捷或迭代等生命周期模型

增量,迭代和原型可以综合使用,但每一次增量或迭代都必须有明确的交付和出口准则24软件过程模型使用总结需求明确——瀑布模型；83“哪种过程模型更好用？”

比较

瀑布模型最简单，但抗需求变化能力最弱增量模型分模块开发，子系统集成怕不兼容快速原型模型能最快实现需求一致性螺旋模型一般只有大型公司或大型项目采用不要太在乎学术上的“先进”与“落后”，适用的就最好。瀑布模型

增量模型快速原型模型螺旋模型我们最常见的系统都是采用增量模型、快速原型模型来开发。当前对软件研发过程质量的评判主要是以SEI（SoftwareEngineeringInstitute）颁布的CMMI（CapabilityMaturityModelIntegration）作为研发标准。25“哪种过程模型更好用？”比较瀑布模型最简单，但抗84软件项目管理流程立项阶段项目验收阶段判断验收时机已经成熟验收流程的优化后续服务及维护条款项目执行阶段经验总结阶段

制定项目建议书、可行性分析、产品调研、承包商选择技巧招投标方式

合同上关于风险应对及责任明晰等内容制定

工作计划质量监管、测试方案

进度监管26软件项目管理流程立项阶段项目验收阶段判断验收时机已经成软件工程项目管理思考及探索课件86立项阶段——方向比努力更重要第一步：项目建议书

项目背景。

意义和必要性。

未来收益预期。

规模和期限。

投资估算。

资金筹措。

其他重要意见。提交项目建议书给相关部门进行审核，“上会”28立项阶段——方向比努力更重要第一步：项目建议书项目背87第二步：项目可行性分析立项阶段

需求分析。项目的背景、项目的目标、业务需求、概要设计。

技术可行性分析。

经济可行性分析。我们预算多少，硬件方面需要多少投资。

主要风险分析。

人员配置及项目实施计划。

可行性研究的结论和建议。

其他重要意见。29第二步：项目可行性分析立项阶段需求分析。项目的背景、项88立项阶段需求的基本标准需求管理的误区

开发分析阶段，开发方与客户只需要在轮廓上达成基本一致即可，具体细节以后再填充。软件项目需求可以持续不断地改变。——实践表明，随着开发进度的推进，实现软件需求更改所需的代价呈指数形式增长。

仅仅满足目前需求即可，不考虑未来几年的状况。准确界定系统的目标和范围完整、正确

可行、必要

划分优先级

无二义性、可验证坚持需求的审查对部分重要需求进行追踪30立项阶段需求的基本标准需求管理的误区开发分析阶段，开发89立项阶段

技术

——开发能力如何？技术方案是否满意？

管理

——内部组织是否混乱？

进度——开发进度是否可以接受？

经验——是否有相关领域、相似产品的开发经验、以前开发的产品质量如何？

诚信度——信誉、口碑如何？采用“一票否决制”

资质——是否取得业界认可证书（如ISO9000质量认证、CMM认证），证书等级后续服务——能否提供较好的开发及维护服务经济实用性——性价比如何？

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

尽可能提前预估风险，制定应对方案。32第四步：合同签署，明晰管理章程。立项阶段第三步：专家组评91项目策划阶段

工作量估计。

寻找关键路径。通过定义各任务之间的依赖关系，计算出项目中的关键路径，帮助区分任务的轻重缓急，合理安排和调整资源，从而保证项目的整体进度。软件项目主管的任务——“排兵布阵”33项目策划阶段工作量估计。软件项目主管的任务——“排兵布软件工程项目管理思考及探索课件软件工程项目管理思考及探索课件软件工程项目管理思考及探索课件95目标：进度快、投资省、质量好。项目执行阶段进度快就要增加投资，而项目提前使用却又可能及早提高收益。

进度快，质量也许就不能保证；质量严格控制，则有可能影响进度；质量严格控制不至返工，又会加快进度。“脱离成本，不谈质量”。项目负责人的任务进度、成本、质量、风险、人力资源等等。进度、成本、质量——对立统一关系成本除了资金成本，还有人力成本，资金少，就多付出些汗水。37目标：进度快、投资省、质量好。项目执行阶段进度快就要增9638项目执行阶段——进度管理(1)97进度的描述里程碑——做完、没做完，没有第三种状态甘特图项目执行阶段——进度管理(1)39进度的描述里程碑——做98甘特图示例40甘特图示例项目执行阶段——进度管理(2)99影响进度的主要因素错估了项目特点及实现条件。项目参与者工作错误。不可预见事件发生。面对进度延迟，我们该怎么做呢？——分析主客观原因，对症下药！项目执行阶段——进度管理(2)41影响进度的主要因素错估了项目执行阶段——进度管理(3)100客观原因进度计划不合理，过于理想化等任务定义过于复杂、过度定义、超出范围测试太多错误而延迟意外发生(比如停电、开发人员生病等)

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

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

正确性——精确地满足需求的程度

健壮性——容错能力，恢复能力

可靠性——误差累积、代码缺陷，突然不正常

性能——“时间-空间”效率，速度快、占用资源少

易用性——用户友好性

清晰性——使用文档详实、易懂

可扩展性——适应变化的能力，模块化功能改进项目执行阶段——质量管理(1)44软件质量度量因素正确性项目执行阶段——质量管理(2)103棘手的问题大多数公司不认真关注质量，只想尽快通过“验收”。“钓鱼”现象存在。如何保证质量？——3大原则缺陷预防。“零缺陷管理”，“质量是做出来的，不是测出来的”。重在过程。每个阶段都要严格组织，责任到人，多层把关。严格审查。“测试驱动开发”，并发数，压力测试等等。作为甲方，我们需要注意分阶段质量把控

验收时结合业务进行多种手段的测试。“试行期”要尽量发现更多问题。项目执行阶段——质量管理