Reviewing The Issues Of Software Systems Information Technology Essay
In this paper I am particularly focus on the issue of failure in relation to that group of software systems known as information systems. Then I am going to discuss two well-known cases that of the London ambulance service computer-aided dispatch system (L ) project and The London stock exchange (TAURUS) project, and describe strong failure factors of information systems failure. My purpose is also to use the generic material on IS failure and the specific details of this particular case study to critique the issues of safety,
Like most computing professionals in the UK we were aware of the failure, using this term broadly, of the computer aided dispatch (CAD) system deployed by the London Ambulance Service (LAS) in, or shortly after,
For orientation a short sketch of the report follows. There have been a number of other analyses of the LAS CAD system failure of which Mellor (1994) is probably the most useful.
The London Ambulance System Disaster, 1992
The basic functionality of the intended LASCAD system was as follows: British Telecom (BT) operators would route all 999 calls concerning medical emergencies as a matter of routine to LAS headquarters (HQ) in Waterloo. 18 HQ ‘receivers’ were then expected to record on the system the name, telephone number and address of the caller, and the name, destination address and brief details of the patient. This information would then be transmitted over a local area network to a locator.
“The system was lightly loaded at start-up on 26 October 1992. Any problems, caused particularly by the communications systems (such as ambulance crews pressing the wrong buttons, or ambulances being radioed in black spots), could be effectively managed by staff. However, as the number of ambulance incidents increased, the amount of incorrect vehicle information recorded by the system increased. This had a knock-on effect in that the system made incorrect allocations on the basis of the information it had. For example, multiple vehicles were sent to the same incident, or the closest vehicle was not chosen for dispatch. As a consequence, the system had fewer ambulance resources to allocate. The system also placed calls that had not gone through the appropriate protocol on a waiting list and generated exception messages for those incidents for which it had received incorrect status information. Indeed, the number of exception messages appears to have increased to such an extent the staff were not able to clear the queue. It became increasingly difficult for staff to attend to messages that had scrolled off the screen. The increasing size of the queue slowed the system.”
Factors Contributed to Such a Disaster
LAS management ignored or chose not accept advice provided to it from many sources outside of the service on the time table or the high risk of the comprehensive systems requirement
The project did not show, or discuss with, the LAS Board independence references on the lead CAD contractor, that raised doubts on their ability to handle such a major project
The LAS boards were given a misleading impression, by the project team of the previous experience of the lead contractor in emergency service system
In awarding the contract for CAD to a small software house, with no previous experience of similar systems, LAS management were taking higher risk
Project management throughout the development and implantation process was inadequate and at times ambiguous. A major system integration project such as CAD requires full time. Professional, experienced project management, this was lacking
There was incomplete “ownership” of the system by the majority of it users. The many problems identified with many of the system components over the preceding months had installed an atmosphere of system destruct in which staff expected system to fail rather than willing it to succeed
LAS board and RHA management, whilst realizing that there were continuing problems with the implementation of CAD, consistently accepted assurances from executive directors that problems were being rectified and that successful implementation would be achieved at no time was a full independent review commissioned of the true state of the project
LAS fail to follow the PRINCE project Management Method in the set up and operation of an information Technology (IT) executive committee, project board, project management team and project assurance team: London Ambulance Service
The CAD system relied on near perfect information on vehicle location and status being available to it at all times. The project team failed to appreciate fully the impact that a higher level of imperfection would have on the system
The system was not fully tested to a satisfactory level of quality and resilience before full implementation on 26 October 1992
On 26 and 27 October 1992 the computer system itself did not fail in a technical sense. Response times did on occasions become unacceptable, but overall the system did what it had been designed to do. However, much of the design had fatal flaws that would, and did, cumulatively lead to all of the symptoms of systems failure
On 4 November 1992 the system did fail. This was caused by a minor programming error that caused the system to “crash” The automatic change over to the backup system had not been adequately tested, those the whole system was brought down
Training provided to CAD staff and to ambulance crews was incomplete and inconsistent
LAS management consultancy attributed CAD problems to willful misuse of the system by some ambulance crews. There is no direct evidence of this, but the circumstantial evidence that does exist indirect to the Inquiry Team that it would have been only one of the many contributory factors that led to the CAD failure
In the period leading up to an including 26 and27 October 1992 there were insufficient control assistants taking emergency call. This contributed to an unacceptable level of calling times. This has since been rectified
Failure was due to a complex mix of factors
Participation alone is not sufficient but helps!
Expectation of failure plays a part
does not meet the needs of the stakeholders
Systems should strive to meet the shared goals & needs of the different stakeholders
LONDON STOCK EXCHANGE (TAURUS) FAILURE
The London stock exchange is one of the largest stock exchanges in the world with numerous foreign listings as well as British organizations
In 1989 the London Stock Exchange (LSE) put forward a proposal for a computerized system to ensure that share certificates and cash changed hands between the interested parties after the trading transaction; implicit in this was the dematerialization of stock certificates. It was a big project with hundreds of staff contracted in and lots of external pressures from various different stakeholders.
The initial goals of the system were 4 folded.
What TAURUS Team did wrong?
Lack of executive and stakeholders support
Based on the problems encountered it seem that the project manager was not that experience
Have a large expanding scope
Went ahead with the implementation of a system with lack of user and stakeholder’s commitment.
Lack of skilled resources and clear complete specs.
Reason for TAURUS Collapse
Poor monitoring and controlling
Monitoring a project work includes collecting, measuring, and disseminating performance information. If TAURUS management had good monitoring and control practices they would have known when they project was not meeting project objectives
Poor management of the nine project management knowledge areas
TAURUS project managers managed the nine project management knowledge areas poorly
Scope: If they had managed the scope of the project effective the huge scope creep would not have been encountered.
Cost: If this was managed effectively the project would not have gone over budget 100%
Time: If this area had been manage effective the project would not have had a schedule overrun by 100%
Quality: If the quality area of the system was manage properly the specification was have been clear and complete
Risk: If the risk had been managed effectively they might have been able to abundant the project earlier.
Communication: If communication was managed all changes and delay would be communicated in a timely.
Human resources: skilled resources would be acquired and utilized.
Integrated Change Control
If TAURUS had an integrated change control they might have been able to influence the factors that create changes to ensure that changes are beneficial and control the scope of the project.
Changes would be communicated to top management and steering committee in a timely manner and they would be able to manage these changes as they occur because change control is a critical success factors.
Project Management Issues
Poor Management of triple constraints
TAURUS managers failed to control and monitor the scope of the project
Management failed to define maintain and utilize clear timetables with small milestones
Management failed to maintain and track change to the project budget
Additionally, the budget and time constraints of the projects were seen to be a differentiator to their success. Goulielmos (2003) states that of the four concepts of failure in Information Systems is process failure where the project over runs its budget or time constrictions. TAURUS did both incurring increasing media attention and scrutiny, which led to an increase in pressure on the project team (Head, 2001).
Throughout the project there were several warning signs that were missed.
The project completion date was delayed 100%
Constantly changing requirements
Project not being accepted by major stakeholders
100% over cost.
Fragmentation of the project (components to work together)
Appraisal of leading system development methodologies
This is the most common and classic of life cycle models, also referred to as a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase must be completed in its entirety before the next phase can begin. At the end of each phase, a review takes place to determine if the project is on the right path and whether or not to continue or discard the project. Unlike what I mentioned in the general model, phases do not overlap in a waterfall model.
Waterfall Life Cycle Model
Simple and easy to use.
One of the main advantages of the waterfall model is its simplicity. It is conceptually straightforward and divides the large task of building a software system into a series of cleanly divided phases, each phase dealing with a separate logical concern. It is also easy to administer in a contractual setup-as each phase is completed and its work product produced, some amount of money is given by the customer to the developing organization.
The project management stakeholders are forced to correctly define the business requirements documentation (BRD) and the project management requirements. At the sometime the developers are forced to understand these thoroughly before they start writing the software requirements specification (SRS), high level design and code.
It essentially requires documentation at every stage. This gives better understanding of the requirements, the logic of the codes and tests that were conducted on the software.
The project scope statement needs to be detailed in infinite depth from the start because changes are not possible when using waterfall methodology. This is because the only way to amend something which has been already developed is to go back and start again. This will cause huge problems on projects where the project sponsors are indecisive and quickly causes scope creep.
Project communications with the client are extremely limited being either at the beginning or at the end of the development. In between, there is no way in which one can get feedback or potentially clarify any confusion over what the requirement actually means. The knock on effect is that it is up to the project team to make the key decisions on what requirements can be developed within the timeframes required, and what is developed later in a later deployment release by project planning in teams. This not only increases the overall time required to develop the software but also means that despite the team’s best efforts, the customer may still be extremely unhappy with the end product delivered.
Key team members stay idle for long durations. You see Waterfall does not operate on a matrix basis which makes project resource management an extremely rigid activity. Basically those allocated to the project stay on it until that phase is over. This as we can imagine, has a direct knock on effect on the project budget.
It is a very inflexible method which does not entertain any change in requirements and which makes any subsequent functionality changes required extremely difficult and expensive to implement. As such the fast pace of changing requirements determined makes this methodology difficult to use and calls for more quick methods of software development such as agile methodology.
This is a cyclic version of the linear model. In this model, once the requirement analysis is done and the design for a prototype is made, the development process gets started. Once the prototype is created, it is given to the customer for evaluation. The customer tests the package and gives his/her feed back to the developer who refines the product according to the customer’s exact expectation. After a finite number of iterations, the final software package is given to the customer.
In this methodology, the software is evolved as a result of periodic shuttling of information between the customer and developer. This is the most popular development model in the contemporary IT industry. Most of the successful software products have been developed using this model – as it is very difficult to comprehend all the requirements of a customer in one shot.
For example, design documents, a test plan, and a test case specification are not needed during the development of the prototype. Another important cost-cutting measure is to reduce testing. Because testing consumes a major part of development expenditure during regular software development, this has a considerable impact in reducing costs. By using these types of cost cutting methods, it is possible to keep the cost of the prototype to less than a few percent of the total development cost.
Overall, prototyping is well suited for projects where requirements are hard to determine and the confidence in the stated requirements is low. In such projects where requirements are not properly understood in the beginning, using the prototyping process model can be the most effective method for developing the software. It is also an excellent technique for reducing some types of risks associated with a project.
Agile methodology is an approach to project management, typically used in software development. It helps teams respond to the unpredictability of building software through incremental, iterative work cadences,
10 Key Principles of Agile Software Development,
Active user involvement is imperative
2. The team must be empowered to make decisions
3. Requirements evolve but the timescale is fixed
4. Capture requirements at a high level; lightweight & visual
5. Develop small, incremental releases and iterate
6. Focus on frequent delivery of products
7. Complete each feature before moving on to the next
8. Apply the 80/20 rule
9. Testing is integrated throughout the project lifecycle – test early and often
10. A collaborative & cooperative approach between all stakeholders is essential
IT/IS Projects Fail. And How Agile Principles Help
Common cause of failure
How agile helps
Project Initiation & Planning Issues
Poor definition of project scope and objectives
Agile projects also benefit from clear definition of scope and objectives, even though details are allowed to emerge throughout the development.
Insufficient time or money given to project
If only agile could solve this!
Long or unrealistic timescales; forcing project end dates despite best estimates
Agile projects encourage short and regular iterations, developing the software and delivering working product in small bite size pieces.
Technical & Requirements Issues
Poor or no requirements definition; incomplete or changing requirements
Agile projects expect requirements to be incomplete and changing. That’s the nature of software. Instead of resisting this, agile projects provide for it by allowing requirements are allowed to emerge and evolve. Requirements being produced on a feature-by-feature basis, just in time to be developed, help with definition because it breaks this intensive task into small pieces instead of being a mammoth effort up front.
Unfamiliar or changing technologies; lack of required technical skills
Agile methods don’t help directly with this issue, although can help to surface such issues early, and make them visible.
Stakeholder Management & Team Issues
Inadequate visibility of project status
Agile projects provide clear visibility of measurable progress on a daily basis.
Project team members lack experience and do not have the required skills
Agile principles may help to surface such issues early, as they may well be evident in early iterations of the software. Frequent delivery of iterations and continuous testing can help to mitigate this risk when it might otherwise go unnoticed until much later in the project.
Poor collaboration, communication and teamwork
Close cooperation and collaboration between all stakeholders is essential.
Project Management Issues
Weak ongoing management; inadequately trained or inexperienced project managers
Agile methods and principles are just management tools. A fool with a tool is still a fool!
Ineffective time and cost management
Daily visibility of measurable progress.
The most Causes for Software Projects to fail Changes in Requirements
Classical Software Development life cycles assume that the requirements are fixed at the beginning of the project, Customer only sees the product at the end of the software development, Customer is not aware of the current status of the Software Development. This happens due to changes in the Business environment, as the customer uses a software module, he/she will see new features that are necessary
All modern software development methodologies (such as Agile) encourage shorter iterations, usually iterations are measured in weeks, and the developers demo the new features during the meetings with the customer at the end of each iteration. The customer can provide valuable feedback that will ensure that the software developed will meet the customer’s actual requirements.Order Now