1. Process

1.1 经验的（Empirical）和确定的（Defined）Process

1.2 Defined Process Control 确定的流程控制

1.3 Empirical Process Control 经验的流程控制

1.4 Empirical Process Control in Scrum

1.5 Defined v Empirical 经验的 V.S. 确定的

1.6 流程与项目管理和软件工程有什么关系？

2. 软件开发生命周期（SDLC）—— Formal

2.1 Software Development Life Cycle (SDLC)

2.2 Waterfall模型

2.3 Incremental模型

2.4 Formal模型

1. Process

1.1 经验的（Empirical）和确定的（Defined）Process

经验的过程控制期待意想不到的事情；确定的过程控制期望每一项工作在前期被完全理解。

1.2 Defined Process Control 确定的流程控制

Defined process control is a process with a well-defined set of steps. When we are in an environment with relatively low volatility that can be easily predicted; given the same inputs, a defined process should produce the same output every time based on its repeatability and predictability nature. The defined process has the following characteristics:

确定的流程控制是一个有一套明确步骤的流程。当我们处在一个波动性相对较低的环境中，可以很容易地预测；给定相同的输入，基于其可重复性和可预测性的性质，一个确定的流程每次都应该产生相同的输出。确定的流程具有以下特点：

Common and Control 共同和控制
Plan what you expect to happen 计划你所期望发生的事情
Enforce the plan, sometimes regardless of change condition 执行计划，有时不考虑变更条件
Use change control because change is expensive 变更控制，因为变更是昂贵的

1.3 Empirical Process Control 经验的流程控制

In empirical process control, you expect the unexpected. With defined process control, every piece of work is understood. In Scrum, an empirical process is implemented where progress is based on observation and experimentation instead of detailed, upfront planning and defined processes. Using empirical process control is working in a fact-based, experience-based, and evidence-based manner that control is exercised through inspection, adaptation. The Empirical Process Control has the following characteristics:

在经验性的流程控制中，你期待着意外的发生。在定义的流程控制中，每一项工作都被理解。在Scrum中，经验性流程的实施是基于观察和实验的，而不是详细的、前期的计划和确定的流程。使用经验流程控制是以事实为基础，以经验为基础，以证据为基础的工作方式，通过检查、适应来进行控制。经验性流程控制具有以下特点：

Learn as we progress 在进步中学习
Expect and embrace change 期待并接受变化
Inspect and adapt using short development cycles 使用短的开发周期进行检查和调整
Estimates are indicative only and may not be accurate 估计数仅是指示性的，不一定准确

1.4 Empirical Process Control in Scrum

在Scrum中，经验流程控制的实现依赖于透明（Transparency）、检查（Inspection）和适应（Adaptation）这三个主要的想法。

Transparency 透明度

Transparency ensures that aspects of the process that affect the outcome must be visible to those managing the outcomes. Not only must these aspects be transparent, but also what is being seen must be known. That is, when someone inspecting a process believes that something is done; it must be equivalent to their definition of done.

透明度确保流程中影响结果的各个方面必须让管理结果的人看到。不仅这些方面必须是透明的，而且被看到的东西也必须是已知的。也就是说，当检查流程的人认为某件事情已经完成；它必须等同于他们对完成的定义。

Inspection 检查

The various aspects of the process must be inspected frequently enough so that unacceptable variances in the process can be detected. The frequency of inspection has to take into consideration that all processes are changed by the act of inspection. A conundrum occurs when the required frequency of inspection exceeds the tolerance to inspection of the process. Fortunately, this doesn’t seem to be true of software development. The other factor is the skill and diligence of the people inspecting the work results.

必须对流程的各个方面进行足够频繁的检查，以便能够发现流程中不可接受的差异。检查的频率必须考虑到所有流程都因检查行为而改变。当要求的检查频率超过流程的检查容忍度时，就会出现一个难题。幸运的是，软件开发似乎并不存在这种情况。另一个因素是检查工作结果的人的技能和勤奋。

Adaptation 适应

If the inspector determines from the inspection that one or more aspects of the process are outside acceptable limits, and that the resulting product will be unacceptable, the inspector must adjust the process or the material being processed. The adjustment must be made as quickly as possible to minimize further deviation.

