面向对象分析建模OOA

2024/1/161第一章软件工程概述2024/1/162§1.1软件工程的背景和历史1968年由NATO(北大西洋公约组织)在德国Garmish召开的学术会议上，FeitzBauer首先提出了“软件工程”概念。2024/1/163软件工程与编程前者是一门学科，一种科学理论来指导软件系统开发，标准化，自动化的过程考虑如何分解一个系统，以便各人分工开发；考虑如何说明每个部分的规格要求；怎样才能易于维护单纯的代码编写是软件工程发展的前身是软件工程中占据很少时间和空间的一部分2024/1/164计算机学科的发展计算机科学(CS)计算机科学(CS)计算机工程(CE)软件工程(SE)信息系统(IS)计算学科(computingdiscipline)2024/1/16560年代以来工厂管理病人监护工资统发图书馆管理机票预定学籍管理

早期

第二阶段第三阶段第四阶段

面向批处理

多用户

分布式系统

强大的桌面系统

有限的分布

实时

嵌入“智能”

面向对象技术

自定义软件

数据库

低成本硬件

专家系统

软件产品

消费者的影响

人工神经网络

并行计算

网络计算机195019601970198019902000Evolutionofsoftware#2024/1/167为什么发展如此之快不准确的时间和金钱的估算软件质量的低下相对硬件产品开发软件开发费用的增加维护、增强软件系统的必要性硬件价格大幅度下降2024/1/168软件技术面临的问题

规模复杂性生产率

Windows95有1000万行代码

Windows2000有5000万行代码例：Exchange2000和Windows2000开发人员结构Exchange2000Windows2000项目经理25人约250人开发人员140人约1700人测试人员350人约3200人2024/1/1610《人月神话》焦油坑

史前史中，没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼。上帝见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。它们挣扎得越是猛烈，焦油纠缠得越紧，没有任何猛兽足够强壮或具有足够的技巧，能够挣脱束缚，它们最后都沉到了坑底。

2024/1/1611软件危机的主要特征软件开发周期大大超过规定日期;

软件开发成本严重超标;

软件质量难于保证。2024/1/1612软件工程的定义FritzBauer在NATO会议上给出的定义：

“软件工程是为了经济地获得可靠的和能在实际机器上高效运行的软件而确立和使用的健全的工程原理（方法）。”2024/1/1613软件工程的定义（2）IEEE【IEE83】给出的软件工程定义：

“软件工程是开发、运行、维护和修复软件的系统方法。”2024/1/1614软件工程的定义（3）IEEE【IEE93】给出了一个更加综合的定义：

“将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程，即将工程化应用于软件中。”软件工程是一门交叉学科软件工程的主要研究内容软件开发技术:软件开发方法学软件开发过程

软件工具和软件工程环境软件工程管理:软件管理学软件经济学软件心理学

软件工程所包含的内容不是一成不变的，随着人们对软件系统的研制开发和生产的理解。应用发展的眼光看待它。2024/1/1616软件工程—一种层次化技术工具方法过程质量焦点Softwareengineeringlayers软件工程三个要素：方法、工具、过程2024/1/1617软件工程与一般工程的差异软件是逻辑产品而不是实物产品软件的功能依赖于硬件和软件的运行环境以及人们对它的操作软件设计的复杂性软件特征： 功能的多样性 实现的多样性 能见度低 软件结构合理性差智力密集及知识产权保护2024/1/1618软件工程知识结构

2001年5月ISO/IECJTC1（ISO和IEC的第一联合技术委员会）发布了《SWEBOK指南V0.95(试用版)》SWEBOK把软件工程学科的主体知识分为10个知识领域。2024/1/1619软件工程知识结构

软件需求软件设计软件构造软件测试软件维护软件配置管理软件工程管理软件工程过程软件工程工具和方法软件质量2024/1/1620“软件工程”课程

与其它软件专业课的区别(1)立足于系统的整体。(2)讲授系统分析、系统设计、测试及维护的理论和方法。(3)构筑一个软件系统，实践软件开发全过程。2024/1/1621“软件工程”课程教学的目标转变对软件的认识：上升

程序系统转变思维定式：上升

程序员系统工程师

(系统分析员)2024/1/1622软件产品的标准化软件开发过程的标准化2024/1/1623软件的工业化生产过程应具备的特点：明确的工作步骤详细具体的规范化文档明确的质量评价标准“一个好的工业，应有一套

良好的标准来配套”2024/1/1624软件工程技术的两个特点

强调规范化强调文档化2024/1/1625§1.2软件和软件生命期模型(SoftwareLifeCycle)软件产品或软件系统从设计、投入使用到被淘汰的全过程。2024/1/1626软件生存期的阶段划分(1)可行性研究与计划(2)需求分析(3)总体设计(4)详细设计(5)实现(6)集成测试(7)确认测试(8)使用和维护成长期（开发期）怀孕期（计划期）

成年期（运行期）2024/1/1627新的国际标准定义的软件生存过程（1995ISO/IEC12207）软件生存期过程支持过程组织过程主要过程获取过程供应过程开发过程运行过程维护过程文档编制过程配置管理过程质量保证过程验证过程确认过程联合评审过程审核过程问题解决过程管理过程基础设施过程改进过程培训过程2024/1/1628软件工作的范围只考虑编写程序

涉及整个软件生存周期扩展到2024/1/1629

软件开发模型是软件开发全部过程、活动和任务的结构框架。它能直观表达软件开发全过程，明确规定要完成的主要活动、任务和开发策略。软件开发模型也常称为： 软件过程模型 软件生存周期模型 软件工程范型软件开发模型可行性研究与计划需求分析设计编码运行维护测试定义阶段开发阶段维护阶段瀑布模型(WaterfallModel)2024/1/1631开发软件不仅仅是编程2024/1/1632按照传统瀑布模型开发软件的特点1.阶段间具有顺序性和依赖性。2.推迟实现的观点。3.每个阶段必须完成规定的文档;

每个阶段结束前完成文档审查,

