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