软件工程

过程模型

惯例过程模型(沟通,策划,建模,构建,部署)

  • 惯例过程模型
  • 瀑布模型
  • 增量模型
    1. 增量模型
    2. RAD模型
  • 演化过程模型
    1. 原型开发
    2. 螺旋模型
    3. 协同开发模型
  • 专用过程模型
  • 统一过程

  1. 瀑布模型 The Waterfall Model

    • 当需求确定,工作能够采用线性的方式完成的时候,瀑布模型是一个很有用的过程模型。
    • 经典生命周期,系统/顺序,线性特性。
  2. 增量过程模型 Incremental Process Models

    • 以迭代的方式运行瀑布模型。增量模型可以规避技术风险。
    • 增量模型发布一系列称为增量的版本,随着每个版本的交付,逐步为每个用户提供更多的功能。
    • 在项目既定的商业要求期限之前不可能找到足够的开发人员,这种情况之下增量模型显得特别有用。
  3. RAD模型 Rapid Application Development

    • 快速应用程序开发是一种侧重于短暂的开发周期的增量软件过程模型。
    • 瀑布模型的“高速变体”。
    • 严格的时间要求使得RAD项目必须具备“可伸缩范围”。
    • 适用于某个商业项目的每个主要功能都能3个月内完成。每个主要功能分配给一个独立的RAD团队,然后再集成一个整体。
  4. 演化过程模型 Evolutionary Process Models

    • 演化过程模型中,每次迭代产生软件的一个完整的版本。
    • 适用于严格的交付时间似的开发团队不可能圆满的完成软件产品,但必须交付功能有限的版本以应对竞争和商业压力;很好地理解了核心产品和系统需求,但是产品或系统拓展的细节问题却没有定义。
    • Evolutionary models are iterative. They are characterized in a manner that enables you to develop increasingly more complete versions of the software.In the paragraphs that follow, I present two common evolutionary process models.
  1. 原型开发 Prototyping

    • 快速设计产生一个原型,对原型进行部署,然后又客户或者用户进行评价。根据反馈,进一步细化软件的需求。
    • 适用于客户提出了软件的一些基本功能,但是没有详细定义输入/处理和输出需求;开发人员可能对算法的效率/操作系统的兼容性和人机交互的形式等情况不确定。
  2. 螺旋模型 The Spiral Model

    • 一种演进式软件过程模型,结合原型的迭代性质和瀑布模型的系统性和可控性特点。
    • 采用循环的方式逐步加深系统定义和实现的深度,同时降低风险;确定一系列里程碑,确保共利益者都支持可行的和令人满意的系统解决方案。
    • 螺旋模型是开发大型系统和软件的理想方法,螺旋模型把原型开发作为降低风险的机制,保留了瀑布模型(经典生命周期)中系统逐步细化的方法,(迭代框架)。
    • 螺旋模型要求在项目的所有阶段始终考虑技术风险。
  3. 协同开发模型 Concurrent Models

    • 协同模型可用于所有类型的软件开发,能够提供准确的项目当前状态图。
    • 定义一个活动的网络,网络中每个活动/动作和任务与其他活动/动作和任务同时存在。过程网络中某一点产生的事件可以触发状态的转换。
    • 协同模型更适合于不同的工程团队共同开发的系统工程项目。

敏捷开发

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
1. What is it?
Agile software engineering combines a philosophy and a set of development guidelines. The philosophy encourages customer
satisfaction and early incremental delivery of
software; small, highly motivated project teams;informal methods; minimal software engineering work products; and overall development simplicity. The development guidelines stress delivery over analysis and design (although these activities are not discouraged), and active and continuous communication between developers and customers.
2. Who does it?
Software engineers and other project stakeholders (managers, customers, end
users) work together on an agile team—a team
that is self-organizing and in control of its own destiny. An agile team fosters communication and collaboration among all who serve on it.
3. Why is it important?
The modern business environment that spawns computer-based systems and software products is fast-paced and everchanging. Agile software engineering represents a reasonable alternative to conventional software engineering for certain classes of software and certain types of software projects. It
has been demonstrated to deliver successful systems quickly.
4. What are the steps?
Agile development might best be termed “software engineering lite.” The basic
framework activities—communication, planning,
modeling, construction, and deployment—
remain. But they morph into a minimal task set
that pushes the project team toward construction and delivery (some would argue that this is done at the expense of problem analysis and solution design).
5. What is the work product?
Both the customer and the software engineer have the same view—the only really important work product is an operational “software increment” that is delivered to the customer on the appropriate commitment date.
6. How do I ensure that I’ve done it right?
If the agile team agrees that the process works, and the team produces deliverable software increments that satisfy the customer, you’ve done it right.

敏捷宣言

  • 2001年,Kent Beck和其他16位知名软件开发者/软件工程作家以及软件咨询师(被称为敏捷联盟)共同签署了“敏捷软件开发宣言”。

