The Changing Nature

of Software
Definition: Software engineering is a detailed study of engineering to
• the design,
• development and
• maintenance of software.

• Software engineering was introduced to address the issues of low-quality

software projects.
• Problems arise when a software generally exceeds timelines, budgets,
and reduced levels of quality.
• It ensures that the application is built consistently, correctly, on time and on
budget and within requirements.
• The demand of software engineering also emerged to cater to the
immense rate of change in user requirements and environment on which
application is supposed to be working.
Description: A software product is judged by how easily it can be used by the end-user
and the features it offers to the user. An application must score in the following areas:-

1) Operational: -This tells how good a software works on operations like budget ,
usability, efficiency, correctness ,functionality , dependability , security and safety.

2) Transitional: - Transitional is important when an application is shifted from one

platform to another. So, portability, reusability and adaptability come in this area.

3) Maintenance: - This specifies how good a software works in the changing

environment. Modularity, maintainability, flexibility and scalability come in maintenance
part.
Software Development Lifecycle or SDLC is a series of stages in software engineering to develop proposed
software application, such as:
1) Communication

2) Requirement Gathering

3) Feasibility Study

4) System Analysis

5) Software Design

6) Coding

7) Testing

8) Integration

9) Implementation

10) Operations and maintenance

11) Disposition
Characteristic of software:
There is some characteristic of software which is given below:

• Functionality

• Reliability

• Usability

• Efficiency

• Maintainability

• Portability
• Software engineering generally begins with the first step as a user-request initiation for a
specific task or an output.
• He submits his requirement to a service provider organization.
• The software development team segregates user requirement, system requirement and
functional requirements.
• The requirement is collected by conducting interviews of a user, referring to a database,
studying the existing system etc.
• After requirement gathering, the team analyses if the software can be made to fulfil all
the requirements of the user.
• The developer then decides a roadmap of his plan. System analysis also includes an
understanding of software product limitations.
• As per the requirement and analysis, a software design is made.
• The implementation of software design starts in terms of writing program code in a
suitable programming language.
• Software testing is done while coding by the developers and thorough testing is
conducted by testing experts at various levels of code such as module testing, program
testing, product testing, in-house testing and testing the product at user’s engagement
and feedback.
Changing Nature of Software
 
• The software is instruction or computer program that when executed
provide desired features, function, and performance.
• A data structure that enables the program to adequately manipulate
information and document that describe the operation and use of the
program.
Changing Nature of Software:
Nowadays, seven broad categories of computer software present continuing challenges for
software engineers.

• System Software:
System software is a collection of programs which are written to service other
programs.

• Software processes complex but determinate, information structures.

• Other system application process largely indeterminate data.

• The system software area is characterized by the heavy interaction with computer
hardware that requires scheduling, resource sharing, and sophisticated process
management.
Application Software:
• Application software is defined as programs that solve a specific business need.
• Application in this area process business or technical data in a way that facilitates
business operation or management technical decision making.
• In addition to convention data processing application, application software is
used to control business function in real time.

Engineering and Scientific Software:

• This software is used to facilitate the engineering function and task.
• Modern application within the engineering and scientific area are moving away
from the conventional numerical algorithms.
• Computer-aided design, system simulation, and other interactive applications
have begun to take a real-time and even system software characteristic.
Embedded Software:
• Embedded software resides within the system or product and is
used to implement and control feature and function for the end-user
and for the system itself.
• Embedded software can perform the limited and esoteric function
or provided significant function and control capability.

Product-line Software:
• Designed to provide a specific capability for use by many different
customers, product line software can focus on the limited and
esoteric marketplace or address the mass consumer market.
Web Application:
• It is a client-server computer program which the client runs on the web browser.
• In their simplest form, Web apps can be little more than a set of linked hypertext files
that present information using text and limited graphics.
• E-commerce and B2B application grow in importance.
• Web apps are evolving into a sophisticate computing environment that not only
provides a standalone feature, computing function, and content to the end user.

Artificial Intelligence Software:

• Artificial intelligence software makes use of a non numerical algorithm to solve a
complex problem that is not amenable to computation or straightforward analysis.
• Application within this area includes robotics, expert system, pattern recognition,
artificial neural network, theorem proving and game playing.
 
 Evolution Processes..
• The evolution process: overview

Change Impact System release Change System

requests analysis planning implementa tion release

Perfective Adaptive Corrective

maintenance maintenance maintenance
 .Evolution Processes.
• Change implementation

Proposed Requirements Requirements Software

changes analysis updating development
 ..Evolution Processes
• Emergency repair [Fig. 21.9, SE-8]. Prompted by:
• System faults
• Business changes
• Environmental changes

all requiring urgent treatment

