2018软考中项高项教材重点之——技术标准规范(

2018软考中项高项教材重点之——技术标准规范(

时间:2020-02-12 17:11 作者:admin 点击:
阅读模式

在软考中项和高项中技术标准都是要考的,而且考试的内容比较杂,所以需要我们多多的了解一下,不能全部得分,但是也不要丢分丢的太多就好。下面来看下软考的技术规范要注意哪些重点吧!

关于标准规范,我们至少需要学4个(是至少)

1、文档管理指南

2、质量特性标准

3、机房工程设计规范

4、软件质量保证规范

1、信息技术软件工程术语GB/T11457—2006(264页,了解)

本标准包含软件工程专用术语定义及缩略词、中文索引、英文索引。

抽象:对某一问题的概括,它抽取与某一特定目标相关的本质内容而忽略其非本质内容。

验收准则:系统或部件必须满足的准则,其目的是使用户、客户或其他授权实体能够予以接受。

验收测试:确定一系统是否符合其验收准则,使客户能确定是否接收此系统的正式测试。

活动:一个过程的组成元素。对基线的变更要经有关机构的正式批准。

活动图:用于对涉及一个或多个类目的进程建模的状态机的一种特例。

适应性:使不同的系统约束条件和用户需求得到满足的容易程度。

关联:规定其实例件连接的多个类目之间的语义联系。

审计:为评估工作产品或工作产品集是否符合软件需求、规格说明、基线、标准、过程、指令、代码以及合同和特殊要求而进行的一种独立检查。

可用性:软件(系统或部件)在投入使用时可操作和可访问的程度或能实现其指定的系统功能的概率。

基线:业已经过正式审核与同意,可用作下一步开发的基础,并且只有通过正式的修改管理管理工程方能加以修改的规格说明或产品。在配置项目生存周期的某一特定时间内,正式制定或固定下来的配置标识文件和这一组这样的文件。基线加上根据这些基线批准批准同意的改动构成了当前配置标识。对于配置管理,有三种基线:功能基线(最初通过的功能配置)、分配基线(最初通过的分配的配置)、产品基线(最初通过的或有条件地通过的产品配置)。

边界值:相应于为系统或部件规定的最小或最大的输入、内部、输出的数据值。

代码审计:由某人、某小组、或借助某种工具对源代码进行的审查,其目的是验证其是否符合软件设计文件和程序设计标准,还可能对正确性和有效性进行估计

代码评审:把软件代码呈现给项目人员、管理人员、用户、客户或其他感兴趣的人员用于评论或批准的会议。

数据字典:软件系统中使用的所有数据项的名字及与这些数据项有关的特性(例如数据项长度、表示等)的集合。

依赖:两个建模元素之间的一种关系,对其中一个建模元素(独立元素)的更改,将影响另一建模元素(依赖元素)。

验证:确定软件开发周期中的一个给定阶段的产品是否达到在上一阶段确立的需求的过程。

确认:在软件开发过程结束时对软件进行评价以确定它是否和软件需求相一致的过程。

测试:通过执行程序来有意识地发现程序中的设计错误和编码错误的过程。测试是验证和确认的手段之一。

软件开发方法:是指软件开发过程所遵循的办法和步骤。软件开发活动的目的是有效地得到一些工作产物,也就是一个运行的系统及其支持文档,并且满足有关的质量要求。

鉴定:是一个正式的过程,通过这个过程决定产品是否符合它的规格说明,是否可在目标环境中适用。

2、软件文档管理指南GB/T-16680—1996(17页,重点掌握)

本标准中,我们可以掌握如下几个知识点:

文档:一种数据及其所记录的数据。具有永久性并可以由人或机器阅读。通常仅用于描述人工可读的内容。比如:技术文档、设计文档、验收文档。

软件文档的作用

1)管理依据:文字载体的计划、绩效报告等资料可以让项目管理者明确的了解项目的进展、存在的问题等,是对项目进行管理控制的依据。

2)任务之间联系的凭证:通常很多软件开发项目由不同的角色、小组去完成不同的任务,各角色、小组之间的相互联系须通过文档资料的复制、分发和引用实现。比如分析员向设计员提供软件需求规格说明书。

3)质量保证:负责质量保证和评估系统性能的人员需要程序规格说明、测试和评估计划、测试该系统的各种质量标准,以及关于期望系统完成什么功能和如何实现这些功能的具体说明;必须制订测试计划和测试规程,并报告测试结果。他们还必须说明和评估安全、控制、计算、检验例行程序及其他控制技术。这些文档的提供可满足质量保证人员和审查人员对上述工作的需要。

