软件项目管理与案例分析思考题及答案

软件项目管理第一章思考题：1、当我们选择软件项目的负责人时，我们在寻找什么？成功的项目负责人应采用一种解决问题的管理风格。

也就是说，软件项目经理应该注重理解要解决的问题、把握住涌现的各种意见、同时让项目团队的每一个人知道质量很重要，不能妥协。

2、选择软件团队的结构时，应该考虑哪些因素？（1）待解决问题的难度；（2）开发程序的规模，以代码行或功能点来度量；（3）团队成员需要共同工作的时间（团队生存期）；（4）能够对问题做模块化划分的程度；（5）待开发系统的质量要求和可靠性要求；（6）交付日期的严格程度；（7）项目所需要的友好交流的程度。

3、定义软件的结构时，我们有哪些选择？封闭式范型。

按照传统的权利层次来组织团队。

当开发与过去已经做过的产品相似的软件时，这种团队十分有效。

但在这种封闭式范型下难以进行创新性的工作。

随机式范型。

松散地组织团队，团队工作依赖于团队成员个人的主动性。

当需要创新或技术上的突破时，按照这种随机式范型的团队很有优势。

但当需要“有次序地执行”才能完成工作时，这种团队就会陷入困境。

开放式范型：试图以一种具有封闭式范型的控制性，又包含随机式范型的创新性的方式来组织团队。

工作是大家相互协作完成的。

良好的沟通和根据团队整体的意见做出决策是开放式范型的特征。

开放式范型的团队结构特别适合于解决复杂的问题，但可能不像其他类型的团队那么有效。

同步式范型。

依赖于问题的自然划分，组织团队成员各自解决问题的一部分，他们之间没有什么交流。

4、何谓有凝聚力的团队？一个有凝聚力的团队是一组团结紧密的人，他们的整体力量大于个体力量的总和。

与一般团队相比，有凝聚力的团队成员有更高的生产率和更大的动力。

他们拥有共同的目标和共同的文化，而且在很多情况下，“精英意识”使得它们独一无二。

5、为什么有些团队没有凝聚力？并非所有的团队具有凝聚力。

事实上，很多团队都受害于Jackman[ JAC 98]称之为“团队毒性”的东西。

她定义了5个“培育潜在含毒团队环境”的因素（1）狂乱的工作氛围（2）引起团队成员产生摩擦的重大挫折（3）“碎片式的或协调很差”的软件过程（4）在软件团队中没有清晰的角色定义（5）“接连不断地重蹈覆辙”。

6、我们如何定义关键的项目特性W5HH原则为什么（Why）要开发这个系统？对这个问题的回答，可以使所有参与者评估软件工作的商业理由的有效性。

换句话说，该系统的商业目的值得花费这些人员、时间和金钱吗？将要做什么（What）?对这个问题的回答将制定完成项目所需的任务清单。

什么时候（When）做？就是标识出何时开展项目任务和何时达到里程碑，对这个问题的回答能够帮助团队安排好项目进度。

某功能由谁（Who）负责？必须规定软件团队的每个成员的角色和责任。

他们的机构组织位于何处（Where）?并非所有角色和责任均属于软件团队，客户、用户和其他共利益者也有责任。

如何（How）完成技术工作和管理工作？一旦确定了产品范围，必须定义项目的管理策略和技术策略。

每种资源需要多少（How much）?对这个问题的回答，是在对前面问题回答的基础上，通过估算而得到小结：软件项目管理是软件工程的普适性活动。

它先于任何技术活动之前开始，且持续贯穿于整个计算机软件的定义、开发和维护之中。

4个P－人员、产品、过程和项目，对软件项目管理具有重大的影响。

必须将人员组织成有效率的团队，激励他们完成高质量的软件工作，并协调他们实现有效的沟通。

产品需求必须在客户与开发者之间进行交流，划分（分解）成各个组成部分，并分配给软件团队。

过程必须适合于人员和问题。

选择通用过程框架，采用合适的软件工程范型，并挑选工作任务集合来完成项目的开发。

最后，必须采用确保软件团队能够成功的方式来组织项目。

第二章思考题：1、对软件度量的私有使用和公用使用有什么不同？不同类型的过程数据的使用可以分为“私有的和公用的”。

私有过程数据是软件工程师个人改进其工作的重要驱动力。

公用度量一般吸取了原本是个人的或团队的私有信息。

收集和评估项目级的缺陷率(肯定不能归因于某个个人)、工作量、时间及相关的数据，以找出能够改善组织过程性能的指标。

2、当我们收集软件度量时，应该采用什么指导原则？软件度量规则：解释度量数据时使用常识，并考虑组织的敏感性。

向收集测量和度量的个人及团队定期提供反馈。

不要使用度量去评价个人。

与开发者和团队一起设定清晰的目标，并确定为达到这些目标需要使用的度量。

不要用度量去威胁个人或团队。

指出问题区域的度量数据不应该被“消极地”看待，这些数据仅仅是过程改进的指标。

不要在某一个别的度量上纠缠，而无暇顾及其他重要的度量。

3、在项目中，我们应该如何使用度量？软件过程度量主要用于战略的目的。

软件项目度量则是战术的。

在大多数软件项目中，项目度量的第一个应用是在估算阶段。

从过去的项目中收集的度量可以作为估算当前软件工作工作量及时间的基础。

随着技术工作的启动，其他项目度量也开始有意义了。

生产率可以根据创建的模型、评审的时间、功能点以及交付的源代码行数来测量。

4、什么是度量基线？它能为软件工程师提供什么益处？度量基线由从以往开发的软件项目中收集的数据构成，一个包含过程和产品测量的数据库。

基线是估算的基础。

