ch-1

软件的概念

软件指的是在计算机系统的支持下，能够完成特定功能的程序、数据、文档。

软件的特点

目的性、组成性、系统性、驻留性

（用于满足要求、三个部分组成、是一个系统，有各种组成要素、依赖于计算机系统软硬设备）

逻辑性、复杂性、易变性、缺陷的隐蔽性、复杂性、由设计开发而来

• 软件和硬件的特点：表现形式、开发范式、需求变化、复杂性、系统缺陷

• 软件质量是指满足给定需求的质量。

  • 修正性：可维护性、可测试性、灵活性、可理解性
  • 转移性：可移植性、可重用性、互操作性
  • 运行性：正确性、有效性、可靠性、完整性、可用性、健壮性、安全性、可信性、持续性

软件危机的概念与产生原因

概念：在软件开发和维护过程产生的一系列问题：进度难以控制、质量难以保障、软件维护困难、容易超出成本、失败风险大

产生原因：对软件的复杂性认知不够、没有找到支持软件系统的有效方法、缺乏成功的软件开发实践和对应的开发经验

什么是软件工程

将系统化、规范化、可量化的方法应用于软件的开发、运行和维护的过程。以及上述方法的研究。

系统化：提供完整和全面的解决方法，包括目标、原则、过程模型、开发活动、开发方法和技术等

规范化：规范化软件系统的开发，包括语言标准、质量标准、编程标准、方法标准、能力极其改进标准等

可量化：为软件开发和管理提供量化的支持，如工作量、成本、进度、质量等要素的量化

认为软件是一个产品，软件开发是一项工程，要按照工程化的方法组织生产。

将软件开发从基于个体的作坊式创作转变成基于团队的协同开发。

软件工程的构成要素

过程、方法、工具

过程：从管理的视角，回答软件开发、运行、维护需要开展什么工作，按照什么样的步骤和次序进行开展。（产生了过程模型）

方法：从技术的角度，回答软件开发、运行、维护如何做的问题（如何进行开发）

工具：从工具辅助的角度，回答如何借助工具辅助软件开发、运行、维护。

方法的关注点（技术视角的“如何”）：

“我应该用面向对象方法来抽象这个用户模型，把属性和行为封装在一起。” —— 这是在选择方法。

过程的关注点（管理视角的“如何”）：

“我应该先写完所有的详细设计说明书，然后再开始写代码。”（瀑布模型）或者“我应该先写一个最小可行产品 (MVP)，听听用户反馈再改。”（敏捷模型） —— 这是在选择过程。

• 计算机辅助软件工程(Computer-Aided Software Engineering, CASE)

• 软件开发：软件创作 + 软件生产

软件创作和软件生产

软件创作：基于软件开发者的经验和技能，借助于智慧，进行自由创新，进行自由创新，如软件设计、编码实现

软件生产：基于工程化的手段，遵循约束和规范，开展软件生产，如遵循过程、按照标准、质量保证等。

软件工程目标

在成本进度等约束条件下，指导软件开发和运维，开发出满足用户需求的足够好的软件。

软件工程原则

抽象和建模

抽象将与相关开发活动所关注的要素提取出来，不关心的要素扔掉，形成与该开发活动相关的软件要素建模基于特定抽象，借助于建模语言（如数据流图、UML等），建立起基于这些抽象的软件模型，进而促进对软件系统的准确理解

模块化

将软件系统的功能分解和实现为若干个模块，每个模块具有独立的功能，模块之间通过接口进行调用和访问。模块内部高内聚，模块间松耦合

软件重用

开发过程中尽可能利用已有软件资源和资产（如函数库、类库、构件库、开源软件、代码片段等）来实现软件系统开发出可被再次重用软件资源（如函数、类、构件等）有助于提高软件开发效率，降低软件开发成本，满足开发工程约束，得到高质量的软件产品

信息隐藏

模块内部信息（如内部的语句、变量等）对外不可见或不可访问，模块间仅仅交换那些为完成系统功能所必需交换的信息（如接口）模块设计时只对外提供可见的接口，不提供内部实现细节。信息隐藏原则可提升模块的独立性，减少错误向外传播，支持模块的并行开发

关注点分离

