软件工程实践课件

软件工程原理计算机系统工程概念系统分析和定义硬件软件系统（总体）设计硬件工程软件工程计算机软件计算机软件定义（GB）：

a.与计算机系统的操作有关的计算机程序、规程、规则，以及可能有的文件、文档及数据。

b.与计算机系统的操作有关的程序、规程、规则及任何与之有关的文档。什么是软件？软件是计算机系统中与硬件相互依存的另一部分，它是包括程序，数据及其相关文档的完整集合。程序是按事先设计的功能和性能要求执行的指令序列数据是使程序能正常操纵信息的数据结构文档是与程序开发，维护和使用有关的图文材料软件的特点软件是一种逻辑实体，而不是具体的物理实体。因而具有抽象性软件的生产与硬件不同，在它的开发过程中没有明显的制造过程在软件的运行和使用期间，没有硬件那样的机械磨损，老化问题软件的开发和运行常受到计算机系统的限制，对计算机系统有着不同程度的依赖性软件的开发至今尚未完全摆脱手工艺的开发方式软件本身是复杂的实际问题的复杂性程序逻辑结构的复杂性软件成本相当昂贵相当多的软件工作涉及到社会因素软件的分类—按功能进行划分系统软件操作系统数据库管理系统设备驱动程序通信处理程序等支撑软件文本编辑程序文件格式化程序磁盘向磁带向数据传输的程序程序库系统支持需求分析、设计、实现、测试和管理的软件

应用软件商业数据处理软件工程与科学计算软件计算机辅助设计／制造软件系统仿真软件智能产品嵌入软件医疗、制药软件事务管理、办公自动化软件计算机辅助教学软件软件的分类—按规模进行划分类别参加人员数研制期限源程序行数

微型 1 1～4周0.5k小型1 1～6月1k～2k中型2～5 1～2年5k～50k大型5～20 2～3年50k～100k甚大型100～10004～5年1M(=1000k)极大型2000～50005～10年1M～10M

软件的分类按工作方式划分：实时处理软件分时软件交互式软件批处理软件按服务对象的范围划分：项目软件产品软件按使用的频度进行划分：一次使用频繁使用按软件失效的影响进行划分：高可靠性软件一般可靠性软件软件发展阶段程序设计阶段—50至60年代程序系统阶段—60至70年代软件工程阶段—70年代以后软件危机...计算机硬件性能／价格比和质量稳步提高软件成本逐年上升，质量没有可靠的保证软件已成为限制计算机系统发展的关健因素将软件开发和维护过程中遇到的一系列严重问题统称为“软件危机”在６０年代后期开始认真研究解决软件危机的方法，逐步形成了新兴的计算机软件工程学...软件危机什么是软件危机？软件危机是指在计算机软件的开发和维护中所遇到的一系列严重问题。几乎所有软件都不同程度地存在这些问题概括地说软件危机包含两方面问题：如何开发软件，怎样满足对软件的日益增长的需求如何维护数量不断膨胀的已有软件软件危机主要表现１．对软件开发成本和进度的估计很不准确２．用户对“已完成的”软件不满意的现象经常发生３．软件产品的质量靠不住４．软件不可维护５．软件没有适当的文档资料６．软件成本占计算机系统总成本的比例逐年上升７．软件开发生产率提高的速度远远跟不上计算机应用迅速普及深入的趋势产生软件危机的原因一方面与软件本身的特点有关在软件运行前，软件开发过程的进展难衡量，质量难评价，因此管理和控制软件开发过程相当困难；在软件运行中，软件维护意味着改正或修改原来的设计，较难维护；软件的显著特点是规模庞大，复杂度超线性增长。要保证高质量大型软件的开发，极端复杂困难，不仅涉及技术问题（如分析方法、设计方法、版本控制），更重要的是必须有严格而科学的管理。另一方面与软件开发和维护方法不正确有关，这是主要原因。特别是忽视软件需求分析的重要性忽视软件需求分析的重要性对用户要求没有完整准确的认识就匆忙着手编写程序软件开发与编程等同忽略文档软件定义不明轻视维护对软件开发的错误认识（1）已经有了关于建造软件的标准和规程使用了吗？开发者知道吗？适用吗？完整吗？已经有了很好的软件开发工具还需要计算机辅助软件工程（CASE）工具对软件开发的错误认识（2）如果计划落后，可以增加人员赶回来给一个已经延迟的软件项目增加人手只会使其更加延迟原有人员需要抽实践训练新手有了目标的一般描述就可以开始写程序不完善的系统定义是项目失败的主要原因对软件开发的错误认识（3）项目需求不断变化，但软件很灵活，变化能够很容易地得到满足软件需求的变化确实是经常的，但其产生的影响随着引入的时间不同而不同写出程序并使其正常运行，工作就结束了越早开始写程序，就要花越长时间才能够完成对软件开发的错误认识（4）在程序真正开始运行前，无法评估其质量正式的技术评审质量过滤器成功项目唯一应该提交的就是运行程序软件=程序+文档+数据文档是成功开发的基础文档为维护提供指导解决办法...全面解决软件危机需要一系列综合措施：在软件研制的各个阶段采用好的工具；对软件的实现提供有效的构件块；为保证软件质量提供自动设计技术；以及为协调、控制、管理提供基本理论和技术——软件工程。...解决办法软件工程这一要素将驾驭前面的工具、构件决和技术软件工程把管理、控制、评审等方法与分析、设计、编码、测试、维护等技术结合起来没有坚实的软件开发方法学，即使最先进的工具和技术也不能使软件危机有所减轻软件工程—工程化方法用于解决任何产品开发的一种工程化方法是：要求在定义、开发和维护阶段的每一步中都采用经过验证的方法要求一系列的复查，以便在产品开发中保证质量规定在每一步中要产生的特定的文档鼓励能够加速开发的各种工具和方法的使用与研制提供从原始产品概念到最后产品制造的一个可追溯的途径软件工程是使计算机软件走向工程科学的途径软件工程—软件工程定义软件工程是为了经济地获得可靠的和能在实际机器上高效运行的软件而建立和使用的好的工程原则。（FritzBauer1969)软件工程是应用于计算机软件的定义、开发和维护的一整套方法、工具、文档、实践标准和工序。（GB）软件工程：（1）将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程，即将工程化应用于软件中。（2）（1）中所述方法的研究。（IEEE93）软件工程是模仿在硬件研制中行之有效的一套计划、管理、技术、方法，基于软件的生存期概念而建立起来的。软件工程的定义Boehm：运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必需的相关文件资料FritzBauer：建立并使用完善的工程化原则，以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法软件工程三要素：方法、工具和过程软件工程方法为软件开发提供了“如何做”的技术软件工具为软件工程方法提供了自动的或半自动的软件支撑环境软件工程—视图1...质量焦点过程方法工具...软件工程—视图1质量焦点：任何工程方法必须以有组织的质量保证为基础。质量的理念刺激不断过程改进，导致出现更加成熟的软件工程方法。它是软件工程的根基。过程：软件工程的基础是过程。软件工程过程是将技术层结合在一起的凝聚力，使得软件能够合理地和及时地开发出来。方法：软件工程方法层提供了建造软件在技术上需要“怎么做”。工具：在工具层对过程和方法提供了自动和半自动的支持。软件工程—生存期概念计算机软件生存期中有三个阶段：定义阶段、开发阶段、维护阶段。定义阶段：为软件项目做出计划、预算资金和进度，分析并规定详细的需求——做什么开发阶段：用经过验证的各种设计、编码和测试方法把软件需求转变为一个可执行的程序——怎么做维护阶段：纠正所遇到的各种问题，修正软件使之适合于不同的工作环境，增强功能要求——改变每一个阶段都有一系列的工程步骤，每一步都以能加以复查并可移交才作为结束软件工程知识结构2001年5月ISO/IECJTC1（ISO和IEC的第一联合技术委员会）发布了《SWEBOK指南V0.95(试用版)》（GuidetotheSoftwareEngineeringBodyofKnowledge,简称SWEBOK）SWEBOK把软件工程学科的主体知识分为10个知识领域。软件工程知识结构