及早改正错误。2024/1/1633原型模型（快速原型模型）原型范型用户测试运行原型建造/修改原型

听取用户意见采用原型模型的软件生存周期分析定义系统需求生成原型系统设计程序设计编码测试运行和维护原型化含原型化的软件生存期2024/1/1635§1.3软件质量的评价成功的标准：

用户在用用户可很容易做完要做的事失败的根本原因：

开发人员写出的东西达不到用户要求(人的问题.技术问题)2024/1/1636质量与生产率质量是软件需求方最关心的问题，用户即使不图物美价廉，也要求个货真价实

质量与生产率之间有着内在的联系，高生产率必须以质量合格为前提

质量与生产率的提高就指望程序员与程序经理

非得在质量与生产率之间分个主次不可，那么应该是质量第一，生产率第二

2024/1/1637质量与生产率（2）质量直接体现在软件的每段程序中，高质量自然是开发人员的技术追求，也是职业道德的要求

高质量对所有的用户都有价值，而高生产率只对开发方有意义

如果一开始就追求高生产率，容易使人急功近利，留下隐患

2024/1/1638不贪污的官就是好官吗“运行正确”的程序就是高质量的程序吗？也许运行速度很低并且浪费内存；也许代码写得一塌糊涂

2024/1/1639软件的质量因素

软件的质量因素很多，如正确性、精确性、可靠性、容错性、性能、效率、易用性、可理解性、简洁性、可复用性、可扩充性、兼容性等等（还可以列出十几个）

一般说来倾向于可维护性、可靠性、可理解性和效率2024/1/1640软件质量因素分类和武学分类正确性与精确性易用性可理解性与简洁性性能与效率可复用性与可扩充性少林派、武当派华山派昆仑派峨嵋派崆峒派2024/1/1641正确性与精确性

机器不会主动欺骗人，软件运行不正确或者不精确一般都是人造成的

需求分析错了，那么对客户而言这个软件也存在错误

如果软件没有100%地按需求规格执行，那么这个软件也存在错误程序员要为“正确”、“精确”四个字竭尽全力

2024/1/1642性能与效率

用户都希望软件的运行速度高些（高性能），并且占用资源少些（高效率）

旧社会地主就是这么对待长工的：干活要快点，吃得要少点

通过优化算法、数据结构和代码组织来提高软件系统的性能与效率优化的关键工作是找出限制性能与效率的“瓶颈”

2024/1/1643易用性

导致软件易用性差的根本原因是开发人员犯了“错位”的毛病：他以为只要自己用起来方便，用户也一定会满意

当用户真的感到软件很好用时，一股温暖的感觉油然而生，于是就用“友好”来评价易用性

2024/1/1644可理解性与简洁性（Note1）

开发人员只有在自己思路清晰时才可能写出让别人能理解的程序

编程时还要注意不可滥用技巧，应该用自然的方式编程

简洁是一种美

如果把学术文章写得很简洁，让人很容易理解，它往往中不了

2024/1/1645可复用性与可扩充性

一种方式是原封不动地使用现成的软件构件

一种方式是对现成的软构件进行必要的扩充后再使用

可复用性好的程序一般也具有良好的可扩充性

2024/1/1646可行性研究与计划需求分析设计编码运行维护测试测试已经开始返回上级，再…..瀑布模型的质量保障体系2024/1/1647小结（Note2）软件的高质量主要是设计出来的不是“管”出来的更不能依赖质量检查。

2024/1/1648第二章

可行性研究与计划2024/1/1649系统流程图（Note3）输入单据磁盘文件处理输出单据2024/1/1650数据流程图数据源点和终点变换数据的加工文件数据逻辑关系符号：与、或、异或2024/1/1651§2.1可行性研究基本概念可行性研究的任务:

可行性研究的主要任务是“了解客户的要求及现实环境，从技术、经济和社会因素等三方面研究并论证本软件项目的可行性，编写可行性研究报告，制定初步项目开发计划。”2024/1/1652可行性研究的内容(1)技术可行性(2)经济可行性(3)操作可行性(4)社会可行性(法律可行性)(5)抉择2024/1/1653技术可行性(Note4)度量一个特定技术信息系统解决方案的实用性及技术资源的可用性考虑的问题开发风险分析资源分析相关技术的发展（现有技术能否实现新系统，技术难点、建议采用技术的先进性）2024/1/1654经济可行性度量系统解决方案的性能价格比考虑的问题成本/效益分析有形成本、效益无形成本、效益价值和成本的关系质量与价值、成本的关系价值/成本的均衡2024/1/1655经济可行性考虑的问题(Note5)成本和效益的估算开发成本的估算开发效益的估算运行成本的估算运行效益的估算2024/1/1656成本分析代码行技术（page19）任务估算技术（page20）总成本、总人力相对误差在内Putnam估算模型（page21）COCOMO模型比较复杂2024/1/1657效益分析系统的经济效益＝使用新系统增加收入＋使用心系统可以节省的运行费用总的效益和软件生存周期有关货币的时间价值（page23）投资回收期（page23）投资回收率（page23）纯收入（page23）投资回收率2024/1/1658系统开发和每年运行费用举例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,4002024/1/1659系统开发和每年运行费用举例.1名数据通讯专家(60小时/名,42美元/小时)$2,4002名在转换期间数据输入人员$49,500(40小时/名,12美元/小时)2024/1/1660系统开发和每年运行费用举例培训：三天的开发人员内部培训课程$7,00030个用户，三天的内部培训课程$10,000物资：复印$500磁盘、纸张等消耗品$6502024/1/1661系统开发和每年运行费用举例购买硬件、软件：20台工作站Windows软件$1,00020台工作站内存升级$8,000网络软件$17,50020台工作站办公软件产品$20,000系统开发总费用$161,6702024/1/1662系统开发和每年运行费用举例2.年运行费用（每年）人员：维护程序员/分析员(250小时/年,42美元/小时)

$10,500网络管理员(300小时/年,50美元/小时)$15,000购买硬件、软件升级：硬件$5,000软件$6,000物资和杂项$3,500每年总运行费用$40,0002024/1/1663操作可行性