在软件开发过程中，将若干性质不同的关注点分离开来，以便在不同开发活动中针对不同的关注点，随后将这些关注点的开发结果整合起来，形成关于软件系统的完整视图软件系统具有多面性的特点，既有结构特征，如软件的体系结构，也有行为特征，如软件要完成的动作及输出的结果；既有高层的需求模型，描述了软件需要做什么，也有低层的实现模型，描述了这些需求是如何实现的使得开发者在每一项开发活动中聚焦于某个关注点，有助于简化开发任务；同时通过整合多个不同视点的开发结果，可获得关于软件系统的更为清晰、系统和深入地认识

分而治之

开发人员可对复杂软件系统进行分解，形成一组子系统如果子系统仍很复杂，还可以继续分解，及至得到的子系统易于处理；然后通过整合子系统的问题解决得到整个系统的问题解决有助于简化复杂软件系统的开发，降低软件开发复杂性，从而提高软件开发效率，确保复杂软件系统的质量

双向追踪

正向和反向追踪当软件制品发生变化时，要追踪这种变化会对那些软件制品产生影响，进而指导相关的开发和维护工作，此为正向追踪追踪产生这种变化的来源，或者说是什么因素导致该软件制品的变化，明确软件制品发生变化的原因及其合理性，此为反向追踪有助于确保软件制品间的一致性，发现无意义的变化，并基于变化指导软件的开发和维护，确保软件质量

工具辅助

利用软件工具来辅助软件开发和维护工作是一项行之有效的方法尽可能地借助计算机工具来辅助软件开发和维护，以降低开发者和维护者的工作负担，提高软件开发和维护效率，提升软件开发及软件制品的质量

开源软件

一种源代码可以自由获取和传播的计算机软件，其拥有者通过开源许可证赋予被许可人对软件进行使用、修改和传播

采购和开发的成本更低

开源软件通常是免费的，即使要付费，其费用也非常低廉

软件质量更高、更安全

核心代码都在公众的视野之中，代码问题（如缺陷、安全漏洞等）很容易被人发现

软件研制和交付的更快

基于开源软件的项目开发可以更为快速地给用户交付

软件产品软件功能更为强大

大量的软件开发者不仅参与软件开发，贡献他们的代码，而且还参与软件的创新，提出和构思软件需求，不断完善软件功能

ch-02

软件生命周期

从提出开发开始到开发出系统、运行维护以及最终退役的全过程（需求分析、软件设计、编码实现、软件测试、部署运行、使用维护）

软件过程

按照项目进度、成本、质量要求，遵循用户需求，开发和维护软件，管理软件项目的一系列的有序的软件开发活动

• 软件开发活动：技术活动和管理活动

软件过程模型

定义软件开发的具体活动和活动之间的逻辑关系

活动

需求分析：定义软件需求，产出软件需求模型、软件需求文档、软件确认测试计划。产生文档类的软件制品

概要设计：建立软件总体架构、制定集成测试计划。产出软件概要设计模型、软件概要设计文档、软件集成测试计划，产生文档类的软件制品

详细设计：设计模块内部细节(算法、数据结构)，制订单元测试计划。产出软件详细设计模型、软件详细设计文档、单元测试计划产生文档类的软件制品

编程实现：编写代码进行单元测试和调试。产出经过单元测试的源程序代码。产生程序类的软件制品。

集成测试：组装软件模块并进行测试以发现问题。产出经过集成测试、修复缺陷的源程序代码，集成测试报告产生数据、文档和代码类的软件制品

确认测试：测试软件是否满足用户需求，产出经过确认测试、修复缺陷后的代码，产出软件确认测试报告产生数据、文档和代码类的软件制品

瀑布模型

定义的过程：需求分析 - 概要设计 - 详细设计 - 编码实现 - 集成测试 - 确认测试

特点：与软件生命周期相互一致、每个活动结束后需要评审、相邻活动间存在因果关系。

优点：简单，一目了然，易理解、掌握、应用和管理

缺点：软件需求易变，导致从头再来（优化就是加上回溯与修改）软件开发处于动荡中，在所有功能实现之后，才能得到可运行软件。

适用：需求易于定义，不易变动的软件系统。

增量模型

定义的过程：需求分析 - 概要设计 - 对增量 i 进行详细设计 - 编码实现 - 集成测试，在所有增量完成之后，进行确认测试。

