【软件工程】知识点总结（上）

过程定义了运用方法的顺序，应该交付的文档资料，为保证软件质量和协调变化所需要采取的管理措施，以及标志软件开发各个阶段任务完成的里程碑。实际从事软件开发工作时，软件规模、类型、开发环境及技术方法等因素会影响到阶段划分，及各阶段的执行顺序，形成不同生存周期模型，又称过程模型。通常使用生命周期模型简洁地描述软件过程。

2、几种软件生命周期模型

（1）瀑布模型

1）瀑布模型的开发阶段严格按照线性方式进行，每一个阶段具有相关的里程碑和交付产品，且需要确认和验证。

2）瀑布模型的特点

①阶段具有顺序性和依赖性

前一阶段结束后一阶段开始，前一个阶段输出文档，后一个阶段输入文档。

②推迟实现观点

瀑布模型在编码前设置系统分析、系统设计，推迟程序物理实现，保证前期工作扎实。

③质量保证观点

瀑布模型每阶段坚持两个重要做法：一是每阶段都必须完成完整、准确的文档。软件开发时人员间通信、运行时期维护的重要依据。二是每阶段结束前对文档评审。

3）带反馈的瀑布模型图

传统瀑布模型过于理想化，但人在工作测试过程中不可能不犯错误，所以实际瀑布模型带反馈环。

4）瀑布模型的优缺点

①优点：

严格地规定了每个阶段必须提交的文档；

每个阶段交出的所有产品都必须经过质量保证小组的仔细验证；

可强迫开发人员采用规范的方法；

②缺点：

在可运行的软件产品交付给用户之前，用户只能通过文档来了解产品是什么样的；

客户必须能够完整、正确和清晰地表达他们的需求；开发人员一开始就必须理解需求。

5）使用场景：需求能被很好的定义和确认

（2）快速原型模型

1）快速原型模型图

快速原型的基本思想是快速建立一个能反映用户主要需求的原型系统，让用户在计算机上试用它，通过实践来了解目标系统的概貌。通常，用户试用原型系统之后会提出许多修改意见，开发人员按照用户的意见快速地修改原型系统，然后再次请用户试用……反反复复地改进，直到原型系统满足用户的要求。

2）快速原型优缺点

a、快速原型模型的优点：通过原型准确获取用户需求，在开发过程的后续阶段不会因为前期需求错误而进行较大的返工；开发人员通过原型系统已经知道系统应该做什么，因此设计和编码阶段发生错误的可能性比较小。克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果软件产品的开发基本上是线性顺序进行的。每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。

b、快速原型模型的缺点：在快速原型开发过程中，没有经过严谨的系统设计和规划，可靠性和性能都难以保障。让客户觉得开发成本很低。

原型的处理：抛弃策略；附加策略

（3）增量模型（渐增模型）

1）瀑布和快速原型模型是一次把满足所有需求产品提交给用户，而增量模型是分批向用户提交产品

2）风险更大的增量模型：确定用户需求后，各构件集并行构建

3）增量模型的优点

①具有瀑布模型的所有优点

②将待开发的软件系统模块化，分批次的提交软件产品，使用户可以及时了解软件项目的进展。

③第一个可交付版本所需要的成本和时间是很少的，由于很快发布了第一个版本，因此可以减少用户需求的变更

④开发顺序灵活

4）适用于具有以下特征的软件开发项目

①待开发的软件系统能够被模块化。

②软件产品可以分批次的进行交付。

③软件开发人员对应用领域不熟悉，难以一次性的进行系统开发。

④项目管理人员把握全局的水平较高。

（4）迭代（演化）模型

1）是一种弹性的开发模式，由一些小的开发步组成，每一步历经需求分析、设计、实现和验证，产生软件产品的一个增量。通过这些迭代，完成最终软件产品的开发。

①针对事先不能完整地定义需求的软件开发

②针对用户的核心需求，开发核心系统

③根据用户的反馈，实施活动的迭代

2）主要特征

该模型显式地把增量模型扩展到需求阶段。由图可以看出，为了第二个构造增量，使用了第一个构造增量来精化需求。这一精化可以有多个来源和路径：首先，如果一个早期的增量已向用户发布，那么用户会以变更要求的方式提出反馈，以支持以后增量的需求开发。第二，通过实实在在地开发一个构造增量，为以前还没有认识到的问题提供了可见性，以便实际地开始这一增量的工作。

3）与瀑布模型的关系：在演化模型中，仍然可以使用瀑布模型来管理每一个演化的增量。一旦理解了需求，就可以像实现瀑布模型那样开始设计阶段和编码阶段。

4）使用演化模型应注意的问题

不能弱化需求分析阶段的工作。其原因是：在项目开始时，需要考虑所有可能需求源的重要性和风险，并对这些需求源的可用性进行评估，有这样才能识别和界定不确定的需求，并识别第一个增量中所包含的需求。

5）演化模型的长处和不足

其长处与增量模型是类似的但还具有以下

优点：在需求不能予以规约时，可以使用这一演化模型。用户可以通过运行系统的实践，对需求进行改进。与瀑布模型相比，需要更多用户/获取方的参与。

不足有：演化模型的使用需要有力的管理。。演化模型的使用很容易成为不编写需求或设计文档的借口，即使很好地理解了需求或设计。用户/获取方不易理解演化模型的自然属性，因此当结果不够理想时，可能产生抱怨。

