Subject Name: Software Engineering

Subject Code: IT-6002

Semester: 6th
Downloaded from be.rgpvnotes.in

UNIT-5
Software Maintenance: -
Software maintenance is widely accepted part of SDLC now a day. It stands for all the modifications and
updating done after the delivery of software product. There are number of reasons, why modifications are

 Market Conditions - Policies, which changes over the time, such as taxation and newly introduced
required, some of them are briefly mentioned below:

 Client Requirements - Over the time, customer may ask for new features or functions in the software.
constraints like, how to maintain bookkeeping, may trigger need for modification.

 Host Modifications - If any of the hardware and/or platform (such as operating system) of the target host

 Organization Changes - If there is any business level change at client end, such as reduction of
changes, software changes are needed to keep adaptability.

organization strength, acquiring another company, organization venturing into new business, need to
modify in the original software may arise.

TYPES OF MAINTENANCE: -
In a software lifetime, type of maintenance may vary based on its nature. It may be just a routine maintenance
tasks as some bug discovered by some user or it may be a large event in itself based on maintenance size or

 Corrective Maintenance - This includes modifications and updating done in order to correct or fix
nature. Following are some types of maintenance based on their characteristics:

 Adaptive Maintenance - This includes modifications and updating applied to keep the software product
problems, which are either discovered by user or concluded by user error reports.

 Perfective Maintenance - This includes modifications and updates done in order to keep the software
up-to date and tuned to the ever-changing world of technology and business environment.

usable over long period of time. It includes new features, new user requirements for refining the software

 Preventive Maintenance - This includes modifications and updating to prevent future problems of the
and improve its reliability and performance.

software. It aims to attend problems, which are not significant at this moment but may cause serious
issues in future.

Software Supportability

 Capability of supporting a software system over its whole product life

It is defined as:-

 Satisfying needs or requirements

 Providing equipment, support, infrastructure, software, facilities, people
 Included defect detection and removal
 Should be considered during the analysis and design process

RE-ENGINEERING
Software re-engineering means re-structuring or re-writing part or all of the software engineering system.
When we need to update the software to keep it to the current market, without impacting its functionality, it
is called software re-engineering. It is a thorough process where the design of software is changed and
programs are re-written.
For example, initially UNIX was developed in assembly language. When language C came into existence, Unix
was re-engineered in C, because working in assembly language was difficult. Other than this, sometimes
programmers notice that few parts of software need more maintenance than others and they also need re-
engineering.

Page no: 1 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

 Decide what to re-engineer. Is it whole software or a part of it?

Business Process Re-Engineering:

 Perform Reverse Engineering, in order to obtain specifications of existing software.

 Restructure Program if required. For example, changing function-oriented programs into object-oriented

 Re-structure data as required.

programs.

 Apply Forward engineering concepts in order to get re-engineered software.

Original Program Modularized Original

Program documenta program data
tion

Reverse
engineering
Program Data
Source code modularization reengineerin
translation g

Program
Structured Reengineered
structure
program data
improvem

Fig 5.1 Reengineering flow

REVERSE ENGINEERING: -
Reverse engineering, in computer programming, is a technique used to analyze software in order to identify
and understand the parts it is composed of. The usual reasons for reverse engineering a piece of software are
to recreate the program, to build something similar to it, to exploit its weaknesses or strengthen its defenses.
It is a process to achieve system specification by thoroughly analyzing, understanding the existing system. This
process can be seen as reverse SDLC model, i.e. we try to get higher abstraction level by analyzing lower
abstraction levels.
An existing system is previously implemented design, about which we know nothing. Designers then do
reverse engineering by looking at the code and try to get the design. With design in hand, they try to conclude
the specifications. Thus, going in reverse from code to system specification.

Restructuring
It is a process to re-structure and re-construct the existing software. It is all about re-arranging the source
code, either in same programming language or from one programming language to a different one.
Restructuring can have either source code-restructuring and data-restructuring or both.
Re-structuring does not impact the functionality of the software but enhance reliability and maintainability.
Program components, which cause errors very frequently can be changed, or updated with re-structuring.
The dependability of software on obsolete hardware platform can be removed via re-structuring.

Forward Engineering
Forward engineering is a process of obtaining desired software from the specifications in hand which were
brought down by means of reverse engineering. It assumes that there was some software engineering
already done in the past.

Page no: 2 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

Forward engineering is same as software engineering process with only one difference – it is carried out
always after reverse engineering.

Fig 5.2 Forward Engineering

Economics of Reengineering
• Cost of maintenance =cost annual of operation and maintenance over application lifetime
• Cost of reengineering = predicted return on investment reduced by cost of implementing changes and
engineering risk factors
• Cost benefit = Cost of reengineering - Cost of maintenance

