构建软件开发方法 第1篇
团队在添加新功能时使用敏捷开发方法来最大限度地降低风险（例如错误、成本超支和需求变化）。在所有敏捷方法中，团队都会以迭代方式开发软件，其中包含新功能的小增量。敏捷开发方法有多种不同形式，包括 Scrum、Crystal、极限编程 (XP) 和功能驱动开发 (FDD)。
优点： 敏捷软件开发的主要好处是它允许软件迭代发布。迭代版本允许团队尽早发现和修复缺陷并调整期望，从而提高效率。它们还允许用户通过频繁的渐进式改进更早地实现软件优势。
缺点： 敏捷开发方法依赖于实时通信，因此新用户通常缺乏加快速度所需的文档。它们需要用户投入大量的时间，并且是劳动密集型的，因为开发人员必须在每次迭代中完全完成每个功能以获得用户批准。
敏捷开发方法类似于快速应用程序开发（见下文），并且在大型组织中可能效率低下。习惯于瀑布方法（见下文）的程序员、经理和组织可能难以适应 敏捷的 SDLC。因此，混合方法通常对他们很有效。
构建软件开发方法 第2篇
传统的软件开发过程可以划分为从概念直到实现的若干个阶段，包括问题定义、 需求分析、软件设计、软件实现及软件测试等。如果采用传统的软件开发模型，软件架构的建立应位于需求分析之后， 概要设计之前。
传统软件开发模型存在开发效率不高，不能很好地支持软件重用等缺点。
也就是说ABSD可以很好的支持软件重用。ABSD通过模块化设计、标准化接口、组件库和框架、领域模型和领域驱动设计、版本管理和文档等多个方面，支持软件重用。
ABSD模型把整个基于架构的软件过程划分为架构需求、设计、文档化、复审、实现和演化6个子过程，
架构文档化过程的主要输出结果是两个文档：架构规格说明和测试架构需求的质量设计说明书。
软件架构的文档要求与软件开发项目中的其他文档是类似的。文档的完整性和质量是软件架构成功的关键因素。
三大注意事项：
✅ 文档要从使用者的角度进行编写
✅ 必须分发给所有与系统有 关的开发人员
✅ 且必须保证开发者手上的文档是最新的
在一个主版本的软件架构分析之后，要安排一次由外部人员(用户代表和领域专家)参加 的复审。
复审的目的是标识潜在的风险，及早发现架构设计中的缺陷和错误
包括架构能否满足需求、质量需求是否在设计中得到体现、层次是否清晰、构件的划分是否合理、文档表 达是否明确、构件的设计是否满足功能与性能的要求等。
构建软件开发方法 第3篇
DevOps 不仅仅是一种开发方法，也是一套支持组织文化的实践。 DevOps 部署以组织变革为中心，增强负责开发生命周期不同部分（例如开发、质量保证和运营）的部门之间的协作。
优点： DevOps 专注于缩短上市时间、降低新版本的失败率、缩短修复之间的准备时间，并在最大限度地提高可靠性的同时最大限度地减少中断。为了实现这一目标，DevOps 组织的目标是自动化 持续部署 ，以确保一切顺利、可靠地发生。使用 DevOps 方法的公司可以通过显着缩短上市时间并提高客户满意度、产品质量以及员工生产力和效率而受益。
缺点： 即使考虑到 DevOps 的优点，它也有一些缺点：
有些客户不希望他们的系统持续更新。 一些行业的法规要求在项目进入运营阶段之前进行广泛的测试。 如果不同的部门使用不同的环境，未检测到的问题可能会溜进生产中。 某些质量属性需要人工交互，这会减慢交付流程。
构建软件开发方法 第4篇
基于架构的软件设计（Architecture-Based Software Design, ABSD）方法。ABSD方法是由架构驱动的，即指由构成架构的业务（商业）、质量和功能需求的组合驱动的。
三大基础：
功能的分解，ABSD方法使用已有的基于模块的内聚和耦合技术。
选择架构风格来实现质量和业务需求。
软件模板的使用，软件模板利用了一些软件系统的结构。
构建软件开发方法 第5篇
快速应用程序开发（RAD）是一个浓缩的开发过程，可以以较低的投资成本生成高质量的系统。 这个 RAD 流程使我们的开发人员能够快速适应快节奏且不断变化的市场中不断变化的需求。快速调整的能力使得投资成本如此之低。
应用快速开发方法分为需求规划、用户设计、构建、割接四个阶段。重复用户设计和构造阶段，直到用户确认产品满足所有要求。
优点： 快速应用程序开发对于具有明确定义的业务目标和明确定义的用户组但计算并不复杂的项目来说是最有效的。 RAD 对于时间敏感的中小型项目特别有用。
缺点： 快速应用程序开发需要稳定的团队组成，其中包括对应用程序领域有深入了解的高技能开发人员和用户。在每个施工阶段后都需要批准的压缩开发时间表中，深入的知识至关重要。不满足这些要求的组织不太可能从 RAD 中受益。
构建软件开发方法 第6篇
ABSD 方法是一个自顶向下，递归细化的方法，软件系统的架构通过该方法得到细化， 直到能产生软件构件和类。
ABSD方法中使用的设计元素如下图所示。在最顶层，系统被分解为若干概念子系统和一 个或若干个软件模板。在第2层，概念子系统又被分解成概念构件和一个或若干个附加软件模板。
从不同的视角来检查，会有不同视图。这样做可以帮助软件设计师全面考虑架构的各种属性，确保设计的完整性和合理性。以下是几种常见的视角及其作用的总结：
静态视角（逻辑视图）：关注系统的功能组织，记录设计元素的功能和概念接口，帮助理解系统内部各组件的功能和职责。
动态视角（进程视图）：关注系统的并发行为，描述系统的运行时行为，帮助评估系统的性能和可靠性。
实现视角（实现视图）：关注系统的实现细节，描述源代码的组织和模块间的依赖关系，帮助开发人员进行代码管理和维护。
配置视角（部署视图）：关注系统的物理部署结构，描述系统的节点和网络连接，帮助系统管理员进行高效的系统管理和运维。
通过这些不同的视角，软件设计师可以全面考虑和评估架构的各个方面，确保设计的合理性和有效性。
用例：用于捕获系统的功能需求，描述用户与系统的交互，确保系统能够提供预期的功能。
质量场景：用于捕获系统的质量需求，包括变更、性能、可靠性和交互性等方面。通过定义预期和非预期场景，帮助评估系统在不同条件下的表现，确保设计的鲁棒性和适应性。
例如，一个预期的性能场景是估计每年用户数量增加10%的影响，一个非预期的场景是估计每年用户数量增加100%的影响。虽然非预期场景可能不会真正实现，但它们在确定设计的边界条件时非常有用。