13开发管理思维导图模板_ProcessOn思维导图、流程图

13.1 项目的范围、时间与成本

项目管理首先要考虑三个约束条件：项目范围、时间进度、成本预算

13.1.1 项目范围管理

所谓项目范围管理，包括保证项目顺利完成所需的全部工作过程。其目的是控制项目的全部活动都在需求范围内，以确保项目资源的高效利用

5 个部分

项目启动指批准项目启动或者允许项目进入下一个阶段

范围计划编制是将生产项目产品所需进行的项目工作渐进明细和形成文件的过程

项目范围定义是把主要的项目可交付成果分解成更小、更易管理的单元

目的

提高对成本、时间及资源估算的准确性。

为绩效测量与控制定义一个基准计划。

便于进行明确的职责分配

范围核实需要审查可交付成果和工作结果，以确保它们都已经正确圆满地完成。如果项目被提前终止，范围核实过程应当对项目完成程度建立文档

项目范围变更控制涉及的是

对造成范围变更的因素施加影响，以确保这些变更得到一致认可；

确定范围变更是否已经发生；

当范围变更发生时对实际变更进行管理

13.1.2 项目成本管理

项目成本管理，是保证在批准预算内完成项目所需要的过程

4 个主要部分内容

资源计划编制是确定为完成项目各活动需什么资源（人、设备、材料）和这些资源的数量

成本估算就是计算出完成一个项目的各活动所需各资源成本的近似值

成本预算是把估算的总成本分配到单个活动或工作包上去，建立基准计划来度量项目实际绩效

成本控制的内容有：对造成成本基准计划变化的因素施加影响，以保证这种变化得到一致认可；确定成本基准计划是否已经发生变化；当变化发生和正在发生时，对这种变化执行管理

成本控制包括以下方面：监测成本执行情况，以寻找出并掌握计划的偏差及原因。确保所有变更都准确地记录在成本基准计划中。防止把不正确、不适宜或未批准的变更纳入成本基准成本。将批准的变更通知项目干系人。采取措施，把预计的成本控制在可接受的范围内

13.1.3 项目时间管理

时间管理包括确保项目按时完成所需的各个过程

5 个部分内容

活动定义是对 WBS 中规定的可交付成果或半成品的产生所必须进行的具体活动进行定义，并形成文档

活动排序是确定各活动之间的依赖关系，并形成文档

活动历时估算是根据项目范围和资源的相关信息为进度表设定历时输入的过程

制订进度计划要决定项目活动的开始和结束日期

进度控制涉及的是：对造成进度变更的因素施加影响，以确保这些变更得到一致认可；确定进度变更是否已经发生；当变更发生时对实际变更进行管理

13.2 配置管理与文档管理

软件配置管理（SoftwareConfiguration Management，SCM）应运而生。其主要作用是通过结构化的、有序化的、产品化的管理软件工程的方法来维护产品的历史，鉴别和定位产品独有的版本，并在产品的开发和发布阶段控制变化；通过有序管理和减少重复性工作，配置管理保证了生产的质量和效率；它涵盖了软件生命周期的所有领域并影响所有数据和过程

13.2.1 软件配置管理的概念

SCM 是指在软件系统中确定和定义构件（源代码、可执行程序、文档等），在整个生命周期中控制发布和变更，记录和报告构件的状态和变更请求，并定义完整的、正确的系统构件的过程

以下几个方面功能

配置标识：产品的结构、产品的构件及其类型，为其分配唯一的标识符，并以某种形式提供对它们的存取

版本控制：通过建立产品基线，控制软件产品的发布和在整个软件生命周期中对软件产品的修改。例如，它将解决哪些修改会在该产品的最新版本中实现的问题

状态统计：记录并报告构件和修改请求的状态，并收集关于产品构件的重要统计信息。例如，它将解决修改这个错误会影响多少个文件的问题

审计和审查：确认产品的完整性并维护构件间的一致性，即确保产品是一个严格定义的构件集合。例如，它将解决目前发布的产品所用的文件的版本是否正确的问题

生产：对产品的生产进行优化管理。它将解决最新发布的产品应由哪些版本的文件和工具来生成的问题

过程管理：确保软件组织的规程、方针和软件周期得以正确贯彻执行。它将解决要交付给用户的产品是否经过测试和质量检查的问题

小组协作：控制开发统一产品的多个开发人员之间的协作。例如，它将解决是否所有本地程序员所做的修改都已被加入新版本的产品中的问题

要求

唯一地标识每个软件项的版本；

标识共同构成一个完整产品的特定版本的每一软件项的版本；

控制由两个或多个独立工作的人员同时对一个给定软件项的更新；

