系统架构设计师——软件开发方法分类

分类

软件开发方法是指软件开发过程所遵循的办法和步骤，从不同的角度可以对软件开发方法进行不同的分类。

按照开发风范

软件开发过程中，开发方法的选择对项目的成功至关重要。这些方法可按照特定的开发风范分为自顶向下和自底向上两种主要策略，它们分别适应不同的项目需求和开发环境。以下是这两种开发风范的特点和应用场景的详细解析：

自顶向下开发方法

1. 核心思想

   • 该方法将一个大规模的问题分解成多个小问题，并逐个解决。每个小问题由相应的模块负责处理，模块内部进一步细分为抽象步骤和具体步骤[¹]。

2. 适用场景

   • 适用于需求明确、结构清晰的项目。这种方法便于管理者从高层次审视项目全局，逐步细化到具体实现，有利于阶段性的成果展示和评估。

3. 优点

   • 易于规划和分阶段实施，可以系统地管理和控制项目的进展。
   • 由于是从整体到局部的逐步精细化，可以确保各部分之间的良好集成和协同工作。

4. 缺点

   • 在项目初期就需要一个清晰、全面的需求分析和设计，若顶层规划有误，将直接影响到后续所有步骤。
   • 对变更的适应性较差，一旦需要修改核心设计，可能导致大量返工。

自底向上开发方法

1. 核心思想

   • 从系统的基础功能开始，逐步构建起完整的系统。开发者从具体的器件或逻辑部件出发，依靠经验和技能，通过连接和修改这些基础部件来扩展系统的功能和规模[¹]。

2. 适用场景

   • 适合于创新型项目或当完整需求不明确的项目。通过实证的方式逐步完善系统功能，特别有效于技术原型的开发和小步快跑的项目推进。

3. 优点

   • 可以快速启动项目并迅速看到初步成果，有助于及早发现设计和实现中的问题。
   • 高度灵活，对于需求和技术路线不确定的项目，可以边开发边调整方向。

4. 缺点

   • 难以进行大规模和长期的项目规划，可能因缺乏前瞻性设计而导致后期整合困难。
   • 在没有明确目标的情况下可能导致项目方向偏离或功能冗余。

总的来说，在选择适合的软件开发风范时，需要根据项目的具体需求、团队的工作经验和项目的管理方式做出决策。自顶向下的方法提供了一种系统的、分层的解决方案，适合需求明确和风险较低的项目。而自底向上的方法则更加灵活，适合创新性强或需求不断变化的项目。在实际开发中，往往需要根据项目的具体情况灵活运用这两种方法的优势，以期达到最佳的开发效果。

按照性质

软件开发方法根据其性质可以分为形式化方法和非形式化方法，其中非形式化方法包括结构化方法、面向对象方法、原型方法、面向服务的方法、构件化开发方法和敏捷开发方法。这些方法各具特色，适应不同的开发需求和项目环境，下面将具体分析每种方法的核心思想、适用场景、优点以及缺点：

形式化方法

1. 核心思想

   • 基于严密的数学形式机制，通过形式规格说明语言来描述软件系统的需求和设计。这种方法侧重于通过数学验证保证软件系统的正确性。

2. 适用场景

   • 适用于对安全性和可靠性要求极高的系统，如交通控制系统、金融交易系统等。

3. 优点

   • 能够提供无歧义的需求和设计描述，减少误解和错误。
   • 支持系统属性的形式验证，提高软件的可靠性。

4. 缺点

   • 高复杂度和成本，需要专业人员掌握形式方法。
   • 难以适用于需求不断变化或不明确的项目。

非形式化方法

1. 结构化方法

1. 核心思想

   • 采用“自顶向下”的设计途径，强调在开发过程中先定义全局结构，再细化到局部实现。

2. 适用场景

   • 适合于需求相对稳定且清楚的项目开发。

3. 优点

   • 易于理解和实施，有助于保持系统的结构清晰。
   • 便于阶段性成果的评估和管理。

4. 缺点

   • 对需求变化的适应性较差，变更成本高。
     结构化开发方法，作为一种传统的软件开发方法，主要包括结构化分析、结构化设计和结构化程序设计三个部分。这种方法强调开发的规范性和系统性，适用于需求明确和项目规模较大的软件开发。以下是结构化开发方法的具体内容和特点解析：