用户使用可能性时间进度可行性组织和文化上的可行性2024/1/1664社会可行性(法律可行性)开发项目是否会在社会上或政治上引起侵权、破坏或其它责任问题2024/1/1665可行性研究计划的完成可行性研究计划2024/1/1666§2.3可行性研究的步骤（page15）

(1)复查确认系统目标、规模

(2)研究正使用系统工作流程

(3)导出新系统高层逻辑模型

(4)重新定义问题

(5)导出和评价供选择的方案

(6)推荐可行的方案

(7)草拟开发计划

(8)编写可行性研究报告，送审2024/1/1667第三章需求分析和规格说明2024/1/1668§3.1为什么需要需求分析开发人员往往急于求成希望对开发进行指导希望开发人员对用户的要求理解希望用户理解开发人员测试部门有理可依2024/1/1669需求分析的任务

准确地定义未来系统的目标，确定为了满足用户的需求系统必须做什么。用<需求规格说明书>规范的形式准确地表达用户的需求。2024/1/1670什么是用户需求思考、涉及的几个问题如何识别、获取需求?

你能够采取何种手段与用户进行交流沟通?何为需求建模?

你如何理解模型与建模?2024/1/1671软件需求分析的几个阶段问题分析问题评估和方案综合建模规约复审系统分析员的主要焦点是“做什么（what）”，不是“怎样做（how）”2024/1/1672需求获取面临的挑战(Note6)

客户说不清楚需求需求易变性问题的复杂性和对问题空间理解的不完备性与不一致性2024/1/1673§3.2需求获取的常用方法（Note7）建立分析小组领域专家：主角系统分析员：导演客户访谈问题分析与确认某出版社系统调查表编号提出问题1您在哪个部门工作？2出版业务流程是什么？3您每日都处理那些文件、数据、报表？4工作中手工处理特别麻烦的事情是什么？5工作中手工处理什么问题解决不了？影响效率的问题有哪些？6您认为提高工作效率，节省工作时间，减轻工作强度可采取哪些办法？某出版社系统调查表编号提出问题7您的部门需要成本核算和统计的内容有哪些？8您的部门采用计算机管理工作情况如何？9如何改进业务流程使之更合理？10哪些问题是目前传统手工方法根本无法解决的？11出版社计算机管理信息系统需要解决什么问题？2024/1/1676听一个故事（Note8）主人公：Contoso制药公司的高级管理长官GerhardContoso公司的信息系统开发小组的新管理员Cynthia内容：客户的需求观

2024/1/1677谁是客户客户是指直接或间接从产品中获得利益的个人或组织

软件客户包括提出要求、支付款项、选择、具体说明或使用软件产品的项目风险承担者(stakeholder)或是获得产品所产生的结果的人。2024/1/1678客户与开发人员之间的合作关系（Note10）

高质量的需求来源于客户与开发人员之间有效的交流与合作

通常，开发人员与客户或客户代理人成为一种对立关系

2024/1/1679软件客户需求权利书（1）（Note11）

客户有如下权利：1.要求分析人员使用符合客户语言习惯的表达。2.要求分析人员了解客户系统的业务及目标。3.要求分析人员组织需求获取期间所介绍的信息，并编写软件需求规格说明。4.要求开发人员对需求过程中所产生的工作结果进行解释说明。5.要求开发人员在整个交流过程中保持和维护一种合作的职业态度。2024/1/1680软件客户需求权利书（2）(Note12)6.要求开发人员对产品的实现及需求都要提供建议，拿出主意。7.描述产品使其具有易用、好用的特性。8.可以调整需求，允许重用已有的软件组件。9.当需要对需求进行变更时，对成本、影响、得失（trade-off）有个真实可信的评估。10.获得满足客户功能和质量要求的系统，并且这些要求是开发人员同意的。

2024/1/1681软件客户需求义务书（1）(Note13)客户有下列义务：1.给分析人员讲解业务及说明业务方面的术语等专业问题。2.抽出时间清楚地说明需求并不断完善。3.当说明系统需求时，力求准确详细。4.需要时要及时对需求做出决策。5.要尊重开发人员的成本估算和对需求的可行性分析。2024/1/1682软件客户需求义务书（2）（Note14）6.对单项需求、系统特性或使用实例划分优先级。7.评审需求文档和原型。8.一旦知道要对项目需求进行变更，要马上与开发人员联系。9.在要求需求变更时，应遵照开发组织确定的工作过程来处理。10.尊重需求工程中开发人员采用的流程（过程）。

2024/1/1683“签约”意味着什么

(Note15)客户与开发人员关系中的重要部分

客户代表经常把“签约”看作是毫无意义的

更为重要的是签名是建立在一个需求协议的基线上

与你的重要客户一起讨论权利书和义务书，以达成协议，并付诸实践2024/1/1684高质量的需求过程带来的好处(Note16)开发后期和整个维护阶段的重做的工作大大减少

强调需求质量并不能引起某些人的重视,他们错误地认为在需求上消耗多少时间就会导致产品开发推迟多少时间将选定系统的需求明确地分配到各软件子系统，强调采用产品工程的系统方法。这样能简化硬软件的集成

2024/1/1685优秀需求具有的特性(Note17)1.完整性

2.正确性

3.可行性

4.必要性

5.划分优先级

6.无二义性

7.可验证性

2024/1/1686§3.3需求获取的内容

1.用户需求分类(1)功能性需求:

定义了系统做什么（描述系统必须支持的功能和过程）(2)非功能性需求（技术需求）:

定义了系统工作时的特性（描述操作环境和性能目标）2024/1/1687两类需求包括的内容(1)功能(2)性能(3)环境(4)界面(5)用户或人 的因素(6)文档(7)数据(8)资源(9)安全保密(10)软件成本消耗 与开发进度(11)质量保证2024/1/1688(1)功能需求

