软件工程导论Part1 Software Processes软件过程

Part1 Software Processes

Chap3 Software Process Structure

1. A Generic Process Model

2. Identifying a Task Set

A task set defines the actual work to be done to accomplish the objectives of a software engineering action.
A list of the task to be accomplished
A list of the work products to be produced
A list of the quality assurance filters to be applied

3. Process Patterns

• describes a process-related problem that is encountered during software engineering work,
• identifies the environment in which the problem has been encountered,
• suggests one or more proven solutions to the problem.

Process Pattern Types

• Stage patterns—defines a problem associated with a framework activity for the process.
• Task patterns—defines a problem associated with a software engineering action or work task and relevant to successful software
  engineering practice
• Phase patterns—define the sequence of framework activities that occur with the process, even when the overall flow of activities is iterative in nature.

CMMI(Capability Maturity Model Integration) 能力成熟度模型 软件过程模型示例

Chap4 Process Models

0. What is a Prescriptive Process Model?

又被称为：软件工程经验模型，软件开发模型等等。

The Framework Activities of a Prescriptive Process Model

• Communication

  Application Requirements determination，Software Requirements specification

• Planning
  Planning，estimation，scheduling

• Modeling
  Architectural design，Detailed design

• Construction：
  Implementation，Integration，Testing

• Deployment

1. The Waterfall Model & the V Model

1. communication
2. planning
3. modeling
4. construction
5. deployment

优点

1. 强调开发的阶段性
2. 强调早期计划及需求调查
3. 强调产品测试

缺点

瀑布模型过于依赖早期进行的唯一一次需求调查，不能适应需求的变化

瀑布模型是单一流程，开发中的经验教训不能反馈应用于本产品的过程

瀑布模型造成软件错误的积累和放大效应

V模型

相比于瀑布模型在于测试方面，单元测试 - 集成测试 - 系统测试 - 验收测试
将测试用例的设计提前了

2. Evolutionary Models

Evolutionary Models

Prototype 原型模型

快速建立原型从而便于根据需求快速修改

原型(prototype)分为三类：

1. 探索型 exploratory prototyping（弄清目标系统的要求）
2. 实验型 experimental prototyping（验证方案或算法的合理性）
3. 演化型 evolutionary prototyping（将原型作为目标系统的一部分最终演化成为目标系统）

原型特征：

1. 是一个切实可行的系统
2. 没有固定的生命期
3. 从需求分析到最终产品都可做原型
4. 必须快速廉价
5. 是迭代过程的集成部分，即每次经过用户评价后修改，运行，不断重复双方认可

原型的优点

能够弄清产品需求
项目早期能够获得一部分项目数据
可以鼓励开发者
客户参与验证并提供有效反馈
使得销售工作可以提早进行

原型的缺点

容易退化为边做边改
可能产生得过且过的想法
对沟通信心产生影响

The Spiral 螺旋模型

即在过程的各步骤进行需求分析

优点

强调严格的全过程风险管理
强调各开发阶段的质量
提供机会检讨项目是否有价值继续下去

缺点

必须引入非常严格的风险识别，风险分析和风险控制，这对风险管理的技能水平提出了很高的要求，也要求人员，资金时间的大量投入

Concurrent 并发

It is possible to use an evolutionary process to emphasize flexibility, extensibility, and speed of development 强调灵活性、可扩展性和开发速度。

Concurrent Process Model - The Big Picture

3. The Incremental Model

增量模型又称产品改进模型
从给定需求开始，通过构造一系列中间版本来实施开发活动，依次类推，直到系统完成。
每一个中间版本都是需求分析、设计、编码和测试的过程。
某些中间版本的开发可以并行进行

增量模型特征

融合了线性顺序模型的基本成分和原型的迭代特征。
是随着日程时间的进展而交错的线性序列。
与原型不一样的地方是强调每个增量均发布一个可操作产品。
最典型的应用是同一个产品的不同项目(合同、用户)版本

增量模型特别适用于：

• 需求经常变化的软件开发
• 市场急需而开发人员和资金不能在设定的市场期限之前实现一个完善的产品的软件开发

