email article printer friendly more resources

Adopt Integrated Development
You might be focused on code today, but get ready for the coming shift to application lifecycle. The tools are already evolving and will affect your job.
by Thomas Murphy

Enterprise Application Lifecycle Management 2003

Modern methods of software development often get more lip service than actual use. What actually happens typically resembles the Psych 101 "telephone" game. The professor puts everyone in a circle, whispers a message in one student's ear, and then the students pass the information around the circle. The last person relays the message back to the professor, and it always morphs. "For breakfast I want bacon and eggs" could come back as "Four dresses worn by contessas."

Similarly, business users express their requirements to business analysts, who turn them into documents and tables, which architects analyze to produce models and yet more documents. Developers then interpret these documents to produce software, which eventually passes on to testing, then operations. Finally the users receive the application and often say either, "This isn't what we asked for" or "Our requirements changed."

The Software Engineering Institute's Capability Maturity Model (CMM) level 2 offers a process designed to provide repeatability and improvement (see Table 1). However, a majority of enterprises are struggling in their efforts to achieve CMM level 2 or any other form of consistency and customer satisfaction. They rarely collect requirements in a standard fashion or follow a consistent project management process.

Development methodologies evolve constantly as IT seeks solutions that enable consistency along with quality and productivity. But often developers react against process and change. They see "development" as synonymous with "writing code," and anything else—such as CMM or other processes—simply adds a roadblock to writing the code that really solves the problem. Moreover, even when development teams try to advance, they find that tools are generally stuck back in the waterfall era (see Figure 1).

The traditional waterfall process compartmentalizes design, coding, testing, and deployment. Each step occurs in sequence, isolated from the rest, with little iteration, and with the teams responsible for each step similarly isolated. However, even if your company's IT operation is still standing under the waterfall, you can prepare yourself for change by examining the drivers for software lifecycle management, the elements of the software lifecycle, and how tools are evolving finally to integrate the lifecycle process.

Thinking about process often starts with the argument over whether software development is an art or a science. Science or engineering advocates liken software development to any other engineering discipline: Specifications are created and software is built to implement the design. Artists focus on the creation itself and treat software more like a living entity. This argument raises the issue of what level of software quality you can reasonably expect (see the sidebar, "Tackle Team Objections to Quality").