软件工程培训课件(ppt 512页).ppt

1、2020/8/13,1,课名： 软 件 工 程,主 讲： 谢 明 志 Email：,使用教材：软件系统开发技术（修订版） 潘锦平 施小英 姚天昉 西安电子科技大学出版社,2020/8/13,2,第一章 软件工程概述,2020/8/13,3,1.1 软件工程的背景和历史,1968年由NATO (北大西洋公约组织)在德国Garmish召开的学术会议上，Feitz Bauer首先提出了“软件工程”概念。,2020/8/13,4,软件工程与编程,前者是一门学科，一种科学理论来指导软件系统开发，标准化，自动化的过程 考虑如何分解一个系统，以便各人分工开发；考虑如何说明每个部分的规格要求；怎样才能易于维护

2、,单纯的代码编写 是软件工程发展的前身 是软件工程中占据很少时间和空间的一部分,2020/8/13,5,计算机学科的发展,计算机科学 (CS),计算机科学 (CS),计算机工程 (CE),软件工程 (SE),信息系统 (IS),计算学科 (computing discipline),2020/8/13,6,60年代以来,工厂管理 病人监护 工资统发 图书馆管理 机票预定 学籍管理,早期 第二阶段 第三阶段 第四阶段 面向批处理 多用户 分布式系统 强大的桌面系统 有限的分布 实时 嵌入“智能” 面向对象技术 自定义软件 数据库 低成本硬件 专家系统 软件产品 消费者的影响 人工神经网络 并行计

3、算 网络计算机,1950,1960,1970,1980,1990,2000,Evolution of software#,2020/8/13,8,为什么发展如此之快,不准确的时间和金钱的估算 软件质量的低下 相对硬件产品开发软件开发费用的增加 维护、增强软件系统的必要性 硬件价格大幅度下降,2020/8/13,9,软件技术面临的问题,规模 复杂性 生产率,Windows95有1000万行代码 Windows2000有5000万行代码,例：,Exchange2000和 Windows2000开发人员结构,2020/8/13,11,人月神话焦油坑,史前史中，没有别的场景比巨兽在焦油坑中垂死挣扎的场

4、面更令人震撼。上帝见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。它们挣扎得越是猛烈，焦油纠缠得越紧，没有任何猛兽足够强壮或具有足够的技巧，能够挣脱束缚，它们最后都沉到了坑底。,2020/8/13,12,软件危机的主要特征,软件开发周期大大超过规定 日期; 软件开发成本严重超标; 软件质量难于保证。,2020/8/13,13,软件工程的定义,Fritz Bauer在NATO会议上给出的定义： “软件工程是为了经济地获得可靠的和能在实际机器上高效运行的软件而确立和使用的健全的工程原理（方法）。”,2020/8/13,14,软件工程的定义（2）,IEEE【IEE83】给出的软件工程定义： “软件工程是开发

5、、运行、维护和修复软件的系统方法。”,2020/8/13,15,软件工程的定义（3）,IEEE【IEE93】给出了一个更加综合的定义： “将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程，即将工程化应用于软件中。”,软件工程是一门交叉学科,软件工程的主要研究内容 软件开发技术:软件开发方法学 软件开发过程 软件工具和软件工程环境 软件工程管理:软件管理学 软件经济学 软件心理学 软件工程所包含的内容不是一成不变的， 随着人们对软件系统的研制开发和生产的理解。 应用发展的眼光看待它。,2020/8/13,17,软件工程 一种层次化技术,工具,方法,过程,质量焦点,Softwar

6、e engineering layers,软件工程三个要素：方法、工具、过程,2020/8/13,18,软件工程与一般工程的差异,软件是逻辑产品而不是实物产品 软件的功能依赖于硬件和软件的运行环境以及人们对它的操作 软件设计的复杂性 软件特征： 功能的多样性 实现的多样性 能见度低 软件结构合理性差 智力密集及知识产权保护,2020/8/13,19,软件工程知识结构,2001年5月ISO/IEC JTC 1（ISO和IEC的第一联合技术委员会）发布了 SWEBOK指南V0.95(试用版) SWEBOK把软件工程学科的主体知识分为10个知识领域。,2020/8/13,20,软件工程知识结构,软件

7、需求 软件设计 软件构造 软件测试 软件维护 软件配置管理 软件工程管理 软件工程过程 软件工程工具和方法 软件质量,2020/8/13,21,“软件工程”课程 与其它软件专业课的区别,(1) 立足于系统的整体。 (2) 讲授系统分析、系统设计、 测试及维护的理论和方法。 (3) 构筑一个软件系统，实践 软件开发全过程。,2020/8/13,22,“软件工程”课程教学的目标,转变对软件的认识： 上升 程序 系统 转变思维定式： 上升 程序员 系统工程师 (系统分析员),2020/8/13,23,软件产品的标准化,软件开发过程的标准化,2020/8/13,24,软件的工业化生产过程应具备的特点：

