软件工程与软件过程 第二课提纲

第二课提纲

 

通用过程模型中的基本活动

  • 瀑布模型 (The Waterfall Model): 将基本活动表示为独立的过程阶段，包括需求规格说明、设计、实现、测试和维护。

  • 增量开发 (Incremental Development): 将基本活动交织在一起；系统以一系列“增量”的形式开发，每个增量在前一个版本的基础上增加功能。

  • 集成与配置 (Integration & Configuration): 依赖于可重用组件的可用性；系统开发侧重于在新环境中使用时的配置、组合和集成。

 

    • 软件规格说明 (Software Specification)

    • 软件开发 (Software Development)

    • 软件验证 (Software Validation)

    • 软件演化 (Software Evolution)

 

 

瀑布模型 (The Waterfall Model)

 

  • 需求定义 (Requirements Definition)

  • 系统与软件设计 (System & Software Design)

  • 实现与单元测试 (Implementation & Unit Testing)

  • 集成与系统测试 (Integration & System Testing)

  • 运行与维护 (Operation & Maintenance)

 

瀑布模型的阶段1

需求分析与定义 (Requirement analysis and definition):

  • 收集关于所需功能（例如，软件系统应提供登录功能）和约束（例如，软件系统应使用PostgreSQL作为后端数据库，因为它与组织现有的IT基础设施兼容）的信息。

  • 分析在给定的预算、时间框架、资源、技能和可用技术下，软件系统是否可实现。

  • 创建详细的系统规格说明。

系统与软件设计 (System and Software Design):

  • 将需求分配给硬件或软件系统。

  • 建立一个整体的系统架构（例如，识别和描述组件的接口及其关系等）。

瀑布模型的阶段2

  • 瀑布模型的阶段 (2) (The Stages of the Waterfall Model (2))

  • 实现与单元测试 (Implementation and Unit Testing):

    • 软件设计被实现为一组程序或程序单元。

    • 对程序单元进行测试以满足其规格说明。

  • 集成与系统测试 (Integration and System Testing):

    • 将各个程序单元或程序集成起来，并作为一个完整的系统进行测试。

    • 经过验证和确认的软件系统在测试后交付给用户。

  • 运行与维护 (Operation and Maintenance):

    • 系统被部署并投入实际使用。

    • 软件系统可能会持续更新以修补错误或安全威胁；提高系统的稳定性；或增强系统的功能。

应用 (Applications)

嵌入式系统 (Embedded Systems):

  • 软件需要与硬件系统接口。

  • 通常，硬件是不灵活的；将软件功能的决策推迟到实现阶段通常是不方便的。

关键系统 (Critical Systems):

  • 需要对软件规格说明和设计进行广泛的安全性和保密性分析。

  • 软件规格说明和设计文档必须完整。

  • 与安全相关的问题通常修复成本高昂。

大型软件系统 (Large Software Systems):

  • 多个合作伙伴共同开发软件系统，可能需要完整的规格说明以允许不同子系统的独立开发。

必须应对变化的软件系统 (Software Systems that must cope with changes):

  • 变化在许多软件项目中是不可避免的，瀑布模型的单向过程特性无法有效应对变化

V模型 (The V-Model)

 

  • (图示: V形结构，左侧下降为开发阶段，右侧上升为测试阶段，一一对应)

    • 需求分析 (Requirements Analysis) <=> 验收测试 (Acceptance Testing)

    • 系统设计 (System Design) <=> 系统测试 (System Testing)

    • 架构设计 (Architecture Design) <=> 集成测试 (Integration Testing)

    • 模块设计 (Module Design) <=> 单元测试 (Unit Testing)

    • 实现 (Implementation) (位于V形底部)

  • 优点:

    • 由于模型的刚性，它简单且易于管理。

    • 它鼓励在所有阶段进行验证和确认。

    • 它同等重视开发和测试。

  • 缺点:

    • 不适用于需求有中到高风险变化的情况。

    • 不建议用于长期且复杂的面向对象软件项目。

     

 

 

增量开发 (Incremental Development)

 

 

  • 描述:

    • 从软件系统一部分的简单实现开始。

    • 随着每个增量，产品不断演进，每次都增加增强功能，直到最终版本完成。

    • 代码以较小的片段编写和测试，从而降低了与过程相关的风险。

    • 它允许在开发过程中轻松地包含变更。

  • (图示流程):

    • 需求 (Requirements) -> 初始版本 (Initial version) -> [开发(Development) -> 验证(Validation)] -> 中间版本 (Intermediate versions) (循环) -> 最终版本 (Final version)image-20250501102432746

 