软件需求软件设计软件构造软件测试软件维护软件配置管理软件工程管理软件工程过程软件工程工具和方法软件质量软件工程的基本原理B.W.Boehm（1983）1)用分阶段的生命周期计划严格管理;2)坚持进行阶段评审;3)实行严格的产品控制;4)采用现代程序设计技术;5)结果应能清楚地审查;6)开发小组的人员应该少而精;7)承认不断改进软件工程实践的必要性。计划管理缺乏科学而周密的计划是软件开发普遍现象不成功软件项目一半以上由于计划不周造成应把软件生存期划分为若干阶段，制定科学周密、切实可行的计划，并严格按计划进行管理，这是软件项目取得成功的先决条件计划所做的和按计划去做计划一般包括：项目开发计划、软件配置管理计划、软件质量保证计划、软件测试计划等评审在每个阶段都进行严格的评审，以便尽早发现在软件开发过程中所犯的错误，是一条必须遵循的重要原则质量保证工作不能等到程序编制完成后才进行：1.程序中的大部分错误是在编码之前造成的2.错误的检测与改正时间越晚，所付出的代价也就越高。3.错误还会被“放大”配置管理...软件研制各阶段产生的文档、报告、程序清单和数据等，构成软件配置全部软件配置是一个软件产品的真正代表，必须使其保持精确和一致为了保持软件配置的一致性，必须实行严格的产品控制，对变更进行严格的控制和管理...配置管理配置管理是标识和确定系统中配置项的过程，在系统整个生存周期内控制这些项的投放和变更，记录并报告配置的状态和变更要求，验证配置项的完整性和正确性。它包括对软件配置的标识、控制、审计、记录等一系列的活动在软件研制过程中，由业已经过正式审核与同意，可用作下一步开发的基础，并且只有通过正式的修改管理步骤方能加以修改的规格说明或产品形成了配置管理的基线软件开发方法和工具软件工程鼓励研制和采用各种先进的软件开发方法和工具各种软件开发方法的出现和采用大大改善了软件的开发效率和维护效率软件工程辅助工具、计算机辅助软件工程（ＣＡＳＥ）环境工具和环境的使用进一步提高了软件的开发效率、维护效率和软件质量文档...软件研制是脑力劳动，具有不可见性为了实现对软件研制过程的管理，在软件研制的每个阶段，都应按规定的格式编写出完整准确的文档文档是软件中不可缺少的组成部分...文档的作用1)作为阶段工作成果和结束标志；2)向管理人员提供软件开发过程中的进展和情况，把软件开发过程中的一些“不可见的”事物转换成“可见的”文字资料；3)记录开发过程中的技术信息，便于协调以后的软件开发、使用和修改；4)提供对软件的有关运行、维护和培训的信息，便于各类人员之间相互了解彼此的工作；5)向潜在用户报告软件的功能和性能，使他们能判定该软件能否服务于自己的需要。开发小组软件开发小组的组成人员的素质应该好，而人数则不宜过多开发小组人员的素质和数量是影响软件产品质量和开发效率的重要因素随着开发人员数目的增加，因为交流情况讨论问题造成的通信开销也急剧增加组成少而精的开发小组是一条基本原理不断改进仅有前面六条基本原理并不能保证软件开发和维护的过程能赶上时代前进的步伐、跟上技术的不断进步Boehm提出应把承认不断改进软件工程实践的必要性作为软件工程的第七条基本原理不仅要积极地采纳新的软件技术，而且要注意不断总结经验软件工程基本原则-1抽象采用分层次抽象，自顶向下、逐层细化的办法控制软件开发过程的复杂性。信息隐蔽将模块设计成“黑箱”，实现的细节隐藏在模块内部，不让模块的使用者直接访问。这就是信息封装，使用与实现分离的原则。模块化如C语言程序中的函数过程，C++语言程序中的类。模块化有助于信息隐蔽和抽象，有助于表示复杂的系统。局部化要求在一个物理模块内集中逻辑上相互关联的计算机资源，保证模块之间具有松散的耦合，模块内部具有较强的内聚。这有助于控制解的复杂性。软件工程基本原则-2确定性

软件开发过程中所有概念的表达应是确定的、无歧义性的、规范的。一致性整个软件系统的各个模块应使用一致的概念、符号和术语。程序内部接口应保持一致。软件和硬件、操作系统的接口应保持一致。系统规格说明与系统行为应保持一致。用于形式化规格说明的公理系统应保持一致。完备性软件系统不丢失任何重要成分，可以完全实现系统所要求功能的程度。为了保证系统的完备性，在软件开发和运行过程中需要严格的技术评审。可验证性开发大型的软件系统需要对系统自顶向下、逐层分解。系统分解应遵循系统易于检查、测试、评审的原则，以确保系统的正确性。软件研制过程模型软件生存周期从产品的设想到不再使用，包含软件开发、运行、维护全过程软件开发包含一系列阶段、活动和里程碑，如需求分析、设计、编码、测试软件研制过程模型给出了将这些基本阶段进行有机组合的结构性模型生存周期支持过程2配置管理1文档编制8问题解决3质量保证4验证5确认6联合评审7审核生存周期基本过程2供应1获取3开发4运作5维护生存周期组织过程1管理3改进2基础设施4培训瀑布模型软件测试详细设计软件实现系统需求软件需求概要设计1970年由W.Royce提出瀑布模型描述从60年代开始，为解决软件危机逐渐发展起软件工程。瀑布模型则是传统软件工程的基础。瀑布模型的基本思想是将软件生命周期划分为若干明确定义的阶段。需求捕获是软件生命周期的第一个阶段；上一个阶段生成规定的软件中间产品（软件文档，伪码等），传到下一阶段作进一步加工，最后得到目标产品。瀑布模型是一个理想化过程，瀑布模型特点(1)阶段间具有顺序性和依赖性(2)推迟实现的观点(3)质量保证的观点瀑布模型的使用风险和适用情况使用风险需求未被充分理解系统太大而不能一次实现事先打算采用的技术迅速发生变化需求迅速发生变化有限的资源无法利用某一中间产品适用情况所有的系统功能一次交付时必须同时淘汰全部老系统时瀑布模型V模型系统需求软件需求概要设计详细设计单元测试组装测试编码确认测试系统联试详细设计概要设计软件需求系统需求型号任务编译后的单元测试后的单元组装后的软件测试后的软件交付软件验证验证验证验证验证验证验证与确认验证与确认

