过程和生命周期建模 - USTChome.ustc.edu.cn/~xiaoning/se2017/PPT/SE_02_Process...Pfleeger and Atlee, Software Engineering: Theory and Practice 软件工程第2章过程和生命

Pfleeger and Atlee, Software Engineering: Theory and Practice

软件工程

第2章过程和生命周期建模 Shari L. Pfleeger Joanne M. Atlee 4th Edition


软件工程

内容 2.1 过程的含义 2.2 软件过程模型 2.3 过程建模的工具和技术 2.4 实际的过程建模 2.5 信息系统的例子 2.6 实时系统的例子 2.7 本章对你的意义


软件工程

第2章的目标

• 过程的含义 • 软件开发的产品、过程和资源 • 软件开发过程中的若干模型 • 过程建模的工具和技术


软件工程

2.1 过程的含义

• A process: a series of steps involving activities, constrains, and resources that produce an intended ouput of some kind 涉及活动、约束和资源使用的一系列步骤，用于生产某种想要的输出。

• A process involves a set of tools and techniques


软件工程

2.1过程的含义过程具有的特性

• 规定了所有主要的过程活动 • 遵从一组约束(such as schedule)使用资源 • 产生中间结果和最终产品 • 可以由子过程组合(hierarchy or links) • 每个过程活动具有进入和退出标准 • 过程按照顺序组织(so timing is clear) • 每个过程具有指导原则，包括每个活动的目标 • 约束可以应用于activity, resource or product


软件工程

2.1过程的含义过程的重要性

• Impose consistency and structure on a set of activities 将步骤组织起来使人们能生产满足一系列目标和标准的产品

• Guide us to understand, control, examine, and improve the activities 允许我们分析、理解、控制和改进组成过程的活动

• Enable us to capture our experiences and pass them along 获取经验并把经验传授给他人


软件工程

2.2 软件过程模型对过程建模的原因

• To form a common understanding 形成共同理解

• To find inconsistencies, redundancies, omissions 发现不一致、冗余、遗漏

• To find and evaluate appropriate activities for reaching process goals 评估候选活动是否合适

• To tailor a general process for a particular situation in which it will be used 根据具体情况对过程进行裁剪


软件工程

2.2软件过程模型软件生命周期

• 当过程是在构造某些产品时，该过程可以被称为生命周期(software life cycle) – 需求分析 Requirements analysis and definition – 系统设计 System (architecture) design – 程序设计 Program (detailed/procedural) design – 编码 Writing programs (coding/implementation) – 测试 Testing: unit, integration, system – 程序发布 System delivery (deployment) – 维护 Maintenance


软件工程

2.2软件过程模型软件开发过程模型

• 瀑布模型 Waterfall model • V模型 V model • 原型化模型 Prototyping model • 可操作规格说明 Operational specification • 可转换模型 Transformational model • 阶段式开发：增量和迭代

Phased development: increments and iteration

• 螺旋模型 Spiral model • 敏捷方法 Agile methods


软件工程

2.2软件过程模型瀑布模型

• 最早提出的模型之一 • Works for well understood problems with

minimal or no changes in the requirements • Simple and easy to explain to customers • It presents

– a very high-level view of the development process – sequence of process activities

• Each major phase is marked by milestones and deliverables (artifacts)


软件工程

2.2软件过程模型瀑布模型(continued)


软件工程

2.2软件过程模型瀑布模型(continued)

• 该模型中不存在迭代(iteration) • 大部分软件是通过大量的迭代进行开发的


软件工程

2.2软件过程模型补充材料2.1 瀑布模型的缺点

• 没有提供指导，关于如何处理开发过程中产品和活动的变化 (assumes requirements can be frozen)

• 将软件视为一个制造的过程，而不是一个创造的过程(从制造业的角度看待软件开发)

• 缺乏创造最终产品过程中所需要的迭代活动 There is no iterative activities that lead to creating a

final product • Long wait before a final product


软件工程

2.2软件过程模型使用原型化的瀑布模型

• 原型：一个部分开发的产品(partially developed product) • 原型有助于：

– 开发者评价可选的设计策略 (design prototype) – 用户理解新系统是什么样子 (user interface prototype)

• 原型有助于进行确认(validation)和验证(verification)


软件工程

2.2软件过程模型使用原型化的瀑布模型

