Enabling Collaborative Development
Creating a truly collaborative development environment will increase productivity and improve the quality of your company's applications.
by Thomas Murphy
November 2002 Issue
Traditional software development methods tend to match
phases in a project with specialist teams. Business analysts work with end users to gather requirements, which they then pass to architects who generate data and object models and deliver the results to developers for implementation. After the developers create code, it's passed over to testing and operations. This division of labor is based on common manufacturing principles and traditional engineering rigor. Unfortunately, it also opens the door for communication gaps (see Figure 1).
In recent years, development teams have seen project timelines shorten and requirements change constantly. In the face of these pressures, top-down engineering practices fall short. Iterative development processes deliver increased productivity and improved quality by driving higher collaboration between the groups involved in producing applications (see Figure 2). Much of this collaboration currently happens outside of the tool environmentit takes place on whiteboards, in war rooms, and during hallway conversations. This leaves a lot of space for miscommunication and can make it difficult to track a project's status. However, development tools are evolving to support a more collaborative approach to application development. In this article, I'll discuss the three areas in which this evolution is occurring: Integrated Development Environments (IDEs), life-cycle tools, and collaborative environments. I'll also explain how your organization can take advantage of this evolution to improve your application's quality and your team's productivity during development.
Traditionally, IDEs have consisted of the simple set of tools (such as compilers, debuggers, code editors, and screen painters) needed to create and deploy applications. As application models have become more complex, it requires a greater number of tools to deliver reliable solutions, including tools for version control, modeling, and profiling. Generally these tools exist separate from the development environment, which reduces their value and complicates collaboration.
The traditional separation of modeling and coding environments offers a good illustration of the break between life-cycle phases. Architects create Unified Modeling Language (UML) models, then toss them over the wall to the developers for implementation. At the end of the development process, "modern" tools allow reverse engineering to find out what the developers really built. This is fundamentally a broken process because there's no way to enforce design decisions made by the architect and it's too hard to iterate through the design, build, and test cycle. This is why less than 10 percent of a development teams use UML, and that percentage uses only a small subset of the available models.
Back to top
|