精品课程《软件工程》PPT课件-

1、软件工程软件工程第一章 概述使用规范说明图表应用强调背景文本和线条阴影标题文本填充强调超链接已访超链接标准配色单击此处添加标题单击添加目录内容1单击添加目录内容2单击添加目录内容3单击添加目录内容4单击添加目录内容5单击添加目录内容6单击添加目录内容7一、软件定义软件程序文档数据程序按事先设计的功能和性能要求执行的指令序列数据能使程序正常操作信息的数据结构文档与程序开发、管理、维护和使用有关的图文资料二、软件的特点和分类软件是一个逻辑实体，而不是具体的物理实体，因而具有抽象性软件生产与硬件生产不同，没有明显的制造过程软件不会用坏，但比较难维护软件本身是复杂的，使人类能够创造的最复杂的产物123

2、4软件本身成本昂贵5软件分类见表1.26三、软件危机1、什么是软件危机： 如何开发软件，以满足不断增长，日趋复杂的需求；如何维护数量不断膨胀的软件产品。软件开发成本和进度的估算常常不准确用户对完成的软件系统不满意现象经常发生软件产品的质量往往靠不住； Bug一大堆软件常常是不可维护的软件通常没有适当的文档资料2、软件危机的表现软件成本在计算机系统成本中所占的比例逐年上升软件开发生产率提高的速度远远跟不上硬件的发展和人们需求的增长软件本身特点：逻辑部件：管理和控制软件开发过程相当困难，较难维护规模庞大：代码长度不正比程序复杂程度软件产品的质量往往靠不住； Bug一大堆软件常常是不可维护的软件通常

3、没有适当的文档资料软件成本在计算机系统成本中所占的比例逐年上升软件开发生产率提高的速度远远跟不上硬件的发展和人们需求的增长3、产生软件危机的原因单击此处添加标题文字内容文字内容文字内容单击此处添加段落文字内容单击此处添加段落文字内容单击此处添加段落文字内容单击添加段落文字单击添加段落文字单击添加段落文字单击添加段落文字。单击添加段落文字单击添加段落文字单击添加段落文字单击添加段落文字。单击此处添加标题单击此处添加标题段落一单击添加内容文字单击添加段落文字单击添加段落文字单击添加段落文字单击添加段落文字。单击此处添加段落文字内容单击此处添加段落文字内容单击此处添加段落文字内容单击此处添加段落文字

4、内容单击此处添加段落文字内容单击此处添加标题单击添加单击添加单击添加单击添加单击添加单击添加内容文字单击添加单击添加内容文字单击添加单击添加内容文字单击添加单击添加内容文字单击此处添加标题单击此处添加标题文字内容文字内容文字内容双击添加标题文字单击此处添加标题此处添加内容单击添加段落文字单击添加段落文字此处添加内容单击添加段落文字单击添加段落文字1234567双击添加标题文字此处添加内容单击添加段落文字单击添加段落文字此处添加内容单击添加段落文字单击添加段落文字此处添加内容单击添加段落文字单击添加段落文字此处添加内容单击添加段落文字单击添加段落文字此处添加内容单击添加段落文字单击添加段落文字双

5、击添加标题文字单击此处添加标题单击添加内容文字单击此处添加标题单击添加图片标题文字单击此处添加标题单击此处添加段落文字内容单击此处添加段落文字内容单击此处添加段落文字内容单击此处添加段落文字内容单击此处添加段落文字内容单击此处添加段落文字内容单击此处添加段落文字内容单击此处添加段落文字内容文字内容文字内容文字内容单击此处添加标题标题一标题二标题三 标题四内容一内容二内容三内容四内容五内容六内容七标示符号单击此处添加标题单击添加标题文字单击添加段落文字单击添加段落文字单击添加段落文字单击添加段落文字。单击添加段落文字单击添加段落文字单击添加段落文字单击添加段落文字。单击此处添加标题此处添加标题单

6、击添加段落文字单击添加段落文字单击添加段落文字单击添加段落文字单击添加段落文字单击添加段落文字单击添加段落文字单击添加段落文字单击此处添加标题单击此处添加段落文字内容单击此处添加段落文字内容单击此处添加段落文字内容单击此处添加段落文字内容双击添加标题文字单击此处添加段落文字内容单击此处添加段落文字内容单击此处添加段落文字内容单击此处添加段落文字内容双击添加标题文字单击此处添加标题内容标题单击此处添加段落文字内容单击此处添加段落文字内容单击此处添加段落文字内容内容内容此处添加内容单击添加段落文字单击添加段落文字此处添加内容单击添加段落文字单击添加段落文字此处添加内容单击添加段落文字单击添加段落文

7、字The end谢谢 本次课程到此结束25软件生存周期及模型第二章26一、软件工程研究内容序号研究方面具体内容1软件开发模型如：瀑布模型、增量模型、迭代模型2软件开发方法如：面向过程方法、面向数据方法、面向对象方法3软件支持过程如：CASE工具Rose、北大青鸟系统、PowerDesigner4软件管理过程如：ISO9000、CMM、软件企业文化271、软件生存周期(Life cycle) 软件有一个孕育、诞生、成长、成熟、衰亡的生存过程。 软件生存周期通常包括可行性研究和项目开发计划、需求分析、概要设计、详细设计、编码、测试、维护等活动（GB8567中规定）。28定义分析蓝图、图表、库存、采

