软件工程

软件开发方法

结构化法

• 自上而下，逐步分解，严格分阶段，应变差，风险高

面向对象的方法

• 自下而上，阶段界限不明确，更好应变，更好复用，符合思维习惯

面向服务的方法

• 粗粒度、松耦合，标准化和组件化
  抽象级别：操作 -> 服务 -> 业务流程

原型法（需求阶段）

• 原型渐进明细，用于让客户更加明确自己的需求，可以与以上方法结合

  • 按功能分：水平原型（界面）、垂直原型（复杂算法）
  • 按最终结果分：抛弃式原型、演化式原型

形式化方法

• 基于数学模型，证明/验证其真伪，偏理想化

统一过程方法

• UP

  • 用例驱动、以架构为中心、迭代和增量

    • 初始：定义最终产品视图和业务模型，确定系统范围
    • 细化：设计及确定系统架构，制定工作计划及资源要求
    • 构建：构造产品并演进包括需求，架构，计划等，直至产品提交
    • 交付：交付给用户使用

敏捷方法

基于架构的开发方法（ABSD）

软件开发模型

瀑布模型（SDLC）

（适用于需求明确稳定的场景）

• 迭代模型/迭代开发方法

  

演化模型

• 快速应用开发

  • 模块化：业务建模、数据建模、过程建模、应用生成、测试与交付

增量模型

螺旋模型

• 统一过程/统一开发方法

  • 以原型为基础+瀑布模型，并且考虑了风险因素

原型模型

• 敏捷开发方法

  

喷泉模型

• 模型驱动的开发方法

  

V模型

• 基于架构的开发方法

  • 测试活动贯穿始终
    

模型关系

构件组装模型

（CBSD）

• 定义构件标准，根据标准获取对应构件，组装形成完整模型

增量和迭代的区别：

增量-完整功能拆分成小的部分，每次提交每个部分的最终版本
迭代-完整功能拆分成多个版本，每次提交完整功能，但新版本伴随功能的升级和增减，每一轮迭代都要进行测试与集成

敏捷方法

适应性的，以人为本，增量迭代，小步快跑，比较适合小型项目

四大价值观：沟通（面对面沟通）、简单（不过度设计）、反馈（及时反馈）、改变（接受改变）

十二条过程实践规则：简单设计、测试驱动、代码重构、结对编程、持续集成、客户沟通、版本小型化、代码归集体所有、系统隐喻、规划策略、规范代码、40小时工作制

实践

• 极限编程

  • 适用于严格控制费用支出的公司

• 水晶方法

  • 用最少的纪律约束团队

• 开放式源码

  • 源代码对团队成员公开

• SCRUM

  • 明确定义可重复的方法过程

    • 产品待办事项列表 -> 排序形成迭代的待办事项 -> 每日站会反馈迭代进度 -> 评审会议，确认验收 -> 回顾会，经验总结

• 功用驱动开发方法
  （FDD）

  • 区分首席程序员和“类”程序员

• ASD方法

  • 三个非线性开发阶段：猜测、合作、学习

逆向工程

简而言之，逆向工程就是设计的恢复过程

实现级

• 包括程序的抽象语法书、符号表、过程的设计表示

结构级

• 反映程序各部分之间相互依赖关系，包括调用关系、数据结构等

功能级

• 反映程序段之间关系的信息，包括数据和控制流模型

领域级

• 反映程序所实现的需求和设计信息，如实体关系模型（ER图）等

系统转换

新开发系统时，需要完全兼容遗留系统的功能模型和数据模型

四种应对策略

• 改造–针对高技术水平、高业务价值系统

  • 对功能模型和数据模型做增强

• 集成–针对高技术水平、低业务价值系统

  • “孤岛”系统，信息打通即可

• 淘汰–针对低技术水平、低业务价值系统

• 继承–针对低技术水平、高业务价值系统

  • 继承原有系统的功能模型和数据模型，做技术升级

转换割接方式

• 直接转换

  • 老系统下线，同时新系统上线，中间没有过渡期

    • 成本低，风险高

• 并行转换

  • 老系统下线前一段时间，新系统上线，然后老系统下线，新系统正式运行

    • 成本高、风险低

• 分段转换

  • 子系统/模块轮流转换，直至全部替换成老系统

    • 成本较低、风险较低

数据的转换和迁移

• 抽取

  • 从老数据库获取数据

• 转换

  • 将抽取到的数据做一些转换以适配新系统的数据库

• 装载

  • 将转换后的数据装载到新系统的数据库中

系统运行与维护

分类

• 正确性维护

  • 修复测试阶段未发现的错误或bug

• 适应性维护

  • 使适应新的外部环境、数据环境、业务场景等

• 完善性维护

  • 增加/扩充新功能、改善性能

• 预防性维护

  • 预防软硬件环境变化