系统做什么？系统何时做什么？系统何时及如何修改或升级？2024/1/1689(2)性能需求软件开发的技术性指标例如：存储容量限制执行速度、相应时间吞吐量2024/1/1690(3)环境需求硬件设备：机型、外设、接口、地点、分布、温度、湿度、磁场干扰等软件：操作系统网络数据库2024/1/1691(4)界面需求

有来自其它系统的输入吗？到自其它系统的输出吗？对数据格式有规定吗？对数据存储介质有规定吗？2024/1/1692(5)用户或人的因素

用户类型？各种用户熟练程度？需受何种训练？用户理解、使用系统的难度？用户错误操作系统的可能性？2024/1/1693(6)文档需求

需哪些文档？文档针对哪些读者？2024/1/1694(7)数据需求

输入、输出数据的格式？接收、发送数据的频率？数据的准确性和精度？数据流量？数据需保持的时间？2024/1/1695(8)资源需求

软件运行时所需的数据、软件。内存空间等资源。软件开发、维护所需的人力、支撑软件、开发设备等。2024/1/1696(9)安全保密要求

需对访问系统或系统信息加以控制吗？如何隔离用户之间的数据？用户程序如何与其它程序和操作系统隔离？系统备份要求？2024/1/1697(10)软件成本消耗

与开发进度需求开发有规定的时间表吗？软硬件投资有无限制？2024/1/1698(11)质量保证

系统的可靠性要求？系统必须监测和隔离错误吗？规定系统平均出错时间？出错后，重启系统允许的时间？系统变化如何反映到设计中？维护是否包括对系统的改进？系统的可移植性？2024/1/1699怎样写需求分析报告作报告时要先从宏观上讲一、二、三、四、五，再从细节上讲A、B、C、D、E。需求分析不象侦探推理那样从蛛丝马迹着手。应该先了解宏观的问题，再了解细节的问题

如图

S={D1，D2，D3，…Dn}Di={P1，P2，P3，…Pm}Pj={F1，F2，F3，…Fk}2024/1/16100怎样写需求分析报告2024/1/16101§3.4需求的开发和管理

整个软件需求工程研究领域划分为需求开发和需求管理两部分更合适

需求工程域的层次分解示意图

2024/1/16102需求开发(Note18)

问题获取（elicitation）分析(analysis)编写规格说明（specification）验证（verification）

2024/1/16103知识技能

(Note19)

绝大部分的软件开发人员都没有接受过高效需求工程所需技能的正规培训培训需求分析人员所有的开发人员都应接受一个基本的需求工程培训培训软件需求的用户代表和管理人员参与软件开发的用户代表应接受为期一天左右,关于需求工程的培训，开发管理者和客户管理者也应参加让开发人员了解应用领域的基本概念组织一些简短的关于客户业务活动、术语、目标等方面的讨论会以帮助开发人员对应用领域有个基本了解

2024/1/16104需求获取(1)(Note20)

确定需求开发过程

编写项目视图和范围文档项目视图

将用户群分类并归纳各自特点

选择每类用户的产品代表

建立起典型用户的核心队伍把同类产品或你的产品的先前版本用户代表召集起来，从他们那里收集目前产品的功能需求和非功能需求

2024/1/16105需求获取(2)(Note21)让用户代表确定使用实例

召开应用程序开发联系会议

分析用户工作流程观察用户执行业务任务的过程

确定质量属性和其它非功能需求在功能需求之外再考虑一下非功能的质量特点

通过检查当前系统的问题报告来进一步完善

可查看需求是否有足够的灵活性以允许重用一些已有的软件组件

2024/1/16106需求分析（Note22）绘制系统关联图。建立数据字典。为需求建立模型。建立用户接口原型。确定需求优先级。

2024/1/16107需求规格说明（SRS）（Note23）采用原始模板在你的组织中要为编写软件需求文档定义一种标准模板

指明需求的来源

为每项需求注上标号制定一种惯例来为每项需求提供一个独立的可识别的标号或记号

记录业务规范业务规范创建需求跟踪能力矩阵

2024/1/16108需求验证（Note24）对需求文档进行正式审查

以需求为依据编写测试用例编写用户手册在需求开发早期即可起草一份用户手册确定合格的标准让用户描述什么样的产品才算满足他们的要求和适合他们使用的

2024/1/16109需求管理(Note25)确定一个选择、分析和决策需求变更的过程

建立变更控制委员会

评估每项选择的需求变更跟踪所有受需求变更影响的工作产品建立需求基准版本和需求控制版本文档维护需求变更的历史记录记录跟踪每项需求的状态建立一个数据库衡量需求稳定性记录基准需求的数量和变更数量使用需求管理工具商业化的需求管理工具

2024/1/16110项目管理（Note26）选择一种合适的软件开发方法生存周期项目开发计划的进度安排将会不断改变发生需求变更时协商项目约定编写文档和管理与需求相关的风险跟踪需求工程所耗的工作量

2024/1/16111分析编写文档评审，商议基准需求说明需求变更过程管理客户需求市场当前基线修正后基线市场，客户，管理项目环境需求开发与需求管理之间的界限(Note27)

2024/1/16112§3.5改进需求过程(Note28)软件开发过程的改进有以下两个主要目标：解决在以前项目或目前项目中遇到的问题。防止和避免你可能在将来的项目中要遇到的问题。2024/1/16113四条改进软件的原则(Note29)改进过程应该是革命性的、彻底的、连续的、反复的

人们和组织机构都只有在他们获得激励时才愿意变更

过程变更是面向目标的将改进活动看作一些小项目2024/1/16114过程改进周期(Note30)

评价当前采用的方法指定活动改进计划创建、实验和实施新过程评价结果图：软件开发过程改进的周期发现和建议活动计划新的过程，实验结果，获得经验实施情况怎样活动计划的效果如何新过程是否达到预期目标？计划下一步的改进周期2024/1/16115§3.6软件需求与风险管理（Note31）听一个故事：同样在Contoso制药公司主人公“化学制品跟踪系统”的项目管理人员Dave

首席程序员Helen

首席测试员Ramesh