8、 明确的工作步骤 详细具体的规范化文档 明确的质量评价标准,“一个好的工业，应有一套良好的标准来配套”,2020/8/13,25,软件工程技术的两个特点,强调规范化 强调文档化,2020/8/13,26,1.2 软件和软件生命期模型,(Software Life Cycle) 软件产品或软件系统从设计、投入使用到被淘汰的全过程。,2020/8/13,27,软件生存期的阶段划分,(1)可行性研究与计划 (2)需求分析 (3)总体设计 (4)详细设计 (5)实现 (6)集成测试 (7)确认测试 (8)使用和维护,成长期（开发期）,怀孕期（计划期）,成年期（运行期）,2020/8/13,28,新的国

9、际标准定义的软件生存过程（1995 ISO/IEC 12207）,软件生存期过程,支持过程,组织过程,主要过程,获 取 过 程,供 应 过 程,开 发 过 程,运 行 过 程,维 护 过 程,文 档 编 制 过 程,配 置 管 理 过 程,质 量 保 证 过 程,验 证 过 程,确 认 过 程,联 合 评 审 过 程,审 核 过 程,问 题 解 决 过 程,管 理 过 程,基 础 设 施 过 程,改 进 过 程,培 训 过 程,2020/8/13,29,软件工作的范围,只考虑 编写程序,涉及整个 软件生存 周期,扩展到,2020/8/13,30,软件开发模型是软件开发全部过程、活动和任务的结构

10、框架。它能直观表达软件开发全过程，明确规定要完成的主要活动、任务和开发策略。 软件开发模型也常称为： 软件过程模型 软件生存周期模型 软件工程范型,软件开发模型,可行性研究与计划,需求分析,设计,编码,运行维护,测试,定义 阶段,开 发 阶 段,维护阶段,瀑布模型(Waterfall Model),2020/8/13,32,开发软件不仅仅是编程,2020/8/13,33,按照传统瀑布模型开发软件的特点,1.阶段间具有顺序性和依赖性。 2.推迟实现的观点。 3.每个阶段必须完成规定的文档; 每个阶段结束前完成文档审查, 及早改正错误。,2020/8/13,34,原型模型（快速原型模型）,原型范型

11、,用户测试 运行原型,建造/修改 原型,听取用 户意见,采用原型模型的软件生存周期,分析定义 系统需求,生成 原型,系统 设计,程序 设计,编码,测试,运 行 和维护,原型化,含原型化的 软件生存期,2020/8/13,36,1.3 软件质量的评价,成功的标准： 用户在用 用户可很容易做完要做的事 失败的根本原因： 开发人员写出的东西达不到 用户要求(人的问题.技术问题),2020/8/13,37,质量与生产率,质量是软件需求方最关心的问题，用户即使不图物美价廉，也要求个货真价实 质量与生产率之间有着内在的联系，高生产率必须以质量合格为前提 质量与生产率的提高就指望程序员与程序经理 非得在质量

12、与生产率之间分个主次不可，那么应该是质量第一，生产率第二,2020/8/13,38,质量与生产率（2）,质量直接体现在软件的每段程序中，高质量自然是开发人员的技术追求，也是职业道德的要求 高质量对所有的用户都有价值，而高生产率只对开发方有意义 如果一开始就追求高生产率，容易使人急功近利，留下隐患,2020/8/13,39,不贪污的官就是好官吗,“运行正确”的程序就是高质量的程序吗？ 也许运行速度很低并且浪费内存；也许代码写得一塌糊涂,2020/8/13,40,软件的质量因素,软件的质量因素很多，如正确性、精确性、可靠性、容错性、性能、效率、易用性、可理解性、简洁性、可复用性、可扩充性、兼容性等

13、等（还可以列出十几个） 一般说来倾向于可维护性、可靠性、可理解性和效率,2020/8/13,41,软件质量因素分类和武学分类,2020/8/13,42,正确性与精确性,机器不会主动欺骗人，软件运行不正确或者不精确一般都是人造成的 需求分析错了，那么对客户而言这个软件也存在错误 如果软件没有100% 地按需求规格执行，那么这个软件也存在错误 程序员要为“正确”、“精确”四个字竭尽全力,2020/8/13,43,性能与效率,用户都希望软件的运行速度高些（高性能），并且占用资源少些（高效率） 旧社会地主就是这么对待长工的：干活要快点，吃得要少点 通过优化算法、数据结构和代码组织来提高软件系统的性能与

14、效率优化的关键 工作是找出限制性能与效率的“瓶颈”,2020/8/13,44,易用性,导致软件易用性差的根本原因是开发人员犯了“错位”的毛病：他以为只要自己用起来方便，用户也一定会满意 当用户真的感到软件很好用时，一股温暖的感觉油然而生，于是就用“友好”来评价易用性,2020/8/13,45,可理解性与简洁性（Note 1）,开发人员只有在自己思路清晰时才可能写出让别人能理解的程序 编程时还要注意不可滥用技巧，应该用自然的方式编程 简洁是一种美 如果把学术文章写得很简洁，让人很容易理解，它往往中不了,2020/8/13,46,可复用性与可扩充性,一种方式是原封不动地使用现成的软件构件 一种方式

