第二章软件过程分解Word文档下载推荐.docx

第二章软件过程分解Word文档下载推荐.docx

《第二章软件过程分解Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《第二章软件过程分解Word文档下载推荐.docx（17页珍藏版）》请在冰豆网上搜索。

软件开发过程的作用是：

（1）成为开发组活动顺序的向导。

（2）详细说明需要开发哪些制品，何时开发。

（3）指导每一个成员及整个开发组的工作。

（4）提供监控、度量产品和活动所依据的准则。

—软件过程是软件项目管理控制的基础，它为项目提供稳定性、可控性和有组织性，能有效避免混乱。

—若没有一个良好定义的过程，开发组将各行其是，成功与否完全依赖个别优秀的人才，这不是能够长久的。

四、软件过程的组成要素（活动、动作、任务）

软件过程是工作产品构建时所执行的一系列活动、动作和任务的集合。

（1）活动（activity）：

实现宽泛的大目标。

（2）动作（action）：

阶段目标。

（3）任务（task）：

关注小而明确的目标，产生实际产品。

—软件过程由活动组成，活动由动作组成，动作由任务组成。

五、基本框架活动和典型的普适性活动

软件过程框架（processframework）定义了若干个框架活动，及一些适用于整个软件过程的普适性活动

1.基本框架活动

一个通用的软件工程过程框架通常会包含以下5个基本的框架活动：

（1）沟通：

在技术工作开始前，先和利益相关者进行沟通与协作，以理解项目目标，并收集需求。

（2）策划：

制定项目计划，包括需要执行的技术任务、可能的风险、资源需求、工作产品、工作进度计划等。

（1）建模：

构思软件的体系结构、构件如何结合等。

（4）构建：

包括编码和测试。

（5）部署：

交付全部软件或部分增量，由用户使用并反馈意见。

2.典型的普适性活动

在软件过程中，还需要补充一些贯穿始终的普适性活动，可帮助团队管理和控制进度、质量、变更和风险。

（1）软件项目跟踪与控制：

根据计划评估当前进度，并采取必要的措施保证项目按进度计划进行。

（2）风险管理：

对可能影响项目成果或质量的风险进行评估。

（3）软件质量保证

（4）技术评审：

评估软件工程的产品，尽量在错误传播到下一个活动之前发现并清除错误。

（5）测量：

定义和收集过程、项目和产品的度量。

（6）软件配置管理：

管理变更所带来的影响。

（6）可复用管理：

定义产品复用标准，建立构件复用机制。

（7）工作产品的准备和生产

六、过程流

过程流（processflow）：

描述了在执行顺序和执行时间上，如何组织框架中的活动、动作和任务。

有以下4类：

七、通用过程模型

—软件过程常使用“过程模型”来表述。

一个通用的软件过程模型，包括以下工作：

（1）选择一种过程流。

（2）定义框架活动：

针对给定的问题、开发人员和利益相关者，制定每个框架活动中需要完成哪些动作。

（例如在沟通活动中，可能包括启动、需求获取、需求系统、谈判、规格说明、确认等动作。

）

（1）明确任务集：

为每个动作制定所需要的任务集。

—任务集由工作任务、相关工作产品、质量保证点和项目里程碑等部分组成。

—对于不同的软件项目，即便是相同的动作，确定的任务集也可能不一样。

（4）编写或查找过程模式。

八、过程模式

1.过程模式的定义

—开发团队在软件过程里会遇到很多问题，如果团队能得到已有的经过验证的解决方案，将有助于快速地分析和解决问题。

因此在软件过程中，最好能将遇到的过程问题、问题环境、解决方案等记录下来，形成过程模式（processpattern）。

—过程模式提供了一个模板，一种在软件过程的背景下，统一描述问题解决方案的方法。

—可以在不同抽象层次上定义模式，比如针对整个过程的、针对框架活动的、针对动作

的、针对任务的等。

例子：

—模式名称：

需求不清

—目的：

该模式描述了一种构建模型（或原型系统）的方法可以反复评估，以便识别和确定软件需求。

—类型:

阶段模式。

—启动条件：

①确定利益相关者；

②已经建立起利益相关者和间的沟通方式；

③利益相关者确定了需要解决的主要问题基本业务需求和项目约束条件有了初步了解。

—问题：

需求模糊或者不存在，但都清楚地认识到项目存在要通过软件解决。

利益相关者不确认他们想要什么；

即他件需求。

—解决办法：

描述了原型开发过程。

—结束条件：

开发了软件原型，识别了基本的需求（例如，征、处理功能等），并获得了利益相关者的认可。

随后，

①原型系统可以通过一系列的增量开发，演化成为软件产统被抛弃，采用其他过程模式建立产品软件。

—相关的模式：

客户沟通、迭代设计、迭代开发、客户评价

九、过程模型

1.通用过程模型

软件过程常使用“过程模型”来表述。

—一个通用的软件过程模型，包括以下工作：

（1）定义框架活动：

针对给定的问题、开发人员和利益相关者，制定每个框架活动中需要完成哪些动作。

（例如在沟通活动中，可能包括启动、需求获取、需求系统、

谈判、规格说明、确认等动作。

（3）明确任务集：

2.过程模型的选择要点

（1）无论要开发软件的大小，都应选择一个合适的软件过程模型。

（2）选择何种软件过程模型，依赖于项目的性质、所构造软件的特点、采用的方法、需要的控制，以及项目团队，不同类型的软件或系统可能需要采用完全不同的软件过程。

