Software evolution and maintenance basic concepts and preliminaries
Download as PPTX, PDF2 likes1,186 views
The document provides an overview of key concepts related to software maintenance and evolution, including: - Software maintenance focuses on preventing failures and involves bug fixing without major design changes. - Software evolution describes how software grows over time to support new features and changes in technology. - Reengineering examines a system to restructure it in a new form through reverse and forward engineering. - Legacy systems are old systems still valuable to organizations that are in the phase out stage of their lifecycle.
Software evolution and maintenance basic concepts and preliminaries
- 1. Software Evolution and Maintenance A Practitioner’s Approach Chapter 1 Basic Concepts and Preliminaries
- 3. Outline • Software maintenance • Software evolution • Software Re-engineering • Legacy System • Impact Analysis • Refactoring • Program Comprehension • Software Reuse
- 4. Software Maintenance • The concept of software maintenance means preventing software from failing to deliver the intended functionalities by means of bug fixing. • Maintenance does not involve making major changes to the architecture of the system. maintenance means keeping an installed system running with no change to its design. • For example, bug fixing must be done and it is a planned activity.
- 6. The hierarchical ways of maintenance modifications • Kitchenham described maintenance modifications in a hierarchical ways based on the concept of activity: 1. Activities to make corrections: If there are discrepancies between the expected behavior of a system and the actual behavior, then some activities are performed to eliminate or reduce the discrepancies. 2. Activities to make enhancements: A number of activities are performed to implement a change to the system, thereby changing the behavior or implementation of the system. This category is subdivided into three types: 1. enhancements that change existing requirement, 2. enhancements that add new system requirements, and 3. enhancements that change the implementation but not the requirements.
- 7. Type of software maintenance • E. Burton Swanson defined three type of software maintenance: • Swanson definition was later updated in the standard for software engineering – ISO/IEC 14764. • Introduced a fourth category called maintenance. Corrective | Adaptive | Perfective Preventive
- 9. Software evolution “software evolution to describe the growth characteristics of software and means of creating new system but related designs from existing ones” • The objectives include supporting new functionalities, making the system perform better, and making the system run on a different operating system.
- 10. Software Evolution: Laws of Lehman • Continuing change (1st) – A system will become progressively less satisfying to its user over time, unless it is continually adapted to meet new needs. • Increasing complexity (2nd) – A system will become progressively more complex, unless work is done to explicitly reduce the complexity. • Self-regulation (3rd) – The process of software evolution is self regulating with respect to the distributions of the products and process artifacts that are produced. • Conservation of organizational stability (4th) – The average effective global activity rate on an evolving system does not change over time, that is the average amount of work that goes into each release is about the same.
- 11. • Conservation of familiarity (5th) – The amount of new content in each successive release of a system tends to stay constant or decrease over time. • Continuing growth (6th) – The amount of functionality in a system will increase over time, in order to please its users. • Declining quality (7th) – A system will be perceived as losing quality over time, unless its design is carefully maintained and adapted to new operational constraints. • Feedback system (8th) – Successfully evolving a software system requires recognition that the development process is a multi-loop, multi-agent, multi-level feedback system.
- 12. Summary Software maintenance Software evolution Software Re-engineering
- 13. Re-engineering Chikofsky and Cross II define reengineering as “the examination and alteration of a subject system to reconstitute it in a new form and the subsequent implementation of the new form.”
- 14. Reengineering = Reverse engineering + + Forward engineering. • Reverse engineering is the activity of defining a more abstract, and easier to understand, representation of the system. • The core of reverse engineering is the process of examination, not a process of change, therefore it does not involve changing the software under examination. • : captures alteration that is change of the system. • forward engineering is the traditional process of moving from high- level abstraction and logical, implementation-independent designs to the physical implementation of the system.
- 15. Legacy System “An old or obsolete system which is valuable for the company which often developed and owns it” (Phase out stage of the software evolution model ).
- 16. Legacy systems management solutions • Freeze: The organization decides no further work on the legacy system should be performed. • Outsource: An organization may decide that supporting software is not core business, and may outsource it to a specialist organization offering this service. • Carry on maintenance: Despite all the problems of support, the organization decides to carry on maintenance for another period. • Discard and redevelop: Throw all the software away and redevelop the application once again from scratch. • Wrap: It is a black-box modernization technique – surrounds the legacy system with a software layer that hides the unwanted complexity of the existing data, individual programs, application systems, and interfaces with the new interfaces. • Migrate: Legacy system migration basically moves an existing, operational system to a new platform, retaining the legacy system’s functionality and causing minimal disruption to the existing operational business environment as possible.
- 17. Summary Software maintenance Software evolution Software Re-engineering Existing systems or Legacy systems New System Reverse engineering + + Forward engineering
- 18. Impact Analysis • Impact analysis is the task of estimating the parts of the software that can be affected if a proposed change request is made. • Impact analysis techniques can be partitioned into two classes: 1. Traceability analysis In this approach the high-level artifacts such as requirements, design, code and test cases related to the feature to be changed are identified. A model of inter-artifacts such that each artifact in one level links to other artifacts is constructed, which helps to locate a pieces of design, code and test cases that need to be maintained. 2. Dependency (or source-code) analysis Dependency analysis attempt to assess the affects of change on semantic dependencies between program entities. This is achieved by identifying the syntactic dependencies that may signal the presence of such semantic dependencies. • The two dependency-based impact analysis techniques are: call graph based analysis and dependency graph based analysis.
- 19. Additional Impact analysis techniques 3. Ripple effect analysis measures the impact, or how likely it is that a change to a particular module may cause problems in the rest of the program. 4. Change propagation activity ensures that a change made in one component is propagated properly throughout the entire system.
- 20. Refactoring • Refactoring “is the process of making a change to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior”. • It is the object-oriented equivalent of restructuring. • Refactoring, which aims to improve the internal structure of the code, achieve through the removal of duplicate code, simplification, making code easier to understand, help to find defects and adding flexibility to program faster.
- 21. Program Comprehension “the task of building mental models of an underlying software system at various abstraction levels, ranging from models of the code itself to ones of the underlying application domain, for software maintenance, evolution and re-engineering purposes.”
- 22. Program Comprehension • Several strategies can be used to arrive at relevant hypotheses such as: • Bottom up (starting from the code). • Top down (starting from high-level goal). • Opportunistic combinations of the two. • A strategy is formulated by identifying actions to achieve a goal. • Strategies guide two mechanisms, namely chunking and cross-referencing to produce higher-level abstraction structures. • Chunking creates new, higher level abstraction structures from lower level structures. • Cross-referencing means being able to make links elements of different abstraction levels.
- 23. Software Reuse “The development of an industry of reusable source-code software components and the industrialization of the production of application software from off-the-shelf components.”
- 24. Software Reuse • Reuse developments includes: • Program families. • Domain analysis. • Program families are sets of programs whose common properties are so extensive that it becomes advantageous to study the common properties of these programs before analyzing individual differences. • Domain analysis is an activity of identifying objects and operations of a class of similar systems in a particular problem domain
- 25. Four types of reusable artifacts: 1. Data reuse, involving a standardization of data formats. 2. Architectural reuse, which consists of standardizing a set of design and programming conventions dealing with the logical organization of software. 3. Design reuse, for some common business applications. 4. Program reuse, which deals with reusing executable code.
- 26. Characteristics of software component to be reusable • Environmental independence - The components can be reused irrespective of the environment from which they were originally captured. • High cohesion - The components that implement a single operation or set of related operations. • Loose coupling - The components that have minimal links to other components. • Adaptability - The components that are adaptable so they can be customized to fit a range of similar situation. • Understandability - The components which are easily understandable that users can quickly interpret functionality. • Reliability - The components that are error-free. • Portability - The components that are not restricted in terms of the software or hardware environment they operate in.
- 27. Benefits of Reuse 1. Increased reliability. 2. Reduced process risk. 3. Increase productivity. 4. Standards compliance. 5. Accelerated development. 6. Improve maintainability. 7. Reduction in maintenance time and effort.
- 28. Thank you …
- 29. Speaker Information Moutasm tamimi Masters of Software Engineering Independent Consultant , IT Researcher. CEO at ITG7.com , IT-CRG.com Email: tamimi@itg7.com Click Here Click HereI T G 7 Click Here Click HereIT-CRG
- 30. Better Software design pattern practices