The problem with applying this model to Software Engineering is that software developers are creative people trained in many of the same disciplines as the software architects; in fact, in most cases only experience distinguishes a software developer from a software architect. When presented with a problem, each software developer will have a unique way to approach it, and is very capable of managing the details of how to implement that approach. To ignore this fact and to have an individual build software designs down to the last detail comes at the expense of allowing a team of highly intelligent, creative problem-solvers to contribute to and improve the design. And, when there are competing, workable solutions to the same problem, and developers are given the freedom to decide which is best, the integrity of each piece will improve, and thus the integrity and reliability of the application on a macro level continues to improve.

See Also: Web 2.0 Best Practices

Overview

In the internet era, in which users think in terms of services rather than packaged software, services are expected to be available on-demand and improve over time. Web-based services typically have no versions, no installations, and no upgrades that the user interacts with. The traditional software development lifecycle of design-develop-test-ship-install is becoming less common as software has increasingly become a service which is always on, always improving.

For development of these services, this shift impacts the entire software development model and delivery process. Success now relies on the adoption of an iterative development model in which software is continuously improved and the users become key contributors to the development process and ongoing support of the online service becomes a core competency

This greatly improves the time to market of an application, reduces the risk of all parties involved, builds a closer relationship between the users and developers and ultimately produces a product that is not only more stable but more closely matches what the users require from the service.

Best Practices

Release Early, Release Often. A critical success factor for web-based services development is the Release Early, Release Often edict developed by the open-source software development community. Using an iterative software development model such as Agile or RUP allows for effective packaging of bug fixes and enhancements into incremental releases that respond to user feedback. Another key element is to use automated testing to perform regression tests on each release, continually building to the test repository to test all existing features as well as past bugs and issues.

Engage Users as Co-Developers and Testers. Real-world user behavior provides much more accurate assessment of new product features than relying solely on requirements specifications, prototypes, or other artifacts that have not been collaboratively developed with the end users. Through effective use of developer-user collaboration, developers are able to accurately monitor how the software will be used in production, allowing the use of statistics and experimentation to make informed product feature decisions.

Capture User Data that Measures the Product’s Objective. In the development process, it is possible to implement not only the customer-facing web-based service but also a framework for capturing how customers are using the product. More can be learned from what users do than from what users say. Capturing user activity data must be planned as carefully as the planning of the web-based services themselves; data captured must answer specific questions in order to accurately measure how well business objectives are being met.

Incrementally Add Features. New and existing features should evolve through rapid releases, user collaboration, and instrumentation. Experiment with new features through planned but incremental processes.

Requirements Management. With the shortened release cycle, continuous change of requirements and features requires a robust requirements management process. In order to effectively manage requirements, there must be in place a documentation model capable of tracking and documenting tradeoffs and decisions as well as easily capturing and communicating business requirements. Typically, the use of Use Case and User Scenarios have proven to be an excellent way to capture functional requirements and to ensure that these drive the design, implementation and testing of software. These documents also provide traceable threads through both the development process and the delivered system.

Change Control. The ability to make certain that each change is acceptable and being able to track changes is essential in an environment in which change is inevitable is essential. The disciplined adherence to a process that describes how to control, track and monitor changes throughout each iteration is critical to enable successful iterative development.

Agile Requirements

Agile development is not for every project or for every development team. Due to the collaborative nature between the developers and the business users, the ability of the teams to work well within themselves as well as with each other is essential. Agile development requires excellent team collaboration and leadership; it requires motivated members across all groups; slackers in the development or business teams can upset the momentum and productivity of the team. Further, developers need to be adept at gathering requirements from the users in addition to being able to intuitively build well designed systems – simplicity is key. Constantly changing requirements and system code exposes an application’s architectural and design weaknesses and flaws. Finally, due the short release cycle, agile development works best in distributed environments such as with Web Services and Web Applications; frequent releases work better when the client doesn’t doesn’t need to be involved in deploying releases.

Pitfalls

User Testing Can Never Replace Quality Assurance. A common pitfall of adopting an iterative development process is the notion that the short release cycling which includes both features and bug fixes is an excuse for poor quality or a lack of accountability. Engaging users as real-time testers is about validating and refining functionality, not quality.

Versions No Longer Exist. Although users no longer interact directly in the release cycle as they did in the traditional design-develop-test-ship-install model, versions are as vital as ever. More frequent release cycles require disciplined design, build, test, deploy, and support processes.