第一章 软件工程概述
1.1 软件的概念与特点
- 软件是开发的或者是工程化的,而不是制造的
- 软件生产是简单拷贝,而不是重复开发
- 软件产品易于多次修改,且总是要求修改
- 软件开发的环境对产品影响较大
- 软件开发的时间和工作量难以估计
- 软件开发进度难以客观衡量
- 软件的测试非常困难
- 软件不会磨损和老化,但会退化
- 软件维护不是简单更换元器件,变更容易产生新的问题
- 一方面是一种产品
- 提供计算能力
- 产生、管理、获取、修改、显示或传输信息
- 另一方面是开发其他软件产品的工具
- 支持或直接提供系统所需的功能
- 控制其他程序(如操作系统)
- 改善通信(如网络软件)
- 帮助开发其它软件(如软件开发工具)
- 其它功能……
个体化 -> 作坊式 -> 工程化 -> 产业化
1.2 软件危机
在计算机软件的开发和维护过程中所遇到的一系列严重问题。导致效率和质量下降。
|
客观:软件本身特点
- 逻辑部件
- 规模庞大
主观:不正确的开发方法
- 忽视需求分析
- 错误认为:软件开发=程序编写
- 轻视软件维护
1.3 软件工程概念与发展过程
IEEE计算机协会将软件工程定义为:
(1)应用系统化的、学科化的、定量的方法,来开发、运行和维护软件,即,将工程应用到软件。
(2)对(1)中各种方法的研究。
软件工程的7个原则
- 使用阶段性生命周期计划的管理
- 进行连续的验证
- 保证严格的产品控制
- 使用现代编程工具工程实践
- 保持清晰的责任分配
- 用更好更少的人
- 保持过程改进
第二章 软件过程模型
2.1 软件过程的概念
软件过程是在工作产品构建过程中,所需完成的活动、动作和任务的集合。
是软件开发全部过程、活动和任务的结构框架。它能直观表达软件开发全过程,明确规定要完成的主要活动、任务和开发策略。
2.2 常见软件过程模型
2.2.1 瀑布模型 顺序开发
1. 瀑布模型
瀑布模型适用于系统需求明确且稳定、技术成熟、工程管理较严格的场合,如军工、航天、医疗。
2. V模型:瀑布模型的变种
区别:在各自层级上测试和反馈
2.2.2 原型模型 先做个原型看看,通过后,再进行开发
也称为原型化模型、快速原型模型
原型模型的适用场合:客户定义一个总体目标集,但是他们并不清楚系统的具体输入输出;或开发者不确定算法的效率、软件与操作系统是否兼容以及客户与计算机交互的方式。
2.2.3 增量模型 做一点,发布一点
增量:满足用户需求的一个子集,能够完成一定功能、小而可用的软件
适用于软件开发中需求可能发生变化、具有较大风险、或者希望尽早进入市场的项目。
2.2.4 螺旋模型 做一点,评估一下,改一下
开发活动和风险管理结合起来控制风险
模型结合了瀑布模型和原型模型的特点
适用于需求不明确或者需求可能发生变化的大型复杂的软件系统。
支持面向过程、面向对象等多种软件开发方法,是一种具有广阔前景的模型。
2.2.5 喷泉模型 (了解)
2.2.6 基于构件的开发模型(了解)
考虑的焦点是集成,而非实现
构件/组件(Component)
– 系统中模块化的、可更换的部分
– 实现特定的功能
– 对实现进行封装,暴露一组接口
– 例如:动态链接库(.dll),浏览器插件
2.2.7 统一开发模型(了解)
基于面向对象方法学
使用统一建模语言UML
2.2.8 敏捷开发过程 DevOps dddd 扔掉不必要的冗余,快速高效的开干
极限编程:一群人在一起(包括客户)高速开卷
2.3 软件过程模型选择
- 前期需求明确的情况下,尽量采用瀑布模型
- 用户无系统使用经验,需求分析人员技能不足的情况下,尽量借助原型模型
- 不确定因素很多,很多东西无法提前计划的情况下,尽量采用增量模型或螺旋模型
- 需求不稳定的情况下,尽量采用增量模型
- 资金和成本无法一次到位的情况下,可采用增量模型
- 对于完成多个独立功能开发的情况,可在需求分析阶段就进行功能并行,每个功能内部都尽量遵循瀑布模型
- 全新系统的开发必须在总体设计完成后再开始增量或并行
- 编码人员经验较少的情况下,尽量不要采用敏捷或迭代模型
- 增量、迭代和原型可以综合使用,但每一次增量或迭代都必须有明确的交付和出口原则
第三章 需求分析
需求分析的概念
确定系统必须具有的功能和性能,系统要求的运行环境,并且预测系统发展的前景。
换句话说需求就是以一种清晰、简洁、一致且无二义性的方式,对一个待开发系统中各个有意义方面的陈述的一个集合。
需求分析和管理过程
需求确认的步骤:需求获取→需求提炼→需求描述→需求验证
功能模型、数据模型、行为模型。
面向对象的需求分析
用例图(会画)
- 基本元素
- 建立用例模型的顺序是:
- 确定谁会直接使用该系统。这些都是参与者(Actor)。
- 选取其中一个参与者。
- 定义该参与者希望系统做什么,参与者希望系统做的每件事成为一个用例。
- 对每件事来说,何时参与者会使用系统,通常会发生什么,这就是用例的基本过程。
- 描述该用例的基本过程。
- 考虑一些可变情况,把他们创建为扩展用例。
- 复审不同用例的描述,找出其中的相同点,抽出相同点作为共同的用例。
- 重复步骤2~7找出每一个用例。
- 关系:
- 关联(Association) 最普通的那种
- 泛化(Inheritance) 没怎么用过
- 包含(Include)
在包含关系中,在执行基本用例时,一定会执行包含用例部分
- 扩展(Extend) 注意箭头方向,是“加上”的“额外”用例
在扩展关系中,一个基本用例执行时,可以执行、也可以不执行扩展用例部分
- 例题
活动图(会画)
活动图是一种用于描述系统行为的模型视图,它可用来描述动作和动作导致对象状态改变的结果,而不用考虑引发状态改变的事件。
- 基本元素
- 动作状态:圆角矩形
- 初始状态、最终状态 (只有一个开始状态,可以有多个结束状态)
- 并发:
并发指的是在同一时间间隔内,有两个或者两个以上的活动执行。 分叉用来表示将一个控制流分成两个或者多个并发运行的分支,汇合用来表示并行分支在此得到同步。 |
- 条件分支
当控制流遇到分支时,会根据进入条件(布尔值)的真假来判定动作的流向。
分支的每个路径的进入条件应该是互斥的,这样可以保证只有一条路径的转换被激发。
- 泳道
为了对活动的职责进行组织而在活动图中将活动状态分为不同的组,称为泳道 每个活动只能明确的属于一个泳道,泳道明确的表示了哪些活动是由哪些对象进行的。 |
- 控制流和对象流
活动图中交互的简单元素是活动和对象,控制流就是对活动和对象之间的关系的描述。
对象流就是一种特殊的控制流。
- 例题
第四章 软件设计
软件设计相关概念
软件设计定义为软件系统或组件的架构、构件、接口和其他特性的定义过程及该过程的结果。
与设计相关的8个概念
抽象、体系结构、设计模式、模块化、信息隐藏、功能独立、细化、重构。
面向对象的设计
面向对象的系统设计,各自包含哪些设计内容?
类图(会画)
- 类
类是包含信息和影响信息行为的逻辑元素。类的符号是由三个格子的长方形组成,有时下面两个格子可以省略。 |
- 类间关系
- 依赖
一个类A使用到了另一个类B,而这种使用关系是具有偶然性
UML类图画法中依赖是一种使用关系,它说明一个事物规范的变化可能影响到使用它的另一个事务,但反之则不然。依赖关系的表示法是虚线箭头,箭头尾部的元素依赖箭头头部的元素,是use-a的关系。
例:类B作为参数被类A在某个method方法中使用
- 关联
体现的是两个类、或者类与接口之间语义级别的一种强依赖关系
用于描述类与类之间的连接,是has-a的关系。
- 聚合
整体与部分之间是可分离的,他们可以具有各自的生命周期,部分可以属于多个整体对象,也可以为多个整体对象共享
例:汽车和轮子
- 组合
体现整体与部分间的关系,整体的生命周期结束也就意味着部分的生命周期结束
例:人和四肢
- 泛化
子类继承超类或类实现接口
- 实现
- 步骤
- 定义类的属性
- 定义类的操作
- 定义类之间的关系
顺序图(会画)
- 顺序图包含4个元素:对象、生命线、消息、激活
- 对象
参与者和对象按照从左到右的顺序排列
一般最多两个参与者,他们分列两端。启动这个用例的参与者往往排在最左边;接收消息的参与者则排在最右端;
- 生命线
生命线使用垂直的虚线表示 如果对象生命期结束,则用注销符号表示 对象默认的位置在图顶部,表示对象在交互之前已经存在 如果是在交互过程中由另外的对象所创建,则位于图的中间某处 |
- 激活
- 消息
- 消息类型
- 同步消息
- 异步消息(可以不和同步区分,画成 -> 就行)
- 反身消息
- 返回消息
- 例子
第六章 软件质量保证
6.1.软件质量保证相关概念
1. 软件质量
明确表示是否符合功能和性能要求,明确地记载开发标准和所有专业开发软件的期望的隐性特点
- 关键点:
符合明确规定的功能和性能要求
符合明确的开发标准
符合所有软件开发专业的共性、隐性标准,如易用性、可维护性等
2. 软件质量保证(SQA)
遵照一定的软件生产标准、过程和步骤对软件质量进行评估的活动。
3. 软件评审
一个过程或会议期间进行的软件产品的审核,由项目人员、管理人员,用户、客户、用户代表或其他有关各方对一个软件产品进行评论或批准
4. 软件可靠性
是指在给定时间内,特定环境下软件无错运行的概率
6.2 软件测试策略
软件测试策略V模型
同层之间相互对应
1. 单元测试
2. 集成测试
3. 系统测试
4. 验收测试
回归测试可以在所有的测试级别执行,并应用于功能和非功能测试中。
6.3 软件测试技术
1. 软件缺陷
2. 验证与确认
3. 软件测试与软件质量保证
软件测试:找出软件缺陷,并确保修复
软件质量保证:创建、执行改进过程并防止缺陷的标准和方法
4. 质量与可靠性
5. 测试与调试
软件测试:目标是发现软件缺陷的存在
软件调试:目标是定位与修复缺陷
6. 测试用例
是测试输入、执行条件、以及预期结果的集合,是为特定的目的开发的,例如执行特定的程序路径或验证与指定的需求相符合。
主要测试方法:
- 概念:
把测试对象看做一个透明盒子,允许利用程序内部逻辑结构及有关信息,进行测试。
通过在不同点检查程序的状态,确定实际的状态是否与预期的状态一致。
又称为结构测试或逻辑驱动测试。
- 完全测试的困难性:
对一个具有多重选择和循环嵌套的程序,不同的路径数目可能是天文数字。
- 逻辑覆盖
Python |
- 语句覆盖:就是设计若干个测试用例,运行被测程序,使得每一可执行语句至少执行一次。
判断后面的执行语句执行即可:return a
- 分支(判断)覆盖:就是设计若干个测试用例,运行被测程序,使得程序中每个判断的取真分支和取假分支至少经历一次。分支覆盖又称为判定覆盖。
每个判断语句的真和假走一遍: a>b and a<c 是真或假
- 条件覆盖:设计若干个测试用例,运行被测程序,使得程序中每个判断的每个条件的可能取值至少执行一次。
每个判断语句里面的子式的T、F :a>b,T/F ;a<c,T/F
- 条件组合覆盖:设计足够的测试用例,运行被测程序,使得每个判断的所有可能的条件取值组合至少执行一次。
多个判断语句子句排列组合
- 控制流图覆盖测试:是将代码转变为控制流图(CFG),基于其进行测试的技术。
节点覆盖:对图中的每个节点,至少要有一条测试路径访问该节点显然,节点覆盖=语句覆盖
边覆盖:对图中每一个可到达的长度小于(无边图)等于1 的路径,中至少存在一条测试路径覆盖。显然,边覆盖包含节点覆盖,且边覆盖也可以实现分支覆盖。
路径覆盖测试:就是设计足够的测试用例,覆盖程序中所有可能的路径
基本路径覆盖测试:将覆盖的路径数压缩到一定限度内,程序中的循环体最多只执行一次。
- 概念:
测试对象看做一个黑盒子,测试人员完全不考虑程序内部的逻辑结构和内部性
只依据程序的需求规格说明书,检查程序的功能是否符合它的功能说明
又叫做功能测试或数据驱动测试。
- 完全测试的困难性:如果考虑所有可能的输入条件和输出条件中,黑盒测试同样可能是天文数字。
- 等价类划分
- 边界值分析
含义:不运行程序,通过检查和阅读等手段来发现错误并评估代码质量的测试技术
作用:代码标准、质量监控提高可靠性尽早通过源代码检查发现缺陷代码审核定位易产生错误的模块
适用:非常有效的质量保证手段,越来越多地被采用
第八章 软件项目管理
8.1 软件项目管理概念
计划、协调、度量、监控、控制及报告等管理方法在软件开发和维护中的具体应用,以保证整个过程是系统的、有原则的、可量化的
软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成,而对人员(People)、产品(Product)、过程(Process)和项目(Project)进行分析和管理的活动。
软件项目管理的4P要素
8.2.软件度量
软件项目管理的成熟化也需要度量与数字化,目的是持续改进软件过程,并用于项目估算、质量控制、生产率评估等。
软件项目度量的方法
- 面向规模的度量
- 面向功能点的度量
- UFC
UFC = 上述计算值的总和(加权和)
- Fi
|
- 面向对象的度量
- 面向用例的度量
8.3 软件项目估算
概念:项目启动之前,软件团队应该估算将要做的工作、所需要的资源、成本、从开始到完成的时间,也即是对这些内容进行预测
策略:项目度量方法为项目估算提供了依据与有效输入,尽量把估算推迟到项目的后期进行,根据已经完成的项目进行估算
- 在基于问题的分解估算方法中,通过估计最大值、最小值、最可能值的加权平均值作为期望值来估算
- 估计期望值=(最大值+4×最可能值+最小值) / 6
- 例如:如果估计系统X规模的最大值为100KLOC,最小值为50KLOC,最可能值为60KLOC,则其估计期望规模为 (100+4×60+50)/6 = 65KLOC
8.4 项目进度计划
定义:对项目进行任务划分,定义任务之间的依赖关系,并进行时间估算和资源分配,确保以最佳的时间与成本输出满足质量要求的产品。 编制项目计划本质是一个优化问题。 |
项目进度计划的可视化——甘特图
定义:任务网络图是项目所有任务(活动)及其之间逻辑关系(依赖关系)的一个图解表示,并从左到右来表示项目的时间顺序。
作用:
可以分解任务以及各项任务所需要耗费的时间及成本
可以显式的描绘各个任务间的时序依赖关系
关键路径(会找关键路径)
在任务网络图中,从项目开始到项目完成有许多条路径,路径上所有弧权重之和最大的路径(路径最长)叫关键路径。
非关键路径:在整个任务网络图中非最长的路径都叫非关键路径。