Post

软件开发过程

Posted
By lreverse
14 min read
软件开发过程

概述

黑盒过程

  • 需求稳定，不易变化 黑盒

白盒过程

  • 需求不稳定，需要不断获取反馈 白盒过程

软件过程模型

定义了软件开发的具体活动以及活动间的逻辑关系

瀑布模型

鲑鱼模型：向前一阶段回溯很难

遵循过程规律，按次序进行，上一个阶段结束，下一阶段才能开始，工作以线性的方式进行

  • 计划、需求分析、设计、编码、测试、运行维护

优点

  • 简单、易懂、快速
  • 为项目提供了按阶段划分的检查点，项目管理比较容易

缺点

  • 在开发早期，用户难以清楚地确定所有需求
  • 开发人员与用户之间缺乏有效的沟通
  • 在项目接近尾声的时候才能得到可执行的程序

增量过程模型

无须等到所有需求都出来才进行开发，只要某个需求的核心部分出来，即可进行开发

增量模型

本质：以迭代的方式运用瀑布模型

  • 第一个增量往往是核心产品：满足了基本的需求，但是缺少附加的特性
  • 客户使用上一个增量的提交物并进行评价，制定下一个增量计划，说明需要增加的特性和功能
  • 重复上述过程，直到最终产品产生为止

缺点

  • 每个附加的增量并入现有的软件时，必须不破坏原来已构造好的东西
  • 无法处理需求发生变更的情况
  • 管理人员须有足够的技术能力来协调好各增量之间的关系
RAD模型

快速应用开发

  • 侧重于短开发周期的增量过程模型，是瀑布模型的高速变体，通过基于构件的构建方法实现快速开发
  • 多个团体并行进行开发

优点

  • 充分利用企业已有资产进行项目开发
  • 提高软件交付速度

缺点

  • 需要大量的人力资源来创建多个相对独立的RAD团队
  • 如果系统不能被合理的模块化，RAD将会带来很多问题

演化过程模型

专门应对不断演变的软件过程模型

  • 本质：循环、反复、不断调整当前系统以适应需求变化
原型模型

抛弃式原型

  • 最初的原型在完成并得到用户认可之后，将不会作为交付给用户的最终系统的一部分，而是被抛弃，其目的只是为了收集与验证需求

演化式原型

  • 最初构造的原型将具备较高的质量，包含了系统的核心功能，然后通过收集需求对其进行不断的改善和精化

优点

  • 提高和改善用户的参与程度，最大程度地响应用户需求的变化

缺点

  • 没有考虑整体软件的质量和长期的可维护性，系统结构通常较差
  • 用户可能混淆原型系统与最终系统
迭代模型

每次迭代完成部分可确定的软件需求

优点

  • 每次迭代是一次完整的过程
  • 适合需求难导出，不易确定且持续变动的软件

缺点

  • 迭代次数不确定
  • 管理较为复杂
螺旋模型

沿着螺线旋转，在四个象限内表达四个方面的活动

  • 制定计划
    • 确定软件目标，选定实施方案，弄清项目开发的限制
  • 风险分析
    • 分析所选方案，考虑如何识别和消除风险
  • 实施工程
    • 实施软件开发
  • 客户评估
    • 评价开发工作，提出修正建议

缺点

  • 适用于大规模软件项目，周期长，成本高

敏捷开发

以快速的增量和迭代方式进行软件开发

变化是软件的本质，软件开发必须适应变化

  • 敏捷：有效地响应变化
  • 目标：快速、增量地发布软件

敏捷软件开发宣言：

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

准则：

  1. 尽早和持续地交付有价值的软件来满足客户
  2. 欢迎对需求提出变更
  3. 要不断交付可用的软件，周期越短越好
  4. 业务人员与开发人员必须在一起工作
  5. 要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务
  6. 最有效的沟通方法是面对面的交谈
  7. 可用的软件是衡量进度的主要指标
  8. 提倡可持续的开发
  9. 对技术的精益求精以及设计的不断完善将提升敏捷性
  10. 要做到简洁，尽最大可能减少不必要的工作
  11. 最佳的架构、需求和设计出自于自组织的团队
  12. 团队要定期反省如何能够做到更有效，并相应地调整团队的行为

