现代软件工程复习
软件工程概述
什么是软件工程
是把系统的，有序的，可量化的方法应用到软件的开发，运营和维护上的过程
软件工程包括那些领域
软件需求分析，软件设计，软件构建，软件测试，软件维护。
为什么要搞软件工程
因为需求复杂（要满足不同用户的多种需求，并提供长期服务）
因为系统复杂
因为人的生命财产依赖于软件
Program = data structure + algorithm
Software = Program + Software Engineering
Software Company = Software + Business Model
软件的特性
- 复杂性（软件是人类创造最复杂的系统类型）
- 不可见性（看不到软件如何在用户机上被执行，且只能捕捉错误出行的一丝痕迹）
- 易变性（看上去很容易修改，人们总是期待1.让软件做新的事。2.让软件适应新的硬件。但正确的修改软件不容易）
- 服从性（软件不能独立存在，服从硬件，系统中其他部分，服从用户，行业要求（银行利率））
- 非连续性（输入的改变和输出的改变差别很大）
- 没有银弹（有许多新特性，但都无关紧要（新编程语言，开发平台，软件开发流程，ai-coding，github），他们无法改变软件工程的根本难度）
软件质量
不合格的软件带来的伤害是巨大的（people and money）
bug or feature？取决于你看的角度
软件工程和计算机科学的不同
计算机科学总与理论有关，软件工程总与人有关
个人技术
单元测试
对软件基本组成单元进行的测试，其测试对象式软件设计的最小单元（模块或类）
- 行覆盖（又叫语句覆盖）就是通过设计一定量的测试用例，保证被测试的方法每一行代码都会被执行一遍。
- 判定覆盖（判定覆盖的含义就是代码里每一个判定都要走一次true，一次false）
- 条件覆盖（条件覆盖和判定覆盖类似，不过判定覆盖着眼于整个判定语句，而条件覆盖则着眼于某个判断条件。条件之间可以搭配走）
- 路径覆盖（覆盖所有可能执行的路径，所有t/f组合）
弊端： 无法测试没写代码 效能问题，线程问题
回归测试
指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误
个人软件流程
PSP 2.1（个人软件工程）
- 优点
- 不依赖于某一种语言，着眼于开发流程
- 不依赖于考试，依赖工程师自己收集数据，然后分析，提高
- 缺点
- 在小型的创业团队很难找到高质量需求分析文档，导致后续活动混乱
- 依赖于数据 需要手动记录，且易丢失
- 难以记录工作量
- 没衡量最终的结果（没客户）
软件工程师的误区
- 分析麻痹（100%把握再出手）
- 依赖链条过长（不分主次，想解决所有问题）
- 过早优化（一开始想太远了）
- 过早泛化(画扇面，太贪了)
双人合作
代码复审
- 自我复审（开发者过于自信，可能无效）
- 同伴复审（简便易行）
- 团队复审（覆盖率高，适合关键代码和不再更新的代码）
复审代码核查表-概要
- 代码符合需求和规格说明么？
- 代码设计是否考虑周全？
- 代码可读性如何？
- 代码容易维护么？
- 代码的每一行都执行并检查过了吗？
复审者的更高要求
- “这么修改之后，有没有别的功能会受影响?”
- “项目中还有别的地方需要类似的修改么?”
- “有没有留下足够的说明，让将来维护代码时不会出现问题？对于这样的修改，有没有别的成员需要告知?”
- “导致问题的根本原因是什么？我们以后如何能自动避免这样的情况再次出现?”
结对编程
好处
- 提高设计质量 避免愚蠢bug
- 减低成本 分享知识，降低debug时间
- 提高解决问题的信心
- 提高士气 工作被认可
- 减轻风险 降低成员离开的负面影响
- 提高效率 不好意思摸鱼
坏处
- 工作方式不同
- 让人感觉威胁
- 时间可能花在培训上
- 对个人情绪和自尊影响
合适的场景
- 降低容易犯的错误 新手 + 新手， 或者双方各有明显弱点
- 探索一个新的领域
- 传播知识和技能 老手+新手
不适合的场景
- 需要深入地研究的项目，需要一个人长时间的独立钻研；
- 在做后期维护的时候，如果维护的技术含量不高，只需要做有效的复审即可；
- 如果验证测试需要运行很长时间，那么两个人在那里等待结果是有点浪费时间；
- 如果团队的人员要在多个项目中工作，不能充分保证足够的结对编程时间，那么成员要经常处于等待的状态，反而影响效率；
团队软件流程
瀑布流程
他反应了软件开发的串行的，连贯的步骤
- 好处：
- 每一步的结果都是可验证的
- 减少风险
- 给团队提供稳定的流程支持
- 坏处
- 流程结束之前无法发布软件，适合大公司
- 很难逆转，代价很大。但一般给不出明确的需求
生鱼片模型
虽然解决了各个步骤分离的缺点，但究竟什么时候结束上一个步骤呢？
waterfall with Subprojects
分而治之
风险：
- 合并的代价
- 不能提前看到
- 相互依赖
螺旋模型
每个版本都要衡量并控制风险，随着投入的增加和产品的运行，失败的风险在降低
- 需要高水平的管理团队
- 很难明确定义目标和稳定的里程碑
RUP统一流程
以上的流程都有一个共同点：
- 重计划
- 重事先表达
- 重文档设计
这一类方法的集大成者是RUP(rational unified process)。他把软件开发的各个阶段整个在一个统一的框架里。
渐进交付
一直循环直到：
没时间了 没钱了 用户满意了
MVP和MBP
最小可行产品 最强最美产品
敏捷开发
敏捷开发是一组软件开发思想的统称
产生背景：
技术更新加快，需求变化快，开发流程必须跟上快节奏的变化。
和传统的区别
原则
- 尽早并持续交付有价值的软件以满足顾客的需求
- 敏捷开发欢迎需求变化，并利用这种变化来提高用户竞争优势
- 经常发布可用的软件，发布间隔不等，能短就短
- 业务人员和开发人员在开发项目过程中每天工作
- 以有进取的人为项目核心，充分支持信任他们
- 无论团队内外，面对面交流最有效
- 可用的软件是衡量项目进展的主要指标
- 应该能保证可持续发展，领导，团队和用户应该能按目前的步调持续合作
- 只有不断关注技术和设计才能越来越敏捷
- 保持简明，尽可能简化工艺
- 只有能自我管理的团队，才能创造优秀的架构
- 时时总结如何提高团队效率，并付出行动
SCRUM
- 找出产品需要做的事 product backlog
- 决定当前的冲刺需要做的事，细化任务，成员能主导任务的分配，提高能动性
- 冲刺 外部人士不打扰，只能通过Scrum大师来完成
- 得到软件的增量版本，发布。接着计划增量
每日立会 燃尽图/看板 冲刺阶段时间驱动
自主管理，自我组织，多功能性
BBD
行为驱动开发
从用户角度描述功能和需求
任何功能必须给顾客有明确的，可认可的价值
事先的分析，设计和计划会过犹不及
敏捷和计划驱动的试用范围
软件需求
需求分类
- 对产品功能性的需求
- 对产品开发过程的需求，产生某种文档，时间约束，对源码约束
- 非功能性的需求 服务质量需求
- 综合需求 牵扯到不同部门
所有利益相关者的需求
用户 顾客 市场分析者 监管部门 软件工程师 产品创始人
用户调研
焦点小组
找到一群目标用户的代表，加上项目的利益相关者来讨论用户想要什么，用户对软件的评价。
问题：
- 容易讨好他人
- 表达能力差异
- 容易控制会议导向
- 容易蒙蔽研究者
- 用户不一定能理解
问卷调查
问题：
- 定义不明确
- 让用户花额外努力来答题
- 带有引导性的提问
- 过于开放式的问题
- 选择过于狭窄的问题
四象限
典型用户和场景
需求规格说明书很重要，表示浪费时间。
项目管理
风险分类
- 人（客户，用户，利益相关者）
- 流程（目标，预算，费用）
- 技术（技术是否可用，安全，开发和测试环境）
- 环境（法律， 对手，经济，商业条件）
分析和优先级划分
计划和管理风险
研究（解决） 接受（承认风险） 规避（预判） 转移（传递风险给其他人） 降低（尽量避免损失） 制定应急预案（提前准备极端情况）
软件设计
UML
一种通用建模语言。用来对软件密集型系统进行详述、构造、可视化和文档化
用例图
参与者 用例（系统边界） 关联
启动用例者，称为启动者（虚拟启动者 每月扣款）
类图
聚合和组合是正常的 指向组后后的对象
泛化和用例图一样是反着的 泛化对象指向被泛化对象
活动图
一个过程或操作的工作步骤
泳道
自动执行，描述并发，分类特性
顺序图
基于时间的动态交互
消息可用有限制条件，用方括号写在上面
自调用就是自己画回来
生命线的概念，创建和删除对象
分支，走向不同的对象
高级概念
激活区 会加粗活动在生命线的区域
时间建模 画出持续时间的感觉，斜线
循环 画个方框
软件测试
定义
测试-提供输入，将结果和预期进行对比
质量保障-所有增加质量的活动总和（测试是一部分）
客观质量和主观质量
1.客观质量：
- 稳定性
- 符合规范
2.主观质量
- 满足客户需求
- 愉快的体验，情感价值
- 让客户想要更多
两类方法
黑箱
在测试过程中把系统当成黑箱，不知道其内部结构。从软件行为来测试
白箱
在测试过程中清晰的知道结构，用软件内部知识来指导测试数据，
测试用例设计方法
等价类划分
将输入域划分成子集，每个子集效果一样
- 有效等价类 合理输入
- 无效等价类 不合理输入
基本思路就是选尽量少的数据测试
边界值分析
最等价类划分的补充
着重分析边界值
正交实验设计法
正交实验
但是单因子代价过大，测试表明双因子性价比最高
效能测试
效能测试-正常情况，保证高效服务
负载测试-人多，尽量保证服务
压力测试-居多，不能崩溃
软件质量
软件工程的质量
- 开发过程的可见性
- 开发过程的风险控制
- 内部模块的交互质量
- 开发成本的控制
- 内部质量的指标
燃尽图
燃尽图可以暴露很多问题
让用户代替测试会面临的问题
- 没有测试（润年的测试）
- 没有严格的测试标准时间
- 要等很久
- 报告的bug很多，但只靠开发员很难复现bug
- 修复也慢
- 没有责任，没有质量
软件发布
- Alpha：指集成了主要功能的第一个试用版本。在这个版本中有些小功能可能并未实现。
- Beta： 功能基本完备，稳定性较Alpha版本高，用户可以在实际工作中小范围使用，可以有 Beta1、Beta2、Beta3 ……
- ZBB（Zero Bug Build）：某天的版本要把在之前（例如48小时前）记录的Bug都解决掉。
- RC（Release Candidate）：发布候选版本，RC1、RC2……直到RTM为止，版本间隔时间较短。
- RTM（Release To Manufacturer）：最终发布版本。如果某一个RC版本没有很大的问题， 那么这一RC就会成为最终的版本，通常情况下，软件公司会把最终的版本和相关的文件及其他资料交给另一个团队（Manufacturer）去包装、刻制光盘。在App Store/ Marketplace的年代，我们有相应的RTM（Release To Market）或者RTS（Release To Store）。
- RTW（Release To Web）：要依赖“Web”来发布我们的最终版本。如果软件产品是一个网站服务，则一般会交给网站运营团队（Operation Team）去管理，这样的发布也可以叫做RTO（Release To Operation），运营团队和研发团队一起决定什么时候系统上线（Go Live）。
从软件完成到发布
会议小组
- 修复
- 设计本来如此
- 不修复
- 推迟
浙公网安备 33010602011771号