J.McDermid于1994年在“软件工程师参考手册”中提出增量模型软件1：运行维护详细设计编码测试系统需求软件需求概要设计软件2：运行维护详细设计编码测试增量模型描述预先计划的产品改进从一套给定的需求开始，通过一系列的造型实施开发，第一个造型纳入一部分需求，下一个造型纳入更多的需求，以此类推，直到系统完成在每个造型中实行必要的过程、活动和任务增量模型特点在开发每个造型时，开发过程中的活动和任务顺序地或部分平行重叠地使用当相继的造型在部分并发地被开发时，开发过程中的活动和任务可以在造型间平行地被采用增量模型的使用风险和适用情况风险需求未被很好地理解突然提出一些功能事先打算采用的技术迅速发生变化需求迅速发身变化长时期内有限的资源投入适用情况需要早期获得功能中间产品可以提供使用系统被自然地划分成增量工作人员和（或）资金可以逐步增加渐进模型开发1运行维护1开发3运行维护3开发2运行维护2渐进模型描述和特点通过造型开发系统需求不能被完全理解，且不能在初始时就确定需求一部分被预先定义，然后在每个相继的造型中逐步完善每个造型被开发时，开发过程中的活动和任务顺序地或部分重叠并行地被采用对所有造型，开发过程中的活动和任务通常按同意顺序被重复使用采用渐进模型的一些原因1）需要某些用户经验来改进和完善需求；2）某些部分的实现可能取决于未来技术的可用性；3）某些新的用户需求被预料到，但目前还不清楚；4）某些需求可能比遇到的那些还难以满足，并且确定不允许因这些需求推迟可用的交付。渐进模型的使用风险和适用情况风险突然提出一些功能长时期内有限的资源投入适用情况需要早期获得功能中间产品可以提供使用系统被自然地划分成增量工作人员和（或）资金可以逐步增加需要用户反馈来理解全部需求便于对技术变化的监督原型开发模型需求分析快速设计用户评价原型建立原型生产产品修改原型原型分类抛弃式原型开发样品式原型开发渐增式原型开发螺旋模型B.Boehm于1988年提出螺旋模型描述瀑布模型和渐进模型相结合，增加风险分析用来指导大型软件项目的开发将开发划分为制定计划、风险分析、实施工程、客户评估四类活动沿螺旋线每转一圈，表示开发出一个更完善的新的软件版本喷泉模型喷泉模型描述1990年B.H.Sollers和J.M.Edwards提出主要用于采用面向对象技术的项目喷泉体现迭代和无间隙的特征软件的某些部分常常被重复工作多次，相关对象在每次迭代中随之加入渐进的软件成分在分析、设计、实现等各项活动之间无明显边界RUP模型软件过程模型的选择1）模型应符合软件本身的性质（规模、复杂性）2）模型应满足软件应用系统整体开发进度要求3）模型应有可能控制并消除软件开发风险4）模型应有可用的计算机辅助工具（如快速原型工具）的支持5）模型应与用户和软件开发人员的知识和技能相匹配6）模型应有利于软件开发的管理与控制航天型号软件研制过程模型航天型号研制经历方案阶段、模样、初样、试样（正样）、定型型号软件研制通常也经历模样、初样、试样（正样）模样、初样、正样软件是针对同一个软件开展的循环研制，侧重面不同。结合原型、渐进模型，以原型-基本型-更新型来形成航天型号软件研制过程模型原型、基本型、更新型基本思想是：首先在需求尚不明确的情况下，对已知的需求和尚不能确定的需求进行分析整理，在此基础上简单地设计、编制软件，产生一个软件的原型，并对原型进行多方面的研究、分析和讨论，以便确定所采取的技术实现方案是否可行，需求还要做哪些补充、修改和完善，从而获得一个内容较完整、接口较明确的软件需求和一个切实可行的软件实现技术途径；其次在软件原型研制的基础上，进行一次完整、严格的软件研制工作，获得一个高质量的软件基本型；最后在软件基本型的基础上，针对更新的软件需求，采用软件更新与更改的的方法，对软件进行更新，获得软件的更新型模样、初样、试样-正样模样初样正样原型基本型更新型更新版本1更新版本2……原型软件原型研制的目的是明确接口、确定需求、试验系统方案需求分析：根据系统的任务分解和技术要求，对已知需求、应有需求、未确认需求等进行综合分析，形成粗略的原型软件需求规格说明。设计：对软件的总体结构和接口进行设计，形成软件设计说明。编码调试：编制程序并调试通过。分析总结：运行软件，并与系统总体、相应接口单位进行详细的分析讨论，对软件需求进行补充、修改和完善，并确定技术途径的可行性。对高质量要求的软件研制，软件原型研制所获的程序应废弃，不带入以后的研制阶段。基本型基本型研制的任务是根据基本确定的软件需求，全面开展软件的研制工作，形成一个基本满足系统对软件各项要求的基本型软件，以直接应用于型号或作为下一步更新的基础。基本型软件的研制，必须采用瀑布式开发过程，严格执行。研制阶段包括：系统需求、软件需求分析、概要设计、详细设计、软件实现、软件组装测试、软件确认测试、系统联试软件开发方法软件开发方法是软件开发过程所遵循的方法和步骤，其目的在于有效地得到一些工作产品，既程序和文档，并且满足质量要求程序设计方法是软件开发方法的组成部分此外还有分析方法和设计方法评价软件开发方法的四大特征技术特征：支持各种技术概念的方法特色，如层次性、抽象性、并行性、安全性、正确性等使用特征：用于具体开发时的特色，如易理解性、易移植性、易复用性、工具的支持、任务范围、使用的广度、活动过渡的可行性、产品的易修改性、对正确性的支持等管理特征：增强对软件开发活动管理的能力方面的特色，如易管理性、支持或阻碍团队工作的程度、中间阶段的确定、工作产品、配置管理、阶段结束准则、费用估计等经济特征：给软件组织产生的在质量和生产力方面的可见效益，如分析活动的局部效益、全生存周期效益、获得该开发方法的代价、使用它的代价、管理的代价等选用软件开发方法的考虑因素1对该开发方法是否已具有经验，或者已有受过培训的人员2开发项目的进度、人员组成情况3为开发项目提供的资源如何4计划、组织、管理的可行性5开发项目的领域知识准备情况航天的考虑结构化方法较全面、最成熟、最基础、使用最广泛、有成功经验结构化方法适合航天软件研制工作结构化方法是基础性方法结构化方法包括就形成了配套的软件结构化分析方法、结构化设计方法和结构化编程方法，其核心和基础是结构化程序设计理论为什么要讲这些所谓的“方法”？“我只要满足需求就可以了，我自己开发使用什么方法你管不着。”“这些方法根本没有什么用处，我们那里高手很多，我们不屑于使用这些方法。”“结构化”起源：对GOTO的认识1968年Dijkstra在ACM通讯中发表了“GOTO语句是有害的”文章，认为：GOTO语句是有害的，是造成程序混乱的祸根，程序的质量与GOTO语句的数量成反比，应该在所有高级程序设计语言中取消GOTO语句激起了强烈的反响和长期广泛的论战论据1966年，Boehm和Jacopini证明了程序设计语言只要上旬、选择和重复三种形式的控制结构就足以表达出各种其他形式的结构1970年McKeeman称其XPL编译程序仅用一个GOTO语句1972年C.Strachey设计的操作系统只在五处使用了标号和GOTO语句争辩否定GOTO取消GOTO后，程序易理解、易排错、易维护没有其它好的结构代替GOTO的话，容易滥用GOTO无GOTO的程序容易进行正确性证明肯定GOTO在块和进程的非正常出口处往往需要使用GOTO会使程序执行效率较高在合成程序目标时，GOTO语句往往是有用的，如返回语句用GOTO结论1974年Knuth发表了总结性文章：“带有GOTO的结构化程序设计”令人信服地总结和证实了以下三点：滥用GOTO语句确实有害，应尽量避免完全避免使用GOTO语句也并非是个明智的方法，有些地方使用GOTO语句，会使程序流程更清楚、效率更高争论的焦点不应该放在是否取消GOTO语句，而应该放在用什么样的程序结构上最后一点使关键，肯定以提高程序清晰性为目标的结构化方法“方法”的核心是模型所谓的“方法”通常围绕一系列的模型展开，给出这些模型的建立，校验和转换方法。COMPUTERMODELREALREAL仿自：CantwellSmith“Computers,ModelsandtheEmbeddingWorld”方法与模型计算机设计模型REAL实际分析模型分析编码设计分析模型和设计模型分析模型：对当前所处的环境，或者现实情况建立的模型，用于分析和评估。设计模型：对未来要建造的系统或者环境建立的模型，用于系统实施，也用于交流和评价。建立模型有助于精确有效地表达和沟通。结构化方法结构化程序设计：一种良好定义的软件开发技术，它采用自顶向下设计和实现方法，并严格地采用结构化程序的控制构造结构化方法的原则清晰第一效率第二设计先于编码自顶向下逐步细化1清晰第一效率第二著名的“清晰第一，效率第二”已成为当今主导的程序设计风格“先求清楚后求快”“保持程序简单以求快”“写清楚——不要为‘效率’牺牲清晰”2设计先于编码“开始写程序越早，完成程序需要的时间就越长。”“设计先于编码”已成为所有程序设计必须遵守的一条原则。设计一定要利用各种设计工具来进行。3逐步细化的设计方法…逐步细化方法是结构化程序设计的心脏。1）中心思想a.程序设计是一个由粗到细的过程;b.程序设计不仅包括对控制结构的设计，也包括对数据结构的设计，两者都要一步步地细化。3逐步细化的设计方法2）指导原则a.先分解主要问题，次要的问题可暂时搁置；b.坚持渐进的原则，每一步的变化不要太大；c.过程的细化与数据结构的细化宜并行、交叉地进行；d.选用适合于问题的设计工具；e.最后一步应详细到所得结果可以直接翻译为源程序。3）优点a.便于控制开发的复杂性;b.便于验证程序的正确性。结构化方法采用的原则抽象逐步求精信息隐藏模块化模块独立模块化原则模块是由边界元素限定的相邻的程序元素(例如，数据说明，可执行的语句)的序列，而且有一个总体标识符来代表它。模块是构成程序的基本构件。模块化就是把程序划分成独立命名且可独立访问的模块，每个模块完成一个子功能，把这些模块集成起来构成一个整体，可以完成指定的功能满足用户的需求。模块化原则主要思想是：将整个系统进行分解成为若干功能独立的，能分别设计、编程和测试的模块程序员能单独地负责一个或几个模块的开发开发一个模块不需要知道系统其它模块的内部结构和编程细节模块之间的接口尽可能简明，模块应尽可能彼此隔离模块化和软件成本Meyer模块化五条标准…(1)模块可分解性如果一种设计方法提供了把问题分解为子问题的系统化机制，它就能降低整个问题的复杂性，从而可以实现一种有效的模块化解决方案。(2)模块可组装性如果一种设计方法能把现有的(可重用的)设计构件组装成新系统，它就能提供一种并非一切都从头开始做的模块化解决方案。Meyer模块化五条标准…(3)模块可理解性如果可以把一个模块作为一种独立单元(无需参考其他模块)来理解，那么，这样的模块是易于构造和易于修改的。(4)模块连续性如果对系统需求的微小修改只导致对个别模块，而不是对整个系统的修改，则修改所引起的副作用将最小。Meyer模块化五条标准…(5)模块保护性如果在一个模块内出现异常情况时，它的影响局限在该模块内部，则由错误引起的副作用将最小。模块化应达到的要求具有可修改性：对整个系统的一次修改只涉及少数几个模块，这种局部性的修改不仅能满足系统修改的要求，而且不会影响系统已经具有的良好质量具有易读性：每个模块的含义和职责被明确，模块之间的接口关系清楚，从而降低复杂性，使得阅读和理解比较方便具有易验证性：只有每个模块能实现正确，才可能使整个系统的正确性有必要的前提抽象人类在认识复杂现象的过程中使用的最强有力的思维工具是抽象。人们在实践中认识到，在现实世界中一定事物、状态或过程之间总存在着某些相似的方面(共性)。把这些相似的方面集中和概括起来，暂时忽略它们之间的差异，这就是抽象。抽象就是抽出事物的本质特性而暂时不考虑细节。逐步求精逐步求精是人类解决复杂问题时采用的基本技术，也是许多软件工程技术的基础。可以把逐步求精定义为：“为了能集中精力解决主要问题而尽量推迟对问题细节的考虑。”求精实际上是细化过程。抽象与求精抽象与求精是一对互补的概念抽象使得设计者能够说明过程和数据，同时却忽略低层细节。可以把抽象看作是一种通过忽略多余的细节同时强调有关的细节，而实现逐步求精的方法。求精则帮助设计者在设计过程中揭示出低层细节。这两个概念都有助于设计者在设计演化过程中创造出完整的设计模型。信息隐藏应用模块化原理时，自然会产生的一个问题：“为了得到最好的一组模块，应该怎样分解软件”Parnas提出的信息隐藏是模块化程序设计的基本方法信息隐藏：为了实现部件的可见性控制，在分层构造软件模块时，要求这些部件只在模块内部可见，在模块外部不可见模块独立“模块独立”概念是模块化、抽象、逐步求精和信息隐藏等概念的直接结果，也是完成有效的模块设计的基本标准。模块的独立程度可以由两个定性标准来度量，这两个标准分别称为内聚和耦合。耦合衡量不同模块彼此间互相依赖(连接)的紧密程度；内聚衡量一个模块内部各个元素彼此结合的紧密程度。耦合耦合是对一个软件结构内不同模块之间互连程度的度量。耦合强弱取决于模块间接口的复杂程度，进入或访问一个模块的点，以及通过接口的数据。应该追求尽可能松散耦合的系统。研究、测试或维护任何一个模块可以不需要对系统的其他模块有很多了解。发生在一处的错误传播到整个系统的可能性就很小。内聚内聚标志一个模块内各个元素彼此结合的紧密程度，它是信息隐蔽和局部化概念的自然扩展。简单地说，理想内聚的模块只做一件事情。设计时应该力求做到高内聚，通常中等程度的内聚也是可以采用的，而且效果和高内聚相差不多；但是，低内聚很坏，不要使用。内聚和耦合内聚和耦合是密切相关的，模块内的高内聚往往意味着模块间的松耦合。内聚和耦合都是进行模块化设计的有力工具，但是实践表明内聚更重要，应该把更多注意力集中到提高模块的内聚程度上。事实上，没有必要精确确定内聚的级别。重要的是设计时力争做到高内聚，并且能够辨认出低内聚的模块，有能力通过修改设计提高模块的内聚程度降低模块间的耦合程度，从而获得较高的模块独立性。启发规则以下的启发规则有助于模块化：改进软件结构提高模块独立性模块规模应该适中深度、宽度、扇出和扇入都应适当模块的作用域应该在控制域之内力争降低模块接口的复杂程度设计单入口单出口的模块模块功能应该可以预测结构化方法图示数据字典DFDSTDERD加工规约数据对象描述控制规约接口设计体系结构设计数据设计过程设计结构化分析方法结构化分析(SA)方法是结构化程序设计理论在软件需求分析阶段的运用。它是七十年代中期倡导的基于功能分解的分析方法，常用于基于瀑布模型的软件研制过程的需求分析阶段，其目的是帮助弄清用户对软件的需求。按照DeMarco的定义，“结构化分析就是使用数据流图（ＤＦＤ）、数据字典（ＤＤ）、结构化英语、决策表和决策树等工具，来建立一种新的、称为结构化规格说明的目标文档。”结构化分析五个步骤1)通过对用户的调查，以软件的需求为线索，获得当前系统的具体模型；2)去掉具体模型中非本质因素，抽象出当前系统的逻辑模型；3)根据计算机的特点分析当前系统与目标系统的差别，建立目标系统的逻辑模型；4)完善目标系统并补充细节，写出目标系统的软件需求规格说明；5)评审直到确认完全符合用户对软件的需求。八条指导原则1)请用户共同参与开发；2)编写用户资料，考虑他们的专门技术水平和阅读与使用资料的目的；3)使用画图工具做媒介，减少与用户交流时发生问题的可能性；4)进行系统设计之前建立一个系统的逻辑模型；5)自顶向下进行分析设计；6)自顶向下的方法进行测试；7)验收之前，就让用户看到系统的某些主要输出，使用户能够尽早地看到结果，及时地提出意见；8)对系统的评价不仅是指开发和运行费用的评价，而是对整个生存过程中的费用和收益的评价。结构化分析方法四大特点一是用画图的方法二是自顶向下地分解三是强调逻辑而不是物理四是没有重复性结构化分析的工具1)数据流图(DFD)；2)控制流图(CFD)；3)数据字典(DD)；4)控制逻辑表达方法,包括状态转换图(STD)等；5)处理逻辑表达方法，包括结构化语言、判断树和判断表；6)数据存储结构规范化；7)数据立即存取图(DIAD)。四句指导工作的准则分层分片，均衡分解；父子平衡，推迟细节。分层就是逐步细化；分片就是用一组数据流图来代替一大张包罗万象的总图。均衡分解是指自顶向下画分层数据流图时，各个子系统的分解程度应大致均匀。父子平衡是指数据流图的父图与子图在输入数据和输出数据上应该分别保持一致。推迟细节是指为了优先考虑重要问题，允许将一些细节推迟到下层数据流图来处理。结构化设计方法70年代提出的面向数据流、重点确定软件结构的设计方法“结构化设计就是采用最佳的可能方法设计系统的各个组成部分以及各成分之间的内部联系的技术。也就是说，结构化设计是这样一个过程，它决定用哪些方法把哪些部分联系起来，才能解决好某个具体有清楚定义的问题。”基本思想是将软件设计成由相对独立、单一功能的模块组成的结构。评价模块结构质量的两个具体标准——内聚度和耦合度耦合度耦合度：耦合度是各模块之间相互联系的一种度量，它是对模块独立性的直接衡量，耦合度越弱就意味着模块的独立性越高，则模块间相互影响就越小。耦合度的强弱可以由弱至强分为非直接耦合、数据耦合、特征耦合、控制耦合、外部耦合、公共耦合和内容耦合七个等级。内聚度内聚度是指一个模块内部各成分（语句或语句段）之间的联系程度，内聚度高，则模块的相对独立性势必会提高。内聚度由低到高可划分为偶然内聚、逻辑内聚、时间内聚、过程内聚、通讯内聚、顺序内聚和功能内聚七个等级。结构化设计方法设计步骤1)建立初始结构图;2)改进初始结构图。建立初始结构图开始细化/修改软件需求规格说明中的数据流图是变换型吗？变换分析事物分析将映射得来的初始结构图改进为最终结构图对最终结构图进行评审结束是否从数据流图过渡到结构图传入传入部分变换中心传出部分（a）变换型结构传出变换接受事务分析动作1动作2动作3接受部分事务中心（b）事务型结构DFD主模块输入模块主加工模块输出模块(a)事务控制模块接受模块动作发送模块动作1模块动作1模块动作1模块(b)SC改进初始结构图…