PROJECT SCHEDULING: -
Project Scheduling in a project refers to roadmap of all activities to be done with specified order and within
time slot allotted to each activity. Project managers tend to define various tasks, and project milestones and
then arrange them keeping various factors in mind. They look for tasks like in critical path in the schedule,
which are necessary to complete in specific manner (because of task interdependency) and strictly within the
time allocated. Arrangement of tasks which lies out of critical path are less likely to impact over all schedule of
the project.
For scheduling a project, it is necessary to –
 Break down the project tasks into smaller, manageable form
 Find out various tasks and correlate them
 Estimate time frame required for each task
 Divide time into work-units
 Assign adequate number of work-units for each task
 Calculate total time required for the project from start to finish

 different ways to track a project:

Tracking the schedule

 each team member periodically reports progress

 evaluate results of reviews
 determine whether formal project milestones have been accomplished by scheduled date
 compare actual start date to planned start date
 get tea e e s assess e t of p og ess to date

Project Management Plan: -

 Software Creation in order to achieve a goal (for example, software development and delivery). A Project
The job pattern of an IT company engaged in software development can be seen split in two parts:

 Project is not a routine activity or day-to-day operation.

can be characterized as: Every project may have a unique and distinct goal.

 Project comes with a start and end time.

 Project ends when its goal is achieved. Hence, it is a temporary phase in the lifetime of an organization.

Page no: 3 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

 Project needs adequate resources in terms of time, manpower, finance, material, and knowledge-bank.

SOFTWARE QUALITY ASSURANCE (SQA) and quality planning: -

Testing vs. Quality Control & Assurance and Audit:
We need to understand that software testing is different from software quality assurance, software quality

 Software quality assurance - These are software development process monitoring means, by which it is
control and software auditing.

assured that all the measures are taken as per the standards of organization. This monitoring is done to make

 Software quality control - This is a system to maintain the quality of software product. It may incl ude
sure that proper software development methods were followed.

functional and non-functional aspects of software product, which enhance the goodwill of the organization.
This system makes sure that the customer is receiving quality product for their requirement and the product
e tified as fit fo use .
 Software audit - This is a review of procedure used by the organization to develop the software. A team of
auditors, independent of development team examines the software process, procedure, requirements and
other aspects of SDLC. The purpose of software audit is to check that software and its development process,
both conform standards, rules and regulations.

SCM activities and plan

SOFTWARE CONFIGURATION MANAGEMENT: -
Configuration management is a process of tracking and controlling the changes in software in terms of the
requirements, design, functions and development of the product.
IEEE defi es it as the p o ess of ide tifyi g a d defi i g the ite s i the syste , controlling the change of
these items throughout their life cycle, recording and reporting the status of items and change requests, and
ve ifyi g the o plete ess a d o e t ess of ite s .
Generally, once the SRS is finalized there is less chance of requirement of changes from user. If they occur, the
changes are addressed only with prior approval of higher management, as there is a possibility of cost and
time overrun.

Baseline:
A phase of SDLC is assumed over if it base lined, i.e. baseline is a measurement that defines completeness of a
phase. A phase is base lined when all activities pertaining to it is finished and well documented. If it was not
the final phase, its output would be used in next immediate phase.
Configuration management is a discipline of organization administration, which takes care of occurrence of
any changes (process, requirement, technological, strategically etc.) after a phase is baseline. CM keeps check
on any changes done in software.

SOFTWARE CHANGE MANAGEMENT AND REPORTING: -

Change control is function of configuration management, which ensures that all changes made to software
system are consistent and made as per organizational rules and regulations.
A change in the configuration of product goes through following steps –
 Identification - A change request arrives from either internal or external source. When change request is

 Validation - Validity of the change request is checked and its handling procedure is confirmed.
identified formally, it is properly documented.

 Analysis - The impact of change request is analyzed in terms of schedule, cost and required efforts. Overall

 Control - If the prospective change either impacts too many entities in the system or it is unavoidable, it is
impact of the prospective change on system is analyzed.

mandatory to take approval of high authorities before change is incorporated into the system. It is decided if

Page no: 4 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

 Execution - If the previous phase determines to execute the change request, this phase takes appropriate
the change is worth incorporation or not. If it is not, change request is refused formally.

 Close request - The change is verified for correct implementation and merging with the rest of the system.
actions to execute the change, through a thorough revision if necessary.

This newly incorporated change in the software is documented properly and the request is formally closed.

Capability Maturity Model (CMM): -

The Software Engineering Institute (SEI) has developed a comprehensive model predicated on a set of
software engineering capabilities that should be present as organizations reach different levels of process
atu ity. To dete i e a o ga izatio s u e t state of p o ess atu ity, the
SEI uses an assessment that results in a five-point grading scheme. The grading scheme determines
compliance with a capability maturity model (CMM) that defines key activities required at different levels of
process maturity. The SEI approach provides a measure of the global effectiveness of a company's software
engineering practices and establishes five process maturity levels that are defined in Fig:-1.9:
Level 1: Initial. The software process is characterized as ad hoc and occasionally even chaotic. Few processes
are defined, and success depends on individual effort.
Level 2: Repeatable. Basic project management processes are established to track cost, schedule, and
functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar
applications.