特点：渐进式、增量式地实现软件功能

优点：渐进快速交付，并行开发，提升效率

缺点：全局架构设计难度大，集成成本高，回归测试难度大，管理复杂度大

适用于：需求可以明确，且不易变化（但是有优先级）的场景

迭代模型

定义的过程：每一次迭代都是优化后的瀑布模型，每一次迭代完成部分可确定的软件需求。

特点：小步快跑，每一次迭代都是完整的过程。

优点：灵活应对需求变更，质量控制很好

缺点：容易无限期迭代下去，资源消耗高，管理复杂度高

适用于：需求难导出、不易确定且持续变动的软件

原型模型

定义的过程：采集和细化需求 - 快速设计 - 建造原型 - 使用评价原型 - 获得反馈 - 回到开头 or 开发系统

特点：软件原型作为交流载体和媒介，支持用户参与到软件开发中，持续、渐进地导出用户要求

优点：需求定位准，沟通门槛低。

缺点：快而后糙的后遗症，留下隐患；开发成本容易爆炸，对人员能力要求高

适合：需求难导出、不易确定且持续变动的软件

螺旋模型

定义的过程：迭代：制定计划 - 风险分析 - 实践工程 - 客户评估。

特点：风险驱动。（软件风险：使软件开发受到影响和损失、甚至导致失败的、可能会发生的事件）

优点：风险控制力强，灵活性高

缺点：成本昂贵，对开发人员要求极高，容易陷入过度开发，管理复杂

适合：高风险的大任务

敏捷软件开发方法

以文档为中心的重型软件开发方法，非常笨重：

• 遵循严格的过程和计划
• 以文档为中心
• 等到开发后期才能得到可运行软件

因此产生了：

重视人和交互、重视可运行软件系统、重视客户合作、重视响应用户需求变化的敏捷开发方法。

”少写软件文档，以代码为中心，快速响应变化“

核心价值：

较之于过程和工具，应更加重视人和交互的价值

较之于面面俱到文档，应更加重视可运行软件系统的价值

较之于合同谈判，应更加重视客户合作的价值

较之于遵循计划，应更加重视响应用户需求变化的价值

例子：scrum 方法，测试驱动开发，极限编程、devops 方法

特点：文档少，周期小，规模小，迭代周期短，每次迭代解决的问题简单，快速响应变化，从用户处获得反馈，允许动态变化

• 基于团队的软件开发方式和组织模式：项目边界封闭

• 群体化开发：依托互联网平台来吸引、汇聚、组织和管理互联网上的大规模软件开发人员，通过竞争、合作、协商等多种自主协同方式，让他们参与软件开发、分享软件开发知识和成果、贡献智慧和力量的一种新颖软件开发方法

• 群体化软件开发方法的特点：软件开发边界开放、互联网大众自由参与、利用海量的大众资源、共享源程序代码、兼顾软件创作和生产、依托互联网平台

ch-03 需求分析

需求分析概念

• 软件开发的本质：根据软件利益相关方的期望和要求，生成软件需求，再依据软件工程过程、方法学和工具，输出软件（文档、代码、数据）

• 利益相关方：从软件系统中受益或与软件系统相关的人、组织或者系统

软件系统的相关利益方，对软件系统的功能和质量，以及软件运行环境、交付进度等方面提出的期望和要求。

指软件用于解决现实世界问题时所表现出的功能和性能等方面的需求。

• 软件需求分为功能性需求、质量需求、约束性需求。

• 具有隐式性、隐晦性、多源性、易变性、领域知识相关性、价值不均性

• 质量要求：有价值、正确、完整、无二义、可行、一致、可追踪、可验证

• 软件需求重要性：软件的价值和意义所在、软件开发的基础和前提、软件验收的标准和依据

• 什么是需求工程：用工程化的理念和方法指导软件需求实践

需求分析和确认

• 需求的工程方法：抽象（有助于揭示（尤其是功能性）需求的本质）、建模（为了更清晰地表达需求，以便于各方之间的理解和交流）、分析（有助于精化需求、发现并解决需求中的问题）

前面是需求分析，最后一个环节是需求确认。

结构化软件需求分析

基本思想：软件的功能主要反映为软件具有什么样的数据以及要对数据进行怎样的处理，软件的功能主要反映为软件具有什么样的数据以及要对数据进行怎样的处理

