考试时间：35 min (5:35 - 6:10)

This is a revision note based on HKU Comp3297 Software Engineering

考试重点：

• 软件和软工的定义
• 开发的方法
• 软件工程师的道德守则，如何避免违反§
• 开发方式的流程和优点

L1 Introduction

软件工程的定义

• 软件工程的定义: an engineering discipline, all aspects of software production
  • 工程学科（用合适的理论和方法解决问题，考虑组织和财政方面的限制 appropriate theories and methods + organizational and financial constraints）
  • 软件相关各个阶段（软件开发，项目管理，系统说明，系统维护，系统使用……）
• 软件工程的重要性：
  • 个人和社会经济发展--> 需要可靠和值得信赖的系统 (trustworthy and reliable) The economies of ALL developed nations are dependent on software, more and more systems are software controlled
  • 降低长期成本 --> cheaper, in the long run, to use software engineering methods and techniques
• 软件工程包括：理论+方法+工具 Software engineering is concerned with theories, methods and tools for professional software development.
• 软件工程的成本：
  • 软件成本往往占据计算机系统成本的主导地位。个人电脑上的软件成本通常大于硬件成本。The costs of software are often greater than the hardware cost.
  • 软件的维护成本比开发成本更高。对于寿命较长的系统而言，维护成本可能是开发成本的数倍: maintenance costs may be several times development costs
  • 软件工程关注于成本效益的软件开发: concerned with cost-effective
• 软件工程的失败
  • 增加系统复杂性： 新的软件工程技术能够帮助建造更大和更复杂的系统，也能够更快的交付。 New SE techniques help us to build larger and more complex systems, and delivered more quickly
  • 没有使用软件工程的方法会使得软件更加昂贵和不可靠。more expensive and less reliable

Professional software development

• 软件是什么？
  • 计算机程序和文档 Computer programs and associated documentation
• 好软件的衡量标准（功能+性能）：
  • 功能functionality
  • 性能performance
    • 可维护性 Maintainability: 满足客户不断变化的需求，软件变更是不可避免的需求 software change is an inevitable requirement
    • 可靠性和安全性 Dependability and security: 可靠软件不应该在系统故障的情况下造成物理或经济上的损失。恶意用户不应该能够访问或破坏系统。reliability & security
    • Efficiency: 软件不应浪费系统资源，如内存和处理器周期。效率包括响应性、处理时间、内存利用率等。responsiveness, processing time, memory utilisation
    • Acceptability: 软件必须为其设计的用户类型所接受，即可理解的、可用的，同时考虑系统兼容。understandable, usable
• 软件产品的类型：
  • 通用类产品： 独立系统卖给任何有需要的顾客。如：预约系统、管理系统、作图软件 Stand-alone systems
  • 定制类产品：由特定的客户委托满足自己的需求。如： 嵌入式控制系统、交通指挥系统 specific customer to meet their own needs
• 产品说明 Product specification：
  • 功能性： what the software should do
  • 版权归属： Generic products are owned by the software developers； Customized products are owned by the customer
  • 软件变更：software change are made by the owners
• 软件开发过程
  1. Software specification: define the software that is to be produced and the constraints on its operation.
  2. Software development: softwareis designed and programmed.
  3. Software validation: checked to ensure that it is what the customer requires.
  4. Software evolution: modified to reflect changing customer and market requirements.
• 可能会影响软件开发的因素
  1. Heterogeneity 不同平台是否支持
  2. Business and social change
  3. Security and trust
  4. Scale
• 软件工程的开发方法和工具多样性
  • no universal set of software techniques
  • methods and tools used depend on:
    • type of application
    • requirements of customer
    • backgrounds of development team
• 软件的类型
  • Entertainment systems
  • Systems for modelling and simulation
  • Data collection systems: collect data from their environment using a set of sensors and send that data to other systems for processing.
  • Systems of systems: composed of a number of other software systems.
  • Stand-alone applications: run on a local computer without connecting to a network.
  • Interactive transaction-based applications: execute on a remote computer and accessed by users from their own PCs.
  • Embedded control systems: control and manage hardware devices.
  • Batch processing systems: process data in large batches.
• 软件工程的原则性共识： 理解需求，管理开发，尽可能复用代码，可靠和表现
  • Dependability and performance
  • Understanding and managing the software specification and requirements
  • reuse software rather than write new software.
  • managed and understood development process.

Software engineering ethics

• Confidentiality保密性
  • 无论是否签订保密协议 whether or not a formal confidentiality agreement has been signed.
