CPT203 （2/N）

下面开始第二部分，该部分从week3开始。

Week3：Agile Methods

这部分的内容主要分为3个：
-敏捷方法
-计划驱动和敏捷开发
-Scrum框架

背景：
如今，企业在一个全球化、瞬息万变的环境中经营。它们必须对新的机会和市场、不断变化的经济条件以及竞争性产品和服务的出现作出反应。这意味着速度要在开发中占据更大的比重。事实上，许多企业都愿意以软件质量为代价，在需求上做出妥协，以更快地部署所需的软件。

得出一套完整稳定的软件需求是不肯能，因为最初的需求不可避免地会发生变化。尽早交付系统，让用户积累经验，才能发现更清晰的真实需求。由于外部因素，需求可能会不可预测地迅速发生变化。

计划完全指定需求，然后设计、构建和测试系统的软件过程并不适合快速的软件开发。当需求变更或需求问题被发现时，系统设计或实现必须重新工作和重新测试。

快速软件开发（Repid Software Development）：

定义：软件不是作为一个单一的单元开发的，而是一系列的增量，每一个增量包括新的系统功能。

基本特征:
•各个过程是交错的
•最小化文档
•在系统涉众的参与下，开发一系列版本或增量
•系统用户界面通常使用交互式开发系统开发，允许快速创建界面设计

计划驱动开发方法-
大型、长寿命的软件——仔细的项目计划、形式化的质量保证、使用CASE工具支持的分析和设计方法，以及受控和严格的软件开发过程。

•多个开发团队的工作必须得到协调
•该系统是一个关键系统
•许多不同的人将长期参与维护软件

敏捷方法：

概念：
敏捷允许开发团队专注于软件本身，而不是设计和文档。这普遍依赖于软件规格说明、开发和交付的增量方法。它们最适合应用程序开发，其中的系统需求通常在开发过程中迅速变化。他们的目的是快速向客户交付工作软件，然后客户可以提出新的和变更的需求，并将其包含在系统的后续迭代中。

•敏捷方法背后的哲学反映在敏捷宣言中，该宣言得到了这些方法的许多主要开发人员的一致认可：
•个人和互动高于过程和工具
•工作软件胜过全面的文档
•客户合作胜过合同谈判
•响应变化而不是遵循计划

注意，很多敏捷方法都是基于基于不同过程的增量开发和交付的概念，然而，他们基于敏捷宣言共享一套原则，因此有很多共同点。

挑战：

在实践中，敏捷方法的基本原则有时很难实现:

它的成功依赖于拥有一个愿意并且能够花时间与开发团队在一起的客户，这个客户能够代表所有的系统涉众。单个团队成员可能没有适合强烈参与的个性，优先级变更可能是极其困难的，特别是在有许多涉众的系统中，维护简单性需要额外的工作。对于一些组织来说，接受开发团队定义的非正式过程是很困难的。

软件需求文档通常是客户和供应商(软件公司)之间合同的一部分。由于增量规范是敏捷方法固有的，为这种类型的开发编写契约可能会很困难。敏捷方法必须依赖契约，在契约中，客户支付系统开发所需的时间，而不是特定需求的开发。如果出现问题，那么谁应该负责，谁应该为解决问题所需要的额外时间和资源支付费用，可能会产生困难的争执。

维护：
在考虑敏捷方法和维护时，有两个问题需要考虑:
•考虑到在开发过程中最小化正式文档的重要性，使用敏捷方法开发的系统是否可维护?
•敏捷方法能否有效地用于开发系统以响应客户的变更请求?
•正式的文档是为了简化系统的发展和维护。然而，在实践中，正式的文档常常不能及时更新，在系统可维护性方面也是如此。

•敏捷方法的支持者认为编写这种过时的文档是浪费时间。实现可维护软件的关键是产生高质量、可读的代码。关键文档是系统需求文档，它告诉软件工程师系统应该做什么。

•软件交付后的主要困难可能是让客户参与到这个过程中来。同时，有可能出现的另一个问题是保持开发团队的连续性。敏捷方法依赖于团队成员对系统各个方面的理解，而无需查阅文档。如果一个敏捷开发团队被解散，那么这种隐性知识就会丢失，新团队成员很难建立对系统及其组件的相同理解。

•大多数软件项目都包括计划驱动和敏捷方法的实践。
•为了在基于计划的方法和敏捷方法之间取得平衡，你必须回答一系列技术、人力和组织问题:

例如：

•需要详细的规格和设计?
•渐进式战略是否现实?
•系统有多大?
•开发什么类型的系统?
•系统寿命?
可用的技术和工具?
•团队组织?
•文化问题?
•提供一套技能?
•外部监管?

