wordpress采集免费版下载,优化师简历,网站链接推广怎么赚钱,南京哪里有做网站的软件项目管理背诵总结 将老师所发ppt的知识点整理#xff0c;方便查阅与背诵。 文章目录 软件项目管理背诵总结1. 概述1.1 什么是项目#xff1f;1.2 项目有那些特征#xff1f;1.3 项目于日常工作有什么区别#xff1f;1.4 如何衡量一个项目是否成功#xff1f;1.5 软件项…软件项目管理背诵总结 将老师所发ppt的知识点整理方便查阅与背诵。 文章目录 软件项目管理背诵总结1. 概述1.1 什么是项目1.2 项目有那些特征1.3 项目于日常工作有什么区别1.4 如何衡量一个项目是否成功1.5 软件项目还有什么特征1.6 什么是项目管理1.7 项目管理的内容可以从几个方面划分1.8 项目管理具有什么特征1.9 软件项目管理有什么特征1.10 项目管理的十个知识领域与五个标准化过程组是什么1.11软件过程是什么1.12 过程管理是什么1.13 过程管理与项目管理有什么关系1.14 什么是敏捷项目开发 2. 项目初始2.1 如何确立一个项目2.2 什么是项目评估如何项目评估2.3 请解释成本效益分析方法中名词。2.4 如何进行Make or Buy决策2.5 项目的立项需要完成什么工作2.6 合同项目立项的流程是怎么样的2.7 内部项目立项的流程是怎么样的2.8 什么是项目授权要做什么2.9 什么是项目章程2.10 项目经理有什么责任2.11 软件项目生存期模型有什么基本特征2.12 有哪些常用的生存期模型给出它们的简单介绍和特点 3.项目范围计划——需求管理3.1 什么是软件需求3.2 什么是需求工程有什么作用3.3 什么是需求获取3.4 需求获取有哪些活动3.5 需求获取需要注意什么3.6 什么是需求分析3.7 需求分析有哪些活动3.8 什么是需求规格编写3.9 什么是需求验证3.10 需求验证要保证什么性质3.11 为什么要有需求变更管理3.12 需求变更管理要完成什么工作3.13 请举例需求变更流程3.14 有哪些传统需求分析方法3.14注 什么是结构化的分析方法3.14.1 原型分析方法3.14.2 数据流建模的方法3.14.3 基于UML建模的方法3.14.4 功能列表法3.14.5 敏捷项目需求分析有哪几个关键要素3.14.5注0 敏捷项目需求分析的背景3.14.5注1 什么是产品代办事项列表3.14.5注2 如何细化产品代办事项列表3.14.5注3 什么是用户故事模板3.14.5注6 如何评价一个用户故事3.14.5注7 用户故事有哪些优先级 4. 项目范围计划——任务分解4.1 什么是任务分解4.2 什么是WBS4.3 WBS有什么作用4.4 有几种WBS分解的形式4.5 工作分解有哪些层次4.6 如何理解工作包work package4.7 WBS的编码有什么用4.8 什么是WBS字典4.9 有哪些任务分解的方法4.10 任务分解的基本步骤是怎么样的4.11 工作分解中需要注意哪些问题4.12 什么是项目可交付结果与里程碑事件4.13 工作分解有哪些困难该如何解决4.14 工作分解有哪些建议4.15 如何展开敏捷项目的任务分解 5. 项目成本计划——成本估算5.1 什么是成本估算有什么作用5.2 成本分为哪几类有哪些成本5.4 什么是软件项目规模5.5 有哪些影响软件项目成本的因素5.6 成本估算的过程是怎么样的给出成本估算的方法。5.6.1 代码行估算法。5.6.2 功能点估算法FP5.6.2.1 功能点估算中的系统组件FP5.6.2.2 给出功能点估算法的步骤 5.6.3 简述用例点估算法的计算流程5.6.4 类比估算法5.6. 5 自下而上估算法5.6.6 三点估算法5.6.7 介绍下参数估算法5.6.7.1 什么是静态单变量模型5.6.7.2 下COCOMO 81 模型 5.6.8 下专家估算法 5.7 什么是项目成本预算5.8 什么是成本基线 6. 项目进度计划6.1 什么是进度进度计划为什么重要6.2 如何制定出进度计划6.3 任务之间的关系有哪几种如何确定关系6.4 进度管理有哪几种图示方法6.5 介绍进度管理几种图示方法。6.5.1 网络图6.5.2 甘特图6.5.3 里程碑图6.5 4 资源图6.5.5 燃尽图/燃起图 6.6 介绍几种任务历时估计的方法6.6.1 PERT技术6.6.2 预留分析6.6.3 敏捷历时估算 6.7 什么是任务进度计划编制有什么基本方法6.7.1 如何使用关键路径法6.7.1.1项目进度管理时间参数对照表6.7.2 介绍下时间压缩法6.7.2.1 介绍下时间成本平衡方法进度压缩单位成本方法)6.7.2.1.1基本假设 6.7.2.2 简要介绍下进度压缩因子法6.7.2.3 对比一下时间压缩方法中的应急法和平行作业 6.7.3 资源平滑方法。6.7.3 资源平滑方法。 1. 概述
1.1 什么是项目
答
项目是为了创造一个唯一的产品或提供一个唯一的服务目标性而进行的临时性的努力是以一套独特而相互联系的任务为前提有效利用资源资源约束性在一定时间内满足一系列特定目标的多项相关工作的总称。
1.2 项目有那些特征
答
目标性临时性独特性资源约束性不确定性
1.3 项目于日常工作有什么区别
答
时限项目是一次性的日常运作是重复进行的追求项目是以目标为导向的日常运作是通过效率和有效性体现的组织项目是通过与项目经理及其团队工作完成的而日常运作是职能式的线性管理管理项目存在大量的变更管理而日常运作基本保持持续的连贯性的
1.4 如何衡量一个项目是否成功
答
衡量项目是否成功应该看该项目是否在工程允许范围内按照成本预算和进度计划生产出客户满意的产品四要素 项目范围成本进度客户满意度
1.5 软件项目还有什么特征
答
抽象性复杂性经验在软件项目中起很大作用变更是软件项目中常见现象项目的独特性和临时性决定项目是渐进明细的目前软件项目的开发较其他领域的项目缺少规范软件项目四要素 过程结果所需资源委托人。
1.6 什么是项目管理
答
指在项目活动中运用专门的知识、技能、工具和方法使项目能够实现或超过项目干系人的需要和期望
知识领域划分项目范围进度成本质量人力资源沟通风险变更管理项目干系人指参与项目和受项目活动影响的人包括项目发起人、项目组、 协助人员、客户、使用者、供应商甚至是项目的反对者。
1.7 项目管理的内容可以从几个方面划分
答 管理职能角度 项目管理包括项目计划、组织、人事 安排、控制、协调等方面的内容 项目获得的全过程角度 项目管理包括项目决策、项目规划与设计、项目的招投标、项目实施、项目终结与后评价等 方面的内容 项目投入资源要素角度 项目管理包括项目资金财务 管理、项目人事劳动管理、项目材料设备管理、项目技术管理、项目信息管理、项目合同管理等方面的内容 项目目标和约束角度 项目管理包括项目进度管理、 项目成本管理、项目质量管理等方面的内容
1.8 项目管理具有什么特征
答
创造性 项目的一次性特点决定了每实施一个项目都要具有创新性。 项目管理是一项复杂的工作具有较强的不确定性 项目一般由多个部分组成工作跨越多个组织、多个学科、多个 行业可供参考的经验很少甚至没有 项目管理需要专门的组织和团队 项目管理通常要跨越部门的界限在工作中将会遇到许多不同部 门的人员 项目经理的作用非常重要 项目经理要在有限的资源和时间的约束下运用系统的观点、科 学合理的方法对与项目相关的所有工作进行有效的管理因此项 目经理对项目的成败起着非常重要的作用。
1.9 软件项目管理有什么特征
答
软件是纯知识产品其开发进度和质量很难估计和度量生 产效率也难以预测和保障。需求在开始难以明确与过早签 订合同是矛盾的周期长复杂度高变数多软件需要满足一群人的期望其对项目的关注点不同利益 也不同软件项目管理的目的是让软件项目能在控制之下以预定成本按质完成
1.10 项目管理的十个知识领域与五个标准化过程组是什么
答
十个知识领域
项目集成管理 (project integration management)项目范围管理 (project scope management)项目进度管理 (project schedule management)项目成本管理 (project cost management)项目质量管理 (project quality management)项目资源管理 (project resource management)项目沟通管理 (project communication management)项目风险管理 (project risk management)项目采购管理 (project procurement management)项目干系人管理 (project stakeholder management)
五个标准化过程也称项目管理生命周期的5个阶段。
启动过程组计划过程组控制过程组执行过程组收尾过程组 1.11软件过程是什么
答:
软件项目的开发过程主要有系统调研、需求分析、概要设计、详细 设计、编码、测试、实施与维护等.软件过程包括流程、技术、产品、活动间关系、角色、工具等 是软件开发过程的各个方面因素的有机结合
1.12 过程管理是什么
答
从做过的项目中总结出的一些完善的过程称为最佳实践软件过程管理就是对最佳实践进行有效积累形成可重复的过程 使最佳实践可以在机构内共享其目的是要让过程能够被共享、重用并得到持续改进过程管理的内容包括过程定义和过程改进 过程定义对最佳实践进行总结形成一套稳定的可重复的软件过程过程改进根据实践中对过程的使用情况进行优化
1.13 过程管理与项目管理有什么关系
答
项目管理用于保证项目的成功孤傲从管理用于管理最佳实践这两者不是相互孤立的而是有机地紧密地结合的过程管理的成果即软件过程可以在项目管理中辅助于项目管理工作。
1.14 什么是敏捷项目开发
答
敏捷软件开发(agile software development) 是一个灵活的开发方法用于在一个动态的环境中向干系人快速交付产品主要特点是关注持续地交付价值通过迭代和快速的用户反馈管理不确定性和应对变更4条价值观 个体和交互胜过过程和工具 (individual and interaction over process and tool)可以工作的软件胜过面面俱到的文档 (working software over comprehensive documentation)客户合作胜过合同谈判 (customer collaboration over contract negotiation)响应变化胜过遵循计划 (responding to change over following a plan) 12个敏捷原则 ① 最先要做的是通过尽早地、持续地交付有价值的软件来使客户满意。 CFAIR② 即使到了开发的后期也欢迎改变需求。敏捷过程利用适应变化来为客户创造竞 争优势。③ 经常性地交付可以工作的软件交付的间隔可以从几个星期到几个月交付的时 间间隔越短越好。④ 在整个项目开发期间业务人员和开发人员尽可能地在一起工作。⑤ 围绕被激励起来的个体组成团队来构建项目给他们提供所需的环境与支持并且信任他们能够完成工作。⑥ 在团队内部及团队之间最有效果并且最有效率的传递信息的方式就是面对面的 交流。⑦ 可以工作的软件是首要的进度度量标准。⑧ 敏捷过程提倡平稳的开发。发起人、开发者和用户应该能够保持一个长期的、恒 定的开发速度。⑨ 不断地关注优秀的技能和好的设计会增强敏捷的能力。⑩ 简单——使未完成的工作最大化的艺术是根本的。⑪ 最好的架构、需求和设计出自于自组织的团队。⑫ 每隔一定的时间团队会在如何才能更有效地工作方面进行反省然后相应地调 整自己的行为。
2. 项目初始
2.1 如何确立一个项目
答
项目评估项目立项项目授权确定生存期模型
2.2 什么是项目评估如何项目评估
答
真正启动一个项目之前需要对项目进行评估主要从战略、操作性、计划、技术、社会可行性、市场可行性、经 济可行性等方面进行评估成本效益分析方法是评价项目经济效益的主要方法它是将系统开发和运行所需要的成本与得到的效益进行比较如果成本高于收益则表明项目亏损如果成本小于效益则表明项目值得投资
2.3 请解释成本效益分析方法中名词。
答 现金流预测是描述何时支出费用、何时有收益的过程 净利润是在项目的整个生命周期中总成本和总收入之差 投资回报期是达到收支平衡或者偿还初始投入所花费的时间 投资回报率会计回报率用于比较净收益率与需要的投入常见的最简 单的公式是 投资回报率(平均年利润/总投资)x 100% 净现值是一种项目评价技术考虑了项目的收益率和要产生的现金流的时限它是基于这样的观点今天收到100元要比明年收到的100元更好 内部回报率指可以直接与利润比较的百分比回报。如果借贷的资本少于 10%或者如果资本不投入到回报大于10%的其他地方则具有10%的内部回报率的项目是值得做的
2.4 如何进行Make or Buy决策
答
对比因素自制的理由购买的理由成本因素自制成本低购买成本低技术能力可以采用自制的技巧不会自制工作量管理工作量可控工作量小战略价值可以获得知识产权购买更有益风险与学习学习新的技能转移风险资源条件有可用的开发人员有很好的供货商项目重点核心项目工作项目可以将注意力放在其他工作上
2.5 项目的立项需要完成什么工作
答
明确项目的目标、时间表、项目使用的资源和经费而且得到执行该项目的项目经理和项目发起人的认可。这个阶段称为立项阶段。立项是要解决做什么的问题需要确定开发的项目关注点是效益和利润。项目立项报告的核心内容是确定立项前期需要投入多少 能否盈利什么时候能够盈利能否持久的盈利 等等
2.6 合同项目立项的流程是怎么样的
答
合同项目立项是指企业与外部客户通过签订商业合同来启动的项目。整体流程分为三个主要阶段
甲方主导阶段招标书定义 → 供方选择乙方响应阶段项目分析 → 提交建议书双方合作阶段合同签署 → 项目启动
项目启动准备
GAP期合同签订后的缓冲准备期用于团队组建和资源调配Kick off召开项目启动会标志项目正式开始Service Delivery进入正式的服务交付阶段 #mermaid-svg-3Cy2Zk7Q47iYZjtG {font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}#mermaid-svg-3Cy2Zk7Q47iYZjtG .error-icon{fill:#552222;}#mermaid-svg-3Cy2Zk7Q47iYZjtG .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-3Cy2Zk7Q47iYZjtG .edge-thickness-normal{stroke-width:2px;}#mermaid-svg-3Cy2Zk7Q47iYZjtG .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-3Cy2Zk7Q47iYZjtG .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-3Cy2Zk7Q47iYZjtG .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-3Cy2Zk7Q47iYZjtG .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-3Cy2Zk7Q47iYZjtG .marker{fill:#333333;stroke:#333333;}#mermaid-svg-3Cy2Zk7Q47iYZjtG .marker.cross{stroke:#333333;}#mermaid-svg-3Cy2Zk7Q47iYZjtG svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-3Cy2Zk7Q47iYZjtG .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-3Cy2Zk7Q47iYZjtG .cluster-label text{fill:#333;}#mermaid-svg-3Cy2Zk7Q47iYZjtG .cluster-label span{color:#333;}#mermaid-svg-3Cy2Zk7Q47iYZjtG .label text,#mermaid-svg-3Cy2Zk7Q47iYZjtG span{fill:#333;color:#333;}#mermaid-svg-3Cy2Zk7Q47iYZjtG .node rect,#mermaid-svg-3Cy2Zk7Q47iYZjtG .node circle,#mermaid-svg-3Cy2Zk7Q47iYZjtG .node ellipse,#mermaid-svg-3Cy2Zk7Q47iYZjtG .node polygon,#mermaid-svg-3Cy2Zk7Q47iYZjtG .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-3Cy2Zk7Q47iYZjtG .node .label{text-align:center;}#mermaid-svg-3Cy2Zk7Q47iYZjtG .node.clickable{cursor:pointer;}#mermaid-svg-3Cy2Zk7Q47iYZjtG .arrowheadPath{fill:#333333;}#mermaid-svg-3Cy2Zk7Q47iYZjtG .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-3Cy2Zk7Q47iYZjtG .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-3Cy2Zk7Q47iYZjtG .edgeLabel{background-color:#e8e8e8;text-align:center;}#mermaid-svg-3Cy2Zk7Q47iYZjtG .edgeLabel rect{opacity:0.5;background-color:#e8e8e8;fill:#e8e8e8;}#mermaid-svg-3Cy2Zk7Q47iYZjtG .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-3Cy2Zk7Q47iYZjtG .cluster text{fill:#333;}#mermaid-svg-3Cy2Zk7Q47iYZjtG .cluster span{color:#333;}#mermaid-svg-3Cy2Zk7Q47iYZjtG div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-3Cy2Zk7Q47iYZjtG :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;}#mermaid-svg-3Cy2Zk7Q47iYZjtG .partyA*{fill:#e1f5fe!important;}#mermaid-svg-3Cy2Zk7Q47iYZjtG .partyA span{fill:#e1f5fe!important;}#mermaid-svg-3Cy2Zk7Q47iYZjtG .partyB*{fill:#f3e5f5!important;}#mermaid-svg-3Cy2Zk7Q47iYZjtG .partyB span{fill:#f3e5f5!important;}#mermaid-svg-3Cy2Zk7Q47iYZjtG .cooperation*{fill:#e8f5e8!important;}#mermaid-svg-3Cy2Zk7Q47iYZjtG .cooperation span{fill:#e8f5e8!important;} 合作流程 乙方流程 甲方流程 任务书 合同签署文本 项目建议书 报价单 项目分析报告 招标文件 需方申请 最终供方名单 2.7 内部项目立项的流程是怎么样的
对比维度合同项目内部项目约束机制商业合同内部协议流程复杂度复杂招标、谈判、法务简化重点在协调风险类型商业风险、合规风险管理风险、协调风险管理重点盈利性、合规性协作性、效率性签署过程正式合同签署内部协议确认
关键差异总结
内部项目无需复杂的招投标流程协议主要用于明确分工而非商业保障更注重部门间沟通协调和资源整合效率
2.8 什么是项目授权要做什么
答 对项目进行授权和初始化以便确认相关的人知晓这个项目 形式文档化输出主要是项目章程
2.9 什么是项目章程
答
确认项目存在的文件包括对项目的确认、对项目经理的授权和项目目标的概述等。项目章程类似项目的授权书相当于对项目的正式授权表明项目可以有效地开始了。项目章程授权项目建立了项目经理的责任心 、发起人的主人翁意识及项目团队的团队意识。
2.10 项目经理有什么责任
答
开发计划 项目经理的首要任务就是开发计划。完善合理的计划对于项目的成功至关重要。项目经理 要在对 所有的合同、需求等熟知、掌握的基础上明确项目目标并就该.目标与项目客户达成一致同 时告知项目团队成员然后为实现项目目标制订基本的实施计划成本、进度、产品 质量组织实施 项目经理组织实施项目主要体现在两个方面第一设计项目团队的组织结构图对各职位的工 作内容进行描述并安排合适的人选组织项目开发第二对于大型项目项目经理 应该决定 哪些任务由项目团队完成哪些由承包商完成项目控制 在项目实施过程中项目经理要时时监视项目的运行根据项目实际进展情况调控项目 必要的 时候调整各项计划方案积极预防防止意外的发生及时解决出现的问题同时预测可能的 风险和问题保证项目在预定的时间、资金、资源下顺利完成。项目组织的领导者管理者决策者分析者计划者控制者组织者评价者协调者
2.11 软件项目生存期模型有什么基本特征
答
描述了开发的主要阶段定义了每一个阶段要完成的主要过程和活动规范了每一个阶段的输入和输出
2.12 有哪些常用的生存期模型给出它们的简单介绍和特点
答
模型名称简单介绍主要特点适用范围瀑布模型(Waterfall)按照需求分析、系统设计、编码、测试、维护的顺序逐步进行每个阶段完成后才进入下一阶段• 线性顺序执行阶段间有明确里程碑• 每个阶段都有详细文档输出• 前一阶段完成后才能进入下一阶段• 结构清晰管理简单• ✅优先选择前期需求明确且稳定的项目• 技术成熟、风险较低的项目• 编码人员经验较少的团队• 多个独立功能开发功能内遵循瀑布V模型(V-shaped)瀑布模型的改进版强调测试与开发阶段的对应关系是改进型瀑布模型的典型代表• 开发阶段与测试阶段一一对应• 强调早期测试计划和验证• 左臂开发过程右臂测试过程• 重视质量保证和缺陷预防• 前期需求明确的高质量要求项目• 安全关键型系统• 对质量要求极高的系统• 作为瀑布模型的改进选择快速原型模型(Rapid Prototyping)通过快速构建系统原型帮助用户理解需求在用户反馈基础上不断完善系统• 快速构建可运行的原型• 用户早期参与频繁反馈• 迭代式开发和改进• 降低需求理解风险• 必须使用用户无信息系统使用经验需求分析人员技能不足• 需求不明确或易变的项目• 用户界面要求高的系统• 可与增量、迭代综合使用增量模型(Incremental)将软件分解为多个增量每个增量都包含完整的开发周期逐步交付可用的软件产品• 分批次交付功能• 每个增量都是完整的子系统• 用户可以早期获得部分功能• 降低项目整体风险• 资金限制资金和成本无法一次到位• 需求不稳定优先采用增量迭代模型• 软件产品分多个版本发布• ⚠️注意全新系统需总体设计完成后开始螺旋式模型(Spiral)结合瀑布和原型模型优点通过风险驱动的迭代开发过程每个迭代都包含风险分析• 风险驱动的开发过程• 四象限确定目标、风险分析、开发测试、规划下轮• 适应性强可处理需求变化• 强调风险管理• 高不确定性不确定性因素很多很多东西前面无法计划• 高风险、大型复杂项目• 创新性技术项目• 需要有经验的开发团队快速应用开发(RAD)强调快速开发和交付通过并行开发、重用组件和用户参与来缩短开发周期• 开发周期短60-90天• 大量使用现有组件和工具• 用户深度参与开发过程• 并行开发多个模块• 时间紧迫的业务应用系统• 有丰富组件库的项目• 用户需求相对稳定的项目• 需要快速交付价值的项目渐近式阶段模型通过多个阶段逐步接近最终目标每个阶段都有明确的交付物和评估标准• 阶段性目标明确• 逐步逼近最终目标• 每阶段都有里程碑检查• 可根据评估结果调整方向• 探索性项目目标逐步明确• 需要阶段性评估和调整的长期项目• 研究开发类项目• 目标不够明确的项目敏捷型模型(Agile)强调个体和互动、工作软件、客户合作和响应变化通过短迭代周期快速交付价值• 短迭代周期1-4周• 持续交付可工作软件• 客户深度参与和反馈• 拥抱变化快速响应• 团队自组织和协作• 需求变化频繁的创新项目• 客户可频繁参与的项目• ❌不建议编码人员经验较少时• 小到中型团队项目• 可与原型模型综合使用 模型组合使用规则
增量、迭代和原型可以综合使用每一次增量或迭代都必须有明确的交付准则对于全新系统的开发必须在总体设计完成后再开始增量或并行 团队经验考虑
编码人员经验较少建议采用瀑布模型避免敏捷或迭代等复杂模型有经验团队可选择螺旋、敏捷等复杂模型 并行开发策略
多个独立功能开发可在需求阶段分功能并行但每个功能内都应遵循瀑布模型
3.项目范围计划——需求管理
3.1 什么是软件需求
答
软件需求是指用户对软件的功能和性能的要求。软件需求三个层次 业务需求组织机构或客户对系统产品高层次的目标要求由管理人员或市场分析人员确定用户需求用户通过使用本软件产品必须完成的任务用户协助提供功能需求开发人员必须实现的软件功能 软件需求规格 描述了软件系统应具有的外部行为即系统展现给用户的行为和执行的操作 #mermaid-svg-Sy5f5IF3XOhAqsPM {font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}#mermaid-svg-Sy5f5IF3XOhAqsPM .error-icon{fill:#552222;}#mermaid-svg-Sy5f5IF3XOhAqsPM .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-Sy5f5IF3XOhAqsPM .edge-thickness-normal{stroke-width:2px;}#mermaid-svg-Sy5f5IF3XOhAqsPM .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-Sy5f5IF3XOhAqsPM .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-Sy5f5IF3XOhAqsPM .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-Sy5f5IF3XOhAqsPM .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-Sy5f5IF3XOhAqsPM .marker{fill:#333333;stroke:#333333;}#mermaid-svg-Sy5f5IF3XOhAqsPM .marker.cross{stroke:#333333;}#mermaid-svg-Sy5f5IF3XOhAqsPM svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-Sy5f5IF3XOhAqsPM .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-Sy5f5IF3XOhAqsPM .cluster-label text{fill:#333;}#mermaid-svg-Sy5f5IF3XOhAqsPM .cluster-label span{color:#333;}#mermaid-svg-Sy5f5IF3XOhAqsPM .label text,#mermaid-svg-Sy5f5IF3XOhAqsPM span{fill:#333;color:#333;}#mermaid-svg-Sy5f5IF3XOhAqsPM .node rect,#mermaid-svg-Sy5f5IF3XOhAqsPM .node circle,#mermaid-svg-Sy5f5IF3XOhAqsPM .node ellipse,#mermaid-svg-Sy5f5IF3XOhAqsPM .node polygon,#mermaid-svg-Sy5f5IF3XOhAqsPM .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-Sy5f5IF3XOhAqsPM .node .label{text-align:center;}#mermaid-svg-Sy5f5IF3XOhAqsPM .node.clickable{cursor:pointer;}#mermaid-svg-Sy5f5IF3XOhAqsPM .arrowheadPath{fill:#333333;}#mermaid-svg-Sy5f5IF3XOhAqsPM .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-Sy5f5IF3XOhAqsPM .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-Sy5f5IF3XOhAqsPM .edgeLabel{background-color:#e8e8e8;text-align:center;}#mermaid-svg-Sy5f5IF3XOhAqsPM .edgeLabel rect{opacity:0.5;background-color:#e8e8e8;fill:#e8e8e8;}#mermaid-svg-Sy5f5IF3XOhAqsPM .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-Sy5f5IF3XOhAqsPM .cluster text{fill:#333;}#mermaid-svg-Sy5f5IF3XOhAqsPM .cluster span{color:#333;}#mermaid-svg-Sy5f5IF3XOhAqsPM div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-Sy5f5IF3XOhAqsPM :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;}#mermaid-svg-Sy5f5IF3XOhAqsPM .requirement*{fill:#f9f9f9!important;stroke:#333!important;stroke-width:2px!important;}#mermaid-svg-Sy5f5IF3XOhAqsPM .requirement span{fill:#f9f9f9!important;stroke:#333!important;stroke-width:2px!important;}#mermaid-svg-Sy5f5IF3XOhAqsPM .final*{fill:#e1f5fe!important;stroke:#01579b!important;stroke-width:3px!important;}#mermaid-svg-Sy5f5IF3XOhAqsPM .final span{fill:#e1f5fe!important;stroke:#01579b!important;stroke-width:3px!important;} 业务需求 用户需求 功能需求 系统需求 软件需求规格 非功能需求 质量特性 约束和假设 需求类型: 功能需求系统必须执行的功能非功能需求对实际使用环境所做的要求如性能要求可靠性 安全性 非功能需求比功能需求要求更严格更不易满足
3.2 什么是需求工程有什么作用
答
80年代中期形成了软件工程的子领域——需求工程需求工程指应用已证实有效的技术、方法进行需求分析确定客户需求帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。作用保证软件需求以一种技术形式描述一个产品应具有的功能性能和性质5个独立过程获取分析规格验证变更 3.3 什么是需求获取
答
需求获取是指通过与用户的交流对现有系统的观察及对任务进行 分析从而开发、捕获和修订用户的需求。主要任务和用户方的领导层业务层人员的访谈式沟通目的从宏观上把握用户的具体需求方向和趋势了解现有的组织架构业务流程硬件环境软件环境现有运行系统等具体情况和客观的信息建立起良好的沟通渠道和方式。
3.4 需求获取有哪些活动
答
了解客户方的所有用户类型及潜在的类型然后根据他们的要求来确定系统的整体目标和系统的工作范围。进行需求调查对用户进行访谈和调研。需求分析人员对收集到的用户需求做进一步的分析和整理需求分析人员将调研的用户需求以适当的方式呈交给用户方和开发方的相关人员。大家共同确认需求。
3.5 需求获取需要注意什么
识别真正的客户正确理解客户的需求具备较强的忍耐力和清晰的思维说服和教育客户需求获取阶段一般需要建立需求分析小组进行充分交流互相学习同时要实地考察访谈收集相关资料进行语言交流必要时可以采用图形、表格等工具。
3.6 什么是需求分析
答 需求分析又称为需求建模 需求分析是为最终用户所看到的系统建立一个概念模型是对需求的抽象描述并尽可能多地捕获现实世界的语义。 应有足够的重视并分配充足的时间和人力要让有经验的系统分 析员负责切忌让项目新手或程序员负责 需求分析的结果是提供需求分析模型它是产品的原型样本使最 终产品更接近于解决需求提高了用户对产品的满意度从而使产 品成为真正优质合格的产品
3.7 需求分析有哪些活动
答
以图形表示的方式描述系统的整体结构包括系统的边界与接口。通过原型、页面流或其他方式向用户提供可视化的界面用户可以对需求做出自己的评价。以模型描述系统的功能项、数据实体、外部实体、实体之间的关系 、实体之间的状态转换等方面的内容。需求分析的基本策略是采用头脑风暴、专家评审、焦点会议组等方式 进行具体的流程细化、数据项的确认必要时可以提供原型系统和明确的业务流程报告、数据项表并能清 晰地向用户描述系统的业务流设计目标用户方可以通过审查业务流程报告、数据项表及操作开发方提供的原 型系统来提出反馈意见并对可接受的报告、文档签字确认。在项目需求分析阶段对问题的描述要足够细致 应用背景、功能要求、性能要求、操作界面要求、与其他软件的接口要求以及对项目进行评估的各种评价标准
3.8 什么是需求规格编写
答
软件需求规格的编制是为了使用户和软件开发者双方对该软件的初 始规定有一个共同的理解使之成为整个开发工作的基础需求分析完成的标志是提交一份完整的软件需求规格说明书 (SRS)需求规格说明书为客户和开发者之间建立一个约定准确地陈述了要交付给客户什么。 软件需求规格说明书的格式可以根据项目的具体情况采用不同的格式没有统一的标准
3.9 什么是需求验证
答
定义需求规格提交后开发人员需要与客户对需求分析的结果进行验证 以需求规格说明书为输入。目的以求需求规格中定义的需求必须正确、准确地反映用户的意图作用验证需求的正确性及其质量能大大减少项目后期的返工现象
3.10 需求验证要保证什么性质
答
正确性一致性完整性可行性必要性可检验性可跟踪性最后的签字
3.11 为什么要有需求变更管理
答
需求变更是软件项目一个突出的特点也是软件项目最为普遍的一个特点需求变更是导致项目失败的主要原因之一。需求变更成本可以占项目总成本的40
3.12 需求变更管理要完成什么工作
答
**建立需求基线。**需求基线是需求变更的依据。此后每次变更并 经过评审后都要重新确定新的需求基线**确定需求变更控制过程。**制定变更控制流程并形成文档建立变更控制委员会 (SCCB)或相关职能的类似组织 。负责裁定接受哪些变更**进行需求变更影响分析。**需求变更先申请然后评估**跟踪所有受需求变更影响的工作产品。**软件计划、产品、活动 都要进行相应的变更以和更新的需求保持一致跟踪每项需求的状态衡量需求稳定性
3.13 请举例需求变更流程
答
根据变更输入按照变更控制系统规定的审批程序执行通过严格审查变更申请后决定项目变更是否应得到批准或拒绝。 #mermaid-svg-MDplPWZi8J05k4DY {font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}#mermaid-svg-MDplPWZi8J05k4DY .error-icon{fill:#552222;}#mermaid-svg-MDplPWZi8J05k4DY .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-MDplPWZi8J05k4DY .edge-thickness-normal{stroke-width:2px;}#mermaid-svg-MDplPWZi8J05k4DY .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-MDplPWZi8J05k4DY .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-MDplPWZi8J05k4DY .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-MDplPWZi8J05k4DY .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-MDplPWZi8J05k4DY .marker{fill:#333333;stroke:#333333;}#mermaid-svg-MDplPWZi8J05k4DY .marker.cross{stroke:#333333;}#mermaid-svg-MDplPWZi8J05k4DY svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-MDplPWZi8J05k4DY .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-MDplPWZi8J05k4DY .cluster-label text{fill:#333;}#mermaid-svg-MDplPWZi8J05k4DY .cluster-label span{color:#333;}#mermaid-svg-MDplPWZi8J05k4DY .label text,#mermaid-svg-MDplPWZi8J05k4DY span{fill:#333;color:#333;}#mermaid-svg-MDplPWZi8J05k4DY .node rect,#mermaid-svg-MDplPWZi8J05k4DY .node circle,#mermaid-svg-MDplPWZi8J05k4DY .node ellipse,#mermaid-svg-MDplPWZi8J05k4DY .node polygon,#mermaid-svg-MDplPWZi8J05k4DY .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-MDplPWZi8J05k4DY .node .label{text-align:center;}#mermaid-svg-MDplPWZi8J05k4DY .node.clickable{cursor:pointer;}#mermaid-svg-MDplPWZi8J05k4DY .arrowheadPath{fill:#333333;}#mermaid-svg-MDplPWZi8J05k4DY .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-MDplPWZi8J05k4DY .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-MDplPWZi8J05k4DY .edgeLabel{background-color:#e8e8e8;text-align:center;}#mermaid-svg-MDplPWZi8J05k4DY .edgeLabel rect{opacity:0.5;background-color:#e8e8e8;fill:#e8e8e8;}#mermaid-svg-MDplPWZi8J05k4DY .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-MDplPWZi8J05k4DY .cluster text{fill:#333;}#mermaid-svg-MDplPWZi8J05k4DY .cluster span{color:#333;}#mermaid-svg-MDplPWZi8J05k4DY div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-MDplPWZi8J05k4DY :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;}#mermaid-svg-MDplPWZi8J05k4DY .stakeholder*{fill:#e1f5fe!important;stroke:#01579b!important;}#mermaid-svg-MDplPWZi8J05k4DY .stakeholder span{fill:#e1f5fe!important;stroke:#01579b!important;}#mermaid-svg-MDplPWZi8J05k4DY .process*{fill:#f3e5f5!important;stroke:#4a148c!important;}#mermaid-svg-MDplPWZi8J05k4DY .process span{fill:#f3e5f5!important;stroke:#4a148c!important;}#mermaid-svg-MDplPWZi8J05k4DY .decision*{fill:#fff3e0!important;stroke:#e65100!important;}#mermaid-svg-MDplPWZi8J05k4DY .decision span{fill:#fff3e0!important;stroke:#e65100!important;}#mermaid-svg-MDplPWZi8J05k4DY .action*{fill:#e8f5e8!important;stroke:#1b5e20!important;}#mermaid-svg-MDplPWZi8J05k4DY .action span{fill:#e8f5e8!important;stroke:#1b5e20!important;}#mermaid-svg-MDplPWZi8J05k4DY .ignore*{fill:#ffebee!important;stroke:#c62828!important;}#mermaid-svg-MDplPWZi8J05k4DY .ignore span{fill:#ffebee!important;stroke:#c62828!important;} 需求方 变更申请 开发方 选择变更方式 忽略 SCCB评估 项目经理自行决定 根据评估结果 拒绝 接受本次修改 下个版本再修改 修改合同相关信息 修改相关需求 修改相应项目计划 3.14 有哪些传统需求分析方法
答
原型分析方法基于数据流的建模方法结构化分析的主要方法基于UML需求建模方法功能列表法
3.14注 什么是结构化的分析方法
答
结构化分析方法的定义SA,Structured Analysis
20世纪70年发展起来的是一种自顶向下逐步求精的分析方法根据软件内部数据传递、变换的关系进行分析的结构化分析方法是很多其他方法的基础
3.14.1 原型分析方法
答
原型分析方法是通过不断评价原型来确定需求的方法在需求分析阶段通过不断优化这个原型来最终确定项目需求实践中可以采用原型建模工具建模如 Axure 等快速原型设计工 具与用户很容易交流。
3.14.2 数据流建模的方法
答
将现实世界描绘为数据在信息系统中的流动以及在数据流动过程中数据向信息的转化数据流图 (DFD) 、数据字典 (DD) 、实体联系图 (ERD) 、 系统流程图等都是数据流分析技术数据流图DFD是一种描述软件系统逻辑模型的图形符号使用4 种基本元素来描述系统的行为即过程、实体、数据流和数据存储 3.14.3 基于UML建模的方法
答
一种面向对象的分析方法。从用户角度看需求将功能需求描述为 一些用例use case 一个用例就是系统向用户提供一个有价值的结果的某项功能。用例捕捉的是功能性需求。所有用例结合起来就构成了“用例模型”描述系统的全部功能 方法主要通过UML的用例视图、顺序视图、活动视图等表达需求模型 一个系统往往可以从不同的角度进行观察从一个角度观 察到的系统就构成系统的一个视图view 分析流程 识别出系统的Actor描述主要的Use case实现用例视图Use case Diagram实现顺序视图Sequence Diagram实现活动视图Activity Diagram状态视图State Diagram等
3.14.4 功能列表法
答
功能列表feature list方法是对项目的功能需求进行详细说明的一种方法。是基于功能特性及其层次关系来描述需求的方法。
需求类别功能/性能名称/标识描述特性Feature AA.1…A.n特性Feature BB.1…B.n特性Feature CC.1…
3.14.5 敏捷项目需求分析有哪几个关键要素
答
产品待办事项列表 细化产品待办事项列表 用户故事
用户故事模板评价用户故事用户故事迭代优先级
3.14.5注0 敏捷项目需求分析的背景
答
需求不断变化、风险大或不确定性高的项目其范围逐渐明确敏捷思维认为对于需求可以“渐进明细”以便应对变化.敏捷方法将需求列入未完项不断构建和审查原型并通过发布多个版本来明确需求。
3.14.5注1 什么是产品代办事项列表
答
产品待办事项列表是一个敏捷团队管理开发过程的核心所有的活动和交付物都围绕它来进行。产品待办事项列表可以帮助我们对将要做的事情有一个整体的认识以及可以知道我们现在的状态。通过产品待办事项列表梳理活动即将被实现的产品待办事项会得到澄清变得明确粒度也拆得更小。
3.14.5注2 如何细化产品代办事项列表
答 每个迭代中获得细化的待办事项列表产品待办事项列表 ➡Sprint订单 Sprint订单是指 从产品待办事项列表Product Backlog中选择出来的 在当前Sprint迭代中需要完成的 具体的、细化的任务清单 细化的过程就是编写用户故事的过程即每个迭代的需求是通过用户故事描述的。 细化会议上产品负责人有很多方法处理待办事项列表的细化准备 与会议其中包括 鼓励团队在开发人员、测试人员、业务分析人员和产品负责人三方面开展合作一起讨论和撰写故事。把整个故事的概念呈现给团队。团队进行讨论并根据需要将其细化为许多故事。与团队一起寻找各种方法探索和撰写故事确保所有的故事都足够小以便团队能源源不断地交付完成的工作
3.14.5注3 什么是用户故事模板
答
用户故事按照一定的语法形式进行表示不使用技术语言来描述 只是以客户能够明白的、简短的形式表达。需求包括功能性需求和非功能性需求用户故事可以描述功能性需求也可以描述非功能需求。
3.14.5注6 如何评价一个用户故事
答
用户故事INVEST的特点 Iindependent代表独立的 Nnegotiable代表可协商的 Vvaluable代表对用户或客户有价值的* Eestimable代表可估计的 Ssmall代表小的 Ttestable代表可测试的
3.14.5注7 用户故事有哪些优先级
答
迭代开发是基于用户故事优先级进行的因此需要对用户故事的优 先级进行排序。用户故事的排序遵守一定的规则如MoSCoW方法
Must Have必须做的/必须要有的Should Have应该做的/应该有的Could Have可以做的/可以有的Won’t Have不要做的/不能有的
4. 项目范围计划——任务分解
4.1 什么是任务分解
答
将一个项目分解为更多的工作 细目或者子项目使项目变得更 小、更易管理、更易操作任务分 解结果WBSWork Breakdown Structure:任务分解结构
4.2 什么是WBS
答
WBS是把所有项目工作逐层分解到较小的、便于管理的要素可交付成果。 WBS 的组成元素有助于项目干系人检查最终的产品 WBS是用来确定项目范围的必须包括项目的所有工作。 WBS 是管理项目范围的基础详细描述了项目所要完成的工作 没有包含在WBS中的工作就不是项目范围内的工作都不要做。如果要做必须通过范围控制过程。WBS的编制需要**“全员参与”项目经理主要发挥“整合者”**的作用。WBS的最底层组织部分是工作包Work Package。 WBS 的最低层元素是能够被评估的可以安排进度的和被追踪的 在WBS中可以单独列出一个**“项目管理”**分支包括项目管理相关工作。
4.3 WBS有什么作用
答
明确和准确说明项目范围工作分解结构定义项目边界明确需要做的工作确定所需要的技术和人力资源明确人员职责进行时间成本和资源估算提高估算的准确性确定工作内容和工作顺序并根据实践情况进行调节和控制估计项目整体和全过程费用有助于防止需求蔓延
4.4 有几种WBS分解的形式 提纲式WBS也称为清单式WBS 最常用项目管理软件中常使用 适用于大型项目 组织结构图式WBS也称为图表式WBS 优点直观结构清晰缺点不易修改不适用大型项目
4.5 工作分解有哪些层次
答
项目群叫大项目也可以叫工程项目项目任务完成项目必须进行的工作活动完成任务需要做什么。工作包活动的构成单元它体现了活动是如何做的。工作单元一般的WBS中不需要分解到具体动作层。
4.6 如何理解工作包work package
答 工作包Work Package是WBS中最底层的项目可交付成果工作包可以再细分为具体动作。 项目经理通常只负责到工作包的层次负责该工作包的团队成员负责把工作包细分为实际工作。 个工作包必须由一个人或者一个部门来负责而不能由两个或两个以上的人或部门来负责。 工作包单元的周期应该是最短周期/ 应明确本工作包与其他工作包之间的关系 能够对工作包进行进度安排成本估算监视和控制 要求: 逻辑上不可再分80h易于估算明确责任人 一个人两周能干完的工作或将一个 人80小时能干完的工作称为一个工作包
4.7 WBS的编码有什么用
答
为了简化信息交流过程常利用编码技术对WBS进行信息转换。通常对每一层的每项任务需要按照来编号。
4.8 什么是WBS字典
答
WBS字典是在制定WBS过程中生成并与WBS配合使用的说明性文件WBS具体工作要素的阐述通常收集在WBS字典(WBS dictionary) 中同时也包括一些其他信息的阐述
4.9 有哪些任务分解的方法
答
模板参照 许多应用领域都有标准或半标准的wbs它们可以当做模板参考使用 类别方法 许多项目有相同或相似周期和因此形成的相同或相似的工作细目要 求可以采用类似项目的WBS作为参考 自上而下 自顶向下方法从一般到特殊的方向进行自顶向下方法需要有更多的逻辑和结构它也是创建WBS的最好方法如果WBS开发人员对项目比较熟悉或者对项目大局有把握可以使用自顶向下方法 自下而上 自底向上是从特殊向一般方向进行的。如果对于项目人员来说这个项目是一个崭新的项目可以采用自底向上方法开发WBS。
4.10 任务分解的基本步骤是怎么样的
答
确定分解标准 按照生存期阶段或产品组成分解不能同时使用两种标准进行分解 确认并分解项目的组成要素。确定分解是否详细确定项目交付成果可以编制WBS字典验证分解的正确性建立一套编号系统 必要和充分性检查完整和模糊性检查可计划和控制性检查分配工期、预算、资源和责任人 4.11 工作分解中需要注意哪些问题
答
不要把工作分解结构变成物品清单 分解出的工作包应是一项项的行动而不能仅仅用名词来表达。 不要考虑活动之间的先后顺序 工作分解结构的目的是清楚地界定实现项目目标所需执行的具体活动并不关心 究竟先做那个、后做那个。活动之间的先后顺序等到确定关键路径时再考虑。 不要试图去做画蛇添足的事 如果你以小时为单位来分解工作而又无法把工作控制到这个程度那你不妨将 工作分解到以天或周为单位就打住否则既浪费了时间又办不成事情 项目分解的原则 在各层次上保持项目内容的完整性不能遗漏工作单元。一个项目单元只能从属于某一个上层单元不能交叉。项目单元应能区分不同的责任人和不同的工作内容。项目结构分解应能方便工期、成本、质量等的控制。详细程度适中。
4.12 什么是项目可交付结果与里程碑事件
答
通过WBS分解出项目的工作任务后还要进一步将每项任务的交付结果即把项目的中间结果定义出来目的是使项目组明白完成 WBS的任务后输出的产品是什么。在项目的一系列可交付结果中可能会有一些事件的开始或结束对项目目标的有效实现至关重要这些事件称之为里程碑事件 里程碑事件必须是项目可交付结果完整的中间产品对这一事件的描述必须精确必须被所有项目参与人所准确理解里程碑事件的完成可度量
4.13 工作分解有哪些困难该如何解决
答
对于不是很大的项目很有效而对于耗时长成本大的项目则分解成本太高。工作包的成本有时候难以确定的新技术的应用会改变项目的进度和预算。在工作分解结构的技术层各种活动直接相关性非常复杂难以用图表表达。
为解决上述困难可以为项目预留一部分资源包括时间、进度、 资源给不确定因素。
4.14 工作分解有哪些建议
答
工作分解结构必须面向可交付成果的工作分解结构必须符合项目的范围工作分解结构的底层应该支持计划和控制工作分解结构中的元素必须有人负责而且只由一个人负责尽管实际上可能需要多个人参与工作分解结构的指导每个级别的工作分解结构把上一级的一个 元素分为4-7个新的元素同一级的元素的大小应该相似工作分解结构并非是一成不变的
4.15 如何展开敏捷项目的任务分解
答
在敏捷开发过程中通过用户故事来将需求具体化成可以进行迭代开发的一个个现实的可见的开发任务。用户故事是站在用户的角度所描述的故事是用户所能看懂的故事 是对需求的细化和切分敏捷项目的分解过程就是将史诗故事Epic分解成用户故事。
Epic–Feature–user Story–Task
敏捷分解检验,分解完成了用户故事之后应该给出接收标准, 它可以作为用户测试用户故事的依据. 这个接收标准一般写在故事卡片的后面以确保这个用户故事是可理解的而且可以方便团队讨论这个用户故事的业务价值。 敏捷项目任务分解可以是对backlog列表进行细化的过程
5. 项目成本计划——成本估算
5.1 什么是成本估算有什么作用
答 成本管理是确保项目在预算范围之内的管理过程包括成本估算、成本预算、成本控制等过程。 成本估算是对完成项目所需费用的估计和计划 估算不是很准确有误差项目经验数据非常重要不要太迷信某些数学模型 重要性和意义
软件成本估算是成本管理的核心成本估算贯穿于软件的生存期。成本估算是项目计划中的一个重要组成部分要实行成本控制首先要进行成本估算软件成本估算一直是软件工程和软件项目管理中最具挑战、最为重要的问题
5.2 成本分为哪几类有哪些成本
答
直接成本 指与项目有直接关系的成本费用是与项目直接对应的包括人员的工资、材料费用、外包外购成本等包括开发成本、管理成本、质量成本等。人的劳动的消耗所需要的代价是软件产品的主要成本即开发成本 。 间接成本 如房租、水电、员工福利、税收等 不能归属于一个具体的项目 是企业的运营成本可以分摊到各个项目中
5.4 什么是软件项目规模
答
软件项目规模即工作量 是从软件项目范围中抽出的软件功能然后确定每个软件功能所必须执行的一系列软件工程任务。是成本的主要因素是成本估算的基础 软件成本估算是预测开发一个软件系统所需要的总工作量的过程。软件项目成本指软件开发过程中所花费的工作量及相应的代价。 LOC (Lines of Code) 代码行 源代码长度的测量FP (Function Point) 功能点 用系统的功能数量来测量人月 人天 人年
5.5 有哪些影响软件项目成本的因素
答
耗用资源的数量和价格 中间产品和服务、市场人力资源、硬件、软件的价格也对成 本产生直接的影响。价格对项目预算的估计影响很大。 项目工期 项目的费用由直接费用和间接费用组成一般工期和直接费用成反比和间接费用成正比缩短工期需要更多的、技术水平更高的人员直接成本费用就会增加。 项目质量 质量总成本由质量故障成本和质量保证成本组成。质量故障成本指为了排除产品质量原因所产生的故障 保证产品重新恢复功能的费用。质量保证成本为了保证和提高产品质量而采取的技术 措施所消耗的费用。 项目管理水平
高的管理水平可以提高预算的准确度加强对项目预算的执行和监 管对工期的控制严格限制在计划许可的范围之内对设计方案和 项目计划更改造成的成本增加、减少和工期的变更可以较为有效 地控制减少风险的损失等。 5.6 成本估算的过程是怎么样的给出成本估算的方法。
答
估算输入 项目需求 工作分解结构WBS 资源计划 资源单位价格进度计划 历史信息 估算处理 代码行估算法、功能点估算法、用例点估算法、类比 (自顶向下) 估算法、自下而上估算法、参数估算法、专家估算法 估算输出 估算通常以货币单位表达如元、法郎、美元等这个估算便是成 本估算的结果也可用人月、人天 或人小时这样的单位这个估算结果便是项目规模估算的结果。有时用复合单位。成本估算是一个不断优化的过程。估算说明 ①工作范围的描述 ②说明估算的基础和依据
5.6.1 代码行估算法。
答
是一种面向规模的度量从软件程序量的角度定义项目规模。 与具体的编程语言有关 分解足够详细 有一定的经验数据类比和经验方法 LOC(Lines of Code) 代码行通常采用非注释的源代码行。 可计算每千行代码(KLOC)的错误数缺陷数成本文档页数。 简单易行但代码行数依赖选择的硬件和软件因此并不被认为是软件度量的最优方法。
5.6.2 功能点估算法FP
答 功能点分析中系统分为5个组件 外部输入、外部输出、外部查询、外部接口文件因为这些组件的每一个都处理文件 因此被称为事务内部逻辑文件 构成逻辑信息的存储地 它是一种按照统一方式测定软件功能的方法最后的结果是一个数 。 这个结果数可以用来估计代码行数成本和工期。与实现的语言和技术没有关系。用系统的功能数量来测量其规模。通过评估、加权、量化得出功能点。 功能点公式 FP UFC*TCF UFC未调整功能点计数TCF技术复杂度因子 功能点作为度量软件规模的方法已经被越来越广泛地接受
5.6.2.1 功能点估算中的系统组件FP
答 外部输入EI 外部输入是最终用户或其他程序用来增加、删除或改变程序数据的屏幕screen、表单 form、对话框dialog或控制信号 control signal等 外部输出EO 外部输出是程序生成供最终用户或其他程序使用的屏幕、报表 report、图表graph 或控制信号等。例如报表和出错信息 等。 外部查询EQ 外部査询是输入/输出组合其中一个输入引出一个即时的简单输出。外部查询是一个输入引出一个即时的简单输出。没有处理过程。 外部接口文件 EIF 外部接口文件是受其他程序控制的文件是用户可以识别的一组逻辑相关数据这组数据只能被引用。数据完全存在于应用的外部并且由另一个应用维护。外部接口文件是另外一个应用的内部逻辑文件。 内部逻辑文件ILF 内部逻辑文件是用户可确认的、在应用程序内部维护的、逻辑上相关联的最终用户数据或控制信息如一个平面文件或者关系数据库中的一个表。完全存在于应用的边界之内并且通过外部输入维护是逻辑主文件的数目。
5.6.2.2 给出功能点估算法的步骤 #mermaid-svg-N6PC9R1Wp3E7mLsG {font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}#mermaid-svg-N6PC9R1Wp3E7mLsG .error-icon{fill:#552222;}#mermaid-svg-N6PC9R1Wp3E7mLsG .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-N6PC9R1Wp3E7mLsG .edge-thickness-normal{stroke-width:2px;}#mermaid-svg-N6PC9R1Wp3E7mLsG .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-N6PC9R1Wp3E7mLsG .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-N6PC9R1Wp3E7mLsG .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-N6PC9R1Wp3E7mLsG .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-N6PC9R1Wp3E7mLsG .marker{fill:#333333;stroke:#333333;}#mermaid-svg-N6PC9R1Wp3E7mLsG .marker.cross{stroke:#333333;}#mermaid-svg-N6PC9R1Wp3E7mLsG svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-N6PC9R1Wp3E7mLsG .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-N6PC9R1Wp3E7mLsG .cluster-label text{fill:#333;}#mermaid-svg-N6PC9R1Wp3E7mLsG .cluster-label span{color:#333;}#mermaid-svg-N6PC9R1Wp3E7mLsG .label text,#mermaid-svg-N6PC9R1Wp3E7mLsG span{fill:#333;color:#333;}#mermaid-svg-N6PC9R1Wp3E7mLsG .node rect,#mermaid-svg-N6PC9R1Wp3E7mLsG .node circle,#mermaid-svg-N6PC9R1Wp3E7mLsG .node ellipse,#mermaid-svg-N6PC9R1Wp3E7mLsG .node polygon,#mermaid-svg-N6PC9R1Wp3E7mLsG .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-N6PC9R1Wp3E7mLsG .node .label{text-align:center;}#mermaid-svg-N6PC9R1Wp3E7mLsG .node.clickable{cursor:pointer;}#mermaid-svg-N6PC9R1Wp3E7mLsG .arrowheadPath{fill:#333333;}#mermaid-svg-N6PC9R1Wp3E7mLsG .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-N6PC9R1Wp3E7mLsG .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-N6PC9R1Wp3E7mLsG .edgeLabel{background-color:#e8e8e8;text-align:center;}#mermaid-svg-N6PC9R1Wp3E7mLsG .edgeLabel rect{opacity:0.5;background-color:#e8e8e8;fill:#e8e8e8;}#mermaid-svg-N6PC9R1Wp3E7mLsG .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-N6PC9R1Wp3E7mLsG .cluster text{fill:#333;}#mermaid-svg-N6PC9R1Wp3E7mLsG .cluster span{color:#333;}#mermaid-svg-N6PC9R1Wp3E7mLsG div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-N6PC9R1Wp3E7mLsG :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 确定功能点的类型 识别项目的范围和边界 人机交互功能点分析 数据类型功能点分析 未调整的功能点数量 确定功能点调整因子 调整后的功能点数量 答 确定应用必须包含的功能 对于于每一项功能根据5项系统组件得到5类功能点数目 在估算中对5类功能计数项中的每一类功能计数项按其复杂性的不同分为简单低、一般中和复杂高3个级别。确定复杂度权重因素对功能点进行加权得到未调整的功能点数量得到该产品的未调整功能点计数UFC
项目简单低一般中复杂高外部输入×3×4×6外部输出×4×5×7外部查询×3×4×6外部接口文件×5×7×10内部逻辑文件×7×10×15 计算项目中14个技术复杂度因子TCF。取值范围是0~5TCF0.650.01×∑Fi 计算调整功能点FP 功能点总数UFC×调整系数TCF
5.6.3 简述用例点估算法的计算流程
答
完整计算流程总结
UAW Σ(角色数量 × 角色权重)1-3UUCW Σ(用例数量 × 用例权重)UUCP UAW UUCWTCF 0.6 (0.01 × Σ(Ti × Wi))0-5分EF 1.4 (-0.03 × Σ(Ei × Wi))0-5分UCP UUCP × TCF × EF工作量 UCP × 生产率因子 计算未调整的角色权值 (UAW)
公式 UAW Σ(角色数量 × 对应权重)角色权重分类 简单角色权重 1通过API交互一般角色权重 2通过协议交互如TCP/IP、FTP、HTTP等复杂角色权重 3通过图形用户界面交互 计算未调整的用例权值 (UUCW) 公式 UUCW Σ(用例数量 × 对应权重)用例权重分类 简单用例权重 5≤3个事务一般用例权重 104-7个事务复杂用例权重 15≥8个事务 计算未调整的用例点 (UUCP) 公式* UUCP UAW UUCW 计算技术复杂度因子 (TCF) 和环境因子 (EF) 技术复杂度因子 (TCF) 公式 TCF 0.6 (0.01 × TFactor 其中TFactor Σ(Ti × Wi) Ti第i个技术因子的评分值0-5分Wi第i个技术因子的权重 环境因子 (EF) 公式 EF 1.4 (-0.03 × EFactor) 其中EFactor Σ(Ei × Wi) Ei第i个环境因子的评分值0-5分 Wi第i个环境因子的权重 计算调整的用例点 (UCP) 公式 UCP UUCP × TCF × EF 计算工作量 (Man-hours) 公式 工作量 UCP × 生产率因子 生产率因子确定 项目简单每用例点 20人时 项目一般每用例点 28人时 项目复杂每用例点 36人时
5.6.4 类比估算法
答 是一种自上而下的估算形式 估算人员根据以往的完成类似项目所消耗的总成本或工作量 来推算将要开发的软件的总成本或工作量然后按比例将它分配到各个开发任务单元中 自上而下的估算又称类比估算通常在项目的初期或信息不足时进行此时只确定了初步的工作分解结构分解层次少估算精度较差。 类比估算中需要评价不同项目间的相似程度。 不加权的欧氏距离加权的欧氏距离
$$ distance(P_i, P_j) \sqrt{\frac{\sum_{k1}^{n} \delta(P_{ik}, P_{jk})}{n}}
\delta(P_{ik}, P_{jk}) \begin{cases} \left(\frac{|P_{ik} - P_{jk}|}{\max_k - \min_k}\right)^2, k \text{是连续的} \ 0, k \text{是分散的且} P_{ik} P_{jk} \ 1, k \text{是分散的且} P_{ik} \neq P_{jk} \end{cases} $$
由于相似度计算比较麻烦类比估算基本上采用主观推断 很少采用相似度计算方法。
5.6. 5 自下而上估算法
答 通常是在项目开始以后或者WBS已经确定的项目需要进行准确估算的时候釆用。 优点准确度较好 缺点需要花费一定的时间 估算本身也需要成本支持 可能发生虚报现象
5.6.6 三点估算法
答
考虑项目的不确定性与风险 3种估算值最可能成本CM、最乐观成本CO、最悲观成本CP三角分布预期成本CE(COCMCP)/3贝塔分布预期成本CE(CO4CMCP)/6
5.6.7 介绍下参数估算法
答 也称为算法模型或经验导出模型是一种使用项目特性参数建立数学模型来估算成本的方法是通过大量的项目数据进行数学分析导出的模型是一种统计技术 找到软件工作量的各种成本影响因子并判定它对工作量所产生影响的程度是可加的、乘数的还是****指数的以期得到最佳的模型算法表达形式 当某个因子只影响系统的局部时一般认为它是可加的当某个因子对整个系统具有全局性的影响时则认为它是乘数的或指数的 模型分类 基于回归分析的模型 静态单变量模型动态多变量模型 基于神经网络的模型 使用条件 具有良好的项目数据为基础存在成熟的项目估算模型 特点 比较简单,而且也比较准确如果模型选择不当或者数据不准,也会导致偏差
5.6.7.1 什么是静态单变量模型
答
静态单变量模型 的整体公式: Eab*SC E:以人月表示的工作量 a,b,c:经验导出的系数 S:主要的输入参数(通常是LOC,FP等)
5.6.7.2 下COCOMO 81 模型
答 COCOMO 81Constructive Cost Model 1981是Barry Boehm在1981年提出的软件成本估算模型是最著名的软件工作量估算模型之一。 模型等级:COCOMO 81有3个等级的模型级别越高模型的参数约束越多 基本COCOMO - 相关信息极少情况下使用中等COCOMO - 需求确定之后使用高级COCOMO - 设计完成后使用 项目模式类型:COCOMO 81根据项目特征将软件项目分为三种模式 有机模式Organic - 小型项目团队经验丰富需求相对稳定 嵌入式模式Embedded - 复杂的硬件/软件系统严格约束条件 半有机模式Semidetached - 介于有机和嵌入式之间的中等规模项目 核心公式 P M A × S E × ∏ i 1 n ( E M i ) PM A \times S^E \times \prod_{i1}^{n}(EM_i) PMA×SE×i1∏n(EMi) Effort a × KLOC b × F \text{Effort} a \times \text{KLOC}^b \times F Efforta×KLOCb×F 其中 PM/Effort项目工作量人月 A/a规模因子常数 S/KLOC软件规模千行代码 E/b规模指数 EM i 第 i 个工作量乘数因子 F调整因子 \text{其中} \begin{align} \text{PM/Effort项目工作量人月} \\ \text{A/a规模因子常数} \\ \text{S/KLOC软件规模千行代码} \\ \text{E/b规模指数} \\ \text{EM}_i\text{第}i\text{个工作量乘数因子} \\ \text{F调整因子} \end{align} 其中PM/Effort项目工作量人月A/a规模因子常数S/KLOC软件规模千行代码E/b规模指数EMi第i个工作量乘数因子F调整因子 参数取值 调整因子F的取值取决于建模等级以及目标模式。由专家决定。基于数据库的项目要求 参数值a、b取决于建模等级以及目标模式通过历史数据统计得出用于准确估算软件开发工作量。
5.6.8 下专家估算法
答
专家估算法是由一些被认为是该任务专家的人来进行的一个专家可能会有偏见最好由多位专家进行估算取得多个估算值最后得出综合的估算值 因此引入Delphi专家估算法 每位专家根据软件系统规格说明书进行估算**保证专家不见面**协调员整理专家估算给出平均期望值三角分布/贝塔分布在此基础上各位专家进行再次估算以上过程可重复多次直到专家评估值之差达到要
5.7 什么是项目成本预算
答
成本预算是将项目的总成本按照项目的进度分摊到各个工作单元中去成本预算的目的是产生成本基线作为度量项目成本性能的基础
5.8 什么是成本基线
答
成本基线是每个时间阶段内的成本.是项目管理者度量或监控项目的依据。
6. 项目进度计划
6.1 什么是进度进度计划为什么重要
答
进度是对执行的活动和里程碑制定的工作计划日期表重要性 按时完成项目是项目经理最大的挑战时间是项目规划中灵活性最小的因素进度问题是项目冲突的主要原因
6.2 如何制定出进度计划
答
根据WBS分解出主要的任务活动 任务是对WBS工作包的进一步细分。 确立任务活动之间的关联关系然后估计每个任务活动需要的资源、时间最后编制出项目的进度计划。
6.3 任务之间的关系有哪几种如何确定关系
答 前置活动任务—〉后置活动任务 确定任务活动之间关联关系的依据 硬逻辑关系 强制性依赖关系客观的不可违背的软逻辑关系 人为的主观的外部依赖关系项目活动与非项目活动之间
6.4 进度管理有哪几种图示方法
答
网络图 network diagramming 节点法/单代号网络图 PDM Precedence Diagramming Method箭线法/双代号网络图 ADM Arrow Diagramming Method 甘特图 Gantt 棒状甘特图三角形甘特图 里程碑图资源图燃尽图/燃起图
6.5 介绍进度管理几种图示方法。
答
6.5.1 网络图
网络图是活动排序的一个输出展示项目中各个活动以及活动之间的逻辑关系 PDM ADM
6.5.2 甘特图
显示基本的任务信息可以查看任务的工期、开始时间和结束时间以及资源的信息。只有时标没有活动的逻辑关系 6.5.3 里程碑图 6.5 4 资源图 6.5.5 燃尽图/燃起图
在项目完成之前燃尽图是对待完成的工作的可视化表示燃起图是对已完成的工作的可视化表示。 对比维度燃尽图Burn Down Chart燃起图Burn Up Chart展示内容仅展示从项目开始到终点的剩余工作量的减少展示完成工作量以及项目总工作量的时间变化图形特征理想情况下是向下的曲线随着剩余工作完成烧尽至零通过两条线完成工作量线和总工作量线展示进度与目标目标明确性目标相对隐含主要关注剩余工作量目标非常明确总工作量线清晰显示项目目标范围变化处理不直接显示范围变化如果增加任务剩余工作量会突然增加可能使读者难以理解原因能够清晰表现项目范围变化总工作量线会随着变更而调整范围变更影响范围发生变化时需要重新绘制图表项目范围变化时总工作量线会上升或下降直观反映范围变动工作量增加显示不直接显示工作量的增加通过总工作量线的变化直观显示工作量增减
6.6 介绍几种任务历时估计的方法
答 定额估算法适合规模较小的项目。 TQ/(R*ST活动历时Q任务规模R人力数量S工作效率 经验导出模型 Da*Eb,D:进度(以月单位) E:工作量(以人月单位) a:2-4之间 b:1/3左右 PERT(工程评估评审技术) 专家判断法 类比估计法 基于承诺的进度估计 Jones的一阶估算准则 基于估算项目功能点,从幂次表中选择合适的幂次将功能点升幂一个商业软件的功能点FP350若一个平均水平的软件公司来承担粗略的进度估算为 3500.4312月 预留分析 敏捷历时估算
6.6.1 PERT技术
答于1958年为适应大型工程的需要并取得不错效果
利用网络顺序图的逻辑关系和加权算法估算任务历时它是基于对某项任务的乐观悲观以及最可能的概率时间估计 贝塔分布方差近似值 P E R T 历时 ( O 4 m P ) / 6 贝塔分布 贝塔分布方差近似值 σ 2 ( P − O 6 ) 2 {贝塔分布方差近似值} PERT历时 (O4mP) / 6贝塔分布\\ 贝塔分布方差近似值 \sigma^2 \left(\frac{P - O}{6}\right)^2\\ 贝塔分布方差近似值PERT历时(O4mP)/6贝塔分布贝塔分布方差近似值σ2(6P−O)2
活动项O,M,PPERT估计值δδ²A2,3,63.334/616/36B4,6,864/616/36C3,4,64.173/69/36估计项目总历时—13.51.0741/36 E E A E B E C δ 2 δ A 2 δ B 2 δ C 2 δ δ A 2 δ B 2 δ C 2 E E_A E_B E_C\\ \delta^2 \delta_A^2 \delta_B^2 \delta_C^2\\ \delta \sqrt{\delta_A^2 \delta_B^2 \delta_C^2} EEAEBECδ2δA2δB2δC2δδA2δB2δC2
6.6.2 预留分析
答 在进行持续时间估算时需考虑应急储备(有时称为“进度储备”), 以应对进度方面的不确定性。 应急储备是包含在进度基准中的一段持续时间用来应对已经接受 的已识别风险。应急储备可取活动持续时间估算值的**某一百分比( 如10%15%)**或某一固定的时间段。 预留的应急储备应该是将每一项任务的预留时间累加在一起放在关键路径末端而不要增加每一项任务时间即把应急储备从各个活动中剥离出来并汇总
6.6.3 敏捷历时估算
答
在敏捷项目中团队的估算最多限于未来几周时间。敏捷历时估算可以分为开发速度稳定前和开发速度稳定后两种
开发速度稳定前可以采用决策技术如举手表决。开发速度稳定后 * 团队通过观察历史表现来更准确地规划下阶段的能力可能需要4 8个迭代才能达到稳定的速度。
6.7 什么是任务进度计划编制有什么基本方法
答
进度计划编制是决定项目开始和结束日期的活动 主要目的是控制和节约项目的时间保证项目在规定的时间内能够完成最终目标建立一个现实的项目进度计划为监控项目的进度进展提供一个基础。 基本方法有 关键路径法 CPM Critical Path Method 正推法/逆推法时间压缩法 应急法/平行作业法资源优化 资源平衡方法/资源平滑敏捷项目进度编排
6.7.1 如何使用关键路径法
答 计算每一个活动的单一的、确定的最早和最迟开始和完成日期 计算网络图中最长的路径。以便确定项目完成时间估计。
6.7.1.1项目进度管理时间参数对照表
中文名称英文名称简称定义/说明最早开始时间Early StartES任务最早可以开始的时间最晚开始时间Late StartLS任务最晚必须开始的时间不影响项目完成最早完成时间Early FinishEF任务最早可以完成的时间最晚完成时间Late FinishLF任务最晚必须完成的时间不影响项目完成超前Lead—两个任务的逻辑关系所允许的提前后置任务的时间滞后Lag—两个任务的逻辑关系所允许的推迟后置任务的时间浮动Float—任务的机动性在不影响项目完成情况下可推迟的时间量自由浮动Free FloatFF在不影响后置任务最早开始时间本任务可延迟的时间总浮动Total FloatTF在不影响项目最早完成时间本任务可延迟的时间
$$ FF ES_{\text{后置任务}} - EF - \text{lag}\
TF LS - ES \quad \text{或} \quad TF LF - EF $$
关键路径上的任务总浮动为0自由浮动≤总浮动任务的自由浮动永远不会超过其总浮动Lead/Lag主要用于调整任务间的逻辑关系时间依赖
6.7.2 介绍下时间压缩法
答
时间压缩法是在不改变项目范围的前提下缩短项目工期的方法是一种数学分析方法分为 应急法——赶工crash 时间成本平衡方法进度压缩单位成本方进度压缩因子方法 平行作业法——快速跟进Fast Tracking
6.7.2.1 介绍下时间成本平衡方法进度压缩单位成本方法)
答
时间成本平衡方法是项目管理中通过增加成本来压缩项目进度的技术核心是找到成本增加与时间节省之间的最优平衡点。
6.7.2.1.1基本假设
序号假设条件1每个任务存在正常进度和可压缩进度、正常成本和可压缩成本2通过增加资源每个任务的历时可以从正常进度压缩到可压缩进度3每个任务无法在低于可压缩进度内完成4有足够需要的资源可以利用5在正常与可压缩之间进度压缩与成本增长成正比 单位压缩成本 可压缩成本 − 正常成本 正常进度 − 可压缩进度 \text{单位压缩成本} \frac{\text{可压缩成本} - \text{正常成本}}{\text{正常进度} - \text{可压缩进度}} 单位压缩成本正常进度−可压缩进度可压缩成本−正常成本
参数类型时间成本正常情况正常进度较长正常成本较低压缩情况可压缩进度较短可压缩成本较高
决策原则 成本效益最大化选择单位压缩成本最低的活动进行压缩 关键路径优先只有关键路径上的活动压缩才能缩短项目总工期 资源约束考虑在资源允许范围内进行压缩
6.7.2.2 简要介绍下进度压缩因子法
答
通过计算进度压缩因子来估算压缩进度后的工作量增加实现时间与成本的量化权衡。 进度压缩因子 压缩进度 正常进度 压缩后工作量 正常工作量 进度压缩因子 \text{进度压缩因子} \frac{\text{压缩进度}}{\text{正常进度}}\\ \text{压缩后工作量} \frac{\text{正常工作量}}{\text{进度压缩因子}} 进度压缩因子正常进度压缩进度压缩后工作量进度压缩因子正常工作量
典型结果
进度缩短17% → 工作量增加21%体现了进度压缩的非线性成本增长特性
安全限制
进度压缩因子 ≥ 0.75最多压缩25%进度超出此范围项目风险急剧增加
6.7.2.3 对比一下时间压缩方法中的应急法和平行作业
对比维度应急法赶工法平行作业法快速跟进法基本原理通过增加资源以最小成本代价压缩进度工期将正常情况下按顺序进行的活动改为至少部分并行开展逻辑关系不改变活动间的逻辑关系可改变活动间的逻辑关系实施方式增加资源投入人力、设备、资金等并行开展某些活动使用提前量适用条件• 位于关键路径上的活动• 通过增加资源就能缩短持续时间的活动• 原本按顺序进行的活动或阶段• 可以部分并行开展的工作主要风险• 可能导致风险或成本增加• 并非总是切实可行• 常导致返工• 增加项目风险• 增加质量风险成本影响直接增加资源成本但以最小成本为目标可能增加项目成本返工、协调、质量问题协调复杂度相对简单主要是资源管理增加相关活动间的协调工作技术可行性取决于活动特性有些活动无法通过增加资源缩短需要仔细分析活动依赖关系的可调整性典型应用增加加班时间、增加工作人员、使用更快设备设计与采购并行、测试与开发重叠
选择建议
优先考虑应急法当关键路径活动可通过增加资源缩短且成本可控时谨慎使用平行作业法当应急法不可行且能承受返工和质量风险时组合使用在复杂项目中可能需要两种方法配合使用
6.7.3 资源平滑方法。
资源平衡法是一种资源优化技术通过调整活动的开始日期和完成日期使计划使用的资源等于或少于可用资源在资源需求与资源供给之间取得平衡。
主要目标具体说明形成平稳连续的资源需求避免资源需求的剧烈波动最有效利用资源提高资源使用效率最小化资源闲置时间减少资源浪费避免超出资源能力防止资源过度分配 适用场景 需要进行资源平衡的情况 共享资源或关键资源只在特定时间可用 资源数量有限 资源被过度分配同一资源在同一时段被分配至两个或多个活动 实施方法 根据资源制约因素对开始日期和完成日期进行调整通过调整任务时间来协调资源冲突。 重要特点 对项目的影响 资源平衡往往导致关键路径改变可在资源有约束的条件下制定可行的进度计划 资源优化方法分类 资源平衡调整时间以匹配可用资源 资源平滑在不改变关键路径的前提下优化资源使用 核心价值 在项目编排中进行资源的优化配置保证资源最优化、最有效实现可执行的项目进度计划。 | 并行开展某些活动使用提前量 | | 适用条件 | • 位于关键路径上的活动• 通过增加资源就能缩短持续时间的活动 | • 原本按顺序进行的活动或阶段• 可以部分并行开展的工作 | | 主要风险 | • 可能导致风险或成本增加• 并非总是切实可行 | • 常导致返工• 增加项目风险• 增加质量风险 | | 成本影响 | 直接增加资源成本但以最小成本为目标 | 可能增加项目成本返工、协调、质量问题 | | 协调复杂度 | 相对简单主要是资源管理 | 增加相关活动间的协调工作 | | 技术可行性 | 取决于活动特性有些活动无法通过增加资源缩短 | 需要仔细分析活动依赖关系的可调整性 | | 典型应用 | 增加加班时间、增加工作人员、使用更快设备 | 设计与采购并行、测试与开发重叠 |
选择建议
优先考虑应急法当关键路径活动可通过增加资源缩短且成本可控时谨慎使用平行作业法当应急法不可行且能承受返工和质量风险时组合使用在复杂项目中可能需要两种方法配合使用
6.7.3 资源平滑方法。
资源平衡法是一种资源优化技术通过调整活动的开始日期和完成日期使计划使用的资源等于或少于可用资源在资源需求与资源供给之间取得平衡。
主要目标具体说明形成平稳连续的资源需求避免资源需求的剧烈波动最有效利用资源提高资源使用效率最小化资源闲置时间减少资源浪费避免超出资源能力防止资源过度分配 适用场景 需要进行资源平衡的情况 共享资源或关键资源只在特定时间可用 资源数量有限 资源被过度分配同一资源在同一时段被分配至两个或多个活动 实施方法 根据资源制约因素对开始日期和完成日期进行调整通过调整任务时间来协调资源冲突。 重要特点 对项目的影响 资源平衡往往导致关键路径改变可在资源有约束的条件下制定可行的进度计划 资源优化方法分类 资源平衡调整时间以匹配可用资源 资源平滑在不改变关键路径的前提下优化资源使用 核心价值 在项目编排中进行资源的优化配置保证资源最优化、最有效实现可执行的项目进度计划。