• Competence能力
  • 不应误导他们的能力水平或者接受超出自己能力范围的工作 NOT misrepresent their level of competence.
• Intellectual Property (IP) rights知识产权
  • 保护知识产权，遵守当地法律；同时也应当保护雇主和客户知识产权 be aware of local laws governing the use of intellectual property such as patents, copyright, etc.
• Computer misuse计算机滥用
  • 计算机滥用范围从相对琐碎的行为（例如在雇主的机器上玩游戏）到极端严重的行为（例如传播病毒或其他恶意软件）NOT use their technical skills to misuse other people’s computers.

L2 Software Processes

Software process models

• Specification – defining what the system should do;
• Design and implementation – defining the organization of the system and implementing the system;
• Validation – checking that it does what the customer wants;
• Evolution – changing the system in response to changing customer needs.

Process activities

• Software process descriptions
  • activities
    • Products
    • Roles
    • Pre- and post-conditions
  • orders
• Different type of process
  • Plan-driven processes
    All of the process activities are planned in advance.
  • Agile processes
    Planning is incremental and it is easier to change the process to reflect changing customer requirements.
  • In practice, most practical processes include elements of both plan-driven and agile approaches.

Four basic process activities

Real software processes are inter-leaved sequences of technical collaborative and managerial activities. Four basic process activities are organized differently in different development processes:

• Software specification
  • Requirements engineering process
• development
  • Software design: 设计软件结构以及软件说明
  • Implementation: 将设计转化为可执行程序
    • 软件是通过开发或者配置系统实现的 developing & configuring
    • 编程是独立活动，没有标准程序 (no standard)
    • Debugging 是检查程序错误和更正的方式
  • 设计和实施是互相交互的 (Design and implementation are interleaved)
• validation
  • Verification and validation (V & V)： 显示系统符合其规范并满足系统客户的要求；包括检查和审查流程，以及系统测试。
  • 程序/系统测试涉及使用测试用例 (test cases)
  • 测试是最常使用的 V&V
• evolution
  • Software is inherently flexible and can change.

  

Software process models (a.k.a. Software Development Life Cycle or SDLC)

1. The waterfall model

   • 特点：
     • Plan-driven model.
     • Separate and distinct phases of specification and development.
   • 缺点
     • 主要问题：每个进程不可逆， 一个进程结束才能进入到下一个进程，很难适应客户的调整。Difficulty of accommodating change.
     • 后果：对于这种不灵活的方式，难以适应客户需求。只有充分理解客户需求才可以，例如嵌入式系统等等。过早冻结软件需求，会导致开发成本增加，开发时间增长，系统质量低下。
     • 理由：很少有需求稳定的商业系统
   • 优点
     • 主要用于大型large系统工程项目
     • 适合系统在多个地点several sites开发
     • 计划驱动能够帮助合作完成工作helps coordinate the work。

   

2. Incremental development

   • 特点：
     • May be plan-driven or agile.
     • 软件的各个开发环节都是交错进行的 Specification, development and validation are interleaved.
   • 优点：
     • 适应不断变化的客户需求的成本降低了，因为需要重做的分析和文档变少
     • 在开发过程中能够更容易的获得用户的反馈
     • 更快的交付变得可能；能够让客户更早的使用和创造价值。
   • 缺点：
     • 开发过程不可见 (not visible)：客户 <--> 经理 <--> 开发者模式下，经理需要定期交付 (regular deliverables) 来衡量进展；而对于一个开发较快的系统，生产文档来展示系统不同版本会显得效率低下 (not cost-effective)。
     • 当添加新的功能时，系统结构会趋于退化 system structure tends to degrade；因此，未来的软件变化会导致其变得更加困难和高成本 costly and difficult。

3. Integration and configuration

   • 特点：
     • May be plan-driven or agile.
     • The system is assembled from existing configurable components or application systems. (有时也称为 COTS)
     • 复用的元素可以进行配置 configured，以使它们的行为和功能适应用户的需求。
     • 复用 Reuse 已成为构建许多类型的业务系统的标准方法, 如： ERP
   • 可重复利用的软件种类：
     • 独立应用系统 (Stand-alone application systems):用于特殊环境
     • 组建:
       • 对象集合 (Collections of objects)
       • Web服务 (Web services)
   • 优点：
     • 减少的成本和风险 (Reduced costs and risks)
     • 快速的交付和部署 (Faster delivery and deployment)
   • 缺点：
     • 需求的妥协是不可避免，所以系统可以不能满足用户的实际需求 may not meet real needs of users
     • 对可复用系统元素的演化失去控制 Loss of control

   

