软件工程知识点汇总.doc

上传人:wj 文档编号:4728945 上传时间:2023-05-07 格式:DOC 页数:11 大小:196KB
下载 相关 举报
软件工程知识点汇总.doc_第1页
第1页 / 共11页
软件工程知识点汇总.doc_第2页
第2页 / 共11页
软件工程知识点汇总.doc_第3页
第3页 / 共11页
软件工程知识点汇总.doc_第4页
第4页 / 共11页
软件工程知识点汇总.doc_第5页
第5页 / 共11页
软件工程知识点汇总.doc_第6页
第6页 / 共11页
软件工程知识点汇总.doc_第7页
第7页 / 共11页
软件工程知识点汇总.doc_第8页
第8页 / 共11页
软件工程知识点汇总.doc_第9页
第9页 / 共11页
软件工程知识点汇总.doc_第10页
第10页 / 共11页
软件工程知识点汇总.doc_第11页
第11页 / 共11页
亲,该文档总共11页,全部预览完了,如果喜欢就下载吧!
下载资源
资源描述

软件工程知识点汇总.doc

《软件工程知识点汇总.doc》由会员分享,可在线阅读,更多相关《软件工程知识点汇总.doc(11页珍藏版)》请在冰点文库上搜索。

软件工程知识点汇总.doc

软件工程知识点汇总

1软件工程、软件工程方法学:

三要素

1.1软件工程:

应用系统化的、规范化的、可度量的方法来开发、运行和维护软件,即将工程应用到软件;对的各种方法的研究

1.2软件工程是一门研究用工程化方法构建和维护有效的实用的和高质量的软件的学科

1.3软件工程三要素是:

方法、工具、过程

软件工程的方法:

是指完成软件开发各项任务的技术方法

软件工具:

是指为软件工程方法的运用提供自动半自动的软件支撑环境

软件工程过程:

是指将软件工程方法和工具综合起来以达到合理、及时地进行计算机软件开发这一目的

2软件工程的原则包括:

模块化原则、信息隐蔽原则、抽象化原则、模块独立原则(内聚、耦合)、依赖倒转原则、开闭原则等

2.1模块化原则:

指解决一个复杂问题时自顶向下逐层把软件系统划分为若干模块的过程。

模块是程序中相对独立的成分,一个独立的编程单位,应有良好的编程接口,模块的大小要适中,模块过大会使模块内部的复杂性增加不利于模块的理解和修改,模块过小会导致整个系统表示过于复杂,不利于控制系统的复杂性。

2.2信息隐蔽原则:

采用封装技术,将程序模块的实现细节隐藏起来,使模块接口尽量简单。

2.3抽象化原则:

抽取事物最基本的特性和行为,忽略非本质细节,采用分层次抽象,自顶向下,逐层细化的办法控制软件开发过程的复杂性。

2.4模块独立原则:

是指每个模块只完成系统要求的独立子功能,并且与其他模块的联系最少且接口简单。

要求在一个物理模块内集中逻辑上相互关联的计算机资源,保证模块间由松散的偶合关系,模块内部有较强的内聚性,这有助于控制系统的复杂性。

(即:

高内聚低耦合)

2.5依赖倒转原则:

抽象不应该依赖于细节,细节应该依赖于抽象。

2.6开闭原则:

软件实体应该是可扩展的,但是不可以修改。

即对于扩展是开放的,对于更改是封闭的。

3软件开发模型:

瀑布模型;快速原型;喷泉模型;各种模型的工作原理、阶段、每阶段任务、特点、示意图;

软件开发模型(也称为软件过程模型):

是从软件项目需求定义开始直至软件经使用后废弃为止,跨越整个生命周期的系统开发、运行和维护所实施的全部过程、活动和任务的结构框架

3.1瀑布模型(又称线性模型):

3.1.1工作原理:

规定了它们自上而下、相互衔接的固定次序,如同瀑布流水,逐级下落。

前一阶段的工作成果是后一阶段工作开始的基础.所以,每个阶段都必须交出合格的文档,必须对前阶段的工作进行评审,前一阶段的工作完成后才可以开始后一阶段的工作

3.1.2阶段:

计划时期:

问题定义、可行性研究

开发时期:

需求分析、设计、编码、测试

运行时期:

运行和维护

3.1.3各阶段任务:

1.需求分析和定义

在软件项目进行过程中,需求分析是从软件定义到软件开发的关键步骤,是今后软件,开发的基本依据,同时也是用户对软件产品进行验收的基本依据。

