《课名软件工程.ppt》由会员分享，可在线阅读，更多相关《课名软件工程.ppt（512页珍藏版）》请在三一办公上搜索。
1、2023/4/26,1,课名：软 件 工 程,使用教材：软件系统开发技术（修订版）潘锦平 施小英 姚天昉 西安电子科技大学出版社,2023/4/26,2,第一章 软件工程概述,2023/4/26,3,1.1 软件工程的背景和历史,1968年由NATO(北大西洋公约组织)在德国Garmish召开的学术会议上，Feitz Bauer首先提出了“软件工程”概念。,2023/4/26,4,软件工程与编程,前者是一门学科，一种科学理论来指导软件系统开发，标准化，自动化的过程考虑如何分解一个系统，以便各人分工开发；考虑如何说明每个部分的规格要求；怎样才能易于维护,单纯的代码编写是软件工程发展的前身是软件工
2、程中占据很少时间和空间的一部分,2023/4/26,5,计算机学科的发展,计算机科学(CS),计算机科学(CS),计算机工程(CE),软件工程(SE),信息系统(IS),计算学科(computing discipline),2023/4/26,6,60年代以来,工厂管理病人监护工资统发图书馆管理机票预定学籍管理,早期 第二阶段 第三阶段 第四阶段面向批处理 多用户 分布式系统 强大的桌面系统有限的分布 实时 嵌入“智能”面向对象技术自定义软件 数据库 低成本硬件 专家系统 软件产品 消费者的影响 人工神经网络 并行计算 网络计算机,1950,1960,1970,1980,1990,2000,E
3、volution of software#,2023/4/26,8,为什么发展如此之快,不准确的时间和金钱的估算软件质量的低下相对硬件产品开发软件开发费用的增加维护、增强软件系统的必要性硬件价格大幅度下降,2023/4/26,9,软件技术面临的问题,规模 复杂性 生产率,Windows95有1000万行代码 Windows2000有5000万行代码,例：,Exchange2000和 Windows2000开发人员结构,2023/4/26,11,人月神话焦油坑,史前史中，没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼。上帝见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。它们挣扎得越是猛烈，焦油纠缠
4、得越紧，没有任何猛兽足够强壮或具有足够的技巧，能够挣脱束缚，它们最后都沉到了坑底。,2023/4/26,12,软件危机的主要特征,软件开发周期大大超过规定 日期;软件开发成本严重超标;软件质量难于保证。,2023/4/26,13,软件工程的定义,Fritz Bauer在NATO会议上给出的定义：“软件工程是为了经济地获得可靠的和能在实际机器上高效运行的软件而确立和使用的健全的工程原理（方法）。”,2023/4/26,14,软件工程的定义（2）,IEEE【IEE83】给出的软件工程定义：“软件工程是开发、运行、维护和修复软件的系统方法。”,2023/4/26,15,软件工程的定义（3）,IEEE
5、【IEE93】给出了一个更加综合的定义：“将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程，即将工程化应用于软件中。”,软件工程是一门交叉学科,软件工程的主要研究内容软件开发技术:软件开发方法学 软件开发过程 软件工具和软件工程环境 软件工程管理:软件管理学 软件经济学 软件心理学 软件工程所包含的内容不是一成不变的，随着人们对软件系统的研制开发和生产的理解。应用发展的眼光看待它。,2023/4/26,17,软件工程 一种层次化技术,工具,方法,过程,质量焦点,Software engineering layers,软件工程三个要素：方法、工具、过程,2023/4/26,18
6、,软件工程与一般工程的差异,软件是逻辑产品而不是实物产品软件的功能依赖于硬件和软件的运行环境以及人们对它的操作软件设计的复杂性软件特征：功能的多样性 实现的多样性 能见度低 软件结构合理性差智力密集及知识产权保护,2023/4/26,19,软件工程知识结构,2001年5月ISO/IEC JTC 1（ISO和IEC的第一联合技术委员会）发布了 SWEBOK指南V0.95(试用版)SWEBOK把软件工程学科的主体知识分为10个知识领域。,2023/4/26,20,软件工程知识结构,软件需求 软件设计 软件构造 软件测试 软件维护 软件配置管理 软件工程管理 软件工程过程 软件工程工具和方法 软件质
7、量,2023/4/26,21,“软件工程”课程 与其它软件专业课的区别,(1)立足于系统的整体。(2)讲授系统分析、系统设计、测试及维护的理论和方法。(3)构筑一个软件系统，实践 软件开发全过程。,2023/4/26,22,“软件工程”课程教学的目标,转变对软件的认识：上升 程序 系统 转变思维定式：上升 程序员 系统工程师(系统分析员),2023/4/26,23,软件产品的标准化,软件开发过程的标准化,2023/4/26,24,软件的工业化生产过程应具备的特点：明确的工作步骤详细具体的规范化文档明确的质量评价标准,“一个好的工业，应有一套良好的标准来配套”,2023/4/26,25,软件工程
8、技术的两个特点,强调规范化 强调文档化,2023/4/26,26,1.2 软件和软件生命期模型,(Software Life Cycle)软件产品或软件系统从设计、投入使用到被淘汰的全过程。,2023/4/26,27,软件生存期的阶段划分,(1)可行性研究与计划(2)需求分析(3)总体设计(4)详细设计(5)实现(6)集成测试(7)确认测试(8)使用和维护,成长期（开发期）,怀孕期（计划期）,成年期（运行期）,2023/4/26,28,新的国际标准定义的软件生存过程（1995 ISO/IEC 12207）,软件生存期过程,支持过程,组织过程,主要过程,获取过程,供应过程,开发过程,运行过程,维
9、护过程,文档编制过程,配置管理过程,质量保证过程,验证过程,确认过程,联合评审过程,审核过程,问题解决过程,管理过程,基础设施过程,改进过程,培训过程,2023/4/26,29,软件工作的范围,只考虑编写程序,涉及整个软件生存周期,扩展到,2023/4/26,30,软件开发模型是软件开发全部过程、活动和任务的结构框架。它能直观表达软件开发全过程，明确规定要完成的主要活动、任务和开发策略。软件开发模型也常称为：软件过程模型 软件生存周期模型 软件工程范型,软件开发模型,可行性研究与计划,需求分析,设计,编码,运行维护,测试,定义阶段,开发阶段,维护阶段,瀑布模型(Waterfall Model)
10、,2023/4/26,32,开发软件不仅仅是编程,2023/4/26,33,按照传统瀑布模型开发软件的特点,1.阶段间具有顺序性和依赖性。2.推迟实现的观点。3.每个阶段必须完成规定的文档;每个阶段结束前完成文档审查,及早改正错误。,2023/4/26,34,原型模型（快速原型模型）,原型范型,用户测试运行原型,建造/修改 原型,听取用 户意见,采用原型模型的软件生存周期,分析定义系统需求,生成原型,系统设计,程序设计,编码,测试,运 行和维护,原型化,含原型化的软件生存期,2023/4/26,36,1.3 软件质量的评价,成功的标准：用户在用 用户可很容易做完要做的事失败的根本原因：开发人员
11、写出的东西达不到 用户要求(人的问题.技术问题),2023/4/26,37,质量与生产率,质量是软件需求方最关心的问题，用户即使不图物美价廉，也要求个货真价实 质量与生产率之间有着内在的联系，高生产率必须以质量合格为前提 质量与生产率的提高就指望程序员与程序经理 非得在质量与生产率之间分个主次不可，那么应该是质量第一，生产率第二,2023/4/26,38,质量与生产率（2）,质量直接体现在软件的每段程序中，高质量自然是开发人员的技术追求，也是职业道德的要求 高质量对所有的用户都有价值，而高生产率只对开发方有意义 如果一开始就追求高生产率，容易使人急功近利，留下隐患,2023/4/26,39,不
12、贪污的官就是好官吗,“运行正确”的程序就是高质量的程序吗？也许运行速度很低并且浪费内存；也许代码写得一塌糊涂,2023/4/26,40,软件的质量因素,软件的质量因素很多，如正确性、精确性、可靠性、容错性、性能、效率、易用性、可理解性、简洁性、可复用性、可扩充性、兼容性等等（还可以列出十几个）一般说来倾向于可维护性、可靠性、可理解性和效率,2023/4/26,41,软件质量因素分类和武学分类,2023/4/26,42,正确性与精确性,机器不会主动欺骗人，软件运行不正确或者不精确一般都是人造成的 需求分析错了，那么对客户而言这个软件也存在错误 如果软件没有100%地按需求规格执行，那么这个软件也
13、存在错误程序员要为“正确”、“精确”四个字竭尽全力,2023/4/26,43,性能与效率,用户都希望软件的运行速度高些（高性能），并且占用资源少些（高效率）旧社会地主就是这么对待长工的：干活要快点，吃得要少点 通过优化算法、数据结构和代码组织来提高软件系统的性能与效率优化的关键工作是找出限制性能与效率的“瓶颈”,2023/4/26,44,易用性,导致软件易用性差的根本原因是开发人员犯了“错位”的毛病：他以为只要自己用起来方便，用户也一定会满意 当用户真的感到软件很好用时，一股温暖的感觉油然而生，于是就用“友好”来评价易用性,2023/4/26,45,可理解性与简洁性（Note 1）,开发人员只
14、有在自己思路清晰时才可能写出让别人能理解的程序 编程时还要注意不可滥用技巧，应该用自然的方式编程 简洁是一种美 如果把学术文章写得很简洁，让人很容易理解，它往往中不了,2023/4/26,46,可复用性与可扩充性,一种方式是原封不动地使用现成的软件构件 一种方式是对现成的软构件进行必要的扩充后再使用 可复用性好的程序一般也具有良好的可扩充性,2023/4/26,47,测试已经开始,返回上级，再.,瀑布模型的质量保障体系,2023/4/26,48,小结（Note 2）,软件的高质量主要是设计出来的不是“管”出来的更不能依赖质量检查。,2023/4/26,49,第二章 可行性研究与计划,2023/
15、4/26,50,系统流程图（Note 3）,输入单据磁盘文件处理输出单据,2023/4/26,51,数据流程图,数据源点和终点,变换数据的加工,文件,数据,逻辑关系符号：与、或、异或,2023/4/26,52,2.1可行性研究基本概念,可行性研究的任务:可行性研究的主要任务是“了解客户的要求及现实环境，从技术、经济和社会因素等三方面研究并论证本软件项目的可行性，编写可行性研究报告，制定初步项目开发计划。”,2023/4/26,53,可行性研究的内容,(1)技术可行性(2)经济可行性(3)操作可行性(4)社会可行性(法律可行性)(5)抉择,2023/4/26,54,技术可行性(Note 4),度
16、量一个特定技术信息系统解决方案的实用性及技术资源的可用性考虑的问题开发风险分析资源分析相关技术的发展（现有技术能否实现新系统，技术难点、建议采用技术的先进性）,2023/4/26,55,经济可行性,度量系统解决方案的性能价格比考虑的问题 成本/效益分析有形成本、效益无形成本、效益 价值和成本的关系质量与价值、成本的关系价值/成本的均衡,2023/4/26,56,经济可行性考虑的问题(Note 5),成本和效益的估算开发成本的估算开发效益的估算运行成本的估算运行效益的估算,2023/4/26,57,成本分析,代码行技术（page 19）任务估算技术（page 20）总成本、总人力相对误差在 内P
17、utnam估算模型（page 21）COCOMO模型比较复杂,2023/4/26,58,效益分析,系统的经济效益使用新系统增加收入使用心系统可以节省的运行费用总的效益和软件生存周期有关货币的时间价值（page23）投资回收期（page23）投资回收率（page23）纯收入（page23）投资回收率,2023/4/26,59,系统开发和每年运行费用举例,1.系统开发费用（一次）.2名系统分析员(450小时/名,45美元/小时)$40,500.5名系统开发人员(275小时/名,36美元/小时)$49,500.1名数据库管理员(30小时/名,42美元/小时)$1,260.2名技术写作者(120小时/
18、名,25美元/小时)$6,000.1名秘书(160小时/名,15美元/小时)$2,400,2023/4/26,60,系统开发和每年运行费用举例,.1名数据通讯专家(60小时/名,42美元/小时)$2,4002名在转换期间数据输入人员$49,500(40小时/名,12美元/小时),2023/4/26,61,系统开发和每年运行费用举例,培训：三天的开发人员内部培训课程$7,00030个用户，三天的内部培训课程$10,000物资：复印$500磁盘、纸张等消耗品$650,2023/4/26,62,系统开发和每年运行费用举例,购买硬件、软件：20台工作站Windows软件$1,00020台工作站内存升级
19、$8,000网络软件$17,50020台工作站办公软件产品$20,000系统开发总费用$161,670,2023/4/26,63,系统开发和每年运行费用举例,2.年运行费用（每年）人员：维护程序员/分析员(250小时/年,42美元/小时)$10,500网络管理员(300小时/年,50美元/小时)$15,000购买硬件、软件升级：硬件$5,000软件$6,000物资和杂项$3,500每年总运行费用$40,000,2023/4/26,64,操作可行性,用户使用可能性 时间进度可行性 组织和文化上的可行性,2023/4/26,65,社会可行性(法律可行性),开发项目是否会在社会上或政治上引起侵权、破
20、坏或其它责任问题,2023/4/26,66,可行性研究计划的完成,可行性研究计划,2023/4/26,67,2.3 可行性研究的步骤（page15）,(1)复查确认系统目标、规模(2)研究正使用系统工作流程(3)导出新系统高层逻辑模型(4)重新定义问题(5)导出和评价供选择的方案(6)推荐可行的方案(7)草拟开发计划(8)编写可行性研究报告，送审,2023/4/26,68,第三章 需求分析和规格说明,2023/4/26,69,3.1 为什么需要需求分析,开发人员往往急于求成希望对开发进行指导希望开发人员对用户的要求理解希望用户理解开发人员测试部门有理可依,2023/4/26,70,需求分析的任
21、务,准确地定义未来系统的目标，确定为了满足用户的需求系统必须做什么。用 规范的形式准确地表达用户的需求。,2023/4/26,71,什么是用户需求,思考、涉及的几个问题如何识别、获取需求?你能够采取何种手段与用户进行交流沟通?何为需求建模?你如何理解模型与建模?,2023/4/26,72,软件需求分析的几个阶段,问题分析问题评估和方案综合建模规约复审 系统分析员的主要焦点是“做什么（what）”，不是“怎样做（how）”,2023/4/26,73,需求获取面临的挑战(Note 6),客户说不清楚需求 需求易变性问题的复杂性和对问题空间 理解的不完备性与不一致性,2023/4/26,74,3.2
22、 需求获取的常用方法（Note 7）,建立分析小组 领域专家：主角 系统分析员：导演客户访谈问题分析与确认,某出版社系统调查表,某出版社系统调查表,2023/4/26,77,听一个故事（Note 8）,主人公：C o n t o s o制药公司的高级管理长官Gerhard C o n t o s o公司的信息系统开发小组的新管理员Cynthia内容：客户的需求观,2023/4/26,78,谁是客户,客户是指直接或间接从产品中获得利益的个人或组织 软件客户包括提出要求、支付款项、选择、具体说明或使用软件产品的项目风险承担者(s t a k e h o l d e r)或是获得产品所产生的结果的人
23、。,2023/4/26,79,客户与开发人员之间的合作关系（Note 10）,高质量的需求来源于客户与开发人员之间有效的交流与合作 通常，开发人员与客户或客户代理人成为一种对立关系,2023/4/26,80,软件客户需求权利书（1）（Note 11）,客户有如下权利：1.要求分析人员使用符合客户语言习惯的表达。2.要求分析人员了解客户系统的业务及目标。3.要求分析人员组织需求获取期间所介绍的信息，并编写软件需求规格说明。4.要求开发人员对需求过程中所产生的工作结果进行解释说明。5.要求开发人员在整个交流过程中保持和维护一种合作的职业态度。,2023/4/26,81,软件客户需求权利书（2）(N
24、ote 12),6.要求开发人员对产品的实现及需求都要提供建议，拿出主意。7.描述产品使其具有易用、好用的特性。8.可以调整需求，允许重用已有的软件组件。9.当需要对需求进行变更时，对成本、影响、得失（t r a d e-o ff）有个真实可信的评估。10.获得满足客户功能和质量要求的系统，并且这些要求是开发人员同意的。,2023/4/26,82,软件客户需求义务书（1）(Note 13),客户有下列义务：1.给分析人员讲解业务及说明业务方面的术语等专业问题。2.抽出时间清楚地说明需求并不断完善。3.当说明系统需求时，力求准确详细。4.需要时要及时对需求做出决策。5.要尊重开发人员的成本估算和
25、对需求的可行性分析。,2023/4/26,83,软件客户需求义务书（2）（Note 14）,6.对单项需求、系统特性或使用实例划分优先级。7.评审需求文档和原型。8.一旦知道要对项目需求进行变更，要马上与开发人员联系。9.在要求需求变更时，应遵照开发组织确定的工作过程来处理。10.尊重需求工程中开发人员采用的流程（过程）。,2023/4/26,84,“签约”意味着什么(Note 15),客户与开发人员关系中的重要部分 客户代表经常把“签约”看作是毫无意义的 更为重要的是签名是建立在一个需求协议的基线上 与你的重要客户一起讨论权利书和义务书，以达成协议，并付诸实践,2023/4/26,85,高质
26、量的需求过程带来的好处(Note 16),开发后期和整个维护阶段的重做的工作大大减少 强调需求质量并不能引起某些人的重视,他们错误地认为在需求上消耗多少时间就会导致产品开发推迟多少时间将选定系统的需求明确地分配到各软件子系统，强调采用产品工程的系统方法。这样能简化硬软件的集成,2023/4/26,86,优秀需求具有的特性(Note 17),1.完整性 2.正确性 3.可行性 4.必要性 5.划分优先级 6.无二义性 7.可验证性,2023/4/26,87,3.3 需求获取的内容,1.用户需求分类(1)功能性需求:定义了系统做什么（描述系统必须支持 的功能和过程）(2)非功能性需求（技术需求）:
27、定义了系统工作时的特性（描述操作环境和性能目标）,2023/4/26,88,两类需求包括的内容,(1)功能(2)性能(3)环境(4)界面(5)用户或人的因素(6)文档,(7)数据(8)资源(9)安全保密(10)软件成本消耗与开发进度(11)质量保证,2023/4/26,89,(1)功能需求,系统做什么？系统何时做什么？系统何时及如何修改 或升级？,2023/4/26,90,(2)性能需求,软件开发的技术性指标例如：存储容量限制 执行速度、相应时间 吞吐量,2023/4/26,91,(3)环境需求,硬件设备：机型、外设、接口、地点、分布、温度、湿度、磁场干扰等软件：操作系统 网络 数据库,202
28、3/4/26,92,(4)界面需求,有来自其它系统的输入吗？到自其它系统的输出吗？对数据格式有规定吗？对数据存储介质有规定吗？,2023/4/26,93,(5)用户或人的因素,用户类型？各种用户熟练程度？需受何种训练？用户理解、使用系统的难度？用户错误操作系统的可能性？,2023/4/26,94,(6)文档需求,需哪些文档？文档针对哪些读者？,2023/4/26,95,(7)数据需求,输入、输出数据的格式？接收、发送数据的频率？数据的准确性和精度？数据流量？数据需保持的时间？,2023/4/26,96,(8)资源需求,软件运行时所需的数据、软件。内存空间等资源。软件开发、维护所需的人力、支撑软
29、件、开发设备等。,2023/4/26,97,(9)安全保密要求,需对访问系统或系统信息加以控制吗？如何隔离用户之间的数据？用户程序如何与其它程序和操作系统隔离？系统备份要求？,2023/4/26,98,(10)软件成本消耗 与开发进度需求,开发有规定的时间表吗？软硬件投资有无限制？,2023/4/26,99,(11)质量保证,系统的可靠性要求？系统必须监测和隔离错误吗？规定系统平均出错时间？出错后，重启系统允许的时间？系统变化如何反映到设计中？维护是否包括对系统的改进？系统的可移植性？,2023/4/26,100,怎样写需求分析报告,作报告时要先从宏观上讲一、二、三、四、五，再从细节上讲A、B
30、、C、D、E。需求分析不象侦探推理那样从蛛丝马迹着手。应该先了解宏观的问题，再了解细节的问题 如图 S=D1，D2，D3，Dn Di=P1，P2，P3，Pm Pj=F1，F2，F3，Fk,2023/4/26,101,怎样写需求分析报告,2023/4/26,102,3.4 需求的开发和管理,整个软件需求工程研究领域划分为需求开发和需求管理两部分更合适,需求工程域的层次分解示意图,2023/4/26,103,需求开发(Note 18),问题获取（e l i c i t a t i o n）分析(a n a l y s i s)编写规格说明（s p e c i f i c a t i o n）验证（
31、v e r i f i c a t i o n）,2023/4/26,104,知识技能(Note 19),绝大部分的软件开发人员都没有接受过高效需求工程所需技能的正规培训培训需求分析人员所有的开发人员都应接受一个基本的需求工程培训培训软件需求的用户代表和管理人员参与软件开发的用户代表应接受为期一天左右,关于需求工程的培训，开发管理者和客户管理者也应参加 让开发人员了解应用领域的基本概念组织一些简短的关于客户业务活动、术语、目标等方面的讨论会以帮助开发人员对应用领域有个基本了解,2023/4/26,105,需求获取(1)(Note 20),确定需求开发过程 编写项目视图和范围文档项目视图 将用户
32、群分类并归纳各自特点 选择每类用户的产品代表 建立起典型用户的核心队伍把同类产品或你的产品的先前版本用户代表召集起来，从他们那里收集目前产品的功能需求和非功能需求,2023/4/26,106,需求获取(2)(Note 21),让用户代表确定使用实例 召开应用程序开发联系会议 分析用户工作流程观察用户执行业务任务的过程 确定质量属性和其它非功能需求在功能需求之外再考虑一下非功能的质量特点 通过检查当前系统的问题报告来进一步完善 可查看需求是否有足够的灵活性以允许重用一些已有的软件组件,2023/4/26,107,需求分析（Note 22）,绘制系统关联图。建立数据字典。为需求建立模型。建立用户接
33、口原型。确定需求优先级。,2023/4/26,108,需求规格说明（SRS）（Note 23）,采用原始模板在你的组织中要为编写软件需求文档定义一种标准模板 指明需求的来源 为每项需求注上标号制定一种惯例来为每项需求提供一个独立的可识别的标号或记号 记录业务规范业务规范创建需求跟踪能力矩阵,2023/4/26,109,需求验证（Note 24）,对需求文档进行正式审查 以需求为依据编写测试用例编写用户手册在需求开发早期即可起草一份用户手册确定合格的标准让用户描述什么样的产品才算满足他们的要求和适合他们使用的,2023/4/26,110,需求管理(Note 25),确定一个选择、分析和决策需求变
34、更的过程 建立变更控制委员会 评估每项选择的需求变更跟踪所有受需求变更影响的工作产品 建立需求基准版本和需求控制版本文档 维护需求变更的历史记录记录 跟踪每项需求的状态建立一个数据库衡量需求稳定性记录基准需求的数量和变更数量 使用需求管理工具商业化的需求管理工具,2023/4/26,111,项目管理（Note 26）,选择一种合适的软件开发方法生存周期项目开发计划的进度安排将会不断改变 发生需求变更时协商项目约定 编写文档和管理与需求相关的风险 跟踪需求工程所耗的工作量,2023/4/26,112,需求开发与需求管理之间的界限(Note 27),2023/4/26,113,3.5 改进需求过程
35、(Note 28),软件开发过程的改进有以下两个主要目标：解决在以前项目或目前项目中遇到的问题。防止和避免你可能在将来的项目中要遇到的问题。,2023/4/26,114,四条改进软件的原则(Note 29),改进过程应该是革命性的、彻底的、连续的、反复的 人们和组织机构都只有在他们获得激励时才愿意变更 过程变更是面向目标的将改进活动看作一些小项目,2023/4/26,115,过程改进周期(Note 30),评价当前采用的方法,指定活动改进计划,创建、实验和实施新过程,评价结果,图：软件开发过程改进的周期,发现和建议,活动计划,新的过程，实验结果，获得经验,实施情况怎样,活动计划的效果如何,新过
36、程是否达到预期目标？,计划下一步的改进周期,2023/4/26,116,3.6 软件需求与风险管理（Note 31）,听一个故事：同样在C o n t o s o制药公司 主人公“化学制品跟踪系统”的项目管理人员D a v e 首席程序员H e l e n 首席测试员R a m e s h 内容需求工程的风险 为何物？,2023/4/26,117,软件风险管理的要素（Note 32）,风险管理就是使用某些工具和步骤把项目风险限制在一个可接受的范围内。风险管理提供了一种标准的方法来指出风险并把风险因素编成文档，评估其潜在的威胁，以及确定减少这些风险评价（risk assessment）风险避免（
37、risk avoidance）风险控制（risk control）,2023/4/26,118,编写项目风险文档(Note 33),2023/4/26,119,与需求有关的风险,下面介绍的风险因素是按需求工程中获取、分析、编写规格说明、验证和管理汇总起来的，并推荐了一些方法用于降低风险发生的可能性或减轻风险发生给项目带来的影响。这张清单仅仅是一个起点，在你做项目逐渐积累经验过程中，加入你的风险因素清单和减轻风险的策略。使用这里提供的条目来帮助你识别需求风险并采用条件结果的格式来书写风险说明。,2023/4/26,120,需求获取（Note 34）,1)产品视图与范围 2)需求开发所需时间 3)
38、需求规格说明的完整性和正确性 4)对革新产品的需求 5)明确非功能需求 6)客户赞同产品需求 7)未加说明的需求 8)把已有的产品作为需求基线 9)给出期望的解决办法,2023/4/26,121,需求分析（Note 35）,1)划分需求优先级 2)带来技术困难的特性 3)不熟悉的技术、方法、语言、工具或硬件平台,2023/4/26,122,需求规格说明（Note 36）,1)需求理解 2)时间压力对T B D的影响 3)具有二义性的术语 4)需求说明中包括了设计,2023/4/26,123,需求验证（Note 37）,1)未经验证的需求 2)审查的有效性,2023/4/26,124,需求管理(
39、Note 38),1)变更需求 2)需求变更过程 3)未实现的需求 4)扩充项目范围,2023/4/26,125,建立项目视图与范围(Note 39),一个项目可能包括一些与软件没有直接关系的需求，例如：硬件的购买、产品的安装、维护或广告。但在此，我们只关心与软件产品有关系的业务需求。,2023/4/26,126,通过业务需求确定项目视图(Note 40),项目视图可以把项目参与者定位到一个共同和明确的方向上 项目视图描述了产品所涉及的各个方面和在一个完美环境中最终所具有的功能 市场需求文档&视图和范围的文档 来自各个渠道的业务需求可能会发生冲突,2023/4/26,127,项目视图和范围文档
40、的模板(Note 41),a.业务需求a.1 背景a.2 业务机遇a.3 业务目标a.4 客户或市场需求a.5 提供给客户的价值a.6 业务风险b.项目视图的解决方案b.1 项目视图陈述b.2 主要特性,b.3 假设和依赖环境c.范围和局限性c.1 首次发行的范围c.2 随后发行的范围c.3 局限性和专用性d.业务环境d.1 客户概貌d.2 项目优先级e.产品成功的因素,2023/4/26,128,计算机学科的发展,计算学科是研究通过在计算机上建立模型并模拟物理过程来进行科学调查和研究的学科.,学科的3个形态理论抽象(模型化)设计重复出现的概念绑定(binding)概念与形式模型一致性和完备性
41、抽象层次重用典型的学科方法：数学方法系统科学方法,计算中抽象的本质和使用。在处理复杂事务、构造系统、隐藏细节和获取重复模式方面使用抽象，通过具有不同层次的细节和指标的抽象，能够表达一个实体和系统,计算机科学与技术学科的方法论,2023/4/26,130,模型(model),模型:现实世界某些重要方面的表示。有时我们使用术语“抽象”来表示模型，因为我们从现实世界中抽象出对我们特别有用的东西。,2023/4/26,131,抽象(模型化),源于实验科学,主要要素为数据采集方法和假设的形式说明,模型的构造与预测实验分析结果分析.在为可能的算法数据结构和系统结构等构造模型时使用此过程.抽象的结果是概念符
42、号模型,2023/4/26,132,3.4 需求分析的步骤,2023/4/26,133,逻辑模型和物理模型,模型是对对象系统的形式化的特征 抽象，概括性或近似地表示构造模型的过程是一个抽象、分 析的过程。,逻辑模型 物理模型(本质模型、概念模型)(实施模型、技术模型),现行系统,目标系统,描述重要的业务功能，无论系统是如何实施的。,描述现实系统是如何在物理上实现的。,描述新系统的主要业务功能和用户新的需求，无论系统应如何实施。,描述新系统是如何实施的（包括技术）。,2023/4/26,135,分析阶段中常用的模型（逻辑模型）,数据流图（DFD）实体联系图（ERD）类图实例图时序图状态图,协作图
43、事件列表数据流定义数据元素定义,2023/4/26,136,数据流图(DFD，Data Flow Diagram)(Note 42),描述逻辑模型的图形工具，表示数据在系统内的变化。DFD可以用来表示一个系统或软件在任何层次上的抽象。较大型软件系统DFD分成多层(子图、父图概念),可以表示数据流和功能的进一步的细节。,2023/4/26,137,数据流程图的表示（page 29-32）,数据源点和终点,变换数据的加工,文件,数据,逻辑关系符号：与、或、异或,2023/4/26,138,画数据流图（page 3233）,规则：由外向里画画系统的输出、输入化系统的内部画加工的内部,2023/4/2
44、6,139,应该注意的几个问题（page 33-34）,适当地命名画数据流而不是控制流先考虑稳定状态忽略琐碎的枝节随时准备重画,2023/4/26,140,分层数据流图,对于大型系统，往往使用一张数据流图画出所有数据流和加工是不可能的自顶向下逐层分解不要一下子引入过多细节，应该逐步增加细节例子（page 35）：图3.13（a）画出了.。图3说明“产生新文件”。显然。,2023/4/26,141,由顶向下画分层数据流图（page 37）,描绘中应该注意的问题：编号父图和子图的平衡局部文件分解的程度,2023/4/26,142,实例运动会管理系统,自学3.3.5节（Page 40）,2023/4
45、/26,143,数据流图的改进,检查数据流图的正确性数据守恒（page 41-42）文件的使用（page 42）父图和子图的平衡（page 42-43）提高数据流图的易理解性简化加工间的联系（page 43）分解的均匀（page 43）适当地命名（page 43-44）重新分解（page 44）,2023/4/26,144,数据实体关联图(Note 43),与数据流图描绘了系统中发生的过程一样，实体联系图（entity-relationship diagram，E R D）描绘了系统的数据关系 分析实体联系图有助于对业务或系统数据组成的理解和交互，并暗示产品将有必要包含一个数据库。实体（e n
46、 t i t y）是物理数据项（包括人）或者数据项的集合，这对所分析的业务或所要构造的系统是很重要的,2023/4/26,145,“化学制品跟踪系统”的实体联系图,2023/4/26,146,需求建模实例酒店管理系统的局部DFD,已预订的入住,预订请求,预订,预订确认,未预订的入住,已预订的入住请求,未预订的入住请求,客人数据,客房数据,预订确认信息,客人信息,夜审,结算信息,财务系统,时钟,2023/4/26,147,需求建模实例：某金融贸易系统用例图(UML),2023/4/26,148,需求建模实例：用例图举例（UML）,签定一份保险单,客户,保险销售人员,销售统计,客户统计,需求建模实
47、例：UML类图实例(Note 44),2023/4/26,150,需求建模实例：描述客房状态的状态图(Note 45),取消,预定,入住,已预订,空闲,占用,维修,维修,完成,退房换房,入住,事件,创建,2023/4/26,151,需求建模实例：接电话的顺序图（UML）,2023/4/26,152,需求建模实例：UML协作图举例,2023/4/26,153,3.5 数据词典(DD，DataDictionary),DD是对所有与系统相关的数据元素的一个有组织的列表,以及精确的、严格的定义，使得用户和系统分析员对于输入、输出、存储成分和中间计算有共同的理解,2023/4/26,154,词典与数据流
48、图之间关系（page 44）,数据流图描述了系统的“分解”；依靠“词典”来说明各个成分的含义；数据流图中所有名字的定义就构成一本词典；数据流图和词典结合在一起构成了“需求说明书”数据流图中出现的每一个数据流名、每一个文件名和每一个加工名在词典中都应该有一个条目给出这个名字的定义。,2023/4/26,155,词典条目的各种类型（page.45）,四个类型条目数据流文件数据项（指不在分解的数据单位）加工词典条目的实例（page 4647）结合上次自习的内容自行学习本节,2023/4/26,156,需求建模实例：数据字典条目的定义,预订请求客人数据住宿期限+客房类别客人数据客人姓名+地址+身份证号
49、码+护照号码+支付方式 身份证号码=十进制15数字18护照号码字母+8数字8字母“A”“Z”十进制数字“0”“9”,2023/4/26,157,需求建模实例：数据字典条目的定义,F1:航班信息文件航空公司名称航班号起点终点日期 起飞时间降落时间航空公司名称2字母4 航班号3十进制数字3 字母“A”“Z”十进制数字“0”“9”起点终点1汉字10 起飞时间降落时间时分,2023/4/26,158,需求建模实例：数据字典条目的定义,时“00”“23”分“00”“59”日期年月日 年2000200120022004 月“01”“12”日“01”“31”,2023/4/26,159,3.6 小说明,数据
50、流图中每一个基本加工（即不再进一步被分解的加工）都必须有一个“小说明”小说明中应精确描述用户要求一个加工“做什么”加工的激发条件加工逻辑加工优先级加工执行频率出错处理,2023/4/26,160,结构化的语言（page 51）,构成方式语态词汇举例,2023/4/26,161,判定表与判定树（page 54-56）,有些问题不易用单纯的语言表达判定表组成：条件桩条件条目操作桩操作条目判定树,2023/4/26,162,3.7 模型的作用,在建模过程中了解系统通过抽象降低复杂性有助于回忆所有的细节有助于开发小组间的交流有助于与用户的交流为系统的维护提供文档,2023/4/26,163,需求分析建
