您能否给出一种可以减轻瀑布模型缺点的方法？
问问题
8618 次
6 回答
16
瀑布的问题在于它由单一的阶段组成，每个阶段都建立在前一个阶段上。因此，代码是在整个系统设计完成后的一个块中开发的，而这又是在收集并签署所有需求之后发生的。
这是一个问题，因为任何更改都必须通过复杂的程序来批准，并在所有阶段产生涟漪效应。但历史的教训是：变化发生了。在我们开始编码时，需求总是不完整的，或者指定错误的或者只是过时的。设计和构建通常基于系统到达 UAT 时无效的假设进行。这会导致疯狂的返工和滑点。
事实上，没有多少客户擅长设想一个工作软件系统所需的抽象思维。太多的 IT 专业人员缺乏理解业务逻辑所需的经验。瀑布拒绝接受这些事实。
唯一诚实的需求规范是“我看到它就知道”。因此，尽快将工作软件呈现在真实用户面前至关重要。任何专注于在短迭代中增量交付工作软件的方法都将“减轻瀑布模型的缺点”。
最初是 RAD或DSDM。然后XP打上横幅。现在有敏捷和相关的东西，比如Scrum和看板。
那么为什么人们坚持使用瀑布方法呢？
人们普遍认为，敏捷只是牛仔黑客抛弃所有无聊的过程的东西并继续他们最喜欢的事情：编写代码的掩护。“极限编程”的品牌肯定鼓励了这种想法，老实说，这不是毫无根据的指控。也就是说，一些编码人员假装敏捷作为不计划、设计或记录的借口。这并不反映敏捷的实际实践，敏捷与任何其他方法一样需要严格。
此外，敏捷需要客户员工投入更多的时间，而许多组织都不愿意接受。此外，买单的人可能不愿意授权他们的初级员工做出决定。Customer和User之间有一个重要的区别。
在外包方面，瀑布模型提供了一个简单的框架，可以将可交付成果与分阶段付款相匹配。事实上，合同方面可能比这更强大：在欧盟，所有价值 1 亿欧元或以上的项目都强制要求使用瀑布。
最后，有些项目瀑布效果很好。这些项目具有稳定的知识域，并且客户和开发人员都很好地理解了这些知识域。
遗言
尽管失败了，瀑布已经成功地交付了许多项目。这是因为努力工作、才能和正直比方法更重要。
于 2010-05-15T07:13:21.713 回答
4
The waterfall model was documented in 1970 by a Dr Winston Royce in a paper titled 'Managing the development of large Software Systems'. Basically outlining his ideas on sequential development. His idea was that software could be produced in a similar fashion to an automobile, where the vehicle is pieced together in sequential/linear phases.
This linear approach doesn't really allow for changes in a piece of software once it begins. There is no tight relationship with the end user/client so its harder to outline possible problem areas.
Its worth noting some phases of the waterfall model allow for 'splashback' whereby there is enough time in the development period to go back and make small changes. Time constraints and the amount of work involved and budgets don't really allow for much change if any to be made using this model.
The waterfall model is old, as time goes by software paradigms themselves change. Object Oriented programming is popular, back then it was barely alive. Through the use of the waterfall model its obvious that the flaws have been spotted and this has lead to the alternative development methodologies.
Ok, so now for alternatives. Incremental model is described by Alistair Cockburn(2008) as a staging and scheduling strategy in which various parts are developed at different times or rates and integrated upon completion of that specific part.
Basically incremental looks a lot like this:
Analysis->Design->Code->Test
Analysis->Design->Code->Test
Analysis->Design->Code->Test
Number of benefits include lifecycle being flexible and allowing for change from the get go. Working software or rather parts are generated quickly and early on. Code produced is earlier to test and manage due to the small iterations of progress. Not all of the requirements of the system are gathered up front, just an outline. This allows for a quick start, however it might be a disadvantage in some systems as things like the system architecture being supported might be missed.
Iterative on the other hand allows parts of the system to be reworked and revised to improve the system. Time is set aside to allow for this. Iterative does not start with a full specification of requirements. Development is done by specifying and implementing just part of the software. Software is reviewed in order to identify further requirements.This is more of a top down approach. Disadvantages with this methodology are making sure all the iterations are compatible. As each new iteration is approved, developers may employ a technique known as backwards engineering, which is a systematic review and check procedure to make sure each new iteration is compatible with previous ones.A major benefit with the constant iterations is that the client is kept in the loop and the final product should meet the requirements.
Other methodologies include Prototyping. Evolutionary and Throwaway. These are also deemed as more of a top down approach. Both process are borrowed from engineering.In engineering it is common to construct scale models of objects to be built. Building models allows the engineer to test certain aspects of the design. The software development prototyping methodology provides the same ideology. Prototyping is not seen as a standalone, complete development methodology but rather an approach to handling selected portions of a larger, more traditional development methodology.
Throwaway Prototyping - Throwaway prototyping does not preserve the prototype that has been developed. In throwaway prototyping there is never any intention to convert the prototype into a working system. Instead the prototype is developed quickly to demonstrate some aspect of a system design that is unclear. It can also be developed to help users or clients decide between different features or interface characteristics. Once any problems or uncertainty has been addressed the prototype can be ‘thrown away’ and the principles learned used in the design and documentation of the actual product.
Evolutionary Prototyping - In Evolutionary prototyping you begin by modeling parts of the target system and if the prototyping process is successful you evolve the rest of the system from those parts. One key aspect of this approach is that the prototype becomes the actual production system. This process allows for difficult parts of the system to be modeled successfully in prototypes and dealt with early on in a project.
Other areas to look into will include Agile-> SCRUM, Extreme programming, Paired programming etc.
Tried to keep it short but people write books on this sort of stuff and there is so much to discuss.
Might be worth having a look at: Incremental and Iterative
于 2010-05-15T12:59:47.290 回答
2
瀑布方法的替代方法是“以正确的方式做”。
如果您在工厂车间装配线上，瀑布似乎很有意义。但我从来没有看到它作为设计过程的一部分工作......软件开发都是一个设计过程。所以瀑布方法从来没有真正起作用，因为它无助于促进高质量产品的创造，而是专注于过程。过程可以很棒，但如果它生产的产品是二流的，那又有什么意义呢？
于 2010-11-24T14:09:08.073 回答
0
从我的脑海中，我可以想办法减轻瀑布模型的缺点：
- 让编码人员专注于自动化流程本身。自动化一个步骤和另一个步骤之间的转换，以便更改或多或少地自动流动。
- 使流程更具双向性。瀑布模型的一个主要特征是变化从上到下流动。这是一个单向的过程，这是问题的一部分。
另一件有帮助的事情是（正如前面的回答中提到的那样）是让开发人员更好地理解所涉及的业务逻辑，以及客户想要什么，并让客户了解开发的特点过程。
于 2014-09-06T14:23:51.473 回答
0
看板和 Scrum 是 Waterfall 最常用的两种替代方案。我试图对不同的SDLC 方法进行很好的概述和比较。
正如 APC 所提到的，瀑布严重依赖于大规模的整体阶段。这是一个巨大的弱点，因为试图从一开始就确定最终产品是徒劳的。
看板有点牛仔，但我发现如果你将它与站立结合起来，它肯定仍然有它的位置。
Scrum 非常适合向团队施加压力并获得门票所有权。我发现大多数地方都在使用这个，但它的缺点是有些人过分地为所有事情开会。Sprint 计划会议、Sprint 启动会议、持续 1 小时、有 20 多人在场的每日站立会议、演示会议，最后是事后分析。
请记住，敏捷只有你做的好，如果你疯狂地参加没有增加价值的无节制会议，你很容易沉沦任何方法论。尽可能保持精简而不混乱。
于 2017-02-13T20:31:48.890 回答
-1
于 2010-05-15T07:11:20.260 回答