软考笔记第十天之软件工程

Posted 朴树的扑

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了软考笔记第十天之软件工程相关的知识,希望对你有一定的参考价值。

瀑布模型(SDLC):需求明确的项目

软件计划→ 需求分析→ 软件设计→程序编码→软件测试→运行维护(→循环自己)

技术分享

其他经典模型:

原型:构造一个简易的模型,对应需求不明确的情况

技术分享

增量模型(引进了增量包的概念,无须等到所有需求都出来,只要某个需求的增量包出来即可进行开发)

螺旋模型(加入了风险分析):

技术分享

V模型(测试更加细化;在需求分析的时候写验收测试和系统测试,可以提早发现问题;在概要设计的时候,写集成测试的测试计划;在详细设计的时候,写单元测试的测试计划;

强调测试贯穿于开发的始终)

喷泉模型(面向对象的模型;迭代,无间隙)

RAD(快速开发模型,快速构建应用系统)

技术分享

构件组装模型(CBSD,极大地提高了软件开发的复用性;可靠性强):

需求分析和定义→软件架构设计→构件库的建立→应用软件构建→测试和发布

技术分享

敏捷开发方法(适用于小型项目):

技术分享

信息系统开发方法:

结构化法

原型法

面向对象方法

面向服务方法

方法 特点
结构化法

用户至上

严格区分工作阶段,每阶段有任务和成果

强调系统开发过程的整体性和全局性

系统开发过程工程化,文档资料标准化

自顶向下,逐步分解(求精)

原型法

适用于需求不明确的开发

包括抛弃式原型和演示化原型

面向对象方法

更好的复用性

关键在与建立一个全面、合理、统一的模型

分析、设计、实现三个阶段,界限不明确

面向服务方法

SO方法有三个主要的抽象级别:操作、服务、业务流程

SOAD分为三个层次:基础设计层(底层服务构件)、应用结构层(服务之间的

接口和服务级协定)和业务组织层(业务流程建模和服务流程编排)

服务建模:分为服务发现、服务规约和服务实现三个阶段

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

需求开发:

软件需求分类:

业务需求,用户需求,系统需求→功能需求,性能需求,设计约束

QFD:基本需求,期望需求,兴奋需求(不该做)

获取方法:收集资料,联合需求计划,用户访谈,书面调查,情节串联板,现场观摩,参加业务实践,阅读历史文档,抽样调查

技术分享

结构化设计:

(概要设计,详细设计)→(自顶向下、逐步求精;信息隐蔽;模块独立[高内聚,低耦合,复杂度])

保持模块的大小适中

尽可能减少调用的深度

多扇入,少扇出

单入口,单出口

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

功能应该是可预测的

技术分享

内聚与耦合

内聚类型 描述
功能内聚 完成一个单一功能,各个部件协同工作,缺一不可
顺序内聚 处理元素相关,而且必须顺序执行
通信内聚 所有处理元素集中在一个数据结构的区域上
过程内聚 处理元素相关,而且必须按特定的次序执行
瞬时内聚(时间内聚) 所包含的任务必须在同一时间间隔内执行
逻辑内聚 完成逻辑上相关的一组任务
偶然内聚(巧合内聚) 完成一组没有关系或松散关系的任务

 

 

 

 

 

 

耦合类型 描述
非直接耦合 两个模块之间没有直接关系,它们之间的联系完全是通过主模块的控制和调用来实现的
数据耦合 一组模块借助参数表传递简单数据
标记耦合 一组模块通过参数表传递记录信息(数据结构)
控制耦合 模块之间传递的信息中包含用于控制模块内部逻辑的信息
外部耦合 一组模块都访问同一全局简单变量,而且不是通过参数表传递该全局变量的信息
公共耦合 多个模块都访问同一个公共数据环境
内容耦合

一个模块直接访问另一个模块的内部数据;一个模块不 通过正常入口转到另一个模块的内部;