1）减少块间联系，降低耦合度：可从方式、作用、数量等方面着手，其中最常用的是减少模块间传递的参数个数；2）消除管道性模块，提高内聚度：管道性模块的块内联系很弱，只是像管道一样将一些参数从主模块传送到它的几个下层模块，对这样的模块，应予以消除；3）适当考虑系统将来可能发生的变化；改进初始结构图4）注意模块的大小：限制模块大小是降低复杂性的手段之一；5）适当调整调用和被调用的次数，即深度、宽度、扇出和扇入都要适当。一个模块调用或被调用过多，往往是设计不好的迹象；6）整体考虑问题：即尽可能研究整张结构图，而不是只分别考虑一张结构图的各个部分。三条指导规则1）对模块分割、合并和变动模块调用关系的指导规则2）保持高扇入/低扇出的规则3）把作用域保持在控制域之内的规则对模块分割、合并和变动模块调用关系的指导规则分割或合并结构图中的模块，应以提高模块独立性为首要的标准：力求提高内聚，降低耦合，简化接口，少用全局性和控制型信息要适当考虑快的大小对模块位置应否变更，视处理是否方便来定，不必拘泥于数据流图保持高扇入/低扇出的规则扇入数指调用该模块的模块个数扇出数指该模块调用的模块个数扇入高则上级模块多，能增加利用率扇出低则下级模块少，能减少复杂度扇出数以３－４为宜，最好不超过5-7软件结构通常具有“瓮”形或“清真寺”形的形状把作用域保持在控制域之内的规则一个模块的控制域，等于模块本身加上其下级模块。一个模块的作用域，是受这个模块中的判定所影响的模块。规则的含义是：a.作用域不要超过控制域的范围；b.软件系统的判定，其位置离受它控制的模块越近越好。结构化编程方法用一组标准的准则和工具从事程序设计，称为结构化程序设计；这些准则和工具包括一组基本控制结构，自顶向下扩展原则，模块化和逐步求精结构化编程方法派生于结构化程序设计理论，它要求使用顺序、选择、循环等基本控制结构，并遵循增加程序产量、提高程序可读性、容易测试和验证的原则来编写程序。结构化编程应遵循的原则…1)使用程序设计语言中的顺序、选择、循环等有限的控制结构表示程序的控制逻辑；2)选用的控制结构只准许有一个入口和一个出口；3)程序语句组成容易识别的块，每块只有一个入口和一个出口；4)复杂结构应该用嵌套的基本控制结构来实现；结构化编程应遵循的原则5)语言中所没有的控制结构，应该采用前后一致的方法来模拟；6)严格控制GOTO语句，仅在下列情况才可使用：a.用一个非结构化的程序设计语言去实现一个结构化的构造；b.若不使用GOTO语句会使功能模糊；c.在某种可以改善而不是损害程序可读性的情况下。结构化编程方法的主要优点1)易于理解、使用和维护。程序员采用结构化编程方法，降低了程序的复杂性，因此容易编写程序。程序员能够进行逐步求精、程序证明和测试，以确保程序的正确性，程序容易阅读并被人理解，便于用户使用和维护。2)提高编程工作的效率，降低了软件开发成本。由于结构化编程方法能够把错误控制到最低限度，因此能够减少调试和查错时间。结构化程序是由一些为数不多的基本结构模块组成，这些模块甚至可以由机器自动生成，从而极大地减轻了编程工作量。结构化方法的缺点著名的“两个鸿沟”“数据和过程的鸿沟”“分析和设计的鸿沟”专注于过程的分析模型，其抗击变动的能力和可复用性就相对较差。软件开发的原则（1）规范严格的原则遵循严格化原则，可以达到开发出正确、成功的软件产品的目的软件开发过程是创造性的工作过程，但严格化不会抑制创造性严格的分析设计可以增强对创造性成果的信心严格化对可靠性、维护性、可移植性、可理解性等产生影响过程详细记录可供精确地掌握和控制开发过程软件开发的原则（2）分隔化的原则解决复杂问题时从不同的方面把问题分隔开，然后单独集中精力解决每一个方面的问题分隔化原则是要将相互关系不太紧密的方面分割开，对相互联系仅考虑其影响分隔的途径：以时间次序、以质量指标、以软件规模、以不同的视图、以开发人员的技能软件开发的原则（3）模块化的原则先对复杂问题进行分析，找出基本要素，尽量使之独立，然后各个击破简单的单元易于加工、维修，可以标准化、通用化复杂问题的分解，基于自顶向下的思路已有模块的组合，基于自底向上的思路软件开发的原则（4）抽象化的原则重要、带有普遍意义特征的方面或内容被抽象出来，次要的、缺乏普遍意义的方面或内容被忽略抽象是分隔化原则的一种特殊应用软件开发的原则（5）预见变动的原则软件由于其错误、新需求、新环境而产生变化要求开发时就要考虑到软件变动的要求PARNAS的原则开发系列产品渐进开发，从子集出发，信息隐藏，保持接口不变采用为变化而设计的技术软件开发的原则（6）通用化的原则尽量找出对类似问题或相关问题的具有一定普遍意义的解决方法，并在相应产品开发中应用，使软件产品具有一定的通用性对普遍性、通用性问题的解决方法具有质量、经济方面的价值对通用和专用，需要在经济和效率方面进行权衡通用性原则是设计通用的软件产品的一个最基本原则软件开发的原则（7）逐步完善的原则由于难以确定用户的具体需求，只能从不完善逐步走向完善必须注意：记录每一个有意义的渐进文档必须尽早反映变动，变动得到控制MICROSOFT在采用逐步完善原则方面取得了成功软件开发的原则（8）有关软件质量的原则用户至上的原则以用户的利益为前提处处为用户使用方便着想千方百计帮助用户使用好软件注意与用户的交流质量可靠的原则在质量、成本之间进行权衡软件开发的原则（9）有关软件文档的原则文档标准化原则用户手册简明原则用词规范尽可能使用用户的专业术语或行话通俗易懂描述的句子不要太长软件开发的原则（10）有关设计编码的原则根据文档设计（需求记录在文档）注意概念的完整整个软件要适于变动、易于维护程序编制简明清晰注意技术与工具更新软件开发的原则（11）有关软件测试的原则测试的独立性原则克服心理障碍独立公正专业优势成功的测试是发现问题的测试要分析错误产生的原因，举一反三需求分析概念软件需求的定义客户定义的“需求”对开发者是一个较高层次的产品概念。开发者所说的“需求”对用户来说像是详细说明。软件需求包含多个层次，不同层次的需求从不同角度与不同程度反映着细节问题。IEEE软件工程术语（1997）的需求定义：（1）用户解决问题或达到目标所需的条件或能力。（2）系统或系统部件要满足合同、标准、规范或其它正式强制性文件所需具有的条件或能力。（3）反映上面（1）或（2）所描述的条件或能力的文档说明。上述定义包括从用户（外部）、从开发者（内部）角度来阐述需求。需求的层次业务需求（businessrequirement）：反映组织机构或客户对系统、产品高层次的目标要求。用户需求（userrequirement）：描述用户使用产品必须要完成的任务。功能需求（functionalrequirement）：定义开发人员必须实现的软件功能。需求规格说明中还包括非功能需求。软件需求各组成部分之间关系业务需求用户需求功能需求系统需求质量属性其它非功能需求约束条件项目视图与范围文件使用实例文档软件需求规格说明需求管理的困难性不成熟的需求分析无足够用户参与用户需求的不断增加摸棱两可的需求不必要的特征（镀金）过于精简的规格说明忽略了用户分类不准确的计划高质量需求过程的获益开发后期和整个维护阶段的重做的工作大大减少Boehm发现可以节省成本68倍有研究认为可以节省成本200倍强调产品开发中的通力合作，面向市场，让用户积极参与，可以建立忠实的客户关系，避免在无用功能上白耗精力，弥补用户期望和开发者实际开发间的期望鸿沟采用系统方法将需求分配到各子系统可以简化集成有效的变更控制和影响分析能降低变更的负面影响清晰、无二义的需求文档有利于测试需求说明的特征完整性正确性可行性必要性划分优先级无二义性可验证性需求规格说明的特点完整性先用TBD标明缺项在开发前必须解决所有TBD一致性可修改性每项需求只在SRS中出现一次可追踪性结构、粒度方便设计、实现、测试的追踪谁是客户定制软件：合同甲方（提出方）通用软件：高层管理者和（或）市场部嵌入式软件：软件所属计算机系统客户的权利1要求分析人员使用符合客户语言习惯的表达2要求分析人员了解客户的业务及目标3要求分析人员编写软件需求规格说明4要求得到需求工作结果的解释说明5要求开发人员尊重你的意见6要求开发人员对需求及产品实施提供建议7描述产品易使用的特性8调整需求，允许重用已有的软件组件9要求对变更的代价提供真实可信的评估10获得满足客户功能和质量要求的系统客户的义务1给分析人员讲解你的业务2抽出时间清楚地说明并完善需求3准确而详细地说明需求4及时地作出决定5尊重开发人员的需求可行性及成本评估6划分需求优先级别7评审需求文档和原型8需求出现变更要马上联系9应遵守开发机构处理需求变更的过程10尊重开发人员采用的需求工程过程对签定需求协议的认识签约是客户同意需求的标志行为客户不应当忽略签约的严肃性开发方不应当因此拒绝变更签约应当建立在一个需求协议的基线上应当理解为：“我同意这份文档表达了目前我们对项目软件需求的了解。进一步的变更可在此基础上通过项目定义的变更过程来进行。我知道变更可能会使我们要重新协商成本、资源和项目时间工期任务等。”需求开发过程需求开发过程需求获取需求分析编写需求规格说明需求验证知识培训需求管理项目管理需求获取的内容在同用户的交流过程中收集各种用户的信息认真理解用户的各项要求澄清模糊排除不合理明确约束分析人员的两个信条第一：只有在彻底了解和掌握了用户的全部意图之后，才有可能建立起成功的软件系统。第二：一切从用户的角度着想，在条件允许的情况下，应尽可能地保证用户从所构造的软件系统中获得最大的利益。容易产生的问题交流障碍误解各方缺乏共同的语言“完整性”问题需求永远会变化用户本身的意见不一致错误的要求认识上混淆目标和需求需求获取的过程确定需求开发过程编写项目目标和范围文档将用户群分类并归纳各自特点选择各类用户的产品代表建立起典型用户的核心队伍让用户代表确定使用实例召开应用程序开发联系会议分析用户工作流程确定质量属性和其它非功能属性通过检查当前系统的问题报告来进一步完善需求跨项目重用需求工作流程用户调查具体模型逻辑抽象当前系统逻辑模型当前系统计算机化评审修改正式模型完善细节目标系统目标系统初始模型经认可的问题需求系统模型用户建立模型的步骤分析现有系统和过程，建立物理模型抽取特征，建立旧系统的逻辑模型根据新的要求，补充和建立新的逻辑模型需求分析的任务需求分析的内容提炼、分析和仔细审查已收集到的需求确保所有利益相关者都明白其含义并找出其中的错误、遗漏或其它不足的地方是从用户最初的非形式化需求到满足用户要求的软件产品的映射过程是对用户意图不断进行提示和判断的过程需求分析的步骤绘制系统关联图创建用户接口（界面）原型分析需求可行性确定需求的优先级别为需求建立模型创建数据字典使用质量功能调配（QFD）明确哪些是客户最关心的特征编制需求规格说明的过程采用软件需求规格说明（SRS）模版指明需求的来源为每项需求注上标号记录业务规范（操作原则）创建需求跟踪矩阵需求规格说明的作用为用户、分析人员和设计人员之间的交流提供方便支持目标软件系统的确认控制软件开发进程软件需求规格说明文档条目1范围2引用文档3工程需求3.1外部接口需求3.2功能需求3.3内部接口3.4数据元素要求3.5适应性要求3.6容量和时间要求3.7安全要求3.8保密要求3.9设计约束3.10软件质量因素3.11人的工程需求3.12需求的可跟踪性4合格性需求4.1合格性方法4.2特殊的合格性需求5交付准备软件需求必须包括的属性1）标识：每项软件需求都必须有标识，使以后的各阶段容易跟踪。2）需要：基础软件需求必须用上述标识标明。基础软件需求是非协商性的；其它不那么重要的需求是可协商的。3）优先级：对于递增式交付，每一项需求必须包括优先级程度，以便决定研制进度。4）稳定性：某些需求在软件生存期内是稳定的；另一些可能是更依赖来自各设计阶段的反馈，或可能在软件生存期内要有所修改，这种非稳定性需求应当被指出。5）源：每一项软件需求都必须有一个能回溯到系统需求的索引。6）清晰性：如果需求有一个并且只有一个解释它就是清晰的。7）验证性：每一软件需求都必须是能被验证的。这意味着必须能做到：检查需求已经体现在设计中；证明该软件将实现需求；测试该软件确实能实现需求。IEEE需求规格说明的编写8原则1从实际重分离功能，描述“做什么”不描述“怎么做”2要求有一个面向处理的软件系统规格说明语言，以描述软件系统的动态行为3必须对以该软件为元素的系统进行说明，以描述清楚之间的关系4必须对软件系统的运行环境进行说明，以保持接口描述的一致性5必须是认识的模型而不是实际的模型6必须是可操作的7必须容忍不完备性和可修改性8必须局部化和松散耦合，使得变化时只修改一个片段SRS编写风格（Kovitz1999)保持语句和段落的简短采取主动语态的表达方式编写具有正确的语法、拼写和标点的完整句子使用的术语和词汇表中所定义的应该一致需求陈述应该采用一致的样式，如“主体+动作+可观察的结果”避免使用模糊的、主观的术语以避免不确定性避免使用比较性的词汇需求表达需求说明语句保持语句和段落的简短采用主动语态的表达方式编写具有正确的语法和标点的完整句子使用的术语应该和词汇表中定义的一致需求陈述应该具有一致的式样，例如“系统必须……”，或者“用户必须……”，并紧跟一个行为动作和可观察的结果，例如“仓库管理子系统必须现实一张在所请求的仓库中有存货的药品名单。”需求表达为了减少不确定性，避免采用模糊的、主观的术语，例如，用户友好、容易、简单、迅速、有效、支持、许多、最新技术、优越的、可接受的和健壮的。避免使用比较性的词汇，例如：提高，最大化，最小化和最佳化。定量地说明所需要提高的程度或者说清一些参数可接受的最大值和最小值。需求表达“产品必须在固定的时间间隔内提供状态消息，并且每次时间间隔不得小于60秒”后台任务管理器应该在用户界面的指定区域显示状态消息在后台任务进程启动之后，消息必须每隔60（+_10）秒更新一次，并且保持连续的可见性。如果正在正常处理后台任务进程，那么后台任务管理器必须显示后台任务进程已完成的百分比当完成后台任务时，后台任务管理器必须显示一个“已完成”的消息。如果后台任务中止执行，那么后台任务管理器必须显示一个出错信息。需求表达“产品必须在显示和隐藏非打印字符之间进行瞬间切换”“用户在编辑文档时，通过激活特定的触发机制，可以在显示和隐藏所有HTML标记之间进行切换。”需求表达“分析程序应该能生成HTML标记出错的报告，这样就可以使HTML的初学者使用它来迅速排错”在HTML分析程序完全分析完一个文件后，该分析程序必须生成一个出错报告，这个报告中包含了在分析文件中所发生错误的HTML所在的行号以及文本内容，还包含了对每个错误的描述。如果分析过程中未发生任何错误，就不必生成任何错误报告需求验证审查需求文档以需求为依据编写测试用例编写用户手册确定判别产品合格的准则需求验证的内容一致性：任何需求不与其它需求矛盾可行性：现有技术条件下可以实现完整性：包括用户需要的每一个功能和性能有效性：正确有效，确实能够解决用户面对的问题知识培训培训需求分析人员培训软件需求的用户代表和管理人员让开发人员了解应用领域的基本概念编写项目术语汇编分析员的职责１）作为管理员、用户和顾客的顾问；２）从各种来源收集数据，并综合问题的解答；３）分析新的系统，并评价现有的系统；４）准备文档和管理报告；５）理解硬件和软件的界面；６）为了产生软件需求规格说明，必要时要进行一些研究工作；７）为编写软件需求规格说明主持座谈会；８）不断吸收先进技术。分析员的素质１）能够合乎逻辑地、象征性地、抽象地、创造性地思考问题；２）能作为小组中的一个成员很好地开展工作；３）熟悉计算机硬件和软件的能力；４）自觉遵守时间，能按规定的进度完成任务；５）在系统的分析和设计中能发挥其他人的作用；６）能保持教师和学生的双重身份，愿意培养其他人，而他本人亦能通过夜校、自学、培训班等不断提高；７）能够倾听别人的意见，但又能根据客观事实来作决策，而不是依赖别人的意见；８）熟悉商业和政策管理部门的组织、原则。分析员应该显示的性格特征1）善于领会一些抽象的概念，重新整理使之成为各种逻辑成分，并根据各种逻辑成分综合出问题的解决办法。2）善于从各种相应冲突或混淆的原始资料中汲取恰当的依据。3）能够理解用户——需求者的环境。4）具备把系统的硬件部分和（或）软件部分应用于用户——需求者环境的能力。5）具备良好的用书面或口头形式进行讨论及交换意见的能力。6）具有“既能看到树木，又能看到森林”的能力。需求管理确定需求变更控制过程建立变更控制委员会（CCB）进行需求变更影响分析跟踪所有受需求变更影响的工作产品建立需求基准版本和需求控制版本文档维护需求变更历史记录跟踪每项需求的状态衡量需求稳定性使用需求管理工具与需求分析相关的项目管理选择一种合适的软件开发模型基于需求的项目计划发生需求变更时协商项目约定文档化和管理与需求相关的风险跟踪需求工程耗费的工作量需求分析方法工具描述工具数据流图(DataFlowDiagram，简称DFD)控制流图(ControlFlowDiagram，简称CFD)状态转换图（StateTransitiondiagram，简称STD）数据字典(DataDictionary，简称DD)处理说明分析模型的结构实体—关系图状态—迁移图数据流图数据对象描述加工规格说明数据字典控制规格说明数据和控制模型的关系过程模型PSPECDFD控制模型CSPECCFD控制输入数据输出控制输出数据输入数据条件过程启动数据流图:DFD（DataFlowDiagram）数据流图是用来描述系统逻辑模型的一种图形工具数据流图从数据传递和加工的角度，以图形的方式刻画数据流从输入到输出的移动变换过程数据流图图符2.1打印数据流DataFlow加工处理Process外部实体ExternalEntity数据存储DataStore数据流图图符说明数据流：箭头表示数据流方向。一般在旁边标注数据流名。加工处理：对数据进行加工、处理和变换，从而实现某个功能或操作外部实体：表示要加工处理的数据是从外部得到或从外部提供，同时也是数据结果的接收者，可以是人、组织、其它系统数据存储：表示处理过程中存放各种数据的文件建立DFD的步骤由外向里：先画系统的输入输出，然后画系统的内部，再画处理的内部。由顶向下：顶层、中间层、底层数据流图逐层分解：从外向里数据流图的层次结构为了表达数据处理过程的数据加工情况，需要采用层次结构的数据流图。按照系统的层次结构进行逐步分解，并以分层的数据流图反映这种结构关系，能清楚地表达和容易理解整个系统数据流图的层次顶层DFD用一个加工处理表示软件含所有相关外部实体含外部实体与软件中间的数据流不含数据存储唯一描述软件的作用范围，对总体功能、输入、输出进行抽象描述，反映软件和系统、环境的关系ABC软件abcd顶层数据流图软件系统外部实体外部实体……外部实体外部实体……输入数据流输入数据流输出数据流输出数据流中间和底层DFD2.1aaa2.2bbb2.3cccddd数据分层的数据流图F0A0B0F11A0B0F12F13F14F15p1C1D1M1N1F21M1F22N1F23K2F24W2F25p1Y2X2第n

