1.增量模型中如何确保增量部分不破坏已开发的部分，不引入新的错误？以及在原型模型等中，用户需求实时更新，意味着最初产品与最终产品相去甚远，更改过程必然十分繁琐、麻烦（比如我们在写很小型很小型的算法代码时，有时由于前期思考方案存在问题，在改善代码甚至换种方法解题的过程中，更改代码付诸的时间很多且容易遗漏小细节，影响代码质量，从而通常会选择重新编写。但对于规模较大的软件，更改的工程量太过浩大，浪费人力物力），为什么不能选择应用某种软件，该软件能够绘制出整体软件的界面、功能等一系列用户可视觉接触到软件的整体用户架构，将这个图片或视频集作为初步产品展现给用户？当然这个初步产品也应当迭代式更改，再根据最后蓝图开发软件。（一定是根据需求分析、可行性计划作出的符合实际开发能力以及用户要求的蓝图）。我知道不能这样，只是不太清楚为什么不可以？

源自书本第一章

原文：（1）原型模型：演化过程中，用户都能及时参与，相当于把维护阶段提前到原型的迭代过程中。由于最初的原型可能离用户最终的系统差别很大而被抛弃，因此原型模型不适宜开发大型软件项目，并且被抛弃的系统原型的开发成本也影响到原型模型的采用。此外，由于原型模型实在需求不明确的情况下进行开发的，因此原型质量及由此产生的问题也难以得到保证。

（2）增量模型是对软件项目中的功能以一系列增量的方式来开发，也称为渐增式开发模型。增量模型是一种非整体开发模型，对于系统整体需求，增量模型先将需求分解为若干部分，每个部分都按照瀑布模型方法进行开发。

增量模型不是在开发末期给出软件的全部，而是逐步提交用户系统中可用的部分，系统功能会随着时间而增加，同时通过用户反馈不断修正原来系统中存在的错误与不足。由Mils、Dyer和Linger提出的净室软件开发方法使用的就是增量模型。

增量模型具有以下特点：

①、灵活性：由于软件开发是以系统的一个子集来进行的，用户能尽早对系统有直观认识。并且由于每次提交的是软件的部分功能，因而可以按照用户需求有选择地先开始系统中重要部分的分析与设计，同时也给开发时间、资源利用等资源带来很大灵活性。

②、降低风险。由于增量模型每次提交的仅是系统的部分功能，因而适用于需求不明确、开发功能多、开发时间长的系统。即使系统出现错误，但由于用户尽早地参与了开发过程，从而使错误的影响范围有限。

由于软件系统的整体结构是设计好的，在增量模型中逐步增加系统功能时，如何确保增量部分不破话已开发的部分，或不引入新错误？此外，如何适应用户需求的变更？这不仅要针对增量部分进行修改，也要完成对已开发部分的变更。

资料：

增量模型缺点:

要求每个新的增量构件能够无缝地集成到现有的软件体系结构中, 必须不破坏原来已经开发的产品; 因此软件体系结构必须是开放的,增加了设计阶段的投入;本身具有矛盾性, 一方面要求开发人员把软件看作一个整体, 另一方面要求开发人员把软件看作构件序列, 且构件间彼此独立。需要开发人员协调这一矛盾。