标签：软件开发 迭代 模型 编程 构件 开发 2.3 软件

2.3现代模型：基于构件的开发模型、统一过程模型、敏捷开发模型

基于构件的开发模型

例如：动态链接库（.dll），浏览器插件

概念

近年来得到广泛应用的软件过程模型。由于采用构件技术和重用技术，它改变了大型软件的开发方式，使得软件开发时考虑的焦点不再是实现，而是集成。通过复用和集成已有的构件来实现软件开发。

构件

就像一个螺丝，是系统中模块化的、可更换的部分，一个相对独立的模块，并且能够被另一个具有相同接口的构件所替换。

功能及特点

构件实现特定的功能，并对实现进行封装，暴露一组接口，外界不需要知道构件内部实现的细节，只需要通过接口访问构件提供的服务。构件的例子很多，如浏览器插件

开发模型

基于构件的开发模型包括 2 部分：系统开发、构件开发与维护。

(1)系统开发

1. 需求分析
2. 构件检索与分析从构件库中选取符合需求的构件
3. 然后基于需求分析和选取的构件进行体系结构设计
4. 在实现阶段复用和集成构件
5. 进行系统测试
6. 系统维护

构件和需求不匹配？

可以有两种选择：

1. 修改构件，但是商用构件通常不能修改。
2. 修改需求，而修改需求可能会导致最终产品和用户要求不完全一致，这时就需要和用户协商。

(2)构件开发与维护

开发新构件或者购买新构件来扩充和维护构件库。

构件开发阶段

四个阶段：

基于构件的开发模型的优缺点

•优点

•软件复用

•降低开发成本和风险，加快开发进度，提高软件质量

缺点

•模型复杂

•商业构件不能修改，会导致修改需求，进而导致系统不能完全符合客户需求

•商业构件通常不能修改，会导致修改需求，也导致了无法完全控制所开发系统的演化

•项目划分的好坏直接影响项目结果的好坏

适用场合

由于采用复用思想，故适用于系统之间有共性的情况。

统一过程模型

完整且完美的软件工程方法，广泛使用，基于面向对象方法学，使用统一建模语言UML（Unified Modeling Language）

描述软件开发过程

——从3个视角：

动态视角：随时间变化的各个阶段，包括初始阶段、精化阶段、构建阶段和产品化阶段，采用迭代方式开发。

静态视角：各个开发阶段所要进行的活动，如业务建模，需求，分析设计，实现，测试等。

实践视角：开发中可采用的良好实践建议，这些实践经过大量实际项目证明，对提高软件开发效率和质量非常有效。

统一过程的模型图

横轴是动态视角，表示软件开发随时间变化的各个阶段。整个过程是迭代的。分成4个连续阶段：

1. 初始阶段：进行项目计划和评估风险；
2. 精化阶段：设计系统的体系结构、制定项目计划、确定资源和需求；
3. 构建阶段：开发出所有组件和应用程序，集成并进行详尽测试；
4. 产品化阶段：将产品移交给用户。

纵轴是静态视角，表示在每个开发阶段所要进行的活动。

1. 初始阶段：进行业务建模和需求
2. 精化阶段：进行分析设计，以及部分实现，
3. 构建阶段：实现和测试
4. 产品化阶段：进行部署
5. 项目管理贯穿整个开发周期。

各过程的工作

初始：项目计划、评估风险；
精化：设计系统的体系结构、制定项目计划、确定资源需求；
构建：开发出所有组件和应用程序，集成并进行详尽测试；
产品化：将产品移交给用户。

统一过程的静态结构

统一过程的动态结构

则是通过对迭代式软件开发过程的周期、阶段、迭代过程以及里程碑等的描述来进行表示。

6个核心工程工作流：

• 业务建模工作流
• 需求工作流
• 分析设计工作流
• 实现工作流
• 测试工作流
• 部署工作流

3个核心支持工作流：

• 项目管理工作流
• 配置与变更管理工作流
• 环境工作流。

适用场景:

大团队、大项目

管理实践

六条最佳实践，从大量实际项目的开发经验中总结而来，对实际开发具有指导意义。

1. 迭代式开发

•需求变更不可避免

•每次迭代产生一个可交付版本，用户反馈，减少风险

•根据客户的轻重缓急来规划增量，先开发和交付优先级最高的增量

2. 管理需求

•采用用例分析来捕获需求，由用例驱动设计和实现

•对需求及其变更进行管理

3. 基于构件体系结构

•采用基于构件的体系结构

•提高软件复用率

4. 可视化建模

•使用统一建模语言（UML）对系统进行可视化建模

