第1章软件过程课件

软件工程与测试基础

——软件过程与方法

引子：罗马不是一天建成的2013年IT界最大的新闻是什么？22010年9月，面对苹果iphone的威胁，Nokia董事会任命埃洛普为新的CEO。此前，埃洛普任微软的BusinessDivision部门的总管，负责Office2010的开发。3第一步：自废武功？埃洛普上任后就做出了很多备受争议的决策：宣布彻底放弃经典的Symbian系统中止了前任诺基亚CEO规划的诺基亚Android手机计划放弃了与intel合作开发的MeeGo系统（搭载此系统的N9手机已经研发成功并上市）4第二步：执子之手2011年，宣布诺基亚与微软公司达成战略合作伙伴，将在所有智能手机上都采用WindowsPhone7操作系统。5微软坑我千百遍但由于：微软在WP7的研发和发布等发面，并未给予Nokia特别的优待；微软的WindowsPhone系统与原有的Symbian系统并不兼容（连导入/导出通讯录都很麻烦）；微软在2011年推出WindowsPhone7后不久，就正式宣布运行WP7的手机无法升级到即将发行的WP8系统。到2013年1季度，WP手机的市场占有率只有2.9%(Anroid74%,iOS14%）6据说是微软的WP8发布会邀请函。为什么主角不是Nokia？7我待微软如初恋一直到收购前，Nokia一直坚持WP独占的战略（WP全部销量中Nokia占70%以上）。相比之下，其他主要的竞争对手三星、HTC及Sony等都采取了多头下注（同时开发Android和WP手机）的策略。8结局：如愿以偿？从2010年埃洛普担任CEO以来，Nokia的手机市场占有率从30%以上一路下跌到不到2%，股价从10.1美元一路下跌到3.9美元。9月3日，微软正式宣布将收购Nokia手机部门。在此之前（8月底），微软CEO鲍尔默正式宣布将于一年内退休。埃洛普随着Nokia的收购回到了微软，并成为了下一任CEO的有力竞争者……9软件过程与方法一、软件过程二、软件过程模型三、敏捷开发与统一过程四、小结10一、软件过程过程与过程管理软件过程定义软件过程要素核心软件活动11还记得吗？软件工程的构成？以质量为中心过程方法工具价值观和过程是“道”，方法和工具是“术”！121.1过程与过程管理过程：也称业务过程，指为客户创造价值的一系列相互关联、有组织的活动或任务的集合。管理学意义上的过程是有明确目的性的：为客户（或企业）创造价值过程的特点：可确定性：有明确的输入、输出和边界；顺序：构成过程的活动，必须在时间和空间里具有确定的顺序；客户：过程的结果必须有接收者——客户。增值：在过程中发生的转换必须为接收者增加价值，无论接收者是在过程的上游还是下游。131.1过程与过程管理过程管理：找出完成一项业务所需的合理的活动（步骤），并针对这些活动的作业流程进行管理。过程管理的目标：确保企业中各种商业活动的执行成果能具有一定的水平和精确度，确保能持续改善活动的进行方式，串连活动的作业流程让企业能保持市场上的竞争力。141.1过程与过程管理过程管理的任务：发现、去除非增值活动，简化过程通过合理安排活动顺序提高过程效率适当改变过程以适应环境变化对过程执行情况加以监控，寻找过程中的错误、薄弱、低效环节并加予以纠正151.2软件过程定义软件过程：构建、维护软件产品时所执行的一系列活动、动作和任务的集合。活动动作任务过程161.3软件过程要素活动：组成软件过程的最主要的宏观步骤。例如：需求分析、设计、编码、发布等。动作：对活动进一步细分的得到的步骤。例如设计活动，可以细分分为总体设计、模块设计等多个动作。任务：具体的工作步骤。例如：编写一个具体的软件模块等。171.4核心软件活动所有合理的软件过程都包含一些共同的必要的活动（步骤），这些活动我们称为核心软件活动。有哪些核心软件活动呢？如果让我们来帮某个人A盖一栋房子，会怎么做呢？：决定要不要盖？能不能盖？了解A想要什么样的房子？制定计划（什么时候开始设计，什么时候开始施工，什么等等设计房屋（外观、结构等等）施工与监理（有没有偷工减料？是否按照设计施工？）交付181.4核心软件活动软件过程通常包括下列五个核心软件活动：需求分析：通过与客户的沟通协作，了解客户的真实需要，决定软件特性和功能，制定项目目标。设计：通过科学的方法来研究、理解软件需要处理的现实问题，构造并（向客户和其他开发人员）展现具体解决方案。191.4核心软件活动核心软件活动（续）：编码与测试：实际编写代码、验证代码的正确性运行与部署：将软件交付用户使用。通常用户会对软件进行一段时间的试用，并给出反馈意见维护：修复用户使用过程中发现的软件缺陷，或者根据用户使用意见对软件进行改进上述活动之间并不一定是简单的线性关系，而是可能存在反复的迭代。20二、软件过程模型软件过程模型与过程流瀑布模型原型开发模型螺旋模型增量过程模型212.1软件过程模型与过程流

软件过程模型是从过程执行这一角度对软件过程的简化描述。“模型的本质在于简化”222.1软件过程模型与过程流

可行性研究需求分析概要设计详细设计实现组装测试验收测试使用与维护退役23软件过程模型示例2.1软件过程模型与过程流过程流（模型）是最主要的一类软件过程模型。过程流描述了如何在执行顺序和执行时间这一层面上，组织软件过程中的活动。几种主要的过程流及典型过程模型：线性过程流：瀑布模型迭代过程流：原型开发模型演化过程流：螺旋模型并行过程流：混合过程流：增量模型242.1软件过程模型与过程流沟通需求策划建模编码测试部署运行线性过程流沟通需求策划建模编码测试部署运行迭代过程流沟通需求策划建模编码测试部署运行演化过程流沟通需求策划建模编码测试部署运行并行过程流252.2瀑布模型瀑布模型（waterfallmodel）是由W.Royce于1970年提出来的。又称为软件生存周期模型。瀑布模型严格按照软件生存周期各个阶段来进行开发，上一阶段的输出即是下一阶段的输入，并强调每一阶段的严格性。它规定了各阶段的任务和应提交的成果及文档，每一阶段的任务完成后，都必须对其阶段性产品（主要是文档）进行评审，通过后才能开始下一阶段的工作。因此，它是一种以文档作为驱动的模型。262.2瀑布模型软件生存周期：软件从定义开始，经过开发、使用和维护，直到最终退役的全过程称为软件生存周期。瀑布模型将软件生命周期分成软件定义、软件开发、运行、维护及退役五个时期组成。而每个时期又可以进一步划分成若干阶段。272.2瀑布模型的结构可行性研究特点：阶段间具有顺序性和依赖性推迟实现质量保证需求分析概要设计详细设计实现组装测试验收测试使用与维护退役282.2瀑布模型的变形-V模型可行性研究需求分析(验收测试计划)概要设计(组装测试计划)详细设计(单元测试计划)编码与调试单元测试集成测试系统测试验收测试运行与维护V模型强调了质量保证活动,特别是测试与其它动作之间的关系292.2瀑布模型的优点可强迫开发人员采用的规范方法；严格规定了每一阶段必须提交的文档；要求每一阶段交付之产品都必须经过质量保证小组的仔细审查；清晰区分了逻辑设计与物理设计，尽可能推迟程序的物理实现。“一种文档驱动的模型”提供了软件开发的基本框架，有利于大型软件开发过程中人员的组织、管理，有利于软件开发方法和工具的研究与使用，因此，在软件工程中占有重要的地位。302.2瀑布模型的不足

瀑布模型要求在项目开始的需求分析阶段就能够完整的得到客户的所有需求。但在实际中客户通常难以清楚地描述出所有的需求；同时，客户自身的需求也可能会随着时间的变化而发生变化。1988年的发表的一份关于软件项目的研究报告指出，平均每个项目有25%左右的需求功能点变化；1997年的另一份研究报告中，需求功能点的变化率则达到了35%-50%。客户要到项目接近尾声的验收阶段才能够看到实际的程序执行效果。如果这时才发现程序和客户实际要求有重大偏差，就可能会造成重大的损失。这两个问题构成了瀑布模型的致命弱点。312.2瀑布模型的不足2001年发表的一份论文，对1027个失败软件项目的失败原因作了研究。其中82%的项目认为采用瀑布模型是导致失败的罪魁祸首！很多采用瀑布模型的项目在开发时为了应对可能的变化，采取了在软件产品中尽可能包含更多功能的方法，这构成了极大的浪费。在一份研究发现，在采用瀑布模型的开发项目中，有45%以上的功能最终根本就没有被使用，有19%以上的功能几乎没有被使用。也就是说，为了开发这将近65%的功能而所作的工作完全是浪费！不过，当需求非常明确时（比如，山寨某个已知的软件），瀑布模型还是个很有用的模型。322.3原型开发模型针对瀑布模型的下列缺陷，提出了原型开发模型：在瀑布模型中，项目开发者在需求分析阶段只能通过文字和图形来向用户展示软件功能，不够直观，很容易造成误解用户直到最后阶段才能看到软件操作界面和实际功能。所谓原型，就是软件的一个模拟的可执行界面。用户可在原型上进行操作，直观的感受软件的执行效果。原型开发就是软件开发人员根据用户提出的软件基本需求快速开发一个原型，向用户展示软件界面和功能。在征求用户对原型的评价意见后，进一步改进、完善原型，如此迭代，直到软件开发人员和用户都确认软件系统的需求并达成一致的理解为止。软件需求确定后，便可进行设计，编码、测试等以后的各个开发步骤。332.3原型开发模型生成原型测试分析定义系统需求系统设计程序设计含原型化的软件生存期原型化运行和维护编码342.3原型开发模型的优点原型的开发和评审是系统分析员和用户/客户共同参予的迭代过程，这种迭代过程有利于双方的充分理解和沟通。原型开发模型比瀑布模型更符合人们认识事物的过程和规律，项目成员能够更清晰的理解用户实际需求。如果原型的开发语言和实际软件相同，那么它的若干高质量的程序片段和开发工具也可被用于工作程序的开发。352.3原型开发模型的缺点

原型开发模型要求开发者和用户在一段时间内紧密配合、共同参与完成原型系统的开发，特别是需要用户的及时反馈。如果用户对此不够重视，那么原型开发的意义也就大打折扣了。原型的快速构造容易让用户误以为实际软件的开发也是可以很容易、很快就完成的，或者要求开发者直接将原型稍加修改使之成为实际运行的产品。而实际上，为了快速开发原型，开发者往往会牺牲软件质量和可维护性而采取了最快速的开发手段，因此实际的高质量软件产品需要抛弃原型从头开发。如果不能够充分的向客户解释这一点的话，就容易导致软件开发人员和用户之间产生矛盾。原型开发模型的另一缺点在于，无法响应开发后期需求变化的问题。362.4原型开发工具过去普遍采用快速开发工具，如VB、Delphi等软件来进行原型开发这些工具本身也是高级程序语言，可以用于一般的软件开发，容易使客户产生困惑现在多使用专门的交互式原型开发工具：只能开发出交互式的图形界面，不具备数据库访问等完整的程序开发功能。不需要编程基础，简单培训即可使用，降低了对人员的要求372.4螺旋模型螺旋模型是一种演化式的软件过程模型。它结合了原型开发模型的迭代性和瀑布模型的系统性和可控性特点。它把软件开发过程转化成了了软件的版本演进过程。通过多次的反复迭代演化，一个版本一个版本的逐步完善软件，提高了软件开发对需求变化的适应能力它在模型中明确加入了风险控制活动，每次迭代时都要考虑可能的风险，并采取措施来降低风险。交付并不意味着软件过程的结束，它只是上一次迭代的结束和下一次迭代的开始。整个软件过程贯穿软件产品的整个生命周期。382.4螺旋模型评审提交线对目标、可选方案和约束的确定制定计划预估可选方案，明确并解决风险风险分析开发验证下一级产品实施工程规划下阶段工作客户评估第一圈产生产品规格说明原型1风险分析需求计划和生存周期计划操作的概念需求评价第二圈产生一个用于开发的原型原型2风险分析软件需求需求有效性验证验收测试计划建模需求精化计划第三圈产生软件产品的初始版本原型3风险分析组装测试计划设计验证与确认产品设计模拟开发计划第四圈产生软件产品比较完善的新版本风险分析操作原型详细设计编码单元测试组装测试验收测试运行维护评价实现计划顺时针为进展方向392.4螺旋模型螺旋模型的每一个迭代周期都包括计划（需求定义）、风险分析、工程实现和评审4个阶段。计划（需求定义）在第一轮迭代周期中，利用需求分析技术理解应用领域，获取初步用户需求，制定项目开发计划（即整个软件生命周期计划）和需求分析计划。在以后的每个迭代周期中，根据用户和开发人员对上一周期工作成果评价和评审，修改、完善需求，明确下一周期软件开发的目标、约束条件，并据此制定新一轮的软件开发计划。402.4螺旋模型风险分析根据本轮制定的开发计划，进行风险分析，评估可选方案，并构造原型进一步分析风险，给出消除或减少风险的途径。此时根据风险分析的结果决策项目是否继续。所以，螺旋模型是一个风险驱动的模型。工程实现在前几轮迭代周期中，构造的原型进行需求建模或进行系统模拟在后面的迭代周期中，逐步构造、完善实际的软件系统。412.4螺旋模型用户评价与阶段评审将原型或者软件产品提交用户使用并征求改进意见。开发人员应在用户的密切配合下进一步完善用户需求，直到用户认为原型可满足需求，或对软件产品设计进行评价或确认等。就这样，螺旋模型从第一个周期的计划开始，一个周期、一个周期地不断迭代，直到整个软件生命周期结束。螺旋模型中的每个迭代周期都不应该太长（一般是2-8周左右）。太短了则每轮实际工作量太少，无法得到有意义的结果太长了，无法及时得到用户的反馈，也就失去了迭代演化的意义。422.4螺旋模型的优点支持用户需求的动态变化。支持软件系统的可维护性，每次维护过程只是沿螺旋模型继续多走一两个周期。这符合人们认识现实世界和软件开发的客观规律。原型可看作形式的可执行的需求规格说明，易于为用户和开发人员共同理解，还可作为继续开发的基础，并为用户参与所有关键决策提供了方便。开发者和用户共同参与软件开发，可尽早发现软件中的错误。螺旋模型特别强调原型的可扩充性和可修改性，原型的使用贯穿整个软件生存周期，这将有助于提高目标软件的适应能力。既保持瀑布模型的系统性、阶段性，又可利用原型评估降低开发风险。螺旋模型为项目管理人员及时调整管理决策提供了方便，进而可降低开发风险。432.4螺旋模型的缺点及适用范围螺旋模型的缺点：如果每次迭代的效率不高，致使迭代次数过多，将会增加成本并推迟提交时间；使用该模型需要有相当丰富的风险评估经验和专门知识，要求开发队伍水平较高。螺旋模型适用场合：支持需求不明确、特别是大型软件系统的开发，并支持面向规格说明、面向过程、面向对象等多种软件开发方法，是一种具有广阔前景的模型。442.4增量过程模型增量过程模型是螺旋模型基础上的改进。前面讲的几种模型，过程流本质都是顺序执行。也就是说，上一个活动执行完才能执行下一个活动这种顺序执行往往会导致项目中产生“阻塞状态”，即由于任务之间的依赖性，项目的部分成员要等待另一些成员的工作完成。94年的一项研究表明，在很多项目中，花在等待上的时间反而超过了花在实际工作上的时间！增量开发模型采用并行的方式来解决这种阻塞带来的浪费问题。452.4增量过程模型软件功能和特征项目时间第一个增量第二个增量第三个增量第n个增量沟通策划建模（分析、设计）构建（编码、测试）部署（交付、反馈）46三、敏捷开发与统一过程敏捷开发的背景敏捷开发宣言什么是敏捷敏捷开发模型XP和Scrum统一过程473.1敏捷开发的背景在现代市场经济条件下，计算机软件系统总是面临着不断的变化：市场环境变化新竞争对手出现新技术涌现这就导致软件开发和实施过程中，用户需求会不断变化1988年的发表的一份关于软件项目的研究报告指出，平均每个项目有25%左右的需求功能点变化；1997年的另一份研究报告中，这需求功能点的变化率则达到了35%-50%。483.1敏捷开发提出的背景传统的过程开发模型都是从管理者的角度来看待软件开发。因此，存在着重大缺陷：忽视变化的存在。过程阶段划分过细、过于死板，难于适应实际情况的变化。忽视了软件开发是一个智力密集型的工作，过分强调纪律和文档，导致人的创造性降低。忽视了人与人之间的直接交流。过多的书面交流既增加整个项目的时间成本，又导致了误解和沟通障碍的增加。过分注重过程。认为符合过程就能导致正确的结果。493.2敏捷开发宣言敏捷开发可以认为是一场“革命”，开发者对管理者的革命。敏捷开发试图将开发者的视角也加入到软件过程管理中来。2001年KentBeck等16位知名专家共同发起了敏捷联盟，并发表了“敏捷开发宣言”：个人与交流胜于开发过程和工具可运行的软件胜于面面俱到的文档客户协作胜于合同谈判响应变化胜于按部就班遵循计划注意，宣言中右边的各项并非没有价值，只是左边的各项价值更大503.3什么是敏捷敏捷的基本推动力：普遍存在的变化敏捷鼓励：使沟通更便利的团队结构和协作态度快速交付可运行产品而非中间文档客户以开发团队中的一员的身份参与项目根据实际情况灵活调整项目计划513.3敏捷对软件开发成本的影响研究表明，敏捷能明显降低：由于需求变化导致的那部分软件开发成本开发进度日程变更成本使用传统软件过程的变更成本使用敏捷过程的理想变更成本使用敏捷过程的实际变更成本523.3敏捷原则敏捷联盟提出了实现敏捷的12条原则：最优先要做的是通过尽早、持续的交付有价值的软件来使客户满意即使在开发的后期，也欢迎需求变更。敏捷过程利用变更为客户创造竞争优势经常交付可运行的软件，交付时间间隔越短越好在整个项目开发期间，业务人员和开发人员应天天在一起工作围绕有积极性的个人构建项目。团队内部最有效率的沟通方式是面对面交谈533.3敏捷原则（续）实现敏捷的12条原则（续）：可运行软件是进度的首要度量指标提倡可持续的开发速度不断的关注优秀技能和好的设计简单（使不必做的工作尽可能多的艺术）是必要的。最好的架构、需求和设计出自于自我组织的团队每隔一定时间，团队应反省如何才能更有效的工作，并相应调整自己的行为543.3敏捷开发中人的因素敏捷开发非常强调人的因素在软件项目开发中的重要性。特别的，敏捷开发强调团队及其成员应该具备下列要素：基本能力。包括软件开发和正确实施敏捷开发的能力。共同目标。团队成员必须瞄准同一个目标，即在承诺的时间内向客户提交能够可靠运行的软件或其增量。精诚合作。团队成员之间，以及团队和项目其他利益相关者（如用户、客户）之间必须精诚合作553.3敏捷开发中人的因素敏捷开发强调团队及其成员应该具备下列要素（续）：决策能力。项目团队在项目问题上必须有自主决策权。相互尊重和信任。具体体现就是良好、高效的沟通。不断学习。团队应从多种来源（包括过去的失败）中学习到经验。自我组织。团队自己组织自身、安排进度来完成项目，并对此负责。563.3敏捷过程模型在敏捷开发思想的指导下，业界提出了很多敏捷过程模型，其中影响较大的有：极限编程（eXtremeProgramming,XP）Scrum特征驱动开发（FDD）精益软件开发（LSD）敏捷统一过程（AUP）等等这里简要介绍一下极限编程和Scrum573.4极限编程策划设计编码测试测试驱动开发发布极限编程过程模型重构用例KISS原则单元测试持续集成面向对象开发方法583.4极限编程极限编程（XP）是使用最广泛的一种敏捷软件过程。XP定义了五个有重要意义的要素：沟通：强调口头的、面对面的交流简明：为了简化设计，只对当前的需要做设计。当设计需要改进时，使用重构来实现。反馈：通过测试、增量交付和持续集成等手段，快速获得反馈鼓励：鼓励符合极限精神的实践。例如，尽可能减少过度设计。尊重：敏捷团队应在内部成员之间，以及内部成员与其他利益相关者之间，灌输相互尊重的思想。减少推诿和扯皮，增加协作。593.4极限编程的缺点要求客户全程参与整个项目，这一点在实际中不容易做到不是所有的编程语言和工具都能良好的支持重构要求团队保持长期相对稳定对团队成员的能力、素质和自觉性要求较高对团队管理者的领导能力