第二章笔记 - 爱码网

可行性研究与计划
关键任务：
　　解决问题是什么？有行得通解决方法？粗略计划
问题定义报告：
　　问题性质、工程目标、工程规模。
可行性研究报告：
　经济、技术、社会（操作）可行性。
项目开发计划：
　　粗略
需求分析
关键任务：
　　目标系统必须作什么？
　　可行性研究的需求分析是粗略、不准确。
　　需求分析师完整、准确、清晰、具体。
需求规格说明书：
　　目标系统需求。
总体设计
关键任务：
　　怎样实现目标系统？
　　根据需求设计方案；分析推荐最佳方案；设计软件结构等。
总体设计说明书：
　　记录总体设计结果。
详细设计
关键任务：
　　该怎样具体实现系统？
　　设计每个模块的算法和数据结构。
详细设计说明书：
　　用适当表达工具表达算法和数据结构。
实现（编码和单元测试）
关键任务：
　　选择语言、工具翻译详细设计结果、测试模块。
实现阶段文档：
　　程序清单、单元测试报告。
集成测试
关键任务：
　将经过单元测试模块组装起来进行测试；
　　通过测试使软件达到预定要求。
测试报告：
　　测试计划、测试方案、测试结果。
确认测试
关键任务：
　　有用户按需求规格说明书规定进行测试。
测试报告：
　　测试计划、测试方案、测试结果。
使用和维护
关键任务：
通过必要维护活动使系统持久满足用户要求。
维护类型：
改正性维护：软件运行过程中发现错误，进行维护。
适应性维护：软件运行软硬件环境变化，进行的维护。
完善性维护：用户要求改进或扩充软件，进行的维护。
　　预防性维护：为将来的维护做准备。

1.4 软件过程模型

实际从事软件开发工作时，软件规模、类型、开发环境及技术方法等因素会影响到阶段划分，及格阶段的执行顺序，形成不同生存周期模型，又称过程模型。

2.1 瀑布模型

使用最早应用最广，瀑布模型如下：

瀑布模型的特点：（文档驱动的）

　　1. 阶段具有顺序性和依赖性

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

　　2. 推迟实现观点

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

　　3. 质量保证观点

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

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

带反馈环的瀑布模型图如下：

优点：

　　提高软件质量，降低维护成本，缓解软件危机。

缺点：

　　模型缺乏灵活性，无法解决需求不明确问题。用户不经过实践提出完整准确需求，不切实际。

2.2 快速原型模型

快速建立反映用户主要需求的原型系统，反复有用户评价修正需求，开发出最终产品；

优点：

　　确定需求上由于瀑布模型（通过原型与用户交互）；提供学习手段，通通过开发原型和演示原型对开发者和使用者了解系统都有积极作用；

　　有的软件原型可以成为最终产品的一部分/

缺点：

　　快速建立的系统结构加连续修改可能导致产品质量低下原型系统的内部结构可能不好。

2.3 增量模型

又称建增模型，开发软件时将软件产品做一系列增量构件设计、编码、集成和测试。

区别于瀑布和快速原型模型：

　　瀑布和快速原型模型是一次把满足所有需求产品提交给用户。

　　增量模型是分批向用户提交产品。

优点：

　　较短时间向用户提交可完成有用工作产品；

　　用户有充裕时间学习适应产品；

　　软件结构必须开放，方便向现有产品假如新构建。

缺点：

　　做到第三个优点比较困难。

前述增量模型在实现构件前玩成总体的需求分析、规格说明和概要设计，相对来说风险较小。

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

2.4 螺旋模型

1988年B·Boehem提出，加入风险分析，常指导大型软件项目。

软件风险：

　　超期、超预算、行业竞争等。

笛卡尔坐标四象限表达四方面活动：

　　1. 制定计划：确定目标、选定方案、设定约束条件。

　　2. 风险分析：评估方案，识别和消除风险。

　　3. 实施工程：软件开发
　　4. 客户评估：评估开发工作，计划下一阶段工作。沿落线自内向外每旋转一圈开发出跟完善新版本。

螺旋模型的基本思想是，是使用原型及其他方法来尽量降低风险。理解这种模型的一个简便方法，是把它看做在每个阶段之前都增加了风险分析过程的快速原型模型。如图1.7

优点：

　　大型软件开发项目有较好的风险控制；

缺点：

　　需要风险评估的经验；

　　契约开发通常需要事先指定过程模型和发布产品

　　普及不如前述模型

