软件过程模型与软件项目组织

软件过程模型(móxíng)与软件项目组织软件生存周期软件过程模型编码修正(xiūzhèng)模型瀑布模型原型实现模型演化过程模型基于构件的开发模型形式化开发过程模型与项目组织共七十一页软件生存(shēngcún)周期软件生存周期是软件产品或系统从形成概念开始，经过研制，交付使用，在使用中不断增补修订，直到最后被淘汰，让位于新的软件产品的全过程。对软件生存周期的不同划分，形成了不同的软件开发模型(móxíng)。软件生存周期的主要阶段制定计划(Planning)需求分析和定义(RequirementAnalysisandDefinition)软件设计(SoftwareDesign)程序编写(Coding,Programming)软件测试(Testing)运行/维护(Running/Maintenance)共七十一页a“quality”focusprocessmodelmethodstools过程规定方法(fāngfǎ)使用的顺序；要求交付的文档资料；为保证质量和适应变化所需要的管理；软件开发各个阶段完成的里程碑。方法提供了“如何(rúhé)做”的技术。工具为软件工程方法提供了自动的或半自动的软件支撑环境，CASE软件工程层次图共七十一页软件(ruǎnjiàn)过程过程过程是为实现一个给定目标而进行的一系列运作步骤。过程具有一系列的性质(xìngzhì)：时间性、并发性、嵌套性和度量性等。软件过程软件过程是开发和维护软件及其相关产品所涉及的一系列活动。过程是活动的集合；活动是任务的集合；任务是把输入转换为输出的操作。共七十一页软件(ruǎnjiàn)过程软件过程(guòchéng)是80年代后软件工程关注的焦点。软件过程是开发高质量软件所需要完成的任务的一个框架。软件工程是由软件人员在定义好的、成熟的软件过程框架中进行的。共七十一页软件(ruǎnjiàn)过程框架软件过程提供了一个公共过程框架；选择一个公共过程框架的依据是产品、人员和项目；在公共过程框架下可以建立一个软件开发的综合计划：若干框架活动适用于所有软件项目，而不在乎其规模(guīmó)和复杂性。若干不同任务的集合使得框架活动适应于不同软件项目的特征和项目组的需求。每一个任务集合都由任务、里程碑、交付物以及质量保证点组成。若干庇护性活动如软件质量保证、软件配置管理、测试与度量等，贯穿于整个过程模型之中。庇护性活动独立于任何一个框架活动，且贯穿于整个过程之中。共七十一页公共过程框架Commonprocessframework庇护性活动UmbrellaActivities