用数据流图进行建模

（面向对象的）获取需求 & 需求分析

基本思想：面向对象软件工程提供对象、类、属性、操作、消息、继承等概念来抽象表示现实世界的应用，分析其软件需求特征，建立起软件需求模型，描述软件需求

利用 UML 图（用来可视化 、描述、构造和文档化软件密集型系统的各种产品支持不同人员之间的交流）进行建模。

优势：自然建模 & 统一抽象概念

总体步骤：

明确问题边界，获取软件需求，建立用例模型

理解系统边界，识别系统利益相关方，导出或构思软件需求，绘制出软件用例图，建立软件用例模型

开展用例分析，精化软件需求，建立分析模型

分析用例，从而精化软件需求，建立起用例的交互模型，并依此导出系统的分析类图

汇总需求模型，撰写需求文档

汇总不同视点、不同抽象层次的需求模型，撰写软件需求文档

！！！如何初步获取软件需求：清晰界定软件要解决的问题及其边界，决定软件的方案（黏合两个系统还是开发新的系统），识别软件利益相关方，然后采取多样化的需求获取方式。传统的有访谈与会议、调查问卷、现场观摩、分析业务资料；创新辅助方案有：软件原型、大脑风暴、集思广益、大模型生成。然后站在利益相关方的视角，导出功能性需求和非功能性需求（质量和约束性）

！！！如何分析软件需求：分析软件需求的优先级，确定用例分析和实现的次序，接着去建立模型。首先分析和建立用例交互模型（分析和确定用例所涉及的对象类（通常是便捷类，控制类，实体类，总称为分析类），分析和确定对象间的消息传递，最后绘制用例交互图），然后分析和建立分析类模型（确定分析类，确定分析类的职责和属性，确定类间关系，绘制分析类图），最后分析和建立状态模型（画状态图）

（面向对象的）需求确认

站在用户和客户的角度，确保软件需求的正确性，通常采用需求评审（Review）、原型确认等方式。

评审：

中肯性，软件问题是否反映实际问题，是否有意义和价值合理性，基于软件的解决方案是否科学和合理。

完整性，软件需求是否覆盖了利益相关方的期望和要求

必要性，每一项软件需求是否有必要

溯源性，每一项软件需求是否都有其来源准确性，描述是否清晰和准确地反映了软件需求的内涵

正确性，是否正确反映该需求提出者真实想法

和关注点一致性，软件需求文档、用例模型以及软件原型对软件系统需求的表述（包括术语等）是否一致

可行性分析：

技术可行性

设备可行性

进度可行性

成本可行性

商业可行性

社会可行性

对软件需求模型和文档进行评审，以确保它们的质量

需求验证

判断软件需求文档和模型是否准确地刻画了用户和客户的要求，后续的软件设计制品、程序代码等是否正确地实现了软件需求

需求的变更管理

多变性和易变性引起的，明确哪些方面的需求发生了变化、反应在软件需求模型和文档的哪些部分、导致软件需求模型和文档的版本发生了什么样变化等

软件需求的追溯管理

开展溯源追踪，掌握清楚是谁提出需求变更、为什么要进行变更等内容，以判别需求变更的合法性；评估需求变更的影响域，基于对需求变更的理解，分析需求变更会对哪些软件制品会产生什么样的影响；评估需求变更对软件项目开发带来的影响

输出

软件需求模型、软件需求文档、软件原型

画图

用例图 - 用力模型

交互图（顺序图）

分析类图 - 结构模型

活动图（含泳道图） - 行为模型

ch-04 系统设计

系统设计分为概要设计和详细设计。

系统设计从体系结构、数据、接口、构件四个方面进行设计。

重要概念

抽象：在分析和解决问题时，忽略与当前目标无关的细节，专注于与当前目标相关的方面 。

体系结构：从高层抽象角度刻画组成软件系统的设计元素（如子系统、构件）以及它们之间的逻辑关联

设计模型：一种经过充分实践考验的、针对特定环境下重复出现的设计问题的解决方案 。

模块化：将软件系统分解为一组相对独立的模块（如包、构件、类），每个模块实现单一功能，通过接口组装 。

信息隐藏：模块应设计得使其内部信息（数据、过程）对不需要这些信息的模块不可访问，只通过接口交换必要信息

