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.
Characteristic of software:
There is some characteristic of software which is given below:
1. Functionality
2. Reliability
3. Usability
4. Efficiency
5. Maintainability
6. Portability
Changing Nature of Software:
Nowadays, seven broad categories of computer software present continuing
challenges for software engineers .which is given below:
1. System Software:
System software is a collection of programs which are written to
service other programs. Some system software processes complex
but determinate, information structures. Other system application
process largely indeterminate data. Sometimes when, the system
software area is characterized by the heavy interaction with
computer hardware that requires scheduling, resource sharing, and
sophisticated process management.
2. 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.

3. Engineering and Scientific Software:

This software is used to facilitate the engineering function and task.
however 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.
4. 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.
 5. 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.
6. 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. However, as 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.
7. Artificial Intelligence Software:
Artificial intelligence software makes use of a nonnumerical
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.

Software Engineering Processes:

A software engineering process is the model chosen for managing the creation of
software from initial customer inception to the release of the finished product.
The chosen process usually involves techniques such as
• Analysis,
• Design,
• Coding,
• Testing and
• Maintenance
Several different process models exist and vary mainly in the frequency,
application and implementation of the above techniques, for example, different
process models use different analysis techniques, other models attempt to
implement the solution to a problem in one big-bang approach, while others adopt
an iterative approach whereby successively larger and more complete versions of
the software are built with each iteration of the process model.

Software Engineering Process

1. Step 1: Understanding Customer Requirements. This step is also known
as the ''requirements collection'' step. ...
2. Step 2: Requirement Analysis: Is the Project Feasible? ...
3. Step 3: Creating a Design. ...
4. Step 4: Coding, Testing, and Installation. ...
5. Step 5: Keeping it Going: Maintenance.

Software engineer Practice: (in Software Development)

A software engineer applies engineering practices to software development, and
typically handles the overall system design of the software application. While
some software engineers also handle programming, these engineers typically
hand off the engineered designs to software programmers for coding. Once the
coding is complete, they test the software and make sure it performs within the
engineered requirements.

Software engineering is divided into several specializations, which focus on a

particular software development area. A few of the most common software
engineering specialties include:

 Requirements engineering looks at the overall requirements of software,

how it fits into the current system, and whether the code from software
programmers meets the necessary requirements. Software quality
management fulfills a similar set of duties, although these software
engineers may only be confirming the software meets someone else's set
of requirements.
  Software engineering process looks at the software development lifecycle
and identifies areas of improvement and optimization. By engineering the
development lifecycle itself, this software engineer ensures the entire
development process runs more efficiently.

 Software design covers one of the most common software engineering

specialities. These engineers define everything from the software's
infrastructure to its interface before programmers start on the code, in
order to create software effective for the environment it's getting
deployed in.

The typical software engineer has many duties and plays an integral part in the
software design and development process:

 Looks at proposed software development projects and determines

whether the guidelines follow sound engineering practices. If they don't,
the engineer addresses any problems and provides an updated project
requirements list.

 Creates documentation for the software design and development of the

project, which allows the programmers to work effectively and any other
engineers working on the project to understand what's going on with the
design.
 Examines business needs to determine whether software can solve
existing problems, fix operational inefficiencies, or otherwise optimize
work processes. When these areas are identified, the software engineer
begins working on a software design document to see whether the
solution is feasible with the resources on hand.
 Software quality assurance and testing sometimes fall in the software
engineering realm, especially if the engineer created the original design
document.

Software engineers create needed efficiency in software development projects,

which ensures the projects fit the needs of the company, stay within the project
scope, and tests developed software to confirm it follows the engineering
practices laid out in the initial design.
Software Myths:
Software myths are misleading attitudes that have caused serious problems for
managers and technical people alike. Software myths propagate misinformation
and confusion. There are three kinds of software myths:

1) Management myths: Managers with software responsibility are often under

pressure to maintain budgets, keep schedules from slipping, and improve
quality. Following are the management myths:
 Myth: We already have a book that’s full of standards and procedures for