Projecttracking&controlFormaltechnicalreviewsQualityassuranceConfigurationmanagementDocumentationReusabilitymanagementMeasurementRiskmanagement框架活动FrameworkActivities任务集合(jíhé)worktasks工作任务workproducts交付物milestones&deliverables质量保证点QAcheckpoints共七十一页软件(ruǎnjiàn)过程分类软件过程可分为三大类：基本过程类：是构成软件生存周期主要部分的过程，包括获取、开发、实施、维护等过程。支持过程类：可穿插到基本过程中提供支持的一系列过程，包括配置管理、质量保证、验证、确认、评审等过程。组织过程类：一个(yīɡè)组织用来建立、实施一种基础结构、并不断改进该基础结构的过程，包括管理、改进、培训等过程。共七十一页软件(ruǎnjiàn)过程模型软件(ruǎnjiàn)过程模型是软件(ruǎnjiàn)过程的抽象表示。一个软件过程模型是软件开发全部过程、活动和任务的结构框架。它能直观表达软件开发全过程，明确规定要完成的主要活动、任务和开发策略。软件过程模型也常称为软件开发模型。共七十一页软件过程(guòchéng)模型过程模型定义了：特定问题和应用的开发过程中将遵循的步骤(bùzhòu)；确定将用于表示问题和解的那些成分的类型；利用这些成分表示与问题解决有关的抽象；直接得到问题的结构。过程模型的选择影响到设计方法、编码语言和测试和维护技术的选择。共七十一页软件过程(guòchéng)模型编码修正模型（CodeandFixModel）瀑布模型（WaterfallModel）快速原型法（Rapidapplicationdevelopment）增量开发(kāifā)模型（TheIncrementalModel）螺旋模型（TheSpiralModel）构件开发模型（Component-BasedDevelopment）形式化开发模型（TheFormalMethodsModel）第四代开发技术（FourthGenerationTechniques）共七十一页编码修正(xiūzhèng)模型从一个大致的想法开始工作，然后(ránhòu)经过非正规的设计、编码和测试，最后完成全部工作。可能有或可能没有规格发布（可能）共七十一页编码修正(xiūzhèng)模型好处：成本可能很低。只需要很少的专业知识，任何写过程序的人都可以。适用于一些非常小的、开发完后就会很快丢弃(diūqì)的软件。缺点：对于规模稍大的项目，采用这种模型使项目难以控制。共七十一页瀑布(pùbù)模型共七十一页瀑布(pùbù)模型所有过程模型的鼻祖。----Royce,1970基本思想是把软件开发过程划分成若干阶段，各个阶段相当于瀑布中的一个台阶，把软件过程比喻成瀑布中的流水，暖流，在这些台阶中由上向下奔流。瀑布模型每个阶段的任务相对独立，便于不同人员分工协作，从而降低了整个软件开发工程的困难程度(chéngdù)。在软件的生存期的每个阶段都采用科学的管理技术和良好的方法与技术，而且每个阶段结束之前，都从技术和管理两个角度进行严格的审查，经确认之后才开始下一阶段工作。瀑布模型适合于结构化开发方法。共七十一页结构化分析过程(guòchéng)共七十一页问题(wèntí)定义和可行性研究确定要开发软件系统的总目标。给出功能、性能、接口等方面的要求，完成该软件任务的可行性研究。估计可利用的资源(计算机硬件，软件(ruǎnjiàn)，人力等)、成本、效益、开发进度。制定出完成开发任务的实施计划,连同可行性研究报告，提交项目管理部门审查。共七十一页需求(xūqiú)分析对待(duìdài)开发软件提出的需求进行分析并给出详细的定义。编写软件需求说明书或系统功能说明书及初步的系统用户手册。提交管理机构评审。共七十一页软件设计总体设计——“如何解决问题”可以列出多种解决方案进行比较把各项需求转换成软件的体系结构。结构中每一组成部分都是意义明确的模块，每个模块都和某些需求相对应详细(xiángxì)设计—对每个模块要完成的工作进行具体的描述，为源程序编写打下基础编写设计说明书，提交评审。共七十一页程序(chéngxù)编写把软件设计转换成计算机可以接受的程序代码，即写成以某一种特定(tèdìng)程序设计语言表示的“源程序清单”。写出的程序应当是结构良好、清晰易读的，且与设计相一致的。共七十一页软件测试单元测试：查找各模块在功能和结构上存在的问题并加以纠正(jiūzhèng)。组装测试：将已测试过的模块按一定顺序组装起来。按规定的各项需求，逐项进行有效性测试，决定已开发的软件是否合格，能否交付用户使用。共七十一页运行(yùnxíng)维护改正性维护：运行中发现了软件中的错误需要修正。适应性维护：为了适应变化了的软件工作环境，需做适当变更。完善性维护：为了增强(zēngqiáng)软件的功能需做变更。共七十一页瀑布模型(móxíng)的特点里程碑或基线驱动，或者说是文档驱动。每个阶段必须完成规定的文档；每个阶段结束前完成文档审查,及早改正错误。是一种严格线性的、按阶段顺序的、逐步细化的过程模型（开发模式），阶段间具有顺序性和依赖性。过程逆转性很差或者说不可逆转，因为上流的错误会在下流进行发散性传播，逆转会延误工期(gōngqī)，增加成本。共七十一页选择瀑布模型(móxíng)的条件开发时间内需求没有(méiyǒu)或很少变化。分析设计人员对应用很熟悉。低风险项目，对目标和环境很熟悉。用户使用环境很稳定。共七十一页瀑布模型的适用(shìyòng)场合当有一个稳定的产品定义和很容易被理解的技术解决方案时，可以采用纯瀑布(pùbù)模型。当你对一个定义得很好的版本进行维护或将一个产品移植到一个新的平台上，可以采用瀑布模型。在质量需求高于成本需求和进度需求的时候，可以采用瀑布模型。共七十一页瀑布(pùbù)模型的缺陷在项目开始的时候，用户常常难以清楚地给出所有需求；用户与开发人员对需求理解存在差异。很少软件项目按照顺序模型进行，不能很好地支持迭代。缺乏灵活性，因为瀑布模型确定了需求分析的绝对重要性，但是在实践中要想获得完善的需求说明是非常(fēicháng)困难的，导致“阻塞状态”。反馈信息慢，开发周期长。只有到了整个项目的后半段时间，客户才能看到软件的模样。一个没有及时发现的错误，可能导致灾难。虽然存在不少缺陷，瀑布模型经常被嘲笑为“旧式的”，但是在需求被很好地理解的情况下，仍然是一种合理的方法。共七十一页瀑布(pùbù)模型变种：V型模型该方法(fāngfǎ)是对瀑布模型的修正，强调了验证活动共七十一页瀑布(pùbù)模型变种：生鱼片模型把阶段重叠起来的瀑布模型起源于日本硬件(yìnɡjiàn)开发模型（富士通—施乐）可行性研究需求分析总体设计详细设计编码和调试系统测试共七十一页瀑布(pùbù)模型变种：生鱼片模型传统的瀑布模型强调阶段之间最小的重叠，而生鱼片模型强调大幅度的重叠，即在需求分析(fēnxī)完成之前就可以进行架构设计和部分详细设计。纯瀑布模型强调在任意两个阶段交接时，文档从一个团队交给另一个完全隔离的团队，但是如果一个团队完成各个阶段任务时，可以没有那么多文档。问题：缺点是什么？生鱼片模型因为阶段重叠，因而里程碑不明确，很难有效地进行过程跟踪和控制。共七十一页瀑布模型变种(biànzhǒng)：具有子项目的瀑布模型纯瀑布模型的一个问题是必须完成全部的总体设计后才能进行详细(xiángxì)设计，但是，整个系统中有些部分可能有些特殊性，可以有自己的步骤，即将这些部分划分为为子项目。问题：该模型有何问题？这种方法的主要风险是相关性无法预料。共七十一页瀑布模型变种：能够(nénggòu)降低风险的瀑布模型纯瀑布模型(móxíng)要求在开始总体设计前，必须将用户的所有需求都搞清楚，但是实际中是很困难的。可降低风险的瀑布模型是在顶端，即需求分析和总体设计阶段引入螺旋以便降低风险。在该螺旋中，先开发一个用户界面原型，采用系统情节串联图版（systemstoryboarding）引导用户提出需求，记录用户与系统的交互操作方式，或者采用其它需求获取方法。共七十一页听取用户意见建造/修改原型用户测试运行原型原型(yuánxíng)模型PrototypeModel共七十一页建立(jiànlì)原型目标开发(kāifā)原型定义原型功能评估原型原型开发过程原型规划框架定义可执行原型评估报告共七十一页原型(yuánxíng)模型分类原型是项目系统中的一个方面或者多个方面的工作模型。抛弃型原型：用于试验某些概念，试验完系统将无用处进化型原型：原型系统不断被开发(kāifā)和被修正，最终它变为一个真正的系统。共七十一页原型模型(móxíng)的基本思想有一个原型，描述了系统的主要功能(gōngnéng)。通过人机交互，让双方了解目标系统的操作。有一个可运行的子集，用户可以评价需求和设计。利用线性系统，不断演化形成最终系统。降低了成本，及早发现错误、修改量小、开发周期短。共七十一页原型模型(móxíng)的特点原型驱动。优点：从实践中学习改善沟通和用户(yònghù)参与使部分已知需求清晰化展示描述的一致性和完整性提高系统的实用性、可维护性共七十一页选择原型(yuánxíng)模型的条件适用于用户驱动(qūdònɡ)的系统，即需求模糊或随时间变化的系统。已有产品或产品的原型，只需客户化的工程项目简单而熟悉的行业或领域有快速原型开发工具进行产品移植或升级共七十一页原型模型(móxíng)的缺点用户有时误解了原型的角色，例如他们可能误解原型应该和真实系统一样可靠。缺少项目(xiàngmù)标准，进化原型方法有点像编码修正。缺少控制，由于用户可能不断提出新要求，因而原型迭代的周期很难控制。额外的花费：研究结果表明构造一个原型可能需要10%额外花费。原型法要求开发者与用户密切接触，有时这是不可能的。例如外包软件。共七十一页原型(yuánxíng)模型的缺点虽然有问题存在，但是原型仍是软件开发的一个有效范型。关键是定义(dìngyì)开始的游戏规则，即用户与开发者两方面必须达成一致：原型被建造仅是为了定义(dìngyì)需求，之后被抛弃（或至少部分被抛弃），实际的软件在充分考虑了质量和可维护行之后才被开发。共七十一页演化软件(ruǎnjiàn)过程模型人们已经越来越认识到软件就象所有复杂系统一样要经过一段时间的演化。业务和产品需求随着开发的发展常常发生改变，想找到最终(zuìzhōnɡ)产品的一条直线路径是不可能的。紧迫的市场期限使得难以完成一个完善的软件产品，但可以先提交一个有限的版本以对付竞争或商业的压力；只要核心产品或系统需求能够很好地理解，而产品或系统的细节部分可以进一步定义。共七十一页演化软件过程(guòchéng)模型演化(yǎnhuà)模型是利用一种迭代的思想方法，它的特征是使软件工程师渐进地开发,逐步完善软件版本。增量模型(IncrementalModel)螺旋模型(SpiralModel)迭代模型（IterativeModel）共七十一页calendartimeanalysisdesigncodetestSystem/informationengineeringincrement1deliveryof1stincrementCoreproductanalysisdesigncodetestincrement2deliveryof2ndincrementMorefeaturesandfunctionalityanalysisdesigncodetestanalysisdesigncodetestincrement3increment4deliveryof3rdincrementdeliveryof4thincrement

