| 作业要求 | 链接 |
|---|---|
| 作业要求 | https://edu.cnblogs.com/campus/jssf/infor_computation17-31/homework/10584 |
| 课程目标 | 讨论软件开发方法的思潮 |
| 参考文献 | https://www.cnblogs.com/xinz/p/3852390.html |
| 作业正文 | https://www.cnblogs.com/TG1999/p/12652937.html |
作业要求
迄今为止，我们了解了不少软件工程的方法论。请从下表挑选几篇关于软件工程方法论的文章，仔细阅读（包括相关的讨论），根据你的软件工程经验分享你的看法。
https://www.cnblogs.com/xinz/p/3852390.html
看法：
瀑布模型
瀑布模型（Waterfall Model） 是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。包括软件工程开发、企业项目开发、产品生产以及市场销售等构造瀑布模型。
瀑布模型有以下优点
1）为项目提供了按阶段划分的检查点。
2）当前一阶段完成后，您只需要去关注后续阶段。
3）可在迭代模型中应用瀑布模型。
增量迭代应用于瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本,同时增加更多的功能。每次迭代必须经过质量和集成测试。
4）它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
瀑布模型有以下缺点
1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
4）瀑布模型的突出缺点是不适应用户需求的变化。
敏捷开发
敏捷软件开发（英语：Agile software development），又称敏捷开发，是一种能应对快速变化需求的软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发过程中人的作用。
1.敏捷方法是适应性而非预测性的。 工程方法倾向于尝试在很长一段时间内详细计划软件过程的很大一部分，这在情况发生变化之前一直很好。因此，他们的天性是抵抗变化。但是，敏捷方法欢迎改变。他们试图成为适应并繁荣发展的过程，甚至达到改变自己的地步。
2.敏捷方法以人为本，而不是以过程为导向。工程方法的目标是定义一个流程，该流程无论碰巧正在使用该流程的人，都能很好地工作。敏捷方法断言，任何流程都无法构成开发团队的技能，因此流程的作用是支持开发团队的工作。
总结：
我认为，我们最终还是得倚重开发者的能力，这才是个更重要的考量因素，而非选择哪门语言或纠结于方法论间的细微差别。坦诚地说，我们都清楚这点，但我们看起来好像过度纠结于开发能力是关键因素这事儿上。或许这是个经济学里一个被广泛接受的观点的引申，要是人人都可以替代（随便找个人都能顶上），那该有多好呀？但事实并非如些。所以，无论方法是再好，最后还是落到个人头上，能合理发挥出来个人效果便足以。
作为有理想的软件工匠，我们一直身体力行，提升专业软件开发的标准，并帮助他人学习此工艺。通过这些工作，我们建立了如下价值观：
不仅要让软件工作，
更要 精益求精
不仅要响应变化，
更要 稳步增加价值
不仅要有个体与交互，
更要 形成专业人员的社区
不仅要与客户合作，
更要 建立卓有成效的伙伴关系
也就是说，左项固然值得追求，右项同样不可或缺
摘自http://manifesto.softwarecraftsmanship.org/#/zh-cn