如果检查员从检查中确定流程的一个或多个方面超出了可接受的限度，并且由此产生的产品将是不可接受的，检查员必须调整流程或正在加工的材料。调整必须尽快进行，以尽量减少进一步的偏差。

1.5 Defined v Empirical 经验的 V.S. 确定的

对于做汉堡这种任务来说步骤是确定的，只需要按照步骤来做就可以完成汉堡的制作。

而对于飞机从一个目的地到达另一个目的地的任务来说，中途可能会遇到一些未知的情况，例如遇到雷云，它可以选择从左绕也可以选择从右绕。

1.6 流程与项目管理和软件工程有什么关系？

项目管理是一个process，因为它定义了一系列的任务（计划、执行和控制），以交付一个特定的/一组商定的结果。

系统开发生命周期（System Development Lifecycle——SDLC）是软件工程中的一个术语。它描述了一个规划、创建、测试和部署信息系统的过程。SDLC可以只由硬件组成，也可以只由软件组成，或者两者的组合。

2. 软件开发生命周期（SDLC）—— Formal

2.1 Software Development Life Cycle (SDLC)

系统开发生命周期（SDLC），也被称为应用程序开发生命周期，是系统工程、信息系统和软件工程中的一个术语，用于描述规划、创建、测试和部署一个信息系统的流程。

SDLC中的活动：

Requirements gathering 需求收集

Systems / Architectural Design 系统/架构设计

Implementation / Coding / Integration 实施 / 编码 / 集成

Testing 测试

Evolution 发展：
Delivery and Release - Deployment 交付和发布——部署

Maintenance 维护

有许多SDLCs，组织通常倾向于正式和敏捷的混合方法。

Formal和Agile是两类概念。

Waterfall，Incremental和V-Model是Formal概念下的三种模型。

Scrum，Kanban和Extreme Programming是Agile概念下的三种模型。

2.2 Waterfall模型

温斯顿-罗伊斯在1970年提出了瀑布模型。这个模型有五个阶段。需求分析和规范，设计，实现，和单元测试，集成和系统测试，以及部署和维护。这些步骤总是按照这个顺序进行，没有重叠。开发者必须在下一阶段开始之前完成每个阶段。这个模型被命名为 "瀑布模型"，因为它的图示类似于瀑布的层层叠叠。

1. 需求分析和规范阶段

这个阶段的目的是了解客户的确切要求，并正确地记录这些要求。客户和软件开发人员一起工作，以记录软件的所有功能、性能和接口要求。在这一阶段，将创建一个名为 "软件需求规范（SRS）"的大文件，其中包括用通用语言详细描述系统将做什么。

2. 设计阶段

这个阶段的目的是将SRS中收集到的需求转化为一种合适的形式，以便进一步用编程语言进行编码。它定义了整体的软件结构，以及高水平和详细的设计。所有这些工作都被记录为软件设计文件（SDD）。

3. 实施和单元测试

在这个阶段，设计被实施。如果SDD是完整的，实施或编码阶段就会顺利进行，因为软件开发人员需要的所有信息都包含在SDD中。

在测试过程中，代码被彻底检查和修改。最初对小模块进行孤立的测试。之后，这些模块通过编写一些开销代码进行测试，以检查这些模块之间的互动和中间输出的流程。

4. 集成和系统测试

这个阶段是非常关键的，因为最终产品的质量是由所进行的测试的有效性决定的。更好的输出将导致客户的满意，降低维护成本和准确的结果。单元测试决定了各个模块的效率。然而，在这个阶段，模块之间的相互作用以及与系统的相互作用都要进行测试。

5. 运行和维护阶段

维护是指在软件交付给客户、安装并运行后，由每个用户执行的任务。

什么时候使用SDLC瀑布模型？

最适合使用瀑布模型的一些情况是：

When the requirements are constant and not changed regularly. 当需求是恒定的，不经常改变时。

A project is short 项目时间短

The situation is calm 情况平稳

Where the tools and technology used is consistent and is not changing 使用的工具和技术是一致的，没有变化

When resources are well prepared and are available to use. 当资源准备充分并可供使用时。

优势

Lecture

Simple and easy to understand and use 简单、容易理解和使用

Easy to manage due to the rigidity of the model 由于模型的刚性，易于管理

