程序员不得不会的计算机科班知识——软件工程篇（软件过程）

酒酿小小丸子

已于 2024-01-11 20:01:36 修改

阅读量764

点赞数

文章标签：软件工程数据仓库 spark 大数据 java ide python

于 2023-08-22 15:16:09 首次发布

本文链接：https://blog.csdn.net/2201_75362610/article/details/132428557

版权

第二章软件过程（Sofeware Process）

2.1 软件工程的层次（层次化，Hierarchical）

软件工程是层次化的结构：

工具：为Process过程和Method方法提供支持
方法：提供技术上的解决方法，指出如何构建
过程：基础，及时、合理地把技术结合在一起
质量关注点：根基，质量承诺

2.2 软件过程概述（Sofeware Process）

2.2.1 通用过程框架（ Generic process framework）

过程框架定义了若干个小的框架活动，为完整的软件开发过程建立了基础。这些框架活动可广泛应用于所有软件开发项目，过程框架还包括一些普适性活动。
通用的软件工程过程框架的5个活动：沟通、策划、建模、构建、部署。（Communication, planning, modeling, construction and deployment）
部署活动提供了反馈报告（ feedback report）

通用框架活动：

沟通：包含了与客户（和其他共利益者）之间大量的交流和写作，还包括需求获取以及其他相关活动。
策划：指为后续的软件工程工作制定计划。它描述了需要执行的技术任务、可能的风险、资源需求、工作产品和开发人员更好地理解软件需求；设计可以实现需求。
建模：它包括创建模型和设计两方面。创建模型有助于客户和开发人员更好地理解软件需求，设计可以实现需求。
构建：它包括编码（手写或自动生成）和测试。
部署：软件（全部或者完成的部分）交付到用户，用户对其进行评测并给出反馈意见。

注：
1）不同软件过程细节可能差别很大，但框架活动都是一致的。
2）对许多项目来说，随着项目的开展，框架活动可以迭代应用。即，在项目的多次迭代过程中，沟通、策划、建模、构建、部署等活动不断重复（迭代 -> 软件增量 -> 软件逐渐完善）。

2.2.2 普适性活动（umbrella activities）

软件项目跟踪和控制Software project management
技术评审Formal technical reviews
软件质量保障Software quality assurance
软件配置管理Software configuration management
工作产品的准备和生产Work product preparation and production
可复用管理Reusability management
测量Measurement
风险管理Risk management

2.2.3 过程评估和改进（Capability maturity Model，CMM等）

2.2.3.1 软件能力成熟度模型的五大等级