Change Analyze Modify Deliver modified

requests source code source code system
• The dangers of emergency repair:
• Software becomes inconsistent
• Changes are not reflected in documentation
• Software ageing is accelerated by workaround solutions
 Legacy Systems: Introduction..
• Legacy systems: old computer-based systems still in use by
organizations
• Many of them still business critical
• Incorporate many changes made over the years
• Many people have been involved in these changes
• Replacing legacy systems with new systems is risky, yet keeping
them means new changes become more and more expensive
 Legacy Systems: .Introduction.
• Risks of replacing a legacy system:
• Specification is difficult because existing documentation is typically
incomplete
• Changing business processes (now adjusted to the system) may entail
high costs
• Undocumented, yet important business rules may be embedded in the
system; a new system may break these rules
• The new system may be delivered late, may cost more than expected,
and may not function properly
 Legacy Systems: ..Introduction
• Factors that make changes to legacy systems expensive:
• In large systems, different parts were implemented by different
teams, without consistent programming style
• It is difficult to find personnel who knows the obsolete
programming languages used in old systems
• In may cases the only documentation is provided by the source
code; even this may be missing
• It is difficult to understand the system given its ad hoc updating
over the years
• Data used by the system is difficult to understand and manipulate;
it can also be obsolete and/or redundant
 Legacy system assessment…..
• Strategic approaches for dealing with legacy systems:
• Scrap the system completely
• When business practices have changed and no longer depend significantly
on the system (they may be supported by new COTS)
• Continue to maintain the system
• The system works well, is fairly stable, and users do not request many
changes
• Transform the system to improve maintainability
• When system quality was affected negatively by changes, yet changes are
still required
• Replace the system with a new one
• When obsolete hardware precludes further operation or the new system
can be built at reasonable cost
 .Legacy system assessment….
• Assessing legacy systems example
Business value
High business value
Low quality High business value
High quality

9
10 8
6
7

Low business value Low business value

Low quality High quality

2 5
1 3 4

System quality
 ..Legacy system assessment…
• Assessment of legacy systems includes:
(1) Business value assessment
• Viewpoints:
• End-users: look at system’s functionality and performance
• Customers: look at the quality of services provided
• Business managers: assess the usefulness of the system in terms of
business support
• IT managers: are concerned with the availability of technical support
for the system
• Senior managers: interested in system’s contribution to the business
goals
• Major criteria: system usage, business processes supported,
dependability, system outputs
 …Legacy system assessment..
(2) System quality assessment. Look at all components of
the system. Hence:
• Environment assessment. Support software & hardware
platform (maintenance costs, faults, etc. – slide 23)
• Application software assessment. Factors considered as in
slide 24 and quantitative data such as:
• Number of system change requests
• Number of different user interfaces
• Volume of data used by the system
 ….Legacy system assessment.
• Factors in environment assessment
Factor Questions
Supplier Is the supplier is still in existence? Is the supplier financially stable and
stability likely to continue in existence? If the supplier is no longer in business,
are the systems maintained by someone else?
Failure rate Does the hardware have a high rate of reported failures? Does the
support software crash and force system restarts?
Age How old is the hardware and software? The older the hardware and
support software, the more obsolete it will be. It may still function
correctly but there could be significant economic and business benefits
to moving to more modern systems.
Performance Is the performance of the system adequate? Do performance problems
have a significant effect on system users?
Support What local support is required by the hardware and software? If there
requirements are high costs associated with this support, it may be worth considering
system replacement.
Maintenance What are the costs of hardware maintenance and support software
costs licences? Older hardware may have higher maintenance costs than
modern systems. Support software may have high annual licensing
costs.
Interoperability Are there problems interfacing the system to other systems? Can
compilers etc. be used with current versions of the operating system? Is
hardware emulation required?
 …..Legacy system assessment
• Factors in application software assessment

Factor Questions
Understandability How diff icult is it to understand the source code of the current system?
How complex are the control structures which are used? Do variables
have meaningful names that reflect their function?
Documentation What system documentation is available? Is the documentation
complete, consistent and up-to-date?
Data Is there an explicit data model for the system? To what extent is data
duplicated in diff erent files? Is the data used by the system up-to-date
and consistent?
Performance Is the performance of the application adequate? Do performance
problems have a significant effect on system users?
Programming Are modern compilers available for the programming language used to
language develop the system? Is the programming language still used for new
system development?
Configuration Are all versions of all parts of the system managed by a configuration
management management system? Is there an explicit description of the versions of
components that are used in the current system?
Test data Does test data for the system exist? Is there a record of regression tests
carried out when new features have been added to the system?
Personnel skills Are there people available who have the skills to maintain the
application? Are there only a limited number of people who understand
the system?