• Waterfall model with prototyping


软件工程

2.2软件过程模型 V模型

• 瀑布模型的变种 • 使用单元测试来验证过程设计(procedural design) • 使用集成设计来验证结构设计(architectural /

system design) • 使用验收测试来确认需求(requirements) • 在验证和确认过程中发现问题，则在再次执行右边的测试步骤之前，重新执行左边的步骤


软件工程

2.2软件过程模型 V模型


软件工程

2.2软件过程模型原型化模型

• 允许对需求或设计进行反复调查

• 减少开发中的风险和不确定性


软件工程

2.2软件过程模型可操作规格说明

• 在开发的早期检查需求及其隐含的含义

Requirements are executed (examined) and their implication evaluated early in the development process

• 允许把功能和设计合并 Functionality and the

design are allowed to be merged


软件工程

2.2软件过程模型可转换模型

• 更少的主要开发步骤Fewer major development steps • 使用一系列转换把需求规格说明变为一个可交付使用的系

统 – 改变数据表示 Change data representation – 选择算法 Select algorithms – 优化 Optimize – 编译 Compile

• 依赖于形式化 Relies on formalism • 需要形式化描述 (to allow transformations)


软件工程

2.2软件过程模型可转换模型(continued)


软件工程

2.2软件过程模型阶段式开发：增量和迭代

• 更短的循环周期(cycle time) • 系统一部分一部分交付

– 使得在系统其他部分正在开发的同时，用户已经获得部分功能

• 允许两个系统并行运行 – 产品系统the production system (release n): 当前正在使用的 – 开发系统the development system (release n+1): 下一个版本


软件工程



软件工程


• 增量开发(Incremental development): 首先定义一个小的功

能子系统，然后在每个新版本中增加新功能 • 跌代开发(Iterative development): 一开始就提交一个完整的

系统，然后在每个新版本中改变子系统的功能


软件工程


• 需要使用阶段式开发的原因： – 即使还缺少某些功能，在早期的发布中就可开始进行培训 – 可以及早为那些以前从未提供的功能开拓市场 – 经常发布新版本使开发人员能全面、快速修复非预期的问题 – 针对不同的发布版本，开发团队将重点放在不同的专业领域技

术上


软件工程

2.2软件过程模型螺旋模型

• Suggested by Boehm (1988) • 把开发活动和风险管理结合，以将风险减到最小并控制风

险 • 该模型表示为一个螺旋，每个迭代过程包含4个主要活动：

– Plan – Determine goals, alternatives and constraints – Evaluate alternatives and risks – Develop and test


软件工程

2.2软件过程模型螺旋模型


软件工程

2.2软件过程模型敏捷方法

• 强调灵活性在快速且有效地生成软件中所发挥的作用 Emphasis on flexibility in producing software quickly and capably

• 敏捷宣言 – Value individuals and interactions over process and tools – Prefer to invest time in producing working software rather than in

producing comprehensive documentation – Focus on customer collaboration rather than contract negotiation – Concentrate on responding to change rather than on creating a plan

and then following it


软件工程

2.2软件过程模型敏捷方法: 示例

• 极限编程(Extreme programming ,XP) • 水晶法(Crystal): 基于如下理念的一组方法：每一个不同的项目都需要一套不同的策略、约定和方法论

• 并列争球法(Scrum): 30天一次迭代; 多个自组织小组并行; 日常协调会议( “scrum” )

• 自适应软件开发 (ASD)


软件工程

2.2软件过程模型敏捷方法: 极限编程

• 强调敏捷方法的4个特性 – 交流 Communication: 客户和开发人员之间持续地交换看法

– 简单性Simplicity: 选择最简单的设计或者实现来处理客户的需求

– 勇气Courage: 尽早地和经常交付功能的承诺 – 反馈Feedback: 在软件开发过程的各种活动中都包含反馈循环


软件工程

2.2软件过程模型敏捷方法: Twelve Facets of XP

• 规划游戏The planning game (customer defines value)

• 小的发布Small release • 隐喻Metaphor (common vision, common names)

• 简单设计Simple design • 首先编写测试Writing tests first • 重构Refactoring

• 对编程Pair programming • 集体所有权Collective ownership • 持续集成Continuous integration (small increments)

• 可忍受的步伐Sustainable pace (40 hours/week)

