Continued From.. Software Maintenance Model
Any standard software process model would primarily consist of two types of activities: A set of framework activities, which are always applicable, regardless of the project type, and a set of umbrella activities, which are the non SDLC activities that span across the entire software development life cycle.
At the end of this session, you will be able to:
Define umbrella activities in a software life cycle
Explain the usage and importance of the following umbrella activities:
a) Traceability Matrix-its definition, usage, and relevance in the SDLC
b) Peer Reviews, Forms of reviews, Planning and execution of peer reviews
Umbrella activities span all the stages of the SDLC. They are not specific to any particular life cycle stage.
The umbrella activities in a software development life cycle process include the following:
Software Project Management
Formal Technical Reviews
Software Quality Assurance
Software Configuration Management
Re-usability Management
Risk Management
Measurement and Metrics
Document Preparation and Production
Managing traceability is required to ensure the requirements are carried through properly to design, development, and delivery. The following animation will show the pitfalls of poor traceability.
Now, let us try to understand the concept of traceability and its importance in software development. For example, in an organization, the activities are departmentalized on the basis of the functionality to be served and employees are allocated to each department. A requirement traceability can be defined as a method for tracing each requirement from its point of origin, through each development phase and work product, to the delivered product. Thus, it helps in indicating, for each work product, the requirements this work product satisfies.
When there is absence of traceability: The product gets compromised since the development cannot be prioritized based on the order of criticality of the component, ultimately leading to missed functionality in the delivered software. Project management is compromised due to the lack of visibility of the components of the application being developed and their interconnections causing a major hindrance to continuous planning. Testing is compromised as the coverage is not verified at every stage of the life cycle. It becomes difficult to demonstrate that the product is ready. Finally, maintenance becomes difficult as identification and analysis of the impacted work products and requirements becomes tedious. This ultimately increases the complexity during testing.
Some benefits are that its availability ensures correct implementation of requirements as traceability gives a clear visibility of the interactions among the components within the system. The forward and backward visibility into the system actually helps in estimating the tasks and activities of the project with greater accuracy through a detailed impact analysis for the changes. This leads to effective project management and planning. Since traceability provides a highly visual view of the interrelationships between the various components, it can be used to identify the requirements that have not been covered and hence analyze the gaps between them. Traceability gives a complete idea about the dependencies and relationships of and between components. For any change in requirement that is requested by the customer, it facilitates impact analysis and simplifies the maintenance activities. Finally, traceability also helps to ensure that all the work is against current requirements and that the requirements are completely satisfied.
The roles and responsibilities with respect to the traceability matrix are explained in this page. Project manager ensures all required information is provided as needed, reviews the traceability matrix for completeness. Requirement analyst updates requirements traceability matrix as needed, support analysis as needed. Designer provides mapping of requirements to design products. Developer provides mapping of requirements to development products. Tester provides mapping of requirements to test products.
Attachment 723
This page details the concept of Peer Review in software projects and identifies the importance and need of Peer Reviews. In software development, Peer Review refers to a type of Software Review in which a work product (any software deliverable, design, or document) is examined by its author and/or one or more colleagues of the author, in order to evaluate its technical content and quality. Management representatives should not be involved in conducting a peer review except when included because of specific technical expertise, or when the work product under review is a management-level document. Managers participating in a peer review should not be line managers of any other participants in the review.
Peer Review has to be planned at the start of the project where the PM or PL identifies the artifacts to be reviewed and the Peer Reviewers. The Review schedule of the individual items to be reviewed along with associated reviewer needs to be planned by the PL during the project execution. The Peer Review needs to be conducted by the assigned Reviewers.
Attachment 722
In this session, you have learned that:
Umbrella activities span all the stages of the SDLC
The concept of umbrella activities focuses on Requirement Traceability Matrix
Requirement traceability matrix is needed to be maintained by projects to ensure that the requirements are adequately addressed
Not maintaining a requirement traceability matrix results in problems including unsatisfied requirements, problems during delivery and maintenance
Software Peer Review needs to be planned, performed, and logged.
The Software Maintenance Model (Application Value Management) ts3 technology
Continued from.. Implementation And Post Implementation In Software Engineering
Software maintenance is the process of enhancing and optimizing deployed software as well as remedying defects in the software. Here is an example of a constructed house. Due to wear and tear, the delivered house would require continuous maintenance. This would include any of the following:
Quickfixes, such as repairing faulty electricity or plumbing appliances.
Additional requirements to be added with the changing needs, such as adding an extra floor to the house.
Major repairs, which also require in-depth analysis and designing of the solution prior to its execution, such as relaying the air-conditioning for the entire house.
At the end of this session, you will be able to:
Ø Learn about the fundamentals of software maintenance
Ø Study the different stages and activities of the maintenance process
Ø Know the service-level agreements and their relevance
Ø Identify the key issues in software maintenance
Ø Learn about the tool, eTracker
When in operation, defects are uncovered, operating environments change, and new user requirements surface. Software maintenance is defined as the totality of activities required to provide cost-effective support to software. This includes modification of a software product after delivery to correct faults or defects, adapt the product to a modified environment, and incorporate additional features in the application to cater to the new requirements.
Software maintenance can be categorized as:
Corrective maintenance: Is a reactive modification of a software product performed after delivery to correct discovered problems and it is also termed as bugfix.
Adaptive maintenance: Is the modification performed on a software product after delivery to keep a software product usable in a changed or changing environment. It is also termed as enhancement.
Perfective maintenance: Is the modification of a software product after delivery to improve performance or maintainability. It is also called performance tuning.
Preventive maintenance: Is the modification of a software product after delivery to detect and correct latent faults in the software product before they become effective faults. This is also termed as bugfix.
Attachment 718
Here is an example of a house built earlier and which requires maintenance at a future point in time. The maintenance person has to initially plan as to how the contract of maintenance would be executed and which areas would be in the scope of the maintenance. He might exclude the electrical maintenance from the contract and he would decide on the team that would be responsible for maintenance and other business issues. After the contract is signed, the architect responsible for the maintenance studies the building plan in detail, including the plumbing layout. Then, the architect passes on the details to the maintenance team. This stage is for developing an understanding of the existing building. Now, based on the request of the customer the house is maintained over a period of time. As discussed earlier, the maintenance can be of the nature of quick fixes or minor repairs, such as electrical or plumbing repairs, a major change, such as repainting the house and incorporation of additional requirements, such as designing the plumbing system or incorporation of air-conditioning in the house.
When the software is in operation, defects are uncovered, operating environments change, and new user requirements surface. The principal stages of an application maintenance project consist of planning, knowledge transition, and finally the steady state maintenance activities.
You have seen what an application maintenance process involves. Now, you will know about the model followed by the application maintenance process. The application maintenance model consists of planning, knowledge transition, and service steady state. The planning phase primarily involves understanding the need of the customer in terms of what is expected from the maintenance team.
This involves a detailed discussion with the client to identify the requirements and finalizing the contract. The activities in this stage are: Business planning at the organizational level: This includes proposal development, estimating for resources and cost, and defining the escalation mechanism. Maintenance planning at transition level: This includes scope definition and the execution process adaptation. And finally knowledge transfer planning, which involves defining the entire methodology to be adopted during the knowledge transfer phase and a detailed schedule of the KT phase.
For maintaining the existing application developed by another vendor, the maintenance team needs to understand the functionalities and the technical details of the system. Hence, a knowledge transition phase is required prior to the commencement of the maintenance activities. The knowledge transition phase primarily consists of obtaining:
The knowledge about the application, considered for maintenance, from the client. Guided support under the supervision of the client, and finally a plan defined for transitioning the obtained knowledge to the team for future support. Initially, the application identified for maintenance has to be thoroughly studied by the K T team. This includes a detailed understanding about the business processes that the application caters to and the functions served by the application. This also includes understanding of the technical details about the application, the environment in which the application is operating along with the details of interaction with the interfacing systems.
Finally, the application inventory is collected by the K T team for providing support in future. After obtaining an understanding of the entire maintenance scenario, the K T team performs the support activities under the supervision of the client’s team. This helps in getting familiar with the support activities and also in defining a detailed plan for transitioning the knowledge obtained and subsequently transferring the knowledge obtained about the system to the entire maintenance team primarily at the offshore centre. The infrastructure required to perform the support is also built during the stage and a knowledge repository containing the details of the maintenance project is also built to capture the entire information, learning, and mistakes committed during the execution of the project. This helps in easy transitioning of resources down the project timelines.
The steady state support involves resolving the service requests sent by the client, optimizing the processes continuously over time. This involves measuring and analyzing the metrics to identify the weaknesses in the process as well as the application being maintained and defining the corrective measures to eradicate the weaknesses. Finally, offering the client value additions identified and obtained over the maintenance period. This includes proactive root-cause analysis of the recurring problems and the necessary measures for improvement. SLA-based measurement also helps in tracking the performance strictly on a defined interval at every level.
The steady state requests can be classified based on the type of request or the level of support and the size of the request. The requests can be of the following types:
FIRST LEVEL-Production support, SECOND LEVEL-Bugfix and THIRD LEVEL-Enhancements
Similarly the bugfix and the enhancements are further classified into Minor, Major, and Super major, based on their size.
Software maintenance sustains the software product throughout its operational life cycle. Modification requests are logged and tracked, the impact of proposed changes is determined, code and other software artifacts are modified, testing is conducted, and a new version of the software product is released. It also includes training and daily support through: helpdesks that are provided to users, or any documentation regarding the application. The enhancement bugfix request, popularly called the EBR, primarily consists of the enhancement or bug description, technical details, the proposed resolution for incorporating the request, and the results of testing done after the change.
Attachment 719
The set of activities performed for software maintenance in the steady state can be sequentially classified into:
Modification request, Classification and Identification, Analysis, Design, Implementation of the change in the necessary places, System Testing, Acceptance Testing, and Delivery.
Based on the size, type, and complexity of the request, one or more of these phases are integrated or eliminated from the execution cycle.
Attachment 720
The workflow shown here actually illustrates the functioning of the onsite and offshore team in a typical maintenance scenario, describing the activities performed for the various levels and type of support.
Attachment 721
Here is a description of different measurement areas and the areas where improvement can be identified over a period of time.
Here, you will know the term service-level agreement and will see its importance in the maintenance projects. A service-level agreement is a contractual service commitment that describes the minimum performance criteria a provider promises to meet while delivering a service. This is usually in measurable terms. It typically also sets out the remedial action and any penalties that will take effect if performance falls below the promised standard. It is an essential component of the legal contract between a service consumer and the provider.
Finally, looking into the value additions offered to the client includes implementing an S L A-based management, which keeps a constant eye on the health of the project and gives a measure of the performances. This subsequently leads to the improvement in the areas of productivity, schedule, and finally the cost involved. The root-cause analysis done at intervals helps in identifying the pain areas of the application and hence focuses on correcting them.
Attachment 717
You will now learn about some key issues and challenges faced during application maintenance. The key issues that should be adeptly dealt with for maintaining the software effectively can be classified as:
Technical issues, which includes limited understanding, extent of testing possible, and the maintainability or is it maintenance of code.
Management issues that include staffing and process-related issues.
Cost estimation that adapts the right methodology as parametric or judgmental.
Measures with respect to Analysis, Changeability, Stability, and the Testability of the software.
In this session, you have learned that:
The maintenance process fundamentally includes correction of defects, adaptation to modified environment, and incorporation of additional requirements. They are termed as production support, enhancements, or bug fixes
Maintenance can be categorized into proactive, reactive, correction, and enhancement. The combination of these categories result in what are termed as Preventive Maintenance, Perfective Maintenance, Corrective Maintenance, and Adaptive Maintenance
The three primary stages of maintenance include Planning for transition, Knowledge transition, and Steady state
The classification of requests is based on a combination of their size and type
A service-level agreement is a contractual service commitment that describes the minimum performance criteria a provider promises to meet while delivering a service. This is usually in measurable terms
The key issues that should be adeptly dealt with for maintaining the software effectively can be classified as:
a) Technical issues, which include limited understanding, extent of testing possible, and the maintainability of code
b) Management issues that include staffing and process-related issues
c) Cost Estimation that adapts the right methodology as parametric or judgmental
d) Measures with respect to Analysis, Changeability, Stability and the Testability of the software
Next Article:- Umbrella Activities In Software Engineering
