Positioning
Introduction"Positioning" may seem to imply that activities in this stage of Comsys-TIM provide little or no immediate benefit. In fact, benefits accrued through the use of Positioning tools and techniques facilitate maintenance productivity improvement, system failure rate reduction, personnel reallocation and the realization of a wide range of short-term priorities. Positioning improves the quality of existing systems without impacting functions or the basic architecture upon which they were built. This includes language change/upgrade, code stabilization, data definition standardization and remodularization. Based on specific needs, source code to source code improvement tasks can stabilize existing systems. Resulting code is easier to understand and maintain. Positioning also provides a baseline from which to extract data and functional content in support of replacement efforts.
Objectives and BenefitsThe Positioning stage supports a variety of tactical needs while concurrently moving systems and organizations towards more strategic goals. Specific objectives and benefits include:
Positioning -- Task SummaryPositioning tasks are summarized below.
While Positioning tasks vary, most include detailed source code analysis, code adjustments, execution of one or more tools, quality reviews and result validation. Positioning estimating guidelines may be found in the Interim Support Planning and Strategic Redevelopment Planning tasks under the Inventory/Analysis stage. System setup and validation are also included as Positioning tasks because they are required to support other Positioning tasks. Quality review procedures are embedded in the Validation task.
Application StagingEach Positioning task requires that multiple copies of a system be established at the onset of the task. This "staging" approach is key to Positioning success. Managing a "window" of time out of production where all code changes must be frozen is critical in highly volatile applications. Application staging facilitates this time management challenge. Because system staging is applied universally to all Positioning tasks, it has been established as a task in and of itself. A given scenario that uses multiple Positioning tasks/steps during the life of a project may invoke the application staging task several times to manage this transition. Different Positioning tasks may have different staging requirements. If a given task requires a variation on the standard application staging approach, it is indicated within the body of that task. Ignoring staging requirements will result in a loss of control of a given Positioning task. One additional benefit of staging applications through various Positioning tasks is that of integrating system improvement efforts with functional upgrades. An interim plan intersperses ongoing maintenance and major enhancement tasks with various Positioning tasks. Staging isolates redevelopment tasks into work units that facilitate maintenance and enhancement upgrades. Finally, most scenario work breakdown structures repeat Application Staging several times based on the number of unique Positioning tasks applied with that scenario. Each of these staging efforts require unique application based on the Positioning task it supports.
Application ValidationPositioning tasks are unique because improvements applied to existing source code have a common goal of changing system or program form, but not function. Functional enhancements can and should be applied between tasks under comprehensive improvement scenarios. But validation must be performed to ensure that a Positioning task did not introduce a functional anomaly. Validation involves running data through a system in the state that it was in prior to the task, and again after completing the task. Results, with possible date or time stamp exceptions, should be identical. Validation can be more complicated with certain tasks, such as field and record size expansion or source code re-aggregation. In these cases, special instructions are included in the Positioning task itself. Finally, most scenario work breakdown structures repeat Validation several times based on the number of unique Positioning tasks applied with that scenario. Each of these validation efforts require unique application based on the Positioning task it supports.
Practical Suggestions and GuidelinesPositioning has historically been undertaken with little front-end analysis and a heavy emphasis on tools. The Comsys-TIM Positioning stage is the first attempt at capturing established techniques and building them into a comprehensive code improvement approach. Even with these improvements, care must be taken in deploying positioned code to application teams. The IS Infrastructure Assessment analyzes issues that can aid in roll out. This includes training in structured coding techniques and languages, introduction of data naming standards and the use of dictionaries or repositories in managing legacy environments. A second point deals with project planning. Delays between assessment completion and Positioning startup may require changes in initial estimates. A broad-based, multi-phased plan to convert, structure, rationalize, upgrade and/or transform a system may lose accuracy as a project progresses to later tasks. Conversions may, for example, result in code that is more difficult to structure than first planned. Another point is that Positioning tasks are meant to be self-contained. Mixing functional changes into a task destroys the audit trail and introduces potential errors that are impossible to trace during validation. Finally, organizations should not underestimate formalization of Positioning efforts. Positioning tasks utilize the results of successful past projects as the model for effective management of source code improvement. |