计算机与软件工程 第五次作业

瀑布

瀑布模型的其核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。瀑布模型将软件生命周期划分为软件计划、需求分析和定义、软件设计、软件实现、软件测试、软件运行和维护这6个阶段，规定了它们自上而下、相互衔接的固定次序，如同瀑布流水逐级下落。
瀑布模型有利于大型软件开发过程中人员的组织及管理，有利于软件开发方法和工具的研究与使用，从而提高了大型软件项目开发的质量和效率。
瀑布模型的优点
1）为项目提供了按阶段划分的检查点。
2）当前一阶段完成后，您只需要去关注后续阶段。
3）可在迭代模型中应用瀑布模型。增量迭代应用于瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本,同时增加更多的功能。每次迭代必须经过质量和集成测试。
4）它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。

大泥球

所谓大泥球，是指杂乱无章、错综复杂、邋遢不堪、随意拼贴的大堆代码。这些年来，为了对付这个泥球，多种指导方法一起出现，然而实际情形没多大变化，“大泥球”看起来仍然是设计软件架构的最常见方法。我们现在惯用的敏捷性开发的很多方面会直接导致泥球，包括：缺少前期设计、应对需求变化过晚、应对架构变化过晚、碎片式增长。
我认为，在这种情况下应该加强对代码的控制，比如团队中加强对代码的严格的管理，增加代码的复审以提高正确率和代码可读性。

教堂

大教堂模式（The Cathedral model）：源代码在软件发行后公开，但在软件的每个版本开发过程中是由一个专属的团队所控管的。作者以GNU Emacs及GCC这两软件为例。

集市

市集模式（The Bazaar model）：源代码在开发过程中即在互联网上公开，供人检视及开发。作者以Linux核心的创始者林纳斯·托瓦兹带领Linux核心的开发为例，亦引用fetchmail的开发为例。

银弹

人狼：西方传说中最恐怖的一种怪物，经常丛熟悉的面孔不然编程怪物，所以最难防备，用来比喻软件开发过程中遇到的种种棘手问题。
银弹：用来射杀人朗的银子弹，比喻解决软件开发过程中问题的有效方法。
*s在他最著名的《没有银弹-软件工程中本质性和偶然性》文章里指出，在软件开发过程里是没有万能的终杀性武器（即银弹）的，只有各种方法综合运用，才是解决之道。而各种声称如何如何神奇的理论或方法，都不是能杀死“软件危机”这头人狼的银弹。
而我个人也倾向于“没有银弹"的看法，软件的内在设计本身就有一定的复杂性，我认为这是必须，有时也是不可避免的。成熟的软件需要综合各个方面的考虑，实际过程中的复杂度就不是能仅仅依靠技术解决的了。

敏捷

敏捷宣言遵循的 12 条原则：

1. 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
2. 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
3. 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
4. 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
5. 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
6. 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
7. 可工作的软件是进度的首要度量标准。
8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
9. 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
10. 以简洁为本，它是极力减少不必要工作量的艺术。
11. 最好的架构、需求和设计出自自组织团队。
12. 团队定期地反思如何能提高成效，并依此调整自身的举止表现。
    敏捷开发要点
    1、注重概念和架构设计，轻详细设计
    2、使用SWOT分析法（参考：https://www.cnblogs.com/katniss-smile/p/5982643.html ）
    3、市场和需求驱动，而非技术驱动
    4、时刻考虑版本兼容性
    5、轻文档，但非无文档