• 在现场的客户On-site customer • 代码标准Coding standard


软件工程

2.2软件过程模型补充材料2.2 When Extreme is Too Extreme?

• 许多极限编程的实践是相互依赖的 – 一个被修改，其他的都会受到影响

• 需求被表示为必须被软件生产通过的测试用例 – 系统通过了测试，但不是客户想要的系统

• 关于重构 – 重做一个系统而不降低体系结构的质量是困难的


软件工程

2.2软件过程模型补充材料2.3 Collections of Process Models

• 开发过程是一个问题求解的活动 • Curtis, Krasner, Iscoe (1988) 对17个大型项目进行现场研究，

以确定过程模型中应获取那些问题求解的因素 • 研究结果提出了一个关于软件开发层次的行为模型，作为对

传统模型的补充 • 过程模型应该不仅仅描述为一系列开发任务；也应该描述对

项目内在不确定性和风险有影响的因素 Process model should not only describe series of tasks, but also

should detail factors that contribute to a project's inherent uncertainty and risk


软件工程

• 采用的表示法(Notation)依赖于想要用模型表示的内容

• 两个主要种类 – 静态模型Static model: depicts the process – 动态模型Dynamic model: enacts the process

2.3 过程建模工具和技术


软件工程

• 过程包含7种类型的要素

• 若干模板, 例如制品定义模板

2.3过程建模工具和技术静态建模: Lai 表示法

- 序列 Sequence - 资源 Resource - 策略 Policy

-活动 Activity -过程模型 Process model -控制 Control -组织 Organization


软件工程

Name Car Synopsis This is the artifact that represents a class of cars. Complexity type Composite Data type (car_c, user-defined) Artifact-state list parked ((state_of(car.engine) = off)

(state_of(car.gear) = park) (state_of(car.speed) = stand))

Car is not moving, and engine is not running.

initiated ((state_of(car.engine) = on) (state_of(car.key_hole) = has-key) (state_of(car-driver(car.)) = in-car) (state_of(car.gear) = drive) (state_of(car.speed) = stand))

Car is not moving, but the engine is running