8、购单等设计实现产品292、软件生存周期模型概念模型是为了理解事物而对事物作出的一种抽象，它忽略了不必要的细节，是事物的一种抽象形式 。软件生存周期模型是描述软件开发过程中各种活动如何执行的模型。它确立了软件开发和演绎中各阶段的次序以及各阶段活动的准则，确立开发过程所必须遵守的规定和限制等。目前有瀑布模型、增量模型、螺旋模型、喷泉模型、变换模型和基于知识的模型等。2022/7/19303、软件工程的传统途径瀑布模型(Waterfall Model) 维 护开发定义DefinitionFeasibility StudyRequirements AnalysisProgram DesignCodin

9、g & Module TestingIntegration & System TestingDelivery & MaintenanceSystem Design31二、瀑布模型瀑布模型1970年由W.Royce提出瀑布模型是传统软件工程的基础。瀑布模型的基本思想是将软件生命周期划分为若干明确定义的阶段。每一阶段活动具有严格性，要实施评审工作，以便及早发现错误，改正错误 ；以文档形式驱动的，上一阶段的结果作为本阶段的输入 ；软件维护报告要求定义确认设计确认编码确认测试确认维护确认测试报告源程序清单设计说明书需求说明书321、软件定义时期基本任务：回答 要解决的问题是什么？该问题有行的通的解决办

10、法吗？若有解决问题的办法，则需要多少费用、资源、时间？结束标准：提出关于问题性质、工程目标和规模的问题定义书面报告；提出可行性研究报告；若问题值得去解决，制定项目开发计划。可行性研究和项目开发计划需求分析基本任务：回答“为了解决这个问题，目标系统必须做什么”，确定目标系统的功能。结束标准：给出软件需求说明书332、软件开发时期系统设计概要设计基本任务：回答 “概括地说，应如何解决这个问题”。把确定的各项功能需求转换成需要的体系结构。设计软件的结构，确定程序由哪些模块组成及模块间的关系，同时设计该项目的应用系统的总体数据结构和数据库结构。结束标准：给出概要设计文档。详细设计基本任务：回答 “应怎

11、样具体地实现这个系统”。为每个模块完成的功能进行具体描述，把功能描述转变为精确的、结构化的过程描述。结束标准：设计出程序的详细规格说明。342、软件开发时期系统实现编码基本任务：把每个模块的控制结构转换成计算机可接受的程序代码。写出的程序应是结构好，清晰易读，并且与设计一致。结束标准：以某种程序设计语言表示的源程序清单。测试基本任务：通过各种类型的测试使软件达到预定的要求。结束标准：软件合格，能交付用户使用。353、软件维护时期基本任务：通过各种必要的维护活动使系统持久地满足用户需要。364、技术审查和管理复审 技术审查是从技术角度进行的审查，是保证软件质量和降低软件成本的重要措施。在每一阶段

12、结束前进行，对于持续时间很长的开发阶段，在阶段中间还要根据需要进行多次正式的或非正式的技术审查。技术审查通常由技术专家组成的审查小组来承担审查工作。审查过程包括：准备和阅读被审文档、开审查会、返工、复查。 管理复审的主要任务是在软件生存周期的每个重要的里程碑，对工程项目的成本、实际花费的经费、投资回收的前景、项目的进度等经济因素从管理角度进行审查。从管理角度对软件开发工程进行复审，是对工程进行管理和控制的主要手段，对发现的问题可以及时采取措施加以解决，必要时甚至可以取消开发工程以避免更大的损失。37名词解释软件工作产品在CMM中，它是软件开发活动中的人工制品，如需求说明书、概要设计说明书、详细

13、设计说明书、源程序、测试报告、用户手册，也包括软件管理文档，如软件开发计划、软件质量保证计划、各种评审报告、里程碑报告、变更申请表、不符合项跟踪报告等。软件产品在CMM中软件产品是最终用户使用的软件。它是软件工作产品的一部分。基线它是软件工作产品。它是要经内部和外部评审过的，并且是下一阶段工作的基础，一根基线是一个里程碑或一个检查点。检查点它是由时间、计划、事件驱动的检查工作进度和质量的一个记号，一个检查点不一定是基线或里程碑。里程碑它是一个记号，只需经过内部评审。它是一个检查点，但不一定是基线。评审是对软件工作产品质量的一次开会或汇签活动。审计是复查评审活动程序的合法性，是否按程序与规范进行

14、。顾客客户用户客户是顾客的一部分，顾客包括潜在的客户。用户是软件产品的最终使用者，用户是客户的一部分。现有系统目标系统现有系统是用户当前正在使用的系统（可能是手工系统）；目标系统是将要实现的系统。Capability Maturity Model forsoftware385、瀑布模型特点是一个理想化过程。会掩饰项目中真正的风险，当你太晚发现它们时已无济于事。 过程逆转性很差，因为上游的错误会在下游进行发散性传播。所以逆转会造成很大损失。缺乏灵活性;特别是无法解决软件需求不明确或不准确的问题后期错误，修正代价高 。纯瀑布模型的缺点是在项目开始的时候，在设计工作完成前和代码写出来前，很难充分描述

15、需求。瀑布模型最主要的问题是缺乏灵活性。必须在项目开始前说明全部需求。但这恰恰是非常困难的。6、瀑布模型适用场合当有一个稳定的产品定义和很容易被理解的技术解决方案时，纯瀑布模型特别合适当你对一个定义得很好的版本进行维护或将一个产品移植到一个新的平台上，瀑布模型也特别合适。纯瀑布模型能够降低管理费用，因为你可以预先完成所有计划。对于那些容易理解但很复杂的项目，采用纯瀑布模型比较合适，因为可以用顺序方法处理问题。在质量需求高于成本需求和进度需求的时候，它尤为出色。当开发队伍的技术力量比较弱或者缺乏经验时，瀑布模型更为适合。39407、瀑布模型变种：V型模型该方法是对瀑布模型的修正，强调了验证活动4