结构化分析

1. 核心思想

   • 通过使用标准化的工具和技术，如数据流图和结构化英语，来描述软件需求和定义系统功能。
   • 该方法侧重于全面理解用户的需求并将这些需求转化为详细规格说明。

2. 适用场景

   • 适合需求稳定且清晰的项目开发，特别是对数据处理要求高的系统。

3. 优点

   • 有助于清晰并详细地捕获用户需求，减少开发过程中的误解和错误。
   • 提供了一种系统化的需求分析方法，易于项目管理和维护。

4. 缺点

   • 对于需求频繁变动的项目，维护和更新文档可能变得困难和耗时。

结构化设计

1. 核心思想

   • 在结构化分析的基础上，采用“自顶向下”的设计方法将系统分解成若干模块，每个模块解决特定的子问题。
   • 使用结构图和伪代码等工具来定义系统的体系结构和各模块之间的关系。

2. 适用场景

   • 适用于大型项目，尤其是需要高度模块化和集成的项目。

3. 优点

   • 有利于系统的模块化设计，提高系统的可读性和可维护性。
   • 便于阶段性成果的评估和管理。

4. 缺点

   • 设计的初期阶段如果出现问题，可能导致整体结构需要重大调整。

结构化程序设计

1. 核心思想

   • 强调程序的逻辑结构清晰和易理解，通常遵循“自顶向下”的程序设计方法。
   • 强调编码规范和注释的完整性，确保代码的质量和可维护性。

2. 适用场景

   • 适合于任何规模的软件开发，特别是那些对代码质量要求高的项目。

3. 优点

   • 促进高质量代码的编写，增加代码的可读性和可维护性。
   • 有助于错误的快速识别和修复。

4. 缺点

   • 对开发者的编程技能要求较高，需严格遵守编码规范。

2. 面向对象方法

1. 核心思想

   • 基于类和对象的概念，强调封装、继承和多态，尝试模拟现实世界的行为。

2. 适用场景

   • 适合大型复杂系统，尤其是需求频繁变更的项目。

3. 优点

   • 提高软件复用性和可维护性，更符合现代软件的开发需求。
   • 更贴近人类对现实世界的认知，便于理解和交流。

4. 缺点

   • 设计阶段较为复杂，对开发者的OO理解有一定要求。

面向对象分析（OOA）、面向对象设计（OOD）和面向对象程序设计（OOP）是面向对象开发的核心组成部分，它们共同支持软件的开发过程。这些方法强调使用对象和类的概念来模拟现实世界的实体，从而提高软件的可理解性、可维护性和可重用性。以下是对这些方法以及相关方法的具体分析：

Coad/Yourdon方法

1. 核心思想：

   • 这种方法特别强调在OOA和OOD之间保持完全一致的概念和表示法，从而减少从分析到设计阶段的转换误差。
   • 该方法侧重于建模对象的类层次结构，定义对象间的消息传递以及识别继承关系。

2. 适用场景：

   • 适合于业务逻辑复杂、数据结构稳定且需要高度模块化的软件项目。

3. 优点：

   • 通过统一的表示法简化了分析和设计过程，易于理解和实施。
   • 增强了系统的适应性和维护性，因为系统的结构更加清晰。

4. 缺点：

   • 对于非面向对象的开发者来说，学习和适应可能需要较长时间。

Booch方法

1. 核心思想：

   • Booch方法强调静态模型和动态模型的使用，其中静态模型包括类图和对象图，而动态模型则包括状态图和顺序图。
   • 这种方法不仅关注系统的结构和组成，还关注对象的行为和交互。

2. 适用场景：

   • 适合对系统行为和交互要求较高的软件开发项目。

3. 优点：

   • 提供了全面的视图，帮助开发者更好地理解系统的整体功能和行为。
   • 促进了高质量的设计和代码实现。

4. 缺点：

   • 方法的学习曲线可能较陡峭，特别是对于那些不熟悉面向对象分析与设计的团队。

OMT方法

1. 核心思想：

   • OMT使用了三种模型：对象模型、动态模型和功能模型，以支持软件开发的全面需求。
   • 特别注重系统的功能需求，使用数据流图（DFD）来描述。