功能独立：高内聚：模块内部各成分紧密结合，完成单一功能 。低耦合：模块之间联系越少越好，依赖程度低

细化：一个从高层抽象到低层抽象的逐步过渡过程

重构：在不改变软件外部行为的前提下，改进其内部结构。

软件设计的过程

体系结构设计 - 人机交互设计 - 软件详细设计 - 文档化软件设计 - 软件设计评审

软件设计元素：过程函数设计类、软构件、子系统

• 结构化软件设计：基于结构化需求分析结果（如数据流图），将其设计为以功能模块为核心的软件设计模型（如模块化、层次化的设计模型），最后交由结构化程序设计语言（如C、Fortran等）加以实现。以数据流为输入，以层次化的软件体系结构为输出采用转换和映射的方法，这一步是体系结构设计。

构件设计模式（面向子系统或者构件）、实现设计模式（面向子系统或者构件的功能）

体系结构设计（面向整个软件系统）

体系结构是以软件需求实现为目标的软件设计蓝图。

定义的过程：系统的设计 - 系统部署设计。

设计原则：高层抽象和组织、模块化、信息隐藏、软件重用、多视点分离

设计元素：构件、连接件、约束。

构件：软件系统中的物理模块，具有特定的功能和精确定义的对外接口，外界可通过接口来访问它

• 可分离、可替换、可配置、可复用

连接件：表示软构件之间的连接和交互关系。

约束：对软构件的布局及相互之间的交互进行必要的限制

多种设计模型：分层风格、管道与过滤器风格、MVC 风格、SOA 风格、总线风格。

然后确立设计元素（子系统和接口（要求职责正交、接口极小化）、构件、设计类），设计部署模型，最后进行整合。

软件详细设计

用例设计 - 构件 / 子系统设计 - 类设计 - 数据模型设计

用例设计：给出用力的具体实现解决方案，描述用例如何通过各个设计元素的交互和协作完成。

类设计：给出每个设计类的具体实现细节。包括类的属性定义，方法的实现算法等。（类的可见范围、属性的数据类型、方法的实现算法、类间关系、状态变化或者活动情况）

数据设计：对软件设计的持久数据和操作进行设计，明确持久数据的存储方式和格式，细化数据操作的实现。（确定持久数据 - 确定数据存储和组织方式 - 设计数据访问操作 - 评审和优化数据设计）

• 设计原则：可追踪、无冗余、考虑和权衡时空效率、贯穿整个软件设计阶段、验证数据完整性

子系统设计 / 构件设计：针对粗粒度的子系统和软构件，给出其细粒度的设计元素，如子子系统、设计类等，明确这些设计元素之间的协作关系，使得它们能够实现子系统/软构件接口所规定的相关功能和服务。（精细化子系统内部设计元素 - 到处子系统的设计类图 - 构造子系统的活动图状态图 - 评审子系统设计）

软件设计评审

规范性、简练性、正确性、可实施性、可追踪性、一致性、高质量

画图

包图

构件图

部署图

交互图 （顺序图）

设计类图

活动图

状态图

ch-05 软件测试

软件质量概念

明确表示是否符合功能和性能要求，明确地记载开发标准和所有专业开发软件的期望的隐性特点。

关键点：符合明确规定的功能和性能要求。符合明确的开发标准，符合所有软件开发专业的共性、隐性标准，如易用性、可维护性。

• 软件质量保证：遵照一定的软件生产标准、过程和步骤对软件质量进行评估的活动。
  • 审查：遵照一定的软件生产标准、过程和步骤对软件质量进
  • 监督：对比文档中描述的执行和实际操作步骤，确保执行过程采取适当步骤和操作方式
  • 审计：确保开发过程使用了恰当的质量控制措施，以符合相应的标准或过程
• 软件测试：运行软件或模拟软件的执行，发现软件缺陷的过程

软件测试策略 V 模型

• 软件测试策略：规定了测试的主要步骤，为软件开发人员、质量保证组织、和客户提供了一个路线图。要求是灵活性和严格。

V 模型非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段对应关系。

测试流程：明确测试对象，制定计划，编写与评审测试用例，编写测试脚本，搭建测试环境。构造测试数据，执行测试记录问题，确认问题，写测试报告，修改，进行回归测试。