16、18、瀑布模型变种：生鱼片模型把阶段重叠起来的瀑布模型起源于日本硬件开发模型（富士通施乐）软件概念需求分析架构设计详细设计编码和调试系统测试428、瀑布模型变种：生鱼片模型传统的瀑布模型强调阶段之间最小的重叠，而生鱼片模型强调大幅度的重叠，即在需求分析完成之前就可以进行架构设计和部分详细设计纯瀑布模型强调在任意两个阶段交接时，文档从一个团队交给另一个完全隔离的团队，但是如果一个团队完成各个阶段任务时，可以没有那么多文档。问题：缺点是什么？生鱼片模型因为阶段重叠，因而里程碑不明确，很难有效地进行过程跟踪和控制。439、瀑布模型变种：具有子项目的瀑布模型纯瀑布模型的一个问题是必须完成全部的架构设计

17、后才能进行详细设计，但是，整个系统中有些部分可能有些特殊性，可以有自己的步骤，即将这些部分划分为为子项目。问题：该模型有何问题？这种方法的主要风险是相关性无法预料。4410、瀑布模型变种：能够降低风险的瀑布模型纯瀑布模型要求在开始架构设计前，必须将用户的所有需求都搞清楚，但是实际中是很困难的。可降低风险的瀑布模型是在顶端，即需求分析和架构设计阶段引入螺旋以便降低风险。在该螺旋中，先开发一个用户界面原型，采用系统情节串联图版（system storyboarding）引导用户提出需求，记录用户与系统的交互操作方式，或者采用其它需求获取方法。45演化模型需求的采集与细化客户评价原型快速设计建造原型

18、加工原型产生样品停止开始先开发一个“原型”软件，完成部分主要功能，展示给用户并征求意见，然后逐步完善，最终获得满意的软件产品。46三、螺旋模型螺旋模型将瀑布模型与演化模型结合起来，并且加入两种模型均忽略了的风险分析。螺旋模型沿着螺线旋转，自内向外每旋转一圈便开发出更完善的一个新版本。 制定计划 确定软件目标，选定实施方案，弄清项目开发的限制条件；风险分析 分析所选方案，考虑如何识别和消除风险；实施工程 实施软件开发客户评估 评价开发，提出修正建议。47三、螺旋模型螺旋模型是一种风险驱动的模型。螺旋模型需要有相当丰富的风险评估经验和专门知识。2022/7/1948ReviewCommitment

19、PartitionRisk analy-sisPrototype 1Simulations, models, benchmarksRequirements plan, life-cycle planConcept of operationPrototype 2Risk analysisSoftware requirementsRequirements validationDevelop-ment planRisk analysisPrototype 3Software product designDesign validation and verificationIntegration and

20、 test planRisk analysisOperational prototypeDetailed designUnit testCodeIntegration and testAcceptance testImplementationPlan next phasesDevelop, verify next-level productDetermine objectives, alternatives, constrainsEvaluate alternatives, identify, resolve risksCumulative costProgress through steps

21、The spiral model49螺旋模型决定目标、方案和限制评价方案、识别风险、弱化风险开发、验证、下一级产品计划下一阶段集成测试50四、增量模型123491011125678需求分析设计编码测试第1块第1次集成第2次集成第3次集成第N次集成第4次集成第1块第1块第1块第1块第N块第4块第3块第2块第2块第2块第2块第3块第3块第4块51四、增量模型遵循递增方式进行软件开发。开发一部分，向用户展示一部分。增量模型是一种非整体开发的模型。适用条件：1）使用面向对象语言或第四代语言；2）需求可能发生变化，客户接受分阶段交付；3）分析设计人员对应用领域不熟悉，难以一步到位；4）项目风险高；52五

22、、原型模型-概念快速原型模型：先开发一个“原型”软件，完成主要功能，展示给用户并征求意见，然后逐步完善。探索型原型：用于需求分析阶段；实验型原型：用于设计阶段；演化型原型：软件开发全过程，及早向用户提交一个原型系统。原型运用方式：抛弃策略和附加策略。53五、原型开发过程-开发步骤原型开发步骤:快速分析：分析人员与用户配合，迅速确定系统的基本要求。要根据原型所要体现的特征，描述基本需求。关键是要注意分析描述内容的选取。构造原型：在软件工具支持下尽快实现一个可运行的系统。运行原型：是发现问题、消除误解、开发者与用户充分协调的一个步骤。评价原型：评价原型的特性，纠正误解与错误，增添新要求或提出要求变

23、动，提出全面的修改意见。修改：原型开发的循环。54五、原型模型的评价原型的优点：可及早为用户提供有用的产品。可及早发现问题，随时纠正错误。减少技术、应用风险，缩短开发时间，减少费用。促使用户主动参与开发活动，促进各类人员的协调，减少误解，适应需求的变化，能有效提高系统质量。原型存在的问题：缺乏丰富而强有力的软件工具和开发环境。缺乏有效的管理机制，还未建立起自己的开发标准。对设计人员水平和开发环境要求较高。在多次重复改变原型的过程中，程序员会感到厌烦。系统的易变性对测试有一定影响，难于做到彻底测试，更新文档较为困难。2022/7/1955五、原型模型-快速原型法快速原型法(Prototyping

24、)适用于用户驱动的系统（即需求模糊或随时间变化的系统）PrototypeFeedbackModification56快速原型模型需求分析需求说明设计说明源程序软件产品设计编码测试维护快速分析需求说明原型修改意见修改类型构造原型运行原型评价原型停止修改修改说明修改原型57六、喷泉模型主要用于采用面向对象技术的项目喷泉体现迭代和无间隙的特征软件的某些部分常常被重复工作多次，相关对象在每次迭代中随之加入渐进的软件成分在分析、设计、实现等各项活动之间无明显边界58六、喷泉模型体现了迭代和无间隙的特性。系统某个部分常常重复工作多次，相关对象在每次迭代中随之加入演进的软件成分。无间隙是指在各项开发活动，即

