DIRECTORATE OF CORRESPONDENCE COURSES KURUKSHETRA UNIVERSITY KURUKSHETRA

Master of Computer Applications (Part-II) Paper No. MCA-DE-26 Lesson No. 8 Software Maintenance The term software maintenance is used to describe the activities that occur following delivery of a software product to the customer. The maintenance phase of the system life cycle is the time period in which a software product performs useful works. Typically the development cycle for a system spans 1 to 2 years, while the maintenance phase spans 5 to 10 years. In common speech, the term maintenance means to fix things that break or wear out. In software there is no wear and tear; it is either wrong from the beginning or we decide later that we want to do something different. Maintenance activities involve making enhancement to system, adapting products to new environments, and correcting problems. Because changes are inevitable, a mechanism must be developed for evaluating, controlling and making modifications. The purpose of software maintenance is to preserve its value over time by enhancing the customer base, meeting additional requirements, making it easier to use and more efficient and employing newer technology. Categories of Maintenance: There is no reason to assume that changes will not be there. As the specification of computer system changes, external world changes, so must the system themselves. There are three different categories of software maintenance with very blurred distinctions between them: 1. Corrective maintenance: It is evident that it is virtually impossible to detect all the errors during the testing phase of the software. Those errors may occur during the operational use of the software. So corrective maintenance is concerned with fixing reported errors in the software. Coding errors are relatively cheap to correct. Design errors are more expensive as they may involve the rewriting of the several program components. Requirement errors are most expensive to repair because of the extensive system redesign, which may be necessary. In the event of system failure due to an error, actions are taken to restore operations of the software system. Due to the management pressure, sometime maintenance personnel use the emergence fix instead of following the proper maintenance process that results in an increased complexity of software and unforeseen ripple effects (i.e. a change in one part of a program may affect other sections of the software). This is often due to lack of time to carry out a thorough impact analysis before effecting the change. 2. Adaptive maintenance: Writer: Sh. Rakesh Kumar Vetter: Dr. Ashok Kumar

Changes in the environment are inevitable. So whenever the environment changes, the software are to be modified to adapt it according to the environment. So adaptive maintenance means changing the software to some new environment such as a different hardware platform or use with a different operating system. The software functionality does not radically change. This type of maintenance includes any work initiated as a consequence of moving the software to a different hardware or a software platformcompiler, operating system or a new processor. 3. Perfective maintenance Perfective maintenance activities involve making enhancements to software products i.e. implementing new functional or non-functional system requirements, improving user displays and modes of interaction, upgrading external documents and internal documentation, or upgrading the performance characteristics of the system. These requirements are generated by software customers as their organization or business changes. 4. Preventive maintenance: There are long term effects of corrective, adaptive and perfective maintenance. This leads to increase in the software complexity, which reflects deteriorating structure. The work is required to be done to maintain it or to reduce it, if possible. This work may be termed as preventive maintenance. These activities include code restructuring,. Code optimzation, and documentation updating. The intention of these activities is to make program easier to understand and hence facilitating future maintenance. Due to a number of changes in the software the complexity of the source code can increase to an unmanageable level, so a complete restructuring of the code is required. Code optimization is performed to enable the program to run faster or to make more efficient use of storage. Updating user and system documentation is often necessary when any part of software is changed. The documents affected by the change should be modified to reflect the current state of the system. It is well established that maintenance activities consume a large portion of the total life cycle budget. It is not uncommon for software maintenance to account for 70 percent of total system life cycle costs (with development requiring 30 percent). As a general rule of thumb, the distribution of effort for software maintenance includes 60 percent of the maintenance budget for enhancement, 20 percent each for adaption and correction. It id difficult to find up-to-date figures for the relative efforts devoted to these different types of maintenances. A survey by Lientz and Swanson discovered that about 65% of maintenance was pefective, 18% adaptive and 17% corrective as shown in the above figure. If maintenance consumes 70 percent of the total life-cycle effort devoted to a particular software product, and if 60 percent of maintenance goes to enhancing the product, then 42 percent of the total life-cycle effort for that product is dedicated to product enhancement. Given this pespective, it is apparent that the product delivered to the customer at the end of the development cycle is only the initial version of the system.

