软件项目管理 --- week 1 formal model

week 1 

1.Project Management Methodologies

formal model

1.1 waterfull 

参考：https://blog.csdn.net/ningmengban/article/details/75059086

 1.1.1 介绍：

   这种模式有明确的阶段活动，阶段顺序固定，自上而下、相互衔接，形如瀑布流水逐级下落。

瀑布模型的本质是一次通过，即每个活动只执行一次，最后得到软件产品，也称为“线性顺序模型”或者“传统生命周期”。    

    其过程是上一个阶段的工作完成输出结果并通过审核，才能“流动”到下一个阶段；否则返回前面，甚至更前的阶段活动。基于这种模型太过强调文档的作用，过程太理想化，在项目运用过程中，它以下的弊端就很突出：  

   各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。

   单一流程，不可逆，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。

   测试只是其中一个阶段，缺乏全过程测试思想。早期的错误可能要等到开发后期的测试阶段才能发现，发现问题越晚造成代价越高。

   在软件需求分析阶段，完全确定用户的所有需求是比较困难的，不能应对需求不断变更的项目

1.1.2 优点

• 为项目提供了按阶段划分的检查点。

• 当前一阶段完成后，您只需要去关注后续阶段。

1.1.3 缺点

• 需求很明确的软件开发项目；

• 在开发时间内需求没有或很少变化；

• 分析设计人员应对应用领域很熟悉；

• 低风险项目（对目标、环境很熟悉）；

• 用户使用环境很稳定；

• 用户除提出需求以外，很少参与开发工作。

 

1.2 Incremental Model 

增量模型（Incremental Model）

　　又称演化模型。与建造大厦相同，软件也是一步一步建造起来的。在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成. 增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件，开发人员逐个构件地交付产品，这样做的好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。

但是，增量模型也存在以下缺陷：

 （1） 由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。　　

（2） 在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。

解释：在使用增量模型时，第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后，经过评价形成下一个增量的开发计划，它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复，直到产生最终的完善产品。　　

例如，使用增量模型开发字处理软件。可以考虑，第一个增量发布基本的文件管理、编辑和文档生成功能，第二个增量发布更加完善的编辑和文档生成功能，第三个增量实现拼写和文法检查功能，第四个增量完成高级的页面布局功能

参考：https://www.cnblogs.com/allenblogs/archive/2011/05/31/2064063.html

 

1.3 V Model

  是我们熟知的瀑布模型的一种改进，瀑布模型（Waterfall Model）将软件生命周期划分为计划、分析、设计、构建、测试和维护六个阶段，且规定了它们自上而下、相互衔接的固定次序，由于早期的错误可能要等到开发后期的测试阶段才能发现，所以带来严重的后果。 v-model就是在这点改进了瀑布模型，在软件开发的生存期，开发活动和测试活动几乎同时的开始，这两个并行的动态的过程就会极大的较少bug和error出现的几率。在v-model中，我认为一个关键词就是parallel，说起来简单，却是v-model的核心。

 v-model包含了三个等级，分别是生存期模型，分配模型，功能性工具需求模型，生存期模型回答了“What has to be done?”的问题，阐述了应当实施哪些活动，应当产生哪些结果，诸如此类。分配模型回答了“How is it be done”，决定了在实施活动的时候应该使用什么方法，功能性工具需求模型回答了“What is used to do it”，采用什么样的工具来实现这些活动。所有这些等级中又是由4个子模块组成的，分别是项目管理模块(PM)，系统开发模块(SD)，品质保证模块(QA)，配置管理模块(CM)，这些模块的功能就显而易见了

 

测试对目的：

单元测试所检测代码的开发是否符合详细设计的要求。

集成测试所检测此前测试过的各组成部分是否能完好地结合到一起。

系统测试所检测已集成在一起的产品是否符合系统规格说明书的要求。

而验收测试则检测产品是否符合最终用户的需求

 

V模型的缺陷
仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段
忽视了测试对需求分析,系统设计的验证，一直到后期的验收测试才被发现。

参考：https://blog.csdn.net/galaft/article/details/2307393

 

1.3 prince 2

1.3.1 介绍

每一个流程都详细标出关键的输入、输出和具体目标及要执行的活动，这为计划偏差提供了自发的控制。依靠严格的监控，项目在控制和组织的方式下得到执行。

参考：https://zh.wikipedia.org/wiki/PRINCE2