搞工程开发大型软件那可是一件特别重要的事，需要正确的管理和技术，这些经过时间考验可是很不容易的。下面就来好好说说相关情况
软件生存期剖析：软件这东西，它也有自己的一生，就跟人一样。从最开始概念冒出来，就像咱们人的出生有个最初的想法一样，然后经过项目定义、决策，再到不停地分析呀设计一点点把这个软件搞成功，让它投入使用。在使用过程中还得不断修改改进，就像人也需要不断成长完善自己一样，一直到最后有新的软件来顶替它，它就完成使命。这个整个过程就是软件生存期，从生到“死”就这么完
软件生存周期模型本质：这个生存周期模型，主要是说软件开发时候各种活动具体咋执行的这么一个模型。但是它也是有不少毛病的。比如说这各阶段之间那顺序那是相当严格，还特别看重提前把需求给定义好。必须得在动手开发之前，先把那个软件需求通过需求分析给弄好，还得“冻结”住，然后就一步接着一步去实现这些需求。要是想变也难就跟被钉死了一样
传统瀑布模型弊端：传统的这个瀑布模型，要是碰到那种需求老是变、模模糊糊不确定的软件系统开发，那可就犯难。因为客户很多时候自己也说不清楚所有的需求在开发过程中，用户又很难参与进去，一直得等到开发完成了才能看到整个软件系统，就感觉这开发就像闭门造车，等车都造好了发现不是想要的样子，那得多闹心。
增量模型实用特点：增量模型可就不一样它厉害的地方就是允许提前开发。把整个需求分成一段一段的来开发，每一段都相当于一个小的瀑布模型，在现代企业里用得可多，像微软的系统就是这么干的。它是那种非整体开发模型，有些阶段的节点它给往后推推，能比较早地就产出能用的软件来。这么一看是不是还挺灵活的
原型法局限缺点：这个原型法，虽然有它自己的优点，但是也有好多限制。比如说它就不适合用来开发大型的信息系统。开发出来的系统，后期维护也比较难。要是用户配合得不好，只知道盲目纠错，那开发进度可就会被拖得老长老长而且对开发人员去创新也不是太有利
原型法适用场景：原型法也不是哪儿都能使得，还是有它适用的地儿的。像那种用户需求不太清楚、管理还有业务不稳定，需求老是变化的情况，或者规模比较小、不太复杂的，还有像开发信息系统的最终用户界面的时候，就还挺合适的。还有就是当用户的软件资源没被组织管理好的时候，因为MIS里面的模型、模块、使用设施还有程序的难易程度对原型使用挺关键的。
各位读者你觉得软件开发中哪种模型更能适应未来的需求变化？