内容需求工程的风险为何物？2024/1/16116软件风险管理的要素（Note32）风险管理就是使用某些工具和步骤把项目风险限制在一个可接受的范围内。风险管理提供了一种标准的方法来指出风险并把风险因素编成文档，评估其潜在的威胁，以及确定减少这些风险评价（riskassessment）风险避免（riskavoidance）

风险控制（riskcontrol）

2024/1/16117编写项目风险文档(Note33)2024/1/16118与需求有关的风险

下面介绍的风险因素是按需求工程中获取、分析、编写规格说明、验证和管理汇总起来的，并推荐了一些方法用于降低风险发生的可能性或减轻风险发生给项目带来的影响。这张清单仅仅是一个起点，在你做项目逐渐积累经验过程中，加入你的风险因素清单和减轻风险的策略。使用这里提供的条目来帮助你识别需求风险并采用条件—结果的格式来书写风险说明。2024/1/16119需求获取

（Note34）1)产品视图与范围2)需求开发所需时间3)需求规格说明的完整性和正确性4)对革新产品的需求5)明确非功能需求6)客户赞同产品需求7)未加说明的需求8)把已有的产品作为需求基线9)给出期望的解决办法2024/1/16120需求分析（Note35）1)划分需求优先级2)带来技术困难的特性3)不熟悉的技术、方法、语言、工具或硬件平台2024/1/16121需求规格说明

（Note36）1)需求理解2)时间压力对TBD的影响3)具有二义性的术语4)需求说明中包括了设计

2024/1/16122需求验证

（Note37）1)未经验证的需求2)审查的有效性2024/1/16123需求管理

(Note38)1)变更需求

2)需求变更过程

3)未实现的需求

4)扩充项目范围

2024/1/16124建立项目视图与范围(Note39)一个项目可能包括一些与软件没有直接关系的需求，例如：硬件的购买、产品的安装、维护或广告。但在此，我们只关心与软件产品有关系的业务需求。2024/1/16125通过业务需求确定项目视图(Note40)项目视图可以把项目参与者定位到一个共同和明确的方向上

项目视图描述了产品所涉及的各个方面和在一个完美环境中最终所具有的功能

市场需求文档

&视图和范围的文档

来自各个渠道的业务需求可能会发生冲突

2024/1/16126项目视图和范围文档的模板(Note41)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.产品成功的因素2024/1/16127计算机学科的发展计算机科学(CS)计算机科学(CS)计算机工程(CE)软件工程(SE)信息系统(IS)计算学科(computingdiscipline)计算学科是研究通过在计算机上建立模型并模拟物理过程来进行科学调查和研究的学科.学科的3个形态理论抽象(模型化)设计重复出现的概念绑定(binding)概念与形式模型一致性和完备性抽象层次重用……典型的学科方法：数学方法系统科学方法……

计算中抽象的本质和使用。在处理复杂事务、构造系统、隐藏细节和获取重复模式方面使用抽象，通过具有不同层次的细节和指标的抽象，能够表达一个实体和系统计算机科学与技术学科的方法论2024/1/16129模型(model)模型:现实世界某些重要方面的表示。有时我们使用术语“抽象”来表示模型，因为我们从现实世界中抽象出对我们特别有用的东西。2024/1/16130抽象(模型化)源于实验科学,主要要素为数据采集方法和假设的形式说明,模型的构造与预测实验分析结果分析.在为可能的算法数据结构和系统结构等构造模型时使用此过程.抽象的结果是概念符号模型2024/1/16131§3.4需求分析的步骤当前系统目标系统物理模型逻辑模型逻辑模型物理模型模型化抽象化具体化实例化怎么做做什么当前系统目标系统需求定义2024/1/16132逻辑模型和物理模型模型是对对象系统的形式化的特征抽象，概括性或近似地表示构造模型的过程是一个抽象、分析的过程。对象系统模型系统抽象（映射）模型应用模型构造的过程

逻辑模型物理模型

(本质模型、概念模型)

(实施模型、技术模型)现行系统目标系统描述重要的业务功能，无论系统是如何实施的。描述现实系统是如何在物理上实现的。描述新系统的主要业务功能和用户新的需求，无论系统应如何实施。描述新系统是如何实施的（包括技术）。2024/1/16134分析阶段中常用的模型

（逻辑模型）数据流图（DFD）实体―联系图（ERD）类图实例图时序图状态图协作图事件列表数据流定义数据元素定义

……2024/1/16135数据流图

(DFD，DataFlowDiagram)(Note42)

描述逻辑模型的图形工具，表示数据在系统内的变化。

DFD可以用来表示一个系统或软件在任何层次上的抽象。较大型软件系统DFD分成多层(子图、父图概念),可以表示数据流和功能的进一步的细节。2024/1/16136数据流程图的表示（32）数据源点和终点变换数据的加工文件数据逻辑关系符号：与、或、异或2024/1/16137画数据流图（page32－33）规则：由外向里画画系统的输出、输入化系统的内部画加工的内部2024/1/16138应该注意的几个问题（34）适当地命名画数据流而不是控制流先考虑稳定状态忽略琐碎的枝节随时准备重画2024/1/16139分层数据流图对于大型系统，往往使用一张数据流图画出所有数据流和加工是不可能的自顶向下逐层分解不要一下子引入过多细节，应该逐步增加细节例子（page35）：

图3.13（a）画出了…..。图3说明“产生新文件”……。显然……。2024/1/16140由顶向下画分层数据流图（page37）描绘中应该注意的问题：编号父图和子图的平衡局部文件分解的程度2024/1/16141实例——运动会管理系统自学3.3.5节（Page40）2024/1/16142数据流图的改进检查数据流图的正确性数据守恒（42）文件的使用（page42）父图和子图的平衡（43）提高数据流图的易理解性简化加工间的联系（page43）分解的均匀（page43）适当地命名（44）重新分解（page44）2024/1/16143数据实体关联图(Note43)与数据流图描绘了系统中发生的过程一样，实体联系图（entity-relationshipdiagram，ERD）描绘了系统的数据关系

分析实体联系图有助于对业务或系统数据组成的理解和交互，并暗示产品将有必要包含一个数据库。

