This White Paper discusses the need at the IT department at a large Federal Government Agency for a Software Life Cycle (SDLC) tool, referred to in this document as an Application Lifecycle Management (ALM) tool. Such a tool is required to replace stove-piping technologies currently in use and to integrate and/or replace the organization’s existing processes and procedures, which are outdated. Currently, numerous Government-off-the-Shelf (GOTS) and Commercial-off-the-Shelf (COTS) products address many facets of the Software Lifecycle Development methodology. None of these tools, however, addresses the entire process successfully and provide ease of use, actionable output, traceability, synchronization and cost effectiveness for the IT department. After describing the existing sub-optimal environment, the remainder of this document will define requirements for tools that meet the organizational objectives, as well as discuss particular tools that meet these requirements.
A critical mission of the IT department at our customer is to provide an infrastructure as well as services supporting Information Technology (IT) development and maintenance throughout the larger organization. Currently, the IT department does offer such support, but in a fragmented manner. The IT department lacks an automated tool that integrates IT support across the entire SDLC. What is more, at the present time, responsibility for IT services is split among three divisions: engineering, support, and delivery. Each of these divisions has its own processes, structure, methodologies, and tools. Adding further complication, business solutions and applications are developed and maintained by contractor firms in their own development environments, using tools of their own choosing that support the various phases of the development lifecycle. Our customer currently specifies no standard tool set for the engineering/development process.
When the solution is developed and ready for independent testing, the code is transported, stored, controlled, and tested in another environment, most often with a different set of tools. After migration to the production environment, problem and incident reporting and tracking occurs at a different organization using yet another set of tools. . When information is captured in a given tool, each of the various tools becomes its own silo which reinforces the tendency of maintaining silos across the IT department. The disparate tools are not smoothly connected with each other and the information flow among them is mostly manual, lacking coordination and synchronization. The IT department found it difficult to share information between different lifecycle solutions, trace items through phases, propagate changes through phases, establish end-to-end automated lifecycle processes, enforce consistent project management controls across phases and gain total visibility into the status and progress of development and IT projects.
More specifically, the IT department has the following problems regarding coordinating and synchronizing life cycle management tools: Lack of Process across the Tools: The IT department has numerous processes that support IT services. The processes are not standardized and cross-organizational consumption of data is cumbersome. Each tool supports its own process. The process steps are typically manual, and data generated in one organization does not easily cross over to the processes in other organizations. The control of tools tends to obscure the control of processes. Traceability between Engineering Artifacts is difficult, and error prone: All relationships among engineering artifacts are created and maintained manually. Requirements are copied from Word or Excel files and pasted into Hewlett Packard Quality Center (HPQC) to express relationships among requirements and test cases, for instance. Likewise, test failures are entered as Test Problem Reports into an internal tool called Tracker, and traceability between a given Test Problem Report, test case, and requirement are maintained manually. Interoperability between any of the IT department tools and data does not exist. Test Analysis Reports are written in Word; data from HPQC is manually retrieved and copied into Word. Defects are manually recorded and stored in Tracker, and also copied into the Test Analysis Report.
- Lack of Process across the Tools
- Traceability between Engineering Artifacts is difficult and error prone
- Manual Consolidated Reporting
- Lack of Visibility
The Kovair Software Life Cycle Development tool suite offers a uniform procedure, common interface, and automated tools with several adaptors designed for scalability and availability to the current software library. The suite supports code storage, traceability metrics, reporting, development, testing, integration, production, and trouble-shooting until final decommissioning of the software package.
The suite fits into the ITIL v3 framework (Service Operation) on the grounds that it:
- Was found to be superior to other tools for Requirements Management.
- Uses current SDLC/ALM best practices for software development and maintenance.
- Provides clear guidance with its process methodology.
- Provides direction for policies and procedures used by engineering review boards and other integrators that will support the organization.
- Makes available adaptors that allow it to exchange information with other tools already being used in the IT environment and enhances their ROI.
- Has Omnibus Integration Bus technology that allows multi-tool integration in bus architecture.