Some authors have suggested that the appropriate life-cycle model for software is development ->evolution -> evolution -> evolution *

Problems during Maintenance

This perspective makes it apparent that the primary goal of development should be production of maintainable system. The high cost of the maintenance is due to a number of problems listed below: 1. 2. 3. 4. 5. Maintenance is not as rewarding as exciting as developing systems. It is perceived as requiring neither skill nor experience. Users are not fully cognizant of the maintenance problem or its high cost. Few tools and techniques are available for maintanence. A good test plan is lacking. Standards, procedures and guidelines are poorly defined and enforced. The programs being maintained may have been developed many years ago without modern techniques. They may be unstructured and optimized for efficiency rather than understandability. Maintenance is viewd as a necessary evil, often devegated to junior programmers. There is particularly no maintenance manager job classification in the MIS field. Programs are often maintained without care for structure and documentation. As a system is changed, its structure tends to degrade. This makes the system harder to understand and make further changes difficult as the programs become less cohesive. There are minimal standards for maintenance. Programmer expects that they will not be in their current commitment by the tie their programs go into the maintenance cycle. Changes made to a program may introduce new faults, which trigger further change requests. New faults may be introduced because the complexity of the system may make it difficult to assess the effects of a change. The links between a program and its associated documentation are sometimes lost during the maintenance process. The documentation may therefore be an unreliable aid to program understanding.

6. 7.

8. 9. 10.

11.

Possible solutions to maintenance problems: A number of possible solutions have been suggested to maintenance problems. Such as (1) Budget and effort reallocation. (2) Complete replacement of existing system (3) Enhancement of existing system. It is suggested that more time and resources should be invested during development and hence making the system more maintainable rather than allocation the resources to maintain a difficult to maintain system. If the cost of maintenance is too high, it is better to replace it by a new system but the cost and risk associated with complete system replacement are very high which is not a viable option sometimes. So sometimes a better approach is to maintain existing

system. The current system may need to have the potential to evolve to a higher state, providing more sophisticated user-driven functionalities, the capability of developing cutting edge technology and of allowing the integration of other systems in a cost-effective manner. The maintenance process: The maintenance process is triggered by a set of change request from system users, managers or customers. Once maintenance objective is established, the maintenance personnel must first understand what they are to modify. Then they must modify the program to satisfy the maintenance objectives. The cost and impact of these changes are assessed. If the proposed changes are accepted, a new release of the system is planned. This release will usually involve elements of adaptive, corrective and perfective maintenance. The changes are implemented and validated and a new version of the system is released. An overview of the maintenance process is given below: CHANGE REQUEST
IMPACT ANALYSIS
SYSTEM RELEASE PLANNING
CHANGE IMPLEMENTATION CHANGE IMPLEMENTATION

CHANGE IMPLEMENTATION

CHANGE IMPLEMENTATION

SYSTEM RELEASE

Software Maintenance process (An overview) In some system, to keep it functional every time is utmost necessary. So there is a lot of management pressure on the maintenance personnel. Change requests sometimes relates to system problems that must be tackled urgently. For example a fault in the system may have to be quickly remedied to allow normal business to continue. In this type of situation, it is difficult to follow the normal maintenance process. At that time the maintenance process will be as follows:

The Fault Repair Process

This emergency repair approach is sometimes necessary if the reported problems affect system availability. However, the danger of this approach is that design documents are not updated. The code and design gradually becomes out of step. It is difficult to avoid this happening because maintenance engineers may be pressurized to deal with new emergency fixes to the software. If an engineer who made the code changes leaves the team before the design is updated, it is then difficult for his or her replacement to retrofit the necessary design changes. A further problem with emergency system repair is that they have to be completed as quickly as possible. A workable solution rather than best solution as far as system structure is concerned may be chosen. This accelerates the process of software aging so that future changes become progressively more difficult. Rather than view the maintenance as a separate process, it should normally be considered as an iteration of the development process. New requirements must be formulated and validated, components of the system must be redesigned and implemented and part or all of the system must be tested. This implies a process model shown below:

Maintenance as iterative development This iterative development process is effective when changes are not urgent and can be batched. If emergency code repairs have to be carried out, the problem of document inconsistency and degraded structure can be avoided if he change request for the repair remains outstanding after the code faults have been fixed. It can then be implemented more carefully after further analysis. Analysis activities during software maintenance involve understanding the scope and effect of desired change, as well as constraints on making the changes. Design during maintenance involves redesigning the product to incorporate the desired changes. The changes then must be implemented, internal documentation of the code must be updated, and new test cases must be designed to assess the adequacy of the modification. Also the supporting documents (requirements, design specifications, test plan, principles of operations, users manuals etc.) must be updated to reflect the changes. Updated version of the system then be distributed to various customers cites. Enhancing maintainability during development: Many activities performed during software development enhance the maintainability of the product. Some of these activities are listed below: Analysis activities The analysis phase is concerned with identifying the functional and non-functional requirements (constraints) of the users. Following analysis activities are helping in making understandable and modifiable software:

 Develop standards and guidelines: Various types of standards and guidelines can be developed to enhance the maintainability of software. Standard formats for requirements documents and design specifications, structured programming conventions, and standardized format for supporting documents such as the test plan, the installation manuals, and the user manuals contribute to the understandability and hence the maintainability. Set milestones for the supporting documents to ensure that the work products are produced on schedule. Specify quality assurance procedures to ensure the development of high quality products. Identify likely product enhancements that will most likely occur following the initial delivery of the system. Determine resources required for maintenance (personnel, equipment, and floor space). Estimate maintenance cost. High-level design activities High-level design is concerned with identifying the modules in the software, conceptual data structures, and interconnection between the modules. Following high-level design activities affect the maintainability of the software: Emphasize clarity and modularity as design criteria. The criteria may include coupling, cohesion, efficiency considerations, interface to existing software, features in the machine architecture etc. Design to ease likely enhancements Use standard notations to document data flow, functions, structures and interconnections. These forms of design documentation aid the software maintainer who must understand the software product well enough to modify if and re-validate it. Observe the principles of information hiding, data abstraction, and top-down hierarchical decomposition. These concepts are appropriate mechanisms for achieving a clearly understandable, modular and easily modified system structure. Detailed design activities Detailed design is concerned with specifying the algorithm for modules identified in the highlevel design, data representations and details of the interfaces among the modules. Following detailed design activities will affect the maintainability of the software: Used standardize notations to specify the algorithms, data structure and procedure interface specification. Specify side effects and exception handling for each routine. Provide cross-reference directories and call graph. These indicate the scope of effect of each module and provide the information needed to determine which modules and data structures are affected by modification to other modules. Implementation activities

Implementation should have the primary goal of producing software that is easy to understand and easy to modify. Following are the activities, which improve the maintainability of the software: Use single entry and single exit constructs. Use standard indentation of constructs Use simple clear coding style Use symbolic constants to parameterize routines Provide margins on resources Provide standard documentation prologue for each routine Follow standard internal commenting guidelines Other activities Develop a maintenance guide. Develop a test suite Provide test suit documentation. Maintenance Cost: Maintenance costs vary widely from one application domain to another. For business application systems, the maintenance costs were broadly comparable with system development costs. For embedded real systems, maintenance cost may be up to four times higher than development costs. The high reliability and performance requirements of these systems may require modules to be tightly linked and hence difficult to change. Maintenance costs are related to a number of product, process and organizational factors. The principal technical and non-technical factors, which affect maintenance, are: 1. 2. 3. 4. Module independence: It should be possible to modify one component of a system without affecting other system components. Programming language: Programs written in a high level language are usually easier to understand and hence maintain than programs written in a low level language. Programming style: The way in which a program is written contributes to its understandability and hence the ease with which it can be modified. Program validation and testing: Generally, more time and effort is spent on design validation and program testing, the fewer errors in the program, consequently, corrective maintenance cost is minimized. The quality of program documentation: If a program is supported by a clear, complete yet concise documentation, the task of understanding the program can be relatively straightforward. Program maintenance cost tends to be less for well-documented systems than for systems supplied with poor or incomplete documentation. The configuration management techniques used:

5.

6.

7.

