软件工程-美备课笔记

第1---作为开发运行产品的载体，是计算机控制、信息通信、创建及控制其它程软件工程：制造正确软件所需要的技术，包括过程、方法和工具早期----->第二阶段----->第三阶段----->第四阶 计算机发展----->软件需求激增----->产生软件----->软件工程 >第产业的观老化的软件工与50、60年代的钢铁产业类似，70年代末发生：软件，软件开发周期太长，成本太大，难以。软件的竞软件的开发由原来的自行开发（公司有自己的软件人员委托第开发厂商完软 ：竞软程序 能够完成特定功能和性能的可以执行的指文档 描述程序的操作和使软件特软件不会“磨损”，软件的比硬件的要复杂得多软件构

过程语软件应确定性：信息的处理顺序及时间是可预定 确定的应用非确定性：信息的处理顺序及时间是不可预定 非确定的应用工科学计算软件PC软件：地平线上的软件：寻求解决途 软件工第2软件过程：建造高质量的软件所需要完成的任务的框架---将系统化的、规范的、可度量的方法应用于软件的开发、运行和的过程；1过程、方法和工包括软件工程在内的任何工程方法，必须以有组织的质量保证为基础软件工程是一种层次化的技术：P/16图软件工程的过程层：将技术层结合在一起，使得软件能够被合理、及时地被开发成功。过程定义了：一组关键过程区域（）的框架；关键过程区域：构成软件项目的管理控制的基础，确立上下各区域之间的关系；规定了技术方法的采用、工程产品（模型、文档、数据、报表等）的产生、里程碑的建立、质量的保证、对变化的管理等。软件工程的方法层：提供开发软件“如何做”的技术方法方法涵盖了一系列的任务：需求分析、设计、编程、测试、。软件工程的工具层：对软件工程的工方法提供自动或半自动支持的工具。如果这些工具被集成后，使得一个工具所产生的信息可以被另一个工具使用，就建立了一个支持软件开发的、称为计算机辅助软件工程的系统。计算机辅助软件工程CASE集成了硬件、软件、软件工程数据仓库（包含有关分析、设计、编程、测试的重要信息），从而形成了一个软件工程的环境。与CAD/CAE（计算机辅助设计/工程）软件工程的阶段划对于某个工程，必须考虑的问题阶段：修改软件，以纠正软件错误、适应环境的改变、增强功能、或预防性。软件工程的其它活动软件过程的图形表示：P/172-下面是软件过程的描述，如果不考虑项目的规模和复杂性，下述的框架活动适用于所有软件项目，保护性活动贯穿整个软件过程，并且独立于任何一个框架活动：任务集合 软件工程产品、交付 软件过

一个公共过程框

任务集合 软件工程产品、交付任务集合 软件工程产品、交付 任务集合 软件工程产品、交付

