《软件项目管理复习题》由会员分享,可在线阅读,更多相关《软件项目管理复习题(12页珍藏版)》请在金锄头文库上搜索。
1、第1讲 项目管理(1) 有效的软件项目管理集中于四个P上,即人员、产品、过程和项目。它们的顺序不是任意的。(2) 在制定项目计划之前,应该首先确定产品的目标和范围,考虑可选的解决方案,识别技术和管理上的限制。(3) 确定产品的范围,要标识出产品的主要数据、功能和行为特性,而且更为重要的是,应以量化的方式界定这些特性。(4) 成功的项目负责人应采用一种解决问题的管理风格。(5) “最好的”团队结构取决于组织的管理风格、团队里的人员数目与技能水平,以及问题的总体难易程序。(6) 规划软件工程团队结构时的七个项目因素:(1)待解决问题的难度;(2)开发程序的规模,以代码行或功能点来度量;(3)团队成
2、员需要共同工作的时间(团队生存期);(4)能够对问题做模块化划分的程度;(5)待开发系统的质量要求和可靠性要求;(6)交付日期的严格程度;(7)项目所需要的友好交流的程度。(7) 软件工程团队的四种“组织范型”:封闭式范型、随机式范型和开放式范型以及同步式范型。(8) 封闭式范型:按照传统的权利层次来组织团队。当开发与过去已经做过的产品相似的软件时,这种团队十分有效。但在这种封闭式范型下难以进行创新性的工作。(9) 随机式范型:松散地组织团队,团队工作依赖于团队成员个人的主动性。当需要创新或技术上的突破时,按照这种随机式范型的团队很有优势。但当需要“有次序地执行”才能完成工作时,这种团队就会陷
3、入困境。(10) 开放式范型:试图以一种具有封闭式范型的控制性,又包含随机式范型的创新性的方式来组织团队。工作是大家相互协作完成的。良好的沟通和根据团队整体的意见做出决策是开放式范型的特征。开放式范型的团队结构特别适合于解决复杂的问题,但可能不像其他类型的团队那么有效。(11) 同步式范型:依赖于问题的自然划分,组织团队成员各自解决问题的一部分,他们之间没有什么交流。(12) 5个“培育潜在含毒团队环境”的因素(1)狂乱的工作氛围(2)引起团队成员产生摩擦的重大挫折(3)“碎片式的或协调很差”的软件过程(4)在软件团队中没有清晰的角色定义(5)“接连不断地重蹈覆辙”。(13) 敏捷团队是小型的
4、充满活力的团队,它不必保持单一的团队结构,而是采用随机、开放、同步式的范型,并且拥有制定计划和做技术决定的自主权。(14) 软件项目管理的第一项活动是确定软件范围。(15) 软件范围是通过项目环境、信息目标以及功能和性能定义的。(16) 软件项目范围在管理层和技术层都必须是无歧义的和可理解的。(17) 问题分解,有时称为问题划分或问题细化,它是软件需求分析的核心活动。(18) 成本和进度估算都是面向功能的。(19) 过程框架是不变的,是软件组织所进行的所有软件工作的。(20) 10个表示信息系统项目正处于危险状态的信号(21) W5HH(22) 项目是一个特定的、待完成的有限任务,是在一定时间
5、内,满足一系列特定目标的多项相关工作的总称。(23) 项目与常规运作的不同体现:n 项目是一次性,常规运作是重复进行;n 项目是以目标为导向,常规运作是通过效率和有效性体现的;n 项目是通过项目经理及其团队工作完成的,而日常运作是职能式的线性管理;n 项目存在大量的变更管理,而日常运作则基本保持续的连贯性。(24) 项目生命周期有3个与时间相关的重要概念:检查点、里程碑和基线。(25) 基线:指一个(或一组)配置项在项目生命期的不同时间点上,通过正式评审而进入正式受控的一种状态。(26) 软件管理的关键实践:n 基于度量的项目管理n 经验成本和进度估计n 获得价值跟踪n 正式的风险管理n 根据
6、质量目标跟踪缺陷n 人员计划管理第2讲 过程和项目度量(27) 测量可以应用于软件过程中,目的是持续地改进软件过程。(28) 测度对一个产品过程的某个属性的范围、数量、维度、容量或大小提供了一个量化的指示。(29) 测量是确定一个测度的行为。(30) 度量为“对一个系统、构件或过程具有的某个给定属性的度的一个定量测量”。(31) 度量:度量是一个系统、构件或过程具有给定属性的量化测量程度。(32) 当收集了一个数据点(例如:在一个软件构件中发现的错误数),就建立了一个测度。(33) 收集一个或多个数据点(例如:一些构件评审、调查单元测试以收集每个单元测试错误数的测度),由此产生测量。(34)
7、软件的度量以某种形式(例如:每次评审发现错误的平均数,或每个单元测试所发现错误的平均数)与单个测度相关。(35) 软件工程师收集测量结果并产生度量,这样就可以获得指标。指标是一个度量或度量的组合,它对软件过程、软件项目或产品本身提供了更深入的了解(36) 软件工程师收集测度并开发度量以便获得指标?35那句是真的?(37) 私有过程数据是软件工程师个人改进其工作的重要驱动力。(38) 公用过程数据可由团队进行复查,以找出能够改善小组性能的指标。公用度量一般吸取了原本是个人的或团队的私有信息。(39) 软件度量规则:n 解释度量数据时使用常识,并考虑组织的敏感性。n 向收集测量和度量的个人及团队定
8、期提供反馈。n 不要使用度量去评价个人。n 与开发者和团队一起设定清晰的目标,并确定为达到这些目标需要使用的度量。n 不要用度量去威胁个人或团队。n 指出问题区域的度量数据不应该被“消极地”看待,这些数据仅仅是过程改进的指标。n 不要在某一个别的度量上纠缠,而无暇顾及其他重要的度量。(40) 在大多数软件项目中,项目度量的第一个应用是在估算阶段。(41) 项目度量的目的:n 能够指导进行一些必要的调整以避免延迟,并减少潜在问题及风险,从而使得开发时间减到最少。n 在项目进行的基础上评估产品质量,并且可在必要时修改技术方法以改进质量。(42) 面向规模的度量(LOC)和面向功能的度量(FP)都是
9、规范化的方法。(43) 面向规模的度量选择代码行(LOC)作为规范化值(度量:错误数、缺陷数、成本、文档页数)。(44) 面向功能的软件度量使用功能(由应用系统提供)测量数据作为规模化值。应用最广泛的面向功能的度量是功能点(Function Point,FP)。(45) 面向对象的度量:n 场景脚本的数量n 关键类的数量n 支持类的数量n 每个关键类的平均支持类数量n 子系统的数量(46) 面向用例的度量(47) Web 工程项目度量:n 静态Web页的数量n 动态Web页的数量n 内部页面链接的数量n 永久数据对象的数量n 通过界面连接的外部系统的数量n 静态内容对象的数量n 动态内容对象的
10、数量n 可执行的功能的数量(48) 定制指数 C = Ndp /( Ndp + Nsp )(49) 软件工程的基本高目标就是在某个时间框架内开发出满足市场需要的高质量的系统、应用软件或产品。(50) 缺陷排除效率 DRE = E /( E D )(把项目作为一个整体时)DREi = Ei / ( Ei Ei1 ) (51) 度量基线由从以往开发的软件项目中收集的数据构成,是估算的基础。(52) 度量评估主要是分析结果产生的根本原因,并生成一组指导项目或过程的指标。(53) 小型组织的度量:“保持简单”,通过表决来确定一个需要改进和目标。(54) 保持简单的缺陷排除效率:DRE Echange
11、/ (Echang + Dchange )。第3讲 产品度量(55) 软件质量是对明确陈述的功能和性能需求、明确记录的开发标准以及对所有专业化软件开发应具备的隐含特征的符合度。(56) 影响软件质量的因素可分为两大类:n 可以直接测量的因素(如:测试期间发现的缺陷)n 只能间接测量的因素(如:易用性和可维护性)(57) 产品度量的作用主要包括:n 辅助分析模型和设计模型的评估n 提供过程设计和源代码复杂性的指示n 方便更有效测试的设计(58) 测量过程的五个活动(测量原则):n 公式化。导出适合于所考虑软件表示的测量和度量。n 收集。用于导出公式化度量所需数据和积累机制。n 分析。度量的计算和
12、数学工具的使用。n 解释。为获得对表示的质量的理解而评价度量。n 反馈。从对递交给软件团队的产品度量的解释中获得建议。(59) 功能点度量(FP)可用做测量系统交付功能的有效手段。(60) 问题复杂性的指标Fi:(61) 分析模型的度量侧重于分析模型的三个成分:功能、数据和行为。第4讲 估算1. 软件项目策划的目标是提供一个管理人员对资源、成本及进度做出合理估算的框架。2. 项目策划任务集:a) 规定项目范围b) 确定可行性c) 分析风险d) 确定需要的资源e) 估计成本和工作量f) 指定项目进度计划3. 软件范围描述了将要交付给最终用户的功能和特性、输入和输出的数据、使用软件时要呈现给用户的
13、“内容”,以及界定系统的性能、约束条件、接口和可靠性。4. 定义范围可以使用两种方法:a) 在与所有共利益者交流之后,写出对软件范围的叙述性描述。b) 由最终用户开发一组用例。5. 软件可行性有四个固定的因素:技术、经济、时间和资源。6. 在制定计划时应该考虑四种软件资源:a) 成品构件b) 具有完全经验的构件c) 具有部分经验的构件d) 新构件7. 每种可行的软件成本估算方法,其效果的好坏取决于估算使用的历史数据。8. 项目估算的准确程度取决于待完成工作的规模估算。规模是指软件项目的可量化的结果。如果采用直接的方法,规模可以用代码行(LOC)来测量。如果选择间接的方法,规模可以用功能点(FP
14、)来表示。9. 四种估算规模问题的方法:a) “模糊逻辑”法b) 功能点法c) 标准构件法d) 修改法10. LOC和FP估算共同的特性:项目计划人员从界定的软件范围陈述入手,根据该说明将软件分解成一些可分别独立进行估算的功能问题。然后,估算每个功能的LOC或FP(即估算变量)。11. 基于LOC 估算(重点):通过乐观值(Sopt)、可能值(Sm)和悲观值(Spess)估算的加权平均值来计算估算变量(规模)的期望值S:S = (Sopt + 4Sm + Spess ) / 6 (“可能”估算值的权重最大)总代码行估算值 =(Si)成本估算值 = 总代码行估算值*每行代码的成本12. 基于FP
15、 估算(重点):FPestimated = 总计 组织平均生产率 + 0.01 (Fi) 成本估算值 = FPestimated 每个FP的成本13. 基于过程的估算:过程分解一组较小的任务,并估算完成任务所需的工作量。将问题功能与过程活动()结合起来,计划人员就可以针对每个软件功能,估算完成各个软件过程活动所需的工作量(如人月)。14. 估算一个步骤就是计算每一个功能及框架活动的成本和工作量。如果基于过程的估算是不依赖LOC和FP估算而实现的,我们现在就已经有了两组或三组成本与工作量的估算,可以进行比较、调和。如果两组估算非常一致,则有理由相信估算是可靠的。反过来,如果这些分解技术得到的结果不一致,则必须做进一步调查和分析。15. 基于用例的估算(不是重点):LOC估算 N LOCavg+(Sa/Sh-1)+(Pa/Ph-1) LOCadjustN:实际的用例数LOCavg: 在这