Phases are processed and completed one at a time 各个阶段逐一处理和完成

Documentation available at the end of each phase 每个阶段结束时都有文件可查

Works well for projects where requirements are very well understood and remain stable对于需求非常了解并保持稳定的项目，效果很好

资料

This model is simple to implement also the number of resources that are required for it is minimal. 这种模式实施起来很简单，而且所需的资源数量也很少。

The requirements are simple and explicitly declared; they remain unchanged during the entire project development. 要求是简单和明确的，它们在整个项目开发过程中保持不变。

The start and end points for each phase is fixed, which makes it easy to cover progress. 每个阶段的开始和结束点是固定的，这使得它很容易涵盖进度。

The release date for the complete product, as well as its final cost, can be determined before development. 完整产品的发布日期，以及它的最终成本，可以在开发前确定。

It gives easy to control and clarity for the customer due to a strict reporting system. 由于有严格的报告制度，它给客户提供了易于控制和清晰的信息。

缺点

Lecture

Difficult to accommodate change after the process in underway 流程开始后很难适应变化

One phase must be completed before moving on to the next 在进入下一阶段之前必须完成一个阶段的工作

Unclear requirements lead to confusion 不明确的要求会导致混乱

Clients approval is in the final stage 客户的批准是在最后阶段

Difficult to integrate risk management due to uncertainty 由于不确定性，难以纳入风险管理

资料

In this model, the risk factor is higher, so this model is not suitable for more significant and complex projects. 在这个模型中，风险系数较高，所以这个模型不适合于比较重要和复杂的项目。

This model cannot accept the changes in requirements during development. 这个模型不能接受开发过程中需求的变化。

It becomes tough to go back to the phase. For example, if the application has now shifted to the coding phase, and there is a change in requirement, It becomes tough to go back and change it. 回归阶段变得很艰难。例如，如果应用程序现在已经转移到了编码阶段，而需求有了变化，再回去改变它就变得很困难。

Since the testing done at a later stage, it does not allow identifying the challenges and risks in the earlier phase, so the risk reduction strategy is difficult to prepare. 由于测试是在后期完成的，它不允许识别早期阶段的挑战和风险，所以很难准备减少风险的策略。

2.3 Incremental模型

在增量模型中，整个需求被划分为不同的版本。多个周期发生，使生命周期成为一个多瀑布周期。循环被划分为更小的、更容易管理的模块。

增量模型是一个软件开发的过程，在这个过程中，需求被分为软件开发周期的多个独立的模块。在这个模型中，每个模块都要经历需求、设计、实现和测试阶段。每个模块的后续版本都会在前一个版本的基础上增加功能。这个过程一直持续到完整的系统实现。

增量模型的各个阶段如下：

1. 需求分析

在增量模型的第一阶段，产品分析专家确定了需求。并由需求分析小组了解系统功能需求。为了在增量模式下开发软件，这个阶段起着至关重要的作用。

2. 设计和开发

在SDLC增量模式的这一阶段，系统功能的设计和开发方法已经成功完成。当软件开发出新的实用性时，增量模型采用风格和开发阶段。

3. 测试

在增量模型中，测试阶段检查每个现有功能的性能以及附加功能。在测试阶段，使用各种方法来测试每个任务的行为。

4. 实施

实施阶段是开发系统的编码阶段。它涉及到设计和开发阶段的最终编码，并在测试阶段测试功能。在这个阶段完成后，产品的工作数量得到加强，并升级到最终的系统产品。

我们什么时候使用增量模式？

When the requirements are superior. 当需求（规模）更大时。

A project has a lengthy development schedule. 一个项目有一个很长的开发时间表。

When Software team are not very well skilled or trained. 团队没有很好的技能或训练。

When the customer demands a quick release of the product. 客户要快速发布产品时。

You can develop prioritized requirements first. 你可以先开发有优先权的需求。

优势——与标准瀑布式相比

Lecture

Each release delivers an operational product 每个版本都提供一个可操作的产品

Less costly to change the scope/requirements 改变范围/要求的成本较低

Customers can respond to each build 客户可以对每个版本作出反应

Initial product delivery is faster 最初的产品交付更快

Customers get important functionality early 客户可以尽早获得重要的功能