单元测试：主要目的是验证软件模块是否按详细设计的规格说明正确运行。（模块接口测试，局部数据结构测试，路径测试，错误处理测试，边界测试，）

集成测试：主要目的是检查多个模块间是否按概要设计说明的方式协同工作。

分类：自顶向下的集成方法（深度 / 广度优先）、自底向上的集成方法（深度 / 广度优先），集成中的 SMOKE 方法。

系统测试：主要目的是验证整个系统是否满足需求规格说明。

分类：压力测试、新功能测试、功能测试、恢复测试、安全测试、配置测试、兼容性测试、本地化测试、易用性测试、文档测试

验收测试：从用户的角度检查系统是否满足合同中定义的需求，以及以确认产品是否能符合业务上的需要。

分类：alpha 测试（用户和开发者在开发环境下一起测试）、beta 测试（最终用户在实际环境下进行测试）。

回归测试：有选择地重新测试系统或其组件，以验证对软件的修改没有导致不希望出现的副作用，并且系统或组件仍然符合其指定的需求。范围：缺陷再测试、功能改变的测试，新功能测试，完全回归测试。

关键概念

测试用例：输入数据、前置条件、测试步骤、预期输出。

软件缺陷：软件缺陷是指存在于软件（包括模型、文档、代码）中的错误或不足，它们最终会导致软件在运行时失效，无法满足预期的功能或性能要求 。

验证和确认：验证：检查过程是否符合规范是否正确；确认：检查适合满足需求。

测试和质量保证：技术层面的活动，检查软件缺陷；管理层面的活动，检查软件开发是否符合规范。

质量和可靠性：后者包含于前者。

调试与测试：解决问题（在测试发现缺陷后，深入代码内部，通过断点、日志等手段定位缺陷的根源，并修改代码以排除缺陷） & 暴露问题（通过运行用例，发现“预期结果”与“实际结果”不一致的地方）

题目

白盒测试方法

语句覆盖（节点覆盖）

分支覆盖（边覆盖，判定覆盖）

条件覆盖

条件组合覆盖

路径覆盖

基本路径覆盖

黑盒测试方法

等价类划分

边界值分析

静态分析测试方法

略

静态分析是指不运行程序代码，而是通过人工阅读或工具辅助的方式，对程序代码、需求文档或设计文档进行检查的过程

ch-06 软件实现

软件实现概念

根据软件设计模型，编写出目标软件系统的程序代码，并对代码进行必要的测试，以发现和纠正代码中存在中的缺陷，并将可运行的目标代码部署到目标计算器上运行。

不仅要编写出程序代码，而且要确保质量。

主要工作内容：编码、单元测试、调试、部署。

群智社区的意义

软件重用

学习与提升

协同与工具

程序设计语言的选择

应用领域：

• 科学计算选 Fortran、C；
• 数据库应用选 SQL、Delphi；
• 机器人/嵌入式选 C、C++、Python；
• 互联网应用选 Java、ASP 。

与遗留系统的交互：考虑是否需要与旧系统互操作 。

特殊功能需求：

• 交互底层硬件选 C、汇编 。
• 需要丰富类库支持选 Python、Java 。
• 知识推理选 Prolog、Lisp 。

目标平台：例如 J2EE 架构需选 Java，ROS（机器人操作系统）开发建议选 C++ 或 Python

程序员经验：优先选择团队熟悉的语言，避免使用未经验证的语言 。

类代码的实现与规范

文件组织：将一个类的代码组织为一个文件，并使用统一的命名规则，保持清晰

结构化布局：

• 按字母顺序说明对象名 。
• 按一定次序说明数据 。
• 确保每个模块内部代码单入口、单出口

注释与文档：对关键语句、语句块、方法进行注释，采用缩进和括号明确层次

理解编程习惯与软件缺陷：易读性、简洁性、容错性 && 软件缺陷

软件调试的工作

1. 发现原因：分析导致软件失效或缺陷的根本原因 。
2. 定位位置：在代码中找到产生缺陷的具体行或模块 。
3. 修复缺陷：修改代码以纠正错误，并确保修改后程序能正常运行 。

ch-07 软件项目管理

概念

项目：为创建一个唯一的产品或者唯一的服务而进行的努力。基于既定资源和约束，为实现既定目标而实现的活动。