（3）软件过程不是教条，它不是对如何构建软件的严格规定，而应是一种可适应性调整的方法，要让软件过程适合于项目团队和要开发的产品。

十、惯用过程模型（传统过程模型）

1.惯用过程模型的含义

—软件工程发展到现在，已经出现了很多不同的过程模型，其中有一些可归属为“传统过程模型”。

—传统过程模型以秩序和一致性作为主要问题，规定了一整套的过程元素，包括：

过程流、框架活动、软件工程动作、任务、工作产品、质量保证、变更控制机制等。

—常见的几种传统过程模型：

瀑布模型、V模型、增量过程模型、原型开发模型、螺旋模型、协同模型。

2.瀑布模型

（1）概念：

瀑布模型（waterfallmodel）是软件工程最早的范例，也称经典生命周期，它提出了一个系统的、顺序的软件开发方法，从用户需求规格说明开始，通过计划、建模、构建和部署的过程，最终提供一个完整的软件并提供持续的技术支持。

（2）特点

—在瀑布模型中，相邻二阶段之间存在因果关系，上一阶段的结果是下一阶段的输入。

—瀑布模型推迟了软件实现，强调在软件实现前必须进行分析和设计工作。

—瀑布模型非常规范：

1.强迫开发人员采用规范的技术方法；

2.严格规定每个阶段必须提交的文档（这些文档往往成为该阶段的里程碑）—“由文档驱动”3.每个阶段结束前必须进行正式的、严格的技术审查和管理复审。

—在实际应用时，往往会添加上“反馈”机制。

（3）V模型：

V模型是瀑布模型的一个变体，它的过程流和瀑布模型一致，但V模型描述了质量保证动作同沟通、建模相关动作以及早期构建相关的动作之间的关系。

（4）W模型

（5）评价

适用条件：

需求明确而稳定，如

—对已有系统仅做适应性调整或增强性工作。

—需求明确的新系统。

优点：

—具有系统性、可控性，克服了软件开发的随意性。

—以阶段评审和文档控制为手段，能及时发现并纠正缺陷。

问题：

—实际项目很少按照该模型给出的顺序进行。

—客户常常难以清楚地给出需求，模型缺乏灵活性。

—客户须要有耐心，只有在项目接近尾声时才能得到可执行程序。

—若在可执行程序评审之前没有发现系统中存在的重大缺陷，将可能造成惨重损失。

—线性流程，开发人员常需要等待，造成“阻塞状态”。

—若每个阶段规定了过多的文档，会极大地增加工作量。

—若管理人员以文档的完成情况来评估项目完成进度，往往会产生错误的结论。

3.增量模型

（1）该模型先对系统最核心或最清晰的需求进行分析、设计、实现、测试，再按优先级逐步对后续需求进行上述工作，并集成到系统中，逐步形成一个完整系统。

（2）增量模型的特点

—增量过程模型综合了线性、并行、演化三种过程流的特征。

—对于每个增量，使用的是线性过程流；

—增量之间有并行；

—整个过程类似于演化，本质上也是迭代的。

—每一个增量都应提交一个可以运行的产品。

—每次增量得到的产品要交由客户使用或仔细评价，并根据使用或评价的结果制定下一个增量计划。

—每次增量需求的划分与增量实现的集成是以不影响系统体系结构为前提的。

（3）评价

—适用于人手不足的情况：

早期的增量可以由少量人员实现，若核心产品的口碑不错，则再投入更多人力。

—客户的需求可以逐步提出来。

—能在较短时间内提交可运行产品，增强了客户的信心。

—可以规避技术风险：

例如，系统需要利用某个正在开发的新硬件，则可以在早期的增量中避免使用这个硬件，以保证部分功能按时交付，不至于造成过分的延期。

缺点：

—增量粒度难以选择；

—确定所有的基本业务服务比较困难。

4.原型开发

原型：

模拟某种产品的原始模型（“样机”）。

—在获得一组基本需求后，可以先通过快速地分析和设计，构造出一个小型的软件系统原型。

用户使用原型系统，开发人员根据用户反馈修改或重建系统。

（2）原型开发的目的

（3）原型开发的特点

—原型系统应仅包括主要功能及重要接口，不包括系统的细节（如异常处理等）。

—原型系统强调“快速”，不宜釆用过多的新技术。

—原型提供了用户与开发人员良好的沟通手段：

批评指责一个已有的事物，要比空洞地描述自己的设想容易得多。

—原型系统是临时系统，通常应该被丢弃，但有时也可以将其演化成实际系统（实际系统以质量为纲）。

—原型的若干高质量的程序片段和开发工具可用于实际系统的开发。

—原型可作为一种技术，用于其它过程模型中。

（4）评价

—用户能亲身感受到实际系统，很直观。

—开发者使用成熟技术，能很快建造出一些东西。

—原型是粗糙的，没考虑软件总体质量和长期的可维护性。

—开发者常要在实现上进行折衷以使得原型能尽快工作，如不合适的语言、低效的算法等。

—文档容易被忽略。

—建立原型的许多工作会被浪费掉。

—对于大型的或流程复杂的系统，不经系统分析而直接用原型

来模拟是很困难的。

—对于大量运算的、逻辑性较强的程序模块，很难构造原型。

5.螺旋模型

螺旋模型结合了原型的迭代性质和瀑布模型的系统性和可控性特点，能快速开发软件的增量版本。

（2）螺旋模型的特点

—螺旋模型要求在所有阶段始终进行风险分析