您好,欢迎访问三七文档
当前位置:首页 > 建筑/环境 > 工程监理 > 《软件工程》第四章.
《软件工程》SoftwareEngineering人的生命周期婴儿—幼儿—儿童—少年—青年—中年—老年—死亡软件的生命周期软件定义软件开发软件支持问题定义可行性分析需求分析概要设计详细设计编码测试软件发布软件运行维护或退役回顾:相关概念(维护报告)可行性研究编码与测试需求分析软件设计项目计划运行与维护软件集成与发布开发时期运行时期计划时期(可行性分析报告)(项目开发计划书)(集成与验收报告)(源程序清单)(软件设计说明书)(需求规格说明书)传统的瀑布模型图回顾:相关概念相关概念:问题定义/可行性研究/系统工程问题定义阶段需要解决的问题是“该软件项目要解决的问题是什么”;可行性研究/分析是要决定“做还是不做”;需求分析是要决定“目标系统必须做什么,不做什么”。“需求分析”的主要内容需求分析基础面向数据流的分析方法(结构化分析)面向对象的需求分析面向数据的分析1需求分析的重要性2需求分析的任务与原则3需求分析的获取方法与建模数据字典数据流图ER图基于数据流的分析方法面向对象的概念面向对象方法简介面向对象分析过程面向数据结构的系统开发方法Jackson系统开发方法形式化方法4.1需求分析的基本概念4.2需求分析的任务4.3需求分析的方法4.4需求描述工具4.5需求过程管理4.6需求分析文档第4章软件需求分析4.7需求评审过程4.1需求分析的基本概念软件需求软件需求分析软件需求分析的基本要求需求分析的重要性需求分析的复杂性和困难性需求分析概述软件需求是指用户对目标软件系统在功能、性能、行为、设计约束等方面的期望。需求分析就是通过对应用问题及其环境的分析与理解,采用一系列的分析方法和技术,将用户的需求逐步精确化、完全化、一致化,最终形成需求规格说明文档的过程。系统分析阶段产生的系统规格说明和项目规划是软件需求分析的基础,分析人员需从软件的角度对其进行检查和调整,并在此基础上展开需求分析。4.1需求分析的基本概念4.1.1软件需求IEEE(InstituteofElectricalandElectronicsEngineers美国电气和电子工程师协会)软件工程标准词汇表中将“需求”定义为:用户为解决某一问题或者达到某个目标所需要的条件或能力。目前虽然对软件需求的定义有着不同的看法,但是通常认为软件需求是指软件系统必须满足的所有功能、性能和限制。4.1.1软件需求业务需求项目视图与范围文档用户需求使用实例文档质量属性功能需求系统需求其他非功能需求约束条件软件需求规格说明4.1需求分析的基本概念4.1.1软件需求1.业务需求业务需求从总体上描述了为什么要开发这个系统,希望达到什么样的目标等一类问题。2.用户需求用户需求是用来描述用户使用软件产品必须要完成什么任务,怎么样完成。3.功能需求功能需求是用来描述开发人员在产品中实现的软件功能,用户利用这些功能来完成任务,满足业务需求。。4.1需求分析的基本概念4.1.2软件需求分析软件需求分析是一项软件工程活动,它使系统分析人员能够描绘出系统的功能和性能,指明软件和其他系统元素的接口,并且建立系统必须满足的约束。通过对问题及其环境的理解与分析,对涉及的信息、功能以及系统行为建立模型,将用户的需求精确化、完整化,最终形成软件需求规格说明。4.1需求分析的基本概念4.1.3软件需求分析的基本要求软件需求分析的基本要求包括以下几方面。完整性。一致性。现实性。有效性。可验证性。可跟踪性。4.1需求分析的基本概念4.1.4软件需求分析的重要性软件需求分析在软件开发过程中的重要性:1.软件需求分析是获得用户需求的有效途径2.软件需求分析是项目取得成功的关键因素3.软件需求分析是软件设计的坚实基础4.软件需求分析是软件质量保证的重要阶段4.1需求分析的基本概念需求分析概述:需求分析的重要性试想当你完成软件开发后,用户认为该软件不是他所期望的而拒绝接收时,你怎么办(你的处境)。SRA是软件开发的前提和基础。SRA过程中产生的文档资料——软件需求规格说明书SRS是软件开发依据,也是软件开发者与用户评估/验收软件产品的依据。软件错误源于分析阶段的比例高达50%~60%;一个错误发现得越晚,修复错误的费用越高(高2~3个数量级,随时间呈指数级增长)。软件项目失败的最重要的五个原因需求不完整缺少客户的参与期望值过高缺少高层的支持0%5%10%15%缺少资源需求分析概述:需求分析的重要性引入同一变动付出的代价随时间变化的趋势TheCostofChange需求分析概述:需求分析的重要性不完善的软件产品软件需求对错误分析的设计正确的设计错误的设计正确的分析错误的分析对错误分析的编码对错误设计的编码正确的编码错误的编码潜在的错误不可改正的错误正确功能可改的错误软件错误的积累和放大效应需求分析软件设计编码软件测试从Analyst的角色和要求看。需求工程——SE中最受重视和最活跃的研究领域之一。软件质量=系统所实现的需求/客户所期望的需求需求分析概述:需求分析的重要性需求分析概述:复杂性和困难性1.用户对需求描述的零乱、模糊问题。2.用户与分析员之间的交流障碍问题。由于教育背景、专业领域不同或利益关系等,而造成误解或无法沟通。3.完整性问题。无法判断用户是否把他(们)所想要的已全部告诉你,也无法期望用户在短时间内把他(们)想要的一件不漏地告诉你。4.用户往往是一个群体,不同层面、不同部门的意见不一定完全相同,甚至有冲突。5.用户不一定能预见到计算机化能给他们带来的有价值的潜在需求,而你预见到的也许并非他们所想要的。6.需求永远不会稳定。7.编、审SRS的困难。8.需求的本质问题:复杂和庞大、模糊、不准确,难以检查和排除不一致,歧义、片面、不完全等软件需求分析的困难需求分析阶段的成果主要是需求规格说明,该成果又是软件设计、编码、测试直至维护的主要基础。需求分析是系统分析和软件设计的重要桥梁,是软件生存周期的关键性阶段。良好的分析活动能够减少错误和遗漏,从而可提高软件生产率和产品质量、降低开发与维护成本。4.2需求分析的过程和任务4.2.1需求分析的过程(1)获取用户需求(2)分析用户需求(3)编写需求文档图(4)通过需求评审4.2.2获取用户需求的主要内容获取的用户需求内容主要包括:(1)物理环境(2)系统界面(3)系统功能(4)数据要求(5)文档规格(6)维护要求4.2需求分析的任务需求获取:范围、环境系统分析人员通过与用户的交流,了解业务现状以及对待开发系统的期望。确定系统或产品范围的限制性描述与系统或产品有关的人员及特征列表系统的技术环境的描述系统功能的列表及应用于每个需求的领域限制一组描述不同运行条件下的应用场景以及为更好地定义需求而开发的系统原型需求获取收集的“原始材料”为进行需求分析提供了基础。需求获取:范围、环境需求的来源客户或用户:例如学院的高层管理者、项目投资人系统管理员教师、学生、图书管理员标准:例如图书资料的标准政策或法律:例如图书资料管理规程、知识产权和版权保护等系统或过程文档:例如当前手工管理的文件、表格、记录等相关领域的专家需求获取:范围、环境需求获取:搜集、理解、获取详细的、充分的用户对目标软件的需求信息,该信息应足以使得开发者能开发出一个使客户方和使用者都满意的产品。需求获取:需求信息、资料收集与理解功能性需求系统需要提供的服务或功能:如图书检索系统对特定输入的处理方式:如对非法输入的提示系统在特定环境下的行为:如长时间无操作时的屏保非功能性需求对系统功能或服务附加的质量约束,例如响应时间、容错性、安全性等——客户所关心的(外部质量)从系统开发和维护角度出发的质量属性,例如可理解性、可扩展性、可配置性等——软件开发或维护者所关心的(内部质量、软件所特有)数据需求:系统涉及的各种数据,它们的名称、内容、类型、数量、限制/约束条件、结构,等等。案例:小型图书资料管理系统问题描述某学院打算开发一个小型图书资料管理系统MiniLibrary,该系统基于Internet实现教师和学生对各种图书资料的借阅、查询和管理。图书管理员负责管理各种图书资料,查询图书资料信息,并进行图书的借阅管理。注册用户可以通过Internet随时查询图书资料信息和个人借阅情况,预订目前借不到的图书资料,并可以快捷地查找和浏览所需要的电子资料。提供适当的浏览器供用户阅读电子文献资料。要求用户界面友好,响应速度快,具有良好的可扩展性。需求获取:FunctionalRequirements功能性需求:即拟开发的软件在职能上应做什么。通常包括系统的输入,系统必须完成的功能,系统的输出以及其它反应。通常包括,功能的划分和各项功能的详细描述例如MiniLibrary:用户可以从图书资料库中查询或者选择其中的一个子集。系统可以提供适当的浏览器供用户阅读电子文献。用户每次借阅图书应该对应一个唯一的标识号,它被记录到用户的帐户上。需求获取:Non-functionalRequirements非功能需求过程需求产品需求外部需求软件交付实现方法标准互操作性道德法规成本可用性软件性能存贮空间可靠性可移植性安全性例如MiniLibrary:系统应在20秒之内响应所有的请求。系统每周7天、每天24小时都可以使用。对于一个没有经验的用户而言,经过两个小时的培训就可以使用系统的所有功能。需求获取:Non-functionalRequirements1)运行环境(或外部界面)需求;2)性能需求;3)过程需求/设计约束;4)其它(软件)产品质量属性需求。需求获取:Non-functionalRequirements(1)运行环境(或外部界面)需求用户界面(如屏幕格式、报表格式,菜单格式等)硬件接口(机型、特性、内外存、外设、数据通信接口,等等)软件接口(支撑软件:如OS,DBMS,网络软件等)控制方式(如本地或远程)操作与使用(制度、素质、技术水平、培训等要求)故障处理要求需求获取:Non-functionalRequirements(2)性能需求时间特性(如响应时间,数据转换与传输时间、运行时间等)。通常还必须给出系统满负荷或超负荷运行时的能力和表现要求。适应性/灵活性(在操作方式、运行环境、与其它软件接口等发生变化时应具有的适应能力)资源有效性(机时,内外存,通讯端口,缓冲区的大小和数目等)数据精度系统规模/容量(用户量、终端数目、对每一可能的输入能够接收多少数据量,一次能处理多少个事件,等等)[通常必须给出最大/最小和平均数目]需求获取:Non-functionalRequirements(3)过程需求/设计约束标准化的约束实现方法约束交付约束…即:强加于设计与实现的限制——如受强制的标准、实现的工具、语言,数据库、资源限制、操作环境等的约束。需求获取:Non-functionalRequirements(4)其它(软件)产品质量属性需求可用性可靠性可移植性安全保密性可维护性可重用性…例:特性度量指标每秒处理的事务速度用户或事件的响应时间屏幕的刷新时间字节数存贮空间RAM芯片数培训时间可用性帮助页面数平均失败时间可靠性系统无效的概率失败发生率失败后的重启次数容错性事件引起失败的比例失败时数据崩溃的可能性数据需求数据需求通常可归入功能性需求。但是由于它的重要性和独特性,特别是在数据密集型的应用问题(或称以数据库为中心的应用)中,常需对数据进行独立分析(称为数据分析)。对数据的描述也常常独立成为需求Specification中的一部分或另外形成一份独立的说明书——数据需求说明书(例如,GB8567-88)。数据需求数据需求静态数据动态输入数据、动态输出数据内部生成数据数据定义:名称、内容、类型、数量、限制/约束条件、结构,等数据采集:要求和范围、输入的承担者、预处理、影响等数据需求数据需求分析与描述数据字典E-R方法、E-
本文标题:《软件工程》第四章.
链接地址:https://www.777doc.com/doc-2804371 .html