两个模块有一部分程序代码重叠;一个模块有多个入口

 

 

 

 

 

 

 

 

系统结构/模块结构

(b)需要掌握

技术分享

测试原则与类型:

尽早、不断的进行测试

程序员避免测试自己的程序

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

修改后应进行回归测试

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

动态测试(利用到计算机)→黑盒测试法,白盒测试法,灰盒测试法

静态测试(纯人工)→桌前检查,代码走查,代码审查

 

黑盒测试→等价类划分,边界值分析,错误推测,因果图

白盒测试→基本路径测试,循环覆盖测试,逻辑覆盖测试[语句覆盖(最低级别),判定覆盖,条件覆盖,条件判定覆盖,修正的条件判断覆盖,条件组合覆盖,点覆盖,边覆盖,路径覆盖(最高级别)]

技术分享

 

测试阶段

 

技术分享

McCabe复杂度

计算有向图G的环路复杂度公式为:V(G)=m-n+2.

其中V(G)是有向图G中的环路个数,m是G中的有向弧数,n是G中的节点数。

技术分享

 

系统运行与维护

软件维护是生命周期的一个完整部分。可以将软件维护定义为需要提供软件支持的全部活动,这些活动包括在交付前完成的活动,以及交付后完成的活动。交付前完成的活动包括交付后运行的计划和维护计划等;交付后的活动包括软件修改、培训、帮助资料等。

可维护性(易分析性,易改变性,稳定性,易测试性)

维护类型(改正性维护(用户找到Bug,去修复,25%),适应性维护(操作系统的环境,数据环境20%),完善性维护(改善性能50%),预防性维护(5%))

技术分享

软件过程改进-CMMI

阶段式→组织能力成熟度

成熟度等级 过程域
已管理级

需求管理、项目计划、配置管理、项目监督与控制、供应商合同管理、

度量和分析、过程和产品质量保证

已定义级

需求开发、技术解决方案、产品集成、验证、确认、组织级过程焦点、

组织级过程定义、组织级培训、集成项目管理、风险管理、集成化的团队、

决策分析和解决方案、组织级集成环境

定量管理级 组织级过程性能、定量项目管理
优化级 组织级改革与实施、因果分析和解决方案

 

 

 

 

 

 

 

 

连续式→软件过程能力

连续式分组 过程域
过程管理 组织级过程焦点、组织级过程定义、组织级培训、组织级过程性能、组织级改革与实施
项目管理

项目计划、项目监督与控制、供应商合同管理、集成项目管理、风险管理、集成化的团队、

定量项目管理

工程 需求管理、需求开发、技术解决方案、产品集成、验证、确认
支持

配置管理、度量和分析、过程和产品质量保证、决策分析和解决方案、组织级集成环境、

因果分析和解决方案

 

 

 

 

 

 

 

技术分享

 

项目管理

九大知识邻域

范围管理

时间管理(考)

成本管理

质量管理

人力资源管理

沟通管理

风险管理(考)

采购管理

整体管理

例:

技术分享

风险是指"损失或伤害的可能性"    关心未来、关心变化、关心选择

分类:

项目风险

技术风险

商业风险

风险曝光度(Risk Exprosure):计算方法是风险出现的概率乘以风险可能造成的损失。

假设正在开发的软件项目可能存在一个未被发现的错误,而这个错误出现的概率是0.5%,给公司造成的损失将是1000000元,那么这个错误的风险曝光度就应为1000000*0.5%=5000元

 

以上是关于软考笔记第十天之软件工程的主要内容,如果未能解决你的问题,请参考以下文章

软考笔记第八天之法律发规与标准化知识

软考中级网络工程师全面学习笔记第2版(5万字)+配套视频及课件

软考《希赛教育·软件设计师考前冲刺与考点分析》计算机硬件基础知识——学习笔记

软考中级软件设计师笔记

软考高级之制定备考计划

(软考笔记) ——系统架构设计师 - 软件架构设计笔记