概念

定义

计划、协调、度量、监控、控制及报告等管理方法在软件开 发和维护中的具体应用，以保证整个过程是系统的、有原则 的、可量化的

四要素4P

  • 人员People：关键业务领域：招聘、选拔、绩效管理、培训、 薪酬、职业发展、组织和工作设计、团队/文化的发展。一个项目管理的好坏，很大程度就体现在团队的建设和管理上。人力资源管理成熟度模型（PCMM） PCMM是通过对人力资源管理的如人力资源规划、薪酬管理、绩效管理、组织管理、职 业规划、培训管理、知识管理等模块，按初始级、重复级、定义级、定量级和优化级这五 个递进层级进行详细描述和分级，建立企业人力资源管理的成熟程度评价模型，以此来对 企业目前人力资源管理现状进行评级，寻找不足和差距，以此来明确未来的发展方向。

    用人的原则：人和人是不一样的，知识、技能可以培训而改变，但人格是很难改变的 ，应该用人之所长

    项目中的三架马车：项目负责人，职能部门经理，项目成员；

    项目目标包括：商业目标，过程目标，行为目标

    如果各个因素的目标一致程度很大 对于项目成功的支持就越大

    团队成长如下图所示

    image-20241206211623192

  • 产品Product：在策划一个项目以前，应当建立产品的目标和 范围，应考虑其他解决办法，以及技术和管理应当被约束。

    在项目活动中，直接构造产品所需的工程活动比例是最高的。

    不同类型的产品所需要的工程活动特征也不一样，分为核心类产品开发，产品的客户化开发，系统的应用集成

  • 过程Process：软件开发的一个全面计划。

  • 项目Project：理解成功项目管理的关键因素，掌握项目计划、 监控和控制的一般方法

软件度量

含义

一种量化衡量方法,使得人们可以理解和把握软件项目的(生产)效率(或者所需要的劳动量)

目的

  • 描述（项目和过程）
  • 评估（状态和质量）
  • 预测（为计划）
  • 改进（产品质量和过程性能）

软件质量和组织绩效的决定因素

关键因素：过程、人、产品、技术。

过程处于三角的中心，连接其它三个因素；

image-20241206212247135

分类

  • 面向规模的度量：一定时间产生的代码行数， 执行速度，文件页数，错误和缺陷数
  • 面向功能的度量：功能性，可靠性，可维护性，复杂性，效率，其他质量指标
  • 面向对象的度量
  • 面向用例的度量

直接测量

这是一种基于规模的度量，比如基于代码行的度量

优点

  • LOC、KLOC和相关度量容易计算
  • 许多现有的软件估算模型都使用LOC和KLOC作为一项重要输入
  • 有大量的关于LOC的文献和数据

缺点

  • LOC依赖于使用的语言，这对短小精悍的程序不利
  • 不太适用于非过程化语言
  • LOC在设计完成的时候才能计算，估算需要一定程度的细节，而这些细节可能很难获得， 例如，项目计划人员难于在分析和设计完成之前估算LOC

间接度量

一般指功能点度量，功能点数从直接度量软件信息域和评估软件复杂性的经验量化关系中获得

步骤： 先算未调整功能点总计数UFC ，再算功能点FP

一般指复杂性调整值，一般有14项，取值在0~5；

  1. 系统需要可靠的备份和恢复么？
  2. 需要进行数据通信么？
  3. 有分布式处理功能么？
  4. 性能重要么？
  5. 将该系统运行在一个现有的操作系统中么？
  6. 系统要求在线输入数据么？
  7. 在线输入数据要求在多个屏幕和操作 之间建立输入事务么？
  8. 主文件是否在线更新？
  9. 输入、输出、文件或查询是否复杂？
  10. 内部处理是否复杂？
  11. 代码是可重用的么？
  12. 设计中包括数据（流程）转换或安装 么？
  13. 系统要为不同的机构设计不同的安装 方法么？
  14. 应用程序便于变更么？易于用户使用 么？

面向功能点的度量标准 计算：

  • 每FP的错误数，即总的错误数除以总的FP数。
  • 每FP的缺陷数，即总的缺陷数除以总的FP数。
  • 每FP的文档页数，即总的文档页数除以总的FP数。
  • 每人月的FP数，即总的FP数除以总的人月数

有趣的是，代码行数和功能点之间的关系依赖于编程语言；

项目估算