敏捷开发方法

极限编程XP

把某件事情做到极致

  • 计划
    • 倾听顾客陈述，形成一组用户故事
    • 为每个用户故事指定优先级、成本
    • 将若干个用户故事指定为下一次发布的增量，确定发布日期
    • 规划整体进度
    • 顾客可以在开发过程中扩展新故事、去除原有故事、改变优先级、拆分等
  • 设计
    • 遵循KIS原则（Keep It Simple）
    • CRC卡片
    • 对设计方案不断重构
  • 编程
    • 在编码之前，根据用户故事设计单元测试用例
    • 结对编程：两人一起编程，实时讨论、实时评审
    • 测试驱动的开发（TDD）：先写测试用例，再写代码
  • 测试
    • 自动化单元测试
    • 持续集成
    • 持续进行回归测试
    • 验收测试
Scrum
  • Sprint：整个开发过程由若干个短的迭代周期组成，每个Sprint的建议长度是2到4周
    • 在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发
  • 产品Backlog：是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事
    • 使用产品Backlog来管理需求
  • 在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量

基本过程

  1. 找出完成产品需要做的事情（Product Backlog）
  2. 决定当前的冲刺需要解决的事情（Sprint Backlog）
  3. 冲刺Sprint
  4. 每日站会

任务墙、燃尽图

软件演化

  1. 新的需求不断出现
  2. 商业环境在不断变化
  3. 软件中的缺陷需要进行修复
  4. 计算机硬件和软件环境的升级需要更新现有的系统
  5. 软件的性能和可靠性需要进一步改进

现代版的西西弗斯和吴刚

Lehman定律

  • 持续变化
  • 复杂度逐渐增大
    • 热力学第二定律（熵值理论）

处理策略

  • 软件维护
    • 为了修改软件缺陷或增加新的功能而对软件进行的变更
    • 软件变更通常发生在局部，不会改变整个结构
  • 软件再工程
    • 为了避免软件退化而对软件的一部分进行重新设计、编码和测试，提高软件的可维护性和可靠性等

软件维护

  • 纠错性维护
    • 修改软件中的缺陷或不足
  • 适应性维护
    • 修改软件使其适应不同的操作环境，包括硬件变化、操作系统变化或者其他支持软件变化等
  • 完善性维护（比重大）
    • 增加或修改系统的功能，使其适应业务的变化
  • 预防性维护
    • 为减少或避免以后可能需要的前三类维护而提前对软件进行的修改工作
维护的内容
  • 程序维护
  • 数据维护
  • 硬件维护

软件的维护成本极其昂贵

遗留系统

“已经运行了很长时间的、对用户来说很重要的、但是目前已无法完全满足要求却不知道如何处理的软件系统”

  • 可行的解决方法：软件再工程

软件配置管理（SCM）

软件配置（software configuration）：由在软件工程过程中产生的所有信息项构成，它可以看作该软件的具体形态(软件配置项)在某一时刻的瞬间影像

SCM贯穿整个软件生命周期与软件工程过程

  • 配置项（CI）
  • 基线（Baseline）
  • 配置管理数据库（CMDB）
  • 备件库（DHS）
  • 最终软件库（DSL）
软件配置项SCI

具有唯一标识和多个属性

  • 计算机程序
  • 描述计算机程序的文档
  • 数据
基线

已经通过正式评审和批准的软件规格说明或代码，它可以作为进一步开发的基础，并且只有通过正式的变更规程才能修改它

  • 在软件配置项成为基线之前，可以迅速而随意的进行变更
  • 一旦成为基线，变更时需要遵循正式的评审流程才可以变更
配置管理数据库（CMDB）

用于保存于软件相关的所有配置项的信息以及配置项之间关系的数据库

  • 版本控制系统（VCS）
    • VSS、CVS、SVN、Git

VCS

  • 本地版本控制系统
  • 集中化版本控制系统
    • 有一个单一的集中管理的服务器，保存所有文件的修订版本
    • CVS，SVN
  • 分布式版本控制系统
    • Git
Course, 软件工程
This post is licensed under CC BY 4.0 by the author.