增量模型和迭代模型有什么区别?

上图是增量：

下图是迭代：

（5）螺旋模型

1）螺旋模型是一种用于风险较大的大型软件项目开发的过程模型。该模型将瀑布模型与快速原型模型结合起来，并且加入了这两种模型忽略了的风险分析。它把开发过程分为制定计划、风险分析、实施工程和客户评估4种活动。

2）螺旋模型沿着螺线进行若干次迭代，每迭代一次，螺旋线就比前一周开发出更完善新版本：

①制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；

②风险分析：分析评估所选方案，考虑如何识别和消除风险；

③实施工程：实施软件开发和验证；

④客户评估：评价开发工作，提出修正建议，制定下一步计划。

3）螺旋模型的优缺点

①优点：将风险分析扩展到各个阶段中，大幅度降低了软件开发的风险，对大型软件开发项目有较好的风险控制；，有助于把软件质量作为软件开发的一个重要目标；减少了过多测试或测试不足所带来的风险；在维护和开发之间并没有本质区别。

②缺点：需要风险评估的经验和专门的知识：风险分析也需要费用增加软件开发的成本

4）使用场景：一般大型项目才有较高的风险，才有进行详细风险分析的必要。因此，这种模型比较适合大型的软件项目

（6）喷泉模型

1）喷泉模型是一种过程模型，同时也支持面向对象开发，主要用于面向对象的软件项目进一步开发体现迭代和无缝特性。

①迭代：求精，系统某部分常被重复工作多次，相关功能在每次迭代中逐渐加入演进系统。

②无缝：分析、设计、编码各阶段间不存在明显边界。

2）喷泉模型优缺点

①优点：无缝，可同步开发，提高开发效率，节省开发时间，适应面向对象软件。

②缺点：可能随时加各种信息、需求与资料，需严格管理文档，审核的难度加大。

（7）Rational统一过程

1）统一软件开发过程(Rational Unified Process， RUP)模型是基于UML（统一建模语言）的一种面向对象软件开发模型。集中了多个软件开发模型的优点，它采用迭代和增量递进的开发策略

•RUP是一个通用的过程框架，可以用于各种不同类型的软件系统、各种不同的应用领域和不同规模的项目。

•RUP的突出特点是由用例驱动，以架构为核心，采用迭代和增量的开发策略

2）每次迭代只考虑系统的一部分需求，针对这部分需求进行分析、设计、实现、测试和部署等工作，每次迭代都是在系统已完成的部分的基础上进行的，每次给系统增加一些新的功能，如此循环往复下去，直至完成最终项目。

a、初始阶段实现过程如下:

①明确项目规模，确定项目边界，制订验收标准，了解环境、主要需求及约束条件，识别关键用例。

②评估项目风险

③评估项目进度、人员配备、成本，制订项目计划。

④阶段技术评审，检查初始阶段的目标是否完成，并决定项目是继续进行还是取消。

b、细化阶段实现过程如下：

①确定架构

②制订构建阶段计划，并建立基线

③建立支持环境，包括开发环境、开发流程等

④选择构件

⑤阶段技术评审，检验系统目标和范围，架构选择，风险解决方案等

c、构建阶段

开发所有剩余的构件和应用程序功能，把这些构件集成为产品，并进行详细测试。本阶段的开发工作，尽量拆分构件开发，并行进行。阶段结束时进行技术评审，评审产品是否可以进行 beta测试。

d、移交阶段

本阶段重点是确保软件对最终用户是可用的。需要进行beta测试，制作发布版本，文档定稿，人员培训，收集反馈等。技术评审评审目标是否已实现，用户是否满意，有无必要开启新一轮迭代和演化。

3）螺旋模型和RUP的区别

• RUP 每次迭代包含9个核心工作流程，而螺旋模型只包含4方面的活动

•RUP对每个阶段内若干次迭代过程完成后所交付增量的具体要求，而螺旋模型没有规定。

•RUP 详细描述了不同阶段不同迭代过程在经历9个核心工作流程时活动内容的重点和强度，而螺旋模型没有规定。

RUP 的二维迭代生命周期结构对“迭代”开发方式的体现比螺旋模型更深刻、具体、详尽和全面，用于指导需求不明确、不稳定的项目开发，具有更强的可操作性。

4）Rationa1统一过程优点

①不断的版本发布成为一种团队日常工作的真正驱动力；

②将发现问题、制定方案和解决过程集成到下一次迭代；

③迭代开发，降低风险；

④更好地安排产品开发的辅助过程；各种软件开发模型的对比

（8）各种软件开发模型的对比

（1）

瀑布模型	经典，需求变化不大
快速原型模型	快速获取用户需求
增量模型	灵活，允许软件变化
螺旋模型	加入风险
喷泉模型	典型面向对象开发模型
统一过程模型	基于 UML的OO过程模型

2）