过程成熟度：软件工程（SEI）一个综合模型，该模型定义了一个软件组SEI第一级：初始级，软件过程的特征是无序、甚至的；无过程定义；软件的开发成第二级：可重复级，建立了最基本的项目管理、费用追踪、进度和功能控制的软件过程，有一定的过程规范，使得可以重视以前类似项目的成功。第三级：定义级，软件过程文档化、标准化，与整个组织的软件过程相集成；并包含第二级的所有特征。第四级：管理级，收集软件过产品质量的详细度量数据，通过这些数据定量地理解和控制软件过产品的生产；并包含第三级的所有特征。第五级：优化级，通过来自于过程、或测试新的想法和技术而得到的定量的反馈，不断对过程进行改进；并包含第四级的所有特征。须具有的软件工程的功能，例如软件项目计划、需求管理等等。每个KPAs都235实现的方法：活动在实现过程中被的方18KPA都用上述特征进行描述。在成熟度第五级中包含18KPA。为解决软件产业开发环境中的实际问题而综合制定的策略。这些策略能够覆盖前面所述的软件过程、方法和工具，及软件工程的一般阶段。是从用户到开发者、到技术的续过程。可以相对划分成4个阶段（状态描述、问题定义、技术开发、方案综述），但是，不可能清楚地进行划分，因为在各阶段内部和各阶段之间的活动往往是交叉进行的。即：对一个软件项目，不管选择什么过程模型，所有的阶段（状态描述、问题定义、技术开发、方案综述）在某个细节的P/202-3。线性顺序模软件工程的“线性顺序模型”也称“传统生命周期模型”、或“瀑布模型”；是一种最早的、应用最广的、支持直线开发的过程模型。P/212-4缺点：1在开发过程中的变化可能引起运行版本只能到项目开发晚期得到，这时才发现的错误，其可能是灾原型模软件工程的“原型模型”是一种从用户处开始收集需求、初步定义软件的总体目标，然后进行快速设计、建造软件“模型”，运行原型、征求用户意见；进一步了解需求，再设计、修改“模型”，再运行原型、征求用户意见…，的一个迭代过程。P/222-5原型模型可以帮助用户和开发者清楚地理解需求，但不是最终交付的软件产品。优点：12缺点：1用户往往把看到的原型作为软件的最初“版本”，实际上是没有考虑软件的总体质量和可性的快速“拼凑”而成的“演示软件”；2由于很早就得到用户“认可”，往往就放松软件开发的管理，开发者也常常进行“折衷”，把“演示”功能中的不合理部分处理成软件的实际功能。应该：原型作为参考，实际的软件开发必须在充分考虑质量和可性以后才进行RAD（快速应用开发）模模型适用于能够被模块化的信息系统的应用软件的开发。P/242-6。RAD5处理建模：抽象并定义数据建模中的数据对象的和处理测试及反复：测试新的构件及所有接口（被复用的构件已经被测试过）特点：1一个开发组一般在短期（60～90）内就能创建出一个功能完善的软件缺点：1RADRAD演化软件过程模先理解好系统需求和产品部分，其它细节部分暂缓进行。P/262-采用随时间的进展而交错迭代的线性序列。每一个线性序列产生一个可发布的软件“增量”。任何增量的处理流程均可以结合进原型范型，但与原型模型有所不同：强调每个增量均是一个可操作产品，最早的增量是最终产品的“可拆卸”的、给用户提供服务和评估的版本。典型的螺旋模型：P/272- 用户评估：为获得用户的反馈所需要的任务工程项目从开始沿螺旋移动螺旋的第一圈一般产生的是产品的规格说明，第二圈一般产生的是一个原适用于整个生命周期的螺旋模型：P/282-螺旋模型需要相当的风险评估的专门技术，其开发成功依赖于这种专门技术；因此，应用并不广泛。利用预先包装好的软件构件（“类”）来构造应用程序。P/292-10并发过程模型（也称“并发工程P/302-该模型可以用于任何类型的软件开发，但多用于“客户/形式化方法模第四代技术4GT数据库查询的非过程语言、报告、数据、屏幕交互和定义、代码、4GT用一种特定的语言，或者用一种用户可以理解的问题描述方法来描述要解决的问题的图形表示，因此，4GT过程模型的关键是：说明软件的能力。4GT第3穿于整个软件的定义、开发和过程中。项目管理活动包括：测量、度量、估算、风险分析、进度安排、项目和控制。选择、业绩管理、培训、、专业发展、组织和工作计划、团队精神、企业文化培方案，定义对人员、、技术和管理上的约束。人项目参与5项项目必须具有管理人的才能应该具有如下能力（JerryWeinbergMOI模型）：想法（Ideas）或创新（Innovation）：管理者的：必须并项目和人员。成就：和团结有成绩的人员，并鼓励在项目的约束下进行“积极”的技术。影响和队伍建设：与人“沟通”，具有在高压力的环境下保持良好的控制能力软件项目nk1：nm人，各小组之间的协调工作由项目进行。3：nm组和项目共同控制。3：P/433-41234主程序员：负责规划、协调和工程的全部技术活动。协调和通信问问随着项目开发的不断进展，需求可能不断被改变，管理者必须不断和考虑人软件范问题分因此，划分和分解问题（任务）是需求分析的活动过所有的软件项目的开发均有如下的一般阶段：定义、开发、在着手开发软件前，必须选择合适的软件工程“过程模型”，然后基于公共过程框架活动集合，定义一个初步的计划。合并问题和过制定项目计划的开始，往往是对问题和过程进行归并：P/473-2每个框架活动都有相应的软件工程的任务，每个软件工程任务又对应具体的软件的功能。项目可以根据图的各个活动单元估算资源要求和时间。过程分项第4章软件过项目的度过程度量：从级洞悉软件过程的功效。测度（measurement）：测量（measure）：对软件产品的质量进试描述。是对一个产品过程的某个属度量（metric）：对一个系统、构件、或过程所具有的某个给定属性的“度”的一个定量的测量。在某种程度上与单个的测量相关（例如，在复审中每人、每小时所发现的错误的平均数）。指标（indicator）：是度量、或度量的组合。收集测量结果、产生度量，就可以过项目领域中的度应该：收集度量，以确定过产品的指标12潜在的风险3在问题造成前发现问题45过程度量和软件过程改软件过程度量对提高组织的总体过程成熟度有利。是的。改进过程的唯一合理的方法就是测量过程的特定属性，基于这些属性开发一组度量，然后使用这组度量来提供指导改进过程的指标。项目度软件项目度量：是战术的。软件管理者和开发者利用项目度量、及从项目度量中得到的指标，改进项目工作流技术活动。软件的间接测量：功能、质量、性能、可靠性、可性等等。面向规模的度度量是通过规范化质量和（或）生产率的测量而得到，这些测量是基于所开发的软件的规模。缺点：在开发初期估算代码行较，适用于过程式程序设计语言。代码行度量依赖于程序设计语言，存在因素。面向功能的度根据事物信息处理程序的基本功能进行度量，在软件的开发初期能估算出软件的规模。功能点：是基于软件信息领域的可计算的、直接测量，以及软件复杂性评估而计算出来的。计算实例：P/594-缺点：涉及到的因素较多，有些数据不易，功能点EP值没有直观的物理扩展的功能点度功能点度量适合商业信息系统的应用软件，不适合其它工嵌入式系统的软件。代码行的度量和功能点的度量之间的关系依赖于开发软件所采用的程序设计语言和设计质量。不同的程序设计语言所产生的代码行的“度量”，不能进行直接比较，尤如“苹果和橘子”无法进行直接比较一样。生产率度量，影响软件生产率的几个重要因素概述影响质量的因影响质量的一组因素产品转换（软件的移植测量质测量。例如，对于“正确性”的质量因素的测量，可以使用如下方法进量：缺陷排除效DRE：DREDRE1，当把一个项目作为一个整体考虑时：DRE=E/(E+D其中：EDiDREi=Ei/(Ei+Ei+1其中 =在软件工程活动i中所发现的错误测量：软件工程过程测量、软件测量、生产率测量，使得管理者和开发者能够改善软件过程，辅助软件项目的计划、、控制，评估产品质量。度量的收集可以使组织“调整”软件工程过程，以排除对软件会引起重大影响的缺陷的致命原因。度量必须在估算、技术、项目控制、过程改善中加以评估和使用。软件项目的管理过程从一组被称为“项目计划”的活动开始，其第一个活动是在项目开始进行之前，必须先对如下几件事进行估算：开发周期、开发工作量、开发人员、开发成本、开发所需要的软硬件资源、开发风险。项目计划的目标：提供一个框架，使得项目责任者能够在一个限定的时间框架内，对资源、成本、进度进行合理的估算（“最好情况估算”与“情况估算”）。软件范围的确定：是软件项目计划的第一个活动。软件范围的确定，可以帮助估算开发软件的工作量。获取定义软件范围所需的信一个范围定义的例然后对获取的信息进行评估。功能、性能、约束必须一起评估。因为，约束性能不同，相同的功能的实现可能存在数量级的差别。性进量在描述软件范围所需要的信息（这些信息已档化了）.否则，计划实施者必须进行资资源的特征说明：资源描述、可用性说明、需要该资源的时间、该资源被持续使用的时间。人力资职位：项目、高级软件工程师、程序员、文档管理员等。专业技能：网络、数据库、设备等。可复用软件资可直接使用的构件：能够从第厂商获得，或已经在过去的项目中开发成功、数据等，软件开发人员在这些构件所代表的应用领域中已具有丰富的经验，只要稍加修改就可使用。因此，修测试数据等，软件开发人员在这些构件所代表的应用领域中具有有限的经验，要作实质上的修改才能使用。因环境资软件项目估在软件范围（规模）估算的基础上，可以进行工作量和资源的估算，在此基础上，可以进行成本估算。 3直接方法：代码量法（LOC）使用模糊逻辑基础的近似推理技术。计划者先说明应用软件的类型，建立定性的规模估算，然后在最初的范围内精化估算。此法需要计划者的个人经验和历史数据库的支持。计划者估算每个标准构件出现的次数，然后统计确定每个标准构件交付时的大小，得到最终的规模值。用于必须作修改才能把已有软件作为项目一部分使用的情况。计划者估算必须完成的修改的数目和类型，得到修改的规模。基于问题的估算和例根据说明分解软件成可以被独立估算的“元素”，元素可以是代码行、功能点、类、某个“修改”等；LOCFP基于过程的估算和例根据说明，把软件的开发过程分解成相对独立的任务，及其相关的“过程活动”；根据“平均劳动力价格”计算每个“过程活动”的工作量和成本；估算小应该至少分别利用上述2种方法进行估算工作量和成本，然后进行比较。如果估算典型的经验估算模型：通过对以往的软件项目所收集到的数据，进行回归分析而导出的。估算模型的结经验估算模型的总体结构：E=A+B*不同的模型，其计算结构有所不同O模1981年BarryBoehm“构造性成本模型（COnstrucriveCOstMOdel）”：在静态、单变量模型的基础上进行构造，把整个模型分为3个层次：基本、中间、详细层次模型：估算相对独立的软部件（模块）OO3软件方程4000估算公式自行开发或的决在许多情况下，软件比开发软件的费用要低。因此，对自行开发软件、还是1可以直接使用的软件2“具有完全经验”或“具有部分经验”的软件构件，然后进行修改和集成3建立软件需求（功能、性能），3～4在最后，决定自行开发还是的决定因素2成本是否比自行开发低3外部支持成本（软件合同）是否比内部支持成本低创建决策P/875-3外存在许多能够帮助计划者进行工作量和成本估算的自动估算工具，这些工具具有共同的特性，并且需要提供一定的数据：P/88。第66.1和主动的风险策对软件开发的计划产生的。技术风险：因软件在设计、实现、接口、验证、过程中可能存在潜在的问题，或采用了不可靠的技术等，对项目质量和交付时间造成的。试图系统化地确定对项目计划（估算、进度、资源分配）构成的所有因素，建立“风险条目检查表”，罗列、归类风险。产品规模风常见的与产品规模有关的风险商业影响风商业考虑常常会与技术实现发生。客户相关的风不同的客户对项目会产生不同的影响。“不好的”客户往往会对项目构成和常见的与客户有关的风险过程风过程风险：由于软件过程定义得不清楚，软件分析、设计、测试的方式方法不合理而产生的风险。P/95~96技术风开发环境风与人员数目及经验相关的风人是项目成功的重要因一常见的与人员及人员素质、经验有关的风险风险因素和驱动因风险驱动因子：对风险预算产生影响的类别。可分为可忽略的、轻微的、严重的、4P/986-风险预测（也称：风险估算描述风险的建立风险P/996-2：分析罗列所有的风险，对每个风险进行分类、概率估算、确定影响类别；然后进行风险排序（按发生概率的高到低、影响的高到低进行排序），确定“中止线”（在中止线上的风险必须进行控制。在中止线下的风险，继续进行评估，然后进行第二次排序…）。评估风险影3风险范围：风险的严重性、及风险整体分布情况（即项目中有多少部分受到影风险评在整个软件过程中，必须不断关注风险、评估风险，尤其是导致成本超支、进度延迟、性能降低、支持的风险。对某个风险，如果一旦超过此值就会导致项目的被迫终止。如果多个风险的组合所产生的问题，引起一个或多个参考水平值被超值，则软件过程被停止。P/1016-风险缓减、和管避免风险是最好的风险策略。为避免风险，必须预先对风险制定风险缓减计划。例如，人员的流动会产生风险，可以制定计划，使得人员流动延任务完成时才发生。风险随着项目的开展，风险控制活动就开始进行。对会产生风险的因素进行控制，同时应控制缓减风险步骤的效力。风险的主要目的注意：风险缓减、和管理（RMMM）将增加额外的项目开销安全性风险和软件的安全性、潜在的。RMMM计RMMM计划：RiskMitigation、Monitoring ManagementPlanRMMM计划的大纲：P/103组成部分。是项目管理者和控制项目的主要活动。软件延期交付的几个根本原因关于“延迟”的评管理者必须：保护软件开发队伍免受不适当的进度安排的压力，并且把这种压力如果某些迫使提前完成软件开发的压力是必须给予“重视”的，一般的方法是与施加压力方会谈，采用分期交付软件的方法，即：首先提交最关键的功能，然后逐次提交其它部分。基本原每个任务必须指定具体 一个例所有参与开发的人员之间存在“通信”问题，因此，产生通信成本和通信时间。所以，不能简单地认为mmm一个经验关在P/85页的5.7.3节中描述的软件方程式中：完成项目的时间与投入的人员的工为实现同样的目标，开发时间与投入人员的工作量应该细加计算：P/111工作量分40－20－40后期的测试工作量应用项目：以用户不察觉的方式对现有软件进行纠错、或适应性的。软件开发是一个过程，不同的过程模型为开发软件提供了不同的范型。过程模型是由一个任务集合组成的。任务集合使得项目组能够定义、开发和最终软件。小的软件系统的任务集合相对简单，而大的软件系统的任务集合就相对复杂。一个任务集合包括一组软件工程的任务、里程碑和交付产品，这些任务是必须完成才能得到软件产品的。一个项目所选择的任务集合必须为最终得到高质量的产品而提供规程要求，但同时又不能让项目组承担不必要的工作。有许多因素影响项目任务集合选择，当综合考虑这些因素时，就构成一个称为严格4随意的：使用所有过程框架活动，但只需要一个最小的任务集合；最小化保护性活动的任务，降低文档要求。结构化的：过程框架活动、适用于项目类型的相关任务、为保证高质量所需要的保护性活动将得到应用。严格的：整个过程按照一种能够保证高质量的严格规程要求进行，所有的保护性活动都将被采用，并且建立健壮的文档。项目管理者为选择合适的严格度，需要定义项目适应性准则，并计算“任务集合选择因子（TSS）”的值。定义适应性准11每条准则都有一个等级分数，取值范围：1～55计算任务集合选择因子的TSS：TSS复审每个适应性准则的因子，因子的值在0.8～1.2之间，以表示适应逐条计算“乘积’：P/1137-TSS：“解释TSS值并选择任务集TSSTSS的取 严格TSS< 1.0<TSS< TSS> 上述存在取值范围的“”，表示不可能定义精确的边界。例如，如果一个项目的TSS值是2.8，表示该项目可以选择结构化的、或严格的任务集合；在进行最后的选择时，还应结合“经验”、“”等考虑因素。例：P/114本节以“概念“型的开发项目为例，列出的需要完成的主要任务：P/115必须完成的任务（项目范围）；是否有人去完成；进行风险评估；以某种方式证明采用的新技术；把采用的技术用原型方式实现（概念实现）；用户评价。最后，如果这个概念可行，则进行产品开发。任务精化可以用大纲格式进行：P/117（概念类型项目的任务的精化格式）任务网络：一个项目的任务流程的图形表示。P/1187-3任务和子任务之间存在相互关系，由于多个开发人员的参与，任务和活动并行进行的可能性就增大。项目必须确定关键任务、各任务之间的依赖关系，协调并发任务，以确保任务的如期完成。2种方法：时间时间表：P/1207-进项目表：P/1217-项目表与时间表一起使用，可以使项目管理者项目的进展情况。文档格式：P/1227-5SQA：是在软件过程中的每一步都要进行的“保护性“活动。是将质量保证的管理对象和设计原则映射到适用的软件工程管理和技术空间上，当映射成功时，其结果就是成3差异控制：是质量控制的。质软件质量：在很大程度上是一种知识实体，因为软件特征的定义比物理对象要质量控质量控制：为保证产品符合需求而在整个开发过程中进行的一系列的、复审、质量保质量的成3鉴定成本：为鉴定在各过程中产品的状态而进行的活动成本。例如，设备成本、内部失败成本：指产品交付前发现错误而的成本。例如，返工、修外部失败成本：指产品交付后发现错误而的成本。例如，解决用软件行业与其它行业一样，必须进行“全面（TQM）”TQM4质量定义：明确的功能和性能要求、明确文档化过的开发标准、以及专业开发 会），如果软件只符合了明确的需求、却没有满足隐含要求，则软件的质背中期（70～80年代）：质量保证的定义是为了保证软件质量而必须的“有计划的、近期：质量保证的定义是在中，有多个机构负有保证软件质量的责任（包SQA活SQA 为项目制定一套方法：在需求分析阶段对软件质量提出要求，并自顶向对软件开发的各个阶段进行软件工程的正式技术评审保证软件的开发过选用的软件开发标准相一致SQASQA除上述活动外，独立的SQA小组还要协调变化的控制和管理，并且帮助收集和分析软件缺陷对成本的影经过数据收集、分析和统计，如果假定一个在软件设计阶段发现的错误，其改正1改正一个在测试开始前发现的错误的成本是6.5个货币单位；改正一个在测试时发现的错误的成本是15个货币单位；改正一个在软件发布后发现的错误的成本是60～100缺陷的放大和消“缺陷放大模型”：用于说明在软件工程过程中的概要设计、详细设计、编码、测试阶段中的错误的产生及检测。在软件工程的各个阶段都会产生新的错误，同时会存一个阶段没有被发现和改正的错误。在某些情况下，前面带过来的错误会被放大：P/1328-2。8-38-4发和成本要大大低于无复审的开发和成本。复审使得开发人员必须付出时间和费用。但是，必须明白：现在付出，否则以后付出。正式技术复审（FTR）：FTR同时，由于FTR的进行，使得参与人员更加了解软件系统，可以起到提高项目连FTR方式：“走查”、“”、“论查”等FTR复审会3～52复审报告和记录保发现什么（或把复审问题列表作为附件）？：保证问题列表中的每个条目均得到改正。可以指定由复审责任者、或小组进行复审指正式技术复审指南的最小集合：P/134～135SQA以数学方法证明程序的正确性。即，把计算机程序看作一个数学对象，对于每一种程序设计语言都能够定义一套严格的语法和语义，并且对软件需求说明也有一种类似的严格定义方法。这样，一旦需求说明以一种严格的方法被表示出来，就能够采用程序正确性的数学证明来说明程序是否严格符合它的说明。Pareto20%Pareto统计数据的收集：P/1378-2。t例表示：一个软件在相同的环境中被执行了10030092300，8改正一个失败可能引入其它，而这些失败的“实现”又可能会引入其它的可靠性和可用性的度平均修复时间（MTTR）：软件可靠性的度量：软件平均失败间隔时间即：MTBF＝MTTF+MTTR可用性＝平均失败时间/(平均失败时间＋平均修复时间)*分析：对于那些“隐藏”时间很常才被发现的缺陷，可靠性度量就不适用。而可用性度量对平均修复时间较敏感。因此，除可靠性度量外，还应该进行可用性度量。软件的安全和的分软件的安全和分析主要解决如何标识出潜在的、导致整个系统失败 ，以及评估潜在 系统可能形成的影响和引起整个系统瘫痪的可能性导致系统或。而软件安全性则软件失败会导致系统发生的条件，把SQA计IEEESQA：P/1408-ISO9000ISO9000ISO对质量的保证系统的方ISO9000包括用现质量计划、质量控制、质量保证和质量改进所需的组织结构、规程、过资源。但是，ISO9000并不描述应该如何实现这些质量要素。因此，真正的在于如何设计一个能够满足这个标准、并且适用于自己公司的产品、服务和文化的质量保证系统。ISO9001标ISO9001ISO900120如果某个软件组织要通过ISO9001，就必须对这些问题的每一条需求都建立相关的软件配置：由一组相关联的软件配置项（包括开发环境）4 目开始，到软件退出运行后才终止的一组和控制活动。基基线：已经通过正式复审和批准的某个规约或产品，这些规约或产品可以作为进一步开发的基础，并且只能通过正式的变化来控制过程的改变。软件配置组成一组基线的项目配置项要改变某个基线SCI，只有在遵循软件配置管理（SCM）的情况下才可以SCM过SCM软件配置中对象的标对象：由基本对象和其它对象组成的对象集合版本控SCI（源代码、文档、数据）的集合，每个版本可能由多个变化控变化控制过程：P/1559-控制和同步控制：P/1569-8SCI配置审软件配置项的标识、版本控制、变化控制能够帮助开发秩序。有关配置审计的问题配置状态报配置状态报告的内容：发生了什么、发生的事是谁做的、什么时候发生的、将会造成什么影响？SCM标SCM：ANSI/IEEEStd.No.828-1983、No.828-1984系统工程：从“整体视图”开始分析产品，以建立所有的基本需求；然后关注点缩小到“领域视图”，分析各个系统元素；把每个系统元素分配给一个或多个工程构件，然后这些元素由相关的工程方法处理。系统工程的任务以创建了系统规约而结束，系统规约是后续工程的工作的基础文档。系统工程构件（元素）：软件、硬件、人员、数据库、文档、过程。系统工程把用户的需求映射到使用这些构件的系统。信息工程、产品工程：都是系统工程方法的一种。本书的“系统工程”包括信息工程和产品工程。构成系统的一组元素可能表示了某个更大的系统的宏元素，而这个宏元素是一个基于计算机的系统，这个系统是某个更大的基于计算机的系统的一部分。例如“工厂自动化系统”中的数控机床，这个数控机床是基于计算机的系统的一个元素，而它本身又是基于计算机的系统。系统工程师：在系统的整体层次（宏元素）的语境内为特定的基于计算机的系统定义一系列元素。法导出：P/16410-2。系统建表示使得工程师更好地理解视图的所有连接（包括输出）信息工程：概产品工程：概系统工程与软件工系统工程的进一步开发，就转变为软件工程P/16610-3、P/16710-4信息策略计业务域分系统分说明客户需可行性研经济分技术分描述基于计算机的系统的功能和性能、以及将支配其开发的约束的文档；是硬件工程、软件工程、数据库工程、人机工程的基础。系统规约文档的一般格式：P/184是发现、求精、建模、规约的过程。为开发和最后的验收提供标准和依据，由系统分析员承担。需求规约复审完成：需求规 软件开发的“合约能、性能、软件与其它系统元间的接口、软件的约束等。过程的启便利的应用规约技FAST（便利的应用规约技术一种面向团队的需求收集方法，用户和开发者双方共同标识和商议，确定解决方案，编写完整的规约草案。质量功能部QFD（质量功能部署是一种技术，把用户的需求翻译成软件的技术需求QFD3记录每个需求的和原因信息软件的信息域：包括数据和事件（控制）3信息内容表示各单个数据和控制对象，这些数据和控制对象可以构成某个更大的由软件变换的信息集合。数据和控制对象可以与其它数据和控制对象相关联，就产生了信息之间的关系。建用图形符号体系创建。把信息、处理、系统行为和其它特征描述为不同的、可识别的符号，模型的其它部分可以用文字描述。从软件的名字开始，经过一系列的迭代处理、提供越来越多的功能细节，直到所有系统功能得到完全描述。描述软件外部的行为模式、及改变行为模式（状态）划分解问题，可以进行功能划分、信息划分、行为划分，使得复杂的问题分解成若干个小而简单的问题，易于问题的求解。基本视图视软件需求的基本视图：描述软件要完成的功能和处理的信息，不描述具体如何实现。软件需求的实现视图：描述处理功能和信息结构的实现元素，需求的实现视图不处理见：2.3选择原型方 表11-1原型方法和工见：2.3规约原 定义系统运作的环境，并指明：一组高度缠绕在一起的，如何对环境中其它表软件需求规软件需求规约的格式：P/20111-产生了需求规约，用户和开发者必须共同对其进行复审。一旦复审通过，规约就成为软件开发的“合约”，即作为软件验收和测试的依据。简19601970定义一组在软件完成后可以被确认（验收）结构化分析模型：P/20712-数据字典：是分析模型的，包含软件的所有数据对象的描述。状态－变迁图数据对象、属性和关基数和形3 111 1，N。 M，N。1，表示关系必须出现一次。关系的基数和形态实例：P/21112-实体---关系E－R例：P/21212-612-712-812-数据流（人机界面）：

针对实时系统的扩实时系统的数据流图扩展的新符号：P/12612-Ward和Mellor扩Hatley和Pirbhai扩P/221~222：12－1912－2012－21对外接口：使用户通过本手册了解系统的用途，并且能够确定在什么情况下如何使用本系统；创建实体---关系E－R：P/223实例 创建数据流模实例 创建控制流模 控制规实例：SafeHome状态变迁图P/229加工规例：P/23012-3012-31数据字典：是所有与系统相关的数据元素的有组织的列表，并对数据进行精确的、严格的定义，使得用户和系统分析员对于输入、输出、成分和中间计算数据有共同的理解。名称：数据或外部实体的主名；别名：数据或外部实体的其它名称；数据字典中的内容描述的符号：P/23212-订票信息＝{航班号|起点＋终点}＋起始地点＋终止地点＋日期＋其中：班号|点＋终点程，例如，到：＋、＋、＋其它常用的三种结构化分析方法：DSSD、Jackson、SADT数据结构化系统开发DSSD：Warnier-OrrJackson系统开结构化分析和设计软件设计是软件工程的技术。设计自“需求分析”之后开始。软件设计模型的创建基于软件的分析模型：P/23913-14，4数据设计：把分析时创建的信息域模型变换成软件所需要的数据结构。依据体系结构设计：定义程序的主要结构元间的关系。从分析模型的数据流图的设计和软件质3 对于编程、测试和人员而言，设计必须是可读、可理解的 设计应该导出具有独立功能特征的模块，例如子例过程软件设计的演3013.4设计对于分析建模应该能够的设计应该具有一致性和集 应该复审设计，以减少概念性（语义性）“软件工程师的智慧的体现，开始于对程序工作和程序正确性之间的区别的识抽使得能够集中于某个一般性级别上的问题，而不考虑无关的底层细节。软件工程过程中的每一个步骤都是软件解决方案抽象级别上的求精。抽象过程是一个命名的指令序列（抽象描述过程），具有特定的和有限的功能。求模块模块是把软件划分成可以独立命名和可以独立的程序“构件”。是对复杂问软件体系结功能、可靠性、安全性、适应性、和其它系统特。控制层P/24513-扇出大：说明模块复杂，可以增加中间层（7）结构划数据结数据结构：表示单个数据元间的逻辑关系，是数据的组织形式软件过因此，过程的表示也是有层次关系的。P/24813-5。信息隐隐藏加强了模块内部过程细节或模块使用的任何局部数据结构的模块化设计：降低了复杂性，方便软件的理解、测试和模块划分没有标准，但是有划分原则 功能独立内内聚 （功能模块的内聚：模块的“”度量低内聚：相对中度内聚“”多些中内聚：相对高内聚，一个模块中有一个以上的“”。高内聚：一个模块只有一个“”，就是高内聚的模块耦数据耦合：通过数据传递而的模块，称之间存在数据耦合。印记耦合：通过传递部分数据结构而的模块，被传递的部分数据结构在如果多个模块中存在相同的处理，则把这相同的处理定义成新的模块，提高模块的内聚度。减少对全局变量