软件工程与计算总结（四）项目管理基础

目录

一.项目和项目管理

二.团队组织与管理

三.软件质量保障

四.软件配置管理

五.项目实践

---

一.项目和项目管理

1.软件开发远不是纯粹的编程，随着软件规模的增长，软件开发活动也变得越来越复杂~

2.软件项目就是要将所有的软件开发活动组织起来，以有效地安排和控制这些活动，保证所有重要的工作都能得到应有的关注，都能顺利的完成，产生高质量道德软件产品~

3.项目是具有下列特征的一系列活动与任务：

• 具有一个明确的目标
• 有限定的开始和结束日期
• 有成本限制
• 消耗人力和非人力资源
• 多工种合作

项目的核心是计划，计划的重要内容包括：项目需要的资源、项目中需要执行的活动、以及项目中需要产生的交付制品

4.项目管理的目标：

• 在限定时间内
• 在一定的成本内
• 在要求的质量水平上
• 高效使用资源
• 获得客户认可

5.软件项目管理包括：项目启动、项目计划、项目执行、项目跟踪与控制、项目收尾5个过程

二.团队组织与管理

协作良好的团队是任何项目成功的基础。软件项目尤其依赖于有效的团队组织和管理:软件开发是一个以人为主的活动，人力资源是软件项目最大的资产。

1.团队的特征

一群人简单地集合到一起并不能自然形成团队，只有他们的组织和管理具备了某些特征才能称为团队。

• 团队成员要具备共同的目标
• 团队成员要共担责任
• 团队成员要技能互补
• 团队是小规模团体
• 团队内部要有一个明确的结构

2.团队结构

• 主程序员团队：主程序员团队中有一名技术能力出色的成员被指定为主程序员，负责领导团队完成任务
• 民主团队：成员之间没有集中的瓶颈，每个成员都可以发挥自己的能动性，能取得更高的士气和工作成就感~
• 开放团队：成员均为有创造性的产品开发者，对他们进行太多的管理会抑制他们的创造性~

3.团队建设

高凝聚力的胶冻团队不是一天形成的，需要长期的团队建设~

建立团队章程

• 1)团队的目标。
• 2)团队的共同追求。这些追求是超出项目之外的所有成员的共同追求，例如追求敏捷理念、开源理念等。
• 3)团队结构和角色分工。
• 4)团队的任务、活动与绩效。一定要明确团队的绩效标准，它体现了对团队成员的期望。
• 5)团队规则与约束。明确团队对成员提出的行为规则要求，例如保持开放氛围、积极参与团队交流活动等。

持续成功

持续成功能够促进团队建设的原因在于:

• 1)持续成功能够积累团队的信心，尤其是面对困难问题时仍然保持成功期望的信心。
• 2)持续成功能够建立团队成员之间的信任，互相信任的团队才可能成为高凝聚力团队。
• 3)持续成功能够激励团队的士气，因为成就感是最能够激励软件开发人员士气的因素。

和谐沟通

• 和谐沟通的首要原则是建立开放的环境
• 和谐沟通需要有制度保障

避免团队杀手

常见杀手类型：

• 防范式管理：管理者要信任团队成员，不能总是担心成员工作不力并据此进行防范式管理
• 官僚主义：官僚主义的管理者会导致团队的和谐交流氛围无法建立，团队的凝聚力也就无法形成。
• 地理分散：地理分散使得团队成员之间无法保持持续、紧密的沟通，无法形成团队氛围和高凝聚力。现在的视频通信等手段能部分缓解地理分散带来的困难，但定期的集中交流仍然是必要的。
• 时间分割：如果团队成员同时参与多个项目，为每个项目分割自己的一部分时间，那么团队就难以形成高凝聚力。“没有人可以成为多个胶冻团队的成员。胶冻团队的紧密人际互动是排他性的。太多分割的团队不会胶冻。
• 产品质量的降低：这是持续成功的反面，会降低团队成员的成就感和互相信任。
• 虚假的最后期限：之所以虚假是因为这些最后期限根本就不可能完成，完全是管理者为了驱动项目进度而强加的。一个做着自知不可能完成的任务的人会有士气吗?
• 小圈子控制：如果团队中有少数成员建立了小圈子，就会破坏整个团队的信任和沟通氛围，自然也就无法建立高凝聚力。

三.软件质量保障

1.软件质量

作为工程师，要对产品的质量负责，保证使用者的生命健康和经济安全~

• 显式的：指用户在软件创建之前就可以清晰地项开发者清晰地表达的要求
• 隐式的：在系统投入使用之后要求补充的条件

如下是两个权威的软件质量标准：

 

2.质量保障

由于软件开发过程是不可见的，且越晚发现缺陷，修复的代价越高，因此软件质量的保障活动要贯穿整个开发过程独立、持续地进行

主要方法有：评审、测试和质量度量3种方式

3.评审

由作者之外的其他人来检查产品问题，是静态分析手段

• 1)规划阶段(planning):制定审查计划，决定审查会议的次数，安排每次审查会议的时间、地点、参与人员、审查内容等。
• 2)总体部署阶段(overview):向所有参与审查会议的人员描述待审查材料的内容、审查的目标以及一些假设，并分发文档。
• 3)准备阶段(preparation):审查人员各自独立执行检查任务。在检查的过程中，他们可能会被要求使用检查清单、场景等检查方法。检查中发现的问题会被记录下来，以准备开会讨论或者提交给收集人员。
• 4)审查会议阶段(inspection meeting):通过会议讨论，识别、确认、分类发现的错误。
• 5)返工阶段(rework):修改发现的缺陷。
• 6)跟踪阶段(follow-up):要确认所有发现的问题都得到了解决，所有的错误都得到了修正。
• 在评审中发现问题是整个评审过程的关键。为了更好地发现问题，需要使用一些检查方法来系统化地帮助和引导检查人员。常见的检查方法是使用检查清单(checklist)[Laitenberger2002]，后面的章节会提供各项评审活动的检查清单。 

4.质量度量

依据统计控制思想，要保障软件产品的质量，就要用数字量化的方式描述软件产品。测度(measure)就是为了描述软件产品而提供的定量指标。通过给软件产品或中间制品建立度量描述，可以分析和确定它们的质量。所以软件产品质量度量是质量保障的常用手段。

• 进行测度的活动称为测量( measurement)
• 度量(metric)是软件产品在特定属性上的量化测度程度

四.软件配置管理

1.配置管理动机

配置管理的定义：用技术的和管理的指导和监督方法，来标识和说明配置项的功能和物理特征，控制对这些特征的变更，记录和报告变更处理及其实现状态，并验证与需求规格的一致性~

2.配置项

需求进行配置管理的软件开发制品，包括最终制品和中间制品。

3.基线

已经经过正式评审的规格说明或制品，可以作为进一步开发的基础，并且只有通过正式的变更控制过程才能变更

（基线的建立意味着第一个里程碑）

4.配置管理活动

• 标识配置项
• 版本管理：赋予版本号
• 变更控制：已纳入配置管理中的配置项发生变化时，需要依据变更控制过程进行处理~

• 配置审计
• 状态报告
• 软件发布管理