增量开发的优点 (Advantages of Incremental Development)

  • 降低实现需求变更的成本 (Reduced cost for implementing requirements changes):

    • 需要重做的分析和文档量明显少于瀑布模型。

  • 及早获得反馈 (Receiving feedback early):

    • 更容易获得用户对已完成工作的反馈。

    • 用户可以评论软件并提供有用的建议。

  • 早期交付部分可工作的产品 (Early delivery of partially working product):

    • 用户可以开始使用早期发布的软件并从中获益。

    • 增量开发并不意味着每个增量都需要交付给用户。

 

 

增量开发的缺点 (Disadvantages of Incremental Development)

  • 过程不可见 (The process is not visible):

    • 需要定期的可交付成果来衡量进度。

    • 如果增量迭代很短，为系统的每个版本制作文档是不划算的。

  • 系统结构趋于退化 (System structure tends to degrade as new increment are added):

    • 频繁的变更给源代码和项目管理带来额外负担。

    • 这也可能损害软件系统架构，随着更多功能组件添加到系统中，现有架构可能需要相应修改，这可能导致级联效应。因此，经常需要重构。

  • 结论: 增量开发模型可能不适合开发大型、复杂且生命周期长的软件系统项目。

 

重构 (Terminology: Refactoring)

  • 定义 (Opdyke, 1992): “一组程序重组操作（重构），支持面向对象应用框架的设计、演化和重用。”

  • 考虑因素 (Fowler, 2018):

    • “当你必须向程序添加功能，但代码结构不方便时，首先进行重构使其易于添加功能，然后再添加功能。”

    • “重构以小步骤更改程序，因此如果你犯了错误，很容易找到错误所在。”

    • “在开始重构之前，确保你有一套可靠的测试。”

  • 定义 (Fowler, 2018): “对软件内部结构进行的更改，使其更易于理解和修改，而不会改变其可观察的行为。”

 

螺旋模型 (The Spiral Model)

 

  • (图示: 螺旋形状，从中心开始，沿四个象限循环向外扩展)

    • 象限1 (左上): 确定目标、替代方案、约束 (Determine objectives, alternatives, constraints)

    • 象限2 (右上): 评估替代方案，识别、解决风险 (Evaluate alternatives, identify, resolve risks) -> 可能涉及原型 (Prototype)

    • 象限3 (右下): 开发、验证下一级产品 (Develop, verify next-level product)

    • 象限4 (左下): 规划下一阶段 (Plan next phases)

     

  • 阅读材料 (螺旋模型): Boehm, B.W., 1988. A spiral model of software development and enhancement. Computer, 21(5), pp.61-72.

 

原型、概念验证和骨架系统 (Terminologies: Prototype, Proof-of-Concept and Skeleton System)

  • 原型 (Prototype): “系统某个功能子集的临时实现，通常呈现给用户以获取反馈和验证，验证完成后即被丢弃。”

  • 概念验证 (Proof-of-Concept): “一些旨在证明所提议架构中某个风险元素是可行的，并突出任何问题和陷阱的代码。概念验证也是一个临时实现，当其目的达到且所研究的风险被理解后即被讨论（或丢弃）。”

  • 骨架系统 (Skeleton System): “实现系统的主要架构结构，但仅包含系统功能的最小子集。骨架系统会被保留而不是丢弃，并成为构建阶段的基础。”

  • 参考: Rozanski, N. and Woods, E., 2012. Software systems architecture: working with stakeholders using viewpoints and perspectives. Addison-Wesley.

  • 注: 骨架系统有时被称为“演化原型 (evolutionary prototype)”。

  • 视角: 从软件架构的角度来看 (From a Software Architecture Perspective)

 

