Problem Statement
It has been noted that shortcomings in the Veteran Health Administration (VHA) system that systematic issues affecting the Return on Investment (ROI) may be due to improper adherence to the steps in the Software Development Life Cycle (SDLC). This document presents key areas of the SDLC that may be behind the shortcomings and recommends a root cause analysis study.
Context
The Software Development Life Cycle (SDLC) is series of steps that play an integral role in the production of software. The cycle includes system engineering, software requirements analysis, systems analysis and design, generation of code, testing and maintenance (Lewis 26).
Based on reports from the PE Lessons Learned team, it has been reported that during development of the VHA system systematic issues suggest poor adherence to the SDLC. In turn this may be responsible for poor Return on Investment (ROI) for the project. Because of this several areas have been identified that could be the reason behind the poor performance of the project.
Concept Initiation
Issues attributed to poor adherence to the SDLC of the VHA system can be traced to concept initiation. Evidence in support of this is identified in the GAO report which highlights the fact that despite spending large sums on money and time on the VA project implementation is yet to be done on many of the projects.
It has been observed that an estimated $127 million has been spent on this project over a period of nine years. It should be noted that of this amount $62 million of the amount was to be spent on planning, management support development equipment and environment.
It has also been noted that the department also paid a further $65 million to the contractor to develop the replacement scheduling system. It should be noted that prior to initiation of the project the VA system relied on an outpatient scheduling system that was over 25 years old. Given that in 2009, VA terminated the contract supporting the development of a suitable scheduling project one can understand why so many defects still exist in the system.
His is because if the scheduling system is so significant, the VA should have first developed this system before undertaking other systems. As a result of this poor planning it was noted that the project was still plagued by a number of defects that VA and the contractor were unable to resolve.
It has therefore been concluded that it is likely that VA did not adequately plan its acquisition of the scheduling application. This can be traced to the fact that one of the best practices in development of software is to closely align software projects with business or organizational goals (ISACA 116).
Concept Definition
Another shortcoming that is attributable to lack of adherence to the SDLC is observed when considering concept definition. This is because an SDLC can be broken into three main stages namely, definition, construction and the implementation phases (Tan and Sheps 296).
In the definition phase, the project team attempts to provide a detailed explanation of what the system is expected to accomplish. It is based on these requirements that the software engineering specialists develop the proposed solution (Tan and Sheps 296). It is therefore clear that an incomplete or unsuitable concept definition will most likely result in a system with degraded performance.
At this point it is also important to mention that definition also involves feasibility study which is essential to the proposed system. The objective of the feasibility study is to point out if the project is absolutely necessary and if the organization is able to complete the software project envisioned (Tan and Sheps 296).
Based on the VHA case it appears evident that a complete feasibility study was not undertaken and as a result a poor system was developed. In addition to that another important question that can be traced to the feasibility study is related to the Enterprise Architecture (EA).
Based on the feasibility study it should have been noted that the Enterprise Architecture to support such a system was absent. This in turn would have suggested the need to develop suitable architecture. The feasibility study should have identified the lack of the required architecture to manage the project. In this case the development of the suitable architecture should have arisen and been addressed accordingly.
Concept Planning
It has already been established that during the development of a software project the project team goes through a series of steps to ensure success of the product.
In a good software project the development team will allow the organization to review progress periodically. It is believed that these reviews play a crucial role in the development process. This is because reviews present opportunities to identify errors and inconsistency (Tan 201). Such reviews provide developers with an opportunity to plan, correct and re-plan the project as it progresses.
In the development of the VHA System it is possible for one to assume that such planning in relation to the concept was not done. For this reason it is evident that due to poor acquisition strategies led to solutions that do not satisfy the stakeholder needs. In addition to that it is noted that due to poor planning there were numerous delays in the project schedule.
Also evident in the project is the lack of communication and absence of meetings between the participants. This appears to be a reason behind the delays in completion. It has been suggested that in similar projects the participation by both the users and the project team helps to keep the project on track (Tan 201). Based on this reason, the numerous delays suggest that there was poor execution of the planning stage.
Development
In the production of software solutions the development stage normally involves the translation of user requirements to code (Langer 221). The code produced during this stage relies heavily on the amount of time dedicated to the definition and planning stages of the SDLC. Therefore, if there were major flaws in definition and planning phases the product produced will certainly contain these flaws. In this stage of the SDLC, the software is also tested to provide data on its performance vis-à-vis the requirements (Langer 221).
It has been reported that due to the fact that VA did not ensure requirements were complete and sufficiently detailed, it was thus unable to guide the development of the scheduling system. It is reported based on guidance that the use of disciplined processes for definition and management can help reduce risks associated with developing a system that does not meet user needs.
Based on the failures associated with the system it is possible to infer that VA did not adhere to this practice. It is also essential that requirements should be well defined and documented by the team to make development an easier task. The move to abandon the scheduling system and begin afresh suggests that not only was the contractor in appropriate, the requirements were not properly defined and documented.
Implementation
During this stage in the development of software a number of tasks are undertaken. These tasks are important because they vet and review the requirements (Kostojohn, Paulen and Johnson 96). There are a number of approaches that can be utilized during development. In this stage the program will also be tested for integration.
It has been observed that the VA approach to the performance of testing increased the risk that the system would not perform as expected. This is because best practices suggest testing activities should be incremental in nature. This is because incremental testing will uncover minor issue which in turn may affect the overall performance of the system. This allows for early detection and correction of software errors. This leads to use of less time and resources in correcting errors.
It has been noted that instead of using the best practice approach to testing, the VA chose a high risk approach of undertaking all testing activity concurrently instead of incrementally.
This is based n information provided by project officials that indicated stage to testing on all 12 versions of the scheduling application began before stage one testing was completed. It has been mentioned that stage two testing began 78 days before stage one testing of the same version was completed. It is even mentioned in a further two cases that stage two testing began even before stage one testing.
It has been further pointed out that the first alpha version had 370 defects that were of critical, major or average severity. However, the department proceeded with these tests even when the departmental criteria for commencing stage two testing indicated that all such defects were to be resolved before stage two testing began. To deal with this issue caused by the defects the VA hired a second contactor to deal with the defects.
However, almost two years after commencing stage two testing 87 defects still remained unresolved. Scheduling project officials reported that they ignored the departmental testing guidance and approved stage two testing. Based on this it has been suggested that if the VA is to succeed in its new initiative it is critical that the project adhere to testing guidelines to ensure prompt problem resolution.
Operations and Maintenance
It has been reported that a significant amount of money spent system development goes into maintenance. For this reason there are a wide number of maintenance activities that can be undertaken on an information system. Corrective maintenance involves the repair of design and programming errors (Dixit 412).
Adaptive maintenance involves the modification of the system to changes in the operating environment. Perfective maintenance is meant to evolve a system and take advantage of existing opportunities (Dixit 412). There is also preventive maintenance, which is performed with a view to providing safety from future problems.
Upon analysis of the VHA system the changes made to the RTLS implementations suggests that the system was poorly maintained. Evidence of this is in the observation that non conformities led to difficulty in data retrieval, viewing and analysis. Based on this information it is possible to suggest that other than poor requirements definition there was poor maintenance. This is because such inconsistencies should have been identified upon implementation and rectified using corrective maintenance measures.
Close out
The final step in a software project is the closeout phase. This stage entails performing actions that effectively conclude a software project (Rittinghouse 157). In this stage the project team holds a post mortem meeting with the stakeholders. After this meeting, a report of the meeting is produced.
It is expected that the report will act as a road map for future activity involving the project (Rittinghouse 157). In the case of the VHA system due to inconsistencies and performance issues it is still not possible to complete this stage. This position suggests a need to take remedial action and conclude the project.
Recommendations
Based on the position revealed by the findings of this report the PE team will undertake investigations to identify shortfalls in the VA project. This position is due to the various high-level issues identified in this report. It has already been noted that poor requirements definition led the project to failure due to the fact that the project did not fully capture the organizations goals.
It has been suggested that this may have arisen because the users and the team did not collaborate adequately in the requirements analysis. Another issue with the project can be attributed to poor financial planning which saw the project utilize a large amount of financial resources and produce a faulty product. It would appear that there was an inadequate definition of requirements and milestones that may have guided the project to success.
In addition to that it has also been identified that there is a need for improvement in project management within the organization. This comes to light due to the fact that approval for step two testing came from within the organization. As such it is hoped that the information contained in this report can be used as a basis for further investigation in budgeting, planning, requirements analysis, testing and change management within the organization.
Works Cited
Dixit, J. B. Structured Systems Analysis and Design. New Delhi: Laxmi Publications (P) Ltd., 2007. Print.
ISACA. CGEIT Review Manual 2011. Printed in the USA: ISACA, 2011. Print.
Kostojohn, S., Brian Paulen, and Mathew Johnson. CRM Fundamentals. New York: Springer, 2011. Print.
Langer, Arthur M. Guide to Software Development: Designing and Managing the Lifecycle. London: Springer, 2012. Print.
Lewis, Jeremy. Sdlc 100 success secrets: Software Development Lifecycle (sdlc) 100 most asked questions. Brisbane: Lulu.com, 2008. Print.
Rittinghouse, John W. Managing Software Deliverables: a software development management methodology. Burlington: Digital Press, 2004. Print.
Tan, Joseph K. H., and Samuel Barry Sheps. Health Decision Support Systems. Maryland: Aspen Publishers Inc., 1998. Print.
Tan, Joseph K. H. Adaptive Health Management Information Systems: Concepts, Cases and Practical Applications. Sudbury, Jones and Bartlett Publishers, 2010. Print.