4)培训与参考:可以使系统管理员、操作员、管理者和其他相关人员了解系统如何工作,以及如何使用系统。

5)软件维护支持:系统维护人员需参考系统的详细说明,以帮助他们熟悉系统,找出并修正错误,改进系统以适应用户需求的变更或是系统运行环境的变化。

6)历史档案:软件文档可记载系统的开发历程,作为组织过程资产进行保留,便于未来项目的参考复用。

软件文档类型

软件文档可分为开发文档(描述开发过程本身)、产品文档(描述开发过程的产物)、管理文档(记录项目管理的信息)。

1)开发文档是描述软件开发过程,包括软件需求、软件设计、软件测试、软件质量保证的一类文档,也包括软件的详细技术描述(程序逻辑、程序间相互关系、数据格式和存储等)基本的开发文档有:可行性研究和项目任务书;需求规格说明;功能规格说明;设计规格说明,包括程序和数据规格说明;开发计划;软件集成和测试计划。

2)产品文档规定关于软件产品的使用、维护、增强、转换和传输的信息。基本的产品文档包括培训手册、参考手册和用户指南、软件支持手册、产品手册和信息广告。

3)管理文档监理在项目管理信息的基础上,这种文档从管理的角度规定涉及软件生存的信息。比如有开发过程的每个阶段的进度记录、软件变更情况记录、相对于开发的判定记录、职责定义等。

软件文档等级

每个文档的质量必须在文档计划期间就有明确的规定。文档的质量可以按文档的形式和列出的要求划分为四级:具体如下:

1)最低限度文档(1级文档):适合开发工作量低于一个人月的开发者自用程序。该文档应包括程序清单、开发记录、测试数据和程序简介。

2)内部文档(2级文档):可用于在精心研究后被认为似乎没有与其他用户共享资源的专用程序。除1级文档提供的信息外,2级文档还包括程序清单内足够的注释,以帮助用户安装和使用本程序。

3)工作文档(3级文档):适合于由同一单位内若干人联合开发的程序,或可被其他单位使用的程序。

4)正式文档(4级文档):适合那些要正式发行供普遍使用的软件产品。关键性程序或具有重复管理应用性质(如薪酬计算)的程序需要4级文档。4级文档遵守GB8567的有关规定。

文档评审

为了提高软件产品质量,我们可以在对每个软件开发过程中每个阶段形成的文档进行严格的评审,通过评审,可以尽早发现问题,及时采取有效措施进行解决,确保文档内容的正确性,避免或尽可能的减少返工,同时为进入下一阶段的工作做好组织上和技术上的准备。

我们需要重点掌握需求评审和设计评审。无论项目大小或项目管理的正规化程度,需求评审和设计评审是必不可少的。

1)需求评审:进一步确认开发者和设计者已了解用户有什么要求,以及用户从开发者一方了解到的某些限制和评审。在这个阶段(可能需要一次或以上)产生一个被确认的需求规格说明。只有对系统要做些什么,实现什么功能进行了共同

了解并确认认可,才能着手详细设计。其中用户代表必须积极参加开发和需求评审,参与对需求文档的认可。

2)设计评审:主要为概要设计评审和详细设计评审。在概要设计评审过程中,主要详细评审每个系统组成部分的基本设计方法和测试计划。系统规格说明应根据概要设计评审的结果加以修改。详细设计评审主要评审计算机程序和程序单元

测试计划。经过设计评审,最终产生的文档需规定系统和程序将如何设计、开发和测试,以满足一致同意的需求。

另外,对于其他文档的正规评审也是必须的。评审一般是采用评审会的方式进行。评审会的流程大家可以对照本标准进行学习。

文档归档

归档的文件应该是软件生存期内所形成的所有文档,在进行归档时,我们必须遵循以下原则:

归档的文件应该是经过鉴定或是评审的;

文档应签署完整、成套、格式统一、字迹工整;

印制本、打印本及各种报告应该装订成册,而且须按规定进行编号,签署;

而且,文档应在开发过程的每个阶段结束后及时归档。

另外,我们还需要注意文档需要覆盖整个软件生存期,而且是可用和可维护的。

其余几个技术标准比较重要,有需要的小伙伴可以私聊的哦,因为明天不发资料类的文章。