- Rich Internet Applications
- Advantages of GWT
- Software Methodologies to Apply
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Software Methodologies to Apply
For classic application development, many well-known methodologies exist, but in the context of modern web development, you should definitely use some techniques.
Classic Development Problems
If you learned to develop systems years ago, you were surely exposed to the Waterfall Model or some other methodologies directly based on it. In this model for the development process, progress is seen as flowing like a waterfall from stage to stage, through well-defined phases (see Figure 1.1) starting with the Analysis of Requirements, following with the Design of the Solution and its Implementation, then to Testing (or Quality Assurance), and finally to Installation and future Maintenance.
)
Figure 1.1 The classic Waterfall Model isn't the best possible for GWT development.
This model is flawed in several ways (and of course, there are some fixes for that) but its main problem is its orientation to highly regimented industries such as Construction, in which late changes can be quite costly to implement, usually requiring tearing down what was done and practically starting anew.
Another point—and an important one—is that you cannot expect users to be fully aware of what they require; it is sometimes said "Users don't know what they want, but they know what they don't want."9 Classical methodologies do not take this into consideration, and might thus incur important costs, because newly discovered or determined requirements can invalidate a previous design.
Finally, it's difficult to predict where difficulties will occur; problems with functionality are usually found "on the go," and if going back to change something to help future development is too costly, you can face a dilemma: Spend money and time revising your design, or keep your substandard design, and spend money and time later trying to make your software do tasks it wasn't well designed to do.
It has been said that the Waterfall Model, and similar ones, are based on the old "Measure Twice, Cut Once" saw, but you cannot actually apply this when you don't actually know what's being measured! (And, furthermore, what happens if requirements change along the way, and by the time you finish with development, the problem has actually changed?) Modern, agile technologies try to take this into account and work in a radically different way, and that's the way you should use with GWT.
Agile Methodologies
Several software development methodologies seek to reduce the time between the requirement analysis phase and the development phase to develop at least parts of the system in shorter times, using possibly an iterative method to advance to the final application. Prototypes are frequently used to bridge the distance between the user and the developer, helping both to understand what's actually required. Instead of attempting to do a whole system at once, development is parceled in smaller subsystems. The user is involved all the time, instead of providing his input (in the form of requirements) only at the beginning and then dealing with the system after its installation.
All these suggestions are currently applied in Agile Software Methodologies (born in 2001) that emphasize collective (i.e., users plus programmers) development of systems, in highly iterative steps, with frequent verification and (if needed) adaptation of the written code.
Agile Methodologies usually break a complex system into several short stages, substituting short, easily measured and controlled iterations, for long-term (and hard to do) planning. Each iteration (usually shorter than a month) involves a mini development cycle that includes all the stages associated with a Waterfall Model but finishes with giving the users a working product with increasing functionality that serves not only as a measure of advance, but also as an aid to determine if changes are needed. The delivered software is used as the main measurement for progress, instead of depending on a Gantt chart or other documents.
GWT is perfectly suited to such methodologies, because it can offer iterative development, rapid prototyping (and here tools such as UiBinder, which we will study, can help quickly develop appropriate interfaces), and automated testing. The latter point is particularly important: Given that development can (and will) go back and forth, and code used in a previous iteration can be modified several times along the complete development process, it's important to check whether old functionality hasn't been lost and whether bugs have been introduced. GWT has tools that provide for both unit testing (at the lowest level) and acceptance testing (at the user level).
Forever Beta?
As a side effect of the iterative development process, it's usually hard to define what constitutes a "version" of the final system. Because practically every iteration produces new functionality, and the final goal isn't as well defined as with classic methodologies (in which the complete roadmap is laid out at the beginning and then preferably left unchanged) with iterative development, you deliver the system in many small steps, rather than in large ones.
In this context, it's not unknown for systems to be considered in "perpetual beta"; beta testing refers to the tests done by actual users with a system that is close to the full product but not necessarily complete. (An extreme case of this is Google's Gmail, which was considered to be at beta level from 2004 to 2009!) With GWT, you can provide functionality increases in short steps, and the web model enables for easy distribution of the updated code.10