软件工程第2章软件生存周期与软件过程

《计算机网络》课件制作人：谢希仁张磊博士副教授[e-mail]第2章软件生存周期与软件过程课件制作人：谢希仁2.1软件生存周期2.2软件生存期模型2.3问题定义2.4可行性研究2.5可行性论证报告的主要方面2.6项目计划课件制作人：谢希仁软件有一个孕育、诞生、成长、成熟、衰亡的生存过程。这个过程即为计算机软件的生存周期。一般说来，软件生命周期划分为三个时期：计划时期、开发时期、运行时期。计划时期划分为问题定义和可行性研究；开发时期又划分为需求分析、概要设计、详细设计、编码和测试阶段；运行时期主要是在运行中完成各类维护。2.1软件生存周期课件制作人：谢希仁问题定义可行性研究需求分析概要设计详细设计编码测试运行计划时期开发时期运行时期课件制作人：谢希仁2.1.1计划时期1.问题定义确定要开发软件系统的总目标。给出功能、性能、可靠性以及接口等方面的要求，系统定义。2.可行性研究估计可利用的资源(计算机硬件，软件，人力等)、成本、效益、开发进度。制定出完成开发任务的实施计划和解决方案,可行性研究报告。课件制作人：谢希仁2.1.2开发时期1.需求分析对待开发软件提出的需求进行分析并给出详细的定义。编写软件需求说明书或系统功能说明书及初步的系统用户手册。提交管理机构评审。课件制作人：谢希仁2.概要设计把各项需求转换成软件的体系结构，结构中每一组成部分都是意义明确的模块，每个模块都和某些需求相对应。编写概要设计说明书。3.详细设计对每个模块要完成的工作进行具体的描述，为源程序编写打下基础。编写详细设计说明书。课件制作人：谢希仁4.编码把软件设计转换成计算机可以接受的程序代码，即写成以某一种特定程序设计语言表示的“源程序清单”。写出的程序应当是结构良好、清晰易读的，且与设计相一致的。5.测试单元测试，查找各模块在功能和结构上存在的问题并加以纠正。组装测试，将已测试过的模块按一定顺序组装起来。按规定的各项需求，逐项进行有效性测试，决定已开发的软件是否合格，能否交付用户使用。课件制作人：谢希仁2.1.3运行时期运行时期的主要工作是维护改正性维护运行中发现了软件中的错误需要修正。适应性维护为了适应变化了的软件工作环境，需做适当变更。完善性维护为了增强软件的功能需做变更。课件制作人：谢希仁各阶段工作小结阶段关键问题结束标准问题定义问题是什么关于规模和目标的报告书可行性研究有可行的解系统的高层逻辑模型需求分析系统必须做什么系统逻辑模型总体设计概括地说，应该如何解决问题可能解法详细设计怎样具体实现编码规格说明课件制作人：谢希仁阶段关键问题结束标准编码和单元测试正确的程序模块源程序清单，单元测试方案和结果综合测试符合要求的软件综合测试方案和结果，完整一致的软件配置维护持久地满足用户需要的软件完整准确的维护记录课件制作人：谢希仁2.2软件生存期模型软件生存期模型是跨越整个生存期的系统开发、运作和维护所实施的全部过程、活动和任务的结构框架。软件开发模型是对软件过程的建模边做边改模型瀑布模型原型模型增量模型螺旋模型RUP过程敏捷过程极限编程微软过程模型课件制作人：谢希仁2.2.1边做边改模型遗憾的是，许多产品都是使用“边做边改”模型来开发的。在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改。课件制作人：谢希仁2.2.2瀑布模型1970年WinstonRoyce提出了著名的瀑布模型，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。该模型将基本的过程活动、描述、开发、有效性验证和进化，看成是一些界限分明的独立的过程阶段，如：需求描述阶段、软件设计阶段、实现阶段、测试阶段等。该模型也可以看成是软件的生命周期模型。该模型是计划驱动的，理论上，在开始工作之前，必须对所有的过程活动制定计划并给出进度安排。课件制作人：谢希仁2.2.2瀑布模型问题定义可行性研究需求分析概要设计详细设计编码测试维护计划时期开发时期运行时期课件制作人：谢希仁问题定义编码需求分析软件设计可行性研究运行与维护测试开发时期运行时期计划时期(目标与范围说明书)(可行性论证论告)(维护报告)(测试报告)(程序)(设计文档)(需求说明书)课件制作人：谢希仁瀑布模型的特点1．阶段间具有顺序性和依赖性关系顺序性的含义是必须待前一阶段的工作完成之后，才能进行下一阶段的工作。依赖性的含义是前一阶段的输出就是后一阶段的输入，只有前一阶段的输出正确，后一阶段的工作才有可能获得正确的结果。。课件制作人：谢希仁2．推迟实现实践表明，编码开始得越早完成开发工作所需要的时间反而越长。这是因为，前期阶段的工作没完全做好，就急于考虑程序实现，其结果导致大量返工，有时甚至产生无法弥补的问题，带来严重后果。课件制作人：谢希仁3．质量保证各阶段都必须完成规定的文档。完整、正确、合格的文档不仅是软件开发时期各类人员之间相互通信的媒介，也是软件维护的重要依据。各阶段结束前都要对所完成的文档进行评审，以便及时发现问题，改正错误。课件制作人：谢希仁瀑布模型的缺点（1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。（2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险。（3）早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。课件制作人：谢希仁2.2.3快速原型模型由于在项目开发的初始阶段人们对软件的需求认识常常不够清晰，因而使得开发项目难于做到一次开发成功，出现返工再开发在所难免。做两次或多次：需求分析原型开发与建模原型评价系统设计系统实现测用户反馈第一次只是试验开发，其目标只是在于探索可行性，弄清软件需求。第二次则在此基础上获得较为满意的软件产品。课件制作人：谢希仁快速原型模型特点在需求定义之前，需要快速构建一个系统。根据构建系统的优缺点，用户给开发人员提出反馈意见。根据反馈意见修改软件需求规格，以便系统可以更正确地反映用户的需求。减少各种假设以及风险。课件制作人：谢希仁2.2.4增量模型在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成。增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件，开发人员逐个构件地交付产品，这样做的好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。课件制作人：谢希仁在使用增量模型时，第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后，经过评价形成下一个增量的开发计划，它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复，直到产生最终的完善产品。课件制作人：谢希仁增量模型也存在以下缺陷（1）由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。（2）在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。课件制作人：谢希仁增量模型总结融合了瀑布模型和原型的迭代特征。每一个增量均发布一个可操作产品。课件制作人：谢希仁2.2.5螺旋模型螺旋模型沿着螺线旋转，在四个象限上分别表达了四个方面的活动，即：制定计划──确定软件目标，选定实施方案，弄清项目开发的限制条件。风险分析──分析所选方案，考虑如何识别和消除风险。工程实现──实施软件开发。评审──评价开发工作，提出修正建议。课件制作人：谢希仁课件制作人：谢希仁螺旋模型的限制条件（1）螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的，因此，这种模型往往适应于内部的大规模软件开发。（2）如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此，螺旋模型只适合于大规模软件项目。（3）软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险。课件制作人：谢希仁螺旋模型总结基于风险驱动的开发模型，使用原型法或其它方法来尽量降低风险。适用于需求不明确的大规模软件项目。课件制作人：谢希仁增量模型和螺旋模型的主要区别（1）增量模型的通过避免使用未成熟技术和经常的客户反馈等方法减少风险；而螺旋模型中直接增加了风险分析，评价所选方案，识别和消除风险。（2）增量模型经常是先做总体需求分析和设计，然后在编码和测试中逐个增量开发；螺旋模型在每个开发周期内采用简化瀑布模型或快速模型。（3）增量模型通过迭代来逐步添加功能和需求，以完善产品；螺旋模型是事先定义大部分需求,开发过程中计划性比较强。课件制作人：谢希仁2.2.6RUP过程(统一过程)课件制作人：谢希仁用例驱动─Concise,simple,andunderstandable以体系结构为中心─Effectivebasisforlarge-scalereuse增量和迭代开发─基于风险前驱的原则，渐进地展开分析、设计及其相关活动，每个迭代都会提供一次验证和调整模型机会，推动软件质量的提升。课件制作人：谢希仁迭代式开发容纳需求变更/减少风险。管理需求使用用例和脚本。使用基于构件的体系结构。可视化建模。验证软件质量质量评估内建在贯穿于整个开发过程的、由全体成员参与的所有活动中。控制软件变更。课件制作人：谢希仁核心工作流业务建模需求分析与设计实现测试部署生成目标系统的可运行版本，移交给用户配置与变更管理跟踪维护开发过程中Artifacts的完整性和一致性项目管理提供项目管理框架，为软件开发项目制定计划、人员配备、执行和监控等方面的使用准则，并为风险管理提供框架环境提供软件开发环境，包括过程管理和工具支持课件制作人：谢希仁工作阶段Inception：建立业务模型，定义最终产品视图，确定项目的范围。Elaboration：设计并确定系统的体系结构，制定项目计划，确定资源需求。Construction：开发所有构件和程序，集成为可户需要的产品，测试所有功能。Transition：把开发出的产品提交给用户使用。课件制作人：谢希仁2.2.7敏捷过程敏捷过程（2001/2—敏捷软件开发宣言TheManifestooftheAgileAlliance）敏捷过程的价值观个体和交互胜过过程和工具。可以工作的软件胜过面面俱到的文档。客户合作胜过合同谈判。响应变化胜过遵循计划。课件制作人：谢希仁敏捷过程的原则我们最优先要做的是通过尽早的，持续的交付有价值的软件来使客户满意。即使到了开发的后期，,也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。经常性地交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。围绕被激励起来的个人来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作。课件制作人：谢希仁敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。在团队内部，最具有效果并且富有效率的传递信息的方法,就是面对面的交谈。工作的软件是首要的进度度量标准。不断地关注优秀的技能和好的设计会增强敏捷能力。简单是根本的。最好的架构、需求和设计出自于自组织的团队。每隔一段时间，团队就会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。课件制作人：谢希仁2.2.8极限编程（eXtremeProgramming,XP）极限编程是敏捷过程中最富盛名的一个，其中“极限”的含义是指把最好的开发实践运用到极致。目前极限编程已经成为一个典型的开发方法，广泛应用于需求模糊且经常改变的场合。特点：对变化和不确定性反应更快速，更敏捷。