building software, won’t that provide my people with everything they need to
know?
Reality: The book of standards may very well exist, but isn’t used. Most
software practitioners aren’t aware of its existence. Also, it doesn’t reflect
modern software engineering practices and is also complete.
 Myth: My people have state-of-the-art software development tools, after all,
we buy them the newest computers.
Reality: It takes much more than the latest model mainframe, workstation, or
PC to do high-quality software development. Computer-aided software
engineering (CASE) tools
are more important than hardware for achieving good quality and productivity,
yet the majority of software developers still do not use them effectively.
 Myth: If we get behind schedule, we can add more programmers and catch up
(sometimes called the Mongolian horde concept).
Reality: Software development is not a mechanistic process like manufacturing.
As new people are added, people who were working must spend time educating
the newcomers, thereby reducing the amount of time spent on productive
development effort. People can be added but only in a planned and well-
coordinated manner.
 Myth: If I decide to outsource the software project to a third party, I can just
relax and let that firm build it.
Reality: If an organization does not understand how to manage and control
software projects internally, it will invariably struggle when it outsources
software projects.
2) Customer myths: Customer myths lead to false expectations (by the
customer) and ultimately, dissatisfaction with the developer. Following are the
customer myths:
 Myth: A general statement of objectives is sufficient to begin writing
programs-we can fill in the details later.
Reality: A poor up-front definition is the major cause of failed software efforts.
A formal and detailed description of the functions, behavior, performance,
interfaces, design constraints, and validation criteria is essential.
 Myth: Project requirements continually change, but change can be easily
accommodated because software is flexible.
Reality: It is true that software requirements change, but the impact of change
varies with the time at which it is introduced. When changes are requested
during software design, the cost impact grows rapidly. Resources have been
committed and a design framework has been established. Change can cause
heavy additional costs. Change, when requested after software is in production,
can be much more expensive than the same change requested earlier.
3) Practitioner’s myths: Practitioners have following myths:
 Myth: Once we write the program and get it to work, our job is done.
Reality: Industry data indicate that between 60 and 80 percent of all effort
expended on software will be expended after it is delivered to the customer for
the first time.
 Myth: Until I get the program “running” I have no way of assessing its
quality.
Reality: One of the most effective software quality assurance mechanisms can
be applied from the inception of a project—the formal technical review.

Software Myths : What is software myth in software engineering.

The development of software requires dedication and understanding on the
developers’ part. Many software problems arise due to myths that are formed
during the initial stages of software development. Unlike ancient folklore that
often provides valuable lessons, software myths propagate false beliefs and
confusion in the minds of management, users and developers.
Managers, who own software development responsibility, are often under strain
and pressure to maintain a software budget, time constraints, improved quality,
and many other considerations. Common management myths are listed in Table.
Table Management Myths
The members of an organization can acquire  Standards are often
all-the information, they require from a incomplete, inadaptable, and
manual, which contains standards, outdated.
procedures, and principles;  Developers are often unaware
of all the established standards.

Developers rarely follow all the known

standards because not all the standards tend
to decrease the delivery time of software
while maintaining its quality.
If the project is behind schedule, increasing  Adding more manpower to the
the number of programmers can reduce the project, which is already
time gap.
 behind schedule, further delays
the project.

New workers take longer to learn about the

project as compared to those already
working on the project.
If the project is outsourced to a third party, Outsourcing software to a third party does
the management can relax and let the other not help the organization, which is
firm develop software for them. incompetent in managing and controlling
the software project internally. The
organization invariably suffers when it out
sources the software project.

In most cases, users tend to believe myths about the software because software
managers and developers do not try to correct the false beliefs. These myths lead to
false expectations and ultimately develop dissatisfaction among the users. Common
user myths are listed in Table.
Table User Myths
Brief requirement stated in the initial  Starting development with
process is enough to start development; incomplete and ambiguous
detailed requirements can be added at requirements often lead to
the later stages. software failure. Instead, a
complete and formal
description of requirements
is essential before starting
development.

