| 课程要求 | (https://edu.cnblogs.com/campus/jssf/infor_computation17-31/homework/10584) |
|---|---|
| 作业目标 | 讨论软件开发方法的思潮 |
| 参考文献 | (https://edu.cnblogs.com/campus/jssf/infor_computation17-31/homework/10584) |
正文
迄今为止，我们了解了不少软件工程的方法论。请从下表挑选几篇关于软件工程方法论的文章，仔细阅读（包括相关的讨论），根据你的软件工程经验分享你的看法。
(https://www.cnblogs.com/xinz/p/3852390.html)
瀑布模型
瀑布模型是将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作，形如瀑布流水，最终得到软件产品。
1970年温斯顿·罗伊斯（Winston Royce）提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。
模型的优缺点
优点
1）为项目提供了按阶段划分的检查点。
2）当前一阶段完成后，您只需要去关注后续阶段。
3）可在迭代模型中应用瀑布模型。
增量迭代应用于瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本,同时增加更多的功能。每次迭代必须经过质量和集成测试。
4）它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
缺点
1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
4）瀑布模型的突出缺点是不适应用户需求的变化。
大泥球
大泥球 ，是指杂乱无章、错综复杂、邋遢不堪、随意拼贴的大堆代码。这些年来，为了对付这个泥球，我们看到了多种指导方法，比如SOLID 、GRASP 和KISS ，与其他诸多年代久远的、提倡高内聚、低耦合的方法一起出现。然而，实际情形没多大变化，“大泥球”看起来仍然是设计软件架构的最常见方法。
教堂
对于大型软件特别是面向行业、面向领域的应用系统采用“教堂”模式有更多的必要性和可行性.在这种大型软件的开发初期它不仅需要有软件方面的知识更需要有领域或行业的知识,还可能有其它方面的知识。而且项目的最终要求涉及方方面面.这就需要精心地作总体规则、整体设计，然后作合理分划.并且为每一部分作出详细设计,包括模块设计、数据结构设计、模块之间接口设计、用户界面设计等等;然后是组织具体编程、测试,最后是集成/测试,和试用/修改/更新,再发布新版本等一系列过程。总之.对于需要专门领域、行业知识的大型应用软件(通常是商品软件)采用教堂模式,或许有更好的结果。
集市
市集模式（The Bazaar model）：源代码在开发过程中即在互联网上公开，供人检视及开发。作者以Linux核心的创始者林纳斯·托瓦兹带领Linux核心的开发为例，亦引用fetchmail的开发为例。
银弹
Brooks在他最著名的《没有银弹-软件工程中本质性和偶然性》文章里指出，在软件开发过程里是没有万能的终杀性武器（即银弹）的，只有各种方法综合运用，才是解决之道。而各种声称如何如何神奇的理论或方法，都不是能杀死“软件危机”这头人狼的银弹。
我也倾向于“没有银弹"的看法，软件的内在设计本身就有一定的复杂性，我认为这是必须，有时也是不可避免的。成熟的软件需要综合各个方面的考虑，实际过程中的复杂度就不是能仅仅依靠技术解决的了。
敏捷
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
总结
读了这些文章，我了解了软件工程方法论的知识，认识到了为了更好地发展和改进软件工程技术，我们有必要从方法论的各个角度分析软件工程的方法、工具和过程，从而有的放矢地改进软件工程中各个过程的思想、方法、模式和规则。