您现在的位置是:首页 >其他 >【软考笔记】10. 软件工程网站首页其他
【软考笔记】10. 软件工程
软件开发模型
瀑布模型 SDLC
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bR18KukG-1683373444331)(/assets/瀑布模型.png)]
缺点:需求阶段难以把控
运用瀑布模型的场景:
- 需求明确
- 二次开发
原型模型,演化模型,增量模型
原型法:在项目开发的初期构造一个简易的系统,如一套界面/初步系统,然后跟用户沟通调整,针对需求不明确的情况
用于 需求分析
阶段
演化模型
:原型
通过演化调整最终形成软件
增量模型
:原型
+ 瀑布模型
,先做核心模块,给用户看,在这个基础上慢慢加其他模块,风险较小
螺旋模型
螺旋模型
:原型
+ 瀑布模型
+ 演化模型
考试时,需求不明确的项目,让选择模型,备选项有原型模型,也有螺旋模型,虽然螺旋模型包含了原型的思想,仍然选择原型
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dERmEHHD-1683373444332)(/assets/螺旋模型.png)]
特征:引入了 风险分析
V 模型
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-u6le36LN-1683373444332)(/assets/V模型.png)]
特点:强调了测试,对测试进行了细化
需求分析 对应 验收测试、系统测试
概要设计 对应 集成测试
详细设计 对应 单元测试
从需求分析阶段就写验收测试的测试计划,这样就不会在最后才发现需求分析阶段有问题,从头改
喷泉模型
特点:面向对象的模型
- 瀑布模型:结构化模型
- 喷泉模型:面向对象的模型
- 迭代
- 无间隙
快速开发模型 RAD
快速开发模型 RAD = 瀑布模型 SDLC + 构件化开发模型 CBSD
特点:能快速构建应用系统
用 VB 等可视化开发就是 RAD
构建组装模型 CBSD
把各过程分别做成标准构建,再组装
把其他项目的模块拿来用
提高复用性 -> 提高开发速度,降低成本,提高可靠性
模块化设计
统一过程 UP 或 RUP
特点:
- 用例驱动
- 以架构为中心
- 迭代与增量
- 每走一个循环有一个增量
初始:选架构
细化:完成架构
构建:组装构件(构件库里拿的),开发剩余构件(构件库里没有的)
交付:进行
β
eta
β测试(由用户做测试)
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NY8gtziM-1683373444332)(/assets/统一过程模型.png)]
敏捷开发方法
减去不必要的文档和流程
适用于小型项目
信息系统开发方法
结构化法
工程化,文档标准化
缺点:不灵活
结构化设计
概要设计
详细设计
结构化设计的原则
- 自顶向下,逐步求精
- 信息隐蔽:函数里的内容不展示在外界,只展现接口
- 模块独立:高内聚,低耦合,复杂度
详细的
- 模块大小适中
- 调用深度少
- 多扇入,少扇出:入度高,出度低
- 入度:别的模块用自己多,说明价值高,好
- 出度:调用其他模块越多,说明模块自身职能多,不好
- 单入口,单出口
- 模块的作用域应在模块之内
内聚与耦合
掌握内聚和耦合的排序
从上到下内聚程度越来越低,耦合程度越来越高
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VotfnJat-1683373444333)(/assets/内聚与耦合.png)]
系统模块结构
传入型模块:向变换控制模块传入信息的模块
传出型模块:变换控制信息传出信息给到的模块
变换型模块:既有传入,又接收传出
原型法
适用于需求不明确的开发
面向对象方法
将系统设计到的物,抽象成对象
有更强的复用性
面向服务方法
三层:操作,服务,业务流程
需求工程
需求的分类
业务需求
明确这个系统总体是干啥的
用户需求
收集各角色的用户希望系统有哪些功能
系统需求
将用户需求转成能指导开发的需求
功能需求
性能需求(非功能需求)
如响应时间,安全性,可靠性
设计约束
既非功能需求也非性能需求,如客户要求用自主研发的数据库
从 QFD 的角度分类
基本需求
用户提出来的需求
期望需求
用户虽然没说,但觉得理所应当要达成的需求
兴奋需求
超越用户预期的需求,程序员要尽量规避
软件测试
测试的原则:
- 尽早,不断测试
- 程序员避免测试自己设计的程序
- 既要选择有效,合理的数据,也要选择无效,不合理的数据
- 修改后应进行回归测试
- 回归测试:重新测之前测过的模块
- 修正一个 bug 会引入新的 bug
- 尚未发现的错误数量与已发现的错误数成正比
- 例:A 模块发现了 30 个 bug,B 模块发现 100 个 bug,后续要着重测试 B 模块
测试的分类
动态测试
用到计算机的测试
黑盒测试法
只知道输入某参数应该输出什么结果,不知道内部结构
- 等价类划分
- 例:成绩管理系统,>=90 分为优,>=60 分为及格,选择 95 分和 80 分进行测试
- 边界值分析
- 例:成绩管理系统,>=90 分为优,>=60 分为及格,选择 89 90 91 59 60 61 分进行测试
- 边界值就是正好边界的值,加上比边界稍小一点的,再加上比边界稍大一点的
- 错误推测法:强调经验,灵感
- 因果图:通过问题反推原因
白盒测试法
知道内部结构
着重了解逻辑覆盖测试
- 基本路径测试
- 循环路径测试
- 逻辑覆盖测试
- 语句覆盖:层次最低
- 例:if(A>0) f11(); else f12(); if(B>0) f21(); else f22()
- 若只测 A>0&&B>0 和 A<=0&&B<=0 两个分支,虽然能完成语句覆盖,但是不全,所以语句覆盖层次最低
- 判定覆盖
- 例:判定是 A>0,A>0 和 A<=0 的两个分支都要覆盖
- 条件覆盖
- 例:条件是 A>0&&B<0,A>0,A<=0,B<0,B>=0 的四个分支都要覆盖
- 条件判定覆盖:组合条件和判定
- 路径覆盖:层次最高,包含了所有可能的情况
- 语句覆盖:层次最低
灰盒测试法
黑盒+白盒
静态测试
纯人工测试
桌前检查
程序员写完代码之后自己浏览一遍看有没有问题
代码走查
把代码执行一遍测试
代码审查
交叉检查
测试阶段
冒烟测试
取连接完电路,看会不会冒烟之意,冒烟说明电路连的有问题,短路了
是最初步的测试,测试有没有明显的问题
单元测试
测单个模块
集成测试
把多个模块联合起来进行测试,测模块之间的衔接
组装模块的方法
- 一次性组装:全装上测
- 增量式组装:一点一点装,装一点测一点
确认测试
确认需求是否达成
- 内部确认测试
- Alpha 测试
- 针对产品,项目开发人员接触不到
- 在开发环境测试
- Beta 测试
- 针对产品,项目开发人员接触不到
- 在用户本地测试
- 验收测试
- 用户接受最终产品
系统测试
偏重压力,性能方面,而非功能方面
考点:能区分 负载测试 强度测试 容量测试
- 压力测试:在极限值的情况
- 例:设计供 1000 人使用的系统,在 100000 人的条件下会不会崩溃
- 性能测试
- 负载测试
- 例:并发 1000 人、2000 人的响应时间
- 强度测试:发生异常时候
- 例:某资源突然下降,系统能否正常工作
- 容量测试
- 负载测试
McCabe 复杂度(非常常考)
一个程序的代码可抽象成一个有向图:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-27A2Xfu0-1683373444333)(/assets/代码抽象为有向图.png)]
有向图 G 的环路复杂度
:
V
(
G
)
=
m
−
n
+
2
V(G)=m-n+2
V(G)=m−n+2
V(G):有向图 G 的路径个数
m:有向边数
n:节点数
系统运行与维护
考点:可维护性涉及的方面及维护的类型
可维护性
系统有缺陷,要编码解决
易分析性
易改变性
如果改变一个地方会影响很多模块,这是不好的
易改变性要求代码松耦合
稳定性
易测试性
维护类型
改正性维护
适应性维护
例:原先 windows2000 服务器,升级成 windows2008,系统需要相应维护使得在新环境中正常运行
数据环境发生变化后进行的维护,也是适应性维护的范畴
完善性维护
例:在系统的运行过程中,发现很多东西发生改变,要扩充功能(增加曲线图)、改善现有的性能
考试中,常常将适应性维护中数据环境发生变化的维护,和完善性维护相混淆来选
如果是单纯的加了功能,那就选完善性维护
如果是“为了适应外部市场环境变化”、“为了适应管理需求的改变”而增加功能,选适应性维护
预防性维护
现在不维护也没问题,但是将来可能有问题
闲时做一些文档方面的工作方便将来维护也属于预防性维护
软件过程改进(CMMI)
CMM:能力成熟度模型,衡量开发者改善软件质量的能力
CMMI:对 CMM 的集成和改进
阶段式:评价企业组织能力成熟度
考点:给一段描述,分析这个企业是 CMMI 的几级
一级:混乱级
没有进行 CMMI 认证的企业都属于混乱级
二级:已管理级
项目级:有过项目开发的经验(但是只是企业中的某些个人有,但是企业自身没有形成体系)
三级:已定义级
组织级:企业有一些标准的模板、规范,文档化
标准化
这些模板、规范称为 组织过程资产
个人在做项目的时候,可以把这些资产拿来用,也可以完善这些资产
将隐性的知识转化成显性的
四级:定量管理级
强调管理的 量化
五级:优化级
企业可以进行持续的 优化
连续式:评价软件过程能力成熟度
按照过程域来分,企业可以自行决定哪些方面的能力需要加强来实施
过程管理
项目管理
工程
支持
项目管理
考点 1:时间管理的概念和计算
考点 2:风险管理的概念
时间管理
甘特图(Gantt 图)
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BKOI33wn-1683373444334)(/assets/甘特图.png)]
优点:简单明了
缺点:不能表达任务间的逻辑关系
PERT 图
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KzIffAL5-1683373444334)(/assets/PERT图.png)]
考点:根据 PERT 图给出的最早开始时间,事件持续时间,最晚开始时间计算 关键路径
关键路径
从开始到结束节点最长的路径,对应整个项目的 最短工期
耗时最长的项目完成了,其他项目也就都完成了
求最晚开始时间
- 正推求所有事件的最早开始时间
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-MmaaFjY8-1683373444334)(/assets/PERT图%20-%20最早开始时间.png)] - 逆推求所有事件的最晚开始时间
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-AF7oQVpg-1683373444334)(/assets/PERT图%20-%20最晚开始时间.png)]
风险管理
风险分类
技术风险
由技术因素导致
如:对某技术不熟悉
某技术是新技术,不成熟
某技术过于陈旧
项目风险
项目组没有做好
如:项目组没有控制好成本,使得花的钱超预算
项目组没有制定好计划,使得项目周期延长
商业风险
外部的问题
如:市场不需要该产品
风险曝光度
量化衡量风险是否重要的指标
计算风险曝光度
风险曝光度 = 风险发生的概率 × 风险造成的损失 风险曝光度=风险发生的概率 imes风险造成的损失 风险曝光度=风险发生的概率×风险造成的损失