敏捷软件过程 - pudn.comread.pudn.com/downloads6/ebook/17821/agile.pdfFDD...
45
Transcript of 敏捷软件过程 - pudn.comread.pudn.com/downloads6/ebook/17821/agile.pdfFDD...
2
Software Engineering
软件工程
方法Methodology
过程Process
工具Tool
解决软件问题和软件危机的金三角
3
4
Evolutionary Software Process Model
5
Unified Process
6
CMM
7
What is Process
软件过程是指软件生存周期中用于开发和维护软件和相关产品所采用的活动一系列相关过程，这些过程的执行可以是有序的、重复的、并行的、嵌套的，也可以是有条件地引发。
8
软件过程的生命周期过程建模 Process Modeling
过程建模语言 过程模型
过程分析与优化 Process Analysis and Optimization静态分析、动态模拟、设计和重组、优化
过程运作 Process Enactment强制方式和指导方式
度量 Measurement质量、生产率、敏捷性等指标，定量控制
过 程 改 进 和 评 估 Process Improvement and Assessment
ISO9001, CMM/TSP/PSP, SPICE, Six Sigma
9
过程定义和演化
过程实例化
定义的过程
过程分析和优化
过程实例
过程实施和监控 优化的过程实例
业务度量
过程范式和构件变更请求
少量调整
变更请求
过程数据
范式或构件
特定过程需求
高层次的需求
过程经验
10
软件开发新格局
全球化
个性化
快速化
高质量
11
敏捷性需求
快速适应系统需求的变化
提高软件生产率
突出企业自身特点，体现企业核心能力支持动态联盟和虚拟组织
面向业务目标持续改进和重组
12
敏捷软件过程的特性
轻载
基于时间
Just Enough
并行
基于组件的软件工程
13
轻载软件过程Light Weight Software Process
VS. ISO9001和CMM软件的需求是难以预期的，开发方法必需适应变化的需求，在快速的迭代中不断改进
小组成员并不完全按照完整的方法进行开发，而根据具体问题和情况，灵活地去除非增值活动
仅仅执行一些必须的活动，使用必须的规则，编写必须的文档
人的因素被放在第一
适合互联网时代的开发要求
14
主要的轻载过程
eXtreme Programming (XP)SCRUMDSDMAdaptive Software Development (ASD)Feature Driven Development (FDD)Crystal FamilyRational RUP & UML方法的适当选择
15
eXtreme Programming(XP)Kent Beck 提出
采用整体价值驱动，四个关键价值： 通信、简化、反
馈、勇气
用户参与 Pair Programming 集体拥有
短周期 简单设计策略 不需要长期计划和复杂模型
迭代增量开发 反馈修正 反复测试（全过程）
必要时，敢于推倒重来，接受变化
适用不超过10人的开发场合，希望同地开发，能有测
试支持
16
SCRUM 开发过程
Easel 公司发明，旨在寻求生产率突破 名称来自英式橄榄球，每个成员都明确自己角色，环绕同一目标，集体行动、奋力拼搏公认的高生产率方法（6倍！） 数十家公司、数百项目中应用 被 PloP作为组织模式标准三个阶段：定义的初始过程 定义要求目标 任务排序和分配 最优设计经验性的开发过程（Sprint 阶段） 一连串联1-6周的短周期冲刺 目标限定明确 （可演示） 集中精力最佳实现 可多个开发组（4-7人） 每天日常会议 15-30分钟 回答三个问题定义的结束过程 集成、系统测试、文档
17
动态系统开发方法 DSDM源自英国， 是工业联盟，会员超出1000家，已走向世界，应用范围和技术支持由于其它
迭代的快速应用开发方法，适合时间要求紧的项目
5个交织阶段： 可行性研究、商务研究、功能模型迭代、设计与构造迭代、实施
基本原则： 积极的用户参与（用户大使）、赋予开发组决策权、强调经常性产品提交（从基于活动到基于产品）、以业务目标判定提交物质量、迭代和增量式的开发、开发中所有变化能回朔、测试集成于整个开发周期、强调各方合作
与传统方法相反，时间固定、需求可变时间箱（Timebox)方法 一系列2-6周固定时间箱突出需求重点 20%时间做80%有用功能
18
Adaptive Software Development由Jim Highsmith 总结传统方法缺点后提出适合高压力、时间紧、极度变化和不肯定性强、难以计划和控制的项目
基于混沌理论的自适应系统方法，强调适应而不是优化，不追随严格步骤，用结果驱动取代过程驱动
核心为三个非线性重叠阶段：Speculation, Collaboration, Learning了解变化难以预料，自适应的周期计划、组件式、迭代交变
通过合作应付不肯定性，鼓励相互通信、创造性解决问题
学习不知道的东西，适应变化
足够好的质量目标 更柔性的开发方法
19
Feature Driven DevelopmentFDD 是一种模型驱动、短迭代开发过程建模开始 一连串两周为期“按特点设计、按特点构造”的迭代过程 特点：小、用户有用的5 个过程活动：发展总体模型 领域成员参与者主结构师指导
构造特点表按特点计划按特点设计按特点构造可按特点跟踪 具有良好可视性和精度FDD 可用于 16-20人场合 有合适主程序员也可扩大
20
Crystal 方法族
IBM Alistair Cockburn 提出，汇总其他项目成功经验
强调一族 不同项目需要不同方法
两个主要变数： 项目组人数和可靠性要求
注重人性，考虑开发者不易遵循严格方法，强调不很严格但仍能保证成功和容易执行的方法
Crystal 可以说是最轻的一类方法
但不惜对迭代过程后期评审加载，以及早发现问题和及时纠正，强调对过程的监控，使开发过程就是专为您设计的
21
Rational RUP and UML
由于 RUP 的开放性，既可用于重载，也可用于轻载方法
专家推荐将 RUP/XML 用于轻载方法因为两者都源于己于人 OO 技术
如用 XML 作迭代开发阶段的概要设计工具，交换设计概念
Robert Martin 提出的 dX Process 企图把 RUP 和 XP 结合起来
22
轻载方法的选用原则
开发规模小于 50人的场合
需求不肯定或变化大大场合
有责任心和积极性的开发人员
客户理解和能参与的场合
当项目规模大、要求苛刻和固定、开发人员素质无保障又缺乏动力的场合，建议仍采用可预期和重载过程
10人左右项目推荐采用 XP， 50人左右可考虑Crystal
23
基于时间的过程Time-based Software Development
VS. 基于规模的软件过程
Just-In-Time Software Development
一个复杂的项目可被分为多个迭代和多次发放
每一次迭代有固定的时间限制
需求在迭代开始时被确定，直至下一次迭代开始前才能再次修改。
24
Just Enough 过程
结合企业业务，开发自已的软件过程
着重领会CMM等过程模型的精神实质和基本原理，而不是简单地生搬硬套，必须根据自己的实际情况，建立适合自己的过程
过程的多样性
探索可满足 CMM KPAs 的 小关键实践集合。
25
并行软件工程Concurrent Software Engineering
借鉴1988年制造业提出的并行工程思想
活动的并行化。站在软件开发全过程的高度，打破传统的各阶段分割封闭的观念，强调开发人员团队协同，注重分析和设计等前段开发工作，避免不必要的返工。
全球软件开发（Global Software Development）。全球软件开发利用全球广阔的人才资源和时区差异，实现24小时不间断开发，和大规模的并行软件工程。
26
基于构件的软件工程Component Based Software Engineering
软件模块被抽象和封装为可复用的构件。整个系统就是一组相互连接的构件，构件间仅通过接口发生关系。
软件开发将不再一切从头开发，开发的过程就构件的组装过程，维护的过程就是构件升级、替换和扩充的过程。
如何选择合适的构件和组建系统将是开发的重要考虑
软件设计将更面向范式Pattern和框架 FrameworkCorba、DCOM、Web Service标准
提高可靠性、可维护性、可扩展性和可重构性
大幅度缩短了软件开发和维护的周期，为软件生产的工业化提供了可能性
27
敏捷软件过程的过程模型
过程模型 =
功能模型 + 合作模型 + 资源模型 + 产品模型
刻划软件过程的基本元素
增加对敏捷性的支持
28
敏捷软件过程的定义
P = ( As, C1, C2, IO, Rs, Ls, Ms)，软件过程={活动，前置条件，后置条件，产品，
资源，地点，过程目标和度量指标}
活动
前置条件
后置条件
输入产品 输出产品
资源
度量指标
地点
29
敏捷性度量指标
时间
生产率
健壮性
自适应和改善能力
30
敏捷软件过程的一个典型运行
当一个过程的前置条件满足时，过程主体就可以启动这一过程，产生该过程的一个实例，开始执行过程逻辑，在指定的环境中利用支持技术将输入转化为有效的输出产品；当过程实例的后置条件满足后，用户就可以终止实例运行，提交产品。在整个运行过程中，度量指标随时辅助管理者进行定量分析、评估和决策，不断改进和调整过程，确保其正确高效地实施。
31
敏捷软件过程的约束关系
产品约束—数据流
数据约束—控制流
32
产品约束
活动和产品间的输入/输出关系
开放的软件过程事务模型
产品约束 描述
A
read-only
P
活动A只读取产品P
write-enable 活动A可读写产品P
reference 活动A只读取产品P作为参考，P的更改不影响A的执行
33
时序约束
活动和活动间的时序关系时序约束 描述
A
finish-start
B
活动B只有在 A 结束后才能开始
start-start 活动B只有在 A 开始后才能开始
start-finish 活动B只有在 A 开始后才能结束
finish-finish 活动B只有在 A 结束后才能结束
after-expect 活动A结束后，B应该开始执行了
after-prohibit 活动A结束后，B不能被执行
while-prohibit 当活动A正在执行时，B不能被执行
34
敏捷软件过程模型的结构
过程视图
度量
产品模型 功能模型
度量
产品nn
产品约束 时序约束
合作模型
过程模型
资源模型
资源分配
资源
活动
地点
35
敏捷软件过程的建模语言 FLEX
过程交换层
用户界面层
FLEX/PL
过程实施层
document IS product { state : (initial, submitted, reviewed); on read_event do read; on write_event f state = initial or state = submitted do write;}
FLEX/BM
<!ELEMENT ProcessView (ProcessEleRep*)><!ATTLIST ProcessView id CDATA #REQUIRED eleRepIds CDATA #REQUIRED fatherFunctionModelId CDATA #REQUIRED name CDATA #REQUIRED><!ELEMENT ProcessEleRep EMPTY>
FLEX/EX
用户
计算机
其他过程
36
Planning AnalysisPlan Requirement
OR OR
OROR Design
DesignCAR
CodingCodeTestingTest
report
7 56
121110
8 4
21
9 3
ReqTimer
Manager Analyser Customer
Tester Programer
Designer
codingsubsystem1
codingsubsystem2
OR
CodingCAR
Designdocument
subsystem1code
subsystem2code
Programersubsystem1
codesubsystem2
code
Code
Milestone1
c1c2
c3
c4
And
c3c5
Decision
Manager
DesignCAR
CodingCAR
Designdocument
37
敏捷软件过程的分析与优化
验证和优化模型
建模的过程是否合理，是否敏捷？
是否是期望的过程？
过程是否被正确建模？
38
分析与优化
静态分析 VS 动态模拟
基于过程改进和重组（BPI/BPR）的管理思想
面向企业的业务目标
围绕软件过程的敏捷性
39
静态分析和优化技术
正确性检查
必要性分析与过程简化
时效分析与并行化
资源和成本分析
图论分析
回路分析 通路分析
孤立点分析 出入度分析
40
静态分析和优化技术 (续）
变异分析
过程的协同和跟踪
缺陷和不完全性分析
价值（流）分析
41
动态模拟技术 - Why
敏捷软件过程在运行时的不确定性
比真实执行取得更快的反馈
以较小风险和代价预先“测试”过程
42
动态模拟技术 - How
采用概率分布模型或边界测试方法产生这些数据
活动报告
资源报告
产品报告
合作报告
43
敏捷软件过程工程环境E-Process
CPT界面 PMT界面 PET界面 PMS界面 RMT界面 ACC界面
过程工程师项目负责人
经理项目成员 系统管理员
构件与范式管理器
构件编辑器
范式编辑器
权限管理
过程编辑器
过程分析器
过程实施器
过程监控器
过程度量器
资源管理器
构件与范式可复用库
过程模型库 过程实施库 过程度量库 资源库
过程演化器
PMN界面 ITT界面
问题跟踪器
问题库
E-Process系统结构
44
45