15、是对现成的软构件进行必要的扩充后再使用 可复用性好的程序一般也具有良好的可扩充性,2020/8/13,47,测试已经开始,返回上级，再.,瀑布模型的质量保障体系,2020/8/13,48,小结（Note 2）,软件的高质量主要是设计出来的 不是“管”出来的 更不能依赖质量检查。,2020/8/13,49,第二章 可行性研究与计划,2020/8/13,50,系统流程图（Note 3）,输入单据 磁盘文件 处理 输出单据,2020/8/13,51,数据流程图,数据源点和终点,变换数据的加工,文件,数据,逻辑关系符号：与、或、异或,2020/8/13,52, 2.1可行性研究基本概念,可行性研究的任

16、务:可行性研究的主要任务是“了解客户的要求及现实环境，从技术、经济和社会因素等三方面研究并论证本软件项目的可行性，编写可行性研究报告，制定初步项目开发计划。”,2020/8/13,53,可行性研究的内容,(1)技术可行性 (2)经济可行性 (3)操作可行性 (4)社会可行性(法律可行性) (5)抉择,2020/8/13,54,技术可行性(Note 4),度量一个特定技术信息系统解决方案的实用性及技术资源的可用性 考虑的问题 开发风险分析 资源分析 相关技术的发展（现有技术能否实现新系统，技术难点、建议采用技术的先进性）,2020/8/13,55,经济可行性,度量系统解决方案的性能价格比 考虑的

17、问题 成本/效益分析 有形成本、效益 无形成本、效益 价值和成本的关系 质量与价值、成本的关系 价值/成本的均衡,2020/8/13,56,经济可行性考虑的问题(Note 5),成本和效益的估算 开发成本的估算 开发效益的估算 运行成本的估算 运行效益的估算,2020/8/13,57,成本分析,代码行技术 （page 19） 任务估算技术 （page 20） 总成本、总人力相对误差在 内 Putnam估算模型 （page 21 ） COCOMO模型比较复杂,2020/8/13,58,效益分析,系统的经济效益使用新系统增加收入使用心系统可以节省的运行费用 总的效益和软件生存周期有关 货币的时间价

18、值（page23） 投资回收期（page23） 投资回收率（page23） 纯收入（page23） 投资回收率,2020/8/13,59,系统开发和每年运行费用举例,1.系统开发费用（一次） .2名系统分析员(450小时/名,45美元/小时) $40,500 .5名系统开发人员(275小时/名,36美元/小时)$49,500 .1名数据库管理员(30小时/名,42美元/小时) $1,260 .2名技术写作者(120小时/名,25美元/小时) $6,000 .1名秘书(160小时/名,15美元/小时) $2,400,2020/8/13,60,系统开发和每年运行费用举例,.1名数据通讯专家(60小

19、时/名,42美元/小时) $2,400 2名在转换期间数据输入人员 $49,500 (40小时/名,12美元/小时),2020/8/13,61,系统开发和每年运行费用举例,培训： 三天的开发人员内部培训课程 $7,000 30个用户，三天的内部培训课程 $10,000 物资： 复印 $500 磁盘、纸张等消耗品 $650,2020/8/13,62,系统开发和每年运行费用举例,购买硬件、软件： 20台工作站Windows软件 $1,000 20台工作站内存升级 $8,000 网络软件 $17,500 20台工作站办公软件产品 $20,000 系统开发总费用 $161,670,2020/8/13,

20、63,系统开发和每年运行费用举例,2.年运行费用（每年） 人员： 维护程序员/分析员(250小时/年,42美元/小时) $10,500 网络管理员(300小时/年,50美元/小时) $15,000 购买硬件、软件升级： 硬件 $5,000 软件 $6,000 物资和杂项 $3,500 每年总运行费用 $40,000,2020/8/13,64,操作可行性,用户使用可能性 时间进度可行性 组织和文化上的可行性,2020/8/13,65,社会可行性(法律可行性),开发项目是否会在社会上或政治上引起侵权、破坏或其它责任问题,2020/8/13,66,可行性研究计划的完成,可行性研究计划,2020/8/

21、13,67,2.3 可行性研究的步骤（page15）,(1)复查确认系统目标、规模 (2)研究正使用系统工作流程 (3)导出新系统高层逻辑模型 (4)重新定义问题 (5)导出和评价供选择的方案 (6)推荐可行的方案 (7)草拟开发计划 (8)编写可行性研究报告，送审,2020/8/13,68,第三章 需求分析和规格说明,2020/8/13,69,3.1 为什么需要需求分析,开发人员往往急于求成 希望对开发进行指导 希望开发人员对用户的要求理解 希望用户理解开发人员 测试部门有理可依,2020/8/13,70,需求分析的任务,准确地定义未来系统的目标，确定为了满足用户的需求系统必须做什么。用 规

22、范的形式准确地表达用户的需求。,2020/8/13,71,什么是用户需求,思考、涉及的几个问题 如何识别、获取需求? 你能够采取何种手段与用户进行交流沟通? 何为需求建模? 你如何理解模型与建模?,2020/8/13,72,软件需求分析的几个阶段,问题分析 问题评估和方案综合 建模 规约 复审 系统分析员的主要焦点是 “做什么（what）” ，不是 “怎样做（how）”,2020/8/13,73,需求获取面临的挑战(Note 6),客户说不清楚需求 需求易变性 问题的复杂性和对问题空间 理解的不完备性与不一致性,2020/8/13,74,3.2 需求获取的常用方法（Note 7）,建立分析小组

