软件工程的前生今世
被迫产生的软件工程
软件开发
- 50-60年代：手工作坊
- 60-70年代：合作生产
- 70年代以后：工程化
1968年“软件危机”概念出现
质量，进度与成本
人们被迫研究软件生产中的技术手段和管理方法
产生了软件工程
软件工程是应用计算机科学、数学及管理科学等原理 开发软件的工程。它借鉴传统工程的原则、方法，以 提高质量，降低成本为目的。
三要素
- 方法
- 过程
- 工具
一级学科
在中国先是计算机与技术0812，然后才产生软件工程0835
知识体系
2001年SWEBOK把软件工程分为10个领域
- 软件需求
- 软件设计
- 软件构造
- 软件测试
- 软件维护
- 软件配置管理
- 软件工程管理
- 软件工程过程
- 软件工程工具和方法
- 软件质量
跨界
软件工程的研究除计算机软件本身外，还涉及众多其他的领域 ，如管理科学、心理学、经济学、人机工程学等，因此，它是 一门综合性学科。
软件自动化级别
主要开发活动所占比例
也许未来的软件开发可能真像老师说的那样，给电脑说出需求，立马就生成软件了，那不就是AI写代码吗！
软件工程的发展
- 形式化 -> 如何描述“做什么”问题
- 工程化 -> 总结软件开发过程的规律，解决“怎么做”
- 软件危机促进了软件自动化的发展
- 软件自动化的目标是解决软件问题
万变不离其宗
幽默一则
看起来在实际的公司里也是很常见的
软件开发周期
软件开发的基本活动相同，但组织方式不同，构成了不同的软件生存（开发）周期模型
从左到右依次是硬件的，理想中软件的和实际软件的
典型的开发周期模型
瀑布模型不可倒流，迭代模型就是不断的迭代
软件开发基本活动
围绕着变更管理这个轴，不断转动轮子
可行性分析 做不做？
- 经济
成本 - 技术
技术人员水品 - 社会环境
政府政策，市场需求 - 人
人物（舵手）,人才，人手，人精
需求分析 做什么？
- 捕获
可能客户自己都不知道想做什么(女孩的心思很难猜)，就只能不断捕获了 - 记录
一条一条几下来 - 分析
常见的会用UML建模语言展示
系统分析与设计 怎么做？
- 体系结构
- 模块
- DS与算法
- 界面
详细设计 怎么做？
应该就是各种设计图，比如UML类图吧
精通各种编程语言
测试
"给你一台冰箱，如何测试？"
常规 + 机端 = 通过
- 单元测试
唯一一项由开发人员测的 - 集成测试
- 系统测试
- 功能测试
- 性能测试
- 压力测试
- 回归测试
部署
- 开发环境与生产环境
- 软件本身bug
- 支持环境兼容性问题（OS，数据库等）
- 自动化部署（降低部署成本）
维护
改正性，适应性，完善性，预防性
管理活动贯穿整个周期
- 二八理论
- 被管理者也应具有管理的思维
- 牧羊与牧猫
一般小团队都在6，7人
不变的是变化
需求捕获与分析
幽默一则：客户，分析人员，设计人员，开发人员对需求的理解
需求分析的困难性
- 客户说不清楚需求
- 需求自身经常变动
- 分析人员或客户理解有误
- “据历史记载，没有一个软件的需求改动少于三次。唯一只改动需求两次的客户是个死人。这个可怜的家伙还是在运送第三次需求的路上被车子撞死的”
需求捕获
- 开发时把人们的期望转化未一种能够满足其期望的产品的过程。
- 产品什么都不是，而开发的过程就是一切
- 发现什么都不是，而发现过程（探索过程）就是一切
需求 捕获
- 一个过程
- 一个发现的过程
- 一个试图发现的过程
- 一个试图发现期望的过程
- 一个试图发现对新产品的期望的过程
- 一个发现客户对新产品的期望的过程
需求捕获方法
- 用户主诉
- 问卷调查
- 头脑风暴会议
- 超越用户
- 业务发展
- 产品数据
- 竞品分析
- 用户的反复无常
脑图工具协助捕获
没有不变的需求
- 需求时隐藏在用户和客户内心最深处的无形东西
- 需求捕获是一切开发活动的基础
- 需求把握的程度与对客户的了解程度相关
- 需求变化是核心（典型情况下未25%的需求变化)
- 因需求变更导致的返工占返工总量的75%-85%
- 需求变更的主要原因：客户参与项目的时间越长，他们对项目的理解就越深入，开发过程能够帮助客户更好的理解自己的需求
司机和汽车
- 客户是司机，确定需求的变化
- 软件开发团队是汽车，需要向客户提供方向盘，并且告知我们现在的位置和状况
- 即使看上去很顺利，司机也不应该把视线从公路上移开
- 汽车离不开司机，不能总是处于自动驾驶状态
如何应对需求变更
- 用户热衷于变更，变更让产品变得完美
- 告诉客户变更所引起的进度和金钱成本
- 进行变更控制（配置管理)
- 编程控制组（CCB)是配置项目变更的监管组织。其任务是对建议的配置项变更做出评价，审批以及监督已批准的变更的实施。
变更请求流程
需求分析前的工作
1.确定涉众和用户类型（命名，简要描述，特征，能力）
2.确定涉众代表（命名，简要描述，责任，参与）
3.项目中加入涉众代表（访谈，问卷，评审，角色扮演）
4.创建共同的构想（问题定义，系统范围，用户目标，飞功能需求前景文档）
5.采用传统的需求捕获技术对需求进行捕获
6.组建需求分析队伍（少量，有问题域知识）
需求分析时
- 在合同中一定要说清楚“做什么”和“不做什么”
- 尽可能地分析清楚哪些时稳定地需求，哪些时易变的需求。以便在进行系统设计时，将软件的核心建筑在稳定的需求上，否则将会吃尽苦头
- 必须满足和协调涉众的利益
有效的需求分析员
- 大多数需求分析人员都是从开发人员成长起来的
- 从数字世界到现实世界
- 教育不同，训练不同
有效的需求分析员
1.一个有效的需求分析员需要子啊需求分析过程中和用户简历真正的伙伴关系
2.能够在错综复杂的现象中发现问题背后的问题
3.在陌生的领域内能学得更快
4.有效的需求分析员必须用自己的智慧，行动和真诚去发现需求，挖掘需求
5.要用共同的语言和用户经行交流
6.好的方法和习惯能够让需求分析更加有效
建立真正的伙伴关系
- 转变态度，具有服务意识
知道用户的业务目标是什么，知道用户三年甚至更久的发展方针是什么，知道我们的软件能够给用户带来哪些利益，用户把我们当作朋友吗 - 培养人际关系
真诚的面对客户，用真心换取真心，尽力和用户成为朋友 - 展开商业想象
大胆寻求满足用户需求的更佳途径。像用户一样看待事物远远不够，要争取看得更清晰，即“超越用户”
发现问题背后得问题
- 如果需求分析知识停留在表面得问题，而不能够发现用户真正关心得问题，很难相信开发出来得软件能够让用户发自内心得满意
- 用户得要求往往是开发完成某个功能得软件，用来解决目前存在得问题。但是软件真正能够给用户创造的价值是什么，这是每一个需求分析员必须思考的问题
用共同的语言进行交流
- 应该努力的去熟悉用户的行业，学习用户使用的术语，标准，以便能够准确的理解用户
- 应该尽量不使用IT行业的术语，而采用浅显易懂的口头语言来解释It行业中高深莫测的术语，以便用户能够很好的理解
用例设计
- 用例反映需求
- 用例连结上下游
- 粒度过小：对设计者无用，不能提供足够的信息
- 粒度过大：客户无法理解专业术语，无法通过良好的迭代过程获取稳定和完整的需求
- 用例采用半形式化描述以满足双方的要求
- 用例开发团队
- 人数：2-3人
- 不同背景，不同性格的人
用例分析误区
- 用例分析技术包括了整个需求过程
只是一个需求分析技术，是在传统的需求捕获技术的基础上使用的，并无法替代这些技术 - 用例分析技术是分解技术
其实用例分析技术是一种合成技术，将在需求捕获中收集而来的零散的特性合成用例
适合做需求分析的人
- 乐于学习，善于学习的人
- 具有快速学习能力的人
- 能站在用户立场上思考的人
- 不以自我为中心的人
- 性格不同的人组成的小而平衡的团队
需求工程
把所有与需求直接相关的活动统称为需求工程
扩展阅读
软件测试
不容忽视的测试
- 亡羊补牢
- 测试不简单
- 测试自动化是必由之路
- 软件产品质量不能只靠测试
软件测试基本原则
- 程序员应避免测试自己编写的程序
- 测试用例的设计必须包括预期的输出结果
- 测试用例应包括有效的和期望的输入情况，也要包括无效的和不期望的输入情况
- 只检查程序是否做了它应该做的事这仅仅完成了测试工作的一半，另一半则是检查程序是否做了它不该做的事
- 彻底检查每个测试结果
- 避免不可重复的即兴测试，保留全部测试用例
- 一段程序中存在错误的概率与在这段程序中已发现的错误数成比例
- 测试一项非常复杂的，创造性的和需要高度智慧的挑战性任务
- 不能为了便于测试擅自修改程序
- 测试工作必须由明确的目标
- 尽早地和不断地进行软件测试
有关测试的几个误区
- 测试范围：代码+文档
- 测试简单？
- 什么时候开始测试？测试用例
- 测试可以驱动开发：不再是亡羊补牢式的工作,TDD(Test-Driven Developement)
疲于奔命捉bug
- 编码随意-> 编码规范
- Quickly and Ugly -> 重构+单元测试
- 只顾编码，不顾文档 -> 随时注释+文档自动化
捉bug有组织有纪律
- 有组织
- 有目的
- 有计划
- 有范围
- 有接口
- 有数据
- 有维护
自动化捉bug
CASE
CASE工具由三个步骤组成
- 分析并设计出明确的需求规格说明书
- 建立功能点和源代码（及文档）---一一对应的数据字典
- 将需求规格说明书转化为源代码和文档
测试工具
- 随着软件测试的地位逐渐提高，测试的重要性逐步显现，测试工具的应用已经成为了普遍的趋势
- 目前用于测试的工具一般可分为
- 用于测试管理（测试流程管理，缺陷跟踪管理，测试用例管理）的工具
- 白盒测试工具
- 黑盒测试工具
- 性能测试工具
应用测试工具的目的
- 提高测试质量
- 减少测试过程中的重复劳动
- 实现测试自动化
日益强大的测试工具
- WinRunner
提高软件质量的方法
- 提高产品质量是一个终极目标
- 捉bug不是唯一的办法
- 提高分析水品，设计水品
- 提高管理水品和团队协作能力
- 提高软件开发过程开发，管理和优化
- 引入软件质量保证:SQA
第三方软件评测
- 国家级和省级软件评测中心
- 致力于软件工程，质量管理，软件系统测试，信息系统集成资质认证，ISO9000认证咨询，CMMI认证咨询，信息工程监理，信息系统验收评估等领域的研究与实践
扩展话题: 软件工程在工作中到底起多大作用？
第二章 敏捷开发
方法论来源于恐惧
软件开发的方法论
- 方法论
- 一系列需要照着做的方法
- 一系列约束开发人员的规则
- 软件工程师非常实践，非常工程，非常灵活的一套方法
- 某些方法在某些情况下会比另一些方法好，反之亦然
方法论源于恐惧
处于对项目的超期，成本失控等等因素的恐惧，项目经理们从以前的经验出发，制定了一些控制，监测项目的方法，技巧
- 方法论的分类
按照规则的多少和约束的强弱，或者软件开发过程中的中间产物，如需求规约，设计模型等 - 重型方法和轻型方法
重型方法
特征： 正规，严谨，开发人员具有较强的可替代性
侧重点： 计划，过程，中间产物（状态报告）
不同人员偏爱程度不同：管理者，开发人员
轻型方法
特征：迭代，重构，响应需求变化
交付物：代码，可运行的产品，测试用例
管理成本低而高效
开发人员偏爱
方法论轻重的确定
1.没有两个项目会采用完全相同的方法论
2.软件工程是非常灵活的一套方法
3.可考虑因素：项目规模和紧要性
4.提倡“刚刚好”
5.工作重点：沟通，反馈，频繁交付
6.管理目标：有效和灵活
轻重方法的融合
1.自动化技术和工具使得轻重方法之间的界限进一步模糊
2.自动化工具的同步特性支持轻型方法的迭代和重构
3.自动化工具的模型翻译和转换依赖于重型方法的详尽文档和模型
4.大型软件项目往往结合轻型方法和重型方法
瀑布模型被取代了么？
1.所有的软件开发方法论和开发模型都毫无例外地由基本开发活动构成
2.不同地方法论相互结合而非取代
3.从不同地方法论中借鉴适合自己团队地方法和工具
敏捷开发是什么
典型瀑布模型开发
将开发过程分为若干活动，每个活动责任明确，活动完成地好坏直接影响着下一活动地好坏
活动之间存在着隔阂，管理采用命令式管理，每个活动的交付物可能很多。写一行代码，弄十篇文档的夸张现象可能也有
从瀑布到车轮
敏捷宣言
1.个体和交互胜过过程和工具
2.可以工作的软件胜过面面俱到的文档
3.客户合作胜过合同谈判
4.响应变化胜过遵循计划
宣言落地
1.不同的敏捷方法采用的实践不同
2.响应变化 -- 快速迭代
3.客户协作--快速迭代
4.可工作的软件--持续交付
5.个体与互动 -- 站会和看板
敏捷特征
1.敏捷目标：灵活和有效
2.开发过程：快速增量迭代
3.管理风格：自组织和自管理
4.响应变化：自适应性
灵活和有效
1.更好的响应变化的需求，更快的开发进度和更高的质量
2.方法的灵活和创新
3.有效的含义
快速增量迭代
1.小步快跑：小版本，小周期
2.随时看到效果
3.收集fankui
4.随时修正
5.维持团队成员开发积极性
自组织团队
1.培养团队是关键
2.自组织与自管理
3.一个团队不只是一群人
4.成员自动自发，默契，协作，互补
5.共同的目标，共同的工作理念和文化
6.建立在团队个人能力和松散管理的基础之上
- 开发能力
- 自我约束能力
- 松散管理（主动认领）
自适应性
1.需求变更可以为客户创造竞争优势
2.需求是不稳定的和全天候的
3.对需求稳定性的判断和预测很难
4.通过建立过程的自适应性来解决不可预测性
5.原地踏步式的连续适应性变化收效甚微
6.必须是增量式适应
典型敏捷开发方法
SCRUM
团队成员像打橄榄球一样迅速、富有战斗激情、人人你争我抢 地完成同一个目标
Product backlog产品需求，具有优先级
Sprint Backlog 拆分出的小任务，等待开发人员主动来领取。
产品负责人
SCRUM master
开发团队
每日站会
- 每天早上
- 15分钟左右
- 没人必须发言
3.1 昨天已做的
3.2今天要做的
3.3 遇到的问题 - 更新看板
各式看板
计划纸牌
SCRUM总结
- 规定了一个非常简单的开发流程
- 以团队的自主自发为基础
- 主要团队成员应跨职能，全职
- 快速，迭代，增量的开发出可交付系统
- 可以融合其他敏捷方法中的工程技术手段。