(1）初始级

软件过程的特点是无秩序或说无定规的，有时甚至是混乱的。软件过程定义几乎处于无章法、无步骤可循的状态，软件产品所取得的成功往往依赖于极个别人的努力和机遇。

(2）可重复级

已建立了基本的项目管理过程,可用于对成本、进度和功能特性进行跟踪。对类似的应用项目,有章可循并能重复以往所取得的成功。

(3）已定义级

用于管理的和工程的软件过程均已文档化、标准化，并形成了整个软件组织的标准软件过程。全部项目均采用与实际情况相吻合的、适当修改后的标准软件过程来进行操作。

(4）已管理级

软件过程和产品质量有详细的度量标准。软件过程和产品质量得到了定量的认识和控制。

(5）优化级

通过对来自过程、新概念和新技术等方面的各种有用信息的定量分析，能够不断地持续地对促进过程进行改进。

2.2.3.2 一些能力成熟度模型评估方法

Standard CMMI Assessment Method for Process Improvement (SCAMPI)：用于过程改进的CMMI标准评估方法。分五个评估阶段：起始、诊断、建立、行动和学习。
CMM-Based Appraisal for Internal Process Improvement (CBA IPI)：用于组织内部过程改进的CMM评估。为评估软件组织的相对成熟度提供诊断技术、使用SEI-CMM作为评估的基础。
SPICE—The SPICE (ISO/IEC15504) ：软件过程改进和能力测定（software process improvement and capability determination）。标准定义了软件过程评估的一组需求。本标准的目的是帮助组织对任何定义的软件过程的有效性进行客观的评估。
ISO 9001:2000 for Software：国际标准化组织的软件开发标准。一种通用标准，适用于任何希望提高其提供的产品、系统或服务的总体质量的组织。因此，本标准直接适用于软件组织和公司。
GB 国标，其中：
- CMM最先出现，但后来得到了改进，并被CMMI所取代。
- 不同的三坐标测量机存在重叠、矛盾、缺乏标准化等问题。CMMI后来解决了这些问题。
- 最初，CMM专门描述软件工程，而CMMI描述集成过程和规程，因为它同时适用于软件和系统工程。
- CMM/CMMI适用于大型项目。关注过程，而不是软件开发的人员和技术方面，这意味着实现它们并不能保证项目成功。
- CMM/CMMI是一个综合的过程元模型，它描述了成熟软件过程中应该出现的特定目标、实践和能力。

2.3 过程流（Process flow，线性、迭代、演化、并行）

线性过程流：从沟通到部署顺序执行五个框架活动
迭代过程流：在执行下一个活动前，重复执行之前的一个或多个活动
演化过程流：采用循环的方式执行各个活动
并行过程流：将一个或多个活动与其他活动并行执行

2.4 过程模型（Process Model）

软件过程模型习惯上也称为软件开发模型，它是软件开发全部活动、动作和任务的结构框架。

2.5.1 瀑布模型（Waterfall Model）

即典型生命周期模型：沟通、策划、建模、构建、部署，如同瀑布流水逐级下落。

2.5.2 V模型（V-Shape Model）

V模型是瀑布模型的一个变体。V模型提供了一种将验证确认活动应用于早期软件工程工作中的方法。

2.5.3 增量模型（Incremental Model）

每个增量都是可提交运行的版本，（第一个增量往往是核心产品core product）

2.5.4 演化模型之概述（Evolutionary Model）

软件总是在持续改变，这些改变通常要求在非常短的期限内完成，在许多情况下，及时投入市场是最重要的要求（如果错过了，软件本身可能会变得毫无意义）。
软件团队面临的挑战是在这些关键项目、产品参数和客户满意度之间建立适当的平衡
在许多情况下，上市时间是最重要的管理要求。如果错过了一个市场窗口，软件项目本身可能毫无意义。
缺陷：
- 不确定性
- 演化速度的控制
- 应侧重灵活性与扩展性
- 演化模型是迭代的过程模型

2.5.5 演化模型之原型模型（Prototype Model）

原型是预期系统的一个可执行版本，反映了系统性质的一个选定的子集。一个原型不必满足目标软件的所有约束，其目的是能快速、低成本地构建原型。

原型模型的过程：首先需要交流，从客户与开发者会议中识别出他们的需求和目标，其次是快速设计阶段，聚焦在更具有代表性的功能，将有形的设计原型给客户。一个原型出现后，再由客户与开发者反复改进，直至建立完整的新系统。

2.5.6 演化模型之螺旋模型（Spiral Model，风险驱动的过程模型）

螺旋模型是一种演化过程模型，它结合了原型的迭代性质和瀑布模型的系统性和可控性，注重风险控制（里程碑），适合大型项目开发。
螺旋模型两个显著特点：
1. 采用循环的方式逐步加深系统定义和实现的深度
2. 确定一系列里程碑，确保利益相关者都支持可行的和令人满意的系统解决方案
在每一次迭代的过程中，都要考虑风险、标记里程碑
分为几步：
1. 制定计划：确定软件的目标，选定实施方案，明确项目开发的限制条件。
2. 风险分析：分析所需的方案，识别风险，消除风险。
3. 实施工程：实施软件开发，验证阶段性产品。
4. 用户评估：评价开发工作，提出修正建议，建立下一个周期的开发计划。