Makesabetteruseofresources.增量(zēnɡliànɡ)模型（IncrementalModel）共七十一页增量模型(móxíng)的特点任务或功能模块驱动，以功能递增的方式进行软件开发，可以分阶段提交产品；融合了线性顺序模型(móxíng)的基本成分和原型实现的迭代特征；能较快地产生可操作的系统；在每一步递增中，均发布一个新的增量，把用户/开发者的经验结合到不断求精的产品中；每个增量的开发没有必要使用相同的过程；可改善测试效果和降低软件开发总成本。共七十一页增量(zēnɡliànɡ)模型的特点增量(zēnɡliànɡ)过程模型与原型实现模型，本质上都是迭代的。两者区别在：增量模型强调每一个增量发布一个可操作的产品。早期的增量提供了为用户服务的功能和给用户评价的平台。共七十一页选择增量(zēnɡliànɡ)模型的条件客户接受分阶段交付。对应用领域不熟悉，难以一步到位。用户(yònghù)可参与到整个软件开发过程中。有较好的类库和构件库。共七十一页增量模型存在(cúnzài)的问题增量应该相对较小，每个增量应该包含一定的系统功能。所以，很难把用户的需求映射到适当规模的增量上。大多数系统需要一组在系统许多部分都会用到的基本服务。但由于增量实现前，需求不能被详细定义，所以，明确所有增量都会用到的基本服务就比较困难。若软件系统的组装和拆卸(chāixiè)性不强，或开发人员全局把握能力不高，或客户不同意分阶段提交产品等，均不合适。共七十一页螺旋(luóxuán)模型（SpiralModel）Spiral模型（Boehm，1988提出）综合了原型模型的迭代特征和瀑布模型的控制和系统化的优点。增加了风险分析，是以风险为导向(dǎoxiànɡ)的生命期模型。从一个小范围的关键中心地带开始寻找风险因素，制定风险控制计划，并交付给下一步骤，如此迭代，每次迭代将项目扩展到一个更大的规模。共七十一页评审提交划分风险分析原型1仿真、模型、基准需求计划，生存期计划操作概念原型2风险分析软件需求需求确认开发计划风险分析原型3软件产品设计设计确认与验证集成与测试计划风险分析可运行原型详细设计单元测试编码集成与测试验收测试实现计划下一阶段开发、验证下一代产品确定目标、方案和限定评估方案，识别、消除风险累积成本按步骤推进共七十一页螺旋(luóxuán)模型的特点螺旋模型沿着螺线旋转，在四个象限上分别表达了四个方面的活动(huódòng)。制定计划——确定软件目标，选定实施方案，弄清项目开发的约束条件。风险分析——分析所选方案，考虑如何识别和消除风险。实施工程——实施软件开发。客户评估——评价开发工作，提出修正建议。共七十一页螺旋(luóxuán)模型的特点把软件开发过程组成为一个逐步细化的定义周期（螺旋周期）序列，每经历一个周期，系统就得到进一步的细化和完善；本质上，具有上述特征(tèzhēng)的螺旋是一直运转的,直到软件退役。有时这个过程处于睡眠状态，但任何时候出现了改变，过程都会从合适的入口点开始；紧密围绕开发中的风险问题，用风险分析推动软件设计向深一层扩展、求精；强调持续地判断、确定和修改用户任务目标，并按成本、效益来分析候选的软件产品性质对任务目标的贡献；可结合采用多种软件开发方法，但究竟结合哪一种方法仍由风险分析来决定。共七十一页螺旋(luóxuán)模型对于大型软件系统的开发，螺旋模型是一个很现实(xiànshí)的方法。优势：随着迭代的增加（成本的增加），风险程度随之降低缺陷：比较复杂，需要相当的风险评估技术，且成功依赖于这种技术。共七十一页基于(jīyú)构件的开发面向对象技术为软件工程的基于构件的模型提供了技术框架。面向对象模型中强调类的创建，类封装了数据(shùjù)和用于操作该数据(shùjù)的方法。通过合适的设计和实现，类可以在系统中复用。共七十一页基于(jīyú)构件的软件开发－－CBSDCBSD的兴起主要是源于如下四个不同的背景：研究方面：现代软件工程思想，特别(tèbié)是对复用技术的强调。产业方面：支持用构件建造GUI、数据库和应用的其他部件的一些理论上质朴但实际可用的技术的成功。政治方面：某些主流互操作技术，如CORBA、COM和EJB的开发者的推动。在软件界：面向对象技术的广泛使用，提供了建造和使用构件的概念基础和实用工具。共七十一页基于(jīyú)构件的软件开发－－CBSDCBSD提供了一种自底向上的、基于预先定制包装好的软件构件(gòujiàn)来构造应用系统的途径，当前讨论的重点主要局限于基于COM、CORBA和EJB等的二进制构件(gòujiàn)。但是，没有理由仅仅从这个局限的角度来看待构件(gòujiàn)，也不应该仅仅是局限于此，应该涉及整个软件生存周期。共七十一页基于(jīyú)构件的软件开发共七十一页基于构件的软件工程(ruǎnjiànɡōnɡchénɡ)(CBSE)过程模型构件开发分析(fēnxī)设计编程测试领域分析系统测试构件提交领域专家经验现有系统资料领域构件需求构件/构架库领域构架领域构件系统开发系统专用构件应用系统构件生产线领域构架领域构件问题域用户需求系统生产线系统组装分析设计编程构架细化专

