吉林大学软件工程1~2

第一章

软件与软件危机

• 软件：程序、数据、文档
• 对软件的质量控制，必须着重在软件开发方面下功夫
• 软件没有机械磨损、老化问题，由退化问题，软件退化缘于修改
• 软件出故障：无法用备用零件替换来解决，是因为设计开发过程中存在错误
• 软件危机：开发、维护
• 软件危机原因：一方面是由于软件本身的特点，另一方面是由于软件开发与维护的方法不正确（软件需求分析的重要性）

软件工程

• NATO最先提出软件工程概念
• 软件工程是指导计算机软件开发和维护的一门工程学科（与软件危机对应）
• 软件工程方法学：方法、工具和过程
• 传统方法学VS面向对象方法学：

1. 传统方法学
   1. 优点：通过将软件生命周期划分成若干个阶段降低了整个软件开发过程的困难程度； 每个阶段结束前的严格审查保证了软件的质量，提高了软件的可维护性。
   2. 缺点：当软件规模庞大，或者对软件的需求是模糊的或会随时间而变化的时候，使用传统方法学开发软件往往不成功，而且维护起来仍然很困难。 原因：把原本密切相关的数据和操作人为地分离成了两个独立的部分，增加了软件开发与维护的难度。
2. 面向对象方法学
   1. 要点：把对象作为融合了数据及在数据上的操作行为的统一的软件构件； 把所有对象都划分成类； 按照父类与子类的关系，把若干个相关类组成一个类层次结构，位于下层的类继承了上层中某类的特点； 对象彼此间仅能通过发送消息互相联系。
   2. 优点：降低了软件产品的复杂性；提高了软件的可理解性；简化了软件的开发和维护工作；促进了软件重用

软件生命周期

• 软件生命周期由软件定义、软件开发和运行维护3个时期组成
• 软件定义：问题定义、可行性研究、需求分析
• 总体设计阶段：设计出实现目标系统的几种可能的方案，权衡利弊推荐一最佳方案
• 详细设计阶段：设计出程序的详细规格说明
• 编码和单元测试阶段
• 综合测试：集成测试/验收测试/现场测试/平行运行
• 改正性维护，适应性维护，完善性维护，预防性维护

第二章

软件过程1

• 瀑布模型：具有顺序性和依赖性，推迟实现，质量保证（文档）
  • 优点：可强迫开发人员采用规范的方法（例如，结构化技术）；严格地规定了每个阶段必须提交的文档；要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证；瀑布模型的成功在很大程度上是由于它基本上是一种文档驱动的模型文档驱动
  • ​​​​缺点：要求用户不经过实践就提出完整准确的需求，在许多情况下都是不切实际的；仅仅通过写在纸上的静态的规格说明，很难全面正确地认识动态的软件产品；将本来非线性的软件开发过程人为地加以线性化，不符合实际中的软件开发情况；软件开发耗时长，可运行版本要等到项目后期才能得到，一旦在后期发现错误，付出的代价将是巨大的。 “由文档驱动”的这个事实也是瀑布模型的一个主要缺点,这可能导致最终开发出的软件产品不能真正满足用户的需要
• V模型：强调测试活动与分析和设计之间的关联，活动驱动
  • 优点：把瀑布模型中一些隐含的迭代过程明确出来，使抽象等级的概念也更明显
  • 缺点：对软件开发过程过于简单、理想化的抽象，对需求变化的适应性差。
• 原型/快速原型模型：不带反馈环，线性顺序进行，有助于需求的定义和确认，可以考虑结合瀑布模型（瀑布模型在工程实践上有反馈环），二者互补性强，原型不可能像最终产品一样面面俱到

软件过程2

• 阶段式开发（演化模型）---尽快得到使用版本：渐增式开发，迭代式开发（螺旋式开发）
  • 增量模型：增量构件；第一个增量构件往往实现软件的基本需求，提供最核心的功能
    • 优点：适用于人员配备不充裕、不能在软件项目期限之前实现一个完全版本的软件的情况； 能有计划地管理技术风险； 每个增量都发布了一个高质量的可操作的版本，用户能在较短时间内使用上部分功能； 逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，减少一个全新的软件可能给客户带来的冲击。
    • 缺点：软件体系结构必须是开放的，使得每个新的增量构件能够无缝地集成到现有的软件体系结构中，增加了设计阶段的投入； 本身具有矛盾性，一方面要求开发人员把软件看作一个整体，另一方面要求开发人员把软件看作构件序列，且构件间彼此独立。需要开发人员协调这一矛盾。
  • 螺旋模型：使用原型及其他方法来尽量降低风险。可以把螺旋模型看作在每个阶段之前都增加了风险分析过程的快速原型模型。（制定计划，风险分析，实施工程，客户评估）
    • 优点：螺旋模型是对瀑布模型的发展，并由客户对阶段性产品做出评审，这对保证软件产品质量十分有利； 由于引入风险分析等活动，测试活动的确定性增强了； 螺旋模型最外层代表维护，开发与维护采用同样方式，使维护得到与开发同样的重视。
    • 缺点：主要适合内部开发，否则风险分析必须在签订合同前完成，或者争取客户的最大理解； 只适合大型软件项目的开发，否则，每个阶段的风险分析将占用很大一部分资源，增加成本； 对开发人员的风险分析能力是极大的考验，否则，模型将退化到瀑布模型，甚至更糟。