模型名称	技术特点	适用范围
瀑布模型	简单，分阶段，阶段间存在因果关系，各阶段完成后都有评审，允许反馈，不支持用户参与，要求预先确定需求。	需求易于完善定义且不易变更的软件系统
快速原型模型	不要求需求预先完备定义，支持用户参与，支持需求的渐进式完善和确认，能后适应用户需求的变化。	需求复杂、难以确定、动态变化的软件系统
增量模型	软件产品是被增量式一块一块开发的，允许开发活动并行和重叠。	技术风险较大、用户需求较为稳定的软件系统。
迭代模型	不要求一次性地开发出完整的软件系统，将软件开发视为逐步获取用户需求，完善软件产品的过程。	需求难以确定、不断变更的软件系统。
螺旋模型	结合瀑布模型、快速原型模型和迭代模型的思想并引入了风险分析活动。	需求难以获取和确定、软件开发风险较大的软件系统。
统一软件开发过程RUP	可改造、扩展和剪裁、可以对他进行设计、开发、维护和发布，强调迭代开发。	复杂和需求难以获取和确定的软件系统，软件开发项目组拥有丰富的软件开发和管理经验。

第三章：敏捷开发方法

1.1 敏捷方法概述

1、软件开发之道

（1）传统的软件开发模式：以预测性为原则；以文档驱动为开发过程；以过程控制为核心

（2）如今的开发过程更侧重于：弹性的开发管理方式；通过初始计划开始工作；项目的资源管理和控制

（3）质量就是软件产品对于某个（或某些）人的价值；软件开发应更关注于交付的价值

（4）正确的软件：一个软件要能够满足用户的需求，为用户创造价值。这里的价值可以体现在两个方面，即为用户创造利润和减少成本

（5）软件运行正确：软件没有或少有缺陷，具有很强的扩展性、良好的性能以及较高的易用性等。

（6）互联网产品的开发特点：快鱼吃慢鱼；版本发布成本低；追求创新；需要开始响应用户的变化；需求不确定性高；关注用户行为

2、敏捷方法与敏捷宣言

（1）敏捷开发是一种基于更紧密的团队协作、能够有效应对快速变化需求、快速交付高质量软件的迭代和增量的新型软件开发方法。

（2）敏捷开发更关注以下：

①更关注协作

②更关注质量

③更关注可工作的产品

④更关注全才化的专才

⑤基于实践而非基于理论

（3）敏捷方法：适应而非预测

1）需求是不可预测的

2）软件开发应是一个自适应的跟踪过程

（4）敏捷方法：以人为导向而非过程导向；软件开发过程中，人的因素是第一位的；强调软件开发中相关人员间信息交流

项目失败的原因最终都可追溯到某个信息没有及时准确地传递到应该接收它的人。——Alistir Cockburn Cockburn

人特别擅长面对面的交流，面对面交流的成本要远远低于文档交流的成本。—Alistir Cockburn

（5）

（6）敏捷开发方法是一组轻量级开发方法的总称，包含很多具体的开发过程和方法，最有影响的两个方法是极限编程(XP)和Scrum开发方法。

（7）敏捷宣言

我们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。

通过这项工作，我们认为：

个体和交互胜过过程和工具

可以工作的软件胜过面面俱到的文档

客户合作胜过合同谈判

响应变化胜过遵循计划

虽然右项也具有价值，但我们认为左项具有更大的价值

（8）敏捷宣言分析

•我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。

•欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。

•要不断交付可用的软件，周期从几周到几个月不等，且越短越好。

•项目过程中，业务人员与开发人员必须在一起工作。

•要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。

•无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。

• 可用的软件是衡量进度的主要指标。

•敏捷过程提倡可持续的开发速度，项目方、开发人员和用户应该能够保持恒久稳定的进展速度。坚持不懈地追求技术卓越和良好设计，这将提升敏捷能力。

• 要做到简单，即尽最大可能减少不必要的工作，这是一门艺术。

•最佳的架构、需求和设计出自于自组织的团队。

•团队要定期反省如何能够做到更有效，并相应地调整团队的行为。

3、敏捷开发核心理念

1.聚焦客户价值

（1）及时消除技术债务，持续保持快速响应

（2）消除软件开发中的浪费

（3）随时构建质量，不容忍缺陷

（4）交付刚刚好的系统

2.激发团队潜能

•团队是价值的真正创造者，应加强团队协作，激发团队潜能

•软件开发是一种团队活动，首先应做到提升沟通效率降低交流成本

3.不断调整以适应变化

• 客户是逐步发现真正需求

• 小批量是快速交付的关键

•通过迭代计划不断调整以适应变化

•应持续保持良好的软件架构

•利用多层次反馈不断调整以逼近目标

•随软件规模增长，需求变化呈非线性增长

•变化无法一次性预测，应根据迭代积累的经验和需求变化的情况，对计划进行不断地调整和细化。

1.2 Scrum框架

1、Scrum框架介绍

（1）Scrum方法：是1995年由Ken Schwaber和Jeff Sutherland博士共同提出，已被众多软件企业广泛使用，如Yahoo, Microsoft, Google, Motorola, SAP,IBM等。

（2）Scrum框架

Scrum 是一种兼顾计划性与灵活性的敏捷开发过程，它将整个开发过程分为若干次更小的迭代，每个迭代周期成为一个冲刺(Sprint)。

（3）迭代开发将整个软件生命周期分成多个小的迭代（一般2~4周），每一次迭代就是一个小的瀑布模型，包括需求分析、设计、实现和测试等活动，结束时都要生成一个稳定和被验证过的软件版本。

（4）迭代开发的关键要点：