用

构件

开

发分析设计编程测试共七十一页4GT4GT包含一系列的软件工具(gōngjù)，其共同点：能使软件开发人员在高层次上规约软件的某些特性，然后，工具(gōngjù)根据开发者的规约自动生成源代码。共七十一页4GT模型(móxíng)需求(xūqiú)分析设计策略用4GL实现测试共七十一页4GT模型(móxíng)支持者：减少开发，提高软件的生产率。反对者：源代码“低效”，系统可维护性令人怀疑。结论：4GT的使用对很多的领域而言是一种可行的途径。对中小型应用(yìngyòng)，可以提高生产率，降低分析和设计的工作量。共七十一页形式化方法模型(móxíng)思想形式化方法的主要目的是要把软件开发过程建立在严密可行的数学基础之上，从而提高软件质量和软件生产率。采用事后的或并行的辅助手段，对系统的性质进行严格的验证。集成到软件开发过程中，希望在严格的形式系统的基础上，实现从需求规约(guīyuē)到程序代码的转换和过渡。共七十一页形式化规格(guīgé)说明与需求(xūqiú)比较后修正形式化开发记录变换n变换2变换1测试系统需求目标系统形式化方法模型共七十一页形式化开发(kāifā)模型与瀑布模型的本质区别：软件需求描述被精练成一个数学符号表达(biǎodá)的详细的形式化描述。设计、实现和测试等开发过程被一个转换的开发过程代替，在这个转换过程中，形式化描述经过一系列转换变成一个可执行程序。共七十一页形式化开发(kāifā)模型优点：在软件开发中，形式化方法提供了一种机制，能够消除其它模型难以克