One of the most significant costs of maintenance is keeping track of all system documents and ensuring that these are kept consistent. Effective configuration management can help control this cost. The application domain: If the application domain is clearly defined and well understood, the system requirements are likely to be complete. Relatively little perfective maintenance may be necessary. If the application is in a new domain, it is likely that the initial requirements will be modified frequently, as users gain a better understanding of their real needs. 8. Staff stability: Maintenance costs are reduced if system developers are responsible for maintaining their own programs. There is no need for other engineers to spend time understanding the system. In practice, however, it is very unusual for developers to maintain a program throughout its useful life. 9. The age of the program:

As a program is maintained, its structure is degraded. The older the program, the more maintenance it receives and more expensive this maintenance becomes. 10. The dependence of the program on its external environment:

If a program is dependent on its external environment it must be modified as the environment changes. 11. Hardware stability:

If a program is designed for a particular hardware configuration that does not change during the programs lifetime, no maintenance due to the hardware changes will be required. However, this situation is rare. Program must often be midified to use new hardware, which replaces obsolete equipments. Process metrics for assessing the maintainability: Following metrics may be useful for assessing the maintainability: 1. Number of requests for corrective maintenance: If the numbers of failure reports are increasing, this may indicate that more errors are being introduced in the program than are being repaired during the maintenance process. This may indicate a decline in maintainability.

2. Average time required for impact analysis:

This reflects the number of program components that are affected by the change request. If this time increases, it implies more and more components are affected and maintainability is decreasing. 3. Average time taken to implement a change request: This is not the same as the time for impact analysis although it may correlate with it. The activities involved are making changes to the system and its documentation rather than simply assessing what components are affected. This change time depends upon the difficulty of programming so that non-functional requirements such as performance are met. If the time to implement a change increases, this may indicate a decline in maintainability. 4. Number of outstanding change request: If this number increases with time, it may imply a decline in maintainability. Maintenance Tools and Techniques Because software maintenance is a microcosm of software development, the activities that a software maintainer may become involved in span the entire spectrum of software engineering. The maintainer may analyze change requests; negotiate with users; formulate recommended solutions for the change control board, including cost estimates and priorities; debug software; provide temporary fixes and emergency repairs; redesign, modify; and revalidate software; update external documentation and master tapes; retain and protect physical media; perform configuration control; and provide liaison and user training for software product users. In some organizations, the software maintainer is supported: By analysts who provide user liaison and formulate recommendations to the change control board. By a training organization that trains users. By technical writers who update the supporting documents. By quality assurance personnel who revalidate modified software, perform configuration management, and maintain physical media. In the ad hoc approach to software maintenance, the maintenance programmer performs all of these activities without the benefit of a change control board to provide guidance. Automated tools to support software maintenance include technical support tools and managerial support tools. Tools to support the technical aspects of software maintenance span the spectrum from analysis and design tools to implementation tools to debugging and testing tools. Automated tools of special importance for software maintenance are itemized in the following table. They include text editors, debugging aids, cross-reference generators, linkage editors, comparators, complexity metric calculators, version control systems, and configuration management databases. A text editor permits rapid, efficient modification of source programs, test data and supporting documents. Text editors can be used to insert and replace segments of source code, internal comments, test data, and supporting documents; to systematically change all occurrences of an

identifier or other textual string; to locate all references to a given identifier or other string of text; and to save both old and new versions of a routine, test file, or document. A syntaxdirected text editor can be used to preserve the structure of source code, and an intelligent text editor can ensure that all cross references in the supporting documents are correctly updated. Automated tools for software maintenance Text editors Debugging aids Cross-reference generators Linkage editors Comparators Complexity metric calculators Version control systems Configuration management databases Debugging aids provide traps, dumps, traces, assertion checking, and history files to aid to locating the causes to known errors. System-level cross-reference generators provide crossreference listings for procedures calls, statement usage, and data references. Cross-reference directories provide the calling structure (the call graph) of who calls whom and from where, and procedure names and statement numbers where formal parameters, local variables, and global variables are defined, set, and used. A linkage editor links together object modules of compiled code to produce an executable program. Linkage editors can be used by a maintenance programmer to configure a system in various ways, and to link selectively recompiled modules into a software system. Linkage editors for Ada programs provide consistency checking of parameter lists between calling and called routines, cross-references of all system-level names, and incremental recompilation and linkage of modified routines. A comparator compares two files of information and reports the differences. Comparators can be used during maintenance to compare two versions of a source program, a test suite, a file of test results, or two versions of a supporting document. Use of a comparator allows the maintenance programmer to pinpoint differences between versions, to determine whether a modification has achieved a desired result, and to determine whether adverse side effects have been introduced by a modification. Source-code complexity metrics, like cyclomatic complexity may be useful in software maintenance. Use of complexity metrics requires automated tools to compute the measures of interest. The complexity of source code can be compared before and after a modification is made to determine whether complexity, as measured by the metrics utilized, has increased as a result of the modification. Source-code complexity metrics, like cyclomatic complexity may be useful in software maintenance. Use of complexity metrics requires automated tools to compute the measures of interest. The complexity of source code can be compared before and after a modification is made to determine whether complexity, as measured by the metrics utilized, has increased as a result of the modification.