Coping with change

• 变化是必然发生的 inevitable，如：新技术、商业变化，平台转换……

• Costs of Change = Rework + Implementing new functionality

• 减少重新工作的成本

  • 预期转换 (change anticipation): 例如，开发一个原型系统 (System prototyping) 来和客户确认关键特点 (key features)、需求 customer's requirements 和可行性 feasibility of design decisions
  • 接受度转换 (change tolerance)
    • 重构 (Refactoring)
    • 增量开发 (incremental development)
    • 增量交付 (incremental delivery)

• 软件原型 Software prototyping

  • 展示概念和设计, 如： UI (demonstrate concepts and try out design options)
  • 帮助需求获取和验证 (help with requirements elicitation and validation)
  • 可以省略功能
    • 重点讲解未理解充分的领域 focus on areas of the product that are not well- understood
    • 不涉及错误检查等
    • 重点在功能性演示 (functional)
  • 基于可以快速设计原型的语言和工具
  • 原型在开发后应该被丢弃
    • 调整系统以满足非功能性需求可能是不可能的；
    • 原型通常没有文档记录；
    • 原型结构通常会通过快速变更而降级；
    • 原型可能不符合正常的组织质量标准。

  

• 增量交付 (Incremental delivery)

  • 内容：
    • 与将系统作为单个交付项交付不同，开发和交付被分解成增量 increments，每个增量提供所需功能的一部分。
    • 用户需求被优先排序 (prioritised)，最高优先级的需求包含在早期增量中。
    • 一旦开始一个增量的开发，需求就被冻结，尽管后续增量的需求仍然可以继续演变。 (later increments can continue to evolve)
  • 优点：
    • 每个增量可以提供客户价值，因此系统功能可以更早地可用 (1. system functionality is available earlier.)
    • 早期增量充当原型，有助于引出后续增量的需求 (elicit requirements for later increments.)
    • 整体项目失败的风险较低
    • 最高优先级的系统服务是接受更多测试
  • 缺点：
    • 大多数系统需要一组基本设施，这些设施被系统的不同部分使用。
    • 迭代过程的本质是规范与软件一起开发。然而，这与许多组织的采购模型 (procurement model) 相冲突。

• 增量开发 (Incremental development)

  • 将系统分成若干增量，并在继续开发下一个增量之前评估每个增量
  • 敏捷方法 (Agile methods) 是常用的方法
  • 由用户/客户 (user/customer poxy) 代理进行评估

Process improvement

• The process maturity approach：专注于改进流程、项目管理，并引入良好的软件工程实践。这种方法的主要目标是提高产品质量和流程可预测性。

• 敏捷方法：专注于迭代开发和减少软件过程中的开销。敏捷方法的主要特点是功能的快速交付和对变化的客户需求的响应能力。

• improvement cycle:

  • Measure: one or more attributes & form a baseline
  • Analyze: Process weaknesses and bottlenecks are identified.
  • Change: Propose process changes

• 衡量方法

  • Time taken，如，开发周期
  • Resources required，如，人力资源需求
  • Number of occurrences， 如，缺陷数

L3 Agile Software Development

• Plan based: seperate development stages; each stages planned in advance
• Agile: Specification, design, implementation and testing are inter-leaved. The output is through a process of negotiation during the software development process. Iteration occurs across activities.

Agile methods

• 敏捷开发的原则
  1. 客户参与 （需求优先级设置，开发决策，系统评价）
  2. 增量交付 incremental delivery （增量开发，每次交付客户提出更多的需求）
  3. 注重人而非过程 (认识和剥削团队Recognize and exploit development team, 不受指令性原则的限制without prescriptive processes)
  4. 接受变化 Embrace change (需求变化的预期，设计系统去适应变化)
  5. 保持简单 (开发过程和软件的简化，消除系统复杂度)
• 敏捷开发的适用性
  • 中小型销售产品
  • 与组织开发，要明确： 客户参与开发过程； 较少外部规则影响软件开发

Agile development techniques