25、分析、设计和编码之间不存在明显的边界。喷泉模型是对象驱动的过程。 59需求阶段分析阶段设计阶段编程阶段集成与测试阶段维护与演进阶段60七、迭代模型（RUP模型）Rational Unified Process初始精化构建移交9个核心流程对初学者来说，使用比较困难61八、智能模型智能模型是基于知识的软件开发模型，它把瀑布模型和专家系统综合在一起。该模型在各个开发阶段都利用了相应的专家系统来帮助软件人员完成开发工作。为此，建立了各个阶段的知识库，将模型、相应领域知识和软件工程知识分别存入数据库。以软件工程知识为基础的生成规则构成的专家系统与包含应用领域知识规则的其他专家系统相结合，构成该应用领域的

26、开发系统。 62用户要求需求分析概要设计详细设计程序编码测试维护支持需求 分析的专家系统支持软件 设计的专家系统 支持测试的专家系统 支持维护的专家系统6364九、软件生存周期模型的剪裁在一个成熟的IT企业或软件组织内部，通常要根据各种软件开发模型的特点，结合本单位的开发经验和行业特点的具体实际，还需要定制适合本单位的“生存周期模型裁剪指南”，有针对性地对选定的软件开发模型中定义的生存周期，进行适当剪裁，使它完全适合于本单位的需求。所谓裁剪，就是对原模型中定义的内容进行增、改、删，去掉对本单位不适用的内容，同时进一步细化，从而构成了完全适合本单位的“软件生存周期模型裁剪指南”。该指南在软件组织

27、内部，专供高层经理和项目经理在软件策划中选取软件开发模型时使用。 65在软件开发过程中必须遵循的软件工程原则有：抽象与自顶向下、逐层细化信息隐蔽和数据封装模块化局部化确定性一致性和标准化完备性和可验证性 十、软件工程原则66软件工程的基本原理有：按软件生存期分阶段制定计划并认真实施；坚持进行阶段评审；坚持严格的产品控制；使用现代程序设计技术；明确责任，使得工作结果能够得到清楚的审查；用人少而精；不断改进开发过程。十一、软件工程的基本原理67案例分析整定软件采用了以原型模型为主的软件开发模型。故障分析是电力系统中非常基本的运算，算法比较成熟，软件用户对此模块的功能也较熟悉，需求变动相对较小，因而

28、本功能模块可以采用瀑布模型。但由于我们已有故障分析程序，只需对该程序的接口、部分功能算法进行修改和调整，所以采用原型模型较为合适。软件开发阶段中重点关注需求分析阶段，弄清楚已有程序与用户需求间的差距。图形建模在建模范围方面基本明确，但在具体内容方面仍有不确定性，原因是用户对此功能模块的想法还不够清晰，通常用“待基本的出来后再讨论”来回答一些细节问题。此外，我们有以前其他项目的图形建模软件基础，所以本模块采用了演化型原型模型，采用附加策略。先在以前图形建模的软件基础上去除一些不需要的内容和添加新的内容，向用户提交初步的原型系统，然后再根据用户的意见进行修改，在反复多次中才达成需求的彻底清晰，此时

29、本模块软件也可以基本开发完成。整定计算是专业性很强的内容，通常需要较多的整定人员工作经验，而整定经验的获得往往无法一次完成，因此开发方需要经常与用户交流沟通。此外，整定计算模块用户最关心的是软件的可用性，即计算过程是否方便、透明，计算结果是否合理。因此，整定计算也采用了原型模型，以某种原理的保护为例反复设计与修改整定的流程，直到满足用户的可用性和实用性为止，其他原理的保护整定则以此为模板进行开发。 68总结掌握：软件生存期各个阶段的基本任务；软件生存期模型。了解：软件生存期的各种模型及特点。69第三讲软件要求定义70学习内容可行性研究项目开发计划软件需求分析71项目来源合同：为别人做；立项：为

30、自己做；失败：无盈利赔钱声誉影响官司失败：尽赔钱公司倒闭东山再起难！学到的远比失去的多！ 72可行性研究（ Feasibility Study） 可行性研究的目的就是用最小的代价在尽可能短的时间内确定该软件项目是否能够开发，是否值得开发，最后给决策者提供做与不做的依据。 可行性研究实质上是要进行一次简化、压缩了的需求分析和设计过程，要在较高层次上以抽象的方式进行需求分析和设计过程。73可行性研究的任务 首先需要进行概要的分析研究，初步确定项目的规模和目标，确定项目的约束和限制。 然后进行简要的需求分析，抽象出该项目的逻辑结构，建立逻辑模型。 最后从逻辑模型出发，经过压缩的设计，探索出若干种可供