• 每一次迭代都建立在稳定的质量基础上，并做为下一轮迭代的基线，整个系统的功能随着迭代稳定地增长和不断完善。

•每次迭代要邀请用户代表验收，提供需求是否满足的反馈。

• 在一次迭代中，一旦团队作出承诺，就不允许变更交付件和交付日期；如果发生重大变化，产品负责人可以中止当次迭代。

•在迭代中可能会出现“分解”和“澄清”，但是不允许添加新工或者对现有的工作进行“实质变更”。

•对于“分解”和“澄清”，如果存在争议，那么将其认定为变更，放到产品订单中下一次迭代再考虑。

2、Scrum团队介绍

1）三个角色

①产品负责人(Product Owner)

职责：定义开发目标以及需要实现的特性和优先级。

②Scrum 主管(Scrum Master)

职责：保证团队高效而不受打扰地工作，优化工作条件和过程。

③团队成员(Team)

职责：自组织地完成项目开发，使用一切可行手段保证进度和质量。

角色	职责	说明
产品负责人	•代表利益相关人（如用户、市场销售、高层管理者等)对产品的投资回报负责 ·确定产品发布计划 ·定义产品需求并确定优先级 •验收迭代结果，并根据验收结果和需求变化更新需求清单和优先级	除了负责客户需求外，责部任务如重构、持续集成环境搭建等也由产品负责人纳入统一管理
Scrum 主管	辅导团队正确应用敏捷实践引导团队建立并遵守规则 •保护团队不受打扰 •推动解决团队遇到的障碍激励团队	不命令和控制开发团队
开发团队	负责估计工作量并根据自身能力找出最佳方案去完成任务且保证交付质量向产品负责人和利益相关人演示工作成果（可运行的软件) •团队自我管理、持续改进	•由5-9名跨功能领域人员组成 ·集中在一起工作 •共同目标，共担责任 •严格遵守团队规则

3)Scrum团队组织

民主式结构：小组成员完全平等，名义上的组长与其他成员没有任何区别；大家享有充分的民主，项目工作由全体讨论协商决定，并根据每个人的能力和经验进行适当分配。

优点：同等的项目参与权激发大家的创造力，有利于攻克技术难关

缺点：缺乏明确的权威领导，很难解决意见分歧。

全功能的整体团队，拥有共同目标，

•一般 6~8人分担责任，彼此承诺

•拥有多技能的、致力于目标实现跨职能协作

·拥有足够授权和资

•关注于向项目干源，解决问题，找系人交付价值到自己的成功之路自指导、自组织角色交叉、可持续的速度·开发、测试、UI设计、文档编写

有效的沟通和信息等的透明

•基于技能而不是“岗位”认领工作

3、Scrum制品和活动

1）Scrum.制品

产品订单(Product Backlog)是从客户价值角度理解的产品功能列表。

•功能、缺陷、增强等都可以是产品订单项

•整体上从客户价值进行优先级排序

迭代订单(Sprint Backlog)是从开发技术角度理解的迭代开发任务。

•简单环境：可直接把产品订单项分配到迭代中

•复杂环境：可把一个产品订单项分为Web/后台......软件/硬件…..程序/美工….等开发任务

可工作软件(Working Software)是可交付的软件产品。

•“可交付”应视不同情况提前设定和选定交付标准。

•正式产品可能包括使用文档，在新产品开发初期可能只需要交付勉强看到效果的产品。

2）产品订单/用户故事

用户故事(User Story)是从用户角度对功能的简要描述。

3）Scrum 活动

迭代规划会议

迭代规划会议在每次迭代（或冲刺）开始时召开，一般不超过8小时，目的是选择和估算本次迭代的工作项。

整个会议分成两部分：

•第一部分以需求分析为主，选择和排序本次迭代需要实现的订单条目

·第二部分以设计为主，确定系统设计方案和工作内容

迭代规划会议一第一部分

会议目的：

•该会议的工作以分析为主，目的是要详细理解最终用户到底要什么，产品开发团队可以从该会议中详细了解最终用户的真实需要。

•产品负责人在会前准备：条目化的需求（用户故事）及其优先级排序，最近1~2次迭代最希望看到的功能。会前准备至关重要，可帮助产品负责人理清头绪，不至于在迭代期内频繁提出变更、增加或删除故事。

基本要求：

•经过估算和排序的产品订单列表

•挂图、马克笔、剪刀、胶水、即时贴、白板、铅笔和蜡笔

•假期计划表、重要人员的详细联系信息

•参会成员：团队成员、Scrum主管、产品负责人

会议过程：

①从第一个产品订单Product Backlog条目（即用户故事）开始，讨论该条目，以深入理解。

②分析并明确用户验收测试。

③找出非功能性需求（性能、稳定性、….）。

找出验收条件。

⑤弄清楚需要“完成”到何种水平。

⑥获得订单条目各个方面的清晰了解。

②绘制所需交付物的相关图表，包括流程图、UML图、手绘草图、屏幕界面设计等

回到步骤①，选取下一个产品订单条目。

会议输出：

•选择好的 Product Backlog 条目

•各个 Backlog 条目的需求

•各个 Backlog 条目的用户验收测试

•注意不要改变订单条目大小，不要估算任务

流程检查：

•在Sprint 规划会议第一部分结束前，团队需要短暂讨论一下，看看他们到底认

