项目管理
范围管理
- 在进行项目计划之前，应该首先进行项目定义，也就是定义项目范围，其中包括建立产品的目的和范围、可选的解决方案、技术或管理的约束等。
- 范围管理是确定在项目内要干什么和不干什么，当然由此界定的项目范围在项目的全生命周期内可能因种种原因而变化，项目范围管理也要管理项目范围的这种变化。项目范围的变化也叫变更。
产品范围和项目范围
- 产品范围是指产品或者服务所应该包含的功能。产品范围是否完成，要根据产品是否满足了产品描述来判断。产品范围是项目范围的基础，产品范围的定义是产品要求的描述。
- 项目范围是指为了能够交付产品，项目所必须做的工作。项目范围的定义是产生项目管理计划的基础。判断项目范围是香完成，要以范围基准来衡量。项目的范围基准是经过批准的项目范围说明书、WBS和WBS词典。
- 产品范围描述是项目范围说明书的重要组成部分，因此，产品范围变更后，首先受到影响的是项目的范围。
管理过程
对项目范围的管理，是通过5个管理过程来实现的：
① 规划范围管理。也叫编制范围管理划，对如何定义、确认和控制项目范围的过程进行描述。
② 定义范围。详细描述产品范围和项目范围，编制项目范围说明书，作为以后项目决策的基础，其输入包括：项目章程、项目范围管理计划、组织过程资产、批准的变更申请。
③ 创建工作分解结构(WBS)。把整个项目工作分解为较小的、易于管理的组成部分，形成一个自上而下的分解结构。
④ 确认范围。正式验收已完成的可交付成果。
⑤ 范固控制。监督项目和产品的范围状态、管理范固基准变更。
WBS
WBS将项目整体或者主要的可交付成果分解成容易管理、方便控制的若干个子项目或者工作包，子项目需要继续分解为工作包，持续这个过程，直到整个项目分解为可管理的工作包，这些工作包的总和是项目的所有工作范围。WBS如下表所示：
练习题
()把软件项目整体或者主要的可交付成果分解为易于管理、方便控制的若干个子项目；再将子项目继续分解为工作包在每个分解单元中，都存在可交付成果和里程碑。该模型的主要用途是（)。
A.分层数据流图
B软件模块图
C.工作分解结构WBS
D.PERT图
A.描述软件项目的功能需求
B.定义项目边界，有助于防止需求蔓延
C.对软件的静态结构进行建模
D.刻画软件开发活动之间的依赖关系
答案C B
进度管理
进度管理：就是采用科学的方法，确定进度目标，编制进度计划和资源供应计划，进行进度控制，在与质量、成本目标协调的基础上，实现工期目标。
基本原则
进度管理基本原则：
① 划分：项目必须被划分成若干可以管理的活动和任务。
② 相互依赖性：分后的各个活动或任务之间的相互依赖关系必须是明确的。
③ 时间分配：必须为每个被调度的任务分配一定数量的工作单位（如若干人天的工作量）。
④ 工作量确认：每个项目都有预定数量的人员参与。
⑤ 确定责任：安排了进度计划的每个任务都应该指定特定的团队成员来负责。
⑥ 明确输出结果：安排了进度计划的每个任务都应该有一个明确的输出结果。
⑦ 确定里程碑：每个任务或任务组都应该与一个项目里程碑相关联。
过程
进度管理具体来说，包括以下过程：
① 活动定义：确定完成项目各项可交付成果而需要开展的具体活动。
② 活动排序：识别和记录各项活动之间的先后关系和逻辑关系。
③ 活动资源估算：估算完成各项活动所需要的资源类型和效益。
④ 活动历时估算：估算完成各项活动所需要的具体时间。
⑤ 进度计划编制：分析活动顺序、活动持续时间、资源要求和进度制约因素制订项目进度计划。
⑥ 进度控制：根据进度计划开展项目活动，如果发现偏差，则分析原因或进行调整。
活动资源估算
活动资源估算的方法主要有：
① 自下而上的估算。把杂的活动分解为更小的工作，以便于资源估算。将每项工作所需要的资源估算出来，然后汇总即是整个活
动所需要的资源数量。
② 自顶而下的估算。参照以前完成的项目所耗费的总成本（或总工作量）来推算将要开发的软件的总成本（或总工作量），然后把它们按阶段、步骤和工作单元进行分配，这种方法称为自顶向下估算方法。
③ 差别估算方法：是将待开发项目与一个或多个已完成的类似项目进行比较，找出与某个相似项目的若干不同之处，并估算每个不同之处对成本的影响，导出待开发项目的总成本。
④ 专家判断法。专家判断法通常是由项目管理专家根据以往类似项目的经验和对本项目的判断，经过周密思考，进行合理预测，从而估算出项目资源。
⑤ 替换方案的确定。资源估算是为了给项目预算明确空间，为早期的资源筹备提供数据，如果某项活动存在替代方案，或提供的资源有替代支持可能，则需要明确声明。
⑥ 公开的估算数据。有些公司会定期地公开一些生产率或人工费率数据，其中包括很多国家和地区的劳动力交易、材料和设备信息。
⑦ 估算软件。依靠软件的强大功能，可以定义资源可用性、费率，以及不同的资源日历。
软件规模估算方法
- COCOMO模型：常见的软件规模估算方法。常用的代码行分析方法作为其中一种度量估计单位，以代码行数估算出每个程序员工作量，累加得软件成本。
模型按其详细程度可以分为三级：
① 基本COCOMO模型是一个静态单变量模型，它用一个以已估算出来的原代码行数(LOC)为自变量的经验函数计算软件开发工作量。
② 中间COCOMO模型是一个静态多变量模型，在基本COCOMO模型的基础上，再用涉及产品、硬件、人员、项目15种影响软件工作量的因素调整工作量的估算。
③ 详细COCOMO模型包括中间COCOMO模型的所有特性，将软件系统模型分为系统、子系统和模块3个层次，更进一步考虑了软件工程中每一步骤（如分析、设计)的影响。 - COCOMO ΙΙ模型：COCOMO的升级，也是以软件规模作为成本的主要因素，考虑多个成本驱动因子。该方法包括三个阶段性模型，即应用组装模型、早期设计阶段模型和体系结构阶段模型。包含三种不同规模估算选择：对象点、功能点和代码行。
进度安排
进度安排的常用图形描述方法有Gantt图（甘特图）和项目计划评审技术(Program Evaluation&Review Technique,PERT)图
左图甘特图：能看到任务的开始和结束以及任务进展情况
右图PEWT图：更强调项目依赖，要会计算关键路径，最晚开始时间等
关键路径法
关键路径：是项目的最短工期，但却是从开始到结束时间最长的路径。进度网络图中可能有多条关键路径，因为活动会变化，因此关键路径也在不断变化中。
关键活动：关键路径上的活动，最早开始时间=最晚开始时间。
通常，每个节点的活动会有如下几个时间：
① 最早开始时间(ES),某项活动能够开始的最早时间。
② 最早结束时间(EF),某项活动能够完成的最早时间。EF=ES+工期
③ 最迟结束时间(LF)。为了使项目按时完成，某项活动必须完成的最迟时间。
④ 最迟开始时间(LS)。为了使项目按时完成，某项活动必须开始的最迟时间。LS=LF-工期。
-
这几个时间通常作为每个节点的组成部分，如图所示：
- 顺推：最早开始ES=所有前置活动最早完成EF的最大值；最早完成EF=最早开始ES+持续时间。
- 逆推：最晚完成LF=所有后续活话动最晚开始的最小值；最晚开始LS=最晚完成LF持续事件。
-
总浮动时间：在不延误项目完工时间且不违反进度制约因素的前提下，活动可以从最早开始时间推迟或拖延的时间量，就是该活动的进度灵活性。正常情况下，关键活动的总浮动时间为零。
-
总浮动时间=最迟开始LS-最早开始ES或最迟完成LF-最早完成EF或关键路径一非关键路径时长。
-
自由浮动时间：是指在不延误任何今后活动的最早开始时间且不违反进度制约因素的前提下，活动可以从最早开始时间推迟或拖延的时间量。
-
自由浮动时间=今后活动最早开始时间的最小值一本活动的最早完成时间。
练习题
进度安排的常用图形描述方法有Gantt图和PERT图。Gantt图不能清晰地描述()；PERT图可以给出哪些任务完成后才能开始另一些任务。下图所示的PERT图中，事件6的最晚开始时刻是(）。
A,每个任务从何时开始
B,每个任务到何时结束
C.每个任务的进展情况
D,各任务之间的依赖关系
A.0
B,3
C.10
D.11
答案D C
解析：
第一，找出关键路径，求出最短工期；关键路径：时间最长的1->2->5->7->9，2+2+5+6=15
第二，确定事件6以后的工作需要多长时间；6->8->9，1+4=5
第三，最短工期-第二步的时间=事件6最晚开始时间。15-5=10
成本管理
项目成本管理是在整个项目的实施过程中，为确保项目在批准的预算条件下尽可能保质按期完成，而对所需的各个过程进行管理与控制。
过程
项目成本管理包括成本估算、成本预算和成本控制三个过程。
① 成本估算是对完成项目所需成本的估计和计划，是项目计划中的一个重要的、关键的、敏感的部分：成本估算主要靠分解和类推的手段进行，基本估算方法分为三类：自顶向下的估算、自底向上的估算和差别估算法。当然还有一些其他估
算方法：专家估算法、类推估算法、算式估算法。
② 成本预算是把估算的总成本分配到项目的各个工作包，建立成本基准计划以衡量项目绩效；应急储备和管理储备。
③ 成本控制保证各项工作在备自的预算范围内进行。
成本的类型
① 可变成本：随若生产量、工作量或时间而变的成本为可变成本。可变成本又称变动成本。
② 固定成本：不随生产量、工作量或时间的变化而变化的非重复成本为固定成本。
③ 直接成本：直接可以归属于项目工作的成本为直接成本。如项目团队差旅费、工资、项目使用的物料及设备使用费等。
④ 间接成本：来自一般管理费用科目或几个项目共同担负的项目成本所分摊给本项目的费用，就形成了项目的间接成本，如税金、额外福利和保卫费用等。
⑤ 机会成本：是利用一定的时间或资源生产一种商品时，而失去的利用这些资源生产其他最佳替代品的机会就是机会成本，泛指一切在做出选择后其中个最大的损失。
⑥ 沉没成本：是指由于过去的决策已经发生了的，而不能由现在或将来的任何决策改变的成本。沉没成本是一种历史成本，对现有决策而言是不可控成本，会很大程度上影响人们的行为方式与决策，在投资决策时应排除沉没成本的干扰。
学习曲线：重复生成产品时，产品的单位成本会随若产量的扩大呈现规律性递减。估算成本时，也要考虑此因素。
练习题
关于成本类型的描述，不正确的是()。
A、项目团队差旅费、工资、税金及设备使用费为直接成本
B、随着生产量，工作量或时间而变的成本称为变动成本
C、利用一定时间或资源生产一种商品时，便失去了使用这些资源生产其他最佳替代品的机会称为机会成本
D、沉没成本是一种历史版本，对现有决策而言是不可控成本
答案A
税金是间接成本
投资者赵某可以选择股票和储蓄存款两种投资方式。他于2017年1月1日用2万元购进某股票，一年后亏损了500元，如果当时他选择储蓄存款，年后将有360元的收益。由此可知 赵某投资股票的机会成本为()元。
A、500
B、360
C、860
D、140
答案B
软件配置管理
- 软件配置管理(Software Configure Management,SCM)用于整个软件工程过程。其主要目标是标识变更；控制变更；确保变更正确地实现；报告有关变更。SCM是一组管理整个软件生存周期中各阶段变更的活动，在系统的整个生命周期中维持配置的完整性和可跟踪性。
- 在GB/T11457-2006中将"配置管理”正式定义为：“应用技术的和管理的指导和监控方法以标识和说明配置项的功能和物理特征，控制这些特征的变更记录和报告变更处理和实现状态并验证与规定的需求的遵循性。”
- 配置管理包括6个主要活动：制订配置管理计划、配置标识、配置控制、配置状态报告、配置审计、发布管理和交付。
配置项
- 配置项：GB/T11457-2006对配置项的定义为："为配置管理设计的硬件、软件或二者的集合，在配置管理过程中作为一个单个实体来对待”。
- 以下内容都可以作为配置项进行管理：外部交付的软件产品和数据、指定的内部软件工作产品和数据、指定的用于创建或支持软件产品的支持工具供方/供应商提供的软件和客户提供的设备/软件。
- 典型配置项包括项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据，它们经评审和检查通过后进入配置管理。
- 每个配置项的主要屈性有：名称、标识符、文件状态、版本、作者、日期等。
- 配置项可以分为基线配置项和非基线配置项两类，例如，基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包括项目的各类计划和报告等。
- 所有配置项的操作权限应由CMO(配置管理员)严格管理，基本原则是：基线配置项向开发人员开放读取的权限：非基线配置项向PM、CCB及相关人员开放。
- 配置项的状态可分为**“草稿"正式"和"修改"三种。配置项刚建立时，其状态为“草稿"。配置项通过评审后，其状态变为"正式”。此后若更改配置项，则其状态变为“修改”**。当配置项修改完毕并重新通过评审时，其状态又变为“正式”
- 配置项版本号：
①处于**"草稿"状态的配置项的版本号格式为0.Y.Z**,YZ的数字范围为01~99。随着草稿的修正，YZ的取值应递增。YZ的初值和增幅由用户自己把握。
②处于**“正式"状态的配置项的版本号格式为X.Y**，X为主版本号，取值范围为1 ~ 9。Y为次版本号，取值范围为0~9。配置项第一次成为"正式"文件时，版本号为1.0。如果配置项升级幅度比较小，可以将变动部分制作成配置项的附件，附件版本依次为1.0,1.1，…。当附件的变动积累到一定程度时，配置项的Y值可适量增加，Y值增加一定程度时，X值将适量增加。当配置项升级幅度比铰大时，才允许直接增大X值。
③处于**"修改"状态的配置项的版本号格式为X.Y.Z**。配置项正在修改时，一般只增大Z值。XY值保特不变。当配置项修改完毕，状态成为正式时，将Z值设置为0，增加XY值。参见上述规则(2) - 配置项版本管理：在项目开发过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比旧版本。所以不能抛弃旧版本。版本管理的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。
配置基线
- 配置基线（常简称为基线）由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体。基线中的配置项被“冻结"了，不能再被任何人随意修改。对基线的变更必须遵循正式的变更控制程序。
- 基线通常对应于开发过程中的里程碑，一个产品可以有多个基线，也可以只有一个基线。交付给外部顾客的基线一般称为发行基线(Release),内部开发使用的基线一般称为构造基线(Build)。
- 一组拥有唯一标识号的需求、设计、源代码文卷以及相应的可执行代码、构造文卷和用户文档构成一条基线。
- 对于每一个基线，要定义下列内容：建立基线的事件、受控的配置项、建立和变更基线的程序、批准变更基线所需的权限。在项目实施过程中，每个基线都要纳入配置控制，对这些基线的更新只能采用正式的变更控制程序。
- 建立基线还可以有如下好处：
①基线为开发工作提供了一个定点和快照。
②新项目可以在基线提供的定点上建立。新项目作为一个单独分支，将与随后对原始项目（在主要分支上）所进行的变更进行隔离。
③当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法。
④可以利用基线重新建立基于某个特定发布版本的配置，以重现已报告的错误。
配置数据库
- 配置数据库：存放配置项并记录与配置项相关的所有信息，是配置管理的有力工具。主要作用：
①记录与配置相关的所有信息，其中存放受控的软件配置项是很重要的内容。
②利用库中的信息评价变更的后果，这对变更控制有着重要的意义。
③从库中可提取各种配苦管理过程的管理信息。 - 使用配置库可以帮助配置管理员把信息系统开发过程的各种工作产品，包括半成品或阶段产品和最终产品管理得井井有条，使其不致管乱、管混、管丢。例如git，svn
- 配置数据库可以分开发库、受控库、产品库3种类型。
①开发库，也称为动态库、程序员或工作库，用于保存开发人员当前正在开发的配置实体，如：新模块、文档、数据元素或进行修改的已有元素。动态中的配置项被置于版本管理之下。动态库是开发人员的个人工作区，由开发人员自行控制。库中的信息可能有较为频繁的修改，只要开发库的使用者认为有必要，无需对其进行配置控制，因为这通常不会影响到项目的其他部分。可以任意的修改。
②受控库，也称为主库，包含当前的基线加上对基线的变更。受控库中的配置项被置于完全的配置管理之下。在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库。可以修改，需要走变更流程。
③产品库，也称为静态库、发行库、软件仓库，包含已发布使用的各种基线的存档，被置于完全的配置管理之下。在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装。一般不再修改，真要修改的话需要走变更流程。
练习题
项目配置管理中，，产品配置是指一个产品在其生命周期各个阶段所产生的各种形式和各种版本的文档、，计算机程序、部件及数据的集合。该集合中的每一个元素称为该产品配置中的一个配置顶，（)不属于产品组成部分工作成果的配置顶
A、需求文档
B、设计文档
C、工作计划
D、源代码
答案C
解析：配置项是构成产品配置的主要元素，配置项主要有以下两大类：（1)属于产品组成部分的工作成果：如需求文档、设计文档、源代码和测试用例等；(2)属于项目管理和机构支学过程城产生的文档：如工作计划、项目质量报告和项目跟踪报
告等
项目配置管理中，配置项的状态通常包括()
A、草稿、正式发布和正在修改
B、草稿、技术评审和正式发布
C、草稿、评审或审批、正式发布
D、草稿、正式发布和版本变更
答案A
质量管理
- 软件质量是指反映软件系统或软件产品满足规定或隐含需求的能力的特征和特性全体。软件质量管理是指确定质量方针、目标和职责，并通过质量体系中的质量计划、质量控制、质量保证和质量改进来使其实现的所有管理职能的全部活动；
过程
软件质量管理主要包括以下过程：
①质量规划：识别项目及其产品的质量要求和标准，并书面描述项目将如何达到这些要求和标准的过程。
②质量保证：一般是每隔一定时间（例如，每个阶段末）进行的，主要通过系统的质量审计（软件评审)和过程分析来保证项目的质量。
③质量控制：实时监控项目的具体结果，以判断它们是否符合相关质量标准，制订有效方案，以消除产生质量问题的原因。
质量模型
- ISO/IEC 9126软件质量模型
- McCall模型
软件评审
软件评审：质量两个必要条件：
- 设计的规格说明书符合用户标准，称为设计质量。
- 程序按照设计规格说明书所规定的情况正确执行，称为程序质量。
软件容错技术
软件容错技术：容错就是软件遇到错误的处理能力，实现容错的手段主要是冗余，包括下面四种冗余技术：
- 结构冗余：分为静态、动态、混合冗余三种，当错误发生时对错误进行备份处理。
- 信息冗余：为检错和纠错在数据中加上一段额外的信息。例如校验码原理。
- 时间冗余：遇到错误时重复执行，例如回滚，重复执行还有错，则转入错误处理逻辑。
- 冗余附加技术：是指为实现结构、信息和时间冗余技术所需的资源和技术，包括程序、指令、数据、存放和调动它们的空间和通道等。在屏蔽硬件错误的容错技术中
练习题
软件质量保证是软件项目控制的重要手段，()是软件质量保证的主要活动之一。
A、风险评估
B、软件评审
C、需求分析
D、架构设计
答案：B
解析：软件质量保证是软件质量管理的重要组成部分。软件质量保证主要是从软件产品的过程规范性角度来保证软件的品质。其主要活动包括：质量审计（包括软件评审）和过程分析。
ISO/IEC软件质量模型中，易使用性是指与使用所需的努力由一组规定或隐含的用户对这样使用所作的个别评价有关的一组属性，其易使用性的子特性不包括()。
A、易理解性
B、易学性
C、易分析性
D、易操作性
答案：C
解析：纯记忆，也可以从易使用性的特点去分析，应该是软件容易使用、理解、操作等，针对用户层面的，不会涉及到是否易分析设计。
风险管理
- 风险管理：就是要对项目风险进行认真的分析和科学的管理，这样，是能够避开不利条件、少受损失、取得预期的结果并实现项目目标的，能够争取避兔风险的发生或尽量减小风险发生后的影响。但是，完全避开或消除风险，或者只享受权益而不承担风险是不可能的。
- 风险识别：识别出项目中已知和可预测的风险，确定风险的来源、产生的条件、描述风险的特征以及哪些项目可以产生风险，形成一个风险条目检查表。
- 风险定性分析：对已经识别的风险进行排序，确定风险可能性与影响、确定风险优先级、确定风险类型。
- 风险定量分析：进一步了解风险发生的可能性具体由多大，后果具体由多严重。包括灵敏度分析、期望货币价值分析、决策树分析、蒙特卡罗模拟。
- 风险应对计划编制：对每一个识别出来的风险来分别制定应对措施，这些措施组成的文档称为风险应对计划。包括消极风险(避免策略、转移策略、减轻策略)；积极风险（开拓、分享、强大）。
- 风险监控：监控风险计划的执行，检测残余风险，识别新的风险，保证风险计划的执行，并评价这些计划对减少风险的有效性。
宏观分类
从宏观上来看，风险可以分为项目风险、技术风险和商业风险。
- 项目风险是指潜在的预算、进度、个人（包括人员和组织）、资源、用户和需求方面的问题，以及它们对项目的影响。项目复杂性、规模和结构的不确定性也构成项目的（估算）风险因素。项目风险威助到项目计划，一旦项目风险成为现实，可能会拖延项目进度，增加项目的成本。
- 技术风险是指潜在的设计、实现、接口、测试和维护方面的问题。此外，规格说明的多义性、技术上的不确定性、技术陈旧、最新技术（不成熟）也是风险因素。技术风险威胁到待开发系统的质量和预定的交付时间。如果技术风险成为现实，开发工作可能会变得很困难或根本不可能。
- 商业风险威胁到待开发系统的生存能力，主要有以下5种不同的商业风险：
① 市场风险。开发的系统虽然很优秀但不是市场真正所想要的。
② 策略风险。开发的系统不再符合企业的信息系统战略。
③ 销售风险。开发了销售部门不清楚如何推销的系统。
④ 管理风险。由于重点转移或人员变动而失去上级管理部门的支持。
⑤ 预算风险。开发过程没有得到预算或人员的保证。
项目风险
项目风险：作用于项目上的不确定的事件或条件，既可能产生威胁，也可能带来机会。
- 通过积极和合理的规划，超过90%的风险都可以进行提前应对和管理。
- 风险应该尽早识别出来，高层次风险应记录在章程里。
- 应由对风险最有控制力的一方承担相应的风险。
- 承担风险程度与所得回报相匹配原则，承担的风险要有上限。
风险的属性
① 随机性：风险事件发生及其后果都具有偶然性（双重偶然），遵循一定的统计规律。
② 相对性：风险是相对项目活动主体而言的。承受力不同，影响不同。风险承受力影响因素：收益大小（收益越大，越愿意承担风险)；投入大小（投入越大，承受能力越小）；主体的地位和资源（级别高的人能承担较大的风险）。
③ 可变性：条件变化，会引起风险变化。包括性质、后果的变化，以及出现新风险。
风险的分类：
- 按后果的不同划分，风险可划分为纯粹风险（无任何收益）和投机风险（可能带来收益）。
- 按风险来源划分，自然风险（天灾）和人为风险（人的活动，又可分为行为风险、经济风险、技术风险、政治和组织风险等）。
- 按是否可管理划分，可管理（如内部多数风险）和不可管理（如外部政策），也要看主体管理水平。
- 按影响范围划分，局部风险（非关键路径活动延误）和总体风险（关键路径活动延误）。
- 按后果承担者划分：业主、政府、承包商、投资方、设计单位、监理单位、保险公司等。
- 按可预测性划分：已知风险（已知的进度风险）、可预测风险（可能服务器故障）、不可预测风险(地震、洪水、政策变化等)。
练习题
以下关于软件风险的叙述中，不正确的是()
A、风险是可能发生的事件
B、如果发生风险，风险的本质、范围和时间可能会影响风险所产生的后果
C、如果风险可以预则，可以避免其发生
D、可以对风险进行控制
答案C
以下叙述中，()不是一个风险。
A.由另一个小组开发的子系统可能推迟交付，导致系统不能按时交付客户
B.客户不清楚想要开发什么样的软件，因此开发小组开发原型帮助其确定需求
C.开发团队可能没有正确理解客户的需求
D.开发团队核心成员可能在系统开发过程中离职
答案B
组织管理
- 组织结构模式：项目型（项目经理绝对领导）、职能型（部门领导为主）、矩阵型（二者结合，既有项目经理也有部门领导，但权利分割不同)。
- 程序设计小组的组织方式：
①主程序员制小组（主程序员全权负责，后援工程师必要时能替代主程序员适合大规模项目）
②民主制小组（也即无主程序员小组，成员之间地位平等，任何决策都是全员参与投票，适合于项目规模小，开发人员少，采用新技术和确定性较小的项目)
③层次式小组（两个层次，·名组长领导若干个高级程序员，每个高级程序员领导若干个程序员）。