2.5 喷泉模型

面向对象生命周期模型，体现迭代和无缝特性。

迭代：

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

无缝：

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

优点：

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

缺点：

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

2.6 Rational统一过程（Rational Unified Process, RUP）

由Rational软件公司退出的一种软件过程，该过程强调迭代和渐增方式开发软件。

Rational统一过程是一个二维生命周期模型。

RUP有9个核心工作流，包括6个核心过程工作流。

RUP有4个连续阶段，每个阶段有明确目标，通过一次或多次迭代完成。

Rational统一过程有点：

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

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

　　迭代开发，降低风险；

　　更好地安排产品开发的辅助过程。

2.7 敏捷过程于极限编程

敏捷过程概述

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

　　优秀的团队成员是软件开发项目获得成功的最重要因素，但不好的过程和工具也会使最优秀的团队成员无法发挥作用。团队成员的合作、沟通以及交互能力要比单纯的软件编程能力更为重要。

“可以使用的软件”胜过“面面俱到的文档”

　　软件开发的主要目标是向用户提供可以使用的软件而不是文档，但是，完全没有文档的软件也是一种灾难。开发人员应该把主要精力放在创建可使用的软件上面，仅当迫切需要并且具有重大意义时，才进行文档编工作，而且所编制的内部文档应该尽量简明扼要和主题突出。

“客户合作”胜过“合同谈判”

　　客户通常不能做到一次性把他们的需求完整准确地表述在合同中。能够满足客户不断变化的需求的切实可行的途径是：开发团队与客户密切协作。因此，能指导开发团队与客户协同工作的合同才是最好的合同。

“响应变化”胜过“遵循计划”

　　软件开发过程总会有变化，这是客观存在的现实。一个软件过程必需反映现实，因此，软件过程应该有足够的能力及时响应变化。然而没有设计的项目也还会因陷入混乱而失败，关键是计划必须有足够的灵活性和可塑性，在形势发生变化时能迅速调整，以适应业务、技术等方面的变化。

　　“敏捷宣言”的原则

最重要的是通过尽早和持续地交付有价值的软件以满足客户需要。

及时在开发后期也欢迎需求的变化。敏捷过程驾驭变化带给客户竞争优势。

经常交付可以使用的软件，间隔可以从几个星期到几个月，时间尺度越短越好。

业务人员和开发人员应该在整个项目过程中每天都在一起工作。

使用积极的开发人员进行项目，给他们提供所需环境和支持，并信任他们能够完成任务。

在开发小组中最优效率和效果的信息传达方式是面对面的交谈。

可以使用的软件是度量进度的主要标准。

敏捷过程提倡的是持续开发过程。投资人、开发人员和用户应该维持一个长期稳定的步调。

持续地追求卓越的技术与良好的设计会增加敏捷性。

简单（尽可能减少工作量）是最重要的。

最好的架构、需求和设计都来自与组织的团队。

团队要定期总结如何提高效率，然后相应地调整自己的行为。

　　根据上述价值观提出的软件工程陈伟敏捷过程，其中应用比较广泛的是极限编程和Scrum。

极限编程

　　极限编程（eXtreme Programming，XP）是敏捷过程中最富盛名的一个，其名称中“极限”儿子的含义是指把好的开发实践运用到极致。目前，极限编程已经成为一种典型的开发方法，广泛应用于需求模糊且经常改变的场合。

　　极限编程的有效实践

客户作为开发团队的成员
必须至少有一名客户代表在项目的整个开发周期中与开发人员一起紧密地配合工作，客户代表负责确定需求、回答开发人员的问题并且设计功能验收测试方案。

使用用户素材
所谓用户素材就是正在进行的关于需求的谈话内容的助记符。根据用户素材可以合理地安排实现该项需求的时间。

短交付周期
每两周完成一次的迭代过程实现了用户的一些需求，交付出目标系统的一个可工作的版本。通过向有关的用户演示迭代生成的系统，获得他们的反馈意见。

验收测试
通过执行由客户指定的验收测试来捕获用户素材的细节。

结对编程
结对编程就是由两名开发人员在同一台计算机上共同编写解决同一个问题的程序代码，通常一个人编码，另一个人对代码进行审查和测试，以保证代码的正确性和可读性。结对编程是加强开发人员相互沟通于评审的一种方式。

测试驱动开发
极限编程强调“测试先行”。在编码之前应该首先设计好测试方案，然后再编程，直至所有测试都通过之后才可以结束工作。