31、选择的主要解决办法，对每种解决方法都要从以下三方面研究它的可行性。技术可行性经济可行性社会可行性74技术可行性在现有资源条件下，项目能否实现，风险有多大（技术、资源是否成熟）。社会可行性是否存在侵权、软件操作方式是否适合用户所在组织、现有管理制度、人员素质是否可行？75经济可行性（成本效益分析） 成本效益分析首先是估算将要开发的系统的开发成本，然后与可能取得的效益进行比较和权衡。效益分有形效益和无形效益。有形效益可以用货币的时间价值、投资回收期和纯收入等指标进行度量；无形效益主要从性质上、心理上进行衡量，很难直接进行量的比较。货币的时间价值：通常用利率表示。 F=P(1+n i) 不计复利投资

32、回收期：就是使累计的经济效益等于最初的投资费用所需的时间。纯收入：就是在整个生存周期之内的累计经济效益（折合成现在值）与投资之差。76提示不是解决问题，而是确定是否可解值得解所以不要花过多精力，占总成本的 5 10 %例：实践性大作业 3 方面考虑：技术上- 23 学生, 7 周, 电脑, 开发经验 ，决心，风险（影响其它课程）. 社会上- 产品有没有人用 经济上 - 预算, 盈利, .77可行性研究的具体步骤1、确定项目规模和目标，明确限制和约束。我们认为用户要的 用户要的2、研究老系统 解决老系统问题老系统功能新增功能注：注意了解与其它系统的接口。 新系统效益 老系统效益 78可行性研究的

33、具体步骤3、导出高层逻辑模型(conceptual design)抽象实现改进老系统模型新模型新系统应该告诉用户“What”而不是“How”79系统流程图（事务图）高层逻辑模型80可行性研究的具体步骤 3、逻辑模型4、复查和重新定义 1、复查定义 注：此时合同未签，应考虑成本，不宜反复太多次。5、导出和评价多种解法进度表经济上合算技术上可行操作上可行技术上不可行用户不可能操作不合算81可行性研究的具体步骤6、推荐行动方针Yes or No?NoYesWhy?Which one is the best?Why? (cost / benefit)8、审查、存档7、编写可行性报告（开发计划） 任务分

34、解，确定负责人 大致进度规划 财务预算 风险分析及对策粗略82文档：可行性报告 参考GB856788中的可行性研究报告，进行适当裁剪。83项目开发计划 是对开发项目的费用、时间、进度、人员组织、硬件设备的配置、软件开发环境和运行环境的配置等进行说明和规划。 是项目管理人员对项目进行管理的依据，据此对项目的费用、进度和资源进行控制和管理。工具：Project85注意事项标书 ：我国对软件成本认识不足人月不能互换：需求的变更、人员的流动、环境的变化；困难：就是缺乏数据估计，导致估计不科学；估算项目复杂度（熟悉程度）、规模 86软件需求分析：“做什么？” 需求分析的过程是开发人员与用户共同协商，明确

35、系统的全部功能、性能以及运行规格，并且使用软件开发人员和用户都能理解的语言准确地表达出来，即完成需求规格说明的过程。87软件需求重要性例子 “喂，是Jack吗？我是人力资源部的Tom,我们在使用你编写的职员系统时遇到一个问题，一个职员想把她的名字改成Sparkle Starlight,而系统不允许，你能帮帮忙吗？”“她嫁给了一个姓Starlight的人吗？”Jack问道。“不，她没有结婚，而仅仅是要更改她的名字，”Tom回答，“就是这问题，好象我们只能在婚姻状况改变时才能更改姓名。”“当然这样，我从没想到谁会莫名其妙地更改姓名，我也不记得你曾告诉我系统需要处理这样的事情。”Jack说。 Tom

36、说：“我想你当然知道每个人只要愿意都可以随时合法更改其姓名。但不管怎样，你在本周五之前解决这问题，否则Sparkle不能支付她的帐单。”“这不是我的错！我现在正忙着做一个新的系统，还要做一些别的需求变更请求。很抱歉，只能下周才能修改。”88故事带给我们的启示 影响：作为客户，很恼火，因为软件系统不能进行一项基本的操作。哪怕开发者给其解决了，也不会感谢他。作为开发者，也很烦人，迫使你增加了当前的工作，又要你优先处理。原因：由于收集、编写、协商、修改需求过程的手续或方法失误带来的。这里是非正式信息的收集、未确定或不明确的功能、未发现或未经交流的假设、不完善的需求文档，以及突发的需求变更过程所造成的

37、。解决办法：重视需求分析，派经验丰富的人员做，最大程度的减少类似情况发生。89定值整定原则1：按与相邻接地距离保护配合整定；原则2：按相邻零序电流保护配合整定；1231与2配；1与3配；方案1：原则相邻线方案2：相邻线原则90需求分析的特点老问题：问题的复杂性交流障碍（讲究技巧和原则）不完备性和不一致性需求易变性（动态性）派经验丰富的人去干！系统分析员91软件需求的任务理解、分解、表达、评审whf:划分系统所有1.问题识别：双方确定问题的综合需求。功能需求：系统必须做什么？ 性能需求：做得怎样？例：response time , memory , back-up memory , 环境需求：运

38、行环境、软硬件配置等。用户界面需求可靠性、安全性、保密性、可移植性和可维护性等方面的需求。将来可能提出的要求共同理解！92软件需求的任务2.分析与综合:导出软件的逻辑模型。对获取的需求进行一致性的分析检查，在分析、综合中逐步细化软件功能，划分成各个子功能。也对数据域进行分解，分配到各个子功能上，并用图文结合的形式，建立起新系统的逻辑模型。93软件需求的任务3.编写文档：编写需求说明书 编写初步用户使用手册编写确认测试计划 修改完善项目开发计划94需求文档用户需求报告需求规格说明书对外的，验收依据对内的，设计依据是合同的产物是立项建议书的产物由用户需求报告可产生需求规格说明书当前系统，目标系统目

