软件概论
软件的概念
软件(software):软件是计算机系统中与硬件相互依存的另一部分。它包括程序、数据及其相关文档的完整集合。
能够完成预定功能和性能的可执行指令(program)
使得程序能够适当地操作信息的数据结构(data)
描述程序的操作和使用的文档(document)
软件危机
软件危机定义:软件在开发和维护过程中遇到的一系列严重问题。
如何开发软件。
如何维护数量不断膨胀的已有软件。
软件工程定义、研究内容
软件工程是建立和使用一套合理的工程原则,以便获得经济的软件,这种软件是可靠的,可以在实际机器上高效的运行。
计算机软件的发展、特点和分类
发展
个体化 程序设计阶段:1946—1956
作坊式 程序系统阶段:1956—1968
工程化 软件工程阶段:1968—1981
产业化 市场更加广阔、品类更加丰富:1981—现在
软件发展越来越快,规模越来越大
特点
软件是开发出来的,不是制造出来的
软件是一种逻辑实体,具有抽象性
软件不会磨损和老化
软件的开发和运行常受计算机系统的限制
软件开发的时间和进度难以估计和衡量
软件测试和维护非常困难
分类
按软件功能分
按软件功能:
系统软件(OS—操作系统,数据库管理系统,设置驱动程序,编译程序)
支撑软件(程序库软件,支持需求分许、设计、实现、测试和支持管理的软件,格式化工具)
应用软件(计算机辅助设计/制造软件,系统仿真软件,人工智能软件,计算机辅助教学软件,办公自动化软件)
按服务对象
项目软件(教务管理系统)
产品软件(互联网软件,火车票预订系统)
软件过程模型
软件生存周期
软件产品或软件系统从产生、投入使用到被淘汰的全过程
三个时期
软件定义、软件开发、软件维护
六个阶段
系统工程:问题性定义、可行性研究
需求工程:需求分析
设计工程:系统设计、详细设计
实现工程:编码
测试工程:测试
维护工程:维护
软件过程模型(也叫软件生命周期模型)
传统软件过程模型:
瀑布模型、演化模型、增量模型、原型模型、螺旋模型、喷泉模型、统一过程模型
瀑布模型
优点:降低复杂度、提高透明性和可管理性、强调需求分析和设计、阶段审核和文档输出保证了阶段之间的正确衔接,能够及时发现问题。
缺点:增加工作量、开发风险大、错误推迟发现、不适应需求变化
应用:适用于需求明确且稳定、技术成熟、工程管理较严格的场合,如军工、航天、医疗。
特点:阶段具有顺序性和依赖性、推迟实现、质量保证
演化模型
优点:明确用户需求、提高系统质量、降低开发风险
缺点:管理难度提高、开发结构化较差、可能抛弃文档驱动、可能导致产品结构化较差
应用:需求不清、开发周期短的中小型系统。
增量模型
优点:保障核心功能实现、开发风险较低、保障最高优先级的功能的可靠实现、提高系统稳定性和可维护性。
缺点:增量粒度难以合理选择、确定所有的需求服务较困难
应用:适用于软件开发中需求可能发生变化、具有较大风险、或者希望尽早进入市场的项目
原型模型
优点:构建原型来明确需求、减少需求不明代开的风险
缺点:构建原型技术和工具不一定主流、快速构建起来的系统加上连续的修改可能导致原型质量低下
应用:它适合于那些不能预先确切定义需求的软件系统的开发,更适合于那些项目组成员(包括分析员、设计员、程序员和用户)不能很好交流或通信有困难的情况。
特点:建立反映用户主要需求的系统,反复由用户评价修正需求,开发出最终产品
螺旋模型:
优点:支持用户需求的动态变化、降低风险
缺点:开发周期长
应用:风险较高、开发周期较长的大型软件项目
喷泉模型
优点:提高效率、缩短周期
缺点:管理结构性较差
应用:适用于面向对象开发的项目
现代软件过程模型
基于构件的开发模型
优点:软件复用思想、降低开发成本和风险、提高软件质量、加快软件开发进度
缺点:模型复杂、不能完全符合客户需求、无法控制开发系统的演化
应用:适用于系统之间有共性的情况
统一过程模型
优点:不断的版本发布成为一种团队日常工作的真正驱动力;将发现问题、制定方案和解决过程集成到下一次迭代;迭代开发,降低风险;更好地安排产品开发的辅助过程。
缺点:只是一个开发过程,并没有涵盖软件过程的全部 内容,例如它缺少关于软件运行和支持等方面的内容;此外,它没有支持多项目的开发结构,这在一定程度上降低了在开发组织内大范围实现重用的可能性
应用:适用于大团队大项目
特点:是用例驱动的、以体系结构为核心的、迭代的增量的软件过程框架,每次迭代都是以上一次迭代为基础并生成包括构件的源代码体、需求说明、测试用例等的制品。每次的迭代又具体分为四个阶段:初始、细化、提交和转移,而在每个阶段又分为多个工作流
软件开发方法
结构化开发
面向数据开发
原型化开发
面向对象开发
概述
敏捷宣言
个体和交互要胜过过程和工具。
工作的软件胜于详尽的文档
客户的合作胜过谈合同
响应变化而不是遵循计划
精益思想
价值最终是从客户的角度定义的。
识别价值
定义价值流
保持价值流的流动
拉动系统
持续改善
敏捷软件开发的核心理念
适应变化
团队协作
交付价值
过程改进
敏捷软件开发具有的共同特点
致力于降低变化带来的成本
强调价值
强调人的价值
使用增量和迭代的开发方法
有影响的敏捷软件开发方法包括
极限编程
Scrum
看板方法
精益软件开发方法
水晶软件开发方法
自适应软件开发
动态系统开发方法
优缺点及应用
优点:快速相应变化和不确定性、可持续开发速度、适应有限资源和有限时间的约束。
缺点:重构而不降低质量困难、测试驱动开发可能会导致通过测试但非用户期望。
应用:适用于需求模糊且经常改变的场合,适用于商业竞技环境下的项目
Scrum方法
极限编程方法(eXtreme Programming)
XP 是一种轻量(敏捷)、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。
四大价值观
沟通(Communication)
简单(Simplicity)
反馈(Feedback)
勇气(Courage)
五大原则
快速反馈
简单性假设
逐步修改
提倡更改
优质工作
十三大实践
故事(用户故事)
估算
简单设计
重构
测试驱动开发
结对编程
持续集成
其他:计划博弈、短小发布、隐喻、代码集成所有(代码共享)、可持续的步调、整体团队、配合
看板方法
3个基本原则
从组织的现状开始
形成以渐进的、演化的方式来改善系统的共识
总重当前的过程定义、角色、职责或头衔
5条规则
可视化工作流
限制WIP的数量
度量并管理时间
明确过程准则
通过科学的方法改善工作流
系统工程
系统工程
定义
是一个问题求解过程,其目的是分析基于计算机的系统的功能、性能等要求,并把他们分配到基于计算机系统的各个系统元素中,确定他们的约束条件和接口
任务
识别用户的要求
系统建模和模拟
成本估算及进度安排
可行性分析
生成系统规格说明
可行性研究
经济可行性(成本、效益、货币的时间价值、投资回收期、纯收入)
技术可行性(风险分析、资源分析、技术分析)
法律可行性
方案的选择和折衷
需求工程
任务
借助当前系统的逻辑模型导出目的系统的逻辑模型
获得当前的物理模型
抽象出当前系统的逻辑模型
建立目标系统的逻辑模型
转换为目标系统的物理模型
过程
需求获取
需求分析与协商
系统建模
需求规约
需求验证
需求管理
需求层次
业务需求
用户需求
功能需求
非功能需求
设计工程
功能独立
高内聚低耦合
任务
数据、类设计:将分析-类模型变换成类地实现和软件实现所需要地数据结构
体系结构设计:体系结构设计定义软件地整体结构
接口设计:接口描述了软件内部、软件和协作系统之间以及软件同人之间如何通信
部件级设计:部件级设计将软件体系结构地结构性元素变换为对软件部件地过程性描述
过程
制定规范
体系结构和接口设计
数据/类设计
部件级(过程)设计
编写设计文档
设计评审
结构化分析与设计
结构化分析与设计是一种面向数据流的传统软件开发方法,它以数据流为中心构建软件的分析模型和设计模型。结构化分析、结构化设计和结构化程序设计构成了完整的结构化方法。
结构化分析方法概述
结构化分析方法
数据建模:实体关系图(E-R图)
功能建模:数据流图(DFD图)
结构化分析模型
数据流图
定义
数据流图:描述输入数据流到输出数据流的变换(即加工),用于对系统的功能建模。
数据流图的图形表示
数据流:由一组固定成分的数据组成。
加工:描述了输入数据流到输出数据流的变换
文件:用于存放数据
源或宿:存在于软件系统之外的人员或组织,表示软件系统输入数据的来源和输出数据的去向,因此也称源点和终点。
基本示例
分层的数据流图的创建(案例:考务处理系统)
结构化设计方法
软件设计分为概要设计和详细设计两个步骤。
结构图
描述软件系统的体系结构,描述一个软件系统由哪些模块组成,以及模块之间的调用关系
数据流图到结构图的映射方法
方块代表模块,直线代表模块间调用关系,尾部空心圆表示传递 数据,实心圆表示传递 控制信息
变换流:输入信息经过变换中心加工处理作为另外一种形式离开系统
事务流:事务中心T根据输入数据类型在若干个动作序列中选择1个来执行
详细设计方法
程序流程图、PAD图、N-S图
软件测试
基础
软件测试目的
软件测试的目的是发现问题,发现至今未发现的问题。检查系统是否满足需求。
Grenford J.Myers观点:
(1)测试是程序的执行过程,目的在于发现错误;
(2)一个好的测试用例在于能发现至今未发现的错误;
(3)一个成功的测试是发现了至今未发现的错误的测试;
基本原则
所有测试都应追溯到客户需求
测试整整开始前就进行测试计划
从小规模逐步转向大规模
穷举测试不可能
独立的第三方承担测试
合理的输入条件和不合理的输入条件
严格执行测试计划、排除测试的随意性
对每一个测试结果做全面检查
测试用例设计的方法
白盒测试(也称:白箱测试、结构测试)
黑盒测试(也称:黑箱测试、行为测试)
白盒测试对程序模块的测试包括
程序模块的所有的执行路径至少测试一次
对所有的逻辑判定,取“真”与取“假”+白盒测试的两种情况都至少测试一次
在上下边界及可操作范围内运行所有循环
测试内部数据结构的有效性
黑盒测试测试发现以下类型错误
不正确或遗漏的功能
接口错误,如输入输出参数的个数、类型
数据结构错误或外部信息访问错误
性能错误
初始化和终止错误
白盒测试
常用的白盒测试方法
逻辑覆盖测试(语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖)
基本路径测试
数据流测试
循环测试(简单循环、嵌套循环、传捷循环、非结构循环)
黑盒测试
主要方法
等价类划分
边界值分析
比较测试
错误猜测
因果图方法
总结
希望软件工程一遍过!