SDTimes - June 1, 2007 - Jennifer deJong
Experts offer up advice for making life-cycle management work
Watch out for trouble around handoffs. Apply agile ideas. Run your shop like a business. Don't expect to change everything overnight.
That's a high-level summary of the advice offered by analysts, consultants and tool makers when asked how best to manage large application development efforts, where dozens of team members work across disparate locations.
"Application life-cycle management has never been easy, or automatic," said Upside Research analyst David Kelly. "It takes discipline and effort to put a strong ALM process in place, and the drive toward distributed development simply increases the challenge."
To help development managers achieve that discipline, SD Times asked more than 15 experts to weigh in with best practices for seven stages of the application life cycle: requirements, architecture, code, build, test, deploy and maintain.
Some key themes emerged from their responses. First, while each stage of the life cycle focuses on a single activity, it is critical to define each stage in terms of its relationship to the other stages, the experts said. This idea is fundamental to the definition of ALM itself, said Forrester analyst Carey Schwaber. "ALM is any best practice that connects those stages." The management of the application life cycle is about making sure the stages are in correspondence, she said.
"Don't think of them as separate stages, but focus on the coordination [among them]," added CollabNet CEO Bill Portelli. Each stakeholder is involved in every stage, but the nature of their concerns differs, he said.
ALM is agile
ALM isn't about building software in one long sequential cycle, where one stage is completed before the next begins, the experts said. Ideas from agile programming, such as writing software in short stints, are central to ALM best practices, even for development teams that have not adopted officially agile methods such as Extreme Programming or Scrum.
"The serial way of working has been shown to be ineffective," noted IBM practice leader for agile development Scott Ambler. A better approach is to do a little of each thing every single day: some analysis, some design, some coding, some testing and so forth, he said.
"It's a bunch of short cycles [that keep repeating]," echoed Bruce Eckel, who heads the software development consultancy MindView. Rapid, repeatable stints bring problems to the fore early enough to fix them, he said. "[Otherwise] when a tester finds something fundamentally wrong with the architecture, it's too late to do anything about it," he said.
Stay on top of handoffs
Another idea central to the experts' responses is that the ALM process is most likely to break down around handoffs. Managing those handoffs effectively increases a project's success. Trouble typically emerges when developers turn their code over to QA, or a business analyst bows out of the process once requirements have been defined, said Compuware marketing director Mike Burba. "The analyst should be shepherding those requirements into testing and beyond."
Keeping all players engaged throughout the ALM process is a tall order, often requiring a shift in mindset. The mindset that enterprise development teams need to take on is that of a commercial software company, said Voke analyst Theresa Lanowitz. "They share the same goals: high-quality software, delivered in a predictable, cost-effective way, with good customer service." But the notion of running the software development process like a business is a difficult one for enterprise shops to engage with, she said. So it's not likely to happen in a short period of time. "They say, ‘We are not a software company. We are in financial services, or we are in the business of manufacturing.'"
Finally, several experts cautioned that the ALM process cannot be transformed overnight. "You can't just say, ‘Throw it out, and do it this way.' You have to figure out where the biggest pain point is, and then determine what changes the organization is capable of making," said Eckel.
Here's their advice for each stage of the application life cycle:
Before you begin, ask the key question, said Balazs Fejes, chief technical officer for software development consultancy EPAM Systems: "Is the planned application aligned with the strategy of the business?"
Elicit the right information, said Forrester's Schwaber. "Document it in a format that means the same thing to the business as it does to [the development team]." Don't draft 100-page requirements documents that line-of-business managers can't bring themselves to read, she said. "Express what they care about, and make sure they buy into it." It's essential to be explicit, added Compuware's Burba. "The line-of-business manager is thinking, ‘Of course the IT guy knows [this application relies on] credit card transactions.'" But making that assumption is risky, he said. "In reality there's a disconnect." It is also important to prioritize requirements, emphasizing those that bring the most value to the business, said Telelogic senior director John Carrillo.
Employ skilled personnel to lead the requirements gathering process, said Forrester's Schwaber. That person is essentially a translator, who bridges the gap between business and IT, and knows how to elicit information from both parties, added Compuware's Burba.
Collocate developers with line-of-business users, said Serena Software CEO Jeremy Burton. "Conventional wisdom says developers don't interface well with the business," he said. "But [the collocation approach] can be stimulating, and I have gotten a good reaction from developers."
Use more than one media type to capture requirements, said Schwaber. "Some text, some simulation, some process modeling and storyboarding.
Embrace the idea that it's impossible to know all application requirements up front, said MindView's Eckel. "The notion that we can accurately define all application requirements at the beginning of a project is false," he said, citing a key concept of agile methods.
"Don't write them down too soon," echoed Mary Poppendieck, co-author with Tom Poppendieck of "Implementing Lean Software Development," among other books. At least 30 percent of requirements change during the development process, she said. "If you have to change them, you wrote them down too soon. That is a waste."
Gather input from each stage of the application life cycle. QA professionals should be part of the requirements meeting, said Borland director of product marketing Marc Brown.
Application support people should be closely involved, too, said mValent CEO Swapnil Shah. "You need a clear understanding of underlying infrastructure the application will run on."
Identify security and performance requirements. Line-of-business leaders have expectations around both of these issues, but they aren't likely to speak up about either one until after the fact, when something goes wrong, said Steve Dystra, director of application delivery management for Compuware. Performance requirements are concerned with issues such as maximum response time, he said. Security requirements include validating user input, said SPI Dynamics security evangelist Michael Sutton. "Is the application taking in ZIP codes, and e-mail addresses? If it is, you need to validate that data."
First consider the overall programming model, said Forrester analyst Jeffrey Hammond. "Over time we have seen that change from host-based, to client/server, to the Web application server model, to service-oriented architecture (SOA) and rich Internet applications. Each model has a distinct set of activities around it."
Identify reusable services for SOA, said Interarbor Solutions analyst Dana Gardner. Consider commercial services, such as PayPal, for processing payments in retail Web applications, and assets within the company, such as a data service that offers a common view of the customer, he said. "Reuse has profound implications for saving money and extending the value of the application you are building."
Think about the long-term life of the application, said Borland's Brown. "A top-down dependency model is key." The application shouldn't depend on circular dependencies that can cause future problems.
CodeUse test-driven development techniques, said Schwaber, referring to the agile practice where developers write a test for the code prior to writing the code itself. "It makes builds more efficient, and it makes testing more efficient." And it also helps organizations build good (and complete) test suites as the solution is progressively developed, added Upside's Kelly.
Insist that coders write unit tests, said MindView's Eckel. "Developers should do a little bit of testing before handing over the code," added Schwaber. "Some redundancy makes sense."
Integrate coding with version management, said EPAM's Fejes. "Every time you check something in, spin off a new build."
Move part of your coding effort offshore, said Serena's Burton. Provided you manage source code in a central repository, it makes sense to take advantage of the lower-cost talent that exists overseas, he said. At the same time, move local developers upstream to work more closely with the business side of the house, he said.
Don't let programmers lose site of the big picture, said Eckel. "They tend to fragment off into their projects." Instead, get them to create the bare bones of "Hello World" and seek feedback on what they've written, he said.
Use source code analysis software to find and fix flaws, said Gartner analyst Joseph Feiman. "It is ideal to address application security at every stage of the life cycle." But prior to the coding stage, there are no tools available to do that, he said.
Build regularly throughout the application life cycle, combining components from multiple team members, said Schwaber. Verify that all of the integration points work, she said.
Replace build scripts frequently, said Schwaber. "They get gnarly over time. If our code was as bad as our scripts, we would be ashamed." But scripts are part of the code, she added.
Make sure code passes security tests before it's checked into the build, said SPI Dynamics Sutton.
Import configuration settings from code to QA, said mValent's Shah. As code gets built, developers change configuration settings, such as those for the database and application server. But if the QA environment doesn't reflect those changes, the code won't run, he said. "We need the same level of care around configurations settings as there is around source code management today."
Map requirements to testing, said Compuware's Burba. "Use requirements to create test plans." Make sure that requirements are complete and accurate, he said. "If requirements are wrong, it's impossible to use them to drive testing." It's also important to test every path, he said, referring to the different series of steps that might be involved in placing an order online, for example.
Automate the pipeline from build to test to deploy, said Schwaber. Deploy to production or a test environment, but make sure you are doing it continuously.
Build some sort of packaging and deployment mechanism, even if all the pieces aren't there, said Eckel. "Otherwise it's hard to know if the application will deploy properly."
Put a process in place for incorporating feedback from users, said Sutton. "Software is developed by human beings. There are flaws that we miss."
Propagate changes upstream, said Shah. Changes in infrastructure, such as an upgrade to a new version of Linux, happen all the time in production. Share that information with developers, testers and other team members, so a mismatch won't occur down the road, he said.
Continue to test during the maintenance phase, said EPAM's Fejes. Keep running compatibility tests to make sure the application works with third-party components. "Dependencies are a big thing — especially with open source components."
Cut the cost of maintenance and allocate more money for innovation, said Serena's Burton. "Maintenance is the least sexy of the ALM stages, but IT organizations spend a disproportionate amount of money on it, sometimes as much as 60 to 70 percent of the budget." That's especially true when two companies merge, he said. "They spend huge sums of money taking two e-mail systems and making them one, for example." The more you cut maintenance costs, the more you can spend on developing new applications that further the business strategy, he said.
One way to do that? "Extreme self-service," where business users make feature requests or report defects online, he said. "Enhancement or defect requests take too long. It's critical to minimize the human intervention involved."
For further information, please contact: email@example.com