Adding requirements at a later stage

often requires repeating the entire
development process.
Software is flexible; hence software Incorporating change requests earlier in
requirement changes can be added the development process costs lesser
during any phase of the development than those that occurs at later stages.
process. This is because incorporating changes
later may require redesigning and extra
resources.

In the early days of software development, programming was viewed as an art, but
now software development has gradually become an engineering discipline.
However, developers still believe in some myths-. Some of the common developer
myths are listed in Table.
 Table Developer Myths
Software development is considered 50% to 70% of all the efforts are
complete when the code is delivered. expended after the software is delivered
to the user.
The success of a software project The quality of programs is not the only
depends on the quality of the product factor that makes the project successful
produced. instead the documentation and software
configuration also playa crucial role.
Software engineering requires Software engineering is about creating
unnecessary documentation, which quality at every level of the software
slows down the project. project. Proper documentation
enhances quality which results in
reducing the amount of rework.
The only product that is delivered after The deliverables of a successful project
the completion of a project is the includes not only the working program
working program(s). but also the documentation to guide the
users for using the software.
Software quality can be assessed only The quality of software can be
after the program is executed. measured during any phase of
development process by applying some
quality assurance mechanism. One
such mechanism is formal technical
review that can be effectively used
during each phase of development to
uncover certain errors.
 Unit 02:
Software Process Structure & Models and Agile Development

What is a Software Process Model?

Software Processes is a clear set of activities for specifying, designing,

implementing and testing software systems.
A software process model is an intellectual representation of a process that
presents a description of a process from some particular perspective. There are
many different software processes but all involve:
 Specification – defining what the system should do;
 Design and implementation – defining the organization of the system and
implementing the system;
 Validation – checking that it does what the customer wants;
 Evolution – changing the system in response to changing customer needs.

Types of Software Process Model

Software processes, methodologies and frameworks range from specific
prescriptive steps that can be used directly by an organization in day-to-day work,
to flexible frameworks that an organization uses to generate a custom set of steps
personalized to the needs of a specific project or group. In some cases a
“guarantor” or “maintenance” organization distributes an official set of
documents that describe the process.
Software Process and Software Development Lifecycle Model
One of the basic notions of the software development process is SDLC
models which stands for Software Development Life Cycle models. There are
many development life cycle models that have been developed in order to achieve
different required objectives. The models specify the various stages of the process
and the order in which they are carried out. The most used, popular and important
SDLC models are given below:
Waterfall model
V model
Incremental model
RAD model
Agile model
Iterative model
Spiral model
Prototype model

Waterfall Model
The waterfall model is a breakdown of project activities into linear sequential
phases, where each phase depends on the deliverables of the previous one and
corresponds to a specialisation of tasks. The approach is typical for certain areas
of engineering design.

V Model
The V-model represents a development process that may be considered an
extension of the waterfall model and is an example of the more general V-model.
Instead of moving down in a linear way, the process steps are bent upwards after
the coding phase, to form the typical V shape. The V-Model demonstrates the
relationships between each phase of the development life cycle and its
associated phase of testing. The horizontal and vertical axes represent time or
project completeness (left-to-right) and level of abstraction (coarsest-grain
abstraction uppermost), respectively.

