笔记:学习了软件工程的相关知识
开发模型:
瀑布模型:结构化方法的模型
基本结构:有计划,分阶段进行,每个阶段有评审
软件计划 -> 需求分析 -> 软件设计 -> 程序编码 ->程序测试 -> 软件维护
困难之处:需求阶段在一开始难以确定,适合需求明确,或者二次开发的项目
原型模型:针对于需求不明确
强调在项目初期做一个简易的原型,用户满意后进行开发
仅用于开发的最初阶段
演化模型:
螺旋模型:
由多个模型组合,
引入风险分析,
增量模型:
先做一块,在做一块,每次做完让用户体验,先进行核心功能实现,
V模型
测试占很大的比重,在需求阶段已经在进行验收测试,系统测试的方案,等等,站在项目的测试阶段发现问题,有一个参照物
喷泉模型:面向对象的模型
进行迭代,无间隙
RAD:快速开发模型
VB开发,瀑布模型和构件化开发结合
CBSD:构件组装模型
将做出的东西进行构件化,以后直接使用,大大提高了代码复用程度
统一过程:UP 或 RUP
用例驱动,
以架构为中心
迭代和增量
敏捷开发
基本原则:站立会议,小型版本发布,较少的文档,客户直接参与,中小型项目,快速,简单,适应性计划调整,
信息系统开发方法
结构化法:
用户至上
严格区分每个阶段,每个阶段右任务和成果
强调开发过程中的整体性和全局性
开发工程化,文档标准化
自顶向下,逐步分解
灵活性差,系统和现实差别大
面向对象方法
现实抽象成对象,建立一个模型,具有更好复用性
原型法:
适用于需求不明确的开发
需求开发
需求分类与需求获取
业务需求,用户需求,系统需求 -> 功能需求,性能需求(非公能需求),设计约束
QFD方法分类:
基本需求:客户要求的
期望需求:客户默认有的
兴奋需求:意外之喜
结构化设计
概要设计和详细设计原则:
自顶向下,逐步求精
信息隐藏
模块独立(高内聚,低耦合)
方法:
模块大小适中
尽可能减少调用深度
多扇入,少扇出(多扇入:很多模块复用自己,少扇出:低耦合)
单入单出
软件测试
原则:
尽早,不断进行测试
程序员避免测试自己的程序(不易发现错误)
既要选择有效合理的数据,也要测试无效,不合理的数据
修改后进行回归测试
尚未发现错误的数量和已发现的错误数成正比
类型:
动态测试(利用计算机进行测试):
黑盒测试:细节隐藏,仅知道输入输出,通过输入输出设计用例
具体方法:
等价类划分(将数据进行归总,进行抽取测试),边界值分析(测边界值),错误推测,因果图(由结果推原因)
白盒测试:完全透明,根据程序结构设计测试用例,比黑盒测试覆盖率更高
具体方法:
语句覆盖:所有代码行都进行运行
灰盒测试:黑加白
静态测试(程序员自己进行检查):
测试阶段:
单元测试:测局部的功能,以模块为单位 ->
集成测试:将模块进行衔接进行测试,主要运用两种方法:一次性组装,增量式组装
确认测试:确认需求,进行需求测试
系统测试:对系统的性能,安全性进行测试
冒烟测试:一开始进行测试,发现问题所在
McCabe复杂度
计算方法:有向边 - 节点 + 2
先化成图,在进行计算
软件维护
周期最长,投入使用至不再使用
可维护性:(编码)
可分析性:代码容易分析
易改变性:修改容易,修改后不会影响其他模块
稳定性:
易测试性:
维护类型:
改正性维护:进行修bug
适应性维护:适应不同平台的维护
完善性维护:扩充功能,改变性能
预防性维护:将将来有可能出现错误的进行提前维护
软件过程改进 CMMI
组织能力成熟度
阶段式:
1、混乱级
2、已管理级:需求管理,项目计划等等,仅仅在项目级上有经验
3、已定义级:文档化,标准化
4、定量管理级:管理的量化
5、优化级:进行持续的优化
项目管理
时间管理:
Gantt图:简单明了,不可以表达依赖关系
PRET图:
风险管理:
风险发生的概率、风险造成的损失
分类:
项目风险:项目一级的
技术风险:技术一级
商业风险:超出项目组的控制范畴
风险曝光度:风险发生的概率 * 风险造成的损失(衡量风险优秀关注等级)
标签:需求,10,模块,模型,28,开发,测试,2023,进行 From: https://www.cnblogs.com/JIANGzihao0222/p/17794864.html