软件工程专业导论_软件工程发展中的新技术和新思想

• 敏捷软件开发方法：变化是不可避免的，应该通过
改善管理实践和工程实践来更好地适应变化
• 强调人在项目中的关键作用
• 敏捷软件开发认为人不是可以互相替换的“编程部
件”，而是具有创造力的个体，成功的软件开发活 动依赖于人的主观能动性
15
• 强调“刚刚好”（Just enough）
• 在保证软件开发有成功产出的前提下，尽量减少开
软件工程发展中的新技术和新思想
主讲人：穆静
1
开发软件的步骤
• 1．问题定义 • 2．可行性研究 • 3．需求分析 （需求？采用的方法？） • 4．软件体系结构（重用？） • 5．设计：总体设计和详细设计（采用方法？如何描 述？） • 6．实现（编码）（选择什么语言？） • 7．测试（完成后交付使用）（如何测试？） • 8．维护（如何维护）
• 因此，项目计划应具有可塑性，有变动的余地。当
23
敏捷宣言的12条原则
⑴ 我们的最高优先级是持续不断地、及早地交付有价值的 软件来使客户满意 ⑵ 拥抱变化，即使是在项目开发的后期。敏捷过程愿意为 了客户的竞争优势而接纳变化
⑶ 经常地交付可工作的软件，相隔几星期或一两个月，倾 向于采取较短的周期
⑷ 业务人员和开发人员必须在项目的整个阶段紧密合作
发过程中的活动和制品的方法，即开发中的活动及 制品既不要太多也不要太少
16
敏捷方法的产生
• 从20世纪90年代开始，逐渐产生了一大批敏捷软件开
发方法
其中比较有影响的包括：极限编程、Scrum、 看板方法、精益软件开发方法、水晶软件开发 方法（crystal）、自适应软件开发（adaptive software development，ASD）、动态系统开发 方法（dynamic system development method， DSDM）等
8
•
• • •
• •
TSE论文的具体主题涵盖如下领域： (1) 软件开发和维护方法和模型，例如：软件需求、设计和 实现相关技术和原理，包括形式化和过程模型等； (2) 评价方法，例如：软件测试和验证，软件可靠性模型， 测试和调试流程，软件差错控制中的冗余设计，软件度量，评 估不同领域的软件产品和过程等； (3) 软件项目管理，例如：生产率系数，成本模型，项目进 度控制和组织架构，相关标准制定等； (4) 工具和环境，例如：特定工具的介绍，集成开发环境， 包括软件架构、数据库以及并行和分布式处理等相关主题；
12
敏捷软件开发的产生背景
• •
软件开发的新挑战
快速的市场进入时间，要求高生产率 快速变化的需求 快速发展的技术
传统的软件开发方法
强调过程和文档 对变化的适应能力偏弱
13
提高对变化的适应能力
• Martin Fowler认为：
•
提前预测需求是困难的。同样，对项目进行过程中客户需求 优先级的变更进行预测也很困难
10
• TOSEM具体主题包括： • (1) 需求工程：需求获取、建模、规格说明、分析和原型
设计等；
• •
(2) 设计工程：软件架构，设计规格说明与细化，设计方 法、策略和风格，设计方案的文档化等； (3) 软件测试、分析和验证：包括用于评估软件是否满足 功能和非功能需求的算法、技术和过程；
• • •
29
· 透明 · 检验
Scrum的核心概念
⑸ 围绕着被激励的个体构建项目。为个体提供所需的环境 和支持，给予信任，从而达成目标
⑹ 在团队内和团队间沟通信息的最有效和最高效的方式是 面对面的交流
24
敏捷宣言的12条原则（续）
⑺ 可工作的软件是进度的首要度量标准。 ⑻ 敏捷过程倡导可持续开发。项目发起者、开发人员和用 户应该维持一个可持续的步调。 ⑼ 持续地追求技术卓越和良好设计，可以提高敏捷性 ⑽ 以简洁为本，它是减少不必要工作的艺术。 ⑾ 最好的架构、需求和设计是从自组织的团队中涌现出来 的。 ⑿ 团队定期地反思如何变得更加高效，并相应地调整自身 的行为。
做以及如何使用，是有价值的。但是，软件开发的 主要目标仍然是创建可运行的软件
•敏捷软件开发强调不断地快速地向用户提交可运行
的软件（不一定是完整的软件），以得到用户的认 可
21
客户合作 重于 合同谈判
• 只有客户才能明确说明需要什么样的软件，然而，
大量的实践表明，在开发的早期客户常常不能完整 地表达他们的全部需求，有些早期确定的需求，以 后也可能会改变 方式，将需求固定下来常常是困难的 流和紧密合作来发现用户的需求
28
Scrum的产生历史
• 1986年，竹内弘高和野中郁次郎在《哈佛商业评论》
上发表了The New New Product Development Game， 首次使用Scrum来描述产品开发中的一种新方法
• 1993年，Jeffery Sutherland和Ken Schwaber将该方法引
入软件开发领域，并于1995年在OOPSLA会议上发表了 相关论文
个体和交互 重于 过程和工具 工作的软件 重于 详尽的文档 客户合作 重于 合同谈判 响应变化 重于 遵循计划
也就是说，尽管右项有其价值，
我们更重视左项的价值
19
个体和交互 重于 过程和工具
• 过程和工具是重要的，但是软件开发中人的作用和
交流的作用更需要被进一步强调
• 软件是由人组成的团队来开发的，与软件项目相关
•
•
对很多项目来说，软件设计和构建是交错进行的。也就是说， 设计需要通过实施构建来获得验证，而在构建的过程中新获 得的知识又可以帮助设计
从制定计划的角度来看，分析、设计、构建和测试活动并不 容易预测
14
敏捷方法的基本观点
• 强调适应性而不是可预测性
• 经典软件开发方法：通过控制变化实现软件开发的
可预测性
2
分析和设计的主流两种方法
• 1．结构化设计方法
SA—〉SD—〉SP—〉ST—〉SM
• 2．面向对象设计方法
OOA—〉OOD—〉OOP—〉OOT—〉OOM 软件工程在过去几十年的发展历程中，也形成了一些鲜 明的新思想。
3
• IBM 提出了软件开发思想的4项要点——迭代开发、以
系统架构为中心、持续的质量保证以及管理变更和资 产，其中只有“持续的质量保证”和传统工业工程是 十分吻合的，而其它3项具有软件特性所拥有的思想。 软件的变更比较频繁，自然对其管理的高要求，进一 步促进迭代开发的合理性。 客户和业务用户始终希望软件能够按时交付高质量的 产品，又认可软件的灵活性，希望软件能够具有随需 应变的能力，及时进行必要的修改来满足业务的新需 求。同时，软件又是一种知识型产品，需要创造性， 并依赖每个开发人员的创造力和积极性。所有这些引 导人们新的思考，引导人们不断认识软件工程而建立 独特的软件工程思想。
17
敏捷宣言
• 2001年2月，17位敏捷方法的先驱在美国犹他州召开了为 • 该宣言由四个价值观声明组成，并提炼出敏捷软件开发
方法必须遵循的12条原则 期2天的会议，成立了敏捷软件开发联盟 并发布了“敏捷 宣言”
18
敏捷宣言
我们正通过亲身或者协助他人进行软件开发实践来 探索更好的软件开发方法。 基于此，我们建立了如下的价值观：
化、产品标准化和技能标准化。
生产标准
• 软件工厂思想造就了组件、构件技术，包括自动化测试。
围绕项目管理开展工作，包括风险预防、里程碑控制和 关键路径法等。
6
软件工程研究领域最顶级的两个 期刊
• 软件工程研究领域最顶级的两个期刊： • IEEE Transactions on Software Engineering (TSE) • ACM Transactions on Software Engineering
的各类人员通过充分的交流和有效的合作，才能成 功地开发出得到用户满意的软件 技能很差，或者不能很好地交流和协作，软件是很 难成功地开发的
20
• 如果光有定义良好的过程和先进的工具，而人员的
工作的软件 重于 详尽的文档
•可以工作的软件是软件开发工作的最终目标 •好的必要的文档能帮助我们理解软件做什么，怎么
•
(4) 配置管理：版本控制和系统演化；
(5) 软件维护和再工程； (6) 软件重用：构件重用技术，例如可重用构件的说明、 设计和实现； (7) 软件过程工程：过程建模、分析、定制、实施和演化 等； 11
Байду номын сангаас
•
(8) 软件工程环境：组织结构、工具集成以及互操作性， 对象管理工具、特定语言下的工具、智能工具、专用 工具等，软件可视化等；
26
精益思想的5条原则（续）
• 拉动系统 • 拉动系统是基于当前客户的需求，向上游环节逐级
反馈，每个环节都基于下一个环节的需求而进行生 产
• 持续改善 • 持续改善是精益思想的最重要支柱。精益思想的核
心就是不断进行改善从而最大化价值
27
敏捷方法的公共特征
• 致力于降低变化的成本 • 价值导向 • 充分发挥人的积极性 • 基于增量和迭代的开发方法
4
•
• 迭代开发，以时间换空间，消除市场风险。 • 敏捷开发或轻量级过程，以不变应万变。 永远的Beta，
不断推陈出新，永无止境。 持续集成、持续构建、 全程测试。
• 知识管理，将软件工程纳入知识管理的范畴。 • 面向对象是一种方法，也是一种思想。 • 软件即服务(SaaS)，面向服务架构(SOA)的开发思想。
• 由于软件开发的预测性的困难，想通过合同谈判的 • 敏捷软件开发强调与客户的协作，通过与客户的交
22
响应变化 重于 遵循计划
• 任何软件项目的开发都应该制订一个项目计划，以
确定各开发任务的优先顺序和起止日期。然而，随 着项目的进展，需求、业务环境、技术等都可能变 化，任务的优先顺序和起止日期也可能因种种原因 会改变 出现变化时及时做出反应，修订计划以适应变化
用例驱动开发，用户为本思想在软件中的体现。
5
• 同时，软件工程可以向传统工业工程学习，吸收传统工
业工程上百年实践积累下来的经验、沉淀下来的思想。 以顾客为中心的全面质量管理。 过程决定结果。 有效的持续改进过程。 预防为主， 检验为辅。 验证和确认缺一不可，质量保证和测试融 为一体。
•
• 以架构设计为中心，体现设计为重的思想。
Methodology (TOSEM)
• 在这两个期刊上发表科研论文是众多从事软件工程研
究的人梦寐以求的事情
7
IEEE Transactions on Software Engineering (TSE)
•
TSE是公认的软件工程领域最权威的国际学术期刊， 从2013年起，TSE恢复月刊，每年一卷，12期（2008年 -2012年为双月刊，每年6期，2008年之前为月刊）， 每期6-10篇论文，一年约80-100篇论文。 TSE既有一些软件工程的理论性研究论文，也有一 些经验性研究论文，这些研究对于软件系统的构造、 分析和管理具有一定的意义，其范围覆盖整个软件工 程研究领域。
•
• • • • •
(9) 软件测量、度量和评估方法及经验研究（实证研 究）；
(10) 人机交互； (11) 协作软件工程; (12) 与分布式系统、实时系统、安全关键系统、安 全系统、多媒体系统和移动计算等相关的特定软件工 程技术； (13) 与编程语言、人工智能和数据库相关的技术； (14) 特定领域的软件工程技术；
• •
(5) 与系统相关的主题，例如软件和硬件的权衡等；
(6) 高水平的调查工作以及综述，例如与一个特定研究领域 的历史发展情况相关的全面性综述。
9
ACM Transactions on Software Engineering Methodology (TOSEM)
•
•
TOSEM是软件工程领域最负盛名的学术期刊之一，基 本上每年1卷，每卷4期，4期发行时间分别为一月、四 月、七月和十月，TOSEM有点季刊的味道。 TOSEM的征稿范围包含软件工程所有研究领域，包 括在整个软件生命周期中与产品和过程细化、评估和 演化相关的模型、语言、方法、机制和工具，涵盖从 需求规格定义到软件维护全过程，TOSEM也包含软件 形式化和一些实验性（经验性）的研究工作。
25
• 识别价值 • 价值是客户愿意购买产品的原因，也是产品开发的
根本价值所在。“是否有助于增加价值”是精益方 法衡量过程活动的准则
精益思想的5条原则
• 定义价值流 • 价值流描述了组织为了交付价值所采取的一系列有
增值的活动
• 保持价值流的流动 • 良好的系统应该让价值迅速流动，从而用较低的成
本生产出正确的产品