按要求在一个或多个位置对复杂产品的更新进行协调；

标识并跟踪所有的措施和更改

配置管理三个核心部分：版本管理、问题跟踪和建立管理，其中版本管理是基础

13.2.2 软件配置管理的解决方案

常用的软件配置管理工具，主要有如下产品：Rational ClearCase，Merant PVCS，Microsoft VSS，CVS

13.2.3 软件文档管理

1．软件文档的作用

（1）管理依据

（2）任务之间联系的凭证

（3）质量保证

（4）培训与参考

（5）软件维护支持

（6）历史档案

（7）销售可能

2．文档的归类

（1）开发文档

（2）产品文档

（3）管理文档

3．文档编制计划

软件开发的管理部门应该根据本单位承担的应用软件的专业领域和本单位的管理能力，制定一个对文档编制要求的实施规定

4．对文档质量的要求如果不重视文档编写工作，或是对文档编写工作的安排不当，就不可能得到高质量的文档

好的软件文档要求具备如下特征

（1）针对性

（2）精确性

（3）清晰性

（4）完整性

（5）灵活性

13.3 软件需求管理

13.3.1 需求变更

需求变更是指在软件开发过程中，用户确定软件需求之后，由于各种客观和主观条件的变化，用户增加了新的需求或改变了原有需求

措施

（1）项目启动阶段的变更预防

对一个需求分析做得很好的项目来说，基准文件定义的范围越详细、清晰，用户跟项目经理的分歧就越少。如果需求做得好，文档清晰且有客户签字，那么后期客户提出的变更超出了合同范围，就需要另外处理

（2）项目实施阶段的需求变更

成功项目和失败项目的区别就在于项目的整个过程是否是可控的。项目经理应该树立一个理念 “需求变更是必然的、可控的、有益的”。项目实施阶段的变更控制需要做的是分析变更请求，评估变更可能带来的风险和修改基准文件

13.3.2 需求跟踪

需求跟踪是指在软件需求管理的过程中定义需求变更流程，分析需求变更影响，控制变化的版本，维护需求变更记录,跟踪每项需求状态

（1）确定需求变更控制过程。制定一个选择、分析和决策需求变更的标准过程，所有的需求变更都需遵循此过程

（2）进行需求变更影响分析。评估每项需求变更，以确定它对项目计划安排和其他需求的影响，明确与变更相关的任务，并评估完成这些任务需要的工作量

（3）建立需求基准版本和需求控制版本文档

（4）维护需求变更的历史记录

（5）跟踪每项需求的状态

13.7 软件过程改进

软件过程改进（Software Process Improvement，SPI）用于帮助软件企业对其软件生产过程进行计划、过程诊断、改进方案的制订及实施等工作。它的实施对象是软件企业的软件过程，即软件产品的生产过程，也包括配置管理、软件维护等辅助过程。目前，使用最多的软件过程改进模型包括 CMM、CMMI、ISO9000 和 ITIL 等系列标准

13.6 软件的运行与评价

（1）软件的稳定性和可靠性评价。软件的稳定性，指软件在一个运行周期内、在一定的压力条件下，软件的出错几率、性能劣化趋势等，并观察其运行环境内的应用服务器、数据库服务器等系统的稳定性

（2）软件是否满足了用户的需求。满足用户的需求是软件开发的基本要求。系统交付使用前，需要用户对系统提供的需求进行评价

（3）软件实施给用户带来的好处。这是用户需要软件开发的原因。通常体现为价值指标,如节省多少人工成本，节省业务流程时间，减小数据质量出错率等

13.5 人力资源管理

1．组织规划组织规划用于确定、记录并分派项目角色、职责和请示汇报关系

（1）垂直团队组织。垂直团队由多面手组成。如，功能模块分配给了个人或小组，然后由他们从头至尾地实现该功能模块

其优点在于，以单个功能模块为基础实现平滑的端到端开发；开发人员能够掌握更广泛的技能。

缺点也很明显：多面手通常是一些要价很高并且很难找到的顾问。多面手通常不具备快速解决具体问题所需的特定技术专长。主题专家可能不得不和若干开发人员小组一起工作，从而增加了他们的负担。所有多面手水平各不相同

（2）水平团队组织。水平团队由专家组成。此类团队同时处理多个功能模块，每个成员都从事功能模块中有关其自身的方面。

优点在于能高质量地完成项目各个方面（需求、设计等）的工作；一些外部小组，如用户或操作人员，只需要与了解他们确切要求的一小部分专家进行交互

缺点在于：专家们通常无法意识到其他专业的重要性，导致项目的各方面之间缺乏联系；由于专家们的优先权、看法和需求互不相同，所以项目管理比较困难