Not Signed-In
Which clippings match 'Waterfall Model' keyword pg.1 of 1
19 SEPTEMBER 2014

Agile Software Development: what we've learned at Forty

"The general idea behind Agile is that instead of arguing about the wording of a requirements document written three months earlier with little perspective into the current situation, it's often healthier to acknowledge that the project is going to be flexible and evolving, and put processes in place that allow it to be that way.

Barely over 200 words, that manifesto become the foundation for a movement that has changed the world of software development forever. Endless writing and speaking has explored the various ways the manifesto could be interpreted, and many specific frameworks and methodologies (such as Extreme Programming, Kanban, Lean, and Scrum) have been developed to formalize its principles. A whole 'Agile industry' has emerged, with successful companies offering tools, training, consulting, certification, and other products and services. The economic engine behind the Agile movement as a whole is massive. ...

On the surface, it seems like design and Agile should magically work together, but there are some underlying philosophical issues you have to wrestle with before figuring it out. Design is all about big–picture thinking: planning, strategy, working out all the details, thinking everything through, making it perfect, etc. (Eric Karjaluoto called it the 'masterpiece mentality.') Agile, on the other hand, is more often about doing the basics and saving details for later: iteration, minimum viable products, 'perfect is the enemy of done,' etc. Those two worlds don't blend smoothly together, at least at first. Agile developers can get frustrated with designers for over–thinking things ('Why can't they just let it go? We can get to that later.'), while the designers get discouraged by the perceived low standards of Agile developers ('Don't you want it to be good? Don't you want the user to be happy?').

In both cases, though, the problem comes from a misunderstanding of each other's perspectives (as problems often do). The designer isn't being obsessive, they're just trying to do right by the user. And the developer isn't being lazy, they're just following a process that actually gets things done with minimal navel–gazing. Both sides could learn some important lessons from each other."

(James Archer, Forty)

1

TAGS

agile development • agile model • agile modelling • agile software development • current situationdesign processdevelopment life cycle • development methodology • Eric Karjaluoto • evolving needseXtreme Programmingfacing unpredicted challengesflexible management methodology • flexible process • formalised principlesiterative approachiterative design processiterative developmentiterative processjust-in-time (JIT)Kanban • Lean (methodology) • management methodology • over-thinking • perfect is the enemy of done • requirements documents • saving details for later • scrum software development processsoftware developmentsoftware development methoduser experience designUX designwaterfall modelwhirlpool model

CONTRIBUTOR

Simon Perkins
28 MARCH 2011

The top 10 major benefits of high-fidelity prototyping

"1) First and foremost, a high–fidelity prototype gives you something realistic enough to try out your ideas with target users and customers before making a significant investment. This lets you discover which ideas are good and which are not, and if the product has real value, and also discover if users can figure out how to use the product.

2) Doing a high–fidelity prototype helps you – even forces you – to think through your product to a much greater degree than paper specs.

3) A high–fidelity prototype enables and encourages the type of collaboration between product manager, interaction designer, and architect/engineer that is necessary to discover a valuable, useful and feasible product.

4) A high–fidelity prototype provides the level of information necessary for accurate engineering cost estimates, early in the process when these estimates are most useful.

5) A high–fidelity prototype provides the engineers and QA organization with a rich, interactive description of the product's intended functionality and design to be used as a reference basis for implementation and test.

6) A high–fidelity prototype provides the rest of the organization – marketing, sales, customer service, business development, company execs – with a useful understanding of the product to come early enough in the process that they have time to do their jobs properly.

7) A high–fidelity prototype prevents the classic waterfall problem of doing design after the requirements, rather than realizing that functionality and user experience are inherently intertwined.

8) If you do a high–fidelity prototype and you test your ideas with users and you find significant problems, you will have saved your company the cost in terms of time and money of building something that would have failed. Not to mention the opportunity cost of what the team could have been building.

9) If you do a high–fidelity prototype and validate this with target users, you will significantly reduce the time it takes for your developers to build the product both because the product is better defined, and also because you will have been forced to resolve many of the questions early that otherwise throw a wrench into development.

10) A high–fidelity prototype helps keep the focus of the team on the user experience."

(Marty Cagan, 29 April 2008)

1

CONTRIBUTOR

Simon Perkins
19 JANUARY 2011

Single-pass sequential 'waterfall' approach to software development

"I am going to describe my personal views about managing large software developments. I have had various assignments during the past nine years, mostly concerned with the development of software packages for spacecraft mission planning, commanding and post–flight analysis. In these assignments I have experienced different degrees of success with respect to arriving at an operational state, on–time, and within costs. I have become prejudiced by my experiences and I am going to relate some of these prejudices in this presentation. ...

A more grandiose approach to software development is illustrated in Figure 2. The analysis and coding steps are still in the picture, but they are preceded by two levels of requirements analysis, are separated by a program design step, and followed by a testing step. These additions are treated separately from analysis and coding because they are distinctly different in the way they are executed. They must be planned and staffed differently for best utilization of program resources."

(Winston Royce, 1970)

Figure 2 The "waterfall method" (one of numerous development models discussed by Royce in his seminal paper).

Winston Royce (1970). "Managing the Development of Large Software Systems", Proceedings of IEEE WESCON 26 (August): 1–9.

1

CONTRIBUTOR

Simon Perkins
06 NOVEMBER 2008

The Waterfall Versus Whirlpool Project Management Methods

"'Whirlpool' projects embrace the fact that requirements are volatile. Instead of trying to deliver a system that satisfies 100% of the requirements in one go, the focus is on delivering an agreed subset of the requirements at intervals. Use cases are the building blocks of requirements and provide a convenient basis for risk assessment and prioritising. The riskiest and most significant use cases are tackled first, within the context of a clearly understood architectural vision. Tackling risk early identifies problems before they become too expensive or threatening, and helps lead to more stable architectures. The system evolves as a sequence of increments, each one an enhancement to the already–delivered functionality.

The development process for each increment is founded on the idea of a workflow, consisting of activities. For example. instead of having an analysis stage followed by a design stage, a worker might be engaged in analysis activities and design activities, depending on the job in hand. It is important to recognise that analysis activities focus on the problem space, while design activities focus on the solution space. A good understanding of one part of the problem may well lead to faster progress to design in that area. It is also possible that design activities highlight shortcoming in the analysis or even the requirements, in which case these are amended to reflect the newer (and hopefully better) understanding.

Successive iterations converge on a more complete, correct and consistent model, leading ultimately to implementation and delivery."
(Tecademy)

1

CONTRIBUTOR

Simon Perkins
Sign-In

Sign-In to Folksonomy

Can't access your account?

New to Folksonomy?

Sign-Up or learn more.