23、 领域专家： 主角 系统分析员：导演 客户访谈 问题分析与确认,某出版社系统调查表,某出版社系统调查表,2020/8/13,77,听一个故事（Note 8）,主人公： C o n t o s o制药公司的高级管理长官Gerhard C o n t o s o公司的信息系统开发小组的新管理员Cynthia 内容： 客户的需求观,2020/8/13,78,谁是客户,客户是指直接或间接从产品中获得利益的个人或组织 软件客户包括提出要求、支付款项、选择、具体说明或使用软件产品的项目风险承担者( s t a k e h o l d e r )或是获得产品所产生的结果的人。,2020/8/13,79,客户

24、与开发人员之间的合作关系（Note 10）,高质量的需求来源于客户与开发人员之间有效的交流与合作 通常，开发人员与客户或客户代理人成为一种对立关系,2020/8/13,80,软件客户需求权利书（1）（Note 11）,客户有如下权利： 1. 要求分析人员使用符合客户语言习惯的表达。 2. 要求分析人员了解客户系统的业务及目标。 3. 要求分析人员组织需求获取期间所介绍的信息，并编写软件需求规格说明。 4. 要求开发人员对需求过程中所产生的工作结果进行解释说明。 5. 要求开发人员在整个交流过程中保持和维护一种合作的职业态度。,2020/8/13,81,软件客户需求权利书（2）(Note 12)

25、,6. 要求开发人员对产品的实现及需求都要提供建议，拿出主意。 7. 描述产品使其具有易用、好用的特性。 8. 可以调整需求，允许重用已有的软件组件。 9. 当需要对需求进行变更时，对成本、影响、得失（ t r a d e - o ff）有个真实可信的评估。 10. 获得满足客户功能和质量要求的系统，并且这些要求是开发人员同意的。,2020/8/13,82,软件客户需求义务书 （1）(Note 13),客户有下列义务： 1. 给分析人员讲解业务及说明业务方面的术语等专业问题。 2. 抽出时间清楚地说明需求并不断完善。 3. 当说明系统需求时，力求准确详细。 4. 需要时要及时对需求做出决策。

26、5. 要尊重开发人员的成本估算和对需求的可行性分析。,2020/8/13,83,软件客户需求义务书（2）（Note 14）,6. 对单项需求、系统特性或使用实例划分优先级。 7. 评审需求文档和原型。 8. 一旦知道要对项目需求进行变更，要马上与开发人员联系。 9. 在要求需求变更时，应遵照开发组织确定的工作过程来处理。 10. 尊重需求工程中开发人员采用的流程（过程）。,2020/8/13,84,“签约”意味着什么 (Note 15),客户与开发人员关系中的重要部分 客户代表经常把“签约”看作是毫无意义的 更为重要的是签名是建立在一个需求协议的基线上 与你的重要客户一起讨论权利书和义务书，以

27、达成协议，并付诸实践,2020/8/13,85,高质量的需求过程带来的好处(Note 16),开发后期和整个维护阶段的重做的工作大大减少 强调需求质量并不能引起某些人的重视,他们错误地认为在需求上消耗多少时间就会导致产品开发推迟多少时间 将选定系统的需求明确地分配到各软件子系统，强调采用产品工程的系统方法。这样能简化硬软件的集成,2020/8/13,86,优秀需求具有的特性(Note 17),1. 完整性 2. 正确性 3. 可行性 4. 必要性 5. 划分优先级 6. 无二义性 7. 可验证性,2020/8/13,87,3.3 需求获取的内容,1.用户需求分类 (1)功能性需求: 定义了系统

28、做什么（描述系统必须支持 的功能和过程） (2)非功能性需求（技术需求）: 定义了系统工作时的特性 （描述操作环境和性能目标）,2020/8/13,88,两类需求包括的内容,(1) 功能 (2) 性能 (3) 环境 (4) 界面 (5) 用户或人的因素 (6) 文档,(7) 数据 (8) 资源 (9) 安全保密 (10)软件成本消耗与开发进度 (11)质量保证,2020/8/13,89,(1) 功能需求,系统做什么？ 系统何时做什么？ 系统何时及如何修改 或升级？,2020/8/13,90,(2) 性能需求,软件开发的技术性指标 例如： 存储容量限制 执行速度、相应时间 吞吐量,2020/8/

29、13,91,(3) 环境需求,硬件设备：机型、外设、接口、 地点、分布、温度、 湿度、磁场干扰等 软件： 操作系统 网络 数据库,2020/8/13,92,(4) 界面需求,有来自其它系统的输入吗？ 到自其它系统的输出吗？ 对数据格式有规定吗？ 对数据存储介质有规定吗？,2020/8/13,93,(5) 用户或人的因素,用户类型？ 各种用户熟练程度？ 需受何种训练？ 用户理解、使用系统的难度？ 用户错误操作系统的可能性？,2020/8/13,94,(6) 文档需求,需哪些文档？ 文档针对哪些读者？,2020/8/13,95,(7) 数据需求,输入、输出数据的格式？ 接收、发送数据的频率？ 数据

