Keeping users fully in the loop can cut IT costs while boosting software quality.
Yahoo's Flickr unit reported recently that the latest update to the photo-sharing Web site went live just before 5 p.m one evening with nine changes made by three of its developers. The "deployment" was the 36th new release in a week where 627 changes were made by 21 developers. Such constant tweaking?called a "perpetual beta" in the Web 2.0 world?is common for companies that build applications for a consumer market that's always in flux.Quick, incremental updates, along with heavy user involvement, are key characteristics of an emerging software development paradigm championed by a new generation of Web 2.0 start-ups.
The new process, which some champions call "application development 2.0," contrasts markedly with the traditional corporate waterfall process (see box for details) that separates projects into several distinct phases, ranging from requirements to maintenance. Nonetheless, application development 2.0 can bring significant benefits to corporate IT shops if managers and developers are willing to change.
"Sometimes enterprise organisations tend to look at these Web 2.0-focused places and say they are not very disciplined," said Jeffrey Hammond, an analyst at Forrester Research. "That is not the case. They have built discipline into the process that allows them to be very reactive?a [good] lesson for IT organisations.
Based on interviews with analysts and executives of Web 2.0 firms, we compiled a list of five ways that corporate IT managers can benefit from using Web 2.0 development processes. Here they are:
1. Break the barrier between developers and end users, and involve users in quality assurance processes.
Applications are inherently built better when developers are not insulated from the people who use their applications. Direct user complaints or compliments are far better motivators for developers than viewing PowerPoint slides with bar charts representing user desires in a meeting room.
William Gribbons, director of the graduate program in human factors at Bentley College
"Companies often think their [internal] applications are different because they're used by employees [who] are compensated for the pain and suffering they are enduring," he said. That pain and suffering, however, can boost training costs and employee turnover and cut productivity?all a hit to the corporate bottom line.
Corporate development teams should focus on close interaction with internal users to gather requirements, and to create a controlled, systematic way to observe users interacting with prototypes, Gribbons suggested.
2. Keep it simple
While many consumer-focused Web 2.0 applications may seem simple, that simplicity is usually the result of hard work by developers working hand in hand with users.
Developers have begun to understand that it's better to build a very simple service and then add application programming interfaces to provide complex services.
Features can actually be obstacles. The more powerful an application is, the more specialised it is, and thus with increased power, its intended audience shrinks.
Many times, traditional enterprise IT shops will identify a need and develop multiple ways of meeting it when the user would be happy with one. But without constant interaction with users, developers often are unaware of the yearning for simple user interfaces.
3. Stick to the script
Web 2.0 companies are partial to dynamic scripting languages like Ruby, Python, Perl and PHP, finding them better choices for their projects than Sun Microsystems?s Java or Microsoft?s .Net.
Forrester's Hammond
4. Release early and often
Update sites often, usually several times a day. The constant interaction with users provides developers with almost immediate notification of bugs. In addition, many Web 2.0 companies run so-called shadow versions of their sites, which help determine how users respond to specific feature updates. A report compiled by the shadow site could show, for example, how often users log off the site or whether the amount of financial information uploaded by users has dropped.
5. Let the users, not the developers, determine new features
Top Internet companies such as Amazon and Google release new features to small subsets of users and then compare their feedback to control groups. The companies say the method provides much better validation for new features and products than customer surveys or even discussions between users and product managers.
While most large companies are unlikely to flock quickly to the Web 2.0 development techniques?and some applications would not be a good fit for this methodology, observers acknowledged?some are starting to realise the merits of these new processes.
In the survey of developers taking part in a recent TopCoder on-line coding competition, an overwhelmingly majority (70%) of the respondents said that traditional corporate development teams could benefit from Web 2.0 techniques, specifically the incremental feature releases, quick user feedback loops and quality assurance programs that include users.
What's more, 57% of the respondents said that problem-solving and analytical skills will be key requirements for next generation developers, while 18% cited the need to work with on-line communities. Meanwhile, 24% said that code generation is the key long-range development skill.
The corporate use of application development 2.0 techniques?especially the focus on the user?could be critical to reducing the number of IT development projects that are scrapped before completion.More about the Waterfall model
Once upon a time, software development consisted of a programmer writing code to solve a problem or automate a procedure. Nowadays, systems are so big and complex that teams of architects, analysts, programmers, testers and users must work together to create the millions of lines of custom-written code that drive our enterprises. To manage this, a number of system development life cycle (SDLC) models have been created: waterfall, fountain, spiral, build and fix, rapid prototyping, incremental, and synchronise and stabilise.
The oldest of these, and the best known, is the waterfall: a sequence of stages in which the output of each stage becomes the input for the next. These stages can be characterised and divided up in different ways, including the following:
Project planning, feasibility study: Establishes a high-level view of the intended project and determines its goals.
Systems analysis, requirements definition: Refines project goals into defined functions and operation of the intended application. Analyses end-user information needs.
Systems design: Describes desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudocode and other documentation.
Implementation: The real code is written here.
Integration and testing: Brings all the pieces together into a special testing environment, then checks for errors, bugs and interoperability.
Acceptance, installation, deployment: The final stage of initial development, where the software is put into production and runs actual business.
Maintenance: What happens during the rest of the software's life: changes, correction, additions, moves to a different computing platform and more. This, the least glamorous and perhaps most important step of all, goes on seemingly forever.
But it doesn't work!
The waterfall model is well understood, but it's not as useful as it once was. In a 1991 Information Center Quarterly article, Larry Runge says that SDLC "works very well when we are automating the activities of clerks and accountants. It doesn't work nearly as well, if at all, when building systems for knowledge workers -- people at help desks, experts trying to solve problems, or executives trying to lead their company into the Fortune 100."
Another problem is that the waterfall model assumes that the only role for users is in specifying requirements, and that all requirements can be specified in advance. Unfortunately, requirements grow and change throughout the process and beyond, calling for considerable feedback and iterative consultation. Thus many other SDLC models have been developed.
The fountain model recognises that although some activities can't start before others -- such as you need a design before you can start coding -- there's a considerable overlap of activities throughout the development cycle.
The spiral model emphasises the need to go back and reiterate earlier stages a number of times as the project progresses. It's actually a series of short waterfall cycles, each producing an early prototype representing a part of the entire project. This approach helps demonstrate a proof of concept early in the cycle, and it more accurately reflects the disorderly, even chaotic evolution of technology.
0 komentar:
Post a Comment