您现在的位置是:首页 >其他 >【软考笔记】10. 软件工程网站首页其他

【软考笔记】10. 软件工程

Ranye123 2024-05-31 12:00:03
简介【软考笔记】10. 软件工程

软件开发模型

瀑布模型 SDLC

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bR18KukG-1683373444331)(/assets/瀑布模型.png)]

缺点:需求阶段难以把控

运用瀑布模型的场景:

  1. 需求明确
  2. 二次开发

原型模型,演化模型,增量模型

原型法:在项目开发的初期构造一个简易的系统,如一套界面/初步系统,然后跟用户沟通调整,针对需求不明确的情况

用于 需求分析 阶段

演化模型原型 通过演化调整最终形成软件
增量模型原型 + 瀑布模型,先做核心模块,给用户看,在这个基础上慢慢加其他模块,风险较小

螺旋模型

螺旋模型原型 + 瀑布模型 + 演化模型

考试时,需求不明确的项目,让选择模型,备选项有原型模型,也有螺旋模型,虽然螺旋模型包含了原型的思想,仍然选择原型

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dERmEHHD-1683373444332)(/assets/螺旋模型.png)]

特征:引入了 风险分析

V 模型

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-u6le36LN-1683373444332)(/assets/V模型.png)]

特点:强调了测试,对测试进行了细化

需求分析 对应 验收测试、系统测试
概要设计 对应 集成测试
详细设计 对应 单元测试

从需求分析阶段就写验收测试的测试计划,这样就不会在最后才发现需求分析阶段有问题,从头改

喷泉模型

特点:面向对象的模型

  1. 瀑布模型:结构化模型
  2. 喷泉模型:面向对象的模型
    1. 迭代
    2. 无间隙

快速开发模型 RAD

快速开发模型 RAD = 瀑布模型 SDLC + 构件化开发模型 CBSD

特点:能快速构建应用系统

用 VB 等可视化开发就是 RAD

构建组装模型 CBSD

把各过程分别做成标准构建,再组装
把其他项目的模块拿来用

提高复用性 -> 提高开发速度,降低成本,提高可靠性

模块化设计

统一过程 UP 或 RUP

特点:

  1. 用例驱动
  2. 以架构为中心
  3. 迭代与增量
    1. 每走一个循环有一个增量

初始:选架构
细化:完成架构
构建:组装构件(构件库里拿的),开发剩余构件(构件库里没有的)
交付:进行 β eta β测试(由用户做测试)

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NY8gtziM-1683373444332)(/assets/统一过程模型.png)]

敏捷开发方法

减去不必要的文档和流程

适用于小型项目

信息系统开发方法

结构化法

工程化,文档标准化

缺点:不灵活

结构化设计

概要设计

详细设计

结构化设计的原则

  1. 自顶向下,逐步求精
  2. 信息隐蔽:函数里的内容不展示在外界,只展现接口
  3. 模块独立:高内聚,低耦合,复杂度

详细的

  1. 模块大小适中
  2. 调用深度少
  3. 多扇入,少扇出:入度高,出度低
    1. 入度:别的模块用自己多,说明价值高,好
    2. 出度:调用其他模块越多,说明模块自身职能多,不好
  4. 单入口,单出口
  5. 模块的作用域应在模块之内

内聚与耦合

掌握内聚和耦合的排序

从上到下内聚程度越来越低,耦合程度越来越高

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VotfnJat-1683373444333)(/assets/内聚与耦合.png)]

系统模块结构

传入型模块:向变换控制模块传入信息的模块
传出型模块:变换控制信息传出信息给到的模块
变换型模块:既有传入,又接收传出

原型法

适用于需求不明确的开发

面向对象方法

将系统设计到的物,抽象成对象
有更强的复用性

面向服务方法

三层:操作,服务,业务流程

需求工程

需求的分类

业务需求

明确这个系统总体是干啥的

用户需求

收集各角色的用户希望系统有哪些功能

系统需求

将用户需求转成能指导开发的需求

功能需求

性能需求(非功能需求)

如响应时间,安全性,可靠性

设计约束

既非功能需求也非性能需求,如客户要求用自主研发的数据库

从 QFD 的角度分类

基本需求

用户提出来的需求

期望需求

用户虽然没说,但觉得理所应当要达成的需求

兴奋需求

超越用户预期的需求,程序员要尽量规避

软件测试

测试的原则:

  1. 尽早,不断测试
  2. 程序员避免测试自己设计的程序
  3. 既要选择有效,合理的数据,也要选择无效,不合理的数据
  4. 修改后应进行回归测试
    1. 回归测试:重新测之前测过的模块
    2. 修正一个 bug 会引入新的 bug
  5. 尚未发现的错误数量与已发现的错误数成正比
    1. 例:A 模块发现了 30 个 bug,B 模块发现 100 个 bug,后续要着重测试 B 模块