Version control systems and configuration management databases are also useful in software maintenance. They can be used to track the history of each module in a system by recording which modules and which versions of which modules comprise which system releases. These tools can also be used to associate source modules with object modules, to record which versions use which modules, and to provide system protection by preventing updates to master files that have not been approved by the change control board. Also, a version control system can coordinate experimental versions of a system when several maintenance programmers are simultaneously modifying the same module or subsystem. Other aspects of change control that can be supported by automated tools include change request processing, periodic status reporting, change control board recommendations, quality assurance tracking, and updating of historical data. CASE TOOLS Historically, the most significant productivity increases in manufacturing or building processes have come about when human skills are augmented by powerful tools. One man and a bulldozer can probably shift more earth in a day than 50 men working with hand tools. Similarly, the productivity of engineering designers is improved when they are supported by CAD systems which take over tedious drawing chores and which check the design for errors and omissions. Automated tool support for software engineers should therefore lead to improvements in software productivity. Since the early 1980s, a wide range of tools to support software development has been developed. CASE provides the software engineer with the ability to automate manual activities and to improve engineering insight. Three different levels of CASE technology can be identified: Production-process support technology: This includes support for processes activities such as specification, design, implementation, testing, and so on. These were among the earliest and consequently are the most mature CASE products. Process management technology: This includes tools to support processes modeling and process management. These tools will call on production process support tools to support specific process activities. A few products in this area are available but it is still the subject of considerable research. Meta-CASE technology: Meta-CASE tools are generators, which are used to create production-process and process management support tools. Some meta-CASE tools are available but they are not easy to use and have not been widely adopted. The market for CASE products expanded very rapidly in the late 1980s and early 1990s but now seems to have entered a period of slower growth. This is partly due to general economic circumstances. However, the first generations of CASE products have not led to the high level of productivity improvements, which were predicted by their vendors. There are various reasons for this:

 For large system development, the fundamental problems were accurately identified by Brooks (1987). They are the problems of managing complexity both in the product being developed and in the development process. Brooks suggested that CASE technology can provide some support but cannot address this essential problem of complexity to any significant extent. Current CASE products represent islands of automation where various process activities are supported to a greater or lesser extent. Integration between these different products is limited. This limits the applicability of the technology. Adopters of CASE technology sometimes underestimated the training and process adaptation costs, which are essential for the effective introduction of CASE. They often skimped on these costs with the consequence that the CASE technology was underutilized. We now have a more realistic view of the costs and benefits of CASE technology. It has not revolutionized software development nor has it produced orders of magnitude productivity improvements. Software engineering has not yet benefited from automation to the same extent as other engineering disciplines. Nevertheless, CASE technology can be applied in a cost-effective way to reduce software costs and development time significantly and to increase software quality; the availability of CASE support makes it possible to re-engineer some software processes so that they are more effective. Thus, CASE has contributed and will continue to contribute to the development of software engineering. CASE classification: CASE tools can be classified by functions, by their role as instruments for managers or technical people, by their use in the various steps of the software engineering process, by the environment architecture (hardware and software) that supports them, or even by their origin or cost. A classification scheme for CASE technology allows different types of tool to be assessed and compared. It also provides a conceptual basis for understanding and explaining the field. In the following figure a number of different types of CASE tools and their specific examples are listed. There are other, more specialized, tool classes, such as tools for support software reuse, tools for software re-structuring and so on, which might be included in some systems. Tools type Management tools Editing tools Configuration management tools Prototyping tools Method support tools Language processing tools Examples PERT tools, estimation tools Text editors, diagram editors, word processors Version management systems, change management systems Very high-level languages, user-interface generators Design editors, data dictionaries, code generators Compilers, interpreters