39、标系统（数据字典，算法分析）95软件需求的任务验证需求的一致性验证需求的完整性验证需求的现实性验证需求的有效性方法： 人工审查 开发原型系统探索型使用软件工具 完整性、一致性基线4.技术审查和管理复审96需求分析的方法结构化分析方法：由数据流和数据字典构成，适于数据处理领域问题。但该方法的一个难点是确定数据流之间的变换，而且数据字典的规模也是一个问题，对数据结构的强调很少。功能分解法：系统功能子功能功能接口。过程抽象观点，很难与软件设计明确分离。基点放在功能上，不稳定，难以适用需求的变化。97需求分析的方法信息建模方法：从数据角度来对现实世界建模。基本工具是E-R图，数据不封闭，每个实体和它的

40、属性的处理需求不是组合在同一实体中，没有继承性和消息传递机制来支持模型。是面向对象分析的基础。面向对象的分析：采用了实体、关系和属性等信息模型分析中的概念，同时采用了封闭、类结构和继承性等面向对象程序设计语言中的概念。98ER模型（Entity-Relationship Approach）实体：客观世界中存在且可相互区分的事物。用矩形框代表。联系：事物间是有联系的。(1:1、1:N、M:N) 用连接相关实体的菱形框表示。属性：实体或联系所具有的性质。 用椭圆形或圆角矩形表示。教师学生课程教学学号职称成绩学分1NNM99注意事项在需求分析时要注意用户对软件开发的了解程度。避免造成两种极端认识。

41、需求的变动或新增是一个极为普遍的问题，既然普遍，所以软件开发人员不仅应该在心理上接受这种变动，还应该在需求分析时积极的发掘需求。需求人员与用户广泛交流，从深度和广度挖掘可能的需求，并应形成规范的需求文档，经用户确认。如果为写文档而写文档，不进行及时更新，甚至准备在软件开发完成后再补文档，这是绝对错误的观点。 100可能错误没有足够用户从参与（类型、数量）开发方与用户沟通可能处于劣势不要锦上添花，画蛇添足不要写的过于简练，过于模糊；计划需求的时间少了，导致需求不完整另外，要注意：需求在签约前要与决策者沟通好；到竞争对手那儿找不足不要被过细的不成熟的细节影响记下不明确的需求，约定期限明确，否则易遗

42、漏101总结熟练掌握：软件需求分析的任务及分析的方法 掌握：可行性研究的任务。了解：其余作一般了解。102作业一人组：交实验三；二人组：交实验三、实验四三人组：交实验一/二、实验三、实验四四人组：交实验一/二、实验三、实验四、实验五103104结构化方法105学习内容结构化方法概述结构化分析数据流图数据字典加工逻辑的描述结构化设计106一.结构化方法概述 它包括结构化分析（Structured Analysis）、结构化设计（ Structured Design）和结构化程序设计（ Structured Programming）三部分组成。 结构化方法的基本指导思想是自顶向下，逐步求精，它的基

43、本原则是抽象与分解。107结构化方法特点成功率较高，发展较为成熟；简单、易掌握，适应于瀑布模型；特别适合于数据处理领域中的应用，对规模大的项目，特别复杂的应用不太适应。难于解决软件重用问题，难于适应需求的变化。108二、结构化分析策略：它根据软件内部数据传递、变换的关系，自顶向下逐层分解描绘出满足功能要求的软件模型。 X1231.11.21.33.13.23.32.12.2顶层：整个系统逐层添加细节109结构化分析步骤建立当前系统的物理模型（系统流程图，怎么做）抽象出当前系统的逻辑模型。（做什么）建立目标系统的逻辑模型。作进一步补充和优化。110描述工具数据流图 ：描速系统的分解。数据词典：定

44、义数据流图中的数据和加工。描述加工逻辑的结构化语言、判定表、判定树等工具：详细描述数据流图中不能被再分解的每一个基本加工的处理逻辑 。111数据流图 数据流图（Data flow Diagram，简称DFD）是表示系统逻辑模型的一种工具，以图形的方式描绘数据在系统中的流动和处理过程。由于只反映系统必须完成的逻辑功能，所以是一种功能模型。112数据流图基本图形符号数据源点和终点：系统的外部实体。一般只出现在顶层图中。为了避免在数据流图上出现数据流的线条交叉，同一个外部实体允许在一张图上出现多次。数据源/终点名称源/终点名称源/终点名称或113数据流图基本图形符号加工 ：对数据进行处理。加工名一般

45、用一个动词和一个作宾语的名词所组成。编号加工名或编号加工名114数据流图基本图形符号数据流： 数据及其流向，通常由一组数据项组成。有时数据流很难用简单而适当的词表达，这时可用概括性的语句来表达，一般用名词或名词短语表示。数据流名问询订货单顾客支票信息顾客顾客事务处理顾客事务处理顾客事务内容115数据流图基本图形符号数据存储：信息的静态存储。它也允许在一张数据流图上重复出现相同的数据存储，以避免数据流的交叉。数据名称或编号数据名称F2 库存记录F2 库存记录116数据流图的分层方法 描述一个复杂的系统，不可能一下子引进太多的细节。否则用一张数据流图画出所有的数据流和加工，则这张图将是极其庞大而复

