After reading this week’s assignment, I think an important takeaway that is worthy to discuss is how organizations should be managing their system maintenance since it is one of the most costly expenditures for many types of organizations. According to the book, more programmers today work on maintenance activities than work on new development of software or applications. The maintenance phase can begin soon after the system is officially installed. As with the initial design of a system, maintenance activities are not limited only to software changes or updates, but can also include changes to hardware and business procedures. Some of the maintenance phases include are, Obtaining Maintenance Requests, Transforming Requests into Changes, Designing Changes, and Implementing Changes. The maintenance phase is always ongoing and a never-terminating phase of the system development life cycle (SDLC). This chapter helped me better understand the maintenance process and the different types of issues that must be considered when maintaining a system.
Maintenance should definitely be a focus of any organization. When you think about saving money, it pays for itself. For physical maintenance, it’s cheaper to schedule downtime to clean hardware, defragment a disk, replace aging parts, etc. than to have an unplanned outage because something broke … and maybe now you have to replace the whole system instead of just one part. It helps to have spare parts inventories or SLAs with vendors and to have a policy to adhere to the vendor maintenance schedule. For software maintenance, you can make tweaks to code as you go along to improve functionality or fix bugs. Nothing is perfect. You can’t just set up a system and forget about it. They need to be continuously managed and maintained.
Software application testing is an activity that analysts plan in the analysis phase of the SDLC. Software testing begins early in the SDLC, even though many of the actual testing activities are carried out during implementation and the purpose of testing is to confirm that the system satisfies requirements. It is in this stage that all the plans are tested whether manually or automatically. Manual code reviews can be very time consuming and tedious work; and, most importantly, are not always the best solution. They involve inspection of code, walkthroughs of the system, and desk checking. Test harness which is an automated testing environment used to review code for errors, standards violations, and other design flaws can be used to help designers and tester to review code automatically. Automatic testing can be done in four ways, syntax checking, unit test, integration test and system test. Once the system tests have been satisfactorily completed, the system is ready for acceptance testing. Either alpha or beta testing will be done and once that is successful then installation of the system can happen.
You bring up an interesting point about code reviews. Code reviews are absolutely essential, but there are better ways than only having someone sit down and read thousands of lines of code. There are a ton of automated code reviewing software options available that can easily find errors and insecure coding practices. Sure, you can’t always replace a human’s ability to use their logical reasoning or experience. But manual code reviews can take a long time and may not always be worth it.
I think this comment is spot on! Like most things there are automated tools that can replace the repetitive and ‘low hanging fruit’ of finding common errors etc. However, code reviews are invaluable to ensure that the coding techniques and software architecture is consistent across an application. Having developers look at each others work within a dev team can be tedious, but the results of doing some form of this are substantial – especially when coupled with the tools that Jonathan mentions above.
I completely agree that maintenance is an extremely important yet costly part of implementation. It was interesting seeing the different ways in which organizations try to reduce maintenance costs. One way is through automated development tools. These tools are used to decrease the time spent on maintaining system documentation by having code generators automatically create new system versions based on criteria set by analysts. These code generators take the input regarding data flow and screen designers and update the source code accordingly. Other automation tools include reverse engineering and re-engineering. Reverse engineering can be used to perform analyses, create data flows, and produce graphical and textual representations. Re-engineering, on the other hand, can be used to alter a current system to improve quality or performance. These automated processes can be extremely useful by decreasing the time, and therefore the cost, of maintaining systems.
Reverse engineering involves deconstructing software, machines, and other products to extract design information from them. The reverse engineering process enables you to determine how a part was designed so that you can recreate it. Organizations often use this approach when purchasing a replacement part from an original equipment manufacturer (OEM) is not an option. Reverse engineering is beneficial for making product improvements and replicating legacy parts. It extends the life of the machinery and equipment which in turn reduces operating costs. One of the disadvantages of reverse engineering is facing legal ramifications if copyright and patent laws are not followed.
Maintenance is definitely the most expensive expenditure for organizations. What interested me the most for this week’s reading was the different types of maintenance which are corrective, adaptive, perfective and preventive. Corrective maintenance refers to changes made to repair defects in the design, coding, or implementation of a system. When corrective maintenance problem occurs, they are urgent and need to be resolved to avoid interruptions in normal business activities. Adaptive maintenance refers to making changes to an information system to evolve its functionality to changing business needs. They are usually less urgent than corrective maintenance because business and technical changes typically occur over some period of time. Perfective maintenance refers to making enhancements to improve processing performance or interface usability. Preventive maintenance refers to changes made to a system to reduce the chance of future system failure. Corrective maintenance is the higher priority among all of these.
In Chapter 13 what I think is interesting is how organization maintenance on an information system. There are several types of maintenance to facilitate organizations to solve the problems, including corrective, adaptive, perfective, and preventive. First, corrective maintenance is focused on repairing the system design and removing the application errors, and it is the major maintenance activity for other ones. Adaptive maintenance is based on the business requirements and the system environment to adjust the application. Perfective maintenance helps the organization to improve the application performance and adds the usability of function so that the new system is aligned with business strategy and business strategy. Last, preventive maintenance could be the last defense line that reduces the problem of the system in the future. If the organization identifies any bugs earlier, it helps to lower some potential losses, such as financial loss and reputation loss. Therefore, the four types of maintenance help the organizations to manage the cost, risk, and project efficiently.
One other dimension of maintenance that was not mentioned in the book but is also very important is the way it is categorized from an accounting POV. Maintenance cannot be capitalized and therefore needs to be treated as expense and fully amortized in the period that it is incurred. Combine this fact with the point Elias raised that it is the largest consumer of resources and this makes getting maintenance right even more important to an organization!