30、的准确性和精度？ 数据流量？ 数据需保持的时间？,2020/8/13,96,(8) 资源需求,软件运行时所需的数据、软件。 内存空间等资源。 软件开发、维护所需的人力、 支撑软件、开发设备等。,2020/8/13,97,(9) 安全保密要求,需对访问系统或系统信息加以控制吗？ 如何隔离用户之间的数据？ 用户程序如何与其它程序和操作系统隔离？ 系统备份要求？,2020/8/13,98,(10) 软件成本消耗 与开发进度需求,开发有规定的时间表吗？ 软硬件投资有无限制？,2020/8/13,99,(11) 质量保证,系统的可靠性要求？ 系统必须监测和隔离错误吗？ 规定系统平均出错时间？ 出错后，重

31、启系统允许的时间？ 系统变化如何反映到设计中？ 维护是否包括对系统的改进？ 系统的可移植性？,2020/8/13,100,怎样写需求分析报告,作报告时要先从宏观上讲一、二、三、四、五，再从细节上讲A、B、C、D、E。需求分析不象侦探推理那样从蛛丝马迹着手。应该先了解宏观的问题，再了解细节的问题 如图 S = D1，D2，D3， Dn Di = P1，P2，P3， Pm Pj = F1，F2，F3， Fk ,2020/8/13,101,怎样写需求分析报告,2020/8/13,102,3.4 需求的开发和管理,整个软件需求工程研究领域划分为需求开发和需求管理两部分更合适,需求工程域的层次分解示意图

32、,2020/8/13,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） 验证（v e r i f i c a t i o n）,2020/8/13,104,知识技能 (Note 19),绝大部分的软件开发人员都没有接受过高效需求工程所需技能的正规培训 培训需求分析人员所有的开发人员都应接受一个基本的需求工程培训 培训软件需求的用户代表和管理人员参与软件开发的用户代表应接受为期一天左右,关于需求工程的培训，开发管理者和客户管理者也应参加 让开

33、发人员了解应用领域的基本概念组织一些简短的关于客户业务活动、术语、目 标等方面的讨论会以帮助开发人员对应用领域有个基本了解,2020/8/13,105,需求获取(1)(Note 20),确定需求开发过程 编写项目视图和范围文档项目视图 将用户群分类并归纳各自特点 选择每类用户的产品代表 建立起典型用户的核心队伍把同类产品或你的产品的先前版本用户代表召集起来，从他们那里收集目前产品的功能需求和非功能需求,2020/8/13,106,需求获取(2)(Note 21),让用户代表确定使用实例 召开应用程序开发联系会议 分析用户工作流程观察用户执行业务任务的过程 确定质量属性和其它非功能需求在功能需求

34、之外再考虑一下非功能的质量特点 通过检查当前系统的问题报告来进一步完善 可查看需求是否有足够的灵活性以允许重用一些已有的软件组件,2020/8/13,107,需求分析（Note 22）,绘制系统关联图。 建立数据字典。 为需求建立模型。 建立用户接口原型。 确定需求优先级。,2020/8/13,108,需求规格说明（SRS）（Note 23）,采用原始模板在你的组织中要为编写软件需求文档定义一种标准模板 指明需求的来源 为每项需求注上标号制定一种惯例来为每项需求提供一个独立的可识别的标号或记号 记录业务规范业务规范 创建需求跟踪能力矩阵,2020/8/13,109,需求验证（Note 24）,

35、对需求文档进行正式审查 以需求为依据编写测试用例 编写用户手册在需求开发早期即可起草一份用户手册 确定合格的标准让用户描述什么样的产品才算满足他们的要求和适合他们使用的,2020/8/13,110,需求管理(Note 25),确定一个选择、分析和决策需求变更的过程 建立变更控制委员会 评估每项选择的需求变更 跟踪所有受需求变更影响的工作产品 建立需求基准版本和需求控制版本文档 维护需求变更的历史记录记录 跟踪每项需求的状态建立一个数据库 衡量需求稳定性记录基准需求的数量和变更数量 使用需求管理工具商业化的需求管理工具,2020/8/13,111,项目管理（Note 26）,选择一种合适的软件开

36、发方法生存周期 项目开发计划的进度安排将会不断改变 发生需求变更时协商项目约定 编写文档和管理与需求相关的风险 跟踪需求工程所耗的工作量,2020/8/13,112,需求开发与需求管理之间的界限(Note 27),2020/8/13,113,3.5 改进需求过程(Note 28),软件开发过程的改进有以下两个主要目标： 解决在以前项目或目前项目中遇到的问题。 防止和避免你可能在将来的项目中要遇到的问题。,2020/8/13,114,四条改进软件的原则 (Note 29),改进过程应该是革命性的、彻底的、连续的、反复的 人们和组织机构都只有在他们获得激励时才愿意变更 过程变更是面向目标的 将改进