需求分析和定义是以用户需求为基本依据,从功能、性能、数据、操作等多个方面,对软件系统给出完整、准确、具体的描述,用于确定软件规格。

2.软件设计

根据系统需求的定义,确定系统的结构,进行系统的概要设计和各部分的功能与结构的详细设计。

3.编码与单元测试

在这一阶段,根据软件设计文档完成了程序模块或程序单元的编码。

通过程序单元测试,验证其是否满足设计规范。

4.集成和系统测试

程序模块或程序单元被组装集成起来成为一个软件系统,然后进行系统测试。

测试完成后即交付用户使用。

5.运行和维护

通常这是软件生命周期中最长的一个阶段。

如果在运行期发现了软件的错误,就要修改软件,可能会重复上述某个或多个阶段的活动。

3.1.4特点:

①顺序性、依赖性:

下一阶段依赖上一阶段的完成。

②推迟实现:

阶段任务结束形成文档,并审核后方能进行设计任务,将程序的实现推迟进行。

③质量保证:

文档完整、文档评审,避免错误积累与放大效应。

3.1.5示意图:

3.2快速原型

3.2.1工作原理:

快速原型是利用原型辅助软件开发的一种新思想。

经过简单快速分析,快速实现一个原型,用户与开发者在试用原型过程中加强通信与反馈,通过反复评价和改进原型,减少误解,弥补漏洞,适应变化,最终提高软件质量。

废弃型:

也称快速建立需求规格原型法:

先构造一个功能简单而质量要求不高的模型系统,针对这个模型系统反复的进行分析修改,从而形成较好的设计思想,据此设计出更加完整、准确、一致可靠的最终系统,系统构造完成后,原来的模型就被废弃

追加型:

也称快速建立渐进原型法。

它采用循序渐进的开发方式,对系统模型作连续精化,即先构造一个功能简单而且质量要求不高的模型系统,最为最终系统的核心,将系统需要具备的性能逐步添加上去,通过不断地扩充修改,逐步追加新的要求,直至所有性能全部满足,此时原型模型也就是最终的产品。

3.2.2阶段及任务

原型快速分析:

是指在分析者和用户的紧密配合下,快速确定软件系统的基本要求,根据原型所要体现的特性(总体结构、处理功能、模拟性能、界面形式等),描述基本需求规格说明,以满足开发圆形的需要。

原型构造:

在快速原型分析的基础上,根据基本需求规格说明,忽略细节只考虑主要特性快速构造一个可运行的系统。

原型运行与评价:

是软件开发人员与用户频繁通信、发现问题、消除误解的用药阶段,目的是验证原型的正确程度,进而开发新的并修改原有的需求。

原型修改:

根据评价原型的活动结果进行修改。

若原型未满足需求说明的要求,说明 对需求说明存在不一致的理解或实现方案不够合理,则根据明确的要求迅速修改原型。

3.2.3特点

1.增强了软件开发人员和用户对系统需求的理解,便于将用户模糊的功能需求明确化

2.为用户提供了一种强有力的学习手段

3.易于确定系统的性能,是理解和确定软件需求规格说明的良好工具

4.按照快速建立渐进原型法建立的原型即为最终的产品

利用快速原型化技术可以为软件开发提供一种完整、灵活、近似动态的需求规格说明方法。

3.2.4示意图

3.3喷泉模型

3.3.1工作原理:

喷泉模型是一种以用户需求为动力,以对象为驱动的模型,主要用于描述面向对象的软件开发过程。

该模型认为软件开发过程自下而上周期的各阶段是相互重叠和多次反复的,各个开发阶段没有特定的次序要求,并且可以交互进行,可以在某个开发阶段中随时补充其他任何开发阶段中的遗漏。

3.3.2阶段

3.3.3每阶段任务

3.3.4特点:

喷泉模型体现了软件创建所固有的迭代和无间隙的特征。

迭代指系统中某个部分常常重复工作多次,无间隙指活动之间没有明显的间隙,如在分析和设计之间没有明显的界限。

3.3.5示意图

4软件生命周期:

阶段、各阶段功能、所涉及的内容(图、工具和文档)

4.1软件生命周期:

是指一个计算机软件从功能确定、设计到开发成功投入使用,并在使用中不断地修改、增补和完善,知道被新的需求所替代而停止该软件的使用全过程。