层第n+1

层第n+2

层数据流图的层次在多层数据流图中，顶层流图仅包含一个加工，它代表被开发系统。它的输入流是该系统的输入数据，输出流是系统所输出数据底层流图是指其加工不需再做分解的数据流图，它处在最底层中间层流图则表示对其上层父图的细化。它的每一加工可能继续细化，形成子图。数据流图中的其它图形元素ABC------有A则B或者C，或者两者都有*ABC+ABC------有A则B与C，或者两者同时有------有A则B或C，但不会同时有B与C------当A或B有一个存在就有CABC*ABC------只有当A与B都存在，则有CDFD规则和注意事项数据存储不出现在顶层图中，外部实体通常不出现在顶层图外数据存储之间不应该有数据流仔细、恰当地为处理命名：处理+对象仔细、恰当地为数据流命名：反映整体含义对处理建立唯一、层次性编号每个处理通常要求既有输入又有输出一个DFD的处理个数为7±2（魔数7±2）不要试图让DFD反映处理的顺序检查数据流图的正确性a.数据守恒某个处理用以产生输出的数据没有输入给这个处理，即出现遗漏另一种是一个处理的某些输入并没有在处理中使用以产生输出b.数据存储（文件）的使用数据存储（文件）应被数据流图中的处理读和写，而不是仅读不写、或仅写不读c.父图和子图的平衡父子关系和平衡规则父图表示子图间的接口，即数据流的方向和数量子图代表父图中某个处理的细节子图个数不大于父图中的处理个数所有子图的输入、输出数据流和父图中相应处理的输入、输出数据流必须一致父图和子图的平衡发票1.3开领书单领书单(a)父图1.3.1学生领书单1.3.21.3.3教材(b)子图遵守加工编号规则顶层加工不编号第二层的加工编号为1,2,3,…,n号第三层编号为1.1,1.2,1.3…n.1,n.2…等号依此类推人工销售教材系统流程图举例学生开购书证明购书证明开购书发票

