软件工程学概述
何谓软件危机
软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题
产生软件危机的原因及解决途径
技术原因
- 软件规模越来越大
- 软件复杂度越来越高
管理原因
- 软件开发缺乏正确的理论指导，过分依靠个人技巧和创造性
- 对用户需求没有完整准确的认识
解决途径：软件工程
- 对计算机软件正确认识
- 推广使用开发软件成功的技术和方法，研究探索更好更有效的技术和方法，消除错误概念和做法
- 开发和使用更好的软件工具
- 对于时间、人员、资源等需要引入更加合理的管理措施
软件工程定义及基本原理
- 软件工程
- 将系统化、规范化、可量化的工程原则和方法，应用于软件的开发、运行和维护
- 对其中方法的理论研究
- 主要目标
- 高效开发高质量软件，降低开发成本
- 基本原理
- 用分阶段的生命周期计划严格管理
- 坚持进行阶段评审
- 实行严格的产品控制
- 采用现代程序设计技术
- 结果应能清楚的审查
- 开发小组的人员应该少而精
- 承认不断改进软件工程实践的必要性
软件工程方法学包含哪三个要素
- 方法
- 工具
- 过程
软件生命周期阶段划分及各阶段的任务
- 可行性分析与开发计划
- 约束和限制
- 简要需求分析，建立逻辑模型
- 对可供选择的解决方法进行研究
- 技术可行性
- 经济可行性
- 社会可行性
- 需求分析
- 功能需求
- 非功能性需求
- 软件设计
- 概要设计
- 详细设计
- 程序编码
- 软件测试
- 单元测试
- 集成测试
- 系统测试
- 软件维护
- 改正性维护
- 适应性维护
- 完善性维护
- 预防性维护
各种生命周期模型的概念和特点
瀑布模型
- 阶段间具有顺序性和依赖性，文档驱动
- 推迟实现，不急于编写代码
- 尽可能的理解和掌握系统需求
- 清楚区分逻辑设计与物理设计，尽可能推迟程序的物理实现
- 质量保证的观点
- 每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务
- 每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误
问题
- 不希望有变化
- 变化来的越晚，付出的代价越高
- 设计阶段过多的假设，导致理想化、一厢情愿的东西过多（用户只参与需求）
- 文档驱动，静态
适合规模较大的系统或分布式开发模式
快速原型模型
- 对系统进行简单和快速的分析，快速构造一个软件原型
- 用户和开发者在试用或演示过程中加强沟通和反馈，获取到用户真正的需求
问题
- 所选用的开发技术和工具不一定是实际项目的需要
- 快速建立起来的模型可能由于不符合各种开发规范，加上不断修改，质量较差，被抛弃
适合一个全新的系统开发
增量模型
- 逐步增加系统功能
- 第一个增量构件往往实现软件的基本需求，提供最核心的功能
问题：
- 加入构件必须不破坏已构造好的系统部分
- 容易退化为“边做边改”模型，从而使软件过程的控制失去整体性
螺旋模型
- 在每个阶段之前都增加了风险分析过程（瀑布模型）的快速原型模型
适合大型复杂的系统
喷泉模型
- 典型的面向对象生命周期模型
- 迭代：逐步求精
- 阶段间没有明显的界限
敏捷软件开发
- 迭代式开发
- 增量交付
- 开发团队和用户反馈推动产品开发
- 持续集成
- 开发团队自我管理
敏捷宣言：
- 个体和互动胜过流程和工具
- 工作的软件胜过详尽的文档
- 客户合作胜过合同谈判
- 相应变化胜过遵循计划
优势
- 精确
- 质量
- 速度
- 丰厚的投资回报率
- 高效的自我管理团队
适合规模中小、需求变化频繁的系统开发，并且强调团队的作用，适合集中式的开发模式
极限编程
- eXtreme Programming
- 目的是降低需求变化的成本
- 开发方法
- 客户代表与开发团队紧密融合
- 结对编程 pair-programming
- 开发流程
- 编写用户故事
- 架构规范
- 实施规划
- 迭代计划
- 代码开发
- 单元测试
- 验收测试
- 核心做法
- 小规模，频繁的版本发布，短迭代周期
- 测试驱动开发 Test-driven development
- 结对编程 Pair programming
- 持续集成 Continuous integration
- 每日站立会议 Daily stand-up meeting
- 共同拥有代码 Collative code ownership
- 系统隐喻 System metaphor
了解敏捷过程和极限编程的基本思想
- Scrum 注重过程，XP 注重实践
- 需求被定义为产品需求积压 product backlogs
- 开发过程氛围多个冲刺周期 sprint
- 燃尽图 burn down 显示当前冲刺中未完成的数目
Scrum 角色
- 产品拥有者 Product Owner
- 利益相关者 Stakeholder
- 专家 Scrum Master
- 团队成员 Team Member
DevOps 过程
- 核心目标是自动化和可持续交付
软件架构的构件
4+1 视图
- 逻辑视图 Logic View
- 主要支持系统的功能性需求，即系统提供给最终用户的服务
- 功能描述
- 类模型
- 开发视图 Development View （模块视图 Module View）
- 软件模块的组织和管理
- 软件可通过程序库或子系统进行组织
- 子系统
- 接口
- 进程视图 Process View （并发视图）
- 系统的运行特性，主要关注非功能性需求
- 处理流程
- 并行性
- 同步
- 物理视图 Physical View
- 把软件映射到硬件上
- 考虑系统性能、规模、可靠性
- 目标硬件
- 网络
- 场景视图 Scenarios View
- 重要系统活动的抽象
软件架构风格
管道与过滤器
层次结构
仓库/黑板系统
- 中央数据结构：说明当前状态
- 独立构件：在中央数据存储上执行
若输入流中某类时间触发进程执行的选择，则仓库是一个传统型数据库
若中央数据结构的当前状态触发进程执行的选择，则仓库是一个黑板系统
正交软件结构
- 组织层
- 线索
客户机/服务器结构
- 服务器：管理系统的资源，服务器访问与并发性控制、服务器安全性、服务器的备份与恢复和全局数据完整性规则
- 客户应用程序：提供用户与服务器交互的界面、向服务器提交用户请求并接收来自服务器的信息、利用客户应用程序对存在于客户端的数据执行应用逻辑要求
- 网络：完成服务器和客户应用程序之间的数据传输
浏览器/服务器结构
与 C/S 结构相比，B/S 结构增加了一个应用服务器，可以将整个应用逻辑保存在应用服务器上，客户端的压力大大减轻，负荷被均衡的分配给了服务器
MVC 结构
Model View Controller