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

软件工程项目管理思考及探索主讲人：冯旭鹏部门：信息技术科日期：2013.10.31主要内容引言软件工程软件项目管理昆工软件项目管理思考内容总结23引言工作中遇到的问题“软件危机”现象《软件工程》4工作概述建设“校园信息化”信息资源管理平台建设和完善重点应用系统......5我们所遇到的共性问题产品质量问题项目进度问题产品与要求相差甚远没有提高工作效率，反而增加了繁琐的业务一旦用户增多，性能就变得非常差交付的产品存在隐患，公司“钓鱼”，故意留下漏洞......公司拖拉，项目进度缓慢，而且总有各种托辞的借口与理由案例：教务处排课系统缺陷四六级报名系统缺陷......公司研发人员态度差，难于沟通出现问题时，互相扯皮......6“软件危机”现象危害严重典型表现伦敦地铁，司机没上车，地铁就驶离站台丹佛机场行李系统，延期16个月，成本超出32亿美元Ariane5，40秒爆炸，损失50亿美元......程序质量低下错误频出进度延误费用剧增......软件危机泛指在计算机软件的开发和维护过程中所遇到的一系列严重问题。软件危机不可避免，也没有根治的途径要解决软件危机，需进行系统性的研究项目建设，“知己知彼，百战不殆”7利器——《软件工程》《软件工程（SoftwareEngineering，SE）》——一门集计算机科学、数学、逻辑学及管理学为一体的学科，意在通过借鉴传统工程的原则、方法，来进行软件开发的管理，从而提高软件质量、降低软件成本和改进软件性能。8软件工程学科发展概述学科知识体系学科框架9《软件工程》发展概述诞生定义软件工程就是采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理方法和先进软件技术结合起来，运用到软件开发和维护过程中，来解决软件危机。思想以系统性的、规范化的、可定量的过程化方法去开发和维护软件使用经过时间考验而证明正确的管理技术1968年，北大西洋公约组织（NATO）举办了软件工程学术会议，首次提出10《软件工程》知识体系含10个知识域，8个学科由软件工程协调委员会(SWECC)于2008年确立的版本。11软件工程框架过程：生产目标产品所需要的步骤目标：生产具有正确性、可用性以及开销合宜的软件产品软件工程过程主要包括开发过程、运作过程、维护过程。软件工程过程覆盖了需求分析、设计、实现、确认以及维护等活动。正确性——满足用户的各项功能需求可用性——软件及其使用文档方便为用户使用开销合宜——软件开发及运行的各项开销能够被用户接受软件工程框架可概括为：目标、过程和原则。原则：围绕工程设计、工程支持以及工程管理在软件开发过程中必须遵循的原则。12软件工程的“四项基本原则”原则三：提供高质量的工程支持。原则二：采用合适的设计方法。“工欲善其事，必先利其器”。软件工具与环境对软件过程的支持颇为重要。软件设计中，通常要考虑软件的模块化、抽象与信息隐蔽、局部化、一致性以及适应性等特征原则一：选取适宜的开发范型。原则四：重视软件开发过程的管理。软件需求、硬件需求以及其他因素之间是相互制约、相互影响的，经常需要权衡。必须认识需求定义的易变性，采用适宜的开发范型予以控制。软件工程的管理，直接影响可用资源的有效利用，生产满足目标的软件产品，提高软件组织的生产能力等问题。因此，仅当软件过程得以有效管理时，才能实现有效的软件工程。13软件生命周期软件生命周期(SystemsDevelopmentLifeCycle，SDLC)问题的定义及规划需求分析软件设计程序编码软件测试运行维护六个阶段14软件项目开发及管理全过程15软件项目管理流程立项阶段项目验收阶段判断验收时机已经成熟验收流程的优化后续服务及维护条款项目执行阶段经验总结阶段制定项目建议书、可行性分析、产品调研、承包商选择技巧招投标方式合同上关于风险应对及责任明晰等内容制定工作计划质量监管、测试方案进度监管16软件项目管理项目管理复杂性分析软件开发过程模型概述软件项目管理流程各阶段需要注意的事项17软件项目管理的复杂之处软件产品是智力产品，软件项目是设计型项目“隔行如隔山”软件使用方在提业务需求时往往不能足够重视需求变化频繁，变更难以控制难以估算工作量开发进度难以界定交付成果难以明确对开发人员依赖性大承建商主要目的是利润，只想提供最少的功能、一定的质量，并在合理时间内完成为达到更高利润，承建商可能对项目进行二次外包，管理更混乱……18软件开发过程重视软件开发过程过程决定了软件建设的步骤与我们管理的方式过程直接影响最终产品的质量软件开发过程模型瀑布模型快速原型模型增量模型构件组装模型螺旋模型19软件过程模型——瀑布模型(Waterfall-model)思想软件开发划分阶段各阶段顺序执行特征最早的、最简单的模型“理想化”的顺序模型单向性，工作不可逆转优点为项目提供分阶段的检查点当前活动完成，只需关注后续活动模板清晰缺点抵抗“需求不断变化”能力弱。用户最终才能见产品，增加开发风险。开发人员常常陷入“阻塞状态”各阶段划分完全固定，产生大量文档，增加工作量。——由Royce于1970年提出20软件过程模型——增量模型(incrementalmodel)思想功能拆分，每个子功能按瀑布模型开发最终合并所有“增量”特征分模块开发多段瀑布模型优点抗变化能力比瀑布模型强可以边开发，边应用缺点所有子系统合并可能“不兼容”对系统设计师的水平要求高——举例：字处理软件解决方法：面向接口的编程方法适用于：小型或是交互型式的系统。大型系统的某些部分，例如用户界面。21软件过程模型——快速原型模型(rapidprototype)思想根据需求先较小代价、快速构建一个软件的“雏形”根据用户反馈不断调整，最终确定产品优点开发方可快速对需求有明晰认识能有效应对需求变化，降低风险缺点快速建立起来的原型系统可能架构脆弱，不断修改，导致产品低下——建立快速原型的主要目的是快速获取与验证需求！22软件过程模型——基于组件的开发模型思想：软件复用23软件过程模型——螺旋模型(SpiralModel)思想施工前先进行风险评估，通过后快速开发出原型，交由用户评估沿螺旋线自内向外每旋转一圈，意味着开发出更加完善的版本特征瀑布模型和快速原型模型的联合体适用于大型复杂项目，有效控制风险——由Boehm于1988年提出缺点需要较高的风险评估技术风险分析费用高，增加成本应用较复杂24软件过程模型使用总结需求明确——瀑布模型；用户无信息系统使用经验，需求分析人员技能不足——快速原型模型需求不确定因素多，无法提前计划——采用增量迭代和螺旋模型资金和成本无法一次到位——增量模型，软件产品分多个版本进行发行全新系统的开发——必须在总体设计完成后再开始增量或并行编码人员经验较少——建议不要采用敏捷或迭代等生命周期模型增量,迭代和原型可以综合使用,但每一次增量或迭代都必须有明确的交付和出口准则25“哪种过程模型更好用？”比较瀑布模型最简单，但抗需求变化能力最弱增量模型分模块开发，子系统集成怕不兼容快速原型模型能最快实现需求一致性螺旋模型一般只有大型公司或大型项目采用不要太在乎学术上的“先进”与“落后”，适用的就最好。瀑布模型增量模型快速原型模型螺旋模型我们最常见的系统都是采用增量模型、快速原型模型来开发。当前对软件研发过程质量的评判主要是以SEI（SoftwareEngineeringInstitute）颁布的CMMI（CapabilityMaturityModelIntegration）作为研发标准。26软件项目管理流程立项阶段项目验收阶段判断验收时机已经成熟验收流程的优化后续服务及维护条款项目执行阶段经验总结阶段制定项目建议书、可行性分析、产品调研、承包商选择技巧招投标方式合同上关于风险应对及责任明晰等内容制定工作计划质量监管、测试方案进度监管28立项阶段——方向比努力更重要第一步：项目建议书项目背景。意义和必要性。未来收益预期。规模和期限。投资估算。资金筹措。其他重要意见。提交项目建议书给相关部门进行审核，“上会”29第二步：项目可行性分析立项阶段需求分析。项目的背景、项目的目标、业务需求、概要设计。技术可行性分析。经济可行性分析。我们预算多少，硬件方面需要多少投资。主要风险分析。人员配置及项目实施计划。可行性研究的结论和建议。其他重要意见。30立项阶段需求的基本标准需求管理的误区开发分析阶段，开发方与客户只需要在轮廓上达成基本一致即可，具体细节以后再填充。软件项目需求可以持续不断地改变。——实践表明，随着开发进度的推进，实现软件需求更改所需的代价呈指数形式增长。仅仅满足目前需求即可，不考虑未来几年的状况。准确界定系统的目标和范围完整、正确可行、必要划分优先级无二义性、可验证坚持需求的审查对部分重要需求进行追踪31立项阶段技术——开发能力如何？技术方案是否满意？管理——内部组织是否混乱？进度——开发进度是否可以接受？经验——是否有相关领域、相似产品的开发经验、以前开发的产品质量如何？诚信度——信誉、口碑如何？采用“一票否决制”资质——是否取得业界认可证书（如ISO9000质量认证、CMM认证），证书等级后续服务——能否提供较好的开发及维护服务经济实用性——性价比如何？其他因素——比如地理位置等选择软件供应商考虑因素CMM五个等级32第四步：合同签署，明晰管理章程。立项阶段第三步：专家组评审《可行性分析报告》专门的技术人员、软件最终使用者涉及到的相关利益主体。案例：教务处排课系统对多媒体教室管理带来的影响。不仅仅是形式，启动是为了形成一个良好的沟通体系，让所有项目人员都理解项目重要性，同时明晰职责，保障项目管理的畅通。第五步：项目启动仪式——“磨刀不误砍柴工”。考虑到后续开发过程中进度、质量等方面的干扰因素，制定规章条例。尽可能提前预估风险，制定应对方案。33项目策划阶段工作量估计。寻找关键路径。通过定义各任务之间的依赖关系，计算出项目中的关键路径，帮助区分任务的轻重缓急，合理安排和调整资源，从而保证项目的整体进度。软件项目主管的任务——“排兵布阵”37目标：进度快、投资省、质量好。项目执行阶段进度快就要增加投资，而项目提前使用却又可能及早提高收益。进度快，质量也许就不能保证；质量严格控制，则有可能影响进度；质量严格控制不至返工，又会加快进度。“脱离成本，不谈质量”。项目负责人的任务进度、成本、质量、风险、人力资源等等。进度、成本、质量——对立统一关系成本除了资金成本，还有人力成本，资金少，就多付出些汗水。项目执行阶段——进度管理(1)39进度的描述里程碑——做完、没做完，没有第三种状态甘特图40甘特图示例项目执行阶段——进度管理(2)41影响进度的主要因素错估了项目特点及实现条件。项目参与者工作错误。不可预见事件发生。面对进度延迟，我们该怎么做呢？——分析主客观原因，对症下药！项目执行阶段——进度管理(3)42客观原因进度计划不合理，过于理想化等任务定义过于复杂、过度定义、超出范围测试太多错误而延迟意外发生(比如停电、开发人员生病等)使用方需求变更主观原因开发人员没有全神贯注于自己的工作。开发人员不恰当的工作方式。任务定义依赖性强，人员工作之间扯皮。项目经理过多干预开发人员工作。应对措施——重新定义进度计划——重新定义任务，舍弃过难技术问题——万不可为了赶进度而降低测试标准！——按风险管理中制定的应急措施处理——核心/关键功能的里程碑事件定义应对措施——生活原因？多多沟通、绩效考核——有针对性地进行经验交流和培训—