为自己能完成多少工作。

•询问团队能否快速回答下列问题，只需要简要回答即可：“我们能在这次迭代中完成第一个订单条目吗?”如果能得到肯定的回答，那么继续询问下一个条目，一直到已经分析完的最后一个条目。

迭代规划会议一第二部分

会议过程：

1从第一个 Backlog 条目开始，查看挂图，确定对于客户需求理解正确。

②围绕该 Backlog 条目进行设计，并基于下列类似问题：

•我们需要编写什么样的接口?

•我们需要创建什么样的架构?

•我们需要更新哪些表?

· 我们需要更新或是编写哪些组件?

③当团队明确知道自己应该如何开发该功能后，就可以转向下一个条目。

4)在会议的最后 10 分钟，团队成员使用即时贴写出初步的任务。这样可以帮助

团队成员知道接下来的工作从哪里开展，将这些任务放在任务板上。

会议输出：

•应用设计、架构设计图、相关图表

•确保团队知道应该如何完成任务

•注意：不要估算任务，不要分配任务每日站立会议

会议目的：

•团队在会议中做计划，协调其每日活动，还可以报告和讨论遇到的障碍。

•任务板帮助团队聚焦于每日活动上，应在这个时候更新任务板和燃尽图。

基本要求：

•任务板、即时贴、马克笔

•成员：团队、Scrum 主管

•每天15分钟，相同时间和地点

•团队成员在聆听他人发言时，应该想：“我该怎么帮他做得更快?”

•准时出席，不要超出限制时间

•不要讨论技术问题，不要转变会议话题

•Scrum 主管不要替团队成员移动任务卡片，不要替团队更新燃尽图

•Scrum 主管不要提出问题，团队成员不要向Scrum主管或管理层人员报告

每日站立会议

会议过程：

①团队聚在故事板旁边，可以围成环形。

②从左边第一个开始，向团队伙伴说明他到现在完成的工作。

③该成员将任务板上的任务放到正确的列中。

④可以的话，该成员可以选取新的任务，将其放入“进行中工作”列。

⑤如果该成员遇到问题或障碍，就要将其报告给Scrum主管。

⑥每个团队成员重复步骤②到步骤⑤。

每个团队成员需要回答三个问题：上次例会后完成了什么?遇到了什么困难（或障碍）?下次例会前计划做什么?

每日站立会议

会议输出：

•团队彼此明确知道各自的工作，最新的工作进度图

•最新的“障碍 Backlog”

•最新的“Sprint Backlog”迭代评审会议

会议目的：

•Scrum 团队在会议中向最终用户展示工作成果，团队成员希望得到反馈，并以之创建或变更 Backlog 条目。

基本要求：

•由团队展示有可能发布的产品增量

•允许所有参与者（包括用户）尝试由团队展示的新功能

•用户对团队演示的产品功能进行反馈

注意事项：

•不要展示不可能发布的产品增量

•团队不要针对产品负责人进行展示

迭代总结会议

每一次迭代完成后，都会举行一次迭代总结会议，会上所有团队成员都要反思这个迭代。举行迭代总结会议是为了进行持续过程改进，会议的时间限制在 4小时

迭代回顾会议的关键要点：好的能做得更好的将来改进的会议气氛：团队全员参加，气氛宽松自由，畅所欲言，头脑风暴发现问题，共同分析根因；关注重点：共同讨论优先级，将精力放在最需要的地方（关注几个改进足以）；会议结论要跟踪闭环：可以放入迭代订单中。

4、敏捷规划和可视化管理

1）Scrum规划.

实行两级项目规划：

产品

将面向整个项目范围的宏观计划和面向当前下发布一次迭代的微观计划相结合，渐进明细地进行项目规划。

迭代

•发布规划是对整个产品发布过程的展望，其结每日果是产生产品订单。

•迭代规划只是对一次迭代的展望，其结果是确定包含一次迭代中具体工作任务的迭代订单。

2）Scrum规划

发布规划

迭代规划

•定义用户故事并进行优先级划分

•确定迭代目标并选择用户故事

•估算规模以及评估团队开发速度

•将用户故事分解和细化到任务

•制定发布计划

•对故事和任务进行时间估算

发布规划是对整个产品发布过程的展望，通常的规划周期是3~6个日。

开发阶段

承诺阶段

适应调整阶段

定义用户故事

基于项目约束确定

目标和里程碑

业务和开发人员参

划分优先级

评估团队

与计划调整

估算故事规模

开发速度

分解与合并确定近期发布中包完成发布计划用户故事含的用户故事

迭代规划将产生Scrum中提到的迭代订单，一般迭代周期为4周的时间。

调整产品订单中

用户故事优先级

确定冲刺目标

选择要增加的

将用户故事

用户故事

细化到任务

选择原则：

对故事和任务

完成冲刺订单

·团队开发速度

进行估算

•团队成员承诺

3）可视化管理

任务白板是团队开发的晴雨表，它将团队的任务和进度可视化地展现出来。而引入电子白板可能会削减团队之间的沟通，降低团队的透明度，违背了敏捷重视人和团队的原则。

燃尽图：以图形化方式展现了剩余工作量(Y轴)与时间(×轴)的关系极限编程概述、

1.3极限编程

1、极限编程概要

