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.