实体（entity）是物理数据项（包括人）或者数据项的集合，这对所分析的业务或所要构造的系统是很重要的

2024/1/16144化学制品仓库存货清单化学制品容器存储执行化学制品请求1MM1“化学制品跟踪系统”的实体联系图2024/1/16145需求建模实例

酒店管理系统的局部DFD已预订的入住预订请求预订预订确认未预订的入住已预订的入住请求未预订的入住请求客人数据客房数据预订确认信息客人信息夜审结算信息财务系统时钟2024/1/16146需求建模实例：

某金融贸易系统用例图(UML)风险分析交易估计进行交易进行交易接待员酒店系统财务系统2024/1/16147需求建模实例：

用例图举例（UML）签定一份保险单客户保险销售人员销售统计客户统计需求建模实例：

UML类图实例(Note44)客人姓名地址身份证号码护照号码……预订……入住住宿编号付款方式……退房……客房状态日期人数……设置状态

……客房……服务日期数量设置……读取……服务类别名称价格设置

……10..*10..*0..*0..11..*10..*1*2024/1/16149需求建模实例：

描述客房状态的状态图(Note45)取消预定入住已预订空闲占用维修维修完成退房换房入住事件创建2024/1/16150需求建模实例：

接电话的顺序图

（UML）受话者交换机远程交换机受话者拿起话筒听通话声拨号码铃响信号铃响铃响停止信号

拿起话筒铃响停止<10

deabc{b-a<1}{e-d<5}{c-b<10}路径2024/1/16151需求建模实例：

UML协作图举例计算机队列打印服务器打印机打印文件

打印机忙保存打印文件打印机空闲打印文件2024/1/16152§3.5数据词典

(DD，DataDictionary) DD是对所有与系统相关的数据元素的一个有组织的列表,以及精确的、严格的定义，使得用户和系统分析员对于输入、输出、存储成分和中间计算有共同的理解2024/1/16153词典与数据流图之间关系（page44）数据流图描述了系统的“分解”；依靠“词典”来说明各个成分的含义；数据流图中所有名字的定义就构成一本词典；数据流图和词典结合在一起构成了“需求说明书”数据流图中出现的每一个数据流名、每一个文件名和每一个加工名在词典中都应该有一个条目给出这个名字的定义。2024/1/16154词典条目的各种类型（page.45）四个类型条目数据流文件数据项（指不在分解的数据单位）加工词典条目的实例（page46－47）结合上次自习的内容自行学习本节2024/1/16155需求建模实例：

数据字典条目的定义预订请求＝客人数据＋住宿期限+客房类别客人数据＝客人姓名+地址+身份证号码

+[护照号码]+支付方式身份证号码=十进制15{数字}18护照号码＝字母+8{数字}8字母＝“A”…“Z”十进制数字＝“0”…“9”2024/1/16156需求建模实例：

数据字典条目的定义F1:航班信息文件＝{航空公司名称＋航班号＋起点＋终点＋日期＋起飞时间＋降落时间}航空公司名称＝2{字母}4

航班号＝3{十进制数字}3

字母＝“A”…“Z”十进制数字＝“0”…“9”起点＝终点＝1{汉字}10

起飞时间＝降落时间＝时＋分2024/1/16157需求建模实例：

数据字典条目的定义

时＝“00”…“23”

分＝“00”…“59”

日期＝年＋月＋日年＝[2000｜2001｜2002｜2004]

月＝“01”…“12”

日＝“01”…“31”2024/1/16158§3.6小说明数据流图中每一个基本加工（即不再进一步被分解的加工）都必须有一个“小说明”小说明中应精确描述用户要求一个加工“做什么”

加工的激发条件加工逻辑加工优先级加工执行频率出错处理2024/1/16159结构化的语言（page51）构成方式语态词汇举例2024/1/16160判定表与判定树（56）有些问题不易用单纯的语言表达判定表组成：条件桩条件条目操作桩操作条目判定树2024/1/16161§3.7模型的作用在建模过程中了解系统通过抽象降低复杂性有助于回忆所有的细节有助于开发小组间的交流有助于与用户的交流为系统的维护提供文档

2024/1/16162需求分析建模方法分析建模方法结构化分析(传统建模方法)面向对象分析2024/1/16163模型的作用计算机世界现实世界影射计算机世界现实世界结构化开发方法结构化分析结构化设计结构化编程OOAOODOOP面向对象开发方法模型的作用2024/1/16165结构化分析模型的组成结构数据流图

(DFD)E-R图状态变迁图(STD图)加工说明控制说明数据对象说明数据字典（DD）2024/1/16166面向对象分析模型的组成结构对象-关系模型类/对象模型对象-行为模型使用实例(UseCase)操作、属性、协作者2024/1/16167重点小结2024/1/16168§3.8结构化分析方法(StructuredAnalisys,SA)基于数据流技术的分析方法

需求获取应遵循的三条基本原则：分解抽象投影2024/1/16169分析模型的元素数据字典(DD)：模型核心(中心库)E-R图(ERD)：数据流图(DFD)

指明数据在系统中移动时如何被变换;描述对数据流进行变换的功能;DFD中每个功能的描述包含在加工规约(小说明)。状态变迁图(STD)

指明作为外部事件的结果,系统将如何动作。2024/1/16170E-R图是数据建模的基础客人入住客房状态客房服务服务类别姓名地址身份证号码护照号码电话……客房号床位数房间类别价格1……住宿编号住宿时间支付方式……日期，客人数状态(已预定/占用/维修中)……日期，数量……名称，价格……2024/1/16171将分析模型转换为软件设计数据字典数据流图E-R图状态变迁图加工规约控制规约数据对描

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

考务处理系统功能考务处理系统的分层DFD如下：2024/1/16174顶层数据流图考生考务处理系统考试中心阅卷站不合格报名单报名单准考证考生通知单成绩清单合格标准错误成绩清单考生名单统计分析表2024/1/161750层数据流图登记报名单报名单准考证1统计成绩2不合格报名单考生通知单成统计分析表考生名册绩清单合格标准考生名单成绩清单错误2024/1/16176一层数据流图