集成与配置 (Integration and Configuration）

  • 描述:

    • 面向重用的开发过程侧重于重用现有软件。

    • 例如：现有的类、库、模式、设计、独立应用系统、Web服务等。

    • 它依赖于一个可重用软件组件库和一个用于组合这些组件的集成框架。

    • 自2000年以来，在软件系统项目的开发中变得极其流行。

 

 

 

该过程中的阶段 (The Stages in the Process)

  • 需求规格说明 (Requirements Specification):

    • 收集系统的初始需求。

    • 应包括基本需求和系统特性的简要描述。

  • 软件发现与评估 (Software Discovery and Evaluation):

    • 概述软件需求，并搜索提供所需功能的组件和系统。

    • 评估候选组件和系统，看它们是否适合在系统中使用。

  • 需求细化 (Requirements Refinement):

    • 使用有关可重用组件和应用程序的信息来细化或修改需求。

  • 应用系统配置 (Application System Configuration):

    • 如果有现成的（off-the-shelf）应用系统可用，可以配置它来创建新系统，那么应首先考虑。

  • 组件适配与集成 (Component Adaptation and Integration):

    • 如果没有现成的应用系统可用，应考虑使用可用组件和/或开发新组件，然后将它们集成以创建系统。

 

 

优缺点

  •  

  • 优点:

    • 减少需要开发的软件量。

    • 降低成本和风险。

      • 较少的开发活动导致成本降低。

      • 现有组件/应用系统通常被证明是正确、稳定和安全的。

    • 现有组件/应用系统提供良好的应用程序编程接口 (API) 以供集成。

    • 更快地交付软件。

  • 缺点:

    • 需求妥协可能会偏离系统的最初构想。

    • 对系统演化的控制有限。

    • 可重用组件的新版本可能与当前使用的版本不兼容，例如，重构的API、新功能、弃用的函数调用等。

 

 

软件模型的适用性 (Applicability of Software Models)

  • 标题: 软件模型的适用性 (Applicability of Software Models)

  • 引用 (Sommerville, 2016):

    • “没有通用的过程模型适用于所有类型的软件开发。”

    • “正确的过程取决于客户和法规要求、软件将使用的环境以及正在开发的软件类型。”

    • “大多数实际的软件过程都基于一个通用模型，但通常会结合其他模型的特性。”

 

 

尝试通用的过程模型 (An Attempt at A Universal Process Model)

  • Rational Unified Process (RUP) / 统一软件开发过程:

    • 一种在开发组织内分配任务和职责的规范方法。

    • 确保在可预测的时间表和预算内生产出满足用户需求的高质量软件。

  • 来源 (RUP): TP026B, R., 2017. Rational Unified Process. October, zv, 18.

 

 

Rational Unified Process -- 初始阶段 (Inception)

  • 活动:

    • 分析部分用例。

    • 分析关键的非功能性需求（例如，安全性、可靠性、可扩展性等）。

    • 创建商业案例。

    • 准备开发环境。

  • 引用 (Larman, 2012): “初始阶段是最初的短步骤，旨在为项目建立共同的愿景和基本范围。初始阶段的目的不是定义所有需求，或生成可信的估算或项目计划。”

  • 总结: “构想产品范围、愿景和商业案例。”

 

 

Rational Unified Process – 精化阶段 (Elaboration)

  • 活动:

    • 核心的、有风险的软件架构被编程和测试。

    • 大部分需求被发现并稳定下来。

    • 主要风险得到缓解。

    • 它涉及一系列迭代。

      • 建议每次迭代在两到六周之间。

  • 引用 (Larman, 2012): “构建核心架构，解决高风险元素，定义大部分需求，并估算整体进度和资源。”

  • 注: “代码和设计是最终系统的生产质量部分。”

 

 

Rational Unified Process – 构建与移交阶段 (Construction and Transition)

  • 构建阶段 (Construction):

    • 关注系统设计、实现和测试。

    • 开发并集成系统的各个部分。

    • 此阶段完成后，应准备好一个部分可工作的系统及相关文档以交付给用户。

  • 移交阶段 (Transition):

    • 在真实的生产环境中部署系统。

    • 此阶段完成后，软件系统应：

      1. 文档齐全 (well documented)

      2. 正确工作 (working correctly)

      3. 在其运行环境中运行 (running in its operational environment)

  • (图示: RUP的四个阶段及迭代关系)

    • 初始 (Inception) -> 精化 (Elaboration) -> 构建 (Construction) -> 移交 (Transition)

    • 每个阶段包含一次或多次迭代 (Iteration)

  •  

  • 阅读材料 (RUP):

    • Larman, C., 2012. Applying UML and patterns: an introduction to object oriented analysis and design and interactive development. Pearson Education.

    • Kruchten, P., 2004. The rational unified process: an introduction. Addison-Wesley Professional.

posted @ 2025-05-01 10:55  糖子哥  阅读(66)  评论(0)    收藏  举报