1）极限编程和传统方法学的本质不同在于它更强调可适应性而不是可预测性。

• 极限编程的支持者认为软件需求的不断变化是很自然的现象，是软件项目开发中不可避免的、也是应该欣然接受的现象；

• XP 是一种迭代方法。团队计划少量工作并在称为 1 到 4 周迭代的短时间盒内构建它。XP 与其他迭代框架的主要区别在于，XP 专注于达到极端水平的软件工程实践。

2）极限编程的目标

•极限编程的主要目标在于降低因需求变更而带来的成本。

•极限编程通过引入基本价值、原则、方法等概念来达到降低变更成本的目的。

•一个应用了极限编程方法的系统开发项目在应对需求变更时将显得更为灵活。

3）结对编程

结对编程是由两名程序员在同一台电脑上结对编写解决同一问题的代码有助于提升代码设计质量；

研究表明结对生产率比两个单人总和低15%但缺陷数少15%，考虑修改缺陷工作量和时间比初始编程大几倍，所以结对编程总体效率更高；

•能够大幅促进团队能力提升和知识传播；实施时需要团队成员克服个性冲突和习惯差异。测试驱动开发测试驱动开发是以测试作为编程中心，要求在编写任何代码之前，首先编写定义代码功能的测试用例，编写的代码要通过测试，并不断进行重构优化。

4)持续集成

持续集成是一项软件开发实践，团队成员经常集成自己的工作，通常每人每天至少集成一次，每次集成通过自动化构建完成。所有开发人员需要在本地机器上进行本取最新新本用地构建，然后再提交到版本控制库中，于市场发布取最新承本实以免影响持续集成。

2、12个核心实践

（1）规划游戏(planning game)快速制定计划，随着细节的变化而改进；详细说明：需结合项目进度和技术条件确定下一阶段拟开发和发布的系统范围。当计划跟不上实际变化时，应更新计划。

（2）小发布 (Small release)系统的设计应该能够尽早交付；详细说明：强调新版本应该在极短的时间内增量发布，这样每个迭代周期的进度很容易估计，工作量和风险也很容易控制；同时，用户的反馈也能得到及时处理。

（3）系统隐喻(System Metaphor)找一个合适的比喻来传达信息；详解：通过比喻来描述系统的工作原理以及系统如何添加新的功能。它通常包含一些可以参考和比较的类和设计模式。

（4）简单的设计(Simple Design)只处理当前的需求，保持设计的简单；在任何时候，系统都应设计得尽可能简单。不必要的复杂性一旦被发现就会被移除。

（5）测试驱动 (Test-driven)先写测试代码，再写程序；说明：程序员不断地编写单元测试，只有这些测试能够正确运行才能继续开发。

（6）重构(Refactoring)重新检查需求和设计并重新清晰地描述它们以满足新的和现有的需求；代码重构是在不改变系统行为的情况下，重新调整和优化系统内部结构，以降低复杂度，消除冗余，增加灵活性，提高性能。

（7）结对编程 (Pair Programming)两个程序员在同一台计算机上编写代码来解决同一个问题。解释：通常一个人负责编写代码，另一个人负责保证代码的正确性和可读性。

（8）集体所有(Collective Programming)任何人都可以随时随地更改系统中的任何代码。说明：每个会员都有修改代码的权利，每个人对所有的代码负责。

（9）持续集成(Continous integration)可以按天甚至按小时运行，供客户运行版本提倡一天集成几次系统，随着需求的变化，不断进行回归测试，避免系统集成一次的噩梦。

（10）每周40小时 (40 hour work)项目组成员每周工作时间不得超过40小时，加班时间不得连续超过两周，否则会影响生产效率。

（11）现场客户(One-site customer)在团队中添加一个真正的、功能性的用户，他将全职回答问题。说明：在整个项目开发周期中，至少需要一名实际客户代表在现场确定需求，回答团队问题，并编写功能验收测试。

（12）代码标准(Code Standards)通过指定严格的代码规范来强调沟通，以尽量减少不必要的文档。

3、4个价值观

（1）沟通(Communication)- 保持正确的对话流畅以减少问题的发生。

（2）简单 (Simplecity)-今天做一件简单的事情，而不是制造你可能永远不需要的镀金。

（3）反馈(Feedback)-与系统、客户以及彼此驱动解决方案的反馈循环。

（4）勇气(Courage)-做出艰难的决定以帮助您以最快的速度交付。

（5）尊重 (Respect)-尊重意味着分享成功和失败的同时，我们尊重彼此、我们的协议和承诺。

4、5个原则

（1）快速反馈

当反馈能做到及时、迅速，将发挥极大的作用。一个事件和对这一事件做出反馈之间的时间，一般被用来掌握新情况以及做出修改。

（2）假设简单

假设简单认为任何问题都可以”极度简单”地解决。传统的系统开发方法要考虑未来的变化，要考虑代码的可重用性。极限编程拒绝这样做。

（3）增量变化

极限编程采用增量变化的原则。比如说，可能每三个星期发布一个包含小变化的新版本。这样一小步一小步前进的方式，使得整个开发进度以及正在开发的系统对于用户来说变得更为可控。

（4）拥抱变化

这一原则就是强调不要对变化采取反抗的态度，而应该拥抱它们。

（5）高质量的工作

