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

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

1、软件工程项目管理思考及探索,主要内容,引言 软件工程 软件项目管理 昆工软件项目管理思考 内容总结,2,3,引言,工作中遇到的问题 “软件危机”现象 软件工程,4,工作概述,建设“校园信息化”信息资源管理平台 建设和完善重点应用系统 ,5,我们所遇到的共性问题,产品质量问题,项目进度问题,产品与要求相差甚远 没有提高工作效率，反而增加了繁琐的业务 一旦用户增多，性能就变得非常差 交付的产品存在隐患，公司“钓鱼”，故意留下漏洞 ,公司拖拉，项目进度缓慢，而且总有各种托辞的借口与理由,案例： 教务处排课系统缺陷 四六级报名系统缺陷 ,公司研发人员态度差，难于沟通 出现问题时，互相扯皮 ,6,“软件

2、危机”现象,危害严重,典型表现,伦敦地铁，司机没上车，地铁就驶离站台 丹佛机场行李系统，延期16个月，成本超出32亿美元 Ariane5，40秒爆炸，损失50亿美元 ,程序质量低下 错误频出 进度延误 费用剧增 ,软件危机,泛指在计算机软件的开发和维护过程中所遇到的一系列严重问题。,软件危机不可避免，也没有根治的途径,要解决软件危机，需进行系统性的研究,项目建设，“知己知彼，百战不殆”,7,利器 软件工程,软件工程（Software Engineering，SE） 一门集计算机科学、数学、逻辑学及管理学为一体的学科，意在通过借鉴传统工程的原则、方法，来进行软件开发的管理，从而提高软件质量、降低

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

4、品所需要的步骤,目标：生产具有正确性、可用性以及开销合宜的软件产品,软件工程过程主要包括开发过程、运作过程、维护过程。 软件工程过程覆盖了需求分析、设计、实现、确认以及维护等活动。,正确性满足用户的各项功能需求 可用性软件及其使用文档方便为用户使用 开销合宜软件开发及运行的各项开销能够被用户接受,软件工程框架可概括为：目标、过程和原则。,原则：围绕工程设计、工程支持以及工程管理在软件开发过程中必须遵循的原则。,12,软件工程的“四项基本原则”,原则三：提供高质量的工程支持。,原则二：采用合适的设计方法。,“工欲善其事，必先利其器”。软件工具与环境对软件过程的支持颇为重要。,软件设计中，通常要考

5、虑软件的模块化、抽象与信息隐蔽、局部化、一致性以及适应性等特征,原则一：选取适宜的开发范型。,原则四：重视软件开发过程的管理。,软件需求、硬件需求以及其他因素之间是相互制约、相互影响的，经常需要权衡。必须认识需求定义的易变性，采用适宜的开发范型予以控制。,软件工程的管理，直接影响可用资源的有效利用，生产满足目标的软件产品，提高软件组织的生产能力等问题。因此，仅当软件过程得以有效管理时，才能实现有效的软件工程。,13,软件生命周期,软件生命周期(Systems Development Life Cycle，SDLC),问题的定义及规划 需求分析 软件设计 程序编码 软件测试 运行维护,六个阶段,

6、14,软件项目开发及管理全过程,15,软件项目管理流程,立项阶段,项目验收阶段,判断验收时机已经成熟 验收流程的优化 后续服务及维护条款,项目执行阶段,经验总结阶段,制定项目建议书、可行性分析、产品调研、承包商选择技巧 招投标方式 合同上关于风险应对及责任明晰等内容制定,工作计划 质量监管、测试方案 进度监管,16,软件项目管理,项目管理复杂性分析 软件开发过程模型概述 软件项目管理流程 各阶段需要注意的事项,17,软件项目管理的复杂之处,软件产品是智力产品，软件项目是设计型项目 “隔行如隔山” 软件使用方在提业务需求时往往不能足够重视 需求变化频繁，变更难以控制 难以估算工作量 开发进度难以

7、界定 交付成果难以明确 对开发人员依赖性大 承建商主要目的是利润，只想提供最少的功能、一定的质量，并在合理时间内完成 为达到更高利润，承建商可能对项目进行二次外包，管理更混乱 ,18,软件开发过程,重视软件开发过程,过程决定了软件建设的步骤与我们管理的方式 过程直接影响最终产品的质量,软件开发过程模型,瀑布模型 快速原型模型 增量模型 构件组装模型 螺旋模型,19,软件过程模型瀑布模型(Waterfall-model),思想,软件开发划分阶段 各阶段顺序执行,特征,最早的、最简单的模型 “理想化”的顺序模型 单向性，工作不可逆转,优点,为项目提供分阶段的检查点 当前活动完成，只需关注后续活动

8、模板清晰,缺点,抵抗“需求不断变化”能力弱。 用户最终才能见产品，增加开发风险。 开发人员常常陷入“阻塞状态” 各阶段划分完全固定，产生大量文档，增加工作量。, 由 Royce 于1970年提出,20,软件过程模型增量模型(incremental model),思想,功能拆分，每个子功能按瀑布模型开发 最终合并所有“增量”,特征,分模块开发 多段瀑布模型,优点,抗变化能力比瀑布模型强 可以边开发，边应用,缺点,所有子系统合并可能“不兼容” 对系统设计师的水平要求高,举例：字处理软件,解决方法：面向接口的编程方法,适用于：小型或是交互型式的系统。大型系统的某些部分，例如用户界面。,21,软件过程

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

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

11、求变化能力最弱 增量模型分模块开发，子系统集成怕不兼容 快速原型模型能最快实现需求一致性 螺旋模型一般只有大型公司或大型项目采用,不要太在乎学术上的“先进”与“落后”，适用的就最好。,瀑布模型 增量模型 快速原型模型 螺旋模型,我们最常见的系统都是采用增量模型、快速原型模型来开发。,当前对软件研发过程质量的评判主要是以SEI（Software Engineering Institute） 颁布的CMMI（Capability Maturity Model Integration）作为研发标准。,26,软件项目管理流程,立项阶段,项目验收阶段,判断验收时机已经成熟 验收流程的优化 后续服务及维护

12、条款,项目执行阶段,经验总结阶段,制定项目建议书、可行性分析、产品调研、承包商选择技巧 招投标方式 合同上关于风险应对及责任明晰等内容制定,工作计划 质量监管、测试方案 进度监管,28,立项阶段 方向比努力更重要,第一步：项目建议书,项目背景。 意义和必要性。 未来收益预期。 规模和期限。 投资估算。 资金筹措。 其他重要意见。,提交项目建议书给相关部门进行审核，“上会”,29,第二步：项目可行性分析,立项阶段,需求分析。项目的背景、项目的目标、业务需求、概要设计。 技术可行性分析。 经济可行性分析。我们预算多少，硬件方面需要多少投资。 主要风险分析。 人员配置及项目实施计划。 可行性研究的结

13、论和建议。 其他重要意见。,30,立项阶段,需求的基本标准,需求管理的误区,开发分析阶段，开发方与客户只需要在轮廓上达成基本一致即可，具体细节以后再填充。 软件项目需求可以持续不断地改变。实践表明，随着开发进度的推进，实现软件需求更改所需的代价呈指数形式增长。 仅仅满足目前需求即可，不考虑未来几年的状况。,准确界定系统的目标和范围,完整、正确 可行、必要 划分优先级 无二义性、可验证,坚持需求的审查,对部分重要需求进行追踪,31,立项阶段,技术 开发能力如何？技术方案是否满意？ 管理 内部组织是否混乱？ 进度 开发进度是否可以接受？ 经验 是否有相关领域、相似产品的开发经验、以前开发的产品质量

14、如何？ 诚信度 信誉、口碑如何？采用“一票否决制” 资质是否取得业界认可证书（如ISO9000质量认证、CMM认证），证书等级 后续服务能否提供较好的开发及维护服务 经济实用性性价比如何？ 其他因素比如地理位置等,选择软件供应商考虑因素,CMM五个等级,32,第四步：合同签署，明晰管理章程。,立项阶段,第三步：专家组评审可行性分析报告,专门的技术人员、软件最终使用者涉及到的相关利益主体。 案例：教务处排课系统对多媒体教室管理带来的影响。,不仅仅是形式，启动是为了形成一个良好的沟通体系，让所有项目人员都理解项目重要性，同时明晰职责，保障项目管理的畅通。,第五步：项目启动仪式“磨刀不误砍柴工”。,

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

16、、成本、质量对立统一关系,成本除了资金成本，还有人力成本，资金少，就多付出些汗水。,38,项目执行阶段进度管理(1),39,进度的描述,里程碑 做完、没做完，没有第三种状态 甘特图,40,甘特图示例,项目执行阶段进度管理(2),41,影响进度的主要因素,错估了项目特点及实现条件。 项目参与者工作错误。 不可预见事件发生。,面对进度延迟，我们该怎么做呢？分析主客观原因，对症下药！,项目执行阶段进度管理(3),42,客观原因,进度计划不合理，过于理想化等 任务定义过于复杂、过度定义、超出范围 测试太多错误而延迟 意外发生(比如停电、开发人员生病等) 使用方需求变更,主观原因,开发人员没有全神贯注于

17、自己的工作。 开发人员不恰当的工作方式。 任务定义依赖性强，人员工作之间扯皮。 项目经理过多干预开发人员工作。,应对措施,重新定义进度计划 重新定义任务，舍弃过难技术问题 万不可为了赶进度而降低测试标准！ 按风险管理中制定的应急措施处理 核心/关键功能的里程碑事件定义,应对措施,生活原因？多多沟通、绩效考核 有针对性地进行经验交流和培训 依赖性强的任务合并！ “用人不疑、疑人不用”,项目执行阶段进度管理(4),43,技巧,延迟如果不补救，就会呈加速度扩展。 如果没有很好的办法，那就辛苦一点，最笨的办法是“紧盯”。 “防患于未然”，影响进度的许多因素，我们争取在立项时就要充分考虑到。,项目执行阶

18、段质量管理(1),44,软件质量度量因素,正确性精确地满足需求的程度 健壮性容错能力，恢复能力 可靠性误差累积、代码缺陷，突然不正常 性能“时间-空间”效率，速度快、占用资源少 易用性用户友好性 清晰性使用文档详实、易懂 可扩展性适应变化的能力，模块化功能改进,项目执行阶段质量管理(2),45,棘手的问题,大多数公司不认真关注质量，只想尽快通过“验收”。 “钓鱼”现象存在。,如何保证质量？3大原则,缺陷预防。“零缺陷管理”，“质量是做出来的，不是测出来的”。 重在过程。每个阶段都要严格组织，责任到人，多层把关。 严格审查。“测试驱动开发”，并发数，压力测试等等。,作为甲方，我们需要注意,分阶段

19、质量把控 验收时结合业务进行多种手段的测试。 “试行期”要尽量发现更多问题。,项目验收阶段(1),46,验收前提,完成合同要求的全部内容。 在“试运行”期间已完成对软件系统的严格测试（白盒、黑盒）。 准备好相关的开发文档和产品文档。 准备好软件安装和验收的部署环境。 相关使用人员的培训工作完成。,验收内容,功能检测。 质量鉴定。 资料评审。 后续维护工作的一些协商。,可以内部先拟定一个详细的验收计划,项目验收阶段(2),47,验收流程,验收报告,验收小组拟定。 基本情况的各项审核。 一些相关的合理性建议。,初审。 复审。,项目总结阶段,48,项目实施过程回顾,工作或过程的扼要评价 问题的跟踪情

20、况 变更的管理 突发事件和突发冲突的处理,从经验中学习,一定要实事求是！ 着眼点要准确，分析要深入！ 不要回避、隐瞒问题和矛盾！ 要有主次之分，条理要清晰。,项目总结交流会,经验教训汇总 棘手难题汇总，如何应对展开讨论 各抒己见，分享体会 一些改进和建议方案的汇总,49,昆工软件项目管理思考,昆工软件项目立项流程图 每个环节都注意哪些,立项阶段(1),51,成熟产品修改？定制开发？优劣利害对比 选择合适的软件开发过程,重视项目的可行性分析,需求分析格外重要，要尽可能丰富地收集业务方的实际需求 技术可行性、经济可行性等方面要客观考量 可能遇到的风险问题要及早预期 多参照相关利益人征集项目建设意见

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

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