(a)检查报名单报名单准考证1.1编准考证号1.2不合格报名单考生名册考生名单合格报名单登记考生1.32024/1/16177一层数据流图(b)检查成绩清单2.1审定合格者2.2考生名册正确成绩清单制作通知单2.3分析统计成绩2.4分析试题难度2.5试题得分清单考生通知单难度分析表合格标准分类统计表成绩清单错误成绩清单经审定的成绩清单S2132.22.12.33.13.2

顶层（不编号）0层1层2024/1/16179数据字典举例F1:航班信息文件＝{航空公司名称＋航班号＋起点＋终点＋日期＋起飞时间＋降落时间}航空公司名称＝2{字母}4

航班号＝3{十进制数字}3

字母＝“A”…“Z”十进制数字＝“0”…“9”起点＝终点＝1{汉字}10

起飞时间＝降落时间＝时＋分2024/1/16180再来看看——

结构化分析模型的组成结构数据流图

(DFD)E-R图状态变迁图(STD图)加工说明控制说明数据对象说明数据字典（DD）2024/1/16181§3.11需求分析的其他工作（page63）确定设计限制确定验收标准编写“初步用户手册”复查需求说明书2024/1/16182补充知识UML语言和图2024/1/16183UML简介（NoteL1）UML定义由信息系统三位专家GradyBooch，JamesRumbaugh和IvarJacobonOMG组织采奶作为业界标准2024/1/16184UML的开发历程（NoteL2）Booch’91其它方法OMT-1OOSEBooch’93OMT-2UML0.8UML0.9&0.91UML1.0UML1.1UML同行专家意见OMG认证10/9510/96&9/96OMG审核,1/97OMG修正,9/97OMG采用,11/97UML1.32024/1/16185UML架构（NoteL3）UML由图和元模型组成元元模型层元模型层模型层用户模型层2024/1/16186UML的模型、视图、图与

系统架构的建模（NoteL4）用例视图逻辑视图并发视图组件视图展开视图2024/1/16187UML与面相对象的软件分析与设计（OOA&D）（NoteL5）标准的表示方法与软件开发的成功经验集成2024/1/16188UML的应用领域（NoteL6）UML被用来为系统建模，它可应用的范围非常广泛在不同系统中的应用信息系统技术系统嵌入式实时系统分布式系统商业系统2024/1/16189在软件开发不同阶段的应用（NoteL7）需求分析分析设计构造测试2024/1/16190静态建模：用例和用例图（NoteL8）用例模型的基本组成：用例、角色和系统用例图：风险分析交易估计进行交易进行交易接待员酒店系统财务系统2024/1/16191发现角色（NoteL9）通过回答下泪问题，可以帮助建模者发现角色使用系统主要功能的人是谁？需要借助于系统完成日常工作的人是谁？谁来维护、管理系统，保证系统正常工作系统控制的硬件设备有哪些？系统需要与哪些其它系统交互？对系统产生的结果感兴趣的人或事是哪些？2024/1/16192发现用例（NoteL10）询问以下问题角色需要从系统中获得哪种功能？角色需要做什么？角色需要读取、产生、删除、修改或存储系统中的信息吗？系统中发生的事件需要通知角色吗？如果用系统的新功能处理角色的日常工作是简化了还是提高了工作效率？2024/1/16193UML中的用例（NoteL11）2024/1/16194用例之间的关系（NoteL12）2024/1/16195描述用例

（NoteL13）2024/1/16196测试用例（NoteL14）用例可用于测试系统的正确性和有效性。正确性表明系统的实现符合规格说明。有效性保证开发的系统是用户真正需要的系统2024/1/16197实现用例

（NoteL15）UML中实现用例的基本思想是用协作表示用例，而协作又被细化为用若干个图。协作的实现用脚本描述。2024/1/16198第四章设计方法2024/1/16199主要内容（Note46）▲

什么是结构化设计▲结构化设计方法的主要思想▲结构化设计的重要组成部分▲结构化设计的方法2024/1/16200结构化设计的工作原理（Note47）结构化设计目标结构化设计的优点利用模块结构减少开发和维护软件的费用2024/1/16201软件设计分为两个阶段：(1)概要设计(总体设计)（Page66）确定软件的结构以及各组成成分(子系统或模块)之间的相互关系。(2)详细设计确定模块内部的算法和数据结构，产生描述各模块程序过程的详细文档。2024/1/16202模块模块是鱼油一定功能的可以用名词调用的程序语句集合，如：独立的汇编程序COBOL的段和节Pascal过程FORTRAN的子程序汇编的宏2024/1/16203控制结构(程序结构)控制结构是软件模块间关系的表示2024/1/16204控制结构图示：2024/1/16205控制结构的层次规则只有一个顶层(0层)模块

0层外任一模块都会在它的邻层存在一模块与它有关同层模块间不发生联系2024/1/16206软件结构度量术语深度宽度扇出扇入(模块的层数)(同一层最大模块数)(一个模块直接调用的模块数)(调用一个给定模块的模块个数)2024/1/16207模块化(Modularity)模块化是好的软件设计的一个基本准则高层模块从整体上把握问题,隐蔽细节复杂问题较小问题

分解可减小解题所需的总的工作分解2024/1/16208抽象(Abstraction)抽象原则应用举例WindowsNT一体化的I/O系统设计文件管理网络管理设备管理高速缓冲存储器ＯＳ对虚拟文件的字节流,虚拟文件可为任何设备和实体抽象2024/1/16209例:将问题(P1+P2)分解为P1,P2设函数C(x)定义问题

x

的复杂程度函数E(x)确定解决问题

x

需要的工作量对问题P1和P2，如：

C(P1)>C(P2)显然：E(P1)>E(P2)有规律：C(P1+P2)>C(P1)+C(P2)

E(P1+P2)>E(P1)+E(P2)

