开发过程模型
瀑布模型
简介：
将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作，形如瀑布流水，最终得到软件产品。其过程是将上一项活动的输出作为该项活动的输入，利用这一输入实施该项活动应完成的内容，然后对当前活动的工作结果进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。
瀑布模型的优点：
- 为项目提供了按阶段划分的检查瀑布模型查点。
- 当前一阶段完成后，只需要去关注后续阶段。
- 可在迭代模型中应用瀑布模型。
- 它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
瀑布模型的缺点：
- 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
- 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
- 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
- 瀑布模型的突出缺点是不适应用户需求的变化。
- 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。
瀑布模型的适用范围：
每一阶段非常的明确，所以需求也需要明确，这样接下来的运行步骤才不会有偏差
原型开发
简介
在开发真实系统之前，通过构建一个可以运行的软件原型，使开发人员与用户达成共识，以便理解和澄清问题，最终在确定的客户需求基础上开发客户满意的软件产品。
根据运用原型的目的和方式不同，可以将原型模型分为快速原型模型（抛弃型）和原型进化模型（渐进型）。
1.快速原型模型
快速原型模型是原型模型在软件分析、设计阶段的应用，用来解决用户对软件系统在需求上的模糊认识，或用来试探某种设计是否能够获得预期结果。
快速原型模型具有以下一些特点：
- 快速原型是用来获取用户需求的，或是用来试探设计是否有效的。一旦需求或设计确定下来了，原型就将被抛弃。因此，快速原型要求快速构建、容易修改，以节约原型创建成本、加快开发速度。快速原型往往采用一些快速生成工具创建，例如 4GL 语言。目前，Microsoft Visual Basic、Inprise Delphi 等基于组件的可视化开发工具，也被应用于原型创建之中，并且都是非常有效的快速原型创建工具，而且还可用于原型进化。
- 快速原型是暂时使用的，因此并不要求完整。它往往针对某个局部问题建立专门原型， 如界面原型、工作流原型、查询原型等。
- 快速原型不能贯穿软件的整个生命周期，它需要和其他的过程模型相结合才能产生作 用。例如，在瀑布模型中应用快速原型，以解决瀑布模型在需求分析时期存在的不足。
2.原型进化模型（演化模型）
原型进化对开发过程的考虑是，针对有待开发的软件系统，先开发一个原型系统给用户使用，然后根据用户使用情况的意见反馈，对原型系统不断修改，使它逐步接近并最终到达开发目标。跟快速原型不同的是，快速原型在完成需求定义后将被抛弃，而原型进化所要创建的原型则是一个今后将要投入应用的系统，只是所创建的原型系统在功能、性能等方面还有许多不足，还没有达到最终开发目标，需要不断改进。
原型进化的工作流程如图所示。
从图中可以看到，它具有以下两个特点：
- 原型进化模型将原型用于开发的全过程，原型由最基本的核心开始，逐步增加新的功能和新的需求，反复修改反复扩充，最后发展为用户满意的最终系统。
- 原型进化模型是通过不断发布新的软件版本而使软件逐步完善的，因此，这种开发模式特别适合于那些用户急需的软件产品开发。它能够快速地向用户交付可以投入实际运行的软件成果，并能够很好地适应软件用户对需求规格的变更。原型进化模型能够适应软件需求的中途变更，但在应用的时候，以下问题需要得到足够的重视。
缺点：
- 原型进化模型虽说使开发进程加快了，但不能像瀑布模型那样提供明确的里程碑管理，随着开发过程中版本的快速更新，项目管理、软件配置管理会变得复杂起来，管理者难以把握开发进度。因此，对于大型软件项目，原型进化模型缺乏有效的管理规程。
- 开发过程中软件版本的快速变更，还可能损伤软件的内部结构，使其缺乏整体性和稳定性。另外，用于反映软件版本变更的文档也有可能跟不上软件的变更速度。这些问题必将影响到今后软件的维护。
适用范围：
与客户的沟通与了解快速了解需求，画出原型图，实现软件的快速开发与迭代，可接受多次交付时采用
增量模型
简介：
增量模型是一种分步开发的模型。它集成了瀑布模型的顺序特征和迭代模型的迭代特性。一般情况下，先针对一个大型的产品进行精细化设计，将复杂项目进行合理的阶段性功能拆分，然后每一个阶段的功能产品都使用瀑布模型开发，并且交付的子功能产品成果。每个阶段(B)都在前一个阶段(A)实现的功能基础上进行迭代开发，多个功能阶段迭代完毕后，就可以将最终完善的产品交付给用户了。
优点：
- 在保证项目目标的方向上，产品交付时间比瀑布模型短
- 在保证交付时间的标准上，产品功能目标比迭代模型好
缺点：
- 精细设计程度：在产品功能设计的时候，要把控好阶段性子功能的边界，对需求经常大变动的项目不太适合
- 阶段性依赖：当前(B)阶段是前一个(A)阶段功能产品的基础上进行的，而且当前(B)阶段功能开发的过程中，不能破坏前一个(A)阶段的功能
- 团队水平：项目研发过程中，功能需求变动频繁导致风险增多，这对领导/组织者水平要求要高一些，软件研发团队的综合应变水平也有一定的要求。
适用范围：
- 大部分项目早期使用增量模型，可以规避技术风险。
- 交付时间紧张、人员不足的项目场景都可以。
- 项目比较大，且需求不会有较大变动
螺旋模型
简介：
螺旋模型很像我们高中时候学习的四象限它分为制定计划，风险分析，实施工程和客户评估阶段，整个螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。
优点：
- 设计上的灵活性,可以在项目的各个阶段进行变更
- 以小的分段来构建大型系统,使成本计算变得简单容易。
- 客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性。
- 随着项目推进,客户始终掌握项目的最新信息 , 从而他或她能够和管理层有效地交互。
- 客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。
缺点：
- 很难让用户确信这种演化方法的结果是可以控制的。
- 建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求。
适用范围：
大型项目，且风险较大的项目需要严格把控软件设计，推动项目进行的
软件测试概念
软件失效
·软件失效是指软件运行时产生的一种不希望或不可接受的外部行为结果。
软件缺陷
·软件缺陷包括软件未达到产品说明书标明的功能，软件出现了产品说明书指明不会出现的错误，软件功能超出产品说明书指明范围等。
软件测试目的
·1. 软件缺陷包括软件未达到产品说明书标明的功能，软件出现了产品说明书指明不会出现的错误，软件功能超出产品说明书指明范围等。
·2. 测试的目的之二是想以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正各种错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的商业风险。
PV信号量
对于信号量，可以认为是一个仓库，有两个概念，容量和当前的货物个数。
P操作从仓库拿货，如果仓库中没有货，线程一直等待，直到V操作，往仓库里添加了货物，为了避免P操作一直等待下去，会有一个超时时间。
V操作往仓库送货，如果仓库满了，线程等待，直到有P操作，从仓库中拿走货物，有空的位置。
创建信号量，设置容量，先有V操作，才能P操作。
P操作：货物个数减1，减过之后，货物个数大于等于0，说明已经拿到货物，线程继续。否者线程阻塞。
V操作：货物个数加1，加过之后，货物个数小于等于容量，说明添加成功，线程继续。否者线程阻塞。
信号量：0≤ 信号量≤容量 ，取值 表示当前可以使用的货物；
信号量<0 ，取值 表示当前等待使用货物的线程；
信号量>容量 ， 信号量-容量 表示当前等待添加货物的线程。
通常，信号量的容量设置很大，可以一直V操作，不会阻塞，但是P操作的时候，很可能阻塞。
当容量为1，也就是互斥，执行流程必定是V操作，P操作，V操作，P操作…
资源分配
解题思路：理解上述资源分配图，结合先分配后申请的规则判断是否堵塞
图为一个资源分配图，图中有3个节点，3个资源，从资源到节点的箭头表示系统分配一个资源给节点，从节点到资源的箭头表示节点申请一个资源，特别要注意的是先分配后申请的关系，图中系统先从R2分配一个资源给P1，P1再从R2申请一个资源。理解上面的关系后这道题目就不难了，可以看到，R1分配了一个资源给P1，又分配了一个资源给P3，P2再从R1申请资源，故P2阻塞，R2分配了3个资源给P1、P2、P3，但P1还从R2申请资源，故P1也阻塞，R3只分配一个资源给P2，R3有2个资源，故可以满足P3的申请，故P3不阻塞。