发票收书费

领书单发书学生学生教材购销系统购书单领书单缺书单进书通知进书通知保管员1销售购书单领书单学生缺书单进书通知2采购保管员第1

层第2

层

教材存量表F1

缺书登记表F2外部实体外部实体

教材销售子系统无效书单购书单1.3登记并开领书单1.2开发票1.1审查有效性1.4登记缺书1.5补售教材采购学生学生进书通知有效书单发票领书单暂缺书单1销售购书单领书单缺书单进书通知2采购进书通知缺书登记表教材存量表学生保管员第2

层补售书单第3层

教材存量表F1

缺书登记表F2F1书号单价数量

各班用书表F3

售书登记表F4外部项1销售购书单领书单缺书单进书通知2采购进书通知缺书登记表教材存量表学生保管员采购子系统

第2层第3

层缺书单2.3修改教材库存和待购量销售进书通知进书通知2.1按书号汇总缺书2.2按出版社统计缺书保管员

教材存量表F1

待购教材表F5

教材一览表F6

缺书登记表F2控制板传感器家庭安全软件电话线警报控制板显示警报类型传感器状态用户命令和数据显示数据电话号码信号与用户交互1配置系统2启/停系统3显示消息状态5处理口令4监控系统6配置信息用户命令和数据配置请求配置数据启/停口令配置数据配置数据启/停消息显示消息传感器信息有效标识消息传感器状态电话号码信号警报类型评价防备设置6.1显示格式化6.2生成警报信号6.3拨电话6.5读传感器6.4配置信息传感器标识,类型传感器状态电话号码配置数据传感器标识,定位警报数据传感器信息电话号码信号控制流图（CFD）2.1打印控制流ControlFlow加工处理Process外部实体ExternalEntity数据存储DataStore控制说明与用户交互1配置系统2启/停系统3显示消息状态5处理口令4监控系统6配置信息显示动作状态（完成、进行中）控制板控制板显示警报电话线传感器传感器事件闪烁标志警报状态时间溢出警报信号启/停开关数据字典（DD）数据字典是对所有与系统相关的数据元素的一个有组织的列表，以及精确的、严格的定义，使得用户和系统分析员对于输入、输出、存储成分和中间计算结果有共同的理解。数据字典把不同的需求文档和分析模型紧密结合在一起数据字典的作用DFD中的数据流、数据存储表示某个有组织的数据集合，它们要由SA的其他描述工具-需求字典(数据字典)来描述，包括：词条描述数据结构描述加工逻辑说明数据字典的内容DD包含的信息名称（标识）别名来源去向组成（内容描述）流动属性（频率、数据量）补充信息数据的层次关系原数据元素组合项重复项选择项可选项数据字典基本符号＝表示“等于”，“定义为”，“由什么构成”＋表示“与”，“和”[|]表示“或”，即选择括号中用“|”号分隔的各项中的某一项{}表示“重复”，即括号中的项要重复若干次，重复次数的上下限也可以在括号边上标出（）表示“可选”，即括号中的项可以没有**表示“注释”（1）数据流词条描述数据流名：说明：简要介绍作用即它产生的原因和结果数据流来源：来自何方数据流去向：去向何处数据流组成：数据结构数据量流通量：数据量，流通量举例：购书单发票领书单审查并开发票开领书单无效书单学生12各班学生用书表学生教材存量表数据流词条说明举例数据流名:发票别名:

无简述:

学生购书时填写的项目来源:

学生去向:

加工1“审查并开发票”组成:(学号)＋姓名＋｛书号＋数量｝数据流量:1000次/周

高峰值：开学期间1000次/天

（2）数据元素词条描述数据元素名：类型：数字（离散值，连续值），文字（编码类型）长度：取值范围：相关的数据元素及数据结构：数据元素词条举例数据项名:货物编号别名:G-No,G-num简述:本公司的所有货物的编号类型:字符串长度：10取值范围及含义:

第1位：[J｜G](进口/国产)

第2-4位：LB01..LB29(类别)

第5-7位：“A00”..“A99”(规格)

第8-10位：“001”..“999”(品名编号)（3）数据文件词条描述数据文件名：简述：存放的是什么数据输入数据：输出数据：数据文件组成：数据结构存储方式：顺序，直接，关键码存取频率：数据文件（存储）词条举例文件名:库存记录别名:无