• 极限编程 Extreme Programming (XP)

  • 极端的迭代开发方法：

    • 可能每天构建多个新版本；
    • 每2周向客户交付增量；
    • 每次构建都必须运行所有测试，只有在测试成功运行的情况下才接受构建。
    

  • 极限编程例子:

    1. User stories for specification
       • 客户或用户是XP团队的一部分，负责对需求进行决策
       • 用户需求以用户故事或场景的形式表达
       • 开发团队将需求拆分为实施任务
       • 客户根据优先级和进度选择下一个版本中要包含的故事
    2. 重构 Refactoring（尽快改进代码，保持代码简单和易维护）
       • 在XP的理论里，不认为值得花费时间和精力去预测变化，而是它提出持续的代码改进（重构），以使变化在必须实施时更容易。
       • 即使没有立即需要，也会寻找可能的软件改进
       • 减少文档量
       • 改变使得代码结构优化清晰
       • 有些需要architecture refactoring的改变会很昂贵。
       • 重构场景： remove duplicate code, renaming attributes and methods, replacement of inline code with calls to methods
    3. 配对编程 Pair programming（开发人员成对工作，相互检查工作并提供支持）
       • 成组配对开发
       • 优点：
         • Common ownership
         • Spread knowledge
         • Informal review process
         • Encourage refactoring
    4. 测试优先开发 Test-first development
       • 先设计测试，后实现功能， 测试也是incremental的
       • 程序自动化测试
       • 以前的测试和新的测试都要自动运行来检测错误
       • 用户参与到检测过程
       • 问题： 很难判断是否所有的测试都已经完成；测试很难增量的编写

    其他还包括：

    • 增量规划Incremental planning（需求记录在故事卡上，根据可用时间和相对优先级确定，将故事拆分为开发任务）
    • 小型发布 Small releases（频繁发布系统并逐步增加功能）
    • 简单设计 Small design（设计足以满足当前需求，没有多余的设计）
    • 共同拥有 Collective ownership（开发人员一起工作系统的所有区域，所有开发人员承担责任，任何人都可以更改任何内容）
    • 持续集成 Continuous integration（将已完成的任务整合到整个系统中，通过单元测试）
    • 可持续节奏 Sustainable pace（大量加班是不可接受的，因为其净效果往往是降低代码质量和中期生产力）
    • 现场客户 On-site customer（团队中有终端用户/客户的代表全职可用）

  • 极限编程的实践

    • XP注重技术，并不容易与大多数组织的管理实践相结合

Agile project management - Scrum

• Scrum是专注于敏捷开发的管理方法，其主要分为三个阶段：

  • outline planning 概要规划
  • increments 一系列冲刺周期
  • warps up the projects 结束项目

• Scrum的开发周期 Scrum sprint cycle

  • 一般为2-4周

  

• Scrum团队的组成

  • Development team
  • Scrum master
  • Product owner

• Scrum的优点

  • manageable and understandable chunks
  • 不稳定的需求不会阻碍进展 not hold up progress
  • 整个团队都能看到所有内容visibility of everything，因此团队沟通得到改善。
  • 客户看到增量的准时交付on-time delivery，并获得产品运作情况的反馈 gain feedback。
  • 客户和开发人员之间建立了信任，并创造了一种积极的文化，每个人都期望项目取得成功。 Trust & positive culture

Scaling agile methods

• 敏捷方法已被证明对于小型和中型项目非常成功

• 扩展敏捷方法 Scaling agile methods涉及将其改变以应对更大、更长的项目，其中可能有多个开发团队，也许在不同的地点工作。(包括扩大系统和扩大组织 Scaling up & scaling out )

• 在扩展敏捷方法时，保持敏捷的基本原则至关重要：灵活的规划、频繁的系统发布、持续集成、测试驱动开发和良好的团队沟通。

• 敏捷开发的问题：

  • 敏捷开发的非正式性与大公司常用的合同定义法律方法不兼容。
    • sol: 需要一种支付开发人员时间而不是功能的合同。
  • 敏捷方法最适用于新软件开发，而不是软件维护。
    • sol: high-quality and readable code
    • sol: 保持开发团队连续性
  • 敏捷方法设计用于小型共同工作的团队，但现在许多软件开发涉及全球分布的团队。
    • sol: Multi-team Scrum

• 敏捷方法用于大型系统

  • System of systems: seperate teams develop each system
  • System configuration rather than code development；尽可能包含现有系统和交互
  • Regulatory constraints
  • 长时间采购，采购和开发时间长，难以维持连贯的团队
  • Diverse stakeholders：多元化的利益相关者，几乎不可能将所有这些不同的利益相关者纳入到开发过程中。
  • 问题：
    • 完全增量开发不可能
    • 不可能只有一个客户代表
    • 不能只专注于代码
    • 跨团队沟通机制
    • 持续集成不可能

All pictures are from Leo's lecturer PPT, please respect the copyright