敏捷建模

  • 敏捷建模(Agile Modeling,AM),是一种用于对软件工程有效建模和文档化的时间方法学。

  • 提出大致的“核心”和“补充”的建模原则,但其中独具特色的是:

    • 有目的的建模。

    • 使用多个模型。

    • 前进灯。

    • 内容重于表述形式。

    • 理解模型及工具。

    • 适用本地需求。

敏捷过程模型

  • 所有敏捷过程模型(或多或少)都遵循敏捷软件开发宣言以及敏捷联盟定义的12条原则。

敏捷过程 :

  • 任何一个敏捷过程都可以由所强调的三个关键假设而识别出来。

    • 提前预测那些需求是稳定和那些需求会变化非常困难。同样,预测项目进行中客户优先级的变化也很困难。

    • 对很多软件来说,设计和构建是交错进行的。事实上,两种活动应当顺序开展以保证通过构建实施来验证设计模型,而在通过构建验证之前很难估计应该设计到什么程度。

    • 从制定计划的角度来看/分析/设计/构建和测试并不像我们所设想的那么容易预测。

ASD

  • 自适应软件开发,作为构建复杂软件和系统的一项技术,其基本概念着眼于人员协作和团队自我组织。ASD“生命周期”包括:思考/协作和学习三个阶段。使用迭代过程,该过程由自适应循环计划/相对严格的需求收集方法和一个迭代开发循环构成,其中迭代开发循环包括客户焦点组和正式技术评审作为实时反馈机制。

XP

  • 极限编程(eXtreme Programming,XP)。

  • XP使用面向对象方法作为推荐的开发范型。XP包括了策划/设计/编码和测试4个框架活动的规则和实践。

  • 极限编程过程:

    • 策划。策划活动开始于建立一系列描述待开发软件必要特征与功能的“故事”(也称为“用户故事”)。每个故事由客户书写并置于一张索引卡上,客户根据对应特征或功能的全局业务价值标明权值(优先级)。ps.一个故事的权值取决于其他相关故事的存在。

    • 设计。XP设计严格遵循KIS(Keep It Simple,简洁保持)原则,即使用简单而不是复杂的表述;不鼓励额外功能性设计;鼓励使用CRC作为有效机制;故事设计中遇到困难,推荐Spike解决方案;XP鼓励既是构建技术又是设计技术的“重构”。

    • 编码。XP推荐在故事开发和基本设计完成之后,开发一系列用于检测本次(软件增量)发布的包括所有故事的单元测试;XP编码活动中的关键概念之一是结对编程。

    • 测试。单元测试 回归测试策略 通用测试集 XP验收测试(客户测试)。

重构

  • 重构是以不改变代码外部行为而改进其内部结构的方式来修改软件系统的过程。这是一种净化代码【并秀瑷/简化内部设计】以尽可能减少引入错误的严格方案。简而言之,重构就是在编码完成之后改进代码设计。

结对编程

  • XP推荐/建议两个人面对同一台计算机共同为同一个“故事”开发代码。这一方案提供了实时解决问题和实时质量保证的机制,同时也使得开发者能够集中精力解决手头的问题。实施中不同成员担任的角色略有不同。 “连续集成” “冒烟测试”。

DSDM

  • 动态系统开发方法是一种提供“通过在可控项目环境中使用增量原型开发模式完全满足对时间有约束的系统的构建和维护”的敏捷软件开发方法。

  • 定义了三种迭代循环:

    • 功能模型迭代

    • 设计和构建迭代

    • 实现迭代

  • 可行性研究和业务研究两个传统的生命周期活动。

  • 倡导时间调度的使用,认为每一个软件增量所需的必要工作仅仅是能够方便的进入下一次增量开发。

FDD

  • 特征驱动开发,可用于中/大型软件项目的适应性敏捷开发过程。和其他敏捷方法相比,更加强调项目管理原则和技术。

Crystal

  • Crystal敏捷方法系列,其目的是发展一种提倡“机动性”的软件开发方法。可用于具有特定特征的项目。采用迭代策略,但可以调整过程的严格程度以适应不同规模和复杂度的项目。

Scrum

  • 一种敏捷过程模型,强调使用一系列“软件过程模型”,这些模式已被验证对时间紧迫/需求变化和业务重要的项目非常有效。每一个过程模型定义一系列开发任务并允许Scrum团队以适应期项目的方式构建过程。

  • 每一个过程模式定义了一系列开发活动:

    • 待定项

    • 冲刺

    • Scrum例会

    • 演示

敏捷性

敏捷原理

政策

团队特征


软件工程实践综述

  1. 实践的精髓

  2. 核心原则

  3. 沟通实践

  4. 策划实践

  5. 建模实践

    分析建模原则

    设计建模原则

  1. 构造实践

    编码原则和概念

    测试原则

  2. 部署


需求工程

需求工程任务

  • 起始(Inception)

  • 导出(elicitation)

  • 精化(elaboration)

  • 协商(negotiation)

  • 规格说明(specification)

  • 确认(validation)

  • 管理(management)