文章目录
软件开发模型
1.瀑布模型—SDLC
- 瀑布模型在过去火爆,但是现在已经淡出大众的视野
在每个阶段的末尾,都会有一个评审工作,并且强调工作的标准化,
但是瀑布模型有一个致命的缺点,导致项目往往不能完成:软件的需求往往难以把控
,尤其是项目初期,需求的不明确导致整个项目方向错误,而且需求改动难以满足,工作量巨大,导致软件项目的失败,导致瀑布模型难以满足软件的开发。
- 瀑布模型应用场景:
- 需求明确
- 二次开发(大部分需求是稳定的)
其他经典模型
增量模型、原型法
-
用户在初期很难确定需求(用户和人员之间有隔阂–>用户懂业务,开发人员懂技术)
-
原型法:先做出一个界面或者是一个简易的系统出来给用户,让他改需求针对需求不明确的情况,如果需求非常明确,可以用瀑布模型or其他模型
-
演化模型:原型不断升级最后演化为最终的产品
-
增量模型:原型法+瀑布模型
-
在我们做系统的时候先把用户的核心需求做出来,让开发周期大大缩短(周期是原来周期的%20左右)
然后逐步对其他增加功能进行开发,到最终完成所有的内容
-
优点:核心内容比较早的和用户进行了接触,每一次将项目交给用户区看的时候,都再一次对项目进行了审视,风险较小
-
螺旋模型
-
特征:螺旋模型融合了多种模型,所以多个模型的特点,螺旋模型都具备
在用户需求不明确的情况下,原型法的优先级大于螺旋模型的优先级
- 风险分析:是螺旋模型最为显著的特点!
V模型
- V模型和瀑布模型和接近,但是V模型更加看重测试(单元测试、集成测试、系统测试、验收测试)
- V模型的缺点:测试压的太后了,当发现了错误,更改的成本比较高
V模型边设计,一遍编写测试文档,这样就可以减少开发时发生的错误
喷泉模型
- 特征:面向对象、迭代、无间隙,是面向对象的模型
RAD—快速开发模型
- 假如我们使用可视化工具进行开发,就算是RAD开发了
构建组装模型(CBSD)
-
我们把各个阶段开发过程做成标准的构件,最后将构件进行组装就得到了最终需要的软件
-
特征:极大的提高了软件开发的复用性,使得软件开发的总时长降低,成本降低,还可以使软件的可靠性增加
一些我们以前在其他系统总进行开发的构件可以直接挪用过来,而这些构件已经经过了很长时间的验证,可靠性比较高
统一过程(UP)
特点:
- 用例驱动
- 挖掘需求发现一些用例,然后实现这些用例,用例作为指导测试用例的开发依据
- 以架构为中心
- 先把架构设计好,设计好架构,在向里面添加构件
- 迭代和增量
- 每完成一个循环,就会有增量要做
β测试:软件在用户环境里进行测试
α测试:开发环境里进行测试
在测试有问题的部分在下一个周期进行修正,统一过程经过多伦的循环迭代才产生最终的产品
敏捷开发方法
敏捷开发方法的基本思想:减去没有必要的开发流程,减少开发人员的负担
一种轻量级的开发方法
敏捷开发方法是一个方法,而是多个方法的集合:
- 自适应方法
- 水晶方法
- 特征驱动方法
- SCRUM
- 极限编程
- 适合于开发小型项目,不适合大中型
信息系统开发方法
-
结构化方法(面向过程)
- 用户至上
- 严格区分工作阶段,每个阶段有任务和成果
- 强调系统开发过程的整体性和全局性
- 系统开发过程化,文档资料标准化
- 自顶向下,逐步分解
- 缺点:难以维护,升级,修改困难
-
面向对象方法
- 复用性好
- 关键在于建立一个全面、合理、统一的模型
- 缺点:分析、设计、实现三个阶段,界限不明确
需求工程
1、业务需求:先分析当前业务、考虑功能、系统的大致功能
2、用户需求:询问相关业务的角色,进行沟通,根据反馈获取需求和相应的功能
3、系统需求:计算机化、能够开发的需求
系统需求:
- 功能需求
- 性能需求:相应时间、安全性、可靠性
- 设计约束:用户在软件设计时对开发提出的一定要求(语言要求、数据库类型…)
QFD需求:
-
基本需求:必须完成的需求
-
期望需求:用户认为理所应当达到的需求
-
兴奋要求:锦上添花,超出客户期望(谨慎)
结构化设计
特点:
- 自顶向下、逐步求精
- 信息隐蔽:函数内部信息不向外部展现
- 模块独立:高内聚、低耦合
内聚指标:(尽可能高)
内聚程度最大的是功能内聚,最小的是巧合内聚
耦合指标:
内容耦合程度最高,非直接耦合程度最低
原则:
-
多扇入,少扇出:
被其他模块调用的多,而少调用其他模块(入度高、出度小)
三种模块结构
软件测试
- 测试应该尽早、不断的测试
- 程序员要避免测试自己的设计的程序
- 即要选择有效、合理的数据,也要选择无效、不合理的测试
- 修改后应该进行回归测试
- 尚未发现的错误数量与该程序已发现的错误数成正比(修改后将以前发现的错误也测试一下)
动态测试:利用到计算机进行测试
静态测试:纯人工测试
测试用例设计
黑盒测试(内部结构未知)
- 等价类划分
- 边界值分析
- 错误推测:经验分析
- 因果图:由结果分析原因
白盒测试(内部结构已知)
- 基本路径测试
- 循环覆盖测试
- 逻辑覆盖测试
软件测试–McCabe复杂度
有向图的环路复杂度公式:
V(G) = m-n+2
系统运行与维护
维护阶段是软件周期中时间最长的
可维护性:
- 可分析性:代码的规范程度高
- 易改变性:修改一段代码的容易程度(低耦合比较好)
- 稳定性
- 易测试性:测试的时候要做回归测试
维护类型:
- 改正性维护–25%
- 适应性维护–20%(升级、适应操作系统升级)
- 完善性维护–50%在系统的运行过程中,对系统的性能、功能进行升级
- 预防性维护–5%做一些预防性的工作,方便日后维护
软件过程改进–CMMI
CMMI是能力成熟度的集成
CMMI分为阶段式和连续式,对项目的评价、分类
- 阶段式
-
混乱级
-
已管理级–>基本的管理
-
已定义级 -->隐形的知识转化为显性
-
定量管理级—>量化
-
优化级–>持续的优化
-
连续式
项目管理
九大知识领域
-
时间管理
- Gannt图(图结构显进度、计划):不能清晰的表达任务之间的逻辑关系,但是可以清晰看出任务之间的并行性、任务进度等
- PERT图可以只管的看到书屋之间的逻辑、先后关系
-
风险管理
-
项目风险:
项目没控制好,导致成本增加
-
技术风险:
新技术不成熟、旧技术太缓慢
-
商业风险:无法控制的风险(无法通过项目管理来控制)
(风险期望)