moving ((state_of(car.engine) = on) (state_of(car.keyhole) = has-key) (state_of(car-driver(car.)) = driving) ((state_of(car.gear) = drive) or (state_of(car.gear) = reverse)) ((state_of(car.speed) = stand) or (state_of(car.speed) = slow) or (state_of(car.speed) = medium) or (state_of(car.speed) = high))

Car is moving forward or backward.

Sub-artifact list doors The four doors of a car. engine The engine of a car. keyhole The ignition keyhole of a

car. gear The gear of a car. speed The speed of a car. Relations list car-key This is the relation between a car and a key. car-driver This is the relation between a car and a driver.



软件工程


• 启动汽车的过程


软件工程


• 汽车的转移图


软件工程

• 展示过程的能力：随着活动的发生，可以观察资源和产品发生了什么情况

• 能够模拟过程，进行修改以改进过程 • 示例: 系统动力学方法

2.3过程建模工具和技术动态建模: 系统动力学


软件工程

• Forrester 1950‘s 提出 • Abdel-Hamid 和 Madnick 应用于软件开发 • One way to understand system dynamics is by

exploring how software development process affects productivity 软件开发过程是如何影响生产率的



软件工程


• 图示表示影响生产力的因素

• 箭头表示一个因素中的变化如何影响另一个


软件工程


• A system dynamic model containing four major areas affecting productivity


软件工程

2.3过程建模工具和技术补充材料 2.4 过程程序设计

• 编写程序来描述和演示(describe and enact)整个过程 – 去除不确定性 – 是产生软件的自动化环境的基础

• 没有抓住开发过程内在的变化 – Implementation environment, skill, experience,

understanding the customer needs • 仅提供了关于任务序列化的信息 • 没有就即将到来的问题向管理人员给出警告


软件工程

2.4 实际的过程建模 Marvel 案例研究

• 使用 Marvel process language (MPL) • 3种主要的结构: 类、规则、工程信封(tool envelopes) • 3部分的过程描述

– 基于规则的过程行为规格说明 – 模型信息过程的面向对象定义 – 用作执行该过程的外部软件工具和Marvel之间的接口的一组信封

set of envelopes to interface between Marvel and external software tools


软件工程

2.4实际的过程建模 Marvel 案例研究

• 涉及两个AT&T网络 – 网络处理电话呼叫 – 信令网负责为呼叫安排路由并平衡网络负载

• 使用MSL描述信令故障解析过程


软件工程

2.4实际的过程建模 Marvel 案例研究

• 信令故障解析过程


软件工程

2.4实际的过程建模 Example of Marvel Commands

TICKET:: superclass ENTITY status : (initial, open, referred_out, referral_done,

closed, fixed) = initial; diagnostics : (terminal, non_terminal, none) = none; level : integer; description : text; referred_to : link WORKCENTER; referrals : set_of link TICKET; process : link PROC_INST;end

diagnose [?t: TICKET]: (exists PROC_INST ?p suchthat (linkto [?t.process ?p])) : (and (?t.status = open}(?t.diagnostics = none)) {TICKET_UTIL diagnose ?t.Name} (and (?t.diagnostics = terminal)

(?p.last_task = diagnose)(?p.next_task = refer_to_WC3));

(and (?t.diagnostics = non_terminal)(?p.last_task = diagnose)(?p.next_task = refer_to_WC2));

Classdefinitionfor troubletickets

Rule fordiagnosingticket


软件工程

2.4实际的过程建模过程建模工具和技术应具有的特性

• 促进人们的理解和交流 • 支持过程改进 • 支持过程管理 • 在执行过程时提供自动化的指导 • 支持自动化的过程执行


软件工程

2.5. 信息系统的例子 Piccadilly Television Advertising System

• 需要一个易于维护并易于改变的软件系统 • 需求可能变化

– 瀑布模型不合适 • 用户界面原型是有用的 • 在广告条例和业务约束中有很多不确定因素

– 需要能管理风险 • 螺旋模型是最合适的


软件工程

2.5信息系统的例子 Piccadilly System

• 风险的特性描述为两部分 – 概率(Probability): 某个特定问题发生的可能性 – 严重性(Severity): 对系统造成的影响

• 为了能管理风险，必须在过程模型中引入关于“风险”的特性描述 – 风险是必须描述的东西 Risk is an artifact that needs to be described


软件工程

2.5.信息系统的例子 Lai Artifact Table for Piccadilly System

Name Risk (problemX) Synopsis This is the artifact that represents the risk that problem X

will occur and have a negative affect on some aspect of the development process.

Complexity type Composite Data type (risk_s, user_defined) Artifact-state list low ((state_of(probability.x) = low)

(state_of(severity.x) = small)) Probability of problem is low, severity problem impact is small.

high-medium ((state_of(probability.x) = low) (state_of(severity.x) = large))

Probability of problem is low, severity problem impact is large.

low-medium ((state_of(probability.x) = high) (state_of(severity.x) = small))

Probability of problem is high, severity problem impact is small.

high ((state_of(probability.x) = high) (state_of(severity.x) = large))

Probability of problem is high, severity problem impact is large.

Sub-artifact list probability.x The probability that

problem X will occur. severity.x The severity of the

impact should problem X occur on the project.


软件工程

2.6 实时系统的例子 Ariane-5 Software

• 涉及复用Ariane-4的软件 • 复用过程模型

– 表示出可复用的子过程，对其进行描述，把它们放在库中

– 分析需求和库中可用的复用构件，提出一组修订后的需求

– 基于修订后的需求设计软件 – 对所有的复用构件进行评估，以保证正确性和一致性

– 构建或修改软件


软件工程

2.6实时系统的例子 Ariane-5 Software

• 复用过程模型


软件工程

2.7 本章对你的意义

• 软件开发过程涉及活动、资源和产品

• 过程模型包含了组织的、功能的、行为的和其他侧面 Process model includes organizational, functional, behavioral

and other prespectives • 过程模型有助于指导开发小组行为，协调和合作 A process model is useful for guiding team behavior,

coordination and collaboration

Documents

过程和生命 周期建模 - USTChome.ustc.edu.cn/~xiaoning/se2017/PPT/SE_02_Process...Pfleeger and Atlee, Software Engineering: Theory and Practice 软件工程 第2章 过程和生命

过程和生命周期建模 - USTChome.ustc.edu.cn/~xiaoning/se2017/PPT/SE_02_Process...Pfleeger and Atlee, Software Engineering: Theory and Practice 软件工程第2章过程和生命