• 目标性、进度性、约束性、多方性、独立性、不确定性

• 影响项目成功的因素：项目范围、进度计划、开发成本、客户满意度

软件项目：针对软件这一特定产品和服务的项目努力开展“软件开发活动”

• 对象：作为逻辑产品的软件
• 过程：不以制造为主，没有重复生产过程
• 属性：实施要素难以度量和估算，如成本、进度、质量
• 复杂性：作为逻辑产品的复杂性非常高
• 易变性：软件需求通常难以确定且经常变化

软件项目的任务：按照预定的进度、成本和质量，开发出满足用户要求的软件产品

• 实施方法：工程化（软件工程方法）

软件项目管理的对象：过程管理、人员管理、产品管理。

管理过程：定义、文档化软件开发过程、明确软件开发活动，得到一个良定义、全面、灵活、简洁和可供剪裁的软件开发过程

软件项目管理（管理过程）：对软件项目所涉及的过程、人员、产品、成本和进度等要素进行度量、分析、规划、组织和控制的过程，以确保软件项目按照预定的成本、进度、质量要求顺利完成

项目跟踪（管理过程）：定义、文档化软件开发过程、明确软件开发活动，得到一个良定义、全面、灵活、简洁和可供剪裁的软件开发过程

管理软件过程明确软件开发活动及过程：过程定义估算软件项目工作量成本：软件度量制定计划、跟踪过程、风险控制等

管理软件产品明确有哪些产品，呈什么形式(规范文档)质量保证、配置管理、需求管理，风险控制

管理项目人员组建开发团队、调动积极性和激情团队建设与沟通、机制设计、风险控制

以下是软件产品管理

软件度量、测量和估算

对软件项目的过程、产品、资源的属性的定量描述

目的是为了对软件项目进行更好管理，如制定计划、质量保证等

软件度量(Metrics)是指对软件产品、软件开发过程或者资源的简单属性的定量描述

软件测量(Measure)对软件产品、软件开发过程和资源复杂属性的定量描述，用于事后 or 实时

估算(Estimation)对软件产品、软件开发过程和资源复杂属性的定量描述，用于事前

常用方法：面向规模的度量 & 构造性成本模型

软件项目计划

核心任务：对活动、人员、任务划分、进度、资源分配做预先规划

工具和技术：甘特图、活动依赖关系的定义

软件配置管理

核心任务：标识、存储、变更控制和版本发布

用于应对易变性和形成基线。

管理对象：配置项 (SCI)，包括文档、代码、数据等

软件风险管理

风险是可能会发生、一旦发生会带来损失的不确定事件 。

类型：需求风险（变化、定义不清楚）、产品风险（模块错误率高、性能不够）、人员风险（核心人员离职）

管理流程：识别、分析、排序、化解、监控

软件质量保证

核心目的：为管理层提供可视性 (Visibility)。不仅仅是让产品没Bug，而是要让管理者清楚地知道质量现状在哪里，哪些地方有问题

主要手段：技术：测试代码、静态分析；管理：制定标准规范，审查文档和开发活动。

执行者：SQA 小组。

ch-0x 软件部署

软件部署

指将目标软件系统（包括构件、配置文件、文档等）进行收集、打包、安装、配置并发布到运行环境的过程

软件运行环境：软件赖以生存的场所，提供必要的基础服务、数据和计算能力。纵向依赖操作系统，横向依赖其他的应用。

主要工作：安装和配置运行环境。安装和配置目标软件系统。

软件维护

定义：在软件交付使用后，为了修正错误、提升性能或其他属性而对软件进行的修改过程 。

纠错性维护、适应性维护、完善性维护、预防性维护

软件老化

随维护次数的增多，软件质量下降，架构变得脆弱，修改成本急剧增加，用户满意度降低 。

原因：缺乏变更、负面变更

软件演化与再工程

代码重组：在不改变软件功能的前提下，对程序代码进行重新组织，使得重组后的代码具有更好的可维护性，能够有效支持对代码的变更

逆向工程：基于低抽象层次软件制品，通过对其进行理解和分析，产生高抽象层次的软件制品。（举例：设计重构）

再工程：通过分析和变更软件架构，实现更高质量软件系统的过程再工程既包括逆向工程也包括正向工程