项目成本模型遵循以下经验公式：

  • 常量A:由组织实践和软件类型决定
  • 常量B：取值在;
  • 常量M：反应产品，过程和人力属性
  • Size是软件代码规模的估算，也可以是功能点和目标点

算法成本估算示意图

image-20241206213659612

不同软件开发阶段的估算的不确定性

image-20241206213732170

COCOMO模型

COCOMO（构造性成本模型）是一个经验模型, 通过收集大量的软件项目（63个） 的数据而获得。

它已得到广泛的证明。可用于公共领域并且很多公共和商业工具都支持它。

应用广泛，并得到了不同组织的评价。

有较长的历史，于1981年第一次实例化；

image-20241206213945142

项目计划

软件开发项目的进度安排有两种方式：

  • 系统最终交付日期已经确定，软件开发部门必须在规定期限内完成；
  • 系统最终交付日期只确定了大致的年限，最后交付日期由软件开发部门确定。

进度安排落空，会导致市场机会的丧失，使用户不满意，而且也会导致成本的增加。

因此，在考虑进度安排时，要把工作量与花费时间联系起来，合理分配工作量, 利 用进度安排的有效分析方法严密监控软件开发的进展情况，使软件开发进度不致拖延；

当几个人共同承担软件开发项目中的某一任务时，人与人之间必须通过交流来解决各自承担任务之间的接口问题，即所谓通信问题。

通信需花费时间和代价，会引起软件错误增加，降低软件生产率。

若两个人之间需要通信，则称在这两个人之间存在一条通信路径。如果一个软件开 发小组有n 个人，每两人之间都需要通信，则总的通信路径有n(n-1)/2 (条)。

  • 一个软件任务由一个人单独开发，生产率最高；
  • 而 对于一个稍大型的软件项目，一个人单独开发，时间太长。因此软件 开发小组是必要的。
  • 但是，开发小组不宜太大，成员之间避免太多的通信路径。
  • 在开发进程中，切忌中途加人，避免太多的生产率损失。

任务的确定和并行：

  • 当参加同一软件工程项目的人数不止一人的时候，开发工作就会出现 并行情形。
  • 软件开发进程中设置许多里程碑
  • 里程碑为管理人员提供了指示项目 进度的可靠依据。
  • 软件工程项目的并行性提出了一系列的进度要求。

image-20241206214344311

进度安排的方法：甘特图， PERT技术和CPM方法等

  • 可以把用于一般开发项目的进度安排的技术和工具应用于软件项目。
  • 为监控软件项目的进度计划和工作的实际进展情况，为表现各项任务 之间进度的相互依赖关系，需要采用图示的方法。
  • 在图示方法中，必须明确标明：
    1. 各个任务的计划开始时间，完成时间；
    2. 各个任务完成标志（即○文档编写和△评审）；
    3. 各个任务与参与工作的人数，各个任务与工作量之间的衔接情况；
    4. 完成各个任务所需的物理资源和数据资源

甘特图

在甘特图中，每一任务完成的标准，不是以能否继续下一阶段任务为标准，而是以 必须交付应交付的文档与通过评审为标准。因此在甘特图中，文档编制与评审是软 件开发进度的里程碑。

image-20241207000501820

PERT技术和CPM方法

PERT技术叫做计划评审技术，CPM方法叫做关键路径法，它们都是安排开发进度， 制定软件开发计划的最常用的方法。 它们都采用网络图来描述一个项目的任务网络，也就是从一个项目的开始到结束， 把应当完成的任务用图或表的形式表示出来。

image-20241207000454614

image-20241207000520257

项目的追踪和控制

软件项目管理一项重要工作就是在项目实施过程中进行追踪和控制：

  • 定期举行项目状态会议。由每位项目成员报告其进展和遇到的问题。
  • 评价在软件工程过程中所产生的所有评审的结果。
  • 确定由项目的计划进度所安排的可能选择的正式的里程碑。
  • 比较在项目资源表中所列出的每一个项目任务的实际开始时间和计划开始时间。
  • 非正式地与开发人员交谈，以得到他们对开发进展和刚冒头的问题的客观评价。
  • 当问题出现的时候，项目管理人员必须实行控制以尽快地排解问题

软件项目的组织与计划

  • 制定计划
  • 软件项目组织的建立
  • 人员配备

制定计划

