Lifecycle Management FAQ
Here are some of the most common questions on application lifecycle management, as provided by our authors for this special report.

Posted October 15, 2003

Q. What are some of the advantages of introducing application lifecycle management practices within an organization?

A. One of the immediate advantages is mastery of the software and the applications in the network, better inventories, better knowledge of your target users, and better understanding of what types of products are within your network. One of the main reasons for this is that when organizations start managing the complete application lifecycle, one of the first things they need to do is understand all the products they use in the network. This is often a perfect opportunity to perform a software rationalization review. This allows you to identify duplicate software in the network and reduce the overall application management workload. It's always better to know what you've got out there.

Q. Some people have recommended that we use conflict management within our application lifecycle. If we decide to do so, how can we reduce our conflict management efforts?

A. Conflict management—the review of every component in either applications or software and its validation against all the other components in the network—can make life a lot easier because it guarantees system stability. But generic conflict management can take a lot of time because you have to match each product against all the other products in the network. We reduce conflict management efforts by using role-based system configurations. By designing a role-based configuration, you reduce the number of software products that can coexist on a given system. This means you don't have to manage conflicts between all the products in your network, but rather, only those that will live together on any given system.

Q. What are the factors that would make someone decide to implement application lifecycle management?

A. Several factors can lead to this decision: The most common is a high level of support calls related to the proper operation of software and applications in your network as well as their installations. Another common factor is deployment projects. It is statistically proven that when you structure software products before deploying a new network, you can obtain significant gains in reliability and stability; therefore, many organizations choose to implement application lifecycle management at the early stages of a deployment project. It helps them master the commercial software in their network as well as redesign and redevelop their internal applications to make sure they operate properly on the new operating system. Whatever your reason, you will note the positive benefits of complete application lifecycle management once it is in place.

Q. My users don't know what they want. How can I get them to write requirements?

A. Hopefully they do have some clue about their needs, or else they wouldn't be talking to you at all. You need to work with them—learn their language, understand their jobs a bit—and help them express their needs more clearly. It's a bit like the classic stage technique of method acting—you might have to live the role to portray it correctly. Same for requirements: Put yourself in their shoes and help them express their needs clearly. Make sure they understand what you are saying and get them to sign off.

Q. How can I start building if the requirements keep changing?

A. This is probably the most commonly reported problem with requirements. In many cases, it arises from the requirements not being well-formed in the first place. Helping the users understand the fundamental business needs, and then helping express those in clear, reliable terms will greatly reduce the amount of change requests. You can help users understand what they are asking for with prototypes.

However, requirements change to reflect changing business conditions. Requirements tools can help here, because the best reaction to a change request is a statement of how much the change will cost. A tool will let you rapidly demonstrate the impact of the proposed changes. Many change requests simply vanish when met with a justified statement of cost. Flexible development methods help handle those that don't.

Q. My developers don't have time to read requirements documents.

A. So they have months to make changes instead? Requirements documents don't have to be long and dull, unless you are building battle ships or space probes. A well-written requirements statement should be readily accessible to all its users. Part of this is a clear, functional structure. This can help developers navigate to the parts they need to work on. A tool can help here as well—good filtering and sorting functions will enable the engineering team not just to find the relevant requirements, but to mark them as completed, too.

Q. Our company thinks that Microsoft Word is a requirements tool. Am I a lost cause?

A. Not at all—all the requirements tools feature at least some level of interoperation with Word. Telelogic DOORSrequireIT lets users work directly in Word documents. The others all feature import from Word into structured environments.

Q. What do design techniques such as abstraction, encapsulation, and decomposition really buy you?

A. The truth is that we could probably design and build a software application that will satisfy today's requirements (a static system) without exploiting sound design principles. In reality, requirements for software systems evolve over time, and this evolution requires a software system that is adaptable. Sound design techniques enable the flexibility to accommodate the future.

Q. What is the best way to learn software design patterns?

A. If a software designer thoroughly understands and consistently practices the fundamentals (abstraction, encapsulation, minimal dependencies, and so on), design patterns will come naturally. This means that, using the fundamentals, you will probably be surprised to find that your designs employ patterns even though you might not have studied them. Learning by studying patterns and then retrofitting a design to use specific patterns is not the right approach. For concrete examples of patterns that evolve from sound design principles, see "The Philosophy of Interface Driven Design" (Java Pro, 2003).