37、活动看作一些小项目,2020/8/13,115,过程改进周期(Note 30),评价当前采用的方法,指定活动改进计划,创建、实验和实施新过程,评价结果,图：软件开发过程改进的周期,发现和建议,活动计划,新的过程，实验结果，获得经验,实施情况怎样,活动计划的效果如何,新过程是否达到预期目标？,计划下一步的改进周期,2020/8/13,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 内容 需求工程的风险 为何物？,2

38、020/8/13,117,软件风险管理的要素（Note 32）,风险管理就是使用某些工具和步骤把项目风险限制在一个可接受的范围内。风险管理提供了一种标准的方法来指出风险并把风险因素编成文档，评估其潜在的威胁，以及确定减少这些 风险评价（risk assessment） 风险避免（ risk avoidance） 风险控制（ risk control）,2020/8/13,118,编写项目风险文档(Note 33),2020/8/13,119,与需求有关的风险,下面介绍的风险因素是按需求工程中获取、分析、编写规格说明、验证和管理汇总起来的，并推荐了一些方法用于降低风险发生的可能性或减轻风险发生给

39、项目带来的影响。 这张清单仅仅是一个起点，在你做项目逐渐积累经验过程中，加入你的风险因素清单和减轻风险的策略。使用这里提供的条目来帮助你识别需求风险并采用条件结果的格式来书写风险说明。,2020/8/13,120,需求获取 （Note 34）,1) 产品视图与范围 2) 需求开发所需时间 3) 需求规格说明的完整性和正确性 4) 对革新产品的需求 5) 明确非功能需求 6) 客户赞同产品需求 7) 未加说明的需求 8) 把已有的产品作为需求基线 9) 给出期望的解决办法,2020/8/13,121,需求分析（Note 35）,1) 划分需求优先级 2) 带来技术困难的特性 3) 不熟悉的技术、

40、方法、语言、工具或硬件平台,2020/8/13,122,需求规格说明 （Note 36）,1) 需求理解 2) 时间压力对T B D的影响 3) 具有二义性的术语 4) 需求说明中包括了设计,2020/8/13,123,需求验证 （Note 37）,1) 未经验证的需求 2) 审查的有效性,2020/8/13,124,需求管理 (Note 38),1) 变更需求 2) 需求变更过程 3) 未实现的需求 4) 扩充项目范围,2020/8/13,125,建立项目视图与范围(Note 39),一个项目可能包括一些与软件没有直接关系的需求，例如：硬件的购买、产品的安装、维护或广告。但在此，我们只关心与

41、软件产品有关系的业务需求。,2020/8/13,126,通过业务需求确定项目视图(Note 40),项目视图可以把项目参与者定位到一个共同和明确的方向上 项目视图描述了产品所涉及的各个方面和在一个完美环境中最终所具有的功能 市场需求文档 描述对数据流进行变换的功能; DFD中每个功能的描述包含在加工规约(小说明)。 状态变迁图(STD) 指明作为外部事件的结果,系统将如何 动作。,2020/8/13,171,E-R图是数据建模的基础,2020/8/13,172,将分析模型转换为软件设计,数据 字典,数据 流图,E-R图,状态变迁图,加,工,规,约,控制规约,数,据,对,描 述,象,数 据 设

42、计,体系结构设计,接口设计,过程设计,分析模型,设计模型,2020/8/13,173,3.9 实例 考务处理系统功能,(1)对考生送来的报名单进行检查; (2)对合格的报名单编好准考证号后将准考证送给考生，并将汇总后的考生名单送给阅卷站; (3)对阅卷站送来的成绩单进行检查，并根据考试中心制定的合格标准审定合格者; (4)制作考生通知单(含成绩及合格/不合格标志)送给考生; (5)按地区进行成绩分类统计和试题难度分析，产生统计分析表。,2020/8/13,174,实例 考务处理系统功能,考务处理系统的分层DFD 如下：,2020/8/13,175,顶层数据流图,考 生,考务 处理系统,考 试

43、中 心,阅卷站,不合格报名单,报名单,准考证,考生通知单,成 绩 清 单,合格标准,错误成绩 清单,考生名 单,统计分析表,2020/8/13,176,0层数据流图,2020/8/13,177,一层数据流图 (a),2020/8/13,178,一层数据流图 (b),S,2,1,3,2.2,2.1,2.3,3.1,3.2,顶层 （不编号）,0层,1层,2020/8/13,180,数据字典举例,F1:航班信息文件航空公司名称航班号 起点终点日期 起飞时间降落时间 航空公司名称2字母4 航班号3十进制数字3 字母“A”“Z” 十进制数字“0”“9” 起点终点1汉字10 起飞时间降落时间时分,2020

44、/8/13,181,再来看看结构化分析模型的组成结构,2020/8/13,182,3.11 需求分析的其他工作（page 63）,确定设计限制 确定验收标准 编写“初步用户手册” 复查需求说明书,2020/8/13,183,补充知识,UML语言和图,2020/8/13,184,UML简介（Note L1）,UML定义 由信息系统三位专家Grady Booch， James Rumbaugh和Ivar Jacobon OMG组织采奶作为业界标准,2020/8/13,185,UML的开发历程 （Note L2）,2020/8/13,186,UML架构（Note L3）,UML由图和元模型组成 元元