• 喷泉模型：面向对象，迭代和无缝，为避免使用喷泉模型开发软件时开发过程过于无序，应该把一个线形过程作为总目标； 面向对象范型本身要求经常对开发活动进行迭代或求精

软件过程RUP

• 迭代式开发，管理需求，使用基于构件的体系结构，可视化建模（UML），验证软件质量（质量评估），控制软件变更
• 
• 核心工作流：业务建模、需求、分析与设计、实现、测试、部署：生成目标系统的可运行版本，移交给用户、配置与变更管理：跟踪维护开发过程中Artifacts的完整性和一致性、项目管理：提供项目管理框架，为软件开发项目制定计划、人员配备、执行和监控等方面的使用准则，并为风险管理提供框架、环境：软件开发环境，包括过程管理和工具支持
• 工作阶段：
  • Inception（先启）：生命周期目标里程碑
  • Elaboration（精化）：生命周期架构里程碑
  • Construction（构建）：初始可操作性能里程碑
  • Transition（移交）：产品发布里程碑
• 整个项目开发过程由多个迭代过程组成。 每次迭代只考虑一部分系统需求。 每个迭代都是风险驱动的。 每个迭代都可以看作是一个“小型的瀑布模型”过程：以一个交付版本结束，其结果是一个增量，增加一些新的功能。每次迭代以不同的重点和强度访问核心工作流。
• 与螺旋模型相比
  • 相似：重复一系列组成系统生命周期的循环
  • 差异： RUP给出了每个阶段内的若干次迭代过程完成后交付的增量的具体要求，即四个阶段的里程碑；RUP详细阐述了不同阶段的不同迭代过程经历的九大核心工作流程中活动内容的重点和强度不同；RUP提供了对每次迭代过程中不同核心工作流程活动的并行化支持
  • 优点：用于指导需求不明确、不稳定的项目开发时具有更强的可操作性。
• 用例及用例驱动；用例是捕获需求的有效方法，用例驱动整个RUP过程；以架构为中心；在面向对象的分析设计中采用UML进行可视化建模；面向对象的设计与构件实现
• 优点：用例驱动、以架构为中心、迭代和增量； 具有二维迭代性，有利于降低风险、适应需求变化； 是可配置的，具有通用性；
• 缺点：在理想的项目开发环境下软件过程的一种完美模式； 未给出具体的剪裁、扩充等配置实施的方法准则。

敏捷过程

• 强调适应而非预测变化，以人为中心
• 价值观：个体和交互 胜过 过程和工具；可以工作的软件 胜过 面面俱到的文档；客户合作        胜过 合同谈判；响应变化 胜过 遵循计划
• 敏捷开发方法是一组轻量级开发方法的总称，包括很多具体的开发过程和方法。极限编程是敏捷过程中最富盛名的一个。
  • 极限编程有效实践：客户作为开发团队的成员，使用用户素材，短交付周期（每两周完成一次迭代），验收测试，结对编程，测试驱动开发，集体所有（程序代码属于整个开发小组，每个成员都有修改代码的权利，都对全部代码负责）
  • 持续集成（一日内多次集成，不断回归测试），可持续的开发速度（周工作时间不超过40小时，连续加班不超过两周），开放的工作空间，计划游戏，简单的设计，重构，使用隐喻（隐喻是把整个系统联系在一起的全局视图，描述系统如何运做，如何把新功能加入到系统中）
• 敏捷过程的特点（与RUP比较）
  • 生命周期
    • RUP：二维
    • 敏捷过程：一维（更快速、更敏捷+可持续性）
  • 人员
    • RUP：RUP中个体的职责是按照“角色”明确分工的，未给出个体间的地位关系
    • 敏捷过程：敏捷过程中各成员个体相互的地位关系是平等的，职责是共同的；个体间的首要协作交互方式为面对面的交谈
  • 方法
    • 敏捷过程：响应变化，使用UML，采用用例驱动方法和动态满足需求方法，设计阶段选择以架构为中心和简单化两种之一来实施
  • 产品
    • RUP：文档+模型
    • 敏捷过程：模型>文档
• 持续集成、持续交付与持续部署
  • 

微软过程

• 
• 软件生命周期：
  • 构思阶段——前景/范围认可里程碑
    • 确定项目前景和项目范围两个项目目标 动态满足需求——先基线化、后冻结
  • 计划阶段——项目计划认可里程碑
    • 以产品特性及其优先级指导整个项目
  • 开发阶段——范围完成里程碑
    • 代码优化：算法优化、高信度计算
    • 源代码管理：建立源代码的管理库
    • 每日编译生成
  • 稳定阶段——发布就绪认可里程碑
    • 零缺陷管理
    • 手工测试与自动测试结合
    • 内部测试与外部测试结合
  • 部署阶段——部署完成里程碑
• 相对RUP，微软过程可视为RUP的一个精简配置版本；相对敏捷过程，微软过程是它的一个扩充版本，扩充了其每个生命周期内的各阶段的具体运作流程。
• 角色划分（相互关系对等）：
  • 产品管理角色：对外的用户需求管理职能
  • 程序管理角色：项目组内部的综合管理职能
  • 开发角色
  • 测试角色
  • 用户体验角色
  • 发布管理角色
• 角色合并原则：项目组内的开发人员不能兼任其他角色，不要试图合并两个有明显利益冲突或制约关系的角色
• 
• 均衡三角形关系：进度、资源、功能与性能