测试的分类

动态测试

用到计算机的测试

黑盒测试法

只知道输入某参数应该输出什么结果,不知道内部结构

  1. 等价类划分
    1. 例:成绩管理系统,>=90 分为优,>=60 分为及格,选择 95 分和 80 分进行测试
  2. 边界值分析
    1. 例:成绩管理系统,>=90 分为优,>=60 分为及格,选择 89 90 91 59 60 61 分进行测试
    2. 边界值就是正好边界的值,加上比边界稍小一点的,再加上比边界稍大一点的
  3. 错误推测法:强调经验,灵感
  4. 因果图:通过问题反推原因

白盒测试法

知道内部结构

着重了解逻辑覆盖测试

  1. 基本路径测试
  2. 循环路径测试
  3. 逻辑覆盖测试
    1. 语句覆盖:层次最低
      1. 例:if(A>0) f11(); else f12(); if(B>0) f21(); else f22()
      2. 若只测 A>0&&B>0 和 A<=0&&B<=0 两个分支,虽然能完成语句覆盖,但是不全,所以语句覆盖层次最低
    2. 判定覆盖
      1. 例:判定是 A>0,A>0 和 A<=0 的两个分支都要覆盖
    3. 条件覆盖
      1. 例:条件是 A>0&&B<0,A>0,A<=0,B<0,B>=0 的四个分支都要覆盖
    4. 条件判定覆盖:组合条件和判定
    5. 路径覆盖:层次最高,包含了所有可能的情况

灰盒测试法

黑盒+白盒

静态测试

纯人工测试

桌前检查

程序员写完代码之后自己浏览一遍看有没有问题

代码走查

把代码执行一遍测试

代码审查

交叉检查

测试阶段

冒烟测试

取连接完电路,看会不会冒烟之意,冒烟说明电路连的有问题,短路了

是最初步的测试,测试有没有明显的问题

单元测试

测单个模块

集成测试

把多个模块联合起来进行测试,测模块之间的衔接

组装模块的方法

  1. 一次性组装:全装上测
  2. 增量式组装:一点一点装,装一点测一点

确认测试

确认需求是否达成

  1. 内部确认测试
  2. Alpha 测试
    1. 针对产品,项目开发人员接触不到
    2. 在开发环境测试
  3. Beta 测试
    1. 针对产品,项目开发人员接触不到
    2. 在用户本地测试
  4. 验收测试
    1. 用户接受最终产品

系统测试

偏重压力,性能方面,而非功能方面

考点:能区分 负载测试 强度测试 容量测试

  1. 压力测试:在极限值的情况
    1. 例:设计供 1000 人使用的系统,在 100000 人的条件下会不会崩溃
  2. 性能测试
    1. 负载测试
      1. 例:并发 1000 人、2000 人的响应时间
    2. 强度测试:发生异常时候
      1. 例:某资源突然下降,系统能否正常工作
    3. 容量测试

McCabe 复杂度(非常常考)

一个程序的代码可抽象成一个有向图:

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-27A2Xfu0-1683373444333)(/assets/代码抽象为有向图.png)]

有向图 G 的环路复杂度
V ( G ) = m − n + 2 V(G)=m-n+2 V(G)=mn+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 图给出的最早开始时间,事件持续时间,最晚开始时间计算 关键路径

关键路径

从开始到结束节点最长的路径,对应整个项目的 最短工期

耗时最长的项目完成了,其他项目也就都完成了

求最晚开始时间

  1. 正推求所有事件的最早开始时间
    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-MmaaFjY8-1683373444334)(/assets/PERT图%20-%20最早开始时间.png)]
  2. 逆推求所有事件的最晚开始时间
    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-AF7oQVpg-1683373444334)(/assets/PERT图%20-%20最晚开始时间.png)]

风险管理

风险分类

技术风险

由技术因素导致

如:对某技术不熟悉
某技术是新技术,不成熟
某技术过于陈旧

项目风险

项目组没有做好

如:项目组没有控制好成本,使得花的钱超预算
项目组没有制定好计划,使得项目周期延长

商业风险

外部的问题

如:市场不需要该产品

风险曝光度

量化衡量风险是否重要的指标

计算风险曝光度

风险曝光度 = 风险发生的概率 × 风险造成的损失 风险曝光度=风险发生的概率 imes风险造成的损失 风险曝光度=风险发生的概率×风险造成的损失

风语者!平时喜欢研究各种技术,目前在从事后端开发工作,热爱生活、热爱工作。