4.2四个工作阶段:

初始阶段:

建立业务模型,定义最终产品视图,并且确定项目的范围。

精化阶段:

设计并确定系统的体系结构,制定项目计划,确定资源需求。

构建阶段:

开发出所有构件和应用程序,把它们集成为客户需要的产品,并且详尽地测试所有功能。

移交阶段:

把开发出的产品提交给用户使用

4.3各阶段功能:

1问题定义可行性研究

可性研究的任务是以最小的代价在尽可能短的时间内确定问题是否值得解决、是否能够解决。

阶段性成果《项目可行性报告》

2需求分析阶段

需求分析的主要任务就是要通过软件开发人员与用户的交流和讨论,准确地获取用户对系统的具体要求。

阶段性成果《需求规格说明书》、数据字典、数据流图(DFD)

3概要设计阶段

划分出组成系统的物理元素,设计软件的结构,即确定模块及模块间的关系,根据需求分析阶段得到的逻辑模型来设计系统的物理模型

阶段性成果《概要设计说明书》

4详细设计阶段

设计每个模块的算法,确定每一模块使用的数据结构,确定模块接口的细节,为每一个模块设计一个测试用例,编写详细设计说明书

《软件详细设计》文档

5编码和单元测试

6系统测试

7软件维护阶段

4.4各阶段所涉及的内容(文档、工具、图)

5结构化方法:

生命周期中各阶段任务.获取用户需求、画数据流图、数据字典

6可行性分析、需求分析、设计(概要设计+详细设计)、测试、维护

7面向对象方法:

核心概念、模型

7.1面向对象中的基本概念:

对象:

代表了一个现实的或虚构的实体

类:

对具有相同数据和相同操作的一组相似对象的定义

继承:

子类自动的共享父类中定义的数据和方法的机制

多态性:

一个名字具有多种语义

封装:

将属性和操作包装成一个单元,使得对状态的访问和修改只能通过封装提供的接口进行

消息:

对象间在交互中所传送的通讯信息

关联:

对象之间所存在的联系

7.2模型

对象模型:

即寻找问题域中的对象,从对象中抽象出类的定义,识别对象的内部特征,定义属性,识别对象的外部关系,识别主题。

动态模型:

即建立交互图、状态图和活动图,进一步定义用例。

功能模型:

即用例分析,以用例对用户需求进行规范化描述;

为了更好地理解问题,人们常采用建立建立问题模型的方法。

模型就是为了理解事物而对事物作出的一种抽象,是对事物的一种无歧义的书面描述。

通常,模型由一组图示符号和组织这些符号的规则组成。

模型是一种思考工具,可以把知识规范地表示出来。

对于那些因过分复杂而不能直接理解的系统,特别需要建立模型,建模的目的主要是为了减少复杂性。

一旦建立起模型之后,就要经受用户和各个领域专家的严格审查。

模型常常会经过多次必要的修改。

用OO方法开发软件,通常需要建立3种形式的模型:

对象模型----描述系统数据结构;动态模型----描述系统控制结构;功能模型----描述系统功能;这三种模型各自从不同的侧面反映软件系统的内容,相互影响、相互制约,有机地结合在一起,全面地表达对目标系统的需求。

对象模型表示静态的、结构化的系统的“数据”性质。

描述了系统的静态结构。

面向对象方法强调围绕对象而不是功能来构造系统。

对象模型为建立动态模型和功能模型,提供了实质性的框架。

1997年11月,国际对象管理组织OMG批准把UML1。

1作为基于面向对象技术的标准建模语言。

通常,使用UML的类图来建立对象模型。

在UML中术语“类”的实际含义是,“一个类及属于该类的对象”

-----------------------------------------------

状态模型表示瞬时的、行为化的系统的“控制”性质,它规定了对象模型中的对象的合法变化序列。

一旦建立起对象模型之后,就需要考察对象的动态行为。

所有对象都具有自己的生命周期。

状态,是对对象属性值的一种抽象。

各对象之间相互触发就形成了一系列的状态变化。

一个触发行为称作一个事件。

对象对事件的响应,取决于接受该触发的对象当时所处的状态,响应包括改变自己的状态或者又形成一个新的触发行为。

状态有持续性,它占用一段时间间隔。

状态与事件密不可分,一个事件隔开两个状态,一个状态隔开两个事件。

事件表示时刻,状态表示时间间隔。

UML中用状态图来描绘对象的状态、触发状态转换的事件及对象的行为。