集体所有
极限编程强调程序代码属于整个开发小组集体所有，小组每个成员都有更改打码的权利，每个成员都对全部代码的质量负责。

持续集成
极限编程主张在一天之内多次集成系统，而且随着需求的变更，应该不断地进行回归测试。

可持续的开发速度
开发人员以长期维持的速度努力工作。XP规定开发人员每周工作实践不超过40小时，连续加班不可以超过两周，以免降低工作效率。

及时调整计划
计划应该是灵活的、循序渐进的。制订出项目计划之后，必须根据项目进展情况及时进行调整，没有一成不变的计划。

简单的设计
开发人员应该使设计与计划要在本次迭代过程中完成的用户素材完全匹配，设计时不需要考虑未来的用户素材。在一次次的迭代过程中，项目组成员不断变更系统设计，使之相对于正在实现的用户素材而言始终处于最优状态。

重构
所谓代码重构就是在不改变系统行为的前提下，重新调整和优化系统的内部结构，以降低复杂性、消除冗余、增加灵活性和提高性能。应该注意的是，在开发过程中不要过分依赖重构，特别是不能轻视设计，对于大中型系统而言，如果推迟设计或者干脆不做设计，将造成一场灾难。

使用隐喻
可以将隐喻看做是把整个系统联系在一起的全局视图，它描述系统如何运作，以及用何种方式把新功能加入到系统中。

　　极限编程的整体开发过程

首先，项目组针对客户代表提出的“用户故事”。

然后，项目组在隐喻和用户故事的基础上，根据客户设定的优先级制定交付计划。

最后，开始多个迭代过程，在迭代期产生的新用户故事不在本次迭代内解决，以抱枕本次开发过程不受干扰。

　　

　　以极限编程为杰出代表的敏捷过程，可以快速、敏捷地响应变化和不确定的需求，同时仍然能够保持可持续的开发速度。上述这些特点使得敏捷过程能够较好地适应商业竞争环境下对项目提出的有限资源和有限开发时间的约束。

2.8 能力成熟度模型

能力成熟度模型（capability maturity model，CMM）并不是一个软件生命周期模型，而是改进软件过程的一种策略，它与实际使用的过程模型无关。1986年美国卡内基—梅隆大学软件工程研究所首次提出能力成熟度模型（CMM），不过在当时它被称为过程成熟度模型。

　　基本思想

软件问题是由管理软件过程的方法不当引起的，所以新软件技术的运用并不会自动提高生产率和软件质量。

能力成熟度模型有助于软件开发组织建立一个有规律的、成熟的软件过程。改进后的过程将开发出质量更好的软件，使更多的软件项目免受时间和费用超支之苦。

　　能力成熟度模型的结构

成熟度等级（maturity levels）：一个成熟度等级是在朝着实现成熟软件过程进化途中的一个妥善定义的平台。5个成熟度等级构成了CMM的顶层结构。

过程能力（process capability）：软件过程能力描述，通过遵循软件过程能实现预期结果的程度。

关键过程域（key process areas，KPA）：每个成熟度等级由若干关键过程域组成。每个关键过程域都表示出一串相关的活动，当把这些活动都完成时所达到的一组目标，对建立该过程成熟度等级是至关重要的。

目标（goals）：目标概括了关键过程域中的关键时间，并可用于确定一个组织或项目是否已有效地实施了该关键过程域。

公共特性（common features）：CMM把关键实践分别归入下列5个公共特性之中：执行约定、执行能力、执行的活动、测量和分析以及验证实施。

关键实践（key practices）：每个关键过程域都用若干关键实践描述，实施关键实践有助于实现相应的关键过程域的目标。

　　

　　CMMI给企业带来的益处

生产力约有10%到20%的提升。

产品错误率约降低一个数量级。

对项目的预估与控制能力约提升40%-50%。

依据SEI的研究资料显示，成功公司软件产品的瑕疵，比不成功的公司少了1/3以上，客户满意度也因而提高。

能力成熟度每提升一级，约可降低5%-10%的开发成本。

　　能力成熟度等级

初始级
软件过程的特征是无序的，优势甚至是混乱的。几乎没有什么过程是经过定义的，项目能否成功完全取决于个人能力。
出于这个最低成熟度等级的组织，基本上没有健全的软件工程管理制度。每件事情都已特殊的方法来做。

可重复级
建立了基本的项目管理过程，以追踪成本、进度和功能性。必要的规范过程已经建立起来了，使得可以重复以前类似项目所取得的成功。

