计算与软件工程 作业五

作业要求	https://edu.cnblogs.com/campus/jssf/infor_computation17-31/homework/10584
课程要求	学习软件开发知识
参考文献	https://www.cnblogs.com/xinz/p/3852390.html
作业正文	https://www.cnblogs.com/zfy8/p/12653976.html

讨论软件开发方法的思潮

大泥球

大泥球，是指杂乱无章、错综复杂、邋遢不堪、随意拼贴的大堆代码。这些年来，为了对付这个泥球，我们看到了多种指导方法，比如SOLID 、GRASP 和KISS ，与其他诸多年代久远的、提倡高内聚、低耦合的方法一起出现。这种情况常常出现在时间和预算限制的情况下，软件开发者无暇将设计做到完美就匆忙开始发行第一个版本。在这种情况下应该加强对代码的控制，比如团队中加强对代码的严格的管理，增加代码的复审以提高正确率和代码可读性。
文中作者拿软件构建和建筑做类比：软件架构师对应于建筑设计师，要做整体规划，设计“建筑图纸”；开发人员则与施工人员相对应，做具体的构建工作。

瀑布模型

瀑布模型（Waterfall Model） 是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。包括软件工程开发、企业项目开发、产品生产以及市场销售等构造瀑布模型。
1970年温斯顿·罗伊斯（Winston Royce）提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。
核心思想：瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

优点：

（1）为项目提供了按阶段划分的检查点。
（2）当前一阶段完成后，您只需要去关注后续阶段。
（3）可在迭代模型中应用瀑布模型。增量迭代应用于瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本,同时增加更多的功能。每次迭代必须经过质量和集成测试。
（4）它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。

缺点：

（1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
（2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
（3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
（4）瀑布模型的突出缺点是不适应用户需求的变化。

敏捷开发

敏捷软件开发（Agile software development），又称敏捷开发，是一种从1990年代开始逐渐引起广泛关注的新型软件开发方法，是一种能应对快速变化需求的软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发过程中人的作用。
敏捷软件开发描述了一套软件开发的价值和原则，在这些开发中，需求和解决方案皆通过自组织跨功能团队达成。敏捷软件开发主张适度的计划、进化开发、提前交付与持续改进，并且鼓励快速与灵活的面对开发与变更。这些原则支援许多软件开发方法的定义和持续进化。

四条原则

（1）递增，而不是连续的：如果开发实践是真正的敏捷精神，那么交付的工作软件是一小部分一小部分递增的。不必等到一个阶段完全完成后才开始另一个，工作也不是向大的发布日期而努力。完成的工作，但并不是业务最终期限，驱动着敏捷交付。但敏捷精神也承认业务操纵着最后截止日期。
（2）避免不必要的开销：如果实践仍然是真正的敏捷精神，那么团队就致力于尽可能多地减少项目计划和文档。与其讨论要做什么，然后再写下来，不如赶紧动手去做，否则，就是在浪费时间在工作的工作上。在工作对工作中，敏捷精神有利于实际的工——作交付工作软件。而且它也值面对面的交流通过邮件和其他书面文件。
（3）协作：根据需求，团队成员一直与其它人进行交互，以及一些外部利益相关者。在敏捷教练世界中，整个团队的负责人Lisa Crispin能够解决所有问题，在问题出现之前 。真正的敏捷精神团队是自助的。他们分配需要做的工作。虽然每个成员承担的任务都在他们的专业技能范围内，他们还是需要与团队协作的。没有人的工作是孤立的，也没有团队本身是独立工作的。没有业务利益相关者，以及诸如用户体验方面的外部专家的重大投入，团队就不可能使项目向前发展，
（4）说真话：为了保证真正的敏捷，团队探讨的与项目相关的一切都要是真实的。在一些至关重要的专业领域，如冲刺测试的编码技能，他们承认存在差距。关于实际生产力，他们的要讲事实；这也就是说，在y时间内，团队是否有能力做到x。他们承认错误。说真话是一项挑战，因为他们害怕承认缺点会让他们显得很弱。但敏捷精神知道说出事实需要勇气。承认问题需要信心，然后快速地去解决问题。

对比瀑布式开发

两者没有很多的共同点，瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。
瀑布式的主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。
相对来讲，敏捷方法则在几周或者几个月的时间内完成相对较小的功能，强调的是能将尽早将尽量小的可用的功能交付使用，并在整个项目周期中持续改善和增强。

大教堂模式

大教堂模式（The Cathedral model）：源代码在软件发行后公开，但在软件的每个版本开发过程中是由一个专属的团队所控管的。

市集模型

市集模式（The Bazaar model）：源代码在开发过程中即在互联网上公开，供人检视及开发。

总结

软件工程方法论可分为重量级方法与轻量级方法。量级方法呈现的是一种“防御型”的姿态。在应用“重量级方法”的软件组织中，由于软件项目经理不参与或者很少参与程序设计，无法从细节上把握项目进度，因而会对项目产生“恐惧感”，不得不要求程序员不断撰写很多“软件开发文档”。
轻量级方法则呈现“进攻型”的姿态，这一点从XP方法特别强调的四个准则—“沟通、简单、反馈和勇气”上有所体现。目前有一些人认为，“重量级方法”适合于大型的软件团队（数十人以上）使用，而“轻量级方法”适合小型的软件团队（几人、十几人）使用。