软件工程-第二章 软件过程
第二章 软件过程
目录
第二章 软件过程
2.1 软件过程概念
一、软件生命周期
二、软件过程
三、软件过程模型
四、软件过程评估
2.2 传统模型---早期提出的
一、瀑布模型 / 经典生命周期模型
二、V模型（V-model）：瀑布模型的变种
三、原型模型 / 原型化模型 / 快速原型模型
四、增量模型
五、螺旋模型
六、喷泉模型
2.3 现代模型
一、基于构件的开发模型
二、统一过程模型RUP（适合大团队大项目）
三、敏捷开发过程（结合基本原理and开发准则）
2.4 模型选择
一、分析
二、经验
三、案件分析
2.1 软件过程概念
内容总览：
（1）软件生命周期
（2）软件过程
（3）软件过程模型
（4）能力成熟度模型
一、软件生命周期
定义：软件产品/软件系统 设计 -> 投入使用 -> 被淘汰 的全过程
二、软件过程
1、定义：软件过程是在工作产品构建过程中，所需完成的工作活动、动作、任务的集合
（1）活动主要实现宽泛的目标，
与应用领域、项目大小、结果复杂性或者实施软件工程的重要程度没有直接关系
（2）动作：阶段目标，包含了主要工作产品生产过程中的一系列任务
（3）任务关注小而明确的目标，能够产生实际产品
2、基本框架活动
一个通用的软件工程过程框架通常会包含以下5个基本的框架活动:
（1）沟通:在技术工作开始前,先和利益相关者进行沟通与协作,以理解项目目标,并收集需求
（2）策划:制定项目计划，包括需要执行的技术任务、可能的风险、资源需求、工作产品…
（3）建模:构思软件的体系结构、构件如何结合等
（4）构建:包括编码和测试
（5）部署:交付全部软件或部分增量,由用户使用并反馈意见
三、软件过程模型
1、别称：软件开发模型 ；软件生存周期模型 ；软件工程范型
2、定义：是软件开发全部过程、活动、任务的结构框架
它能直观表达软件开发全过程，明确规定要完成的主要活动、任务、开发策略
四、软件过程评估
1、能力成熟度模型CMM
按成熟度划分为5个等级，等级越高，软件生产能力越成熟，软件开发能力越强
（1）迄今为止学术界和工业界公认的有关软件工程和管理实践的最好的软件过程评估模型
（2）为评估软件组织的生产力提供了标准
（3）为提高软件组织的生产过程指明了方向
2、ISO 9000 质量标准体系
3、ISO/IEC 15504 SPICE 信息技术软件过程评估
2.2 传统模型---早期提出的
一、瀑布模型 / 经典生命周期模型
1、简述
（1）第一个软件过程模型
（2）规定了各项软件工程活动，以及它们自上而下，相互衔接的固定次序，如同瀑布流水，逐级下落
（3）软件开发过程与软件生命周期一致
（4）线性模型
（5）阶段间具有顺序性和依赖性
（6）推迟实现的观点（编码在软件开发的中后期）
（7）是一种使用广泛，以文档为驱动的模型
（8）每个阶段都有与其相关联的里程碑和可交付产品
（9）每个阶段结束前完成文档审查，及早改正错误
（10）一直被用来规范软件开发活动
（11）很多其它模型都是在瀑布模型基础上的改进
2、实际（带反馈）的瀑布模型
（1）当后面阶段发现前面阶段的错误，则沿反馈线返回并修正
（2）对软件的维护，则反馈到相应的阶段
3、缺点
（1）增加工作量
各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量
（2）早期错误发现晚
早期的错误可能要等到开发后期的测试阶段才能发现， 进而带来严重的后果
（3）开发风险大
由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险
（4）不适应需求变化
不能反映实际的开发方式，软件开发需要迭代；
无法适应需求不明确和需求的变化
4、应用场合
适用于系统需求明确且稳定、技术成熟、工程管理较严格的场合，如军工、航天、医疗
二、V模型（V-model）：瀑布模型的变种
如果在单元测试发现错误，则需要检查相应模块的详细设计，修改相应模块的代码，并重新进行单元测试
错误越晚发现，改正花费的代价越大
三、原型模型 / 原型化模型 / 快速原型模型
1、原型
（1）定义
Δ1、一个部分开发的产品，使客户和开发人员能够对计划开发的系统的相关方面进行检查
Δ2、原型是一个实际项目的前期准备，目的是快速给用户提供一个“看得见、 摸得着”的演示系统，
寻求用户有价值的反馈和进一步开发的建议
Δ3、注意前期过程强调的是功能的展示，而不是包含的内容或数据；
原型系统中的数据并不需要真实的数据
（2）举例：要开发图书借阅系统，先开发主要界面
要开发智能家居系统，先实现少量的室内信息监视和电器控制
（3）原型化的目的
Δ1、明确并完善需求，如演示原型
Δ2、研究技术选择方案，如技术验证原型
（4）原型结果
Δ1、抛弃原型
Δ2、把原型发展成最终产品
2、原型模型
3、优缺点
（1）优点：减少需求不明确带来的风险
（2）缺点：构造原型采用的技术和工具不一定主流
快速建立起来的系统加上连续的修改可能导致原型质量低下
设计者在质量和原型中进行折中
客户意识不到一些质量问题
4、应用场景
客户定义一个总体目标集，但是他们并不清楚系统的具体输入输出;
或开发者不确定算法的效率、软件与操作系统是否兼容以及客户与计算机交互的方式
此时，原型模型是很好的选择
四、增量模型
1、增量
（1）定义：满足用户需求的一个子集，能够完成一定功能、小而可用的软件
（2）举例
2、增量模型
（1）方式一
（2）方式二
3、增量的方式（实际使用中，常常是两种方式的结合）
（1）增量方式
（2）迭代方式
4、增量模型的特点
（1）增量模型是一种非整体开发的模型，是一种进化式的开发过程
（2）增量模型从部分需求出发，先建立一个不完整的系统，
通过测试运行这个系统取得经验和反馈，进一步使系统扩充和完善
（3）如此反复进行，直至软件人员和用户对所设计的软件系统满意为止
（4）增量模型结合了原型模型的基本要素和迭代的特征，采用了基于时间的线性序列，
每个线性序列都会输出该软件的一个“增量”
（5）每个增量的开发可用瀑布或快速原型模型
5、增量模型的优点
（1）增量概念的引入，不需要提供完整的需求，只要有一个增量出现，开发就可以进行；
（2）软件能够更早投入市场
（3）开放式体系结构，便于维护
（4）在项目的初始阶段不需要投入太多的人力资源
（5）产品逐步交付，软件开发能够较好地适应需求的变化；
（6）能够看到软件中间产品，提出改进意见，减少返工，降低开发风险
6、缺点
（1）每个增量必须提供一些系统功能，这使得开发者很难根据客户需求给出大小适合的增量
（2）软件必须具备开放式体系结构（困难）
（3）易退化成边做边改的方式，使软件过程控制失去整体性
7、增量模型的适用场合
适用于软件开发中需求可能发生变化、具有较大风险、或者希望尽早进入市场的项目
五、螺旋模型
1、背景：软件开发普遍存在风险
（1）交付的产品用户不满意
（2）产品不能按时交付
（3）开发成本超过预算
（4）产品开发期间关键开发人员离职
（5）产品投入市场前竞争对手发布功能相近价格更低产品
2、螺旋模型
（1）概述
Δ1、模型结合了瀑布模型和原型模型的特点，把开发活动和风险管理结合起来控制风险
Δ2、开发过程分成若干次迭代，每次迭代代表开发的一个阶段，对应模型中一条环线
Δ3、每次迭代分成四个方面的活动，对应笛卡尔坐标的四个象限：
°1、确定本阶段目标，选定实施方案，弄清项目开发的限制条件；
°2、评估所选方案，通过构造原型和风险 分析识别和消除风险；
°3、实施软件开发和验证；
°4、评价本阶段的工作成果，提出修正建议，并计划下一阶段工作
（2）优点
Δ1、螺旋模型强调原型的可扩充性和可修改性，原型的进化贯穿整个软件生存周期，
这将有助于目标软件的适应能力，支持用户需求的动态变化
Δ2、原型可看作可执行的需求规格说明，易于为用户和开发人员共同理解，
还可作为继续开发的基础，并为用户参与所有关 键决策提供了方便
Δ3、螺旋模型为项目管理人员及时调整管理决策提供了方便，进而可降低开发风险
（3）缺点
Δ1、如果每次迭代的效率不高，致使迭代次数过多，将会增加成本并推迟交付时间
Δ2、使用该模型需要有相当丰富的风险评估经验和专门知识，
要求开发队伍水平较高，否则会带来更大风险
（4）适用场合
适用于需求不明确或者需求可能发生变化的大型复杂的软件系统
支持面向过程、面向对象等多种软件开发方法，是一种具有广阔前景的模型
六、喷泉模型
1、概述
（1）喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程 （2）软件开发早期定义对象，整个开发过程充实和扩充对象
（3）各个阶段使用统一的概念和表示方法，生命周期各阶段无缝连接
（4）各个开发步骤多次反复迭代
2、优点
喷泉模型的各个阶段没有明显的界限，开发人员可以同步进行开发，
可以提高软件项目开发效率，节省开发时间
3、缺点
（1）由于喷泉模型在各个开发阶段是重叠的，在开发过程中需要大量的开发人员，
因此不利于项目的管理。
（2）喷泉模型要求严格管理文档， 使得审核的难度加大，
尤其是面对可能随时加入的各种信息、需求与资料的情况
4、适用场合
面向对象开发
2.3 现代模型
一、基于构件的开发模型
1、概述
（1）是近年来得到广泛应用的软件过程模型，由于采用构件技术和重用技术，
它改变了大型软件的开发方式
（2）考虑的焦点是集成，而非实现
2、构件/组件（Component）
（1）系统中模块化的、可更换的部分
（2）实现特定的功能
（3）对实现进行封装，暴露一组接口
（4）例如：动态链接库（.dll），浏览器插件
3、基于构件的开发模型包括两部分：系统开发、构件开发与维护
4、分析---四个阶段
（1）需求分析：与其它过程模型相同
（2）构件分析：根据需求搜索构件
如果没有完全匹配的构件，则需要修改构件或者修改需求
（3）系统设计：与其它过程模型不同
考虑重用和集成
如果没有可重用的构件，则设计新软件
（4）开发集成：将构件集成到系统中
开发新软件
5、优点
（1）软件复用思想
（2）降低开发成本和风险，加快开发进度，提高软件质量
6、缺点
（1）模型复杂
（2）商业构件不能修改，会导致修改需求，进而导致系统不能完全符合客户需求
（3）无法完全控制所开发系统的演化
（4）项目划分的好坏直接影响项目结果的好坏
7、适用场合：适用于系统之间有共性的情况
二、统一过程模型RUP（适合大团队大项目）
1、特点
（1）完整且完美的软件工程方法
（2）RUP吸收了多种开发模型的优点，具有很好的可操作性和实用性
（3）RUP基于面向对象方法学，开发过程中的需求分析和系统设计表示法，均使用UML，
在面向对象领域已获得广泛使用
2、从3个视角描述软件开发过程
（1）动态视角：描述面向对象开发随时间变化的各个阶段
通过对开发过程中的周期、阶段、迭代过程、里程碑等的描述来表示
（2）静态视角：描述在各个开发阶段所要进行的活动or工作流
（3）实践视角：总结了在实际项目开发中可以采用的良好实践
3、实践视角： 6条最佳实践
（1）迭代式开发
Δ1、软件开发初期往往很难明确需求，需求变更 不可避免
Δ2、迭代式开发是应对需求变更的有效方法，每次迭代产生一个可交付版本，
获得用户反馈，以计划和调整下一个版本，减少风险
Δ3、根据客户的轻重缓急来规划增量，先开发和交付优先级最高的增量
（2）管理需求
Δ1、对需求及其变更进行管理，有效的需求管理是项目成功的关键
Δ2、采用用例分析法来捕获需求，由用例驱动设计和实现
（3）基于构件的体系结构
便于集成已有构件，提高软件复用率，进而提高软件开发效率和软件质量
（4）可视化建模
使用统一建模语言（UML）进行可视化建模，对系统分析和设计
（5）验证软件质量
Δ1、软件质量评估贯穿整个开发过程的所有活动
Δ2、软件质量不只是质量小组的任务，也不只是软件编码后的任务
只有全员参与并贯穿整个开发过程，才能保证软件的高质量
（6）控制软件变更
descirbe how to 控制、跟踪软件的变更
4、Rational统一过程模型（RUP驼峰图）
|
|
|
5、统一过程的静态结构
6、统一过程的动态结构
三、敏捷开发过程（结合基本原理and开发准则）
1、背景：2001年2月，17位编程大师发表敏捷软件开发宣言
虽然左边的项（现有的做法）有价值，但我们更重视右边的项（冥界的做法）
高效工作、快速响应变化
2、敏捷开发方法
极限编程：eXtreme Programming/XP
自适应软件开发 Adaptive Software Development/ASD
并列争球法：Scrum
动态系统开发方法 Dynamic System Development Method/DSDM
水晶法：Crystal
特征驱动开发：Feature-Driven Development/FDD
精益软件开发：Lean Software Development/LSD
3、极限编程
4、极限编程的有效实践
5、敏捷开发の优缺点
（1）优点：快速响应变化和不确定性
可持续开发速度
适应商业竞争环境下的有限资源和有限时间
（2）缺点：测试驱动开发可能导致通过测试，但非用户期望
重构而不降低质量困难
6、适用场合：需求模糊且经常改变的场合， 适合商业竞争环境下的项目
2.4 模型选择
一、分析
1、软件过程模型是不断发展的
2、各种软件过程模型各有优缺点和适用场合
3、不同软件往往需要不同软件过程模型、
4、选用时不必拘泥于某种模型
5、可组合多种模型
6、可根据实际创造新的模型
二、经验
1.前期需求明确的情况下，尽量采用瀑布模型
2.用户无系统使用经验，需求分析人员技能不足的情况下，尽量借助原型模型
3.不确定因素很多，很多东西无法提前计划的情况下，尽量采用增量模型or螺旋模型
4.需求不稳定的情况下，尽量采用增量模型
5.资金和成本无法一次到位的情况下，可采用增量模型
6.对于完成多个独立功能开发的情况，可在需求分析阶段就进行功能并行，每个功能内部都尽量遵循瀑布模型
7.全新系统的开发必须在总体设计完成后再开始增量或并行
8.编码人员经验较少的情况下，尽量不要采用敏捷or迭代模型
9.增量、迭代和原型可以综合使用，但每一次增量或迭代都必须有明确的交付和出口原则
三、案件分析
1、案件一
（1）案件：医疗设备控制软件
（2）分析：需求明确且稳定 ； 可靠性和安全性要求极高 ； 对软件错误和故障的控制和跟踪能力强
需要对软件开发过程严格控制 ； 需要大量严格的文档
（3）选择：瀑布模型
2、案件二
（1）案件：校园一卡通系统
（2）分析：包括若干相对独立的功能 ； 系统具体需求不明确且会发生变化 ； 系统需要具有可扩充性
用户需要熟悉和适应新的系统 ； 项目复杂程度中等、有一定风险 ； 产品和文档的再使用率较高
（3）选择：增量模型
3、案件三
（1）案件：智能化小区
智能家庭：家居信息的实时和远程监视 家用电器的远程和自动控制 家庭安防报警和远程通知
智能小区：安防门禁、可视对讲等 ； 物业管理 ； 一卡通系统 ；
缴费、包裹、公告、便民信息等发布到户 ； 家政相关服务，如送水、送餐等
（2）分析：包括若干相对独立的业务管理功能 ； 系统具体需求不明确且会发生变化 ；
部分技术方案可行性不确定 ； 系统需要具有可扩充性 ； 用户需要熟悉和适应新的系统 ；
项目复杂程度较大、风险较大 ； 希望尽早投入市场
（3）选择：原型化模型+增量模型
软件工程-第二章 软件过程相关推荐
- 软件工程第二章 软件工程
详细思维导图及资源可点击幕布连接 :第二章 软件工程
- 软件工程--第二章--可行性分析
文章目录 可行性研究内容 可行性研究的步骤 系统流程图 数据流程图 数据流图 命名 数据字典 定义数据的方法 数据元素字典的定义 数据流字典的定义 数据存储字典的定义 数据处理字典的定义 成本效益分析 ...
- 现代软件工程 第二章 【个人技术】 练习与讨论
1 基本作业: 从Hello World开始 要求每个读者(或者学生)开始管理自己的源代码: 每个人都有一个VSTS的客户端,系统管理员给每一个人都创建了TFS项目,每个学员都是各自项目的管理员. ...
- 《软件过程管理》 第二章 软件过程成熟度
- 软件工程知识点复习第二章
软件工程第二章 1.软件问题定义和可行性分析 软件问题定义 可行性研究 数据流图(重点) 数据字典(重点) 成本效益分析 货币的时间价值 1.软件问题定义和可行性分析 软件问题定义 需要什么,要做什么 ...
- 软件工程复习提纲——第二章
软件工程复习提纲,期末.考研的学霸笔记 第二章--可行性研究 第二章可行性研究 1.可行性研究的任务:可行性研究的目的不是解决问题,而是用最小的代价在尽可能短的时间内确 定问题是否能够解决,是否值得去 ...
- 第二章 软件工程基础知识
第二章 考试大纲 软件需求分析与定义 软件设计.测试与维护 3. 软件复用 4. 软件质量保证及质量评价 5. 软件配置管理 6. 软件开发环境 7. 软件过程管理. 知识点: 1. 软件需求分析与定 ...
- 软件工程技术--第二章 可行性研究
第二章 可行性研究及软件计划 1.软件定义--做什么? 软件生命周期的阶段划分: 软件计划:问题定义.可行性研究 软件开发:需求分析.软件设计(概要设计.详细设计).程序编写.软件测试 软件运行维护: ...
- 软件工程第二周阅读作业
提出问题 快速通读教材<构建之法>,并参照提问模板,提出5个问题. 如何提出有价值的问题? 请看这个文章:http://www.cnblogs.com/rocedu/p/5167941.h ...
最新文章
- Redis缓存数据库安全加固指导（一）
- kubernetes一次生产故障日记
- Linux网络编程 五种I/O 模式及select、epoll方法的理解
- LiveVideoStack线上交流分享 ( 一 ) —— 解密GPU：视频转码与分析加速
- c# mysql executenonquery_C#中ExecuteNonQuery()返回值注意点分析
- 解释如何优化css选择器_购物车解释了CSS选择器
- 现代科技概论_现代科技概论课程：力与运动1
- java 计时 timeclock_用 java 写一个clock的类，100毫秒的时钟 求代码。。越简单越好。。最好有注释...
- Linux学习（2）常用的命令
- Android优秀参考APP源码
- 电子产品可靠性测试报告
- android 支持swf格式,安卓手机如何播放swf文件
- [Vmware卸载] Vmware12卸载
- PHP项目汇报ppt模板,免费工作汇报模板（课堂PPT）
- 论文解读《使用支持向量机和PSSM谱预测蛋白质中的RNA结合位点》
- java 句柄无效_Java 关于java.io.IOException: 句柄无效。
- C. The Intriguing Obsession[组合数学]
- c# mysql登录界面_C#窗体控件与MySQL实现登录功能
- 大素数判定以及大整数分解
- 创业公司如何制定员工股份和股权的分配