On friday in Information Systems We went over the last few things about software strategy. And went over the things about Upgrade strategy
The Upgrade strategy has three issues they are:
Future Proofing
Compatibillity and integration testing
Support for legacy Systems
Future Proofing involves selecting hardware and software resources which will have a lifespan generally of three to five years, All new resources deployed by an organisation should be future proof.
An example of future proofing would be ensuring that a new computer system can be upgraded with additional memory and storage if required. If Upgrades or additional resources are to be used with existing systems, It is important that these resources and systems are tested for compatibility.
Compatibility Testing checks for unintended interactions that disrupt normal operation or decrease any other functional or non-functional properties of the system.
An example of compatibility testing would be ensuring that an upgrade version of a computer’s operating system was compatible with the organisation’s main applications.
There are several interrelated elements of computer systems which require testing when a new item of hardware or software is introduced to an existing system.
Integration testing is another type of testing which software and/or hardware components are combined and tested to confirm that they interact according to their requirements. Integration Testing can continue progressively until the entire system has been integraded.
An example of Integration Testing would be if a new stock control system were to be introduced in a large supermarket. The system would first be tested for compatibility with existing systems within the stock control area.
Legacy Systems are the systems which are in existance and either deployed or under development at the start of an upgrade program. All Legacy Systems will be affected by upgrading, to a greater or lesser extent.
Issues of cost make it important to support Legacy Systems as part of any upgrade strategy. Many effective and vital business applications were developed for mini and mainframe computer systems. These systems are costly to replace. Often the cost of developing new software to replace these applications is higher than the cost of purchasing new hardware.
One more quick thing
Emulation
Emulation requires an Emulator. An emulator is a product designed to imitate one system while running on another. The emulator accepts the same data, executes the same programs, and achieves the same results as the system it is emulating. The concept was invented by IBM Systems engineer Larry H. Moss in 1964 to describe the new IBM Systems/360 would provide support for programs that had been designed to work with older IBM Systems.
The downside of using an emulator is that often( but not always) the performance of the emulator may be slower than the native program, and it is possible that the emulator will not fully support modern hardware which was not supported by the emulated program.
Please leave comments
