计算与软件工程 作业五

博客作业

这个作业要求在哪里	第五周作业
我在这个课程的目标是	分享软件工程经验
此作业在哪个具体方面帮我实现目标	阅读文章
其他参考文献	(https://www.cnblogs.com/xinz/p/3852390.html)

我的看法

对软件工程方法论的思考

瀑布, 大泥球, 教堂，集市，敏捷和银弹

银弹

在所有充满我们民间传说恶梦的怪物中，没有比狼人更可怕的了，因为它们出乎意料地从熟悉的变成了恐怖。为了这些，人们寻找能神奇地将它们安息的银子弹。熟悉的软件项目，至少就像非技术经理所看到的那样，具有这种特性；它通常是无辜的和直截了当的，但它可能会变成一个由错过的时间表、被吹掉的预算和有缺陷的产品组成的怪物。因此，我们听到了绝望的呼声，要求一颗银弹---某种能使软件成本与计算机硬件成本一样迅速下降的东西。
要把布鲁克斯自己的比喻转向一个新的方向，就有一颗银弹。这是一种强大的武器，由巨大的经济力量推动，仅仅是技术障碍就能短暂抵抗。但正如布鲁克斯所同意的那样，这不是一项技术，一项神奇的发明，它将杀死软件狼人，而无需我们的努力，也不会对我们的价值体系和软件生产商与消费者之间的力量平衡产生巨大的副作用。
银弹是一种文化变革，而不是一种技术变革。这是一次范式转变--一场基于可重用和可互换部分的软件工业革命，它将像工业革命改变制造业一样，改变软件世界。

大泥球

即使是具有定义良好的体系结构的系统也容易受到结构的侵蚀。任何成功的系统所吸引的不断变化的需求的无情冲击可能会逐渐破坏其结构。曾经整洁过的系统随着时间的推移而变得臃肿起来。零碎增长逐渐允许系统中的元素以一种不受控制的方式蔓延。
如果这种扩张继续有增无减，系统的结构可能会严重受损，因此必须放弃。就像一个衰败的街区，随之而来的是螺旋式下降。由于系统变得越来越难理解，维护变得更加昂贵和困难。优秀的程序员拒绝在那里工作。投资者撤资。然而，和社区一样，也有办法避免甚至扭转这种衰退。和宇宙中的任何其他东西一样，对抗熵力需要能量的投入。软件士绅化也不例外。在软件中阻止熵的方法是重构它。一个持续的承诺，重构可以防止一个系统沉入一个大泥球。
系统及其组成要素以不同的速度发展。正如他们所做的那样，迅速变化的事物往往与那些变化较慢的事物不同。这个剪切层它们之间的发展就像断层线或面，有助于促进持久抽象概念的出现。
要开始控制衰退，一个简单的方法是封锁受影响的地区，并在其周围设置一个吸引人的外墙。我们称之为这种策略把它扫到地毯下面。在更高级的情况下，可能别无选择，只能把一切都拆掉，重新开始。当总数重建成为必要的，所有剩下的是拯救的模式，作为经验的基础。

敏捷

敏捷方法是自适应的，而不是预测的。工程方法倾向于在很长一段时间内详细规划大部分软件过程，直到事情发生变化为止。所以他们的本性就是抵制变化。然而，敏捷方法欢迎改变。他们试图成为适应变化并在变化中茁壮成长的过程，甚至到了改变自己的程度。
敏捷方法是面向人的，而不是面向过程的。工程方法的目标是定义一个过程，无论谁使用它，它都能很好地工作。敏捷方法断言，任何过程都不会构成开发团队的技能，因此流程的角色是支持开发团队的工作。

总结

在围绕软件开发实践和方法的宗教战争中有很多教条。阶段门方法是有效地管理软件开发的风险，还是仅仅是风险管理歌舞伎？TDD真的能创造出更高质量的软件吗？成对编程是代码评审的一个更好的替代，还是仅仅是一种提高咨询率的方法？我要说的是，虽然缺乏科学证据来决定这些说法，但有两个一般原则可以帮助我们选择好的做法，同时提高我们所提供软件的价值：缩短周期时间和增加反馈。
但传统的软件项目与常规的、可预测的环境正好相反。衡量一个项目成功的唯一标准--最终结果是否创造了其生命周期内的预期价值？--与那些导致成功或失败的关键决定相距甚远，即使是原始团队中的任何人，也很少能得到反馈。几乎不可能确定哪一个在那些导致成功或失败的决定中(在人工智能中，这被称为信用分配问题)。
这些因素使得IT专业人员很难获得成功的产品和服务的技能。相反，开发人员获得的技能使他们能够以最有效的方式实现他们受到激励的目标--通常会尽快宣布他们的工作“开发完成”，而不管这些功能是否集成和生产准备就绪，在其他功能领域也会出现类似的问题。
软件项目是复杂的系统而不是常规环境，这一事实导致了另一个问题--收集关于哪些技术、实践和方法实际有效的数据极其困难，以及在收集数据的背景之外几乎不可能概括这些数据。
事实上，从创意到反馈周期短的好处是非常重要的，因此它们应该成为您的业务模型中最重要的标准之一。3D打印可能会在这一领域产生巨大影响，因为它允许将软件开发实践应用于硬件系统的发展。在跨职能团队如果你想实现足够短的周期时间，或多或少是一项要求。