＂各个击破＂理论2024/1/16210模块度(Note48)成本或工作量模块数量软件总成本集成成本成本/模块M最小成本区域2024/1/16211结构化设计的适用范围（Note49）尤其适用于采用结构化程序设计实现的系统结构化设计并不是一种广泛适用的系统设计技术什么人来完成设计呢？结构化设计的结果2024/1/16212SA与SD的关系（Note50）结构化分析的结果结构化设计的工具数据流图初始结构图生存周期字典的数据部分设计数据字典伪码实现方面伪码实体关系图数据库设计事务框图分层、细化事务模型2024/1/16213SD来源于SA来源：结构化分析来源：结构化分析来源：结构化分析数据流图字典项伪码实体关系图事务框图环境的限制质量的标准转化分析细化设计进入实现阶段初始结构框图2024/1/16214概要设计的基本概念将系统划分成模块（Page66）决定每个模块的功能（Page66）决定模块的调用关系（Page66）决定模块的界面，即模块间传递的数据（Page66）2024/1/16215结构化设计（SD方法）概要相对独立、单一功能的模块（page67）块间联系和块内联系（page67）描述方法（page68）步骤（page69）2024/1/16216结构图(SCStructureChart)结构图主要成分（page68）模块——用方框表示，方框中写有模块的名字，一个模块的名字应适当地反映这个模块的功能，这就在某种程度上反映了块内联系；调用——从一个模块指向另一个模块的箭头表示前一模块中含有对后一模块的调用；数据——调用箭头边上的小箭头表示调用时从一个模块传入送给另一个模块的数据，小箭头也指出了传送的方向。2024/1/16217结构图(SCStructureChart)SD方法在概要设计中的主要表达工具约定：编辑学生记录读学生记录学生数据无此学生学号不加区分的数据数据信息控制信息2024/1/16218SC中的四种模块传入模块(a)(b)AA传出模块BB变换模块(c)CD协调模块E(d)EFF2024/1/16219SC中的选择调用ACBDA根据内部判断决定是否调用BA按另一判定结果选择调用C或D2024/1/16220SC中的循环调用ABCA根据内在的循环重复调用B、C等模块2024/1/16221结构图(SC)举例医院管理系统门诊管理药房管理药库管理病房管理财务管理处方挂号处理挂号费总计挂号单挂号费总计出库处理进药管理病历管理处方管理常规处理2024/1/16222酒店管理信息系统功能结构图HMIS收银管理子系统收银管理子系统收银管理子系统客人登记预定登记客房处理历史记录客房查询预定查询餐桌安排菜单作业营业结帐汇总打印各类查询初始设置客帐处理退房处理夜审处理客帐查询报表打印2024/1/16223大型零售商场管理信息系统功能结构图TMMIS系统维护POS系统零售实时系统商品进货管理商品批发管理商品库存管理商品及商品帐管理顾客管理连锁店管理财务管理人事工资管理计划统计管理经理查询2024/1/16224信息隐蔽(InformationHiding)模块所包含的信息，不允许其它不需要这些信息的模块访问，独立的模块间仅仅交换为完成系统功能而必须交换的信息。2024/1/16225块间联系块间联系大小：方式、作用、数量联系方式（Page71）用过程语句调用、直接引用共用信息的作用（Page73）公用信息的数量（Page74）表格4.1（page75）2024/1/16226块内联系偶然型（Page76）逻辑型（Page76）瞬时型（Page77）通讯型（Page77）顺序型（Page78）功能型（Page78）2024/1/16227偶然内聚(巧合内聚)ABCMMOVEOTORREADFILEFMOVESTOT模块M中的三个语句没有任何联系缺点：可理解性差，可修改性差例:2024/1/16228逻辑内聚把几种相关功能（逻辑上相似的功能）组合在一模块内，每次调用由传给模块的参数确定执行哪种功能。2024/1/16229逻辑内聚模块ABCEFGABCEFGA1B1C1EFG模块内部逻辑E、F、G逻辑功能相似，组成新模块EFG缺点：增强了耦合程度(控制耦合)

不易修改，效率低公用代码段公用代码段2024/1/16230时间内聚(经典内聚)模块完成的功能必须在同一时间内执行，这些功能只因时间因素关联在一起。例如:初始化系统模块、系统结束模块、紧急故障处理模块等均是时间性聚合模块.2024/1/16231过程内聚（顺序性组合）模块内各处理成分相关，且必须以特定次序执行2024/1/16232过程内聚模块读入成绩单审查成绩单统计成绩打印成绩读入并审查成绩单统计并打印成绩单2024/1/16233通信内聚模块内各部分使用相同的输入数据，或产生相同的输出结果2024/1/16234通信内聚模块例产生工资报表计算平均工资职工工资记录职工工资报表平均工资产生职工工资报表并计算平均工资模块2024/1/16235信息内聚模块完成多个功能，各功能都在同一数据结构上操作，每一功能有唯一入口。2024/1/16236信息内聚模块符号

表查找登录删除修改几个加工同时引用一个共同的数据2024/1/16237功能内聚模块仅包括为完成某个功能所必须的所有成分。模块所有成分共同完成一个功能，缺一不可

内聚性最强2024/1/16238块间联系无直接关系型数据耦合标记耦合控制耦合外部耦合公共耦合内容耦合2024/1/16239(1)无直接耦合

两个模块没有直接关系(模块1和模块2)，模块独立性最强。模块1模块2模块3模块4240(2)数据耦合

一模块调用另一模块时，被调用模块的输入、输出都是简单的数据(若干参数)。属松散耦合。241数据耦合举例开发票计算水费单价数量金额242(3)标记耦合(复合型耦合)

如两个模块通过传递数据结构(不是简单数据，而是记录、数组等)加以联系，或都与一个数据结构有关系,则称这两个模块间存在标记偶合。243标记耦合举例计算水电费计算水费计算电费住户情况水费电费住户情况“住户情况”是一个数据结构,图中模块都与此数据结构有关.“计算水费”和“计算电费”本无关,由于引用了此数据结构产生依赖关系,它们之间也是标记偶合.244将标记耦