🌈 个人主页：十二月的猫-CSDN博客
🔥 系列专栏： 🏀软件开发必练内功_十二月的猫的博客-CSDN博客💪🏻 十二月的寒冬阻挡不了春天的脚步，十二点的黑夜遮蔽不住黎明的曙光
目录
1. 过程
1.1 过程定义
1.2 过程的重要性
1.3 过程的几个阶段
2. 软件开发建模
3. 一些软件开发模型
3.1 瀑布模型
3.2 V模型
3.3 原型化模型
3.4 分阶段开发模型
3.4.1 增量式开发
3.4.2 迭代式开发
3.4.3 总结
3.5 螺旋模型
3.6 敏捷开发
3.6.1 XP极限编程
4. 静态和动态建模技巧
4.1 静态建模
4.2 动态建模
1. 过程
1.1 过程定义
过程：软件开发活动中产生某种期望结果的一系列有序任务，涉及活动、资源和约束
过程本质上是指软件开发过程，软件开发过程必然是一系列有前后顺序的任务（需求分析、系统设计、程序设计等等，存在前后顺序关系）
软件开发过程涉及活动、资源和约束主要理解如下：
- 软件开发过程规定了很多活动
- 软件开发过程需要遵循一组约束使用资源，并产生中间结果和最终产品
- 大型过程可以看作是子过程的链接
生命周期：软件开发过程（过程）称为生命周期
1.2 过程的重要性
过程（软件开发过程）就是：软件开发活动中的一系列有序活动
其中重点在于：有序、一系列
一系列：活动类型相似（相同），软件开发的都执行这些工作
有序：活动除了相似外还需要保证前后顺序
保证活动类型相同并且顺序相同，主要目的是保证：
- 一致性
- 结构性
- 通用性
- 自我指导性
对我们：让我们知道是否完成了工作
对别人：让所有软件开发遵循一样的结构
1.3 过程的几个阶段
- 需求分析
- 系统设计
- 程序设计
- 程序实现
- 单元测试
- 集成测试
- 系统测试
- 系统交付
1、每个阶段本身是一个过程，它同样由一系列活动组成
2、每个活动涉及输入，子活动 ，约束，资源
3、过程阶段化目的：尽量让每个阶段之间解耦，从而提高通用化
2. 软件开发建模
软件开发过程中建模是相当重要的。
就目前来说，我们本科生的课程设计都是没有一个明确的开发模型的，这将导致很多的问题。
下面来说说为什么软件开发需要建模：
- 从消极一方面来说，这直接导致开发过程没有一致性、结构性、通用性。这三者属性的缺失对于一个软件来说可能不是致命的，但是对于软件开发本身来说将是致命的
- 另一方面来说，软件开发建模将带来多方面的益处：
- 软件开发过程建模有助于开发团队就软件开发过程中涉及的活动、资源和约束达成共识
- 软件开发过程建模有助于发现过程层面的缺陷（过程不完善、过程不一致等）
- 软件开发过程建模有助于确立软件开发目标（评价软件功能、开发过程的量化指标等）
- 为特殊情况定制一般化的处理过程
3. 一些软件开发模型
3.1 瀑布模型
瀑布模型就是把软件开发过程像瀑布一样从上到下去安排，前后存在严格的顺序。
模型图如下：
瀑布模型特点如下：
- 阶段间的依赖性和连续性
- 推迟实现的观点
- 质量保证的观点
- 高维度整体看开发过程的观点
瀑布模型的优点：
- 描述了软件开发活动并为每一个活动设置了里程碑和提交物
- 简单易懂（容易向开发者解释）
- 是其他复杂模型的基础
瀑布模型的缺点：
- 不能处理迭代的情况，难以面对重复开发问题
- 文档转化很困难
真实开发过程：
原型化开发是对瀑布模型的改进：
- 原型：一种部分开发的产品，用来让用户和开发者共同研究，为最终产品定型
核准（validation）和检验（verification）的区别：
- 核准是检查文档SRS（需求分析）
- 检验是检查系统设计内容
- 核准和检验环节在系统测试环节进行
3.2 V模型
定义：是瀑布模型的一种变种
模型图：
和瀑布模型的区别：
- V模型存在一些迭代，更加清楚明白
- 瀑布模型强调文档和提交物
- V模型强调开发活动及其正确性，允许重复活动
3.3 原型化模型
该模型本身是有效的过程模型的基础。每一阶段都基于原型建立，以快速构造系统，逐步完成各阶段任务
类似于一个插件，运用在有效过程模型的任何阶段，用来辅助有效过程模型的开发
简化过程为：
- 需求
- 设计
- 实现
- 测试
3.4 分阶段开发模型
分阶段开发模型的意思就是： 让模型开发分为不同的阶段，每个阶段不是注重产生文档和说明而是强调具体的产品。
1、瀑布式强调文档和说明（一方面方便manager检查，另一方面导致不注重活动产品本身）
2、V模型强调过程和过程的正确性
3、分阶段开发模型是原型化开发模型的增强，强调的是每个阶段的原型化产品产出
定义：系统被设计成部分提交，每次用户只能得到部分功能，而其他部分处于开发过程中
循环时间：软件开发时整理需求文档时间与系统提交时间之差
分阶段开发模型能够有效减少循环时间。
产品系统和开发系统互相迭代式开发，如下图：
3.4.1 增量式开发
介绍
在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成。整个产品被分解成若干个构件，开发人员逐个构件地交付产品。
特点
在使用增量模型时，第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后，经过评价形成下一个增量的开发计划，它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复，直到产生最终的完善产品。
系统需求按照功能分成若干子系统，开始建造的版本是规模小的，核心的，部分功能的系统。后续版本添加有新功能的子系统，最后版本是包含全部功能的子系统集。
3.4.2 迭代式开发
介绍
系统一开始就提供了整体功能框架，后续版本陆续增强各个子系统，最后版本使各个子系统功能达到最强。
特点
1. 一次迭代过程包括了所有软件开发流程。
2. 每一次迭代均产生一个可发布的产品。
3. 该产品为最终产品的一个子集。
3.4.3 总结
上面是增量式开发；下面是迭代式开发：
分阶段开发最大的优势：每个软件版本的周期减少了
3.5 螺旋模型
一般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模型。螺旋模型是渐进式开发模型的代表之一。
四个任务：计划、目标/方案、风险评估、开发测试
四轮迭代：操作概念、软件需求、软件设计、系统实现与部署允许
此法将开发活动与风险管理结合起来，以降低和控制风险
适用范围：较大型软件工程项目
操作概念：结合业务模型，总结出若干基本的软件操作或流程，涉及角色、动作和制约关系等
举个例子：
3.6 敏捷开发
重点：
- 强调开发更快速
- 强调开发更灵活
原则：
- 个体和交互价值胜过过程和工具（更灵活）
- 软件开发胜过文档编写（更快速）
- 客户合作胜过合同谈判（更快速）
- 响应变化胜过遵循计划（更灵活）
敏捷开发的软件过程倾向性
包括：
- XP极限编程
- SCRUM编程
3.6.1 XP极限编程
四个变量：成本、时间、质量和范围。通过研究变量之间的互相作用，将项目开发分析的更加透彻。
四个准则：沟通、简单性、反馈、勇气
一个选择题：
4. 静态和动态建模技巧
建模工具和技术有很多，这些技术可以帮助我们建立前面提到的各类模型。只有利用这些工具/技术，前面的瀑布式、原型化、敏捷开发等过程模型才能够很好的呈现。
建模工具包括两大类：静态建模、动态建模
4.1 静态建模
静态建模的方式有许多种。在20世纪90年代早期，Lai设计了一种全面的过程表示法，目的是让人们能够在任何细节的层次上对任何过程都可以建模（Lai 1991）。它是在一种范型的基础上建立的，在这种范型中：人扮演角色，资源执行活动，从而产生制品。这个过程模型表明了角色、活动和制品之间的相互关系。而状态表说明在给定的时间内，每个制品完成情况的信息。
过程包含以下7种类型的要素。
(1) 活动：过程中将要发生的事情。该要素可以与下面几项相关联：该活动前后发生的事情、所需的资源、使活动开始的触发器、支配活动的规则、如何描述算法以及得到的经验教训，以及如何将该活动与项目团队联系起来。
(2) 序列：活动的顺序。序列可用触发器进行描述，也可以用程序结构、转换、排序或满足的条件来描述。
(3) 过程模型：是关于系统兴趣的观点。因此，部分过程可以用单独的模型表示，或者用以预测过程行为，或者用以检查某些特性。
(4) 资源：必要的项、工具或人员。资源可以包括设备、时间、办公空间、人员、技术，等等。过程模型确定每个活动对于每一个资源所需的数量。
(5) 控制：施加于过程执行的外部影响。控制可以是手工的或自动的、人工的或机械的。
(6) 策略：指导原则。它是影响过程执行的高层的过程约束，可能包含一个规定的开发过程、必须使用的工具或强制性的管理模式。
(7) 组织：过程代理的层次化结构，使物理的分组与逻辑分组及相关角色相对应。从物理分组到逻辑分组的映射必须足够灵活以便反映物理环境的变化。
过程描述本身具有若干层次的抽象，包括软件开发过程（它指导特定资源用于构造特定的模块）以及类似于螺旋模型或瀑布模型的一般模型。Lai表示法包括若干模板，例如，记录特定制品信息的制品定义模板。
Lai方法可以用于软件开发过程建模。在本章后面的论述中，我们将利用它为开发过程所涉及的风险建模。为了演示如何使用它以及它表示复杂活动多方面信息的能力，我们把它应用到相对简单、但又十分熟悉的过程中：驾驶汽车。表2-1是对这个过程中的关键资源——汽车（car）——的描述。
定义一个过程就是定义：角色、活动（活动改变状态）和制品间相互关系
其他的模板定义了关系、过程状态、操作、分析、动作和角色。绘制的图表示要素之间的相互关系，保存主要关系和次要关系。例如，图2-11说明启动汽车的过程。“initiate”框表示进入条件，“park”框表示退出条件。条件框中的左列列出了制品，右列列出了相应制品的状态。
转换图是对过程模型的补充，它说明状态之间是如何联系的。例如，图2-12显示了汽车的状态转换。
4.2 动态建模
过程模型的一个良好特性就是演示过程的能力，这样，随着活动的发生，我们就可以观察资源和产品发生了什么情况。换言之，我们想要描述这个过程的模型，并且在软件向我们展示资源流是如何通过活动成为输出的时候可以进行观察。这种动态过程的视图使我们能够模拟过程，并在实际消耗资源之前能够进行修改。例如，可以使用动态过程模型帮助我们确定需要多少名测试人员及必须何时启动测试才能够按进度完成。同样，可以增加或去除活动，看一看它们对工作量和进度的影响。例如，可以增加一个代码评审活动，对评审过程中发现的故障数量做出假设，以便确定评审是否明显地减少了测试时间。
建立动态过程模型的方法有很多种。Forrester于20世纪50年代提出了系统动力学方法。该方法在模拟不同的过程（包括生态、经济和政治系统）中一直很有用（Forrester 1991）。Abdel-Hamid和Madnick曾把系统动力学方法应用到软件开发中，使项目经理在开发人员中强行推行过程之前，能够对他们的过程选择进行“考验”（Abdel-Hamid 1989；Abdel-Hamid and Madnick 1991）。
要了解系统动力学方法是如何运作的，可以考虑一下软件开发过程是如何影响生产率的。我们可以构建包括开发人员时间在内的各种活动的描述性模型，然后考虑模型中的变化是怎样增加或减少设计、编写和测试代码所用的时间的。首先，必须确定哪些因素对总生产率有影响。图2-13描述了Abdel-Hamid对这些因素的理解。箭头表明一个因素中的变化是如何影响另一个因素中的变化的。例如，如果在分配给项目的人员中，有经验的职员所占比例从1/4增加到1/2，那么，我们预期平均生产率也会有所提高。同样，职员所占的比例越大（反映在职员规模上），那么用于项目团队成员之间交流的时间就越多（交流开销）。
从图2-13可以得知，名义平均潜在生产率受下面3种因素影响：有经验职员的生产率、有经验职员的比例以及新职员的生产率。同时，新职员必须了解这个项目。项目完成的部分越多，则新职员在他们能够成为团队中高产的成员之前，就必须了解得越多。
其他问题也会对总体的开发生产率产生影响。首先，必须考虑每个开发人员每天对项目贡献所占的比例，进度带来的压力会影响这个比例，开发人员对工作量的承受力会影响这个比例。职员规模也会影响生产率，但是职员越多，则项目团队成员用于交流信息的时间就越多。交流、动机以及潜在生产率（表示为图2-13的上半部分），三者合在一起给出了一种概括的软件开发生产率关系。
因此，使用系统动力学方法的第一步是将实证性证据、研究报告和直觉这三者结合在一起来标识这些关系。下一步是量化这些关系，量化可以包含直接的关系。例如，职员规模和交流之间的关系。我们知道，如果给一个项目分配n个人，那么可能有n(n1)/2对人员必须彼此交流和协调。对某些关系，尤其是那些涉及随时间变化的资源的关系，必须进行一些分配来描述资源的增加和减少。例如，在一个项目中，很少会出现每个人都在第一天开始工作的情况。系统分析员首先开始工作，当大量需求和设计构件文档化之后，编程人员才加入到项目中。因此，这种分配就描述了资源的增加和减少（甚至是波动，例如节日或暑假的出勤率）。
一个系统动力学模型可能包含大量信息并且非常复杂。例如，Abdel-Hamid的软件开发模型包含100多个因果链接，图2-14给出了他所定义的关系的总体描述。他定义了影响生产率的4个主要方面：软件生产、人力资源管理、计划以及控制。生产包括质量保证、学习和开发速率等相关问题。人力资源强调雇用、人事变动和经验。计划关心进度安排和由此带来的压力，而控制则强调过程测度和完成项目所需的工作量。
由于系统动力学模型中链接的数目可能相当大，所以存在一些支持软件可以获取链接和它们的量化描述，从而可以模拟整个过程或某些子过程。
系统动力学模型的强大功能给人们留下了深刻的印象，但是必须谨慎地使用这个方法。模拟的结果依赖于量化的关系，但量化的关系常常是启发式的或含糊不清的，它不是明确基于实证性研究的。然而，正如我们在后面的章节中将要看到的那样，使用一个包含开发各方面的测度信息的历史数据库，有助于我们对关系的理解，从而对动态模型的结果更有信心。
如果觉得对你有帮助，麻烦点个赞啦~~~·