46、杂，因而难以绘制，也难以理解。所以必须用分层的方法将一个流程图分解成几个流程图，来分别表示。117数据流图的分层方法一套分层的数据流图由顶图、0层图、中间层和底图的数据流图所组成。顶图说明了系统的边界，即系统的输入和输出的数据流，顶图只有一个加工，标识被开发的系统。画系统内部，一般将层号从0开始编号。0层图分解顶层图的系统为若干子系统。底图由一些不必再分解的加工组成，这些加工称为基本加工。在顶图和底图之间是中间层。称上层图为下层图的“父”图，下层图称为上层图的“子”图。118子图P1bd子图P2cabd父图（0层图）cde子图P3eP1P3P2acP1 .3P1 .2P1 .1P2 .1P2

47、.2P2 .3P3 .3P3 .2P3 .1Pabe源点1终点源点2顶图119绘制数据流图的几个问题合理地命名：数据流程图中对每一个元素都要命名，恰当地命名有助于数据流程图的理解与阅读。命名原则：为了避免引起错觉，为每个元素所取的名字要能反映该元素的整体性内容，而不只是它的部分内容。每个元素的名字都能有唯一地标识该元素。避免用空洞的名字，要具体的含义。如果发现难以为某个数据流或加工命名时，这往往是数据流图分解不当的征兆，可重新分解。120绘制数据流图的几个问题编号的设置子图的编号是父图相应的加工的编号。子图中加工编号由子图号、小数点与局部号组成。121绘制数据流图的几个问题父图与子图的平衡子图

48、是详细地描述父图中加工，因而子图的输入、输出数据流应该同父图中加工的输入、输出数据流相一致。订货单P提货单P3P1P2提货单数量客户122绘制数据流图的几个问题局部数据存储 局部数据存储不是父图中相应加工的外部接口，而只是本图中某些加工之间的数据接口。在子图中出现的数据存贮，可以不出现在父图中，画父图时只需画出处理逻辑之间的联系，不必画出各个处理逻辑内部的细节，有助于实现信息隐蔽。acP1 .3P1 .2P1 .1库存记录123绘制数据流图的几个问题加工的分解与分细的程度为提高数据流图的易理解性，注意合理分解。分得太细，则使得层次太多；分得太快，则达不到分层的目的。从管理的层次结构原理来看，一

49、个领导人管理他的下属一般不超过7人，故在分解一层时不宜超过7个加工。一个加工分解到基本加工为止。基本加工：能表达系统所有的逻辑功能和必要的数据输入与输出，这些功能与数据的描述能使用户清楚地理解，并且还能使以后的系统设计人员看到每一个加工，有一个明确的概念，并据此能设计程序模块实现这些加工。注意子加工的独立性和匀称性。124125126数据流图实例以某企业的销售管理系统为例，采用SA方法进行需求分析，建立功能模型。该企业销售管理的描述如下：（1）接受顾客的订单，检验订单。若库存有货，则进行供货处理，即修改库存，给仓库开备货单，并将订单留底；若库存量不足，则将缺货订单登入缺货记录。（2）根据缺货记

50、录进行缺货处理，将缺货通知单发给采购部门，以便采购。（3）根据采购部门发来的进货通知单处理进货，即修改库存，并从缺货记录中取出缺货订单进行供货处理。（4）根据留底的订单进行销售统计，打印统计表给经理。 127数据流图实例顶层图1280层图1291层图图1图21301层图图3图41311层图图5修改下面的经营处理系统顾客供应商订货单发货单订货单发货单顶层数据流程图经营处理系统经理统计表顾客P1销售P2采购供应商F1 配件库存P3会计付款收据应付款通知收款通知到货通知订货单订货单发货单发货单统计缺货通知第0层数据流程图经理统计表付款收据付款收据付款收据134数据流图的优缺点总体概念强，每一层都明确

51、强调“干什么”，“需要什么”，“给出什么”。可以反映出数据的流向和处理过程。由于自顶向下分析，容易及早发现系统各部分的逻辑错误，也容易修正。容易与计算机处理相对照。不直观，一般都要在作业流程分析的基础上加以概括、抽象、修正来得到。如果没有计算机系统帮助的话，人工绘制太麻烦，工作量较大。135与其它流程图的差别与系统流程图的区别系统流程图中不仅有数据流，还有物质流、资金流。数据流程图仅以数据流的形态来反映一个组织中整个管理业务的过程。与程序结构图的区别程序结构图反映模块之间的控制关系，以及模块之间的调用关系，而数据流图则不反映控制关系、调用关系、控制流，只画数据流。136与其它流程图的差别与程序

52、流程图的区别程序流程图中的处理框之间有严格的时间上的顺序，也就先执行哪个处理框，起始点以及终止点等。而数据流程图只反映数据的流向、加工和必要的数据存储，它不反映加工的先后的时间顺序。数据字典Data Dictionary，简称DD数据字典是用来定义DFD中各个成分的具体含义的，它以一种准确的、无二义性的说明方式为系统的分析、设计及维护提供了有关元素的一致的定义和详细的描述。它和数据流图共同构成了系统的逻辑模型。 数据字典的内容数据流、数据存贮、数据项、基本加工。数据字典的符号符 号含义举例及说明被定义为与X=a+b表示X由a和b组成。 | 或X=a|b表示X由a或b组成。重复X=a表示X由0个

53、或多个a组成。m n或 nm重复X=2a5或X a 52 表示X中最少出现2次a，最多出现5次a，5、2为重复次数的上下限。()可选X=(a)表示a可在X中出现，也可不出现。“”基本数据元素X=“a”,表示X是取值为字符a的数据元素。 连接符X=1 9，表示X可取1到9中任意一个值。139数据流条目 在一个数据流图上，数据按数据流为单位传输。主要内容有：数据流名称、别名及简述。数据流的来源：可能是一个外部实体、处理逻辑、数据存贮。数据流的去处。（同上）数据流的组成：一个数据流可能包括若干个数据结构，若只有一个数据结构，就不需要专门定义。数据流的流通量：单位时间内的传输次数。140数据流条目举例