Incremental model
The incremental build model is a method of software development where the
model is designed, implemented and tested incrementally (a little more is added
each time) until the product is finished. It involves both development and
maintenance. The product is defined as finished when it satisfies all of its
requirements. Each iteration passes through the requirements, design, coding
and testing phases. And each subsequent release of the system adds function
to the previous release until all designed functionally has been implemented.
This model combines the elements of the waterfall model with the iterative
philosophy of prototyping.
Iterative Model
An iterative life cycle model does not attempt to start with a full specification of
requirements by first focusing on an initial, simplified set user features, which
then progressively gains more complexity and a broader set of features until the
targeted system is complete. When adopting the iterative approach, the
philosophy of incremental development will also often be used liberally and
interchangeably.
In other words, the iterative approach begins by specifying and implementing
just part of the software, which can then be reviewed and prioritized in order to
identify further requirements. This iterative process is then repeated by
delivering a new version of the software for each iteration. In a light-weight
iterative project the code may represent the major source of documentation of
the system; however, in a critical iterative project a formal software specification
may also be required.
RAD model
Rapid application development was a response to plan-driven waterfall
processes, developed in the 1970s and 1980s, such as the Structured Systems
Analysis and Design Method (SSADM). Rapid application development (RAD) is
often referred as the adaptive software development. RAD is an incremental
prototyping approach to software development that end users can produce
better feedback when examining a live system, as opposed to working strictly
with documentation. It puts less emphasis on planning and more emphasis on
an adaptive process.
RAD may resulted in a lower level of rejection when the application is placed into
production, but this success most often comes at the expense of a dramatic
overruns in project costs and schedule. RAD approach is especially well suited
for developing software that is driven by user interface requirements. Thus,
some GUI builders are often called rapid application development tools.

Spiral model
The spiral model, first described by Barry Boehm in 1986, is a risk-driven
software development process model which was introduced for dealing with the
shortcomings in the traditional waterfall model. A spiral model looks like a spiral
with many loops. The exact number of loops of the spiral is unknown and can
vary from project to project. This model supports risk handling, and the project
is delivered in loops. Each loop of the spiral is called a Phase of the software
development process.
The initial phase of the spiral model in the early stages of Waterfall Life Cycle
that is needed to develop a software product. The exact number of phases
needed to develop the product can be varied by the project manager depending
upon the project risks. As the project manager dynamically determines the
number of phases, so the project manager has an important role to develop a
product using a spiral model.

Agile model
Agile is an umbrella term for a set of methods and practices based on the values
and principles expressed in the Agile Manifesto that is a way of thinking that
enables teams and businesses to innovate, quickly respond to changing
demand, while mitigating risk. Organizations can be agile using many of the
available frameworks available such as Scrum, Kanban, Lean, Extreme
Programming (XP) and etc.
The Agile movement proposes alternatives to traditional project management.
Agile approaches are typically used in software development to help businesses
respond to unpredictability which refer to a group of software development
methodologies based on iterative development, where requirements and
solutions evolve through collaboration between self-organizing cross-functional
teams.
The primary goal of being Agile is empowered the development team the ability
to create and respond to change in order to succeed in an uncertain and
turbulent environment. Agile software development approach is typically
operated in rapid and small cycles. This results in more frequent incremental
releases with each release building on previous functionality. Thorough testing
is done to ensure that software quality is maintained.
Generic Process Model in Software
Engineering
What is Generic Process Model:
The Generic process model is an abstraction of the software development
process. It specifies the stages and order of a process. Generic Process Model will
define the following:
i. The tasks to be performed.

ii. The input and output of each task.

iii. The pre and post conditions for each task.

iv. The flow and sequence of each task.

Software Process:
It is a set of activities, methods, practices, and transformations that people use to
develop and maintain software and the associated products. As a Software
Organization, the software process becomes better defined and more
consistently implemented throughout the organization.

Example: Project plans, Design-Documents, Code, Test cases, and User-manuals

Generic Process Framework Activities:

It establishes the foundation for a complete software process by identifying a
small number of framework activities. It also includes a set of umbrella activities
that are applicable across the entire software process. Each framework activity is
populated by a set of software engineering actions. A Generic Process Framework
for Software Engineering encompasses five activities.
1. Communication: This framework activity involves heavy communication and
collaboration with the customer. It encompasses requirements gathering and
other related activities.

2. Planning: This activity establishes a plan for the software engineering work that
follows. It describes the technical tasks which are conduct. The resource requires
and the work products are producing with a work schedule.
3. Modeling: It encompasses the creation of models that allow the developer and
the customer. It is easy to better understand Software requirements and the
design that will achieve those requirements.
4. Construction: This activity combines code generation and the testing that is
required to uncover errors in the code.
5. Deployment: The software delivered to the customer who evaluates the
delivered product. It also provides feedback based on the evaluation.

Process Patterns in Software Engineering

As the software team moves through the software process they encounter problems. It
would be very useful if solutions to these problems were readily available so that
problems can be resolved quickly. Process-related problems which are encountered
during software engineering work, it identifies the encountered problem and in which
environment it is found, then it will suggest proven solutions to problem, they all are
described by process pattern. By solving problems a software team can construct a
process that best meets needs of a project.
Uses of the process pattern :

At any level of abstraction, patterns can be defined. They can be used to describe a
problem and solution associated with framework activity in some situations. While in
other situations patterns can be used to describe a problem and solution associated with
a complete process model.

Template :

 Pattern Name –
Meaningful name must be given to a pattern within context of software
process (e.g. Technical Reviews).

 Forces –
The issues that make problem visible and may affect its solution also
environment in which pattern is encountered.
Type :
It is of three types :
1. Stage pattern –
Problems associated with a framework activity for process are described by
stage pattern. Establishing Communication might be an example of a staged
pattern. This pattern would incorporate task pattern Requirements
Gathering and others.
2. Task-pattern –
Problems associated with a software engineering action or work task and
relevant to successful software engineering practice (e.g., Requirements
Gathering is a task pattern) are defined by task-pattern.
3. Phase pattern –
Even when the overall flow of activities is iterative in nature, it defines
sequence of framework activities that occurs within process. Spiral Model
or Prototyping might be an example of a phase pattern.
Initial Context :
Conditions under which the pattern applies are described by initial context. Prior to
the initiation of the pattern :
1. What organizational or term-related activities have already occurred?
2. Entry state for the process?
3. Software engineering information or project information already exists?
For example, the Planning pattern requires that :
 Collaborative communication has been established between customers and
software engineers.
 Successful completion of a number of task patterns for the communication
pattern has occurred.
 The project constraints, basic requirements, and the project scope are
known.
Problem :
Any specific problem is to be solved by pattern.
Solution –
Describes how to implement pattern successfully. This section describes how initial
state of process is modified as a consequence of initiation of pattern.
Resulting Context :
Once the pattern has been successfully implemented, it describes conditions. Upon
completion of pattern :
1. Organizational or term-related activities must have occurred?
2. What should be the exit state for the process?
3. What software engineering information has been developed?
Related pattern :
Provide a list of all process patterns that are directly related to this one. It can be
represented n a hierarchy or in some other diagrammatic form.

Software Process Assessment & Improvement

A software process assessment is a disciplined examination of the software

processes used by an organization, based on a process model. The assessment
includes the identification and characterization of current practices, identifying areas
of strengths and weaknesses, and the ability of current practices to control or avoid
significant causes of poor (software) quality, cost, and schedule.
A software assessment (or audit) can be of three types.
 A self-assessment (first-party assessment) is performed internally by an
organization's own personnel.
 A second-party assessment is performed by an external assessment team
or the organization is assessed by a customer.
 A third-party assessment is performed by an external party or (e.g., a
supplier being assessed by a third party to verify its ability to enter contracts
with a customer).
Software process assessments are performed in an open and collaborative
environment. They are for the use of the organization to improve its software
processes, and the results are confidential to the organization. The organization being
assessed must have members on the assessment team.

Prescriptive Process Model

Prescriptive process model were originally proposed to bring order to the chaos of software
development. Prescriptive process model define a prescribed set of process elements and a
predictable process work flow. “prescriptive” because they prescribe a set of process
elements framework activities, software engineering actions, tasks, work products, quality
assurance, and change control mechanisms for each project.
There are three types of prescriptive process models. They are:

1. The Waterfall Model

2. Incremental Process model
3. RAD model

1. The Waterfall Model

 The waterfall model is also called as 'Linear sequential

model' or 'Classic life cycle model'.
 In this model, each phase is fully completed before the beginning of
the next phase.
 This model is used for the small projects.
 In this model, feedback is taken after each phase to ensure that the
project is on the right path.
 Testing part starts only after the development is complete.

NOTE: The description of the phases of the waterfall model is same as that
of the process model.

An alternative design for 'linear sequential model' is as follows:

Advantages of waterfall model

  The waterfall model is simple and easy to understand, implement, and
use.
 All the requirements are known at the beginning of the project, hence
it is easy to manage.
 It avoids overlapping of phases because each phase is completed at
once.
 This model works for small projects because the requirements are
understood very well.
 This model is preferred for those projects where the quality is more
important as compared to the cost of the project.
Disadvantages of the waterfall model
 This model is not good for complex and object oriented projects.
 It is a poor model for long projects.
 The problems with this model are uncovered, until the software
testing.
 The amount of risk is high.

2. Incremental Process model

 The incremental model combines the elements of waterfall model and

they are applied in an iterative fashion.
 The first increment in this model is generally a core product.
 Each increment builds the product and submits it to the customer for
any suggested modifications.
 The next increment implements on the customer's suggestions and
add additional requirements in the previous increment.
 This process is repeated until the product is finished.
For example, the word-processing software is developed using the
incremental model.
Advantages of incremental model
 This model is flexible because the cost of development is low and
initial product delivery is faster.
 It is easier to test and debug during the smaller iteration.
 The working software generates quickly and early during the software
life cycle.
 The customers can respond to its functionalities after every increment.
Disadvantages of the incremental model
 The cost of the final product may cross the cost estimated initially.
 This model requires a very clear and complete planning.
 The planning of design is required before the whole system is broken
into small increments.
 The demands of customer for the additional functionalities after every
increment causes problem during the system architecture.

3. RAD model

 RAD is a Rapid Application Development model.

 Using the RAD model, software product is developed in a short period
of time.
 The initial activity starts with the communication between customer
and developer.
 Planning depends upon the initial requirements and then the
requirements are divided into groups.
 Planning is more important to work together on different modules.
The RAD model consist of following phases:

1. Business Modeling
 Business modeling consist of the flow of information between various
functions in the project.
 For example what type of information is produced by every function
and which are the functions to handle that information.
 A complete business analysis should be performed to get the essential
business information.
2. Data modeling
 The information in the business modeling phase is refined into the set
of objects and it is essential for the business.
 The attributes of each object are identified and define the relationship
between objects.
3. Process modeling
 The data objects defined in the data modeling phase are changed to
fulfil the information flow to implement the business model.
 The process description is created for adding, modifying, deleting or
retrieving a data object.
4. Application generation
 In the application generation phase, the actual system is built.
 To construct the software the automated tools are used.
5. Testing and turnover
 The prototypes are independently tested after each iteration so that
the overall testing time is reduced.
 The data flow and the interfaces between all the components are are
fully tested. Hence, most of the programming components are already
tested.
Introduction to Agility software engineering:
The meaning of Agile is swift or versatile." Agile process model" refers to a software
development approach based on iterative development. Agile methods break tasks into
smaller iterations, or parts do not directly involve long term planning. The project scope
and requirements are laid down at the beginning of the development process. Plans
regarding the number of iterations, the duration and the scope of each iteration are clearly
defined in advance.

 Agility means effective (rapid and adaptive) response to change, effective

communication among all stockholder.
 Drawing the customer onto team and organizing a team so that it is in control of
work performed. -The Agile process, light-weight methods are People-based rather
than plan-based methods.
 The agile process forces the development team to focus on software itself rather
than design and documentation.
 The agile process believes in iterative method.
 The aim of agile process is to deliver the working model of software quickly to the
customer For example: Extreme programming is the best known of agile process.
Phases of Agile Model:
Following are the phases in the Agile model are as follows:

1. Requirements gathering
2. Design the requirements
3. Construction/ iteration
4. Testing/ Quality assurance
5. Deployment
6. Feedback

1. Requirements gathering: In this phase, you must define the requirements. You
should explain business opportunities and plan the time and effort needed to build
the project. Based on this information, you can evaluate technical and economic
feasibility.

2. Design the requirements: When you have identified the project, work with
stakeholders to define requirements. You can use the user flow diagram or the high-
level UML diagram to show the work of new features and show how it will apply to
your existing system.

3. Construction/ iteration: When the team defines the requirements, the work
begins. Designers and developers start working on their project, which aims to deploy
a working product. The product will undergo various stages of improvement, so it
includes simple, minimal functionality.

4. Testing: In this phase, the Quality Assurance team examines the product's
performance and looks for the bug.

5. Deployment: In this phase, the team issues a product for the user's work
environment.

6. Feedback: After releasing the product, the last step is feedback. In this, the team
receives feedback about the product and works through the feedback.

Agility and Cost of Change in

Software Engineering
May 6, 2021

An agile process reduces the agility and cost of change because software is
released in increments and change can be better controlled within an
increment.

Agility argue that a well designed agile process “flattens” the cost of
change curve shown in following figure, allowing a software team to
accommodate changes late in a software project without dramatic cost and
time impact. When incremental delivery is coupled with other agile
practices such as continuous unit testing and pair programming, the cost
of making a change is attenuated. Although debate about the degree to
which the cost curve flattens is ongoing, there is evidence to suggest that a
significant reduction in the cost of change can be achieved.

Agile Process
Any agile software process is characterized in a manner that addresses a
number of key assumptions about the majority of software projects:

1. It is difficult to predict in advance which software requirements will

persist and which will change. It is equally difficult to predict how
customer priorities will change as the project proceeds.
2. For many types of software, design and construction are interleaved.
That is, both activities should be performed in tandem so that design
models are proven as they are created. It is difficult to predict how
much design is necessary before construction is used to prove the
design.
3. Analysis, design, construction, and testing are not as predictable

Agility Principles
Agility and cost of change principles for those who want to achieve agility:

1. Our highest priority is to satisfy the customer through early and

continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile
processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout
the project.
5. Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the job
done.
 6. The most efficient and effective method of conveying information to
and within a development team is face to face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace
indefinitely.
9. Continuous attention to technical excellence and good design
enhances agility.
10. Simplicity the art of maximizing the amount of work not done
is essential.
11. The best architectures, requirements, and designs emerge from
self organizing teams.
12. At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly.

Extreme Programming

 Extreme programming uses an object-oriented approach as its preferred

development paradigm.
 Extreme programming encompasses a set of rules and practices that occur within
the context of four framework activities: planning, design, coding, and testing.
1. Planning:

 The planning activity begins with the creation of a set of stories that describe
required features and functionality for software to be built.
 Each story is written by the customer and is placed on an index card. The customer
assigns a value to the story based on the overall business value of the feature of
function.
 Members of the XP (Extreme Programming) team then assess each story and assign
a cost – measured in development weeks – to it.
 If the story will require more than three development weeks, the customer is asked
to split the story into smaller stories, and the assignment of value and cost occurs
again.
 Customers and the XP team work together to decide how to group stories into the
next release to be developed by the XP team.
 Once a basic commitment is made for a release, the XP team orders the stories that
will be developed in one of three ways:

1. All stories will be implemented immediately.

2. The stories with highest value will be moved up in the schedule and implemented
first.
3. The riskiest stories will be moved up in the schedule and implemented first.

 As development work proceeds, the customer can add stories, change the value of
an existing story, split stories or eliminate them.
 The XP team then reconsiders all remaining releases and modifies its plan
accordingly.
2. Design :

 XP design follows the KIS (Keep It Simple) principle. A simple design is always
preferred over a more complex representation.
 The design provides implementation guidance for a story as it is written – nothing
less, nothing more.
 XP encourages the use of CRC (Class Responsibility Collaborator) cards as an
effective mechanism for thinking about the software is an object oriented context.
 CRC cards identify and organize the object oriented classes that are relevant to
current software increment.
 The CRC cards are the only design work product produced as a part of XP process.
 If a difficult design is encounter as a part of the design of a story, XP recommends
the immediate creation of that portion of the design called as ‘spike solution’.
 XP encourages refactoring – a construction technique.

3. Coding
  XP recommends that after stories are developed and preliminary design work is
done, the team should not move to cord, but rather develop a series of unit test
that will be exercise each stories.
 Once the unit test has been created, the developer better able to focus on what
must be implemented to pass the unit test.
 Once the code complete, it can be unit tested immediately, thereby providing
instantaneous feedback to the developer.
 A key concept during the coding activity is pair programming. XP recommends that
two people work together at one computer workstation to create code for a story.
This provides a mechanism for real time problem solving and real time quality
assurance.
 As pair programmers complete their work, the code they developed is integrated
with the work of others.
 This continuous integration strategy helps to avoid compatibility and interfacing
problems and provides a smoke testing environment that helps to uncover errors
early.

4. Testing :

 The creation of unit test before coding is the key element of the XP approach.
 The unit tests that are created should be implemented using a framework that
enables them to be automated. This encourages regression testing strategy
whenever code is modified.
 Individual unit tests are organize into a “Universal Testing Suit”, integration and
validation testing of the system can occur on daily basis. This provides the XP team
with a continual indication of progress and also can raise warning flags early if
things are going away.
 XP acceptance test, also called customer test, are specified by the customer and
focus on the overall system feature and functionality that are visible and
reviewable by the customer.

Extreme Programming − A way to handle the common shortcomings

Software Engineering involves −
 Creativity
 Learning and improving through trials and errors
 Iterations
Extreme Programming builds on these activities and coding. It is the detailed (not the
only) design activity with multiple tight feedback loops through effective
implementation, testing and refactoring continuously.
Extreme Programming is based on the following values −
 Communication
 Simplicity
 Feedback
  Courage
 Respect

What is Extreme Programming?

XP is a lightweight, efficient, low-risk, flexible, predictable, scientific, and fun way to
develop a software.
eXtreme Programming (XP) was conceived and developed to address the specific
needs of software development by small teams in the face of vague and changing
requirements.
Extreme Programming is one of the Agile software development methodologies. It
provides values and principles to guide the team behavior. The team is expected to
self-organize. Extreme Programming provides specific core practices where −
 Each practice is simple and self-complete.
 Combination of practices produces more complex and emergent behavior.
Embrace Change
A key assumption of Extreme Programming is that the cost of changing a program
can be held mostly constant over time.
This can be achieved with −
 Emphasis on continuous feedback from the customer
 Short iterations
 Design and redesign
 Coding and testing frequently
 Eliminating defects early, thus reducing costs
 Keeping the customer involved throughout the development
 Delivering working product to the customer

Extreme Programming in a Nutshell

Extreme Programming involves −
 Writing unit tests before programming and keeping all of the tests running at all
times. The unit tests are automated and eliminates defects early, thus reducing
the costs.
 Starting with a simple design just enough to code the features at hand and
redesigning when required.
 Programming in pairs (called pair programming), with two programmers at one
screen, taking turns to use the keyboard. While one of them is at the keyboard,
the other constantly reviews and provides inputs.
 Integrating and testing the whole system several times a day.
  Putting a minimal working system into the production quickly and upgrading it
whenever required.
 Keeping the customer involved all the time and obtaining constant feedback.
Iterating facilitates the accommodating changes as the software evolves with the
changing requirements.

Why is it called “Extreme?”

Extreme Programming takes the effective principles and practices to extreme levels.
 Code reviews are effective as the code is reviewed all the time.
 Testing is effective as there is continuous regression and testing.
 Design is effective as everybody needs to do refactoring daily.
 Integration testing is important as integrate and test several times a day.
 Short iterations are effective as the planning game for release planning and
iteration planning.