Software Maintenance Models: Pros and Cons Overview
The quick-fix, iterative enhancement, and reuse maintenance models along with their advantages and disadvantages in software maintenance. Understand the practical approaches to addressing urgent needs and evolving software systems effectively.
Uploaded on Mar 16, 2025 | 0 Views
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
3IT-2024 Maintenance Context Dr. Wurood Albayati Lecture No. 3
Head points Maintenance Process Models: Pros. and Cons. Quick fix Pros and cons Iterative Software Maintenance Life cycle (SMLC)
Quick fix model The quick-fix model is an ad hoc approach to maintaining software. It operates on the principle of fire-fighting: waiting for problems to occur and then quickly fixing them. The primary objective is to identify and address issues as soon as possible. Changes are made at the code level, without much consideration for future implications. Unfortunately, this approach can lead to rapid degradation of the software s overall structure. Advantages: Speed and Cost: It works swiftly and at low cost. Meeting Urgent Needs: Users often require rapid software modifications. Deadline and Resource Constraints: Suitable for projects with tight deadlines and limited resources. Disadvantages: Not for Large Projects: Unsuitable for extensive systems; better suited for smaller programming tasks. Lack of Structured Design: The absence of structured design and development. Short-Term Fixes: Not ideal for long-term error resolution due to rapid software degradation. In summary, the quick-fix model is a practical way to address urgent needs and pressing obstacles in software maintenance. When using the quick-fix model, annotate (mark) changes with code comments and include a change ID. Enter these changes into a maintenance history that details why the change was made, who made it and what specific techniques they used.
Iterative Enhancement Model This model segments the software maintenance process into smaller, more manageable parts. Each iteration builds upon the previous one, adding new features and addressing problems found in earlier stages. It provides an environment where development teams can effectively adjust to changing requirements. Business justification for changes may be ignored, as it primarily involves the software development team rather than business stakeholders
An iterative maintenance approach covers the common development steps of requirements, design, code, and test and verify results. This iterative flow is roughly the same as a complete software project and includes a benefits analysis. Because it does not include business analysis, the iterative model best suits changes made to limited application targets, with little cross- impact on other apps or organizations.
Reuse maintenance model Also called-Component-Based Maintenance Model: This model focuses on managing software maintenance through modular components or building blocks. It emphasizes reusability, scalability, and flexibility by maintaining and updating individual components separately, rather than the entire software system. Similar to the iterative model, the reuse model includes the order to build, and then reuse, software components. These components can work in multiple places or applications. Some organizations equate this model to componentized iteration, but that's an oversimplification; the goal here is to create reusable components, which are then made available to all projects under all maintenance models.
Reuse maintenance model A development (DEV.) team typically introduces the reuse model in the requirements phase, which means the process has a similar structure to that of the iterative model, once requirements for reuse are met. When applying the reuse model, the development team should consider components of the existing application for reuse, and either make modifications to them or add new ones. It's crucial to work within the organization's broader reuse missions with this approach. Dev. teams can easily introduce too much specialization into code and prevent its reuse.
Taute Maintenance Model The Taute Maintenance Model is a straightforward and practical approach used in software maintenance. Introduced by B.J. Taute in 1983, this model represents the software maintenance process as a closed-loop cycle. It consist of Change Request Phase (identification phase): During this phase, the customer submits a request to the maintenance team for a change in the software. The request can fall into one of the following categories: Corrective software maintenance. Adaptive software maintenance. Perfective software maintenance. Preventive software maintenance. The maintenance team assigns a unique identification number to the request.
Estimate Phase (analyse): In this phase, the team estimates the time and effort required to implement the requested change. Impact analysis on the existing system is also conducted to minimize any ripple effects caused by the change. The team identifies change requests for the next scheduled release. Necessary planning documents may be prepared during this phase. Programming Phase (design): The maintenance team modifies the source code to implement the requested change. Relevant documents (such as design documents and manuals) are updated accordingly. The output of this stage is a test version of the source code. Test Phase : The modified source code is thoroughly tested to ensure correct implementation. Regression testing is performed, using existing test cases and potentially designing new ones. Delivery (Documentation Phase) After regression testing, the team updates system and user documents. This step maintains the correlation between the source code and the associated documents.
Release Phase: The modified software product, along with updated documents, is delivered to the customer. Acceptance testing is carried out by system users. Operation Phase: Once acceptance testing is successful, the software is placed into normal operation. If new issues or functionality requirements arise during usage, the customer can initiate another Change request process, and the cycle repeats. Remember, the Taute Maintenance Model provides a structured approach for maintaining software, ensuring that changes are handled efficiently and systematicall
Software Maintenance Capability Maturity Model (SM-CMM) SM-CMM is often associated with software development, its principles can also be applied to software maintenance. SM-CMM provides a structured approach for organizations to assess and improve their software maintenance processes, ultimately leading to higher quality, increased efficiency, and greater customer satisfaction. It is a framework developed by the Software Engineering Institute (SEI) at Carnegie Mellon University to assess and improve the maturity of software development processes.
The Capability Maturity Model (SW- CMM) In the context of software maintenance, the SM-CMM can be used to evaluate and enhance the maturity of an organization's maintenance processes. The model defines five levels of maturity: Level1. Initial: Processes are ad hoc and chaotic. There is little control over maintenance activities, and success largely depends on individual efforts. Level2. Repeatable: Basic project management processes are established, and maintenance activities are carried out in a more structured manner. There is an emphasis on documenting processes and procedures to ensure consistency. Level3. Defined: Maintenance processes are well-defined and documented. Standardized procedures and guidelines are in place, and there is a focus on process improvement and optimization. Level4. Managed: Maintenance processes are monitored and measured using quantitative metrics. Continuous process improvement is emphasized, and deviations from established processes are identified and addressed. Level5. Optimizing: Maintenance processes are continuously refined and optimized to achieve maximum efficiency and effectiveness. There is a culture of innovation and continuous improvement within the organization.
