软件工程第五次作业

第五次作业 讨论软件开发方法的思潮

作业要求的链接	https://edu.cnblogs.com/campus/jssf/infor_computation17-31/homework/10584
该次作业在程序效能方面实现我的目标	代码规范复审和两人合作结对编程
其他参考文献	https://www.cnblogs.com/xinz/p/3852390.html http://www.laputan.org/mud/ https://baike.baidu.com/item/敏捷软件开发/7108658?fr=aladdin https://blog.csdn.net/xiajun2356033/article/details/81513957 https://baike.baidu.com/item/瀑布模型/9817778?fr=aladdin http://www.51sjk.com/b1b87850/ https://www.ituring.com.cn/article/9363
作业正文	https://www.cnblogs.com/taotaochen/p/12658472.html

1 Big Ball of Mud

 大泥球是指一个随意化的杂乱的结构化系统，只是代码的堆砌和拼凑，往往会导致很多错误或者缺陷。这使得系统内的信息无法得到更好的控制和共享，使得信息失去了应有的价值。大泥球复杂和杂乱无章。最终会使得这个系统的代码不被程序员理解，更无法对其修复，无法满足用户的需求变化。
 即使具有明确定义的体系结构的系统也容易受到结构侵蚀。任何成功的系统所吸引的不断变化的需求的无情攻击会逐渐破坏其结构。过去整洁的系统随着PIECEMEAL GROWTH的增长而变得过分生长，逐渐允许系统的元素以不受控制的方式蔓延。如果这种蔓延持续不减，则系统的结构可能会受到严重损害，必须放弃。就像一个腐烂的社区一样，随之而来的是螺旋式下降。由于系统变得越来越难以理解，因此维护变得更加昂贵且更加困难。好的程序员拒绝在那里工作。投资者撤资。
 一种开始控制下降的简单方法是封锁枯萎的区域，并在其周围放置有吸引力的外墙。我们称这种策略为“扫荡”。在更高级的情况下，可能别无选择，只能拆除一切并重新开始。当有必要进行全面重建时，剩下的就是可以作为经验基础的模式。
 谴责大泥巴不是我们的目的。在系统发展的早期阶段，休闲架构是很自然的。读者当然必须怀疑，我们的希望是我们可以渴望做得更好。通过认识到导致建筑瘫痪的力量和压力，以及如何以及何时面对它们，我们希望为真正耐久的文物的出现做好准备，这些文物可以使建筑师在未来几年中占据主导地位。关键是要确保随着系统的成长和成熟，系统，其程序员以及整个组织，甚至是整个领域，都将了解该领域以及即将出现的架构机会。

2 敏捷软件开发

 敏捷开发是一种从1990年代开始逐渐引起广泛关注的新型软件开发方法，是一种能应对快速变化需求的软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于"非敏捷"，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重做为软件开发中人的作用。

敏捷12原则

1. 我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
2. 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
3. 要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
4. 项目过程中，业务人员与开发人员必须在一起工作。
5. 要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
6. 无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
7. 可用的软件是衡量进度的主要指标。
8. 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持持续稳定的进展速度。
9. 对技术的精益求精以及对设计的不断完善将提升敏捷性。
10. 要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
11. 最佳的架构、需求和设计出自于自组织的团队。
12. 团队要定期反省如何能够做到更有效，并相应地调整团队的行为。
    符合敏捷价值观及原则的主流敏捷开发方法包括：极限编程（eXtreme Prgramming），精益软件开发（Lean Software Development），动态系统开发方法（DSDM）,Scrum等等。
    （摘自https://www.cnblogs.com/pangguoming/p/9504254.html）
    
    （图片来源https://blog.csdn.net/xiajun2356033/article/details/81513957）

3 瀑布模型

 瀑布模型是一个经典的软件生命周期模型，也叫预测型生命周期、完全计划驱动型生命周期。在这个模型里，在项目生命周期的尽早时间，要确定项目范围及交付此范围所需的时间和成本。
 在这个模型里，项目启动时，项目团队专注于定义产品和项目的总体范围，然后制定产品（及相关可交付成果）交付计划，接着通过各阶段来执行计划。应该仔细管理项目范围变更。如果有新增范围，则需要重新计划和正式确认。对于经常变化的项目而言，瀑布模型毫无价值。    
 以下情况优先选择这种生命周期：项目需求明确、充分了解拟交付的产品、有厚实的行业实践基础、或者整批一次性交付产品有利于干系人。
 例如开发一个软件项目时，如果采用这个模型的话，一般将软件开发分为可行性分析（计划）、需求分析、软件设计（概要设计、详细设计）、编码（含单元测试）、测试、运行维护等几个阶段，如下图所示。

原文链接：https://blog.csdn.net/iblade/article/details/80631153

4 集市

 市集模式（The Bazaar model）：源代码在开发过程中即在互联网上公开，供人检视及开发。作者以Linux核心的创始者林纳斯·托瓦兹带领Linux核心的开发为例，亦引用fetchmail的开发为例。
 采用集市模式开发软件的一些必要条件是Internet源码开放、遵循GPL规则.不以经济利益为追求目标等等。这是开放源码 / 自由软件运动的特征. 所以集市模式对于开放源码软件的开发是一种适宜、有生命力并有成效的开发模式,可以全力采用, 当然要获得成功仍需多方面的努力。
参考文献 （集市模式_是一种新的软件工程方法吗_孙玉芳http://www.cnki.com.cn/Article/CJFDTotal-JSJA200205006.htm）