Week4: Requirement Engineering

背景：
需求工程属于软件过程中软件规范的一部分。它是对系统应该做什么的描述，反映顾客对系统的需求。而这个发现、分析、记录和检查这些需求和约束的过程称为需求工程(RE)。需求可以用系统应该提供的服务或系统约束的高级抽象语句来描述。从另一方面说，它是对系统功能的详细，正式的的定义。

•高级描述还是详细描述?
•作为大型软件开发项目合同的一部分，它必须以一种足够抽象的方式定义其需求。一旦合同被授予，承包商必须为客户写一个更详细的系统定义，以便客户理解并验证软件将做什么。
•不同层次的细节服务于不同的目的。用户需求和系统需求：
•用户需求——用自然语言和图表描述服务和系统约束的语句。
•系统需求-更详细地描述软件系统的功能、服务和运作限制。

tip：
需求应该说明系统应该做什么，而设计应该描述它如何做到这一点。

用户需求——
客户经理 系统最终用户 客户端工程师 承包商 管理人员 系统架构师

系统需求——
系统最终用户 客户端工程师 系统架构师 软件开发人员

重点：功能和非功能需求

软件需求通常被分为功能性需求和非功能性需求。

功能性需求：
这些是系统应该提供的服务的陈述。服务在特定条件下应该如何反应和行为。在某些情况下，功能需求还可能明确地说明系统不应该做什么。

•当表达为用户需求时，功能需求通常以系统用户可以理解的抽象方式描述。
•更具体的功能系统需求，详细描述系统功能、输入输出、异常等。

系统的功能需求规范应该既完整又一致。完整性意味着应该定义用户所需的所有服务。一致性意味着需求不应该有相互矛盾的定义。在实践中，对于大型、复杂的系统，实现需求的一致性和完整性实际上是不可能的。在为复杂的系统编写规范时，在大型系统中有许多涉众，很容易犯错误和遗漏。涉众有不同的，而且经常是不一致的需求。

非功能性需求：
这些是对系统提供的服务或功能的限制。非功能性需求通常应用于整个系统，而不是单个系统特性或服务。

非功能性需求，顾名思义，是与系统交付给用户的特定服务不直接相关的需求。
•系统属性，如可靠性、响应时间和店面占用率。
•系统实现约束，如性能、安全性、可用性等。
•通常指定系统作为一个整体的约束特征。
•通常比单个功能需求更重要。

•未能满足非功能性需求可能意味着整个系统无法使用。
•非功能性需求的实现可能复杂地分散在整个系统中。
•它们可能会影响系统的整体架构，而不是单个组件。
•单个非功能需求可能会产生许多相关的功能需求。

•产品需求——这些需求指定或约束软件的行为。
•组织需求——这些需求是广泛的系统需求，来源于客户和开发人员组织的政策和程序。
•外部需求——这个大标题涵盖了来自系统及其开发过程外部因素的所有需求。

下面是一个例子：
产品需求：MHC-PMS应在正常工作时间(周一至周五，8:30 -17.30)提供给所有诊所。正常工作时间内的停机时间在一天内不得超过5秒。
组织需求：
MHC-PMS系统的用户应使用其卫生主管部门身份证进行身份验证。
外部需求：
该系统应执行HStan-03-2006-priv中规定的患者隐私规定。

总结：
非功能性需求经常与其他功能性或非功能性需求发生冲突并相互作用。在需求文档中很难将功能性和非功能性需求分开。您应该明确地强调与紧急系统属性(如性能或可靠性)明显相关的需求。

不同类型需求之间的区别并不像这些简单定义所建议的那样明确。

软件需求文档：

软件需求文档(有时称为软件需求说明书或SRS)是系统开发人员应该实现什么的官方声明。它应包括系统的用户需求和系统需求的详细规格说明。

•当外部承包商开发软件系统时，需求文档是必不可少的。
•敏捷开发方法认为，需求变化如此之快，以至于一写完需求文档就过时了。所以敏捷开发适合需求不稳定的业务系统，但编写一份简短的支持文档来定义系统的业务和可靠性需求仍然是有用的。

各个角色：
系统客户——指定需求并阅读它们以检查它们是否满足需求。客户指定对需求的更改。
经理——使用需求文档计划系统投标和计划系统开发过程。
系统工程师——使用需求来理解要开发的系统。
系统测试工程师——使用需求来开发系统的验证测试。
系统维护工程师——使用需求来理解系统及其各部分之间的关系。

剩下的一小部分内容因为考试没有涉及，在此不提及。