通过建立度量基线，软件工程师及管理者能够更好地了解他们所做的工作和开发的产品，在过程级、项目级和产品（技术）级上都能获得收益。

5、我们应该怎样导出一组“简单的”软件度量？不是从测量而是从结果入手，软件小组通过表决来确定一个需要改进的目标，根据这个目标，小型组织可以选择一些易于收集的测量，从而得出度量，并进行过程改进。

6、一个Web工程团队已经开发了一个包含145个网页的电子商务WebApp。

在这些页面中，65个是动态页面，即根据最终用户的的输入而在内部生成的页面。

那么，该应用的定制指数是多少？N sp = 静态Web页的数量N dp = 动态Web页的数量定制指数C = N dp /( N dp + N sp )=65/145≈0.448小结：测量能使管理者和开发者改进软件过程，辅助进行软件项目的计划、跟踪及控制，评估生成的产品(软件)的质量。

对过程、项目及产品的特定属性的测量可用于计算软件度量。

分析这些度量可获得指导管理及技术行为的指标。

过程度量使得一个组织能够从战略角度深入了解一个软件过程的功效。

项目度量是战术性的，能使项目管理者实时改进项目的工作流程及技术方法。

面向规模的度量和面向功能的度量在业界都得到了广泛的应用。

面向规模的度量以代码行作为其他测量（如人·月，缺陷）的规范化因子。

功能点则是从信息域的测量及对问题复杂度的主观评估中导出的。

软件质量度量（如生产率度量）关注的是过程、项目及产品。

一个组织通过建立并分析质量的度量基线，能够纠正引起软件缺陷的软件过程区域。

测量会带来企业文化的改变。

如果开始进行度量，则数据收集、度量计算及度量分析是必须完成的三个步骤。

通常，目标驱动的方法有助于一个组织关注于对其业务的正确度量。

通过建立度量基线——一个包含过程和产品测量的数据库，软件工程师及管理者能够更好地了解他们所做的工作和开发的产品。

第三章思考题:1、有效测量过程的步骤是什么？①公式化。

导出适合于所考虑软件表示的测量和度量。

②收集。

用于导出公式化度量所需数据和积累机制。

③分析。

度量的计算和数学工具的使用。

④解释。

为获得对表示的质量的理解而评价度量。

⑤反馈。

从对递交给软件团队的产品度量的解释中获得建议。

2、用于提供问题复杂性的指标有哪些？Fi 用于提供问题复杂性的指标。

Fi（i＝1~14）是值调整因子（V AF），它基于对下列问题的回答来确定：系统需要可靠的备份和恢复吗？需要专门的数据通信从应用系统中传输信息或将信息传输到应用系统吗？存在分布处理功能吗？性能是关键的吗？系统将运行在一个现有的、紧张使用的操作环境吗？系统需要在线数据项吗？在线数据项需要对多个屏幕或操作建立输入事务吗？ILF在线更新吗？输入、输出、文件或查询复杂吗？内部处理复杂吗？所设计的代码是可复用的吗？转换与安装包括在设计中吗？系统是为不同组织中的多个安装而设计的吗？应用系统是为便于变更和易于为用使用而设计的吗？每个问题可用从0（不重要或不适用）到5（绝对必需）间的数值来回答。

小结：软件度量为产品内部属性的质量评估提供了一种定量方法，从而可以使软件工程师在产品开发出来之前进行质量评估。

度量为创建有效的分析模型、设计模型、可靠的代码和完全的测试提供了必要的理解。

为在现实世界中有用，软件度量必须是简单和可计算的、有说服力的、一致和客观的。

它应该是与程序设计语言无关的，且为软件工程师提供有效的反馈。

分析模型的度量侧重于分析模型的三个成分：功能、数据和行为。

第四章思考题：1、基于LOC和基于FP的估算有什么共同点？LOC和FP估算是两种不同的估算技术，但两者有很多共同的特性：项目计划人员从界定的软件范围陈述入手，根据该说明将软件分解成一些可分别独立进行估算的功能问题。

然后，估算每个功能的LOC或FP（即估算变量）。

2、我们如何计算软件规模的期望值？可以通过乐观值(Sopt)、可能值(Sm)和悲观值(Spess)估算的加权平均值来计算估算变量（规模）的期望值S：S = (Sopt + 4Sm + Spess ) / 63、为什么开发基于用例的估算技术很困难？描述用例时，可以采用多种格式和风格－没有标准形式。

用例表现的是软件的外部视图（用户视图），常常在不同的抽象级别上建立用例没有标识出它所描述的功能和特性的复杂性。

用例没有描述出涉及很多功能和特性的复杂行为（如，交互）。

4、什么是对象点？对象点是一种间接的软件测量。

计算对象点时，使用如下的数值：1)（用户界面的）屏幕数2)报表数3)构造应用可能需要的构件数小结：在项目开始之前，软件项目计划人员必须先估算三件事：需要多长时间、需要多少工作量、以及需要多少人员。

此外，计划人员必须预测所需要的资源(硬件及软件)和蕴含的风险。

范围陈述能够帮助计划人员使用一种或多种技术进行估算，这些技术主要分为两大类：分解和经验建模。

分解技术需要划分出主要的软件功能，接着估算：（1）LOC的数量；（2）信息域内的选择值；（3）用例的数量；（4）实现每个功能所需的人·月数；或者，（5）每个软件工程活动所需的人·月数。

经验技术使用根据经验导出的关于工作量和时间的公式来预测这些项目数字，可以使用自动工具来实现特定的经验模型。

对项目做精确估算时，一般至少会用到上述3种技术中的两种。

通过对不同技术产生的估算值进行比较和调和，计划人员更有可能得到精确的估算。

软件项目估算永远不会是一门精确的科学，但可靠的历史数据与系统化的技术结合起来能够提高估算的精确度。