已定义级
用于管理和工程活动的软件过程已经文档化和标准化，并且已经集成到整个组织的软件过程中。所有项目都使用文档化的、组织批准的过程来开发和维护软件。这一级包含了第2级的所有特征。

已管理级
已收集了软件过程和产品质量的详细度量数据，使用这些详细的度量数据，能够定量地理解和控制软件过程和产品。这一级包含了第3级所有的特征。

优化级
通过定量的反馈能够实现持续的过程改进，这些反馈是从过程及对新思想和技术的测试中获得的。这一级包含了第4级的所有特征。

　　关键过程域

　　关键过程域是达到一个成熟度等级的必要条件。
　　除第一级成熟度之外，每个成熟度等级都包含几个关键过程域。关键过程域指明了为改进其软件过程，软件开发组织应该重视的区域，同时也指明了为达到某个成熟度等级所必须解决的问题。下面列出的关键过程域是累加的。

成熟度第2级
软件配置管理
软件质量保证
软件子合同管理
软件项目跟踪和监督软件。
项目计划。
需求管理。

成熟度第3级
同事复审
组间协作
软件产品工程
集成的软件管理。
培训计划。
软件过程定义。
组织过程焦点。

成熟度第4级
软件质量管理。
定量的过程管理。

成熟度第5级
过程变化管理。
技术变化管理。
错误预防。

　　应用CMM

　　CMM的用途主要有两个：软件开发组织用它来改进开发和维护软件的过程；政府或商业企业用它来评价与一个特定的软件公司签订软件项目合同的风险。

2.9 微软过程

规划阶段：

　　开展市场调查研究，结合公司战略形成产品的远景目标。

设计阶段：

　　根据产品远景目标，完成软件功能规格说明和总体设计，确定软件开发的主要进度。

开发阶段：

　　完成产品中所有构件的开发工作。

稳定阶段：

　　实行全面的内部和外部测试，最终形成可发布的RTM版本

发布阶段：

　　确认产品质量符合发布标准后，发布产品及相关消息。

递进式的开发策略：

　　解决问题的及时性分、不确定和变更因素可控性、缩短产品上市周期

　　

三、小结

　　软件过程是为了获得高质量软件产品所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。软件过程必须科学、合理，才能开发出高质量的软件产品。

　　按照软件生命周期全过程中应完成的任务的性质，在概念上可以把软件生命周期划分成问题定义、可行性研究、需求分析、概要设计、详细设计、编码和单元测试、综合测试以及维护8个阶段。实际从事软件开发工作是，软件规模、种类、开发环境、使用的技术方法等因素，都影响阶段的划分，因此，一个科学、有效的软件过程应该定义一组适合于所承担的项目特点的任务集合。

　　生命周期模型（即软件过程模型）规定了把生命周期划分成的阶段及各个阶段的执行顺序。本章介绍了5类典型的软件生命周期模型。瀑布模型历史悠久、广为人知，它的优势在于它是规范的、文档驱动的方法。这种模型的问题是，最终交付的产品可能不是用户真正需要的。

　　快速原型模型正是为了克服瀑布模型的缺点而提出来的。它通过快速构建一个可运行的原型系统，让用户试用原型并收集用户反馈意见的办法，获取用户的真实需求。

　　增量模型具有能在软件开发的早期阶段使投资获得明显回报和易于维护的优点。但是，要求软件具有开放结构是使用这种模型时固有的困难。

　　风险驱动的螺旋模型适用于大规模的内部开发项目，但是，只有在开发人员具有风险分析和排除风险的经验及专门知识时，使用这种模型才会获得成功。

　　当使用面向对象范型开发软件时，软件生命周期必须是循环的。也就是说，软件过程必须支持反馈和迭代。喷泉模型是一种典型的适合于面向对象范型的过程模型。

　　能力成熟度模型（CMM），是改进软件过程的一种策略。它的基本思想是，因为问题是管理软件过程的方法不恰当引起的，所以运用新软件技术并不会自动提高软件生产率和软件质量，应当下大力气改进对软件过程的管理。CMM以增量方式逐步引入变化，它明确地定义了5个不同的成熟度等级，一个软件开发组织可用一系列小的改良性步骤迈入更高的成熟度等级。

　　每个软件开发组织都应该选择适合本组织及所要开发的软件特点的软件生命周期模型。这样的模型应该把各种生命周期模型的合适特性有机地结合起来，以便尽量减少它们的缺点，充分利用它们的优点。
　　