软件开发项目的计划涉及到实施项目的各个环节，带有全局性质。

  • 计划的合理性和准确性往往关系着项目的成败。
  • 计划应力求完备。要考虑到一些未知因素和不确定因素，考虑到可能的修改。
  • 计划 应力求准确。尽可能提高所依据数据的可靠程度。

指定计划目标和进行风险分析

  • 制定计划的目的就是要回答：这个软件项目的范围是什么？需要哪些资源？花费多 少工作量？要用的成本有多少？以及进度如何安排等等一系列问题。
  • 这步工作应当以系统计划为基础，以系统规格说明为依据。
  • 在开发工作尚未开始之前，准确回答这些问题是十分困难的。需要通过以往的开发 经验做出估算，很难达到准确。
  • 从估算出发，项目必然带有一定的风险。估算的准确性越差，风险也就越大。研制 的软件项目越复杂，规模越大，结构化程度越低，资源、成本、进度等因素的不确 定性越大，承担这一项目所冒的风险也越大。
  • 组织软件项目必须事先认清可能构成风险的因素，并研究战胜风险的对策，只有这 样才能避免出现灾难性的后果，取得项目预期的成果。

软件计划的类型

  • 项目实施计划（软件开 发计划） ：这是软件 开发的综 合性计划， 通常应包 括任务、 进度、人 力、环境、 资源、组 织等多个 方面。
  • 质量保证计划 ：把软件开 发的质量 要求具体 规定为每 个开发阶 段可以检 查的质量 保证活动。
  • 软件测试计划 ：规定测试 活动的任 务、测试 方法、进 度、资源、 人员职责 等。
  • 文档编制计划 ：综合支持计 划 软件分发计 划 规定所开 发项目应 编制的文 档种类、 内容、进 度、人员 职责等。 规定对用 户进行培 训的目标、 要求、进 度、人员 职责等。
  • 用户培训计划 ：软件开发 项目完成 后，如何 提供给用 户。 规定软件 开发过程 中所需要 的支持， 以及如何 获取和利 用这些支 持

项目实施计划中任务的划分

如何进行工作划分是实施计划首先应解决的问题。常用的计划结构有：

  • 阶段项目计划：按软件生存期，把开发工作划分为若干阶段，对每一阶段工作做出计划。 再把每一阶段工作分解为若干任务，做出任务计划。还要把任务细分为若干步骤，做出步 骤计划。

  • 任务分解结构WBS：按项目的实际情况进行自顶向下的结构化分解，形成树形任务结构。进一 步把工作内容、所需工作量、预计完成的期限也规定下来。

    image-20241207001143613

  • 任务责任矩阵：在任务分解的基础上，把工作分配给相关的人员，用一个矩阵形表格表示 任务的分工和责任。

    image-20241207001154418

软件项目组织建立

开发组织采用什么形式，要针对软件项目的特点来决定，同时也与参与人员的素质 有关。

  1. 组织原则 ：

    • 尽早落实责任：在软件项目工作开始时，要尽早指定专人负责。使他有权进行管理，并对任务的完成负全责。
    • 减少接口：一个组织的生产率随完成任务中存在的通信路径数目增加而降低。 要有合理的人员分工、好的组织结构、有效的通信，减少不必要的生产率的损失。
    • 责权均衡：软件经理人员所负的责任不应比委任给他的权力还大。

  2. 组织结构的模式

    • 按课题划分的模式 把软件开发人员按课题组成小组，小组成员自始至终参加所承担课题的各项任务。他们应负责 完成软件产品的定义、设计、实现、测试、复查、文档编制、甚至包括维护在内的全过程。
    • 按职能划分的模式 把参加开发项目的软件人员按任务的工作阶段划分成若干个专业小组。要开发的软件产品在每 个专业小组完成阶段加工（即工序）以后，沿工序流水线向下传递。例如，分别建立计划组、需求 分析组、设计组、实现组、系统测试组、质量保证组、维护组等。各种文档资料按工序在各组之间 传递。
    • 矩阵形模式 这种模式实际上是以上两种模式的复合。一方面，按工作性质，成立一些专门组，如开发组、 业务组、测试组等；另一方面，每一个项目又有它的经理人员负责管理。每个软件人员属于某一个 专门组，又参加某一项目的工作。

    image-20241207001409920

  3. 程序设计小组的组织形式

    小组内部人员的组织形式对生产率也有影响。现有的组织形式有三种。 （1）主程序员制小组 （2）民主制小组 （3）层次式小组

    image-20241207001357518