软考-软件设计师-软件工程基础

  1. 软件生命周期

制定计划、需求分析、设计、编码、测试、运行维护

  1. 软件开发模型(重点)

常见的几种模型:瀑布模型、原型、演化模型、增量模型、螺旋模型、V模型、喷泉模型

(1)瀑布模型(需求明确/二次开发)

适用于需求已经很明确的工程,缺乏灵活性,容易导致完成后才发现问题。

(2)原型、演化模型、增量模型(解决用户需求分析困难)

(1)原型和瀑布模型是互补关系,原型是为了解决用户需求分析难以把控即需求不明确而提出的,该模型即:先做出初步模型,然后让用户使用,以便于用户进一步明确自己的需求,是一种抛弃式的模型,因为需求一旦明确就会被抛弃。

(2)演化模型即是一种渐进式的原型,即它采取原型的设计模式,但不会将其抛弃,而是在此基础上进一步进行设计。

(3)增量模型:是一种递增式设计,将产品一步一步进行设计,每完成一步就交由客户审视,这样也可以使得下一步的设计更为明确。

适用于需求不明确的工程

(3)螺旋模型(强调风险分析,多个原型,需求可以不明确)

包含四个方面的活动:制定计划、风险分析、实施工程、客户评估。

适用于庞大、复杂、高风险的系统

(4)V模型(强调测试,尽早地测试,并贯穿始终)

需求分析完成后就进行验收测试和系统测试,概要设计完成后就进行集成测试。

(5)喷泉模型(面向对象模型:迭代、无间隙)

无间隙就是指在开发活动(分析、设计、编码)之间不存在明显的界限。它不像瀑布模型那样,在需求分析活动结束后才开始设计活动,在设计活动结束后才开始编码活动,而是允许各开发活动交叉、迭代地进行。各阶段没有明显的界限,开发人员可以同步进行。

(6)构件组装模型(CBSD)

该模型将软件开发过程中的各个模块都做成构件,最后再将构件进行组装,基于构件的软件开发,主要强调在构建软件系统时复用已有的软件“构件”,在检索到可以使用的构件后,需要针对新系统的需求对构件进行合格性检验适应性修改,然后集成到新系统中。

(7)统一过程模型(UP)