5. 验证软件质量

•软件质量评估贯穿整个开发过程的所有活动

•全员参与

6. 控制软件变更

•描述如何控制和跟踪软件的变更

敏捷开发模型

不同点

别具一格：不要求较复杂的结构，不要求规范的开发，不要求完善的文档。

起源

2001年2月，17位编程大师发表敏捷软件开发宣言

宣言

一、个体和交互胜过过程和工具。软件开发时，良好的软件过程和现代的软件开发工具非常重要，但是参与开发的人和他们之间的交互更加重要。如果开发人员能力很弱或者他们之间交流很少，即使有良好的软件过程和现代的开发工具也无济于事。

二、可以工作的软件胜过面面俱到的文档。我们开发的目的是可以工作的软件，而非文档。因此我们的开发的重点应该在软件上，而不是花费大量时间撰写大量文档，但并不是不写文档，文档足够即可。

三、客户合作胜过合同谈判。客户和开发者之间应该建立一种合作关系，共同努力开发出软件产品，而不是合同谈判的双方。这样在出现问题时或者计划发生变化时，才能更好应对实现双赢。

四、响应变化胜过遵循计划。外部环境变化往往导致软件需求等发生变化，则计划需要调整，因此软件开发需要能够快速响应变化，及时抓住市场和机遇。

强调

敏捷开发强调高效工作、快速响应变化，具有敏捷性。

敏捷开发方法

敏捷开发不是一个方法，它还含有许多不同方法。

例如：

• 极限编程，
• 自适应软件开发
• 并列争球法
• 动态系统开发方法
• 水晶法
• 特征驱动开发
• 精益软件开发

敏捷软件开发

是基本原理和开发准则的结合

基本原理强调：

• 客户满意度和较早的软件增量交付，软件开发采用迭代方式，每次迭代产生一个增量，每次交付的周期都很短;
• 团队小但有激情，团队中的每一个人能力都很强，且工作非常有激情，这是保证快速开发的前提；
• 采用非正式的开发方法，以可工作的软件为目标，适当时候进行结构调整和程序优化；
• 每次产生最小的软件工程产品。每次迭代产生的增量都很小，保证每次迭代时间都很短，并且对变化具有敏捷性，能根据变化及时调整；
• 整体开发过程尽量简单化。

开发准则强调：

• 分析和设计的交付
• 开发者和客户之间积极持续的交流，客户会派工作人员到开发组，作为客户代表参与开发，使得交流及时和持续，保证敏捷性。

极限编程为例子为例（eXtreme Programming）

简称XP，意为：“把好的开发实践运用到极致。”

一次迭代的过程

注：

编程之前，需要先写测试用例，再进行编程，以保证开发出的程序能够顺利通过测试。

编程时采用结对编程，即两个人使用同一个工作台进行编程，一个编程一个看，这样能及时发现问题，保证较高程序质量。

开发的程序持续集成到系统中并进行测试，当所有任务完成后发布该版本，然后评估当前版本，进入下一次迭代

极限编程的有效实践

极限编程通过一些有效实践来保证快速敏捷开发。

1. 增量式开发。开发采用迭代方式，每次迭代产生一个增量，这种方式能够使得软件及早进入市场，且能够根据反馈及时调整后续开发；

2. 小版本短周期交付：每次迭代产生的增量都很小，交付的周期也很短；

3. 结对编程

4. 代码集体所有

5. 开发团队在开放的工作空间，便于开发人员之间的交互和交流；

6. 可持续的开发速度：<40小时/周，连续加班不超过两周【会导致效率降低、质量下降】

7. 设计尽量简单

8. 测试驱动开发，即：先写测试用例再编程，以保证开发出的程序能够顺利集成到软件中并通过测试。

9. 持续集成，软件编写完成随即进行集成，集成频率很高，几天甚至每天都会进行集成；

10. 适时进行程序重构和优化，只改变程序内部结构，不改变其行为。由于编写代码较快，采用的结构未必最优

11. 根据每次迭代的情况，及时调整计划

12. 客户派工作人员作为开发团队成员，以便及时明确客户需求和反馈

优点

•快速响应变化和不确定性

•在快速的、可持续的开发速度

•适应商业竞争环境下的有限资源和有限时间

缺点

•测试驱动开发可能导致通过测试但非用户期望

•重构而不降低质量困难

适用场合

适用于需求模糊且经常改变的，能适应商业竞争环境下对项目提出的有限资源和有限开发时间的约束。

标签：软件开发,迭代,模型,编程,构件,开发,2.3,软件
来源： https://www.cnblogs.com/tupo/p/15630923.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。