45、模型层 元模型层 模型层 用户模型层,2020/8/13,187,UML的模型、视图、图与系统架构的建模（Note L4）,用例视图 逻辑视图 并发视图 组件视图 展开视图,2020/8/13,188,UML与面相对象的软件分析与设计（OOA根据问题域结构可提取候选 的类及对象;,2020/8/13,378,重点,与系统发生作用的其它系统和必要 的设备可作为候选的类及对象; 如： 打印机等 (分析阶段可不把与实现有关的计算 机部件作为候选的类及对象),2020/8/13,379,重点,系统必须观测、记忆的与时间有关的 事件可作为候选的类及对象; 如：建立帐户的日期 打开一个帐户等 与系统发生交

46、互的人及系统必须保留其信息的人,可作为候选的类及对象; 如：柜员、储户等 这些人所属的组织单位，可作为候选的类及对象; 如：总行、分行等,2020/8/13,380,重点,系统必须记忆、且不在问题域约束中 的顺序操作过程(为了指导人机交互) 可作为候选的类及对象; 如：柜员事务、远程事务等。 其中属性是操作过程名,操作特权及操作 步骤的描述; 系统需了解掌握的物理位置、办公 地点等可作为候选的类及对象; 如：ATM机器、帐户等,2020/8/13,381,(2)审查和筛选,舍弃无用的类 对象的精简 只有一个属性的对象 只有一个服务的对象 推迟到OOD考虑的对象,2020/8/13,382,帐册

47、,上级系统接口,供货员,销售事件,商品,特价商品,计量商品,收款机,商品一览表,超市销售管理系统(对象层),2020/8/13,383,步骤2： 定义属性与服务,定义属性 定义服务 对象的状态与状态转换图 例：栈的状态/服务对照表,2020/8/13,384,例：栈状态转换图,2020/8/13,385,定义服务,对象行为分类 发现服务的策略 审查与调整 识别对象的主动行为 服务的详细说明(服务解释、消息协议、消息发送、约束条件、服务流程图),超市销售管理系统(特征层),帐册,前班节余 销售事件表 收入累计 上交款 本班节余,接班 计帐 报帐交班,上级系统接口,帐目目册,消息发送 查帐 报帐

48、价格更新 种类增删,供货员,缺货登记表,缺货登记 供货,销售事件,收款人 购物清单 应收款 ,销售计划 入帐,商品,编号 名称 单价 架上数量 下限,售出 补充 价格更新,特价商品,开始日期 结束日期,计量商品,*单价 计量单位 计价方式,*售出 *补充 *价格更新,收款机,本班收款员 开始时间 结束时间,登录 售货 结帐,商品一览表,商品目录,检索 种类增删,2020/8/13,387,建立数据字典,为所有模型实体准备一个数据字典, 精确描述每一个对象类,包括: 成员 约束 关联、属性、操作,2020/8/13,388,对象字典举例：,2020/8/13,389,步骤3：定义结构与连接,初步

49、确定关联 对应于描述性动词或动词短语 需求陈述中隐含 根据问题域知识得出 筛选 完善,2020/8/13,390,步骤3：定义结构与连接,分析标识对象之间的关系 对象之间的分类关系：一般-特殊结构 对象之间的组成关系：整体-部分结构 对象之间的静态联系：实例连接 对象之间的动态关系：消息连接,2020/8/13,391,从一般类发现特殊类,2020/8/13,392,从特殊类发现一般类,公司职员,股东,姓名 身分证号码 ,股份 ,职员,工资 ,股东,姓名 身分证号码 股份 ,职员,姓名 身分证号码 工资 ,？,2020/8/13,393,收款机类成为可供本领域其它系统复用的领域构件,收款机,A

50、 B C,现钞收款机,D E F,现钞收款机,A B C D E F,X Y Z,Z,X Y,为支持复用建立结构,取消没有特殊属性的特殊类,2020/8/13,395,通过增加属性简化一般-特殊结构,2020/8/13,396,两种结构的变通,冷藏车,汽车,制冷设备,冷藏车,汽车,制冷设备,仅用一般 -特殊结构,两种结构 同 用,冷藏车,汽车,制冷设备,仅用整体 -部分结构,2020/8/13,397,用整体-部分结构实现复用,车床,机床,刨床,起重机,电动机,钻床,送料车,2020/8/13,398,筛选：删除下列关联,已删去的类间的关联 无关或实现关联 瞬时事件 三元关联 派生关联,202

51、0/8/13,399,步骤4：定义服务及消息连接,分析和认识对象之间在行为上的往来关系,2020/8/13,400,顺序系统中的消息传递,2020/8/13,401,并发系统中的消息传递,2020/8/13,402,多个控制线程之间的消息与顺序系统中消息的不同之处,(1)并发执行的控制线程之间传送的消息的不同用途： 向接收者发出访问请求 向接收者提交数据 向接收者发布通知或事件信息 向接收者传递同步控制信号 (2)消息的同步与异步 (3)接收者对消息的不同响应方式 (4)发送者对消息处理结果的不同期待方式 (5)消息的接收者是否唯一 定向消息 广播消息,2020/8/13,403,OOA对消息