没人喜欢拖泥带水，每个人都期望出色的完成工作。极限编程的提倡者认为范围、时间、成本和质量这个四个软件开发的变量，只有质量不可妥协的。

第四章：可行性分析

1.1 可行性分析的目的

用最小的代价最短的时间来确定问题是否能够解决

1.2 可行性分析的任务

1、任何一个完整的软件工程项目都是从项目立项开始的。项目立项包括项目发起、项目审核和项目立项四个过程

2、可行性研究的任务：

（1）可行性研究需要从多个方面进行评估，主要包括：操作可行性、经济可行性、技术可行性、法律可行性、战略可行性、社会可行性、市场可行性、计划可行性

（2）可行性研究的任务：一般都要从经济、技术、操作和法律四个方面来研究每种解法的可行性，做出明确结论来供用户参考

①经济可行性

经济可行性主要进行成本-效益分析，从经济角度，确定系统是否值得开发。

成本--效益分析是可行性研究的重要内容。基于项目的经济合理性，给出项目开发的成本论证，并将估算的成本与预期的利润进行对比。一般说来，基于项目的成本由4个部分组成：购置并安装软硬件及有关设备的费用；项目开发费用；软硬件系统安装、运行和维护费用；人员的培训费用。在项目的分析和设计阶段只能得到上述费用的预算，即估算成本在项目开发完毕并将系统交付用户运行后，上述费用的统计结果就是实际成本

经济效益通常可用货币的时间价值、投资回收期和纯收入来度量。

②技术可行性分析主要根据系统的功能、性能和约束条件等。分析在现有的资源和技术条件下系统能否实现

技术可行性主要研究待开发的系统的功能、性能和限制条件，确定现有技术能否实现有关的解决方案，在现有的资源条件下实现新系统的技术风险有多大。这里的资源条件是指已有的或可以得到的软硬件资源，现有的开发项目的人员的技术水平和已有的工作基础。

在评估技术可行性时，需要考虑以下情况：

了解当前最先进的技术，分析相关技术的发展是否支持新系统：确定资源的有效性，如新系统的软硬件资源是否具备，开发项目的人员在技术和时间上是否可行等；

分析项目的开发的技术风险，即能在给定的资源和时间等条件下，设计并实现系统的功能和性能等。操作可行性是对开发系统在一个给定的工作环境中能否运行或运行好坏程度的衡量。操作可行性研究决定在当前的政治意识形态、法律法规、社会道德、民族意识以及系统运行的组织机构或人员等环境下，系统的操作是否可行。操作可行性往往最容易被忽视或被低估，或者认为它一定是可行的。

③法律可行性分析

研究系统开发过程中可能涉及到的合同、侵权、责任以及各种与法律相抵触的问题。

法律可行性分析主要依据：

• 中华人民共和国著作权法实施条例

• 计算机软件保护条例明确系统目标进行可行性研究的步骤不是固化分析研究现行系统的，而是根据项目的性质、特点以及开发团队的能力有所区别。

④操作可行性是对开发系统在一个给定的工作环境中能否运行或运行好坏程度的衡量。操作可行性研究决定在当前的政治意识形态、法律法规、社会道德、民族意识以及系统运行的组织机构或人员等环境下，系统的操作是否可行。操作可行性往往最容易被忽视或被低估，或者认为它一定是可行的。

1.3 可行性研究的步骤

1.4 可行性分析的结论

（1）可以立即开始执行

（2）条件满足之后才可以开始执行

（3）不可行

如果可行：系统可能会有多个可行的方案，每个方案对成本、时间，人员技术要求不同，对不同的系统开发方案进行分析、比较和论证，选择合理的方案。推荐最优方案制定初步计划，书写文档提交审查

1.5 可行性研究报告

不同的标准模板，可行性研究报告的格式各有不同，但主要内容应该包括以下几项：

1.引言;

2.可行性研究前提；

3.对现有系统的分析；

4.对所建设系统的分析：经济可行性、技术可行性、社会因素的可行性等；

5.其他与设计有关选择方案；

6.其他与设计有关的专门问题；

7.结论意见；

第五章：需求工程

【掌握需求的定义和分类；掌握功能需求和非功能需求】

1.1 需求基础

1、需求的来源

需求来源于现实世界的问题（业务需求+用户需求）——》软件功能描述系统需求（）

2、需求的定义

IEEE软件工程中需求的定义：

（1）用户为了解决问题或达到目标所需的条件和能力

（2）系统或系统部件为满足合同、标准、规范或其它正式规定文档所需具有的条件和能力

3、需求的层次

