Software User Assistance Project Management

This article takes a look at a methodology for developing and managing a Software User Assistance (UA) System, a way of doing things in a structured manner. It provides a complete walkthrough for managers responsible for designing, developing, and managing a software product’s user assistance system. The software’s UA system could comprise of both paper-based user manuals and online help systems. A software UA system’s lifecycle is closely aligned to that of the software for which it is being developed. Therefore, it is imperative that its development closely models the software’s developmental phases.

Mapping the Software Development Life Cycle (SDLC) to the Software User Assistance Development Life Cycle

Phase 1: Capture Software UA Requirements

Capture your customer requirements in a UA Requirements Specification document.

Identify Your Customer

Know what your customer wants today as well as tomorrow. Knowing your customer’s future requirements ensures less rework on your design. Use communication to your advantage.

Communication

• - Ask questions, more questions, and even more questions.
• - Use diagrams
• - Receive constant feedback

Phase 2: Analyze UA Requirements

Analyze the requirements to gain a deeper, more technical understanding of them. Understand where and how your UA system will be used. Will it be used in hospital laboratories or IT departments? What is the data retrieval time for your UA system? Record this information for your UA design. Hospital laboratories could have dim lighting and the data retrieval time from your UA system could be less than 3 seconds!

Phase 3: Design a UA Solution

Design your UA system based on modular components. Modular UA systems can be plugged and unplugged as required. They also ensure easier maintenance, tighter security, enabling access rights, and easier licensing. Paper-based UA systems carry a chapter related numbering. This makes printing and binding cost effective.

Design Considerations

Consider the following parameters when designing your UA system.

• Choosing the Platform – Platform-independent or platform-specific.
• Choosing the Familiar – There always is a strong temptation to choose what you are familiar with. Although it is difficult to be objective, it is always to ask other people for opinions, especially individuals who do not have exactly the same preferences as you do.
• Future Proofing – All the same, for a long-term software application, your design for its UA system must be based on future considerations. Study the UA system’s survival capacity. Use new innovations that are likely to stabilize in the future. For example, if you choose an authoring tool provided by a single supplier, what is the likelihood of that supplier being around in the next five to ten years?
• Changing Technologies – Is the technology used for your UA system likely to change?
• Including Modularity – Keeping pace with changing technologies lies in an accurate analysis of your UA system’s functional requirements. Therefore, design with a high degree of modularity and try to encapsulate each module so that it presents a well-defined user interface. Everything else must be hidden. This approach enables you to adapt to changing technologies by simply unplugging one module and replacing it with another that makes use of the new technology.
• Using a Simple Model – Above all, create a simple design for your UA system. Always include the software application’s Domain Business Logic into your design. The business logic will be required later for access restrictions through licensing of certain modules of the software application, thereby impacting the UA system’s modules. At times, your UA system might need to have an Input User Query module, an Output Result module (handling the user interface, and a Database Access module (containing the data-processing module with the business logic). Your UA system might end up having a Client-Server design that could be a Single-Tier or a Three-Tier model!