软件项目开发流程PPT课件

.,1,软件开发流程SoftwareDevelopmentProcess,jzwsc,.,2,软件生命周期：软件生命周期是软件产品或系统一系列相关活动的全周期。,软件定义：确定软件开发总目标；确定工程的可行性；导出实现策略及系统功能；估计资源和成本，并且制定工程进度表。,软件开发：具体设计和实现在前一个时期定义的软件,软件维护：使软件持久地满足用户的需要。,1.问题定义、2.可行性研究、3.需求分析,4.总体设计、5.详细设计、6.编码和单元测试、7.综合测试,8.软件维护,.,3,软件产品或系统一系列相关活动的全周期,软件定义,软件开发,可行性分析,需求分析,总体设计,详细设计,编码,测试,软件发布,软件运行,软件维护,软件维护,问题定义,系统设计,系统实现,.,4,1.问题定义“要解决的问题是什么?”确定用户要求解决的性质、工程的目标和规模。2.可行性研究“对于上一个阶段所确定的问题有行得通的解决办法吗?”经济可行性、技术可行性、法律可行性、不同的方案3.需求分析“为了解决这个问题，目标系统必须做什么”确定系统必须具有的功能和性能，系统要求的运行环境，并且预测系统发展的前景。规格说明书(specification),.,5,4.总体设计（概要设计）“概括地说，应该怎样实现目标系统?”设计出实现目标系统的几种可能的方案。推荐一个最佳方案。5.详细设计“应该怎样具体地实现这个系统呢?”设计出程序的详细规格说明。6.编码和单元测试写出正确的容易理解、容易维护的程序模块仔细测试编写出的每一个模块。,.,6,7.综合测试集成测试和验收测试，现场测试或平行运行8.软件维护使系统持久地满足用户的需要。改正性维护，适应性维护，完善性维护，预防性维护。,.,7,.,8,IEC12207软件生命周期,.,9,ISO/IEC15504软件过程,.,10,软件过程,任务框架，各项任务的工作步骤运用方法的顺序、文档资料、管理措施，各个阶段的里程碑生命周期模型或过程模型典型的过程模型瀑布模型(Waterfallmodel)快速原型开发模型(RapidPrototypingmodel)增量模型(Incrementalmodel)螺旋模型(Spiralmodel),.,11,瀑布模型,理想的瀑布模型,实际的瀑布模型,.,12,软件过程：瀑布模型（续1）,瀑布模型的特点阶段间具有顺序性和依赖性推迟实现的观点清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现。质量保证的观点(文档驱动)每个阶段都必须完成规定的文档每个阶段结束前都要对所完成的文档进行评审,.,13,软件过程：瀑布模型（续2）,瀑布模型的缺点开发过程一般不能逆转，否则代价太大规格说明很难理解：“我知道这是按我的要求做的，但不是我想要的样子。”软件的实际情况必须到项目开发的后期客户才能看到。（文档驱动的两面性）,.,14,快速原型模型,用户测试运行原型,建造/修改原型,听取用户意见,.,15,软件过程：快速原型模型,原型模型的特点快速原型的本质是“快速”快速原型可以取代规格说明阶段，但不是设计阶段，容易适应需求的变化有利于开发与培训的同步原型模型的应用范围对所开发的领域比较熟悉而且有快速的原型开发工具项目招投标时，可以以原型模型作为软件的开发模型进行产品移植或升级时，或对已有产品原型进行客户化工作时，原型模型是非常适合的,.,16,软件过程：快速原型模型,比较瀑布模型试图一次就获得正确的产品快速原型频繁变化，然后废弃,.,17,软件过程：增量模型（续1）,增量模型的优点每个阶段交付一个可用的产品减少一个全新产品给客户带来的心理上的影响分阶段地交付产品不需要大的资金支出需求经常变化，增量模型的灵活性使其具有更加优越的适用性增量模型的困难需要一个开放的结构，方便构件的加入增量模型本身就是一个矛盾的名词,.,18,软件过程：增量模型,风险更大的增量模型,.,19,软件过程：螺旋模型,1988年，BarryBoehm正式发表了软件系统开发的“螺旋模型”，它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析简化版本：瀑布模型+风险分析每个阶段之前确定目标，可供选择的办法及其限制条件风险分析每个阶段之后评估计划下一阶段,.,20,简化的螺旋模型,.,21,完整的螺旋模型,.,22,软件过程：螺旋模型（续2）,螺旋模型的优点容易确定什么时候已经对某一阶段的产品充分测试完毕维护和开发之间没有什么本质上的差别螺旋模型的缺点仅适合于大型软件风险驱动既是优点也是缺点,.,23,软件过程：建造修补模型,对于100或200行长的短程序可以做得很好问题没有规格说明书没有设计不能令人满意,.,24,各种生命周期模型的比较,.,25,不知山林、险阻、沮泽之形者，不能行军。,.,26,这个项目是做还是不做呢？,可行性研究,.,27,一旦软件范围已经被标识出来，们自然会问：“我们能够开放软件以满足改范围吗？项目是可行的吗？”在软件危机时期人们通常会跳过这个阶段，往往陷入从开始就注定失败的项目泥潭中。可行性分析的目的是为了用最小的代价在尽可能短的时间内确定问题是否能够解决。必须记住：可行性分析不是要求解问题本身，而是要确定问题是否有解。,.,28,可行性研究的任务,最根本的任务是对以后的行动方针提出建议如果问题没有可行的解，应该建议停止这项开发工程，以避免时间、资源、人力和金钱的浪费如果问题值得解，应该推荐一个较好的解决方案，并且为工程制定一个初步的计划,.,29,可行性研究的内容,(1)技术可行性(2)经济可行性(3)操作可行性(4)社会可行性(法律可行性)(5)抉择,.,30,可行性研究的任务,经济可行性,操作可行性,这个系统的经济效益能超过它的开发成本吗？,使用现有的技术能实现这个系统吗？,技术可行性,系统的操作方式在这个组织内行得通吗？,.,31,技术可行性,度量一个特定技术信息系统解决方案的实用性及技术资源的可用性考虑的问题(1)开发风险分析(2)资源分析(3)相关技术的发展（现有技术能否实现新系统，技术难点、建议采用技术的先进性）,.,32,可行性研究报告,包括总体方案和可行性论证两个方面内容：引言系统建设的背景、必要性和意义拟建系统的候选方案可行性论证方案的比较结论可行性分析报告要尽量取得有关管理人员的一致认识,.,33,经济可行性,度量系统解决方案的性能价格比。考虑的问题：成本/效益分析（开发、运行的成本/效益）有形成本、效益无形成本、效益价值和成本的关系质量与价值、成本的关系价值/成本的均衡,.,34,举例,该系统节省经费,该系统成本,盈亏平衡点,投资回收期,-成本及效益分析图,.,35,操作可行性,用户使用可能性时间进度可行性组织和文化上的可行性,.,36,复查系统规模和目标,研究目前正在使用的系统,导出新系统的逻辑模型,评价可能解法，推荐行动方案，草拟开发计划,书写可行性报告等文挡，提交审查,符合要求吗？,n,y,.,37,什么是需求工程？,需求工程提供了一个比较完善的流程和方法来解决如何定义一个待开发的软件系统,.,38,需求工程的内容,需求工程过程可以被描述为6个部分：需求获取、需求分析、需求传递、需求建模、需求确认和需求管理,.,39,需求工程的目标,开发出符合客户要求的系统需求，包括符合客户要求的界面提供有效的解决方案以便确定软件系统中的主要元素将定义的需求分配给系统中的每个元素，了解软件需求受系统的制约、对操作环境的影响制定合适的软件版本发布策略，以确定系统或软件需求实现的优先级确定软件需求，并根据客户需求变化进行必要的更新,.,40,什么是软件需求,（1）用户解决问题或达到目标所需的条件或性能（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档条件或性能（3）一种反映上面（1）或（2）所描述的条件或性能的文档说明。,.,41,软件需求的层次（1）,业务需求反映组织机构或客户对系统、产品的概括性要求，包括所要达到的业务目标，由项目视图与范围文档说明用户需求描述用户使用系统而要完成的各种任务，由用例（usecase）文档或方案脚本说明功能需求定义开发人员必须实现的软件功能，它源于用户需求，是软件需求说明书中重要的组成部分,.,42,软件需求的层次（2）,需求层次之间的关系,不同层次成果,简单性描述,.,43,需求开发(1),需求获取：通过各种途径获取用户的需求信息，经过“定义问题分析问题根本原因分析涉众定义系统边界确定约束条件”需求分析：对获取的需求信息去伪存真、归纳处理，进行各种分析，试图掌握用户的真正意图和要求,需求获取,需求分析,需求定义,需求确认,.,44,需求开发（2）,需求定义：根据需求调查和需求分析的结果，解释涉众需求，并整理成规范的、清晰的产品需求规格说明书需求确认是指开发方和客户方共同对需求说明书进行评审，双方对需求达成共识后作出承诺，并符合优秀需求陈述的特征，包括完整、正确、可行、必要、具有优先级、无二义性和可验证,需求获取,需求分析,需求定义,需求确认,.,45,需求管理,需求管理是针对不断变化的客户需求加以收集、处理和跟踪，并建立软件需求的基准线，以作为项目中软件开发活动过程和产品度量和变更管理的基础。需求管理可以分为需求评审、需求跟踪和需求变更控制需求变更控制是需求管理中最主要的工作,.,46,软件设计,系统架构设计,详细设计,.,47,软件设计的目标,可靠性性能和安全性可扩展性可定制性或可移植性可维护性可重用性,.,48,体系结构设计任务,设计软件系统结构，如系统层次结构的划分、分布式结构的布局。确定设计元素，为设计元素分配特定功能。确定设计元素之间的关系，完成相应的通讯、同步与数据存取的协议和接口的设计。分析系统的规模和负载等，使系统满足性能、安全性等要求。对不同的设计方案进行比较和分析，选择最优的解决方案。编写设计文档。设计文档评审,.,49,.,50,体系结构设计视角,软件体系结构是一个抽象的系统规范，包含一定形式的结构化元素，对程序系统各构件的可见特性、结构及其相互之间关系的描述,.,51,详细设计,详细设计就是考虑在技术上如何实现已设计好的体系结构、如何实现已定义的软件功能主要任务是为每个模块确定所采用的算法、程序流程和数据结构，确定每个模块的接口细节,.,52,部署设计,构造软件系统的逻辑体系结构，包括系统层次依赖关系将逻辑体系结构中指定的组件映射到物理环境，从而生成一个高级部署体系结构创建一个实现规范创建一系列详细说明实现软件部署方案的计划,.,53,设计评审,软件设计评审，主要是技术评审，也包括文档审查。软件设计的审查涉及软件体系结构和详细设计结果，其审查对象是产品规格设计说明、系统架构和技术设计文档、测试计划和测试用例。其目的是保证软件设计和需求分析保持一致，使设计更好地符合用户需求和业务需求，确保软件系统能满足系统功能性和非功能性的需求,.,54,实施的丰富内容,.,55,编程,.,56,单元测试,单元测试:是验证那些可单独被测试的软件部分其隔离的功能特性单元测试的对象是构成软件产品或系统的最小的独立单元,.,57,驱动程序和桩程序,驱动程序（driver），对底层或子层模块进行（单元或集成）测试时所编制的调用被测模块的程序，用以模拟被测模块的上级模块桩程序（stub），对顶层或上层模块进行测试时，所编制的替代下层模块的程序，用以模拟被测模块工作过程中所调用的模块。,.,58,集成测试,集成测试是将已分别通过测试的单元按设计要求组合起来再进行的测试，以检查这些单元之间的接口是否存在问题持续集成,.,59,自顶向下法(Top-downIntegration),.,60,自底向上法(Bottom-upIntegration),.,61,功能测试,每项功能符合实际要求功能逻辑清楚，符合使用者习惯菜单、按钮等各项操作是否正常、灵活系统的界面清晰、美观系统的各种状态按照业务流程而变化，并保持稳定能接受正确的数据输入，对异常数据的输入可以进行提示、容错处理等数据的输出结果准确，格式清晰，可以保存和读取软件升级后，能继续支持旧版本的数据与外部应用系统的接口有效,.,62,系统测试,负载测试（Loadtest）/压力测试(stresstest)容量测试（Capacitytest）性能测试（Performancetest）安全性测试（Securitytest）容错测试（Recoverytest）兼容性测试（Compatibilitytest）可靠性测试（Reliabilitytest）,.,63,验收测试,验收测试是是技术测试的最后一个阶段，也称为交付测试。验收测试一般会根据产品规格说明书严格地检查产品，逐字逐句地对照说明书以检查事先定义的软件产品的各项具体要求，确保所开发的软件产品符合用户期望和需求,.,64,2.5部署、运行和维护,2.5.1系统部署2.5.2软件运行和技术支持2.5.3维护过程,.,65,系统部署,开发试验性系统对试验性系统进行全面认证测试通过，开始规划原型系统根据培训规划培训部署的管理员和用户完成原型系统的网络构建、软硬件的安装和配置数据备份或做好可以恢复（Roll-back）的准备将数据从现有应用程序迁移到当前解决方案进行相关的设置、定制