2. 适用场景：

   • 适用于需要精确描述系统功能和数据流的项目。

3. 优点：

   • 提供了一个从不同角度审视系统的框架，增加了分析和设计的深度。
   • 有助于揭示系统中的复杂数据关系和处理流程。

4. 缺点：

   • 可能会增加分析和设计的复杂度，特别是在数据和功能模型较为复杂时。

OOSE

1. 核心思想：

   • 使用用例代替传统的数据流图来进行需求分析，强调从用户视角出发的需求定义。
   • 支持整个开发过程中的一致性和连贯性。

2. 适用场景：

   • 特别适合那些需求频繁变更和需要紧密用户参与的项目。

3. 优点：

   • 加强了与用户的沟通，确保开发的产品更贴近用户需求。
   • 提高了开发过程的灵活性和迭代效率。

4. 缺点：

   • 需要较高的用户参与度和良好的沟通机制，否则可能导致需求不稳定和项目延期。

3. 原型方法

1. 核心思想

   • 通过构建可运行的模型（原型）来获取用户反馈，逐步完善需求和设计。

2. 适用场景

   • 特别适合需求不明确或需快速验证的项目。

3. 优点

   • 可以快速验证和调整需求，降低风险。
   • 用户参与度高，有助于提升用户满意度。

4. 缺点

   • 若管理不当，可能导致项目目标偏移或无法按时完成。

4. 面向服务的方法

1. 核心思想

   • 以服务为核心构建软件，每个服务独立提供业务功能，通过标准接口与其他服务交互。

2. 适用场景

   • 适合需要高度可扩展性和平台无关性的分布式系统。

3. 优点

   • 支持模块化开发和服务重用，提高系统的灵活性和可维护性。
   • 易于集成和扩展，适应快速变化的业务需求。

4. 缺点

   • 设计和实现难度较大，需要良好的SOA架构设计。

5. 构件化开发方法

1. 核心思想

   • 使用预制的高复用代码组件进行软件开发，提高开发效率和质量。

2. 适用场景

   • 适合有大量标准功能模块可复用的项目。

3. 优点

   • 显著缩短开发时间，降低成本。
   • 提高软件的可靠性和可维护性。

4. 缺点

   • 需要丰富的组件库支持，且对组件的管理要求较高。

6. 敏捷开发方法

1. 核心思想

   • 强调人的交互、产品的逐步完善、客户合作以及对变化的快速响应。

2. 适用场景

   • 特别适合需求快速变化和项目周期短的开发环境。

3. 优点

   • 灵活性高，能快速响应需求变化。
   • 持续交付，确保项目始终在正确的轨道上前进。

4. 缺点

   • 需要团队成员具有高度的自我管理和协作能力。
   • 可能不适合那些需求稳定且明确的项目。

综上所述，软件开发方法的选择应考虑项目的具体需求、团队的技能和项目所处的环境。在实际开发中，往往需要根据项目的具体情况灵活运用各种方法的优势，以达到最佳的开发效果。

适用范围

整体性方法通常适合于项目需求明确、变更较少的情况，而局部性方法则更适应于需求频繁变动或不确定性较高的项目。以下是详细说明：

1. 整体性方法的适用范围：

   • 结构化方法强调了整体性和全局性，适合那些需求较为稳定和明确的项目。
   • 瀑布模型适合于需求确定、工作环境稳定、对目标和环境很熟悉的低风险项目。
   • V模型适用于对软件质量有严格要求的项目，它不利于需求变化的适应。

2. 局部性方法的适用范围：

   • 快速原型模型适用于对所开发领域比较熟悉且有快速原型开发工具的项目；在产品移植或升级时也非常适合。
   • 增量模型适用于已有产品升级或新版本开发，以及完成期限严格要求的产品。
   • 螺旋模型适合于大规模软件项目，尤其是需要风险管理和客户持续参与的项目。
   • 敏捷开发，如Scrum模型和极限编程，适合于需求频繁变化、迭代周期短的项目，需要经验丰富的开发者和良好的团队协作。

针对整体性方法和局部性方法的选择，考虑以下因素：

• 项目的复杂度和规模
• 团队的技能和经验
• 需求的变动频率
• 风险管理的必要性