Program analysis tools Testing tools Debugging tools Documentation tools Re-engineering tools

Cross-reference generators, static analyzers, dynamic analyzers Test data generators, file comparators Interactive debugging systems Page layout programs, image editors Cross-reference systems, program re-structuring systems

Functionality is one possible classification dimension where the tools are classified according to the functions they support. Other possible classification dimensions are: Process support: What process phases are supported by the CASE technology? Tools can be classified as design tools, programming tools, and maintenance tools and so on. Breadth of support: What is the extent of process activity supported by the technology? Narrow support means support for very specific tasks in the process such as creating an entity-relation diagram, compiling a program, etc. Broader support includes broader support for process phases such as design with the most general support covering all or most phases of the software process. Following figure is an activity-based classification which shows the process phases supported by a number of different types of CASE tool. Tools for planning and estimating, text editing, document preparation and configuration management may be used throughout the software process. Specification Design Implementation V&V Test data generations tools Modeling & Simulation tools Program transformation tools Interactive debugging systems Program analysis tools Language processing tools Method support tools User interface mgmt. Systems Data dictionary tools Diagram editing tools Prototyping tools Configuration management tools Document preparation tools Text editing tools Planning & estimation tools

Activity based classification of CASE tools This classification shows that tool support is available for all process activities from specification through to verification. Obviously, these tools are also used in system maintenance. This would appear to suggest that computer-aided software engineering has now matured with good coverage of all process activities. However, the quality of the available support is uneven. Very good support for design and implementation activities is available but significantly weaker support for requirements and maintenance. These differences are illustrated in following figure. The excellent quality of the support for system modeling, design and programming reflects the fact that these activities are relatively well understood. The more difficult activities of requirements definition, formal specification and maintenance are not well supported by CASE. CASE support is most successful when it is based on some method. We currently do not have effective methods for these activities.

Quality of CASE support for software process activities The breadth of support for the software process offered by CASE technology is another possible classification dimension. Fuggetta (1993) proposes that CASE systems should be classified in three categories: (1) Tools: Tools support individual process tasks such as checking the consistency of a design, compiling a program, comparing test results and so on. Tools may be general-purpose, stand-alone tools (for example, a word processor) or may be grouped into workbenches. Workbenches: Workbenches support process phases or activities such as specification, design and so on. They normally consist of a set of tools with some greater or lesser degree of integration. Environments: Environments support all or at least a substantial part of the software process. They will normally include several different workbenches, which are integrated in some way.

(2)

(3)

Following figure illustrates this classification and shows some examples of these different classes of CASE support. This figure shows only general-purpose tools rather than tools which are built into workbenches. General-purpose tools are used at the discretion of the software engineer who makes decisions about when to apply them for process support Workbenches, however, usually support some method, which includes a process model, and a set of rules/guidelines, which apply to the software being developed. The workbench should therefore provide some guidance on how to apply the method and when tools in the workbench should be used.

