Software Evolution – Software Engineering

Software Evolution is a term that refers to the process of developing software initially, and then
timely updating it for various reasons.

The software evolution process includes fundamental activities of change analysis, release planning,
system implementation, and releasing a system to customers.

Necessity of Software Evolution

Software evaluation is necessary just because of the following reasons:

1. Change in requirement with time: With time, the organization’s needs and modus Operandi
of working could substantially be changed so in this frequently changing time the
tools(software) that they are using need to change to maximize the performance.

2. Environment change: As the working environment changes the things(tools) that enable us
to work in that environment also changes proportionally same happens in the software
world as the working environment changes then, the organizations require reintroduction of
old software with updated features and functionality to adapt the new environment.

3. Errors and bugs: As the age of the deployed software within an organization increases their
preciseness or impeccability decrease and the efficiency to bear the increasing complexity
workload also continually degrades. So, in that case, it becomes necessary to avoid use of
obsolete and aged software. All such obsolete Pieces of software need to undergo the
evolution process in order to become robust as per the workload complexity of the current
environment.

4. Security risks: Using outdated software within an organization may lead you to at the verge
of various software-based cyberattacks and could expose your confidential data illegally
associated with the software that is in use. So, it becomes necessary to avoid such security
breaches through regular assessment of the security patches/modules are used within the
software. If the software isn’t robust enough to bear the current occurring Cyber attacks so it
must be changed (updated).

5. For having new functionality and features: In order to increase the performance and fast
data processing and other functionalities, an organization need to continuously evolute the
software throughout its life cycle so that stakeholders & clients of the product could work
efficiently.

Software Evolution

Laws used for Software Evolution

1. Law of Continuing Change

This law states that any software system that represents some real-world reality undergoes
continuous change or become progressively less useful in that environment.

2. Law of Increasing Complexity

As an evolving program changes, its structure becomes more complex unless effective efforts are
made to avoid this phenomenon.

3. Law of Conservation of Organization Stability

Over the lifetime of a program, the rate of development of that program is approximately constant
and independent of the resource devoted to system development.

4. Law of Conservation of Familiarity

This law states that during the active lifetime of the program, changes made in the successive release
are almost constant.

Software Myths:

Most, experienced experts have seen myths or superstitions (false beliefs or interpretations) or
misleading attitudes (naked users) which creates major problems for management and technical
people. The types of software-related myths are listed below.

`Types of Software Myths

(i) Management Myths:

Myth 1:

We have all the standards and procedures available for software development.

Fact:

 Software experts do not know all the requirements for the software development.

 And all existing processes are incomplete as new software development is based on new and
different problem.

Myth 2:

The addition of the latest hardware programs will improve the software development.

Fact:

 The role of the latest hardware is not very high on standard software development; instead
(CASE) Engineering tools help the computer, they are more important than hardware to
produce quality and productivity.
  Hence, the hardware resources are misused.

Myth 3:

 With the addition of more people and program planners to Software development can help
meet project deadlines (If lagging behind).

Fact:

 If software is late, adding more people will merely make the problem worse. This is because
the people already working on the project now need to spend time educating the
newcomers, and are thus taken away from their work. The newcomers are also far less
productive than the existing software engineers, and so the work put into training them to
work on the software does not immediately meet with an appropriate reduction in work.

(ii)Customer Myths:

The customer can be the direct users of the software, the technical team, marketing / sales
department, or other company. Customer has myths leading to false expectations (customer) &
that’s why you create dissatisfaction with the developer.

Myth 1:

A general statement of intent is enough to start writing plans (software development) and details of
objectives can be done over time.

Fact:

 Official and detailed description of the database function, ethical performance,

communication, structural issues and the verification process are important.

 Unambiguous requirements (usually derived iteratively) are developed only through effective
and continuous
communication between customer and developer.

Myth 2:

Software requirements continually change, but change can be easily accommodated because
software is flexible

Fact:

 It is true that software requirements change, but the impact of change varies with the time
at which it is introduced. When requirements changes are requested early (before design or
code has been started), the cost impact is relatively small. However, as time passes, the cost
impact grows rapidly—resources have been committed, a design framework has been
established, and change can cause upheaval that requires additional resources and major
design modification.
Different Stages of Myths

(iii)Practitioner’s Myths:

Myths 1:

They believe that their work has been completed with the writing of the plan.

Fact:

 It is true that every 60-80% effort goes into the maintenance phase (as of the latter software
release). Efforts are required, where the product is available first delivered to customers.

Myths 2:

There is no other way to achieve system quality, until it is “running”.

Fact:

 Systematic review of project technology is the quality of effective software verification

method. These updates are quality filters and more accessible than test.

Myth 3:

An operating system is the only product that can be successfully exported project.

Fact:

 A working system is not enough, the right document brochures and booklets are also
required to provide guidance & software support.

Myth 4:

Engineering software will enable us to build powerful and unnecessary document & always delay us.

Fact:

 Software engineering is not about creating documents. It is about creating a quality product.
Better quality leads to reduced rework. And reduced rework results in faster delivery times

Layered Technology in Software Engineering

Software engineering is a fully layered technology, to develop software we need to go from one layer
to another. All the layers are connected and each layer demands the fulfillment of the previous layer.
Layered technology is divided into four parts:

1. A quality focus: It defines the continuous process improvement principles of software. It provides
integrity that means providing security to the software so that data can be accessed by only an
authorized person, no outsider can access the data. It also focuses on maintainability and usability.

2. Process: It is the foundation or base layer of software engineering. It is key that binds all the layers
together which enables the development of software before the deadline or on time. Process
defines a framework that must be established for the effective delivery of software engineering
technology. The software process covers all the activities, actions, and tasks required to be carried
out for software development.

Process activities are listed below:-

 Communication: It is the first and foremost thing for the development of software.
Communication is necessary to know the actual demand of the client.

 Planning: It basically means drawing a map for reduced the complication of development.

 Modeling: In this process, a model is created according to the client for better
understanding.

 Construction: It includes the coding and testing of the problem.

 Deployment:- It includes the delivery of software to the client for evaluation and feedback.

3. Method: During the process of software development the answers to all “how-to-do” questions
are given by method. It has the information of all the tasks which includes communication,
requirement analysis, design modeling, program construction, testing, and support.

4. Tools: Software engineering tools provide a self-operating system for processes and methods.
Tools are integrated which means information created by one tool can be used by another.
Measurement & Metrics: This will include all the measurement of every aspects of the software project.

Risk Management: Risk management is a series of steps that help a software team to understand and manage
uncertainty. It’s a really good idea to identify it, assess its probability of occurrence, estimate its impact, and
establish a contingency plan that─ ‘should the problem actually occur’
Capability Maturity Model Integration (CMMI)

The Capability Maturity Model Integration (CMMI) is an advanced framework designed to improve and
integrate processes across various disciplines such as software engineering, systems engineering, and people
management. It builds on the principles of the original CMM, enabling organizations to enhance their
processes systematically. CMMI helps organizations fulfill customer needs, create value for investors, and
improve product quality and market growth. It offers two representations, staged and continuous, to guide
organizations in their process improvement efforts.

What is Capability Maturity Model Integration (CMMI)?

Capability Maturity Model Integration (CMMI) is a successor of CMM and is a more evolved model that
incorporates best components of individual disciplines of CMM like Software CMM, Systems Engineering CMM,
People CMM, etc. Since CMM is a reference model of matured practices in a specific discipline, so it becomes
difficult to integrate these disciplines as per the requirements. This is why CMMI is used as it allows the
integration of multiple disciplines as and when needed.

Objectives of CMMI

1. Fulfilling customer needs and expectations.

2. Value creation for investors/stockholders.

3. Market growth is increased.

4. Improved quality of products and services.

5. Enhanced reputation in Industry.

CMMI Representation – Staged and Continuous

A representation allows an organization to pursue a different set of improvement objectives. There are two
representations for CMMI :

 Staged Representation :

o uses a pre-defined set of process areas to define improvement path.

o provides a sequence of improvements, where each part in the sequence serves as a

foundation for the next.

o an improved path is defined by maturity level.

o maturity level describes the maturity of processes in organization.

o Staged CMMI representation allows comparison between different organizations for multiple
maturity levels.

 Continuous Representation :

o allows selection of specific process areas.

o uses capability levels that measures improvement of an individual process area.

o Continuous CMMI representation allows comparison between different organizations on a

process-area-by-process-area basis.

o allows organizations to select processes which require more improvement.

o In this representation, order of improvement of various processes can be selected which

allows the organizations to meet their objectives and eliminate risks.
CMMI Model – Maturity Levels

In CMMI with staged representation, there are five maturity levels described as follows :

1. Maturity level 1 : Initial

 processes are poorly managed or controlled.

 unpredictable outcomes of processes involved.

 ad hoc and chaotic approach used.

 No KPAs (Key Process Areas) defined.

 Lowest quality and highest risk.

2. Maturity level 2 : Managed

 requirements are managed.

 processes are planned and controlled.

 projects are managed and implemented according to their documented plans.

 This risk involved is lower than Initial level, but still exists.

 Quality is better than Initial level.

3. Maturity level 3 : Defined

 processes are well characterized and described using standards, proper procedures, and
methods, tools, etc.

 Medium quality and medium risk involved.

 Focus is process standardization.

4. Maturity level 4 : Quantitatively managed

 quantitative objectives for process performance and quality are set.

 quantitative objectives are based on customer requirements, organization needs, etc.

 process performance measures are analyzed quantitatively.

 higher quality of processes is achieved.

 lower risk

5. Maturity level 5 : Optimizing

 continuous improvement in processes and their performance.

 improvement has to be both incremental and innovative.

 highest quality of processes.

 lowest risk in processes and their performance.

CMMI Model – Capability Levels

A capability level includes relevant specific and generic practices for a specific process area that can improve
the organization’s processes associated with that process area. For CMMI models with continuous
representation, there are six capability levels as described below :
 1. Capability level 0 : Incomplete

 incomplete process – partially or not performed.

 one or more specific goals of process area are not met.

 No generic goals are specified for this level.

 this capability level is same as maturity level 1.

2. Capability level 1 : Performed

 process performance may not be stable.

 objectives of quality, cost and schedule may not be met.

 a capability level 1 process is expected to perform all specific and generic practices for this
level.

 only a start-step for process improvement.

3. Capability level 2 : Managed

 process is planned, monitored and controlled.

 managing the process by ensuring that objectives are achieved.

 objectives are both model and other including cost, quality, schedule.

 actively managing processing with the help of metrics.

4. Capability level 3 : Defined

 a defined process is managed and meets the organization’s set of guidelines and standards.

 focus is process standardization.

5. Capability level 4 : Quantitatively Managed

 process is controlled using statistical and quantitative techniques.

 process performance and quality is understood in statistical terms and metrics.

 quantitative objectives for process quality and performance are established.

6. Capability level 5 : Optimizing

 focuses on continually improving process performance.

 performance is improved in both ways – incremental and innovation.

 emphasizes on studying the performance results across the organization to ensure that
common causes or issues are identified and fixed.

What is the Agile Methodology?

Agile methodologies are iterative and incremental, which means it's known for breaking a project into smaller
parts and adjusting to changing requirements.

1. They prioritize flexibility, collaboration, and customer satisfaction.

2. Major companies like Facebook, Google, and Amazon use Agile because of its adaptability and
customer-focused approach.
1. Requirement Gathering

 In this stage, the project team identifies and documents the needs and expectations of various
stakeholders, including clients, users, and subject matter experts.

 It involves defining the project's scope, objectives, and requirements.

 Establishing a budget and schedule.

 Creating a project plan and allocating resources.

2. Design

 Developing a high-level system architecture.

 Creating detailed specifications, which include data structures, algorithms, and interfaces.

 Planning for the software's user interface.

3. Development (Coding)

Writing the actual code for the software. Conducting unit testing to verify the functionality of individual
components.

4. Testing

This phase involves several types of testing:

 Integration Testing: Ensuring that different components work together.

 System Testing: Testing the entire system as a whole.

 User Acceptance Testing: Confirming that the software meets user requirements.

 Performance Testing: Assessing the system's speed, scalability, and stability.

5. Deployment

 Deploying the software to a production environment.

 Put the software into the real world where people can use it.

 Make sure it works smoothly in the real world.

 Providing training and support for end-users.

6. Review (Maintenance)

 Addressing and resolving any issues that may arise after deployment.

 Releasing updates and patches to enhance the software and address problems.
Benefits of Agile Methodology

The advantages of the agile model are as follows:

1. Immediate Feedback: It allows immediate feedback, which aids software improvement in the next
increment.

2. Adapts to Changing Requirements: It is a highly adaptable methodology in which rapidly changing

requirements, allowing responsive adjustments.

3. Face-to-Face Communication: Agile methodology encourages effective face-to-face communication.

4. Time-Efficient: It is well-suited for its time-efficient practices, which help in delivering software quickly
and reducing time-to-market.

5. Frequent Changes: It effectively manages and accommodates frequent changes in project

requirements according to stakeholder convenience.

6. Customer Satisfaction: It prioritizes customer satisfaction.

7. Flexibility and Adaptability: Agile methodologies are known for their flexibility and adaptability.

Limitations of Agile Methodology

The disadvantages of the agile model are as follows:

1. Less Documentation: Agile methodologies focus on less documentation; it prioritizes working on

projects rather than paperwork.

2. Challenges in Large Organizations: Busy schedule of clients can make daily meetup and face-to-face
communication difficult.

3. Need for Senior Programmers: It may require experienced programmers to make critical decisions
during the development of software.

4. Limited Scope Control: It has less rigid scope control, which may not be suitable in certain situations.

5. Predictability: Compared to more structured project management methods, it may lack predictability.