教学课件PPT软件工程软件过程.ppt

软件过程 (software processes),outline,软件过程 过程活动 软件过程模型 敏捷软件开发,2,outline,软件过程 过程活动 软件过程模型 敏捷软件开发,3,软件过程(software process),软件过程是开发软件产品的一系列相关活动(activities)的集合。 软件过程的目的是为各种人员提供一个公共的框架，以便用相同的语言进行交流。 many different software processes but all involve: specification defining what the system should do; design and implementation defining the organization of the system and implementing the system; validation checking that it does what the customer wants; evolution changing the system in response to changing customer needs.,4,software process descriptions,when we describe and discuss processes, we usually talk about the activities in these processes such as specifying a data model, designing a user interface, etc. and the ordering of these activities. process descriptions may also include: products, which are the outcomes of a process activity; roles, which reflect the responsibilities of the people involved in the process; pre- and post-conditions, which are statements that are true before and after a process activity has been enacted or a product produced.,5,outline,软件过程 过程活动 软件过程模型 敏捷软件开发,6,process activities,四个基本的过程活动 specification development validation evolution 在不同的软件开发过程中，它们的组织形式不同 顺序(sequence) 交替(interleaved) ,7,software specification,the process of establishing what services are required and the constraints on the systems operation and development. requirements engineering process feasibility study is it technically and financially feasible to build the system? requirements elicitation and analysis what do the system stakeholders require or expect from the system? requirements specification defining the requirements in detail requirements validation checking the validity of the requirements,8,feasibility study,“对于问题定义所确定的问题有可行的解决方法吗？” 了解用户要求和现实环境 从技术、经济、市场等方面研究并论证开发该软件系统的可行性 技术可行性：当前的软件开发方法和工具能否支持需求的实现； 操作可行性：用户能否在特定的环境下使用这个软件； 经济可行性：开发和使用、维护这个软件的成本能否被用户所接受。 阶段性产品 可行性论证报告 制定初步项目开发计划 (人员,进度),9,requirements elicitation and analysis,“为了解决问题，目标系统必须做什么？” 任务：确定用户对软件系统的需求： 功能需求：软件必须要完成的功能； 性能需求：软件的安全性、可靠性、可维护性、精度、错误处理、适应性、用户培训等； 运行环境约束：待开发的软件产品必须满足的环境要求 重要性：软件开发的依据，软件验收的标准,10,requirements elicitation and analysis,困难：难以说清、动态变化、歧义、复杂。 应用软件的需求分析涉及应用领域的知识和经验。 需求分析人员必须与用户不断、反复地交流和商讨，使用户需求逐步准确、一致、完全。 方法：面向数据流的分析方法、面向数据的分析方法、面向对象的分析方法。 工具：rational rose等。 阶段性产品 软件需求规格说明书srs 用户手册概要,11,the requirements engineering process,12,software design and implementation,the process of converting the system specification into an executable system. software design design a software structure that realises the specification; implementation translate this structure into an executable program; the activities of design and implementation are closely related and may be inter-leaved.,13,a general model of the design process,14,design activities,architectural design, where you identify the overall structure of the system, the principal components (sometimes called sub-systems or modules), their relationships and how they are distributed. interface design, where you define the interfaces between system components. component design, where you take each system component and design how it will operate. database design, where you design the system data structures and how these are to be represented in a database.,15,两步设计,总体设计：体系结构 阶段性产品 概要设计规格说明书 数据库或数据结构设计说明书 集成测试计划 详细设计 “应该怎样具体地实现这个系统呢？” 任务 细化概要设计所生成的各个模块, 并详细描述程序模块的内部细节(算法，数据结构等)，形成可编程的程序模块，制订单元测试计划 阶段新产品 详细设计规格说明书, 单元测试计划,16,implementation,任务 把软件设计转换成程序代码，即写成以某一种特定程序设计语言表示的“源程序清单”。 写出的程序应当是结构良好、清晰易读的，且与设计相一致的。 方法 以详细设计规格说明书为依据、基于某种程序设计语言进行编码 结构化程序设计、面向对象程序设计 工具 eclipse, visual studio.net 阶段产品 源程序代码,17,software validation,verification and validation (v & v) is intended to show that a system conforms to its specification and meets the requirements of the system customer. involves checking and review processes and system testing. system testing involves executing the system with test cases that are derived from the specification of the real data to be processed by the system. testing is the most commonly used v & v activity.,18,stages of testing,19,testing stages,development or component testing individual components are tested independently; components may be functions or objects or coherent groupings of these entities. system testing testing of the system as a whole. testing of emergent properties is particularly important. acceptance testing testing with customer data to check that the system meets the customers needs.,20,software evolution,software is inherently flexible and can change. as requirements change through changing business circumstances, the software that supports the business must also evolve and change. although there has been a demarcation between development and evolution (maintenance) this is increasingly irrelevant as fewer and fewer systems are completely new.,21,outline,软件过程 过程活动 软件过程模型 敏捷软件开发,22,软件过程模型,a software process model is an abstract representation of a process. it presents a description of a process from some particular perspective. 软件过程模型是软件过程的抽象表示。 软件过程模型也常称为： 软件工程模式 软件生存周期模型,23,软件过程模型,建造-修正模型 瀑布模型 快速原型模型 增量模型 螺旋模型 喷泉模型 形式化方法模型 基于构件的开发模型 rup 敏捷过程与极限编程 微软过程模型,24,注：软件过程模型是不断发展的，每种模型都有各自的优缺点，使用时可组合多种模型。,建造修正模型,build and fix or code like hell(鲁莽编码) 从一个大致的想法开始工作，然后经过非正规的设计、编码、调试和测试方法，最后完成工作。,25,可能有或可能没有规范,发布（可能）,建造修正模型,好处： 成本可能很低。 只需要很少的专业知识，任何写过程序的人都可以。 对于一些非常小的、开发完后就会很快丢弃的软件可以采用。 缺点： 对于规模稍大的项目，采用这种模型是很危险的。,26,传统的瀑布模型,实际的瀑布模型,瀑布模型,27,瀑布模型的特点,1. 阶段间具有顺序性和依赖性 前一阶段的工作完成之后，才能开始后一阶段的工作； 前一阶段的输出文档就是后一阶段的输入文档。 2. 推迟实现的观点 对于规模较大的软件项目来说，往往编码开始得越早最终完成开发工作所需要的时间反而越长。 3. 质量保证的观点 每个阶段都必须完成规定的文档，是“文档驱动”的模型； 每个阶段结束前都要对所完成的文档进行评审，尽早发现问题，改正错误。,28,瀑布模型的优缺点,1. 瀑布模型的优点： 可强迫开发人员采用规范的方法； 严格地规定了每个阶段必须提交的文档； 要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。 2. 瀑布模型的缺点： 只能通过文档了解产品，不经过实践的需求是不切实际的。 3. 瀑布模型适用于： 需求是预知的； 软件实现方法是成熟的； 项目周期较短。,29,导致问题的主要原因,1. 用户与开发者之间存在着差异，由于没有有效的沟通渠 道或媒介，这种差异常常无法协调。 2 . 用户由于不熟悉信息技术，可能提出非常含糊甚至不可 行的需求，这种需求经常被开发人员所误解。 3. 经验表明，一旦用户开始使用一个计算机系统他们对目 标系统的理解可能又会发生很多变化这导致原始需求失效 。更严重的是一个大型系统往往需要很多人，花几年的时 间才能完成。在这期间，用户的需求和环境可能发生了大 变化，从而使最终的系统不能使用。,30,解决办法,实际上，软件开发，特别是开发的早期阶段，应该是学习 和实践的过程，这个活动（action）应该包括开发人员和用 户两个方面。 尽管用户在开始时说不清楚所要求的未来软件系统(目标 系统）会是什么样子（需求） ，但他们却可以对 it人员开 发的系统非常熟练地进行挑剔！ 这就启发我们能否一开始就给用户展示一个目标系统的 的雏形，让用户评头论足，然后逐步进行修改，直至成功。 这就是所谓的快速原型模型。,31,快速原型模型,快速原型模型,快速原型：是快速建立起 来的可以在计算机上运行 的程序，它所能完成的功 能往往是最终产品能完成 的功能的一个子集。,32,优点,适用于用户驱动的系统（即需求模糊或随时间变化的系统） 软件产品的开发基本上是线性、顺序的 改善的用户参与 提高系统的实用性、可维护性 节省开发的投入、缩短整个软件的开发周期 本质就是“快速”,33,原型模型存在的问题,用户有时误解了原型的角色：例如他们可能误解原型应该和真实系统一样可靠 缺少控制：由于用户可能不断提出新要求，因而原型迭代的周期很难控制 额外的花费：研究结果表明构造一个原型可能需要10%额外花费 为了尽快实现原型，采用了不合适的技术，运行效率可能会受影响 原型法要求开发者与用户密切接触，有时这是不可能的，例如外包软件。,34,注意,虽然有问题存在，但是快速原型模型仍是软件开发的一个有效的过程模型。 关键是定义了开始的游戏规则，即用户与开发者两方面必须达成一致：原型被建造仅是为了定义需求，之后被抛弃（或至少部分被抛弃），实际的软件在充分考虑了质量和可维护行之后才被开发。,35,构建原型的方法,1. 手工绘制一个书面原型，或采用简单的开发平台，如微机，构造一个功能型界面。 2. 使用开发工具，快速开发一个初步的、符合用户基本（主要）需求的、可运行的原型。 3. 借用一个商品化的，或第三方开发的类似系统，或对成功软件的功能复用（部分的或全部的）请用户评价是否符合需求，在明确了基本需求之后，再着手开发自己的原型。,36,case analysis 2,37,案例：构建原型,江苏省防汛防旱监测预警系统 项目初期需求不是很清晰，难以获得完整的需求，瀑布模 型不适用，考虑使用快速原型模型，先构建一个原型系统给 用户用，在用户使用的过程中获取更多的需求。 构建好的原型系统就是用户和开发人员之间进行沟通的纽 带。,38,系统介绍,江苏省防汛防旱监测预警系统根据今年省水利厅的防 汛要求可以随时随地地让防汛有关工作人员看到报警信息， 当出现紧急情况时，能主动把报警信息推送到这些工作人员 的电脑桌面，也可以以短消息或者图片的形式发到工作人员 的移动设备上，使相关人员随时了解实时信息，为监视、分 析、决策、指挥提供灵活方便的信息获取手段。,39,“客户端登录”功能原型,在本界面用户输入服务器地址、用户名及密码，可以进行登 录，也可以勾选自动登录以便下次运行时自动使用已保存的 用户名与密码进行登录。,40,“自动预警”功能原型,当有预警消息传送至桌面，会进行判断客户端是否开启， 若客户端开启，则自动打开预警消息的弹窗并显示预警消息 ，否则会等待下次开启客户端时进行离线传送。,41,“用户管理”功能原型,用户管理用于管理接受预警信息的用户。用户 权限分为3种，超级管理员，管理员，普通用户。 超级管理员默认只有一位，可以查看编辑所有用 户信息，管理员可以查看编辑自己的用户信息以 及普通用户的信息，普通用户仅仅可以查看自己 的用户信息。,42,“用户管理”功能原型,43,“测站管理”功能原型,测站管理功能实现对所有测站的基础信息的管理，包括测站基础数据浏览与查看、测站的预警标识的设置。测站信息是系统数据的关键基础部分，通过测站的添加与删除，为系统提供了测站的预警范围，同时可以根据预警需要进行设置测站是否预警。,44,“测站管理”功能原型,45,“预警管理”功能原型,预警管理页面是对预警信息进行管理，预警信息是预警系统当中重要预警功能重要的组成部分，包括降雨量门槛，流量门槛，水位门槛，水库站门槛。预警管理页面将对这些门槛进行设置，设置后的门槛值为系统提供预警条件，当预警条件改变时也可以通过预警管理页面编辑对门槛值进行修改。,46,“预警管理”功能原型,47,“日志管理”功能原型,日志管理页面用于查询历史记录，可以查询特定用户的预警信息，可以查看历史记录状态是已经发送，未发送，还是通过离线发送，可以对历史记录进行删除。日志管理页面是预警系统结果反馈的重要组成部分。,48,“日志管理”功能原型,49,“消息管理”功能原型,消息管理用于用户自定义自己习惯的消息格式，每个用户对于消息格式有不同的要求，消息管理界面用于对所有的消息格式总共9类进行编辑，对于消息格式不正确的格式，系统会自动判断，并且自动替换成正确的消息格式。消息管理功能为用户提供了多样性选择，便于系统扩展。,50,“消息管理”功能原型,51,增量模型,增量模型把软件产品作为一系列的增量构件来设 计、编码、集成和测试。每个构件由多个相互作用 的模块构成，并且能够完成特定的功能。,52,增量模型,53,增量模型适用于： 适用于需求经常改变的软件开发过程。 如果在项目既定的商业要求期限之前不可能找到足够的开发人员，在这种情况下，增量模型显得特别有用。,54,螺旋模型,螺旋模型的基本思想： 使用原型及其他方法 来尽量降低风险。把 它看作在每个阶段之 前都增加了风险分析 过程的快速原型模型。,55,简化的螺旋模型,完整的螺旋模型,56,螺旋模型适用于： 特别适用于庞大、复杂并具有高风险的系统。 适用于内部开发的大规模软件项目。,57,支持软件复用。利用预先包装好的软件构件来构造应用系统。,58,基于构件的开发模型,形式化方法是建立在严格数学基础上的一种软件开发方法。软件开发的全过程中，从需求分析、规约、设计、编程、系统集成、测试、文档生成、直至维护各个阶段，凡是采用严格的数学语言，具有精确的数学语义的方法，都称为形式化方法。,59,形式化方法模型,rup,rational统一过程(rational unified process, rup)是由rational软件公司推出的一种完整而完美的软件过程。 rup是一种迭代的，以架构为中心的，用例驱动的软件开发方法。 rup是一种具有明确定义和结构的软件工程过程。 rup还是一个过程产品，提供了可定制的软件工程的过程框架。 rup被广泛应用在不同工业领域中的不同企业中。,60,rup总结了6条软件开发经验最佳实践： 迭代式开发 管理需求 使用基于构件的体系结构 可视化建模