（1）业务需求
业务需求描述组织或客户的高层次目标，是系统目标，它必须是业务导向、可度量、合理、可行的。这类需求通常来自与高层，例如项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。
业务需求从总体上描述了为什么要开发系统(why)组织希望达到什么目标。一般使用前景和范围(visionand scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求(project charter 或 market requirement）文档。

业务需求，不是某一个环节或者某一项工作的需求，也不是某个人的需求，而是该业务整体的通用的需求。业务需求也可以称作为行业、领域需求。

（2）用户需求
用户需求描述的是用户使用产品必须完成的目标或任务，怎么完成需求，通常是在问题定义的基础上进行用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求。
用户需求必须能够体现软件系统将给用户带来的业务价值，或用户要求系统必须能完成的任务，也就是说用户需求描述了用户能使用系统来做些什么(what)，这个层次的需求是非常重要的。用例、用户故事、特性（用户满意度最为关键的产品特征或特征描述）等都是表达用户需求的有效途径
通常用用例文档来描述

（3）系统需求
系统需求描述用户对系统行为的期望，每个系统需求反映了一次外界与系统交互行为
功能需求规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。
功能需求是需求的主体，它描述的是开发人员如何设计具体的解决方案来实现这些需求(how)，其数量往往比用户需求高一个数量级。这些需求记录在软件需求规格说明书(Software Requirments Specification) 中。SRS用于后续的开发、测试、质量保障、项目管理等相关功能

1.2 需求分类

1、功能需求

和系统主要工作相关的需求，即在不考虑物理约束的情况下，用户希望系统所能够执行的活动，这些活动可以帮助用户完成任务。功能需求主要表现为系统和环境之间的行为交互
·最常见、最主要和最重要的需求
·能够为用户带来业务价值的系统行为
·最需要按照三个抽象层次进行展开
·软件产品产生价值的基础

2、非功能需求——性能需求

（1）非功能需求：
性能需求：系统整体或系统组成部分应该拥有的性能特征，例如CPU使用率、内存使用率等。
质量需求：系统完成工作的质量，即系统需要在一个“好的程度”上实现功能需求，例如可靠性程度、可维护性程度等。
对外接口：系统和环境中其他系统之间需要建立的接口，包括硬件接口、软件接口、数据库接口等等。
约束：进行系统构造时需要遵守的约束，例如编程语言、硬件设施等

（2）非功能需求-性能需求
速度：系统完成任务的时间
容量：系统所能存储的数据量
吞吐量：系统在连续的时间内完成的事务数量
负载：系统可以承载的并发工作量
实时性：严格的实时要求

3、非功能需求——质量需求

（1）系统为了满足规定的及隐含的所有要求而需要具备的要素称为质量
·质量属性是为了度量质量要素而选用的特征
·质置模型就是能够为质量需求的描述和评价提供工作基础的特征集及特征之间的联系
·质量属性的重要性
对设计的影响很大，对越复杂的系统越为重要
·[Robert19901]：真实的现实系统中，在决定系统的成功或失败的因素中，满足非功能需求往往比满足功能性需求更重要

（2）常见的质量属性
可靠性：在规格时间间隔内和规定条件下，系统或部件执行所要求能力的能力
可用性：软件系统在投入使用时可操作和可访问的程度或能实现其指定系统功能的概率。
安全性：软件阻止对其程序和数据进行未授权访问的能力，未授权的访问可能是有意，也可能是无意的。
可维护性：软件系统或部件能修改以排除故障、改进性能或其他的容易程度，包括可修改性和可扩展性
可移植性：系统或部件能从一种硬件或软件环境转换至另外一种环境的特性。
易用性：与用户使用软件所花费的努力及其对使用的评价相关的特性。
可维护性：软件系统或部件能修改以排除故障、改进性能或其他的容易程度，包括可修改性和可扩展性
可移植性：系统或部件能从一种硬件或软件环境转换至另外一种环境的特性。
易用性：与用户使用软件所花费的努力及其对使用的评价相关的特性。
可靠性：软件系统在指定环境中没有失败而正常运行的概率如QR1：客户端崩溃率不超过1% 。
存活性：当系统的某一部分系统不能运行时，该软件继续运行如QR2：服务端登录功能崩溃用户能正常查看菜品。

用户友好性：学习和使用一个软件系统的容易程度

健壮性：指的当系统或软件遇到非法输入、相关软件或硬件组成部分的缺陷或异常的操作情况下，能继续正确运行功能的程度。安全性、可移植性、可维护性

4、非功能需求——对外接口

系统和环境中其他系统之间需要建立的接口，包括硬件接口、软件接口和数据库接口等。

5、非功能需求——约束

非功能需求-约束
构建系统时需要遵循的限制条件，如编程语言、硬件设施、设
计约束、法律法规等。
服务器必须用 Linux系统
服务器cpu性能必须高于i3，内存大于8G
数据库系统：MySQL Server5.4或更新版本
服务器用Tomcat8
后台需要用Java开发
手机App支持Android4.4以上的系统，iOS10以上的系统符合计算机软件保护条例

6、需求分类总结

1.3 需求工程

1、需求工程概要

概念：所有需求处理活动的总和。它收集信息、分析问题、整合观点、记录需求并验证其正确性，最终描述出软件被应用后与其环境互动形成的期望效应。

2、需求开发过程

（1）需求开发过程模型

（2）需求获取

（3）需求分析常用方法

（4）软件需求规格说明书

1）软件需求规格说明活动，就是将需求信息及其软件解决方案进行正式的定义并文档化，并传递给开发人员的需求工程活动。
2）产生的文档成为需求规格说明文档。
3）需求规格文档要求完整、准确、清晰、具体

（5）软件需求规格说明书范本

（6）需求验证
需求规格说明文档至少要满足下面几个标准：
文档内每条需求都正确、准确的反映了用户的意图
文档记录的需求集在整体上具有完整性和一致性
文档的组织方式和需求的书写方式具有可读性和可修改性需求管理

3、需求管理

（1）

（2）需求开发与管理之间的界线