第2章:过程模型
开场白:
1、什么是软件过程:就是过程模型
2、开发人员必须灵活地选择过程模型并遵循过程模型
3、重要性:规范化
4、步骤:具体情况选择具体的过程模型
5、软件过程的产品:代码+数据+文档
6、质量保证措施:质量是最终目标
软件工程和软件过程的区别?
软件工程 = 软件过程+方法+工具
2.1 通用过程模型
基于第一章提出的通用过程模型(包含5个活动的过程模型),提出过程流的概念:就是5个活动的顺序
1、线性过程流:12345
2、迭代过程流:12123123412345……
3、演化过程流:123451234512345……
4、并行过程流:12
3
45
2.2 定义框架活动
一个活动 由 哪些动作组成 比较适合项目团队?
2.3 明确任务集
一个活动 由 哪些 任务组成 比较适合项目团队?
2.4 惯用过程模型
开场白:也叫传统过程模型,传统二字的来源:该系列模型定义了过程框架中:过程流、动作、任务集、质量控制、……什么时间该干什么都给你定义的死死的,你照着过程模型跑就行了!而且必须照着跑,对于不同的项目,会有一些不同的过程模型;本小节介绍的惯用过程模型都支持通用框架活动,但是不同的模型的过程流可能不同;第三章将介绍适应变更的过程模型。
2.4.1 瀑布模型
线性过程流===》最早模型:瀑布模型,也叫线性顺序模型
过程:12345结束
适用前提:需求定义明确且变更最好不要有
使用场景:原系统的修改增强
破绽:客户自己都不明确需求、到结束才有exe给用户展示、越晚提出的变更代价越大……总之,不适合当前飞速变更的时代
2.4.2原型开发过程模型
基于瀑布模型的问题,提出原型开发过程模型;
过程:迅速地12345以定义软件需求
使用前提:Stateholders都清楚的知道原型的主要目的是定义需求
适用场景:客户不明确自己需要什么功能、工程师不确定UI界面……
破绽:原型的质量不行,有些人直接将迭代了几次的原型交付
总结:原型开发过程模型可以作为一个完整的过程框架,但是更多的时候是用来明确定义需求的,可以与任何一种其他的过程模型结合使用,原型是为定义需求服务的,开发人员需要丢弃原型(某些部分可以重用),以更好地满足用户的需求。
2.4.3演化过程模型
典型的有两种:螺旋模型VS增量模型:
增量模型和螺旋模型的本质区别主要体现在它们对软件开发生命周期的不同理解和处理方式上。
-
增量模型的本质:
- 理念: 增量模型的本质是将整个系统划分为多个相互关联的增量,每个增量都包含一部分系统的功能。
- 开发方式: 增量模型采用渐进式的方法,通过逐步增加新的功能,逐渐构建整个系统。
- 交付: 每个增量都是一个可交付的部分系统,可以在每个迭代周期结束时向用户交付,使用户能够逐步体验系统的功能。
-
螺旋模型的本质:
- 理念: 螺旋模型的本质是通过风险管理来推动整个软件开发生命周期。它强调在开发过程中不断进行风险评估,并在每个螺旋周期中进行改进。
- 开发方式: 螺旋模型采用风险驱动的方法,通过迭代循环,每个周期都包括计划、风险评估、工程和评审等活动。
- 交付: 每个螺旋周期的最终产品是一个部分系统,而不是一个完整的、可交付的系统。
-
关注重点的不同:
- 增量模型: 关注于渐进地提供功能,强调系统的快速交付和用户的早期参与。
- 螺旋模型: 关注于风险管理,强调在整个开发过程中不断学习和适应,以降低项目失败的风险。
-
适用场景的不同:
- 增量模型: 适用于大型系统,可以通过分阶段地引入新功能来满足用户需求。
- 螺旋模型: 适用于大型、复杂、高风险的项目,其中风险评估和管理至关重要。
总的来说,增量模型的本质是通过渐进构建来满足用户需求,而螺旋模型的本质是通过风险管理来推动整个软件开发生命周期。选择其中一个模型取决于项目的特点、需求和风险程度。
EX:找个实例看一下
2.4.4统一过程模型Unified Process UP
正如UML是对各种优秀的工具的集合一样,UP是对前面所有惯用过程模型的优秀特质的综合。并以敏捷软件开发中许多好的原则来实现……说白了,就是对所有过程模型中优秀特质的大杂烩。
UP模型分为五个阶段,每个阶段由惯用过程模型5个通用活动取连续的两个组成,看书上的图一目了然。前面的惯用过程模型都只使用了活动的名字,没有介绍组成活动的动作和任务,书上的图下面的讲述是对使用过的、优秀的方法和工具的简介。
总之:何谓统一?集大成者即为UP
统一过程(Unified Process,UP)是一种面向对象的软件工程过程,它提供了一个通用的、可定制的框架,用于开发、部署和维护软件系统。UP是一种迭代的、增量的过程,强调在整个软件开发生命周期中的灵活性和适应性。
另一本书上的对统一过程的主要特点和组成部分的介绍:
-
迭代和增量:
- 统一过程采用迭代和增量的方式进行开发。开发过程被划分为一系列的迭代,每个迭代都会产生一个可执行的系统的部分。
-
体系结构驱动:
- UP强调在项目早期关注系统体系结构的设计和演化。通过体系结构驱动的方法,可以确保系统的核心结构能够支持未来的需求变化。
-
用例驱动:
- 用例是统一过程中的核心概念,用于描述系统的功能需求和与外部实体的交互。用例驱动的方法有助于从用户的角度定义系统的行为。
-
组件化和模型驱动:
- 统一过程鼓励通过组件化的方式构建系统,同时注重建模。建模工作包括用例图、类图、活动图等,以帮助理解和传达系统的设计。
-
迭代的阶段:
- 统一过程将整个软件开发过程划分为四个阶段:
- 初始阶段(Inception): 着重于定义项目的范围、目标和约束。
- 构建阶段(Elaboration): 着重于定义系统体系结构、建立核心组件和进行初步的项目规划。
- 转变阶段(Construction): 着重于系统开发、测试和部署。
- 移交阶段(Transition): 着重于软件的发布、维护和升级。
- 统一过程将整个软件开发过程划分为四个阶段:
-
工作流程:
- 统一过程定义了一系列工作流程,每个工作流程都包含一组相关的活动。典型的工作流程包括需求、分析与设计、实现、测试和部署。
-
最佳实践:
- 统一过程提供了一系列最佳实践,涵盖了项目管理、配置管理、质量管理等方面。这些最佳实践是为了提高软件开发过程的质量和效率。
统一过程是一种可定制的过程框架,允许根据项目的特点和需求进行调整。它为团队提供了一种有组织、系统化的方法,帮助项目团队在整个软件开发生命周期中更好地管理和交付项目。
2.5 产品和过程
这一小节是对2.4中各种模型的对比,每个模型都有缺点,没有一种模型是通用的,项目团队需要根据自己的需要灵活的进行取舍。
顺带提出了一个观点,软件是产品和过程的辩证统一,是产品,也是过程。
2.6 小结
1970瀑布模型——1970增量模型——1986螺旋模型——1999统一过程模型
*迭代到底迭代出了什么工作产品,增量和演化模型地区别到底是什么,说是风险控制?那他们地过程流的区别到底是什么呢?螺旋模型每一轮的结果都不能作为EXE吗?……实习的时候了解了解%无需深究历史版本,了解最新的东西更为重要。
习题与思考题
1:
(1) 设计人员应该问用户的问题:
-
需求澄清: 用户对于系统的需求是否清晰和一致?是否有可能出现需求的变更?
-
用户期望: 用户对系统的期望是什么?有哪些关键功能或特性对用户来说是最重要的?
-
用户体验: 用户对于系统的界面和交互有何期望?有哪些用户友好性的方面需要特别考虑?
-
可维护性: 用户对于系统的可维护性有何要求?是否期望容易进行升级和扩展?
-
交付时间: 用户对于软件交付的时间表和进度有何期望?是否有紧急需求?
(2) 用户应该问设计人员的问题:
-
技术选型: 设计人员选择了哪些技术和工具来构建系统?这些选择是否满足系统的要求?
-
开发流程: 设计人员采用了什么样的软件开发过程?如何确保质量和可维护性?
-
沟通渠道: 用户与设计人员之间的沟通渠道是什么?如何确保双方能够及时了解项目的进展和需求的变化?
-
风险管理: 设计人员对于项目中的风险有怎样的认识和管理计划?如何应对可能的问题?
-
测试策略: 设计人员有哪些测试策略和计划,以确保软件的质量和稳定性?
(3) 用户对将要构建的软件的自问:
-
需求确认: 我对系统的需求是否清晰明确?有没有可能存在遗漏或理解偏差?
-
期望明确: 我对于系统的期望是否清晰并被记录?我期望系统在使用中能够达到哪些效果?
-
使用频率: 我会以多频或少频的方式使用系统?这对系统的性能和稳定性有何影响?
-
学习曲线: 我是否需要花费大量的时间来学习和适应系统?是否提供了足够的培训和文档?
-
未来需求: 我是否考虑到未来可能的需求变化?系统是否具备良好的可扩展性?
(4) 设计人员对于软件产品和建造该产品采取的软件过程的自问:
-
过程选择: 我选择的软件过程是否适用于项目的规模和性质?是否有必要进行定制或调整?
-
团队协作: 我如何确保团队成员之间的良好协作?有无采用适当的协同工具和沟通渠道?
-
质量标准: 我制定了哪些质量标准和最佳实践,以确保软件的质量和性能?
-
变更管理: 我对于需求变更和技术变更有哪些合理的变更管理措施?如何确保变更不对项目产生负面影响?
-
学习与改进: 我是否定期进行项目评估和团队反馈?是否有机制促使团队学习和不断改进软件开发过程?
2:都有对应的过程模型,对应的适用场景
3:叫上金主,一条龙服务,然后:“吃了这么多好处,你可要少提点需求!”
4、略
5、略
6、这一圈螺旋,会产生什么东西?
7、可以,原型+anyone
8、优点:开发速度快;缺点:质量没保障
9、不是他的职责
10、不是捏,UP是过程模型,UML是这个过程模型中使用的工具;