1.起始阶段:该阶段专注于项目的初创活动(生命周期目标

2.精化阶段:精化阶段在理解了最初的领域范围之后进行需求分析和架构演进(生命周期架构

3.构建阶段:该阶段关注系统的构建,产生实现模型(初始运作功能

4.移交阶段:关注软件提交方面的问题,产生软件增量(产品发布

(8)敏捷开发方法

该方法是一类方法,其特点是快捷,该类方法包括:自适应开发、水晶方法、特征驱动开发、SCRUM、极限编程;他们都遵循一些基本原则和价值观,该类方法适用于做小型项目。

1.极限编程(XP):测试先行、结对编程、集体代码所有制、持续集成(可以按日甚至按小时为客户提供可运行的版本)、每周工作40个小时。

2.并列争求法(scrum):使用迭代的方法,其中把每三十天一次的迭代成为一个冲刺,并按需求的优先级来实现产品,多个自组织和自治小组递增实现产品,并通过简短的日常情况会议进行协调。

3.水晶法(crystal):该方法认为每一个不同的项目都需要一套不同的策略、约定和方法论。

3、软件开发方法

包括四种:结构化法、原型法、面向对象方法、面向服务方法;

结构化方法指导思想是自顶向下、逐层分解,基本原则是功能的分解与抽象。

其中结构化方法的典型代表是瀑布模型,原型法的典型代表是原型和演化模型,目前应用最广的方法是面向对象方法,而面向服务方法尚处于摸索阶段。

4、需求分类

软件需求包括三类:业务需求、用户需求、系统需求;系统需求是用户需求的发展,而系统需求包括功能需求、性能需求、设计约束(即开发语言的选用)

5、结构化设计

面向数据流的结构化设计

包括概要设计和详细设计,其设计原则是:自顶向下、逐步求精,信息隐蔽、模块独立(通过:高内聚、低耦合、复杂度)

内聚:模块内部

耦合:模块之间

5.1、结构化设计的原则

1.保持模块的大小适中

2.尽可能减少调用的深度

3.多扇入,少扇出(上层模块调用自己称之为扇入,自己调用其他模块称之为扇出)

4.单入口,单出口

5.模块的作用域应该在模块之内

6.功能应该是可预测的

5.2、概要设计包括四个项目

  1. 设计软件系统总体结构

基本任务是将系统按功能划分成模块,确定模块功能,确定模块间的调用关系、接口、传递的信息。

  1. 数据结构和数据库设计
  2. 数据结构设计

细化需求阶段已经描述的数据的组成、操作约束、数据之间的关系等方面

  1. 数据库设计

①概念设计:E-R模型既是设计数据库的基础,也是设计数据结构的基础

②逻辑设计:E-R是独立于数据库管理系统(DBMS)的,要结合具体的DBMS的特征来建立数据库的逻辑结构

③物理设计:数据库存储要求、存取方法和索引的建立等

3.编写概要设计文档:文档中应有概要设计说明书、数据库设计说明书、用户手册以及修订测试计划

4.评审

5.3、详细设计

详细设计包括模块内的数据设计、数据库的物理设计、代码设计、输入输出格式设计、用户界面设计、编写详细设计说明书、评审等。

需求分析确定软件要完成的功能及非功能要求,概要设计将需求转化为软件的模块划分,确定模块之间的调用关系;详细设计将模块进行细化,得到详细的数据结构和算法;编码根据详细设计进行代码的编写,得到可以运行的软件,并进行单元测试。

6、软件测试

6.1、基本原则

(1)尽早、不断的进行测试;

(2)程序员避免测试自己设计的程序;

(3)既要选择有效、合理的数据,也要选择无效、不合理的数据;

(4)既要检验程序是否做了该做的事,也要检验是否做了不该做的事;

(5)修改后应进行回归测试;

(6)尚未发现的错误数量与该程序已发现错误数成正比;

6.1、测试过程

(1)制定测试计划:内容、进度、环境、条件等

(2)编制测试大纲:针对系统的每一项功能的测试项目和标准

(3)测试设计说明文档:被测项目、输入数据、测试过程、预期结果

(4)实施测试

(5)生成测试报告:测试结论、缺陷、错误、改进

6.3、测试方法

静态测试和动态测试

静态测试是指程序不在机器上运行,利用人工检测和计算机辅助静态分析的手段对程序进行检测。

人工检测:代码检查、静态结构分析、代码质量度量

计算机辅助静态分析:检查程序逻辑缺陷和可疑程序构造

动态测试:通过运行程序发现错误

  1. 动态测试包括:

黑盒测试:功能测试,即看不到程序内部,只管输入的是什么,输出的是什,针对软件界面和功能测试,主要用于集成测试阶段。

白盒测试:结构测试,从程序结构方面进行测试,检查软件内部的逻辑结构,主要用于单元测试阶段。

灰盒测试:关注输出对于输入的正确性,也关注内部表现,是基于外部表现又结合程序内部逻辑来设计用例、执行程序并采集程序路径执行信息和外部接口结构的测试技术。

(2)静态测试包括:桌前检查、代码走查、代码审查

黑盒测试:

(1)等价类划分:即将程序的输入域划分为若干等价类,从每个等价类中选出一个代表性的数据进行测试即可。

等价类划分原则:

①取值范围或个数,一个有效价类和两个无效价类

②值的集合或“必须”或布尔量,一个有效价类和一个无效价类

③输入数据的一组值,n个有效价类和一个无效价类

④输入数据遵守的规则,一个有效价类(符合规则)和n个无效价类(不同角度违反规则)

注:这类题型喜欢考察不合适的测试用例,输入的条件都是无效等价类的那种就是不合适的,这样的话,要是检测出错误,不知道是哪个条件造成的。

(2)边界值分析:即需要对等价类之间的边界值进行测试(一般是端点、略小于端点的值、略大于端点的值)

(3)错误推测:即自己推测错误的原因,该方法强调经验

(4)因果图:找出输入条件和输出或程序状态的改变

白盒测试:

常用技术是逻辑覆盖、循环覆盖、基本路径测试

(1)逻辑覆盖

逻辑覆盖标准有语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖6种。

①语句覆盖:即程序中的每个可执行语句至少执行一次,覆盖度最低的测试,只管语句,不考虑分支的组合等。

②判定覆盖:不仅每个语句至少执行一次,且所有判断的真假分支都要测试一遍,又称分支覆盖。

③条件覆盖:不仅每个语句至少执行一次,且判定表达式的每个条件的各种值至少满足一次。

④判定/条件覆盖:每个条件的真假至少出现一次,每个判定本身也至少出现一次。

⑤条件组合覆盖:每个判定表达式中条件结果的所有可能组合至少出现一次。

⑥路径覆盖:每条可能执行到的路径都至少经过一次,如果有环路,每条环路至少执行一次,较强的覆盖。

(2)循环覆盖:循环中的每个条件得到验证

(3)基本路径测试:每条可执行语句至少执行一次,所以条件语句的真假都测试一次。

6.4、测试阶段

(1)单元测试:模块性的测试,即对于一个函数,是否达到了其目的,每个模块的功能是否完善。

(2)集成测试:即模块间的衔接测试,不衔接的模块将其组装起来。

①一次性组装(一次全部组装)

②增量式组装(组装两个模块时测试一下、组装到三个模块时再测试一下....)

③冒烟测试

自顶向下:只需要一个驱动,需要桩模块辅助

自底向上:不需要写桩程序,需要驱动模块辅助

(3)确认测试:即对需求进行确认,测试该程序是否满足需求。

测试包括:

①内部确认测试

②Alpha测试(即用户在项目的开发环境进行测试)

③Beta测试(即用户在自己的本地计算机自行测试)

④验收测试

(4)系统测试:主要是压力、性能、可靠性的测试,

性能测试包括:

*负载测试

*强度测试(即系统资源缺失的情况下系统能否正常运行)

*容量测试

压力测试则是测试同时访问人数的极限

注:测试阶段的测试目标来自于需求分析阶段,那时就已经确定了产品的功能。

6.5、软件测试抽象方法

1.演绎法(靠猜推理):从一般性的前提出发,通过推导即“演绎”,得出具体陈述或个别结论的过程

2.归纳法(有素材的推理):以一系列经验事物或知识素材为依据,寻找出其服从的基本规律或共同规律,并假设同类事物中的其他事物也服从这些规律,从而将这些规律作为预测同类事物的其他事物的基本原理的一种认知方式

6.6、软件复杂性度量

McCabe复杂度(必考)

注:这类题通常将程序抽象为有向图,并要求计算环路复杂度。

计算有向图的环路复杂度公式为:V(G)=m-n+2;说明:其中V(G)是有向图G中的环路个数,m是G中的有向弧数(边数),n是G中的节点数(点数)

如上图的环路复杂度为:15-12+2=5

7、系统运行与维护

7.1、软件维护的概念

可维护性:

a易分析性(即代码应该容易看懂)

b易改变性

c 稳定性

d易测试性

维护类型:

a改正性维护(25%):即用户发现bug,然后修改bug

b适应性维护(20%):运行平台版本更迭的问题,应用环境发生变化后修改

c完善性维护(50%):指在运行过程中发现了一些不足,进而对系统的性能等方面进行完善和扩充

d预防性维护(5%):对将来可能导致的问题进行预防工作

重:在判断维护类型的时候,经常把适应性维护和完善性维护搞混淆,一般题目明确指出了环境的改变,就是适应性维护,否则基本上都是完善性维护。

注:系统设计中,人机交互“黄金三原则”包括:置于用户控制之下、减少用户的记忆负担、保持界面的一致性

7.2、软件的质量

(一)ISO/IEC 9126软件质量模型:由3个层次组成,第一层是质量特性,第二层是质量子特性,第三层是度量指标。

1.功能性:适合性、准确性、互用性、依从性、安全性

2.可靠性:成熟性、容错性、易恢复性

3.易用性:易理解性、易学性、易操作性

4.效率:时间特性、资源特性

5.可维护性:易分析性、易改变性、稳定性、易测试性

6.可移植性:适应性、易安装性、一致性、易替换性

(二)Mc Call软件质量模型

Mc Call软件质量模型从软件产品的运行、修正和转移3个方面确定了11个质量特性,它也给了三层模型框架,第一层质量特性,第二层评价准则,第三层度量指标

软件质量保证:

(1)必须满足用户规定的需求

(2)遵循标准开发准则

(3)满足某些隐含需求,如好的可理解性,可维护性

软件评审

1)软件质量评审

①软件规格是否符合用户的要求

②评审可靠性,避免输入错误,硬件软件失效

③评审保密措施实现情况,使用资格,重要数据加密等

④评审操作特性实施情况

⑤评审性能实现情况

⑥评审软件是否具有可修改性、可扩充性、可互换性、可移植性

⑦评审软件是否具有可测试性

⑧评审软件是否具有复用性

2)程序质量评审

①功能结构

* 数据结构

* 功能结构

* 数据和功能结构之间的关系

②功能的通用性

③模块的层次

④模块结构

* 控制流结构

* 数据流结构

* 模块结构和功能结构之前的对应关系

⑤处理过程的结构

3)与运行环境的接口

①与硬件的接口

②与用户的接口

7.3、软件开发工具

1.需求分析工具

2.设计工具

3.编码与排错工具

4.测试工具

7.4、软件维护工具

1.版本控制工具

2.文档分析工具

3.开发信息库工具

4.逆向工程工具

5.再工程工具

6.配置管理支持工具

7.5、软件管理和支持工具

1.项目管理工具

2.配置管理工具(SVN,GIT)

3.软件评价工具

软件配置管理的内容:版本控制、变更控制、过程控制;

8、软件过程能力成熟度模型(CMM)

CMM是一个软件开发团队的评级标准,该评级标准分为了阶段式和连续式两种分组

阶段式

一级为混乱级,即未通过CMMI认证的团队都是该等级

二级为项目级,即对某个具体的项目有相关开发经验和开发能力,但只限于模仿和套用

三级为定义级,该进别下的团队有了自己的改进能力,能对他人的项目提出不同的看法

连续式

CL0(未完成的):过程域未执行或未得到CL1中定义的所有目标

CL1(已执行的):其共性目标是过程将可标识的输入工作产品转换成可标识的输出工作产品,以实现支持过程域的特别目标

CL2(已管理的):其共性目标是已管理的过程的制度化。根据组织级政策规定过程的运作将使用哪个过程,项目遵循已文档化的计划和过程描述,所有正在工作的人都有权使用足够的资源,所有工作任务和工作产品都将被监控、控制、和审评

CL3(已定义级的):其共性目标集中于已定义的过程的制度化。过程是按照组织的裁剪指南从组织的标准过程中裁剪得到的,还必须收集过程资产和过程的度量,并且用于将来对过程的改进

CL4(定量管理的):其共性目标集中于可定量管理的过程的制度化,使用测量和质量保证来控制和改进过程域,建立和使用关于质量和过程执行的质量目标作为管理准则

CL5(优化的):使用量化(统计学)手段改变和优化过程域,以满足客户的改变和持续改进计划中的过程域的功效

CMM软件过程的成熟度划分为5个等级:

①初始级——过程无序,进度、预算、功能、质量等不可预测

②可重复级——有经验,但未行成文档,建立了基本管理制度和规章,制度化,有纪律,可重复

③定义级——文档化,软件生命周期的管理和工程化都实现标准化、项目组、团队

④管理级——量化,定量过程管理,软件质量管理

⑤优化级——优化,软件过程持续改进(预防缺陷,技术变更)

9、项目管理

注:只需要掌握时间管理的概念及计算以及风险管理的概念;

9.1、时间管理

Gantt图:水平条状

可以很清晰地看到任务的开展,何时开始,何时结束,任务的进展情况以及各个任务的并行性。缺点是不能清晰地反映各个任务之间的依赖关系,难确定关键所在,不能反映有潜力的部分。

PERT图:网络模型

可以明确地表达任务之间的依赖关系,即哪些任务完成后才能开始另一些任务,以及如期完成整个工程的关键路径;缺点是不能清晰地描述各个任务之间的并行关系。每一个原型的左侧是事件执行的顺序号,右上角是最早时间,右下角是最晚时间;事件六的最晚开始时间的计算步骤:先从事件1逐步进行推进,如事件1到事件2最早需要时间加2,事件2到事件5则再需要加2(此时最早时间等于4),而事件1到事件6需要的最早执行时间为3,事件4到事件6的最早时间为4,因此取时间长的为事件6的执行时间(原因是事件六的执行需要事件3和4共同作用),以此类推,事件9所需最早时间为15,再由事件9逆推回来15-4-1=10即为事件6的最晚开始时间。

重:关键路径是持续时间最长的路径

9.2、风险管理

1.风险:指“损失或伤害的可能性”,风险可以分为项目风险和技术风险以及商业风险,特点是关心未来、关心变化、关心选择

2.风险曝光度:计算方法是风险出现的概率乘以风险可能造成的损失;风险曝光度常用于风险的管控。

风险曝光度=错误出现率X错误造成损失

风险管理的风险活动:

①风险识别:风险条目检查表

②风险预测:风险的可能性和概率,以及发生后产生的后果

③风险评估:定义风险参考水平值,预测影像参考水平值的风险组合

④风险控制:风险避免、风险监控和管理以及意外事件计划

10、软件项目估算

常用的估算方法有三种:

①基于已经完成的类似项目进行估算

②基于分解技术进行估算(分解技术包括问题分解和过程分解)

③基于经验估算模型(IBM模型、COCOMO模型、Putnam模型)

开发成本估算模型(COCOMO/IBM/Putnam)

1.COCOMO:该模型按其详细程度分为基本、中级、详细;

基本COCOMO:静态单变量模型,用于对整个软件系统进行估算。

中级COCOMO:静态多变量模型,将软件系统模型分为了系统和部件两个层次,系统由部件构成。

详细COCOMO:将软件系统模型分为系统、子系统和模块三个层次。

2. IBM:静态单变量模型

注:COCOMOII模型在模型层次结构中有三种不同的规模估算选择:对象点、功能点和代码行。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值