54、数据流的名称：销售科发货单别名：无简述：工厂对顾客办理的发货单数据流来源：“销售科”外部实体数据流去向：“核对发货单”处理逻辑数据流组成：发货单标识+顾客+配件流通量：50份/天141数据存储条目 数据存储是数据结构停留或保存的场所。主要内容：数据存储的名称、别名及其简述。流入、流出的数据流：流入的数据流指出其来源，流出的数据流指出其去向。数据存储的组成：指它所包含的数据项或数据结构。组织方式、查询要求等。数据存储条目举例数据存储名称：销售历史别名：无简述：公司从月初到目前为止所有配件的销售量。流入的数据流：“顾客的发货单”，来源是“产生发货单”处理逻辑。流出的数据流：“销售量”，去向是“产生

55、销售报表”处理逻辑。数据存贮的组成：配件编号+日期+销售量。组织方式：以配件编号为关键字建立索引。查询要求：能立即查询。143数据项条目 数据项也称数据元素，是“不可再分”的数据单位，是数据的最小组成单位。主要内容有：数据项名称、别名及简述：给数据项取名时，按“顾名思义”的原则，反映该数据项的含义，易于他人理解、记忆。数据项的类型数据项的长度：指数据项所包含的字符或数字的位数。取值的范围和取值的含义144数据项条目举例数据项名称：货物编号别名：G_No，Goods_No简述：本公司的所有货物的编号。类型：字符串长度：10取值/含义：第一位：进口/国产24位：类别57位：规格810：品名编号加工

56、条目用来说明DFD中基本加工的处理逻辑的。加工名；编号；简述：对处理逻辑的简明描述，其目的是使人了解这个处理逻辑是做什么用的。激发条件；优先级；输入、输出；加工逻辑：描述该加工“做什么”，即实现加工的策略，而不是实现加工的细节，描述如何把输入数据流变换为输出数据流的加工规则。常用的描述方法：结构化语言、判定表及判定树。146加工条目举例加工名：确定能否供货编号：1.2简述：激发条件：接受到合格订单时优先级：普通输入：合格订单输出：可供货订单、缺货订单加工逻辑：根据库存记录IF 订单项目的数量该项目库存量的临界值THEN 可供货处理ELSE 此订单缺货，登记，待进货后再处理ENDIF147加工逻

57、辑的描述结构化语言 结构化语言是在自然语言基础上加了一些限定，使用有限的词汇和语句来描述加工逻辑，其结构分内外二层。外层用来描述控制结构，采用顺序、选择、重复三种基本结构。内层一般采用祈使语句的自然语言短语。使用数据字典中的名词和有限的自定义词，动词含义要具体。还可使用一些简单的算术运算和逻辑运算符号。148结构化语言示例IF 顾客订额1000IF 顾客信誉好订单设“优先”标志ELSEIF 顾客是老顾客订单设“优先”标志ELSE订单设“正常”标志ENDIFENDIFELSE订单设“正常”标志ENDIF加工逻辑的描述判定表条件定义条件取值的组合动作定义在各种取值的组合下应执行的动作判定表1234

58、5678条件顾客订额1000顾客信誉好顾客是老顾客处理订单设“优先”标志订单设“正常”标志150判定表判定表能把什么条件下系统应做什么动作准确地表示出来，同时能发现需求的不完整性，如某些条件组合下缺少应采取的动作。也能发现冗余的动作，可将条件合并。但判定表不能描述循环的处理特性，循环处理还需结构化语言。YNYYNN两条规则合并YN-151加工逻辑的描述判定树 好-优先处理1000 顾客信誉 老顾客-优先处理顾客订额 不好顾客是 新顾客-正常处理 C(p2)then E(p1) E(p2)因为C(p1+p2) C(p1)+ C(p2)，所以 E(p1+p2) E(p1)+ E(p2).定义有效的

59、模块系统的能力：模块可分解性模块可组装性模块可理解性模块连续性模块保护性2、抽象分解：对于一个复杂的系统，为了将复杂性降低到可以掌握的程度，可以把大问题分解成若干小问题，然后分别解决。 抽象：分解可以分层进行，即先考虑问题最本质的属性，暂把细节略去，以后再逐层添加细节，直至涉及到最详细的内容，这种用最本质的属性表示一个子系统的方法就是“抽象”。3、逐步求精求精：是细化过程，对高抽象级功能陈述说明具体实现细节。 求精可以帮助程序员对复杂问题的思考，是一种自顶向下的设计策略。4、信息隐藏 应该这样设计和确定模块，使得一个模块内部包含的信息（过程和数据等实现细节）对于不需要这些信息的模块来说，不能访

60、问。5、 软件独立性准则 软件独立性的含义是指开发具有功能专一，模块之间无过多相互作用的模块。又称为模块独立性准则。 这种类型的模块可以并行开发，开发容易，能减少错误的影响，使模块容易组合、修改及测试。 软件独立性的度量标准是两个定性指标： 耦合性 用于描述模块之间联系的紧密程度。内聚性 用于描述模块内部联系的紧密程度。耦合分类：数据耦合：模块间有且仅有数据交换控制耦合：模块间有控制信息交换公共耦合：多个模块通过一个公共环境相互作用。复合耦合：两个模块既往公共环境送变量又从公共变量里面取数据内容耦合：一个模块访问另一个模块内的全部数据。内聚性(cohesion)偶然型逻辑型瞬时型通讯型顺序型弱