Easier to test and debug during smaller iterations 在较小的迭代过程中更易测试和调试

资料

Errors are easy to be recognized. 错误容易被识别。

Easier to test and debug 更容易测试和调试

More flexible. 更加灵活。

Simple to manage risk because it handled during its iteration. 简单地管理风险，因为它在其迭代过程中处理。

The Client gets important functionality early. 客户尽早得到重要的功能。

缺点——与标准瀑布式相比

Lecture

More resources may be required 可能需要更多的资源

More management attention is required 需要更多的管理层关注

Defining / partitioning the increments is difficult and often not clear 定义/划分增量是困难的，往往不明确

Each phase of an iteration is rigid with no overlaps 迭代的每个阶段都是刚性的，没有重叠。

Problems may occur at the time of final integration 在最终整合时可能会出现问题

资料

Need for good planning 需要良好的规划

Total Cost is high. 总成本很高。

Well defined module interfaces are needed. 需要定义好的模块接口。

2.4 Formal模型

Formal模型有意义的特点：

Projects where the customer has a very clear view of what they want 客户对其需求有非常明确的看法的项目

Projects that will require little or no change to requirements 需要很少或不需要改变需求的项目

Software requirements are clearly defined and documented 软件需求被清楚地定义和记录

Software development technologies and tools are wellknown 软件开发技术和工具是众所周知的

Large scale applications and systems developments 大规模的应用和系统开发

软件流程和管理（二）：SDLCs — Process Formal相关推荐

软件流程和管理（八）：质量管理
目录 1. 质量管理的基本原理 1.1 什么是质量? 1.2 什么是软件质量? 1.3 质量的成本 2. 质量管理流程 2.1 Quality assurance 质量保证 2.1.1 Verific ...
软件流程和管理（十）：配置管理
目录 1. 了解配置管理的作用 1.1 什么是软件配置? 1.2 配置管理的作用 2. 了解 configuration management process 配置管理过程 2.1 CM Proce ...
软件流程和管理（一）：软件管理概述
目录 1. 项目管理的方法和标准 1.1 Waterfall 1.2 Agile 1.3 结构化的项目管理方法,如编辑等 1.4 选择合适的项目管理方法 2. 项目的成功与失败 2.1 导致成功的因 ...
软件流程和管理（一）：什么是项目
目录 1. 什么是项目 1.2 为什么组织要使用项目 2. 什么是项目管理 2.1 项目管理的价值 3. 项目经理技能/属性 3.1 项目经理的核心技能/特质 3.2 项目经理的主要活动(传统) 3. ...
软件流程和管理（九）：外包，合同和采购
目录 1. Outsourcing 外包 1.1 什么是外包 1.2 为什么外包? 2. Procurement 采购 2.1 The Procurement Management Process 采 ...
软件流程和管理（五）：Project Scheduling
目录 1. The role of a project schedule 项目进度表的作用 1.1 Project Schedule 的定义 1.2 Project Schedule 的内容 1.3 ...
软件流程和管理：Tutorial汇总
目录第一个项目管理流程:initialization 初始化 Project Analysis Waterfall Incremental V-Model Agile SDLC Summary Ag ...
软件流程和管理（七）：个人、激励和团队
目录 1. Individuals and Motivation 个人与动机 2. Organisational Theory & Motivation 组织理论与激励 2.1 Maslow ...
软件流程和管理（三）：Risk Management
目录 1. 理解风险管理的基本原理 1.1 Risk vs Uncertainty 1.2 为什么要进行正式的风险管理 2. 理解风险管理流程 3. Risk Management Planning ...

软件流程和管理（二）：SDLCs — Process Formal

1. Process

1.1 经验的（Empirical）和确定的（Defined）Process

1.2 Defined Process Control 确定的流程控制

1.3 Empirical Process Control 经验的流程控制

1.4 Empirical Process Control in Scrum

1.5 Defined v Empirical 经验的 V.S. 确定的

1.6 流程与项目管理和软件工程有什么关系？

2. 软件开发生命周期（SDLC）—— Formal

2.1 Software Development Life Cycle (SDLC)

2.2 Waterfall模型

2.3 Incremental模型

2.4 Formal模型

软件流程和管理（二）：SDLCs — Process Formal相关推荐

最新文章

热门文章