每个类的动态行为用一张状态图来描绘,各个类的状态图通过共享事件合并起来,从而构成系统的动态模型。

动态模型是基于事件共享而互相关联的一组状态图的集合。

-----------------------------------------------

功能模型表示变化的系统的“功能”性质,它指明了系统应该“做什么”,因此更直接地反映了用户对目标系统的需求。

通常,功能模型由一组数据流图组成。

在OO方法中,数据流图远不如在结构化方法中那样重要。

但建立功能模型有助于开发人员更深入地理解问题域,改进和完善自己的设计。

UML中提供的用例图也是进行需求分析和建立功能模型的强有力工具。

UML中把用例图建立起来的系统模型称为用例模型。

使用用例模型代替传统的功能说明,往往能够更好地获取用户需求,它所回答的问题是“系统应该为每个(或每类)用户做什么”。

8面向对象方法、UML:

获取用户需求、画用例图、对象模型、UML中的关系

1.面向对象的方法

(1)分析:

包括问题描述、构建对象模型、构建动态模型、构建功能模型。

最后得到的分析文档包括问题需求的陈述、对象模型、动态模型和功能模型。

(2)系统设计:

结合问题域的知识和目标系统的体系结构,将目标系统分解为子系统,标识由问题所规定的并发性,设计适当的控制机制组织子系统协调工作,然后选择数据管理的基本策略,考虑对边界条件的处理。

最后得到的系统设计文档包括基本的系统体系结构和高层次的决策策略。

(3)对象设计:

以分析模型为基础,首先定义类,设计类属性及操作,为每个操作选择合适的数据结构并定义算法,调整类结构以强化继承性;然后创建对象,设计消息以补充对象关联;通过关联发现新的对象或交互条件时,修改类组织以优化对数据的访问,改善设计结构。

最后得到的对象设计文档包括细化的对象模型、细化的动态模型和细化的功能模型。

(4)实现:

将设计转换为特定编程语言代码并在相应环境运行,同时保持可追踪性、灵活性和可扩展性。

2.UML:

统一建模语言(UML)是一个通用的可视化建模语言,用于对软件进行描述、可视化处理、构造和建立软件系统产品的文档。

UML描述了一个系统的静态结构和动态行为

3.获取用户需求

(1)与用户进行充分沟通,了解用户对软件的需求;

(2)识别对象集合及对象间的关系;

(3)定义类(包括属性和操作)并建立类间的层次关系;

(4)建立模型来表示对象之间的关系及行为特性。

4.用例图:

用例模型描述外部执行者所理解的系统功能。

用例模型用于需求分析阶段,描述待开发系统的功能要求,帮助软件设计人员理解系统要做的工作,同时用例模型还可以为其他模型建立、结构设计、实现及测试工作等提供依据。

一个用例模型是由若干用例图组成的,进行用例建模的过程主要包括寻找执行者、寻找用例、描述用例、确定执行者和用例之间的关系等工作,其中寻找执行者和用例是用例建模的关键。

5.对象模型:

对象模型表示静态的、结构化的系统的“数据”性质。

描述了系统的静态结构。

面向对象方法强调围绕对象而不是功能来构造系统。

对象模型为建立动态模型和功能模型,提供了实质性的框架。

通常,使用UML的类图来建立对象模型。

在UML中术语“类”的实际含义是,“一个类及属于该类的对象”

6.关系:

依赖

关联

泛化

实现

9测试:

黑盒、白盒设计测试用例

9.1白盒测试(结构测试、逻辑驱动测试):

9.1.1语句覆盖:

设计若干个测试用例,使得被测试的程序中的每条可执行语句至少被执行一次

9.1.2判断覆盖:

每个判断至少都获得一次“真”值和“假”值

9.1.3条件覆盖:

每个判断中的条件可能的取值至少被执行一次

9.1.4判断与条件覆盖:

每个判断的真假值分支至少被执行一遍,并且每个判断的条件的内部判断式的真假值分支也要被执行一遍

9.1.5条件组合覆盖:

程序中每个判断条件的内部判断式的各种真假值组合可能都至少执行一遍

9.1.6路径覆盖:

覆盖程序中所有可能的路径

9.1.7六种逻辑覆盖从弱到强的排列顺序

语句覆盖-à判断覆盖-à条件覆盖--à判断条件覆盖à条件组合覆盖--à路径覆盖

9.2黑盒测试