Tools, workbenches and Environments Environments are classified as integrated environments or process-centered environments. Integrated environments provide infrastructure support for data, control and presentation integration. Process-centered environments are more general. They also include software process knowledge and a process engine, which uses this process model to advice engineers on what tools or workbenches to apply and when they should be used. In practice, the boundaries between these different classes are not clear-cut. Tools may be sold as a single product but may embed support for different activities. For example, many word processors now provide a built-in diagram editor. As CASE workbenches mature and are made available on more powerful hardware, they offer increasing support for programming and testing so they resemble software engineering environment. It may therefore not always be easy to position a product using a classification. Nevertheless, it provides a useful first step to help understand the degree of process support, which a tool is likely to provide. Integrated CASE: The real power of case can be achieved by the integration of individual case tools. The Integrated-CASE environment combines integration mechanism for data, tools, and human-computer interaction. Data integration can be achieved through direct exchange on information, through common file structures, by data sharing or interoperability. Tools integration can be custom-designed by vendors who work together or through management software. Human-computer integration is achieved through interface standards that are becoming increasingly common throughout the industry. Wasserman proposed a five-level model for integration in software engineering environments. (1) Platform integration: Tools run on the same hardware/operating system platform. The major problems which arise with platform integration occur when an organization runs a heterogeneous network with different computers running different operating systems. (2) Data Integration: Tools operate using a shared data model. There are a number of different levels of data integration: (a) Shared files: All tools recognize a single file format. (b) Shared data structures: The tools make use of shared data structures the details of which are agreed in advance by all tools and are hard-wired into the tools. (c) Shared repository: The tools are integrated around an object management system, which includes a public, shared data model describing the data entities and relationships, which can be manipulated by the tools. (3) Presentation integration: Tools offer a common user interface. There are different levels of presentation integration: (a) Window system integration: Tools use the same window system. Windows have the same appearance and the same commands for window movement, resizing, iconification and so on. (b) Command integration: Tools use the same form of command for comparable function. In a textual user interface, the syntax of command lines and the

parameters is the same for all commands. In the Graphical user interface the menu items are positioned in the same place in each application and the same icons are used in all sub-systems for button, menus, and so on. (c) Interaction integration: this means that the same direct manipulation operations such as selection and deletion are provided in all sub-systems. So if a text is selected by double clicking, it should be possible to select entities in a diagram in the same way. (4) Control Integration: Tools may activate and control the operation of other tools. A tool can start and stop other tools; a tool can call on services provided by another tool in the system. (5) Process integration: Tools usage is guided by an explicit process model and associated process engine. In it the CASE system has embedded knowledge about the process activities, their phasing, their constraints and tools needed to support these activities. The CASE system participates in the scheduling of these activities and in checking that the required activity sequence is maintained. Benefits of I-CASE: The benefits of integrated CASE (I-CASE) are: 1. 2. 3. 4. Smooth transfer of information from one tool to another tool and one software engineering step to the next. A reduction in the efforts required to perform activities such as configuration management, quality assurance, and documents production. An increase in project control that is achieved through better planning, monitoring and communication. Improved coordination among staff members who are working on a large software project. Provide a mechanism for sharing software engineering information among all tools contained in the environment. Enable a change to one item of information to be tracked to other related information items. Provide version control and overall configuration management for all software engineering information. Allow direct non-sequential access to any tool contained in the environment. Enable the users of each tool to experience a consistent look and feel at the humancomputer interface. Support communication among software engineers. Collect both management and technical metrics that can be used to improve the process and the product.

An I-CASE environment should fulfill the following requirements: 1. 2. 3. 4. 5. 6. 7.

Exercises:

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 1. 2. 3. 4.

What do you understand by software maintenance? Why is it needed? What are the different types of software maintenance? What are the factors influencing the maintenance cost? Explain. What are the different activities to be carried out during software maintenance? Explain. What are the activities during development of the software, which may affect the maintainability of the software? Explain. What do you understand by software metric? Discuss the process metrics for assessing the software maintainability. What are the implications of maintenance for a one-person software production organization? What do you think that the mistake is frequently made of considering software maintenance to be inferior to software development? Discuss the various problems during maintenance. Describe some solutions to these problems. What is self-descriptiveness of a program? Explain the effect of this parameter on maintenance activities. What is ripple effect? Discuss the various aspects of ripple effect and how does it affect the stability of a program? What do you understand by Computer Aided Software Engineering (CASE)? What are the advantages of it? Differentiate between CASE tool, CASE workbenches, and CASE environments. Explain the activity based classification of CASE tools. What is I-CASE? What are the advantages of it? What facilities should be provided by an I-CASE environment? Software Engineering concepts by Richard Fairley (McGraw Hill) Software Engineering by K.K.Aggarwal and Yogesh Singh (New Age International Publishers) Software Engineering by Ian Sommerville (Addison Wesley) Software Engineering by Roger S. Pressman (McGraw-Hill Publication)

References: