4_软件项目管理

软件工程王忠杰[e-mail]2011年3月21日软件工程第二章软件开发过程管理4 软件项目管理4 软件项目管理主要内容4.1  软件项目管理概述4.2  项目可行性分析与估算4.3  项目进度安排4.4* 项目风险管理4.5* 项目质量管理软件工程4.1 软件项目管理概述4 软件项目管理若干基本概念项目(Project) ：为创建某种特定的产品或服务而组织或设计的临时的、一次性的行动，通过执行一组活动，使用受约束的资源(资金、人、原料、能源、空间等)来满足预定义的目标。项目管理(Project Management, PM)：有效的组织与管理各类资源(例如人)，以使项目能够在预定的范围、质量、时间和成本等约束条件下顺利交付(deliver)。–挑战1：在各类约束条件下交付项目；–挑战2：通过优化资源的分配与集成来满足预先定义的目标；软件项目的特征：–软件产品的不可见性软件项目复杂和抽象；–项目的高度不确定性预定计划于实际情况存在较大偏差；–软件过程的多变化性不确定、不稳定；–软件人员的高技能及其高流动性风险；软件工程一个小案例4 软件项目管理X项目的初始状态一个年轻的项目经理A10个经验缺乏的技术人员项目交付期：紧张技术风险：较高4 软件项目管理X项目的当前状态进度已经落后于计划项目经理A已经向客户汇报了一次项目开发进度，并已经演示了系统功能，已开发的功能已被用户接受并认可。此时：项目组补充加入了一位水平高、经验丰富的技术人员BB检查了团队目前完成的代码，发现：原来写的代码效率不高，构架繁冗，不方便后期维护，也可能导致软件性能方面存在重大缺陷。B的建议：重构代码和数据库设计。4 软件项目管理X项目的当前状态团队的想法：辛苦写的代码被一票否决，心里很不舒服，但是也承认自己的代码质量不高。项目经理A的想法：预计客户将来会提到这个问题，而届时再重构，会更加麻烦。公司CEO的意见：已经向客户申请过一次计划调整并基本得到用户的理解，但目前进度已经落后于计划，急需完成剩余部分功能的开发。不能再次申请延期。4 软件项目管理X项目的客观情况如果系统重构，很有可能需要再次调整计划，而用户已经明确表示计划是不可能再调整的了。B在技术上没有问题，但是缺乏时间观念，且身兼多个项目，重构速度令人失望。老成员一开始挺配合系统重构，但是随着重构的深入，发现难度很大，基本等于重新开发。于是对B很有意见，不怎么配合B的指挥。如果你作为项目经理，怎么办？4 软件项目管理X项目何去何从？这是软件项目管理中的典型案例。一个平均技术水平低下的研发团队而使得项目进展存在较多隐患。一个无奈的弱势项目经理缺乏经验几乎无法处理全部问题；一个鲁莽但是经验丰富的技术人员，粗鲁的忽视了开发进度和客户需求，进行单方面技术改进的要求；公司因为项目款项回收速度慢而指责团队开发进度。4 软件项目管理软件项目管理的“4P”软件工程4.1.2 人员(People)4 软件项目管理软件项目的参与人员项目经理高级管理者：负责定义业务问题；项目(技术)管理者：计划、激励、组织和控制软件开发人员；开发人员：拥有开发软件所需技能的人员；–系统分析员；系统架构师；设计师；程序员；测试人员；质量保证人员；…客户：进行投资、详细描述待开发软件需求、关心项目成败的组织/人员；最终用户：一旦软件发布成为产品，最终用户就是直接使用软件的人。4 软件项目管理软件开发团队“最好的”团队取决于项目经理的管理风格、团队里的人员数目与技能水平、项目的总体难易程度；组建团队时应考虑以下要素：–从个人能力来看：•应用领域经验•开发平台经验•编程经验•教育背景•沟通能力•适应能力•工作态度•团队协作能力•……–从项目需求来看：•待解决问题的难度；•待开发软件系统的规模；•待开发软件系统的技能要求；•交付日期的严格程度；•共同工作的时间；•彼此之间的人际关系与友好交际程度；•……4 软件项目管理民主式：小组成员完全平等；主程序员式：一个人全面负责、其他人给予支持；技术管理式：综合上述二者的特征；上述三种项目的组织方式各有什么利弊？软件开发团队的组织方式技术人员技术人员技术人员后备工程师秘书高级工程师技术人员技术人员技术人员技术人员技术人员技术人员技术人员管理组长技术组长4 软件项目管理大型项目的技术管理组织结构4 软件项目管理人员协调与沟通问题1：为什么需要沟通？问题2：沟通的方式有哪些？–面对面交谈、电话交谈、email、面对面会议、电话会议、网络会议、项目网站、书面报告；问题3：项目沟通活动有哪些？–规划项目沟通；–实施阶段性评审；–每周小组会议；–……4 软件项目管理Scrum中的“People”三种角色：–产品负责人(Product Owner)：高度的控制能力；–ScrumMaster：团队leader，高度的管理与协调能力；–Scrum团队：彼此完全平等，具备交付产品增量所需要的各种技能；沟通方式：–发布计划会议(Release Planning Meeting) –Sprint计划会议(Sprint Planning Meeting)–每日站会(Daily Scrum Meeting)–Sprint评审会(Sprint Review Meeting)–Sprint 回顾会议(Sprint Retrospective Meeting)软件工程4.1.3 产品(Product)4 软件项目管理软件产品4 软件项目管理软件产品首先应确定软件范围：–项目环境–信息目标–功能和非功能(性能)–在管理层和技术层都必须是无歧义的和可理解的，软件范围应是确定的；一旦确定了范围，需要对其进行分解——分而治之。文本输入编辑及格式设计剪贴/复制/粘贴页面布局能力自动生成索引和目录文件管理[例]文档编辑产品4 软件项目管理产品分解结构(PBS)项目管理里通常使用“产品结构分解(ProductBreakdownStructure,PBS)”作为产品分解的工具：–PBS：通过分层的树型结构来定义和组织项目范围内的所有产出物(产品)，自顶向下，逐级细分；–产出物：项目结束时需要提交的最终产品，在项目之初就可以准确的预计。4 软件项目管理1.软件项目1001.1可行性分析报告81.2需求分析报告151.3设计报告301.4源代码51.5测试用例151.6测试记录151.7项目管理文档121.软件项目1.1可行性分析报告1.软件项目1.1.1时间可行性1.1.2成本可行性1.1.3人员可行性1.1.4技术可行性1.2需求分析报告151.3设计报告1.3.1概要设计书1.3.2详细设计书1.4源代码51.5测试用例151.6测试记录1.6.1测试环境1.6.2测试记录1.6.3测试结果1.6.4修改记录2213131724451.7项目管理文档12100100PBS第1层PBS第2层PBS第3层产品结构分解(PBS)4 软件项目管理Scrum中的“Product”Product Backlog：–一个排列好优先级的功能列表，优先级由商业价值、风险、和必要性决定。–产品负责人负责产品Backlog的内容、可用性和优先级。–最初版本只列出最基本的和非常明确的需求，并随时间推移不断演进。–条目包括：功能性需求、非功能性需求、验收条件。Sprint Backlog：–是团队承诺在当前Sprint完成的任务列表，由产品Backlog选取的需求条目细化和分解而来。软件工程4.1.4 过程(Process)4 软件项目管理软件过程Step 1: 选择合适的软件过程模型–…还记得都有哪些过程模型了吗？–…还记得各过程模型所适用的不同场合吗？Step 2: 根据所选的过程模型，对其进行适应性修改；Step 3: 确定过程中应包含的工作任务列表；–[例]沟通活动：•列出需澄清的问题清单；•与客户见面并说明问题；•共同给出范围陈述•与所有相关人员一起评审；•根据需要修改范围陈述。4 软件项目管理工作分解结构(WBS)XXX企业软件项目沟通策划建模构建部署业务建模流程建模数据建模构件复用代码生成测试集成交付反馈项目管理里通常使用“工作结构分解(WorkBreakdownStructure,PBS)”作为过程分解的工具：WBS：通过分层的树型结构来定义和组织工作任务之间的分解关系，自顶向下，逐级细分；–[例]RAD过程模型的WBS分解结构4 软件项目管理Scrum中的“Process”Sprint (冲刺)：代表一个2‐4周的迭代；发布计划会议(Release Planning Meeting) Product BacklogSprint计划会议(Sprint Planning Meeting) Sprint Backlog 每日站会(Daily Scrum Meeting)Sprint评审会(Sprint Review Meeting)Sprint 回顾会议(Sprint Retrospective Meeting)软件工程4.1.5 项目(Project)4 软件项目管理项目关注的四个方面项目关注的四个方面–范围(Scope)–时间(Time)–成本(Cost)–质量(Quality)项目管理的主要任务–项目可行性分析与估算–项目进度安排–项目风险管理–项目质量管理–项目跟踪与控制4 软件项目管理W5HH原则Why为什么要开发这个系统？What将要做什么？When什么时候做？Who某功能由谁来做？Where他们的机构组织位于何处？How如何完成技术与管理工作？How much各种资源分别需要多少？软件工程4.2 可行性分析与估算4 软件项目管理可行性分析与估算在项目开始之前，必须预先估计三件事情：–需要多少工作量–需要多少时间–需要多少人员此外，还必须预测所需要的资源(硬件和软件)以及蕴含的风险；从而得出“该项目是否可行”的结论。4 软件项目管理4.2.1 确定范围范围(Scope)：描述了将要交付给最终用户的功能和特性、输入输出数据、用户界面、系统的性能、约束条件、接口和可靠性等，以及期望的时间、成本目标；两种方法：–与所有项目成员交流之后，写出对软件范围的叙述性描述；–由最终用户开发一组用例。注意：–并不是客户所有的需求都“来者不拒”，需要分别对待！–最终一定要用户签字确认！4 软件项目管理4.2.1 确定范围NeedsRequirementsExclusionsBaselineSignatureNeeds: 客户/最终用户的请求、想法和业务需求；Requirements:对未来系统所应具备的功能的陈述；Exclusions: 将不包含在未来系统中的功能的陈述；Baseline:对未来系统中应包含的功能的陈述。4 软件项目管理4.2.2 可行性分析技术可行性：–项目在技术上可行吗？它在技术水平范围内吗？能够将缺陷减少到一定程度吗？经济可行性：–它在经济上可行吗？能以可负担的成本完成开发吗？时间可行性：–项目投入市场的时间可以按预期完成吗？资源可行性：–组织拥有取得成功所需要的资源吗？4 软件项目管理4.2.3 软件项目估算如何估算时间、成本、资源？——靠经验？——靠数学公式？到目前为止，因为变化的要素太多，所以对软件的估算从来没有达到精确。但是，估计得越精确，项目成功的可能性就越高。方法：–代码行技术–功能点技术–过程估算技术4 软件项目管理(1) 代码行技术(LOC)LOC: Lines of Code–从过去开发类似产品的经验和历史数据出发，估计出所开发软件的代码行数。64bmaLL估计的代码行数a乐观值b悲观值m可能值LμCL估计的代码行数每行代码的单位成本C总成本LPML估计的代码行数平均生产率(LOC/pm)PM总的工作量(pm)4 软件项目管理(1) 代码行技术(LOC)900086007700设计分析模块平均生产率=62