52、的表示消息连接,消息连接是OOA（或OOD）模型中对对象之间行为依赖关系的表示 识别和表示的主要问题： 对象之间是否存在消息？ 消息是同一线程内部的还是不同线程之间的？ 每一种消息是从发送者哪个服务发出的？ 由接收者哪个服务响应处理的？ 消息是同步还是异步？ 发送者是否等待消息的处理结果？,2020/8/13,404,如何建立消息连接,(1)建立控制线程内部的消息连接 基本策略：“服务模拟” “执行路线追踪” 具体做法： 人为地模拟当前服务的执行，通过考虑需要请求其它对象的服务来发现新消息。 分析该消息的发送者与接收者在执行时是否属于同一控制线程,2020/8/13,405,(2)建立控制线程

53、之间的消息连接,对每个控制线程考虑： 它在执行时是否需要请求其它控制线程中的对象为它提供服务？由哪个对象发出？由哪个对象中的服务处理？ 它在执行时是否要向其它控制线程中的对象提供或索取数据？ 它在执行时是否将产生对其它控制线程的执行有影响的事件？ 各个控制线程的并发执行是否要传递同步控制信号 一个控制线程在何种条件下中止执行？ 中止后在何种条件下由其它控制线程用何法唤醒?,2020/8/13,406,(3)对象分布问题及对消息的影响,每台处理机上分布的一组对象中至少应有一个主动对象； 同一台处理机上的对象之间的消息通信既可能是一个控制线程内部的，也可能是不同控制线程之间的。,(关系层, 完整的

54、类图),帐册,前班节余 销售事件表 收入累计 上交款 本班节余,接班 计帐 报帐交班,上级系统接口,帐目目册,消息发送 查帐 报帐 价格更新 种类增删,供货员,缺货登记表,缺货登记 供货,销售事件,收款人 购物清单 应收款 ,销售计划 入帐,商品,编号 名称 单价 架上数量 下限,售出 补充 价格更新,特价商品,开始日期 结束日期,计量商品,*单价 计量单位 计价方式,*售出 *补充 *价格更新,1,m,商品一览表,商品目录,检索 种类增删,1,m,收款机,本班收款员 开始时间 结束时间,登录 售货 结帐,2020/8/13,408,步骤5：标识主题(主体),Coad/Yourdon方法中主题

55、的概念： 主题是把一组具有较强联系的类组织在一起而得到的类的集合。,2020/8/13,409,主题概念及其用途,主题层是在OOA基本模型(类图)之上建立一个能帮助人们从不同的认识层次来理解系统的补充模型； 主题一种比类和对象抽象层次更高、粒度更大的概念，用以建立系统的高层抽象视图； 主题有助于指导系统设计者或用户等理解一个大的系统模型, 有助于组织一个大项目的工作。,2020/8/13,410,主题概念的特点,是由一组类构成的集合 一个主题内部的对象类应具有某种意义上的内在联系 描述系统中相对独立的组成部分（如一个子系统） 描述系统中某一方面的事物（如人员、设备） 解决系统中某一方面的问题（

56、如输入输出） 主题的划分有一定的灵活性和随意性,2020/8/13,411,如何划分主题,把每个结构作为一个主题； (选取结构中最上层的类作为一主题) 通过实例连接互相联系的类可划分到一个主题； 把不属于任何结构，也没有实例连接的类作为一个主题。,2020/8/13,412,如何精练主题,从问题域和接口复杂性两方面入手: 使用问题域精练主题,即用整体/部分结构对问题域进行划分,而不是按功能分解方法划分. 按高内聚低偶合原则,通过使主题间依赖性和交互性最小原则保留能反映子问题域的主题. 主题数目7个左右,则进一步精练主题.,2020/8/13,413,何时引入主题,依赖于模型自身复杂性 小系统:

57、 不需引入主题; 中等系统:先标识类及对象, 然后引入主题; 大系统: 先标识主题,对问题域进行 划分,分给不同的任务组,2020/8/13,414,主题层次的控制,中小型系统可只设一层主题，最多不超过两层； 大型系统可只设两层主题，最多不超过三层。,(关系层, 完整的类图),帐册,前班节余 销售事件表 收入累计 上交款 本班节余,接班 计帐 报帐交班,上级系统接口,帐目目册,消息发送 查帐 报帐 价格更新 种类增删,供货员,缺货登记表,缺货登记 供货,销售事件,收款人 购物清单 应收款 ,销售计划 入帐,商品,编号 名称 单价 架上数量 下限,售出 补充 价格更新,特价商品,开始日期 结束日期,计量商品,*单价 计量单位 计价方式,*售出 *补充 *价格更新,1,m,商品一览表,商品目录,检索 种类增删,1,m,收款机,本班收款员 开始时间 结束时间,登录 售货 结帐,1,1,1,1,3,3,3,3,2,2,2,2,2020/8/13,416,第五章 人机界面设计,2020/8/13,417,概念,人机界面（Human Computer Interface，简称HCI）通常也称为用户界面 界面设计