9.2.1等价类划分:

有效等价类和无效等价类

9.2.2边界值分析

10软件项目管理:

项目管理、五大过程、九大知识领域、项目三角形

项目管理:

是为完成一个预定的目标,而对任务和资源进行规划、组织和管理的程序

项目三角形:

时间:

反映在项目计划中的项目完成所需时间。

资金:

即项目的预算,取决于资源的成本,这些资源包括完成任务所需的人员、设备和材料。

范围:

项目的目标和任务,以及完成这些目标和任务所需的工时。

项目管理的五大过程:

启动过程、计划过程、实施过程、控制过程、收尾过程

项目管理的九大知识领域:

范围管理、时间管理、成本管理、质量管理、风险管理、人力资源管理、沟通管理、采购管理、综合管理

11配置管理:

配置管理、配置管理项、基线、里程碑

配置管理:

是一组追踪和控制活动,它们开始于软件项目开始时,结束于软件被淘汰之时。

配置管理项:

1。

计算机程序----源代码和可执行程序2。

描述计算机程序的文档----供技术人员或用户使用3。

数据----程序内包含的或在程序外的。

每个配置项的主要属性有名称、标识符、文件状态、版本、作者、日期等

基线:

是一组配置项,这些配置项不能被随便修改和变更。

基线是软件生存期中各开发阶段末尾的特定点,又称里程碑。

软件开发各阶段的基线:

12结构化方法与面向对象方法的比较:

基本思想;分阶段比较

1.结构化方法:

基本思想:

可以概括为自顶向下、逐步求精,采用模块化技术和功能抽象将系统按功能分解为若干模块,从而将复杂的系统分解成若干易于控制和处理的子系统,子系统又可分解为更小的子任务,最后的子任务都可以独立编写成子程序模块,模块内部由顺序、选择、循环等基本控制结构组成。

2.面向对象方法

基本思想:

面向对象方法的出发点和基本原则,是尽可能模拟人类习惯的思维方式,使开发软件的方法与过程尽可能接近人类认识世界、解决问题的方法与过程,将客观世界中的实体抽象为问题域中的对象。

使用现实的概念抽象地思考问题,从而自然地解决问题,保证软件系统的稳定性和可复用性以及良好的维护性。

3.两种方法的比较:

传统的结构化方法,是软件工程中最为成熟的方法。

对于能够预先确定需求的系统的开发,采用结构化方法非常有效,但是对于需求是模糊的或随时间变化的系统开发这种方法不能适应。

面向对象方法,对于需求不能预先确定的系统的开发,可采用面向对象方法结合,这样就能够结合面向对象方法所具有的稳定性好、可复用性好和可维护性好的特点。

需求分析阶段:

结构化方法:

采用自顶向下功能分解的方法,强调逻辑功能而不是实现功能的具体方法,使用图形进行系统分析并表达分析的结果--数据流图,使用结构化分析方法获得的需求规格说明书由数据流图、数据词典及补充材料组成。

面向对象方法:

面向对象分析的关键是识别出问题域中的对象,并分析它们之间的关系,最终建立起问题域的简洁、精确、可理解的正确模型。

面向对象分析模型通常包括对象模型、动态模型和功能模型。

对象模型是最重要、最基本、最核心的。

设计阶段:

结构化软件是功能的集合,通过模块调用实现系统。

面向对象软件是事物的集合,通过对象及联系实现系统。

结构化软件=过程+数据,以过程为中心。

面向对象软件=数据+相应操作,以数据为中心。

结构化软件采用顺序处理方式,由过程驱动控制;面向对象软件采用交互式、并行处理方式,由消息驱动控制;结构化方法的重点是设计;面向对象方法的重点是分析。

结构化方法更适合数据类型比较简单的软件项目的开发;面向对象方法更适合大型复杂的软件项目的开发

练习题:

1.看书上实例A,理解RUP过程

2.试讨论RUP过程的优缺点

3.RUP过程主要适用于何种项目?

4.用面向对象方法开发软件时与结构化方法开发软件时相比较,软件的生命周期有何不同?

这种差异带来了什么后果?

5.为什么说广州本田牌汽车是小汽车类的特化,而发动机不是小汽车类的特化?

6.什么是对象?

它与传统的数据有何区别?

7.试用面向对象分析方法设计下述程序:

8.在显示器屏幕上圆心坐标为(100,100)的位置画一个半径为40的圆,在圆心坐标为(200,300)的位置画一个半径为20的圆,在圆心坐标为(400,150)的位置画一条弧,起始角为30度,结束角度为120度,半径为50.

9.思考题1、一个程序能够既正确又不可靠吗?

请解释你的答案。

软件可靠性是程序在给定的时间间隔内按规格说明书的规定成功地运行的概率。

软件可靠性即包含正确性又包含健壮性。

即程序在正常环境下应能正确地完成预期功能,在意外环境下,也应能作出适当的响应。

如果某程序在正常环境下可正常运行,在异常环境下不能作出适当的响应,则该项程序就是既正确又不可靠

思考题2、为什么在开发软件的过程中变化既是必要的又是不可避免的?

为什么必须进行配置管理?

在软件开发过程中,下述原因会导致软件配置项发生变化,新的市场条件导致需求或业务规则变化,客户的需求也会或多或少地发生变化。

企业改组或业务缩减,引起项目优先级或软件工程队伍结构变化,预算或进度限制,导致对目标系统的重新定义,发现了前期阶段的错误,必须加以改正。

因此,在开发软件的过程中,变化既是必要的,又是不可避免的。

如果不能适当地控制和管理变化,势必造成混乱并产生许多严重的错误。

软件配置管理是在软件的整个生命期内管理变化的一组活动,可以认为软件配置管理是应用于整个软件生命期的软件质量保证活动,是专门用于管理变化的软件质量保证活动,软件配置管理的目标是使变化更正确且更容易被适应,在必须变化时减少所需花费的工作量,综上所述,进行配置管理是十分必要的

3、某些软件工程师不同意“目前国外许多软件开发组织把60%以上的人力用于维护已有的软件”的说法。

他们争论说:

“我并没有花费我的60%的时间去改正我所开发的程序中的错误”。

请问,你对上述争论有何看法?

答:

软件维护并非仅仅是改正程序中的错误,它还包括适应性维护、完善性维护和预防性维护。

纠错性维护只占维护活动总量的1/5,“目前国外许多软件开发组织把60%以上的人力用于维护已有的软件”,指的是软件开发组织内人力分配的整体状况。

至于具体到软件组织内的每一位工程师,则分工各不相同。

(专职维护、专职开发、兼职维护和开发)软件维护人叫并非只负责维护自己开发的程序,一名维护人员通常会参与多个软件产品的维护工作

思考题4、假设你的任务是对一个已有的软件做重大修改,而且只允许你从下述文档中选取两份:

(1)程序的规格说明

(2)程序的详细设计结果(自然语言描述加上某种设计工具表示)

(3)源程序清单(其中有适当数量的注释)

你将选取哪两份文档?

为什么这样选取?

答:

“对一个已有的软件做重大修改”意味着对软件功能做较大变更或增加较多新功能,这往往需要修改软件的体系结构。

规格说明书描述了系统的数据要求、功能需求、性能需求、可靠性、可用性、异常处理、接口需求、约束等内容。

对了解系统的总体情况很重要。

因此在对已有软件做重大修改之前,需要仔细研究这份文档。

避免许多修改可能产生的错误。

应该选取。

有经验的软件工程师通过阅读含有适当数量注解的源程序,不难搞清程序的实现算法。

没有详细设计结果的文档并不会给维护工作带来太大困难。

为了修改程序代码,源程序清单是必不可少的。

因此为了对程序做重大修改,应该选取的第二份文档是源程序清单。

思考题5某软件公司拟采取下述措施提高他们所开发的软件产品的可维护性。

请判断哪些措施是正确的?

哪些措施是不正确的?

1、在分析用户需求时同时考虑维护问题

2、测试完程序后,删去程序中的注解以缩短源程序长度

3、在软件开发过程中尽量保证各阶段文档的正确性

4、编码时尽量多用全局变量

2、4错

5、选用时间效率和空间效率尽可能高的算法

6、尽可能利用硬件特点以提高程序效率

7、尽可能使用高级语言编写程序

8、进行总体设计时加强模块间的联系

9、尽量减少程序模块的规模

10、用数据库系统代替文件系统来存储需要长期保存的信息

11、用CASE环境或程序自动生成工具来自动生成一部分程序

错:

5689

12、尽量用可重用的软件构件来组装程序

13、使用先进的软件开发技术

14、采用防错程序设计技术,在程序中引入自检能力

15、把

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 幼儿教育 > 幼儿读物

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2