增量模型能有计划地管理技术风险，如早期增量版本中避免采用尚未成熟的技术

4. Other Process Models

Component based development—the process toapply when reuse is a development objective
Formal methods—emphasizes the mathematical specification of requirements
AOSD—provides a process and methodological approach for defining, specifying, designing, and constructing aspects

5. The Unified Process

• use-case driven
• architecture-centric
• iterative and incremental
• software process closely aligned with the Unified Modeling Language (UML)

初始 细化 构建 移交

RUP的时间轴被分解为四个顺序的阶段：

• 初始阶段(Inception)为系统建立业务案例并确定项目的边界。
• 细化阶段(Elaboration)分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素。
• 构造阶段(Construction)所有剩余的构件和应用程序功能被开发并集成为产品，所有的功能被详细测试。
• 交付阶段(Transition)确保软件对最终用户是可用的。

• RUP的优点：

提高了团队生产力，在迭代的开发过程、需求管理、基于组件的体系结构、可视化软件建模、验证软件质量及控制软件变更等方面，针对所有关键的开发活动为每个开发成员提供了必要的准则、模板和工具指导，并确保全体成员共享相同的知识基础。它建立了简洁和清晰的过程结构，为开发过程提供较大的通用性

• RUP的缺点

RUP在理论上，是比较理想的，但在实际应用上，还需要更多的工具的支持和普及推广工作

Chap5 Agile Development 敏捷开发

0. Manifesto for Agile Software Development 敏捷开发宣言

• Individuals and interactions over processes SSSand tools
• Working software over comprehensive documentation
• Customer collaboration over contractnegotiation
• Responding to change over following a plan

1. What is “Agility”?

• Effective (rapid and adaptive) response to change
• Effective communication among all stakeholders
• Drawing the customer onto the team
• Organizing a team so that it is in control of the work performed

Rapid, incremental delivery of software

3. An Agile Process

• Is driven by customer descriptions of what is required (scenarios)
• Recognizes that plans are short-lived
• Develops software iteratively with a heavy emphasis on construction
  activities
• Delivers multiple ‘software increments’
• Adapts as changes occur

4. Agility Priniciples

5. Extreme Programming (XP)

XP Planning

• Begins with the creation of user stories
• Agile team assesses each story and assigns a cost
• Stories are grouped to for a deliverable increment
• A commitment is made on delivery date
• A commitment is made on delivery date
• After the first increment project velocity (速度) is used to help define subsequent delivery dates for other increments

XP Design

• Follows the KIS principle(Keep It Simple)

• Encourage the use of CRC cards

• For difficult design problems, suggests the creation of spike solutions — a design prototype

  A spike solution is a very simple program to explore potential solutions. Build the spike to only addresses the problem under examination and ignore all other concerns. Most spikes are not good enough to keep, so expect to throw it away.

• Encourages refactoring 重构 — an iterative refinement of the internal program design

XP Coding

• Recommends the construction of a unit test for a story before coding commences (测试驱动编程)
• Encourages pair programming (结对编程)

XP Testing

• All unit tests are executed daily (强调DailyBuilding，冒烟测试)
• Acceptance tests are defined by the customer and executed to assess customer visible functionality (强调验收测试，回归测试)

6. Scrum

Scrum—distinguishing features

• Development work is partitioned into “packets”
• Testing and documentation are on-going as the product is constructed
• Work occurs in “sprints” and is derived from a “backlog” of existing requirements
• Meetings are very short and sometimes conducted without chairs
• “demos” are delivered to the customer with the time-box allocated

7. Kanban

Chap6 Human Aspects of Software Engineering

1. Traits of Successful Software Engineers

• Sense of individual responsibility
• Acutely aware of the needs of team members and stakeholders
• Brutally honest about design flaws and offers constructive criticism
• Resilient under pressure
• Heightened sense of fairness
• Attention to detail
• Pragmatic

2. Behavioral Model for Software Engineering

3. Software Teams

Team Leader

Team Roles

Effectiveness vs. Toxicity（毒性）

Team Structure

Agile Teams

4. Team Coordination & Communication