Fig 5.3- Capability Maturity Model

Level 3: Defined. The software process for both management and engineering activities is documented,
standardized, and integrated into an organization wide software process. All projects use a documented and
approved version of the organization's process for developing and supporting software. This level includes all
characteristics defined for level 2.

Page no: 5 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

Level 4: Managed. Detailed measures of the software process and product quality are collected. Both the
software process and products are quantitatively understood and controlled using detailed measures. This
level includes all characteristics defined for level 3.
Level 5: Optimizing. Continuous process improvement is enabled by quantitative feedback from the process
and from testing innovative ideas and technologies. This level includes all characteristics defined for level 4.

Software project management standards

Software Project:
A Software Project is the complete procedure of software development from requirement gathering to testing
and maintenance, carried out according to the execution methodologies, in a specified period of time to
achieve intended software product.

Need of software project management:

Software is said to be an intangible product. Software development is a kind of all new stream in world
business and there is very little experience in building software products. Most software products are tailor
ade to fit lie t s e ui e e ts. The ost i po tant is that the underlying technology changes and advances
so frequently and rapidly that the experience of one product may not be applied to the other one. All such
business and environmental constraints bring risk in software development hence it is essential to manage
software projects efficiently.

PROJECT AND PROCESS PLANNING: -

Software project planning is task, which is performed before the production of software actually starts. It is
there for the software production but involves no concrete activity that has any direct connection with the
software production; rather it is a set of multiple processes, which facilitates software production. Project
planning may include the following:
Scope Management:
It defines scope of the project; this includes all the activities, process need to be done in order to make a
deliverable software product. Scope management is essential because it creates boundaries of the project by
clearly defining what would be done in the project and what would not be done. This makes project to contain
limited and quantifiable tasks, which can easily be documented and in turn avoids cost and time overrun.

 Define the scope

During Project Scope management, it is necessary to -

 Decide its verification and control

 Divide the project into various smaller parts for ease of management.
 Verify the scope
 Control the scope by incorporating changes to the scope

RESOURCE ALLOCATIONS: -
All elements used to develop a software product may be assumed as resource for that project. This may
include human resource, productive tools, and software libraries.
The resources are available in limited quantity and stay in the organization as a pool of assets. The shortage of
resources hampers development of the project and it can lag behind the schedule. Allocating extra resources
increases development cost in the end. It is therefore necessary to estimate and allocate adequate resources
for the project.
Resource management includes –
 Defining proper organization project by creating a project team and allocating responsibilities to each team

 Determining resources required at a particular stage and their availability.

member.

Page no: 6 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

 Manage Resources by generating resource request when they are required and de-allocating them when
they are no more needed.

Introduction to component based software engineering

A component is a part of software program code, which executes an independent task in the system. It can
be a small module or sub-system itself.
Example The login procedures used on the web can be considered as components, printing system in
software can be seen as a component of the software.
Components have high cohesion of functionality and lower rate of coupling, i.e. they work independently and
can perform tasks without depending on other modules.
In OOP, the objects are designed are very specific to their concern and have fewer chances to be used in
some other software.
In modular programming, the modules are coded to perform specific tasks which can be used across number
of other software programs.
There is a whole new vertical, which is based on re-use of software component, and is known as Component
Based Software Engineering (CBSE).
Re-use can be done at various levels
Application level - Where an entire application is used as sub-system of new software.
Component level - Where sub-system of an application is used.
Modules level - Where functional modules are re-used.
Software components provide interfaces, which can be used to establish communication among different
components.
Reuse Process
Two kinds of method can be adopted: either by keeping requirements same and adjusting components or by
keeping components same and modifying requirements.

Fig 5.3- Component based software engineering

 Requirement Specification - The functional and non-functional requirements are specified, which a
software product must comply to, with the help of existing system, user input or both.

Page no: 7 Follow us on facebook to get real-time updates from RGPV

Downloaded from be.rgpvnotes.in

 Design - This is also a standard SDLC process step, where requirements are defined in terms of
software parlance. Basic architecture of system as a whole and its sub-systems are created.
 Specify Components - By studying the software design, the designers segregate the entire system into
smaller components or sub-systems. One complete software design turns into a collection of a huge
set of components working together.
 Search Suitable Components - The software component repository is referred by designers to search
for the matching component, on the basis of functionality and intended software requirements..
 Incorporate Components - All matched components are packed together to shape them as complete
software.

Page no: 8 Follow us on facebook to get real-time updates from RGPV

 We hope you find these notes useful.
You can get previous year question papers at
https://qp.rgpvnotes.in .

If you have any queries or you want to submit your

study notes please write us at
rgpvnotes.in@gmail.com