UNIT-1

SOFTWARE PROCESS AND AGILE DEVELOPMENT

Introduction to Software Engineering - Definitions of Software EngineeringThe Serial or
Linear Sequential Development Model – Iterative Development Model- The incremental
Development Model- The Parallel or Concurrent Development Model- Software Process,
Perspective and Specialized Process Models – Introduction to Agility- Agile process-
Extreme programming- XP Process - Introduction and Evolving Role of Software- Software
Characteristics - Software Applications.

1.1 INTRODUCTION
1.1.1 Software
Computer programs and associated documentation

Software is
(1) instructions (computer programs) that when executed provide desired features, function
and performance,
(2) data structures that enable the programs to adequately manipulate information,
(3) descriptive information in both hard copy and virtual forms that describes the operation
and use of the programs

Software takes on a dual role. It is a product, and at the same time, the vehicle for delivering
a product.

Software products may be

Generic - developed to be sold to a range of different customers
• E.g. Database, word processor, drawing packages and project management tools
Bespoke (custom) - developed for a single customer according to their specification
• E.g. Control systems for electronic devices, air traffic control systems

Software Characteristics
Software is a logical rather than a physical system element.

1. Software is developed or engineered; it is not manufactured in the classical sense.

Software development and hardware manufacturing-the two activities are
fundamentally different.
In both activities, high quality is achieved through good design, but the manufacturing
phase for hardware can introduce quality problems that are nonexistent (or easily corrected)
for software.
Software costs are concentrated in engineering. This means that software projects
cannot be managed as if they were manufacturing projects.

2. Software doesn't "wear out."

The figure below shows failure rate as a function of time for hardware. The
relationship, often called the "bathtub curve," indicates that hardware exhibits relatively high
failure rates early in its life (these failures are often attributable to design or manufacturing
defects); defects are corrected and the failure rate drops to a steady-state level (ideally, quite
low) for some period of time.

Software Application Domains

System software
System software is a collection of programs written to service other programs.
e.g., compilers, editors, and file management utilities, operating system components, drivers

Application software
Application software are stand-alone programs that solve a specific business need.
used to control business functions in real time
e.g., point-of-sale transaction processing, real-time manufacturing process control

Engineering and scientific software

Engineering and scientific software have been characterized by "number crunching"
algorithms.
e.g., Computer-aided design, system simulation, and other interactive applications

Embedded software
Embedded software resides in within a product or system and is used to control products and
systems for the consumer and industrial markets.
e.g., keypad control for a microwave oven, digital functions in an automobile such as fuel
control, dashboard displays, and braking systems
Product-line software
designed to provide a specific capability for use by many different customers.
e.g., inventory control products, word processing, spreadsheets, computer graphics and
personal and business financial applications

Web applications
WebApps are sophisticated computing environments that not only provide stand-alone
features, computing functions, and content to the end user, but also are integrated with
corporate databases and business applications

Artificial intelligence software

Artificial intelligence (AI) software makes use of non-numerical algorithms to solve complex
problems that are not amenable to computation or straightforward analysis.
e.g., robotics, expert systems, pattern recognition (image and voice), artificial neural
networks, theorem proving, and game playing

1.1.2 Software engineering

The application of a systematic, disciplined, quantifiable approach to the development,

operation, and maintenance of software; that is, the application of engineering to software.

An engineering discipline that is concerned with all aspects of software production

The establishment and use of sound engineering principles in order to economically obtain
software that is reliable and works efficiently on real machines

Difference between software engineering and computer science

Computer science is concerned with theory and fundamentals;
Software engineering is concerned with the practicalities of developing and delivering
useful software

Difference between software engineering and system engineering

System engineering is concerned with all aspects of computer-based systems
development including hardware, software and process engineering.
Software engineering is part of this process concerned with developing the software
infrastructure, control, applications and databases in the system

Software Engineering: A Layered Technology

Software engineering is a layered technology.
Any software can be developed using these layered approaches.
Software engineering layers

A Quality focus
The bedrock that supports software engineering is a quality focus.
Total quality management, Six Sigma and similar philosophies foster a continuous
process improvement culture, and this culture ultimately leads to the development of
increasingly more mature approaches to software engineering.

Process
The foundation for software engineering is the process layer.
Software engineering process is the glue that holds the technology layers together and
enables rational and timely development of computer software.
Process defines a framework for a set of key process areas (KPAs) that must be
established for effective delivery of software engineering technology.
The key process areas form the basis for management control of software projects and
establish the context in which technical methods are applied, work products (models,
documents, data, reports, forms, etc.) are produced, milestones are established, quality is
ensured, and change is properly managed.

Methods
Methods provide the technical how-to's for building software.
Methods encompass a broad array of tasks that include requirements analysis, design,
program construction, testing, and support.
Software engineering methods rely on a set of basic principles that govern each area of
the technology and include modeling activities and other descriptive techniques.

Tool
Tools provide automated or semi-automated support for the process and the methods.
When tools are integrated so that information created by one tool can be used by another,
a system for the support of software development, called computer-aided software
engineering is established.
 1.2 SOFTWARE PROCESS

Software Process
It is a is a collection of activities, actions, and tasks that are performed when some work
product is to be created.
An activity strives to achieve a broad objective (e.g., communication with stakeholders)
and is applied regardless of the application domain, size of the project, complexity of the
effort, or degree of rigor with which software engineering is to be applied.
An action encompasses a set of tasks that produce a major work product.
A task focuses on a small, but well-defined objective (e.g., conducting a unit test) that
produces a tangible outcome.

A Generic Process Model

A process framework establishes the foundation for a complete software engineering
process by identifying a small number of framework activities that are applicable to all
software projects, regardless of their size or complexity.

In addition, the process framework encompasses a set of umbrella activities that are
applicable across the entire software process.
A generic process framework for software engineering defines five framework activities

1. Communication
This framework activity involves heavy communication and collaboration with the
customer and other stakeholders
It encompasses requirements gathering and other related activities that help define
software features and functions.
2. Planning
This activity establishes a plan for the software engineering work.
It describes the technical tasks to be conducted, the risks that are likely, the resources that
will be required, the work products to be produced, and a work schedule.
3. Modeling
This activity encompasses the creation of models that allow the developer and the
customer to better understand software requirements and the design that will achieve those
requirements.
1. Analysis
2. Design
4. Construction
This activity combines code generation (either manual or automated) and testing, i.e.,
required to uncover errors in the code.
5. Deployment
The software (as a complete entity or as a partially completed increment) is delivered to
the customer who evaluates the delivered product and provides feedback based on the
evaluation.

Software engineering process framework activities are complemented by a number of

umbrella activities. In general, umbrella activities are applied throughout a software project
and help a software team manage and control progress, quality, change, and risk.
Typical umbrella activities include:
Software project tracking and control—allows the software team to assess progress
against the project plan and take any necessary action to maintain the schedule.
Risk management—assesses risks that may affect the outcome of the project or the
quality of the product.
Software quality assurance—defines and conducts the activities required to ensure
software quality.
Technical reviews—assesses software engineering work products in an effort to uncover
and remove errors before they are propagated to the next activity.
Measurement—defines and collects process, project, and product measures that assist the
team in delivering software that meets stakeholders’ needs; can be used in conjunction with
all other framework and umbrella activities.
Software configuration management—manages the effects of change throughout the
software process.
Reusability management—defines criteria for work product reuse (including software
components) and establishes mechanisms to achieve reusable components.
Work product preparation and production—encompasses the activities required to
create work products such as models, documents, logs, forms, and lists

Process Flow
Linear process flow executes each of the five activities in sequence.
An iterative process flow repeats one or more of the activities before proceeding to the
next.
An evolutionary process flow executes the activities in a circular manner. Each circuit
through the five activities leads to a more complete version of the software.
A parallel process flow executes one or more activities in parallel with other activities
(modeling for one aspect of the software in parallel with construction of another aspect of the
software)
 1.3 PRESCRIPTIVE PROCESS MODELS
Prescriptive Process Models
It prescribes a set of process elements—framework activities, software engineering
actions, tasks, work products, quality assurance, and change control mechanisms for each
project.
Each process model also prescribes a process flow (also called a work flow)—that is, the
manner in which the process elements are interrelated to one another
The software process model is also known as software development life cycle (SDLC)
model
Various Perspective models are

Waterfall Model
Incremental Process Models
Incremental Model
RAD Model
Evolutionary Process Models
Prototyping
The Spiral Model
Concurrent Models

1.3.1 Waterfall Model

Also called as the classic life cycle or the linear sequential model
The linear sequential model is the oldest and the most widely used paradigm for software
engineering.
It suggests a systematic, sequential approach to software development that begins with
customer specification of requirements and progresses through analysis, design, coding,
testing, and support.
When requirements are well defined and reasonably stable, it leads to a linear fashion.

Communication
This is the first phase of waterfall model which includes a meeting with the customer to
understand his requirements.
The information domains, function, behavioral requirements of the system are
understood.
Requirement gathering and Analysis phase the basic requirements of the system must be
understood by software engineer.
Planning
This activity establishes a plan for the software engineering work that follows.
It describes the technical tasks to be conducted, the risks that are likely.

(a) the resources that will be required

(b) the work products to be produced
(c) work schedule
Modeling
This activity encompasses the creation of models that allow the developer and the
customer to better understand software requirements and the design.
The generic process framework, the modeling activity is composed of two software
engineering actions
• Analysis
• Design
Software design is actually a multistep process that focuses on four distinct attributes of a
program: data structure, software architecture, interface representations, and procedural
(algorithmic) detail. The design process translates requirements into a representation of the
software that can be assessed for quality before coding begins.

Construction
The design must be translated into a machine-readable form.
The code generation step performs this task.
Once code has been generated, program testing begins.
The testing process focuses on the logical internals of the software, ensuring that all
statements have been tested, and
On the functional externals; that is, conducting tests to uncover errors and ensure that
defined input will produce actual results that agree with required results.

Deployment
The software is delivered to the customer who evaluates the delivered product and
provides feedback based on the evaluation.
Software will undoubtedly undergo change after it is delivered to the customer.
Change will occur because errors have been encountered, because the software must be
adapted to accommodate changes in its external environment (e.g., a change required because
of a new operating system or peripheral device), or because the customer requires functional
or performance enhancements.
Software support/maintenance reapplies each of the preceding phases to an existing
program.

When to use the Waterfall Model

Requirements are very well known
Product definition is stable
Technology is understood
New version of an existing product
Porting an existing product to a new platform.
Waterfall Model Disadvantages
Real projects rarely follow the sequential flow that the model proposes.
Although the linear model can accommodate iteration, it does so indirectly. As a result,
changes can cause confusion as the project team proceeds.
The linear sequential model requires the customer to state all requirements explicitly.
A working version of the program(s) will not be available until late in the project time-
span. A major blunder, if undetected until the working program is reviewed, can be
disastrous.

The linear nature of the classic life cycle leads to “blocking states” in which some project
team members must wait for other members of the team to complete dependent tasks.
The project requires the fulfillment of one phase, before proceeding to the next.
Waterfall Model Advantages
Easy to understand, easy to use
Provides structure to inexperienced staff
Milestones are well understood
Sets requirements stability
Good for management control (plan, staff, track)
Works well when quality is more important than cost or schedule

1.3.2 Incremental Process Models

1.3.2.1 The Incremental model
The incremental model combines elements of linear and parallel process flows
Each linear sequence produces deliverable “increments” of the software
The first increment is often a core product (basic requirements are addressed but
supplementary features remain undelivered)
The core product is used by the customer (or undergoes detailed evaluation)
Based on evaluation results, a plan is developed for the next increment
The process is repeated following the delivery of each increment, until the complete
product is produced.
The incremental process model, like prototyping and other evolutionary approaches, is
iterative in nature
But unlike prototyping, the incremental model focuses on the delivery of an operational
product with each increment
E.g. Word processing software incremental method developed as follows:
Basic file management, editing and document production functions in the first increment.
More sophisticated editing and document production capabilities in the second increment.
Spelling and grammar checking in the third increment.
Advanced page layout capability in the fourth increment.

When to use the Incremental Model

Risk, funding, schedule, program complexity, or need for early realization of benefits.
Most of the requirements are known up-front but are expected to evolve over time
A need to get basic functionality to the market early
On projects which have lengthy development schedules
On a project with new technology

Incremental Model advantages

Particularly useful when staffing is unavailable
Increments can be planned to manage technical risks
Each release delivers an operational product
Customers get important functionality early
Risk of changing requirements is reduced

Incremental Model disadvantages

Requires good planning and design
Well-defined module interfaces are required
Total cost of the complete system is high

1.3.2.2 The RAD Model

Rapid Application Development is a incremental model that emphasizes a short
development cycle
A “high speed” adaptation of the waterfall model
Uses a component-based construction approach
May deliver software within a very short time period (e.g. ,60 to 90 days) if requirements
are well understood and project scope is constrained
The application should be modularized and addressed by separate RAD teams
Integration is required

Various phases of RAD model are

Communication
To understand the business problem and the information characteristics that the software
must accommodate.
Planning
Planning is essential because multiple software teams work in parallel on different system
functions.
Modeling
Modeling encompasses three major phases and establishes design representations that serve
as the basis for RAD's construction activity.
Business modeling
The information flow among business functions is modeled in a way that answers the
following questions: What information drives the business process? What information is
generated? Who generates it? Where does the information go? Who processes it?
Data modeling
The information flow defined as part of the business modeling phase is refined into a set of
data objects that are needed to support the business. The characteristics (called attributes) of
each object are identified and the relationships between these objects defined.
Process modeling
The data objects defined in the data modeling phase are transformed to achieve the
information flow necessary to implement a business function. Processing descriptions are
created for adding, modifying, deleting, or retrieving a data object.
Construction
It emphasizes the use of pre-existing software components and the application of automatic
code generation.
Deployment
Deployment establishes a basis for subsequent iterations if required.
The RAD Model – Drawbacks
For large, but scalable projects, RAD requires sufficient human resources
RAD projects will fail if developers and customers are not committed to the rapid-fire
activities
If a system cannot be properly modularized, building the components necessary for RAD
will be problematic
If high performance is an issue, and performance is to be achieved through tuning the
interfaces to system components, the RAD approach may not work
RAD may not be appropriate when technical risks are high. This occurs when a new
application makes heavy use of new technology or when the new software requires a high
degree of interoperability with existing computer programs.

The RAD Model Advantages

Extremely short development time.
Uses component-based construction and emphasizes reuse and code generation

1.3.3 Evolutionary Process Models

Software, like all complex systems, evolves over a period of time
Business and product requirements often change as development proceeds, making a
straight-line path to an end product is unrealistic
Evolutionary models are iterative
A process model that has been explicitly designed to accommodate a product that evolves
over time

1.3.3.1 The Prototyping Model

Often, a customer defines a set of general objectives for software but does not identify
detailed input, processing, or output requirements. In other cases, the developer may be
unsure of the efficiency of an algorithm, the adaptability of an operating system, or the form
that human/machine interaction should take. In these, and many other situations, a
prototyping paradigm may offer the best approach.
The prototyping paradigm begins with Communication.
Developer and customer meet and define the overall objectives for the software, identify
whatever requirements are known, and outline areas where further definition is mandatory.
A prototyping iteration is planned quickly and modeling in the form of quick design
occurs.
The quick design focuses on a representation of those aspects of the software that will be
visible to the customer/user (e.g.,human interface layout or output display formats).
The quick design leads to the construction of a prototype.
The prototype is evaluated by the customer/user and used to refine requirements for the
software to be developed

Iteration occurs as the prototype is tuned to satisfy the needs of the customer, while at the
same time enabling the developer to better understand what needs to be done.
Ideally, the prototype serves as a mechanism for identifying software requirements.
If a working prototype is built, the developer attempts to use existing program fragments
or applies tools (e.g., report generators, window managers) that enable working programs to
be generated quickly.

Prototyping Disadvantages
Customers may press for immediate delivery of working but inefficient products
The developer often makes implementation compromises in order to get a prototype
working quickly
Iterative process continues forever which cannot be stopped at a particular stage.
Prototyping Advantages
Iterative process facilitating enhancements.
Partial products can be viewed by the customer.
Flexibility of the product.
Customer satisfaction of the product.

1.3.3.2 The Spiral Model

Couples the iterative nature of prototyping with the controlled and systematic aspects of
the waterfall model
It provides the potential for rapid development of increasingly more complete versions of
the software

It is a risk-driven process model generator

It has two main distinguishing features
– Cyclic approach
• Incrementally growing a system’s degree of definition and implementation while decreasing
its degree of risk
– A set of anchor point milestones
• A combination of work products and conditions that are attained along the path of the spiral
Unlike other process models that end when software is delivered, the spiral model can be
adapted to apply throughout the life of the computer s/w
The circuits around the spiral might represent
– Concept development project
– New Product development project
– Product enhancement project
The spiral model demands a direct consideration of technical risks at all stages of the
project
The Spiral Model – Drawbacks
It may be difficult to convince customers (particularly in contract situations) that the
evolutionary approach is controllable.
It demands considerable risk assessment expertise and relies on this expertise for success.
If a major risk is not uncovered and managed, problems will undoubtedly occur.

1.3.3.3 The Concurrent Development Model

Sometimes called concurrent engineering
Can be represented schematically as a series of framework activities, s/w engineering
actions and tasks, and their associated states
Defines a series of events that will trigger transitions from state to state for each of the
s/w engineering activities, actions, or tasks
The activity—modeling —may be in any one of the states noted at any given time.
Similarly, other activities (e.g., communication or construction) can be represented in an
analogous manner. All activities exist concurrently but reside in different states.
For example, early in a project the customer communication activity has completed its
first iteration and exists in the awaiting changes state.
The modeling activity (which existed in the inactive state while initial communication
was completed, now makes a transition into the under development state.
If, however, the customer indicates that changes in requirements must be made, the
modeling activity moves from the under development state into the awaiting changes state.
For example, during early stages of design, an inconsistency in the requirements model is
uncovered. This generates the event analysis model correction, which will trigger the
requirements analysis action from the done state into the awaiting changes state.
The concurrent process model is often used as the paradigm for the development of
client/server applications
It provides an accurate picture of the current state of a project.

1.4 SPECIALIZED PROCESS MODELS

Specialized Process Models
Specialized process models take on many of the characteristics of one or more of the
traditional models
These models tend to be applied when a specialized or narrowly defined software
engineering approach is chosen
Various types are
o Component-Based Development
o Formal Methods Model
o Aspect-Oriented Software Development

1.4.1 Component-Based Development

Commercial off-the-shelf (COTS) software components, developed by vendors who offer
them as products, provide targeted functionality with well-defined interfaces that enable the
component to be integrated into the software that is to be built
It incorporates many of the characteristics of the spiral model.
It is evolutionary in nature demanding an iterative approach to the creation of software.
But, the component-based development model constructs applications from prepackaged
software components.
Modeling and construction activities begin with the identification of candidate
components (either conventional software modules or object-oriented classes or packages of
classes).
The component-based development model incorporates the following steps:

1. Available component-based products are researched and evaluated for the application
domain in question.
2. Component integration issues are considered.
3. A software architecture is designed to accommodate the components.
4. Components are integrated into the architecture.
5. Comprehensive testing is conducted to ensure proper functionality.
The component-based development model leads to software reuse, and reusability
provides software engineers with a number of measurable benefits.
Software engineering team can achieve a reduction in development cycle time as well as
a reduction in project cost

1.4.2 The Formal Methods Model

The formal methods model encompasses a set of activities that leads to formal
mathematical specification of computer software.
Formal methods enable us to specify, develop, and verify a computer-based system by
applying a rigorous, mathematical notation.
When formal methods are used during development, they provide a mechanism for
eliminating many of the problems that are difficult to overcome using other software
engineering paradigms. Ambiguity, incompleteness, and inconsistency can be discovered and
corrected more easily through the application of mathematical analysis.

When formal methods are used during design, they serve as a basis for program
verification and therefore enable to discover and correct errors that might otherwise go
undetected.
Concerns about its applicability
o The development of formal models is currently quite time consuming and expensive.
o Because few software developers have the necessary background to apply formal methods,
extensive training is required.
o It is difficult to use the models as a communication mechanism for technically
unsophisticated customers.
The formal methods approach is mainly used in building safety-critical software (e.g.,
developers of aircraft avionics and medical devices) and among developers that would suffer
severe economic hardship should software errors occur
1.4.3 Aspect-Oriented Software Development
As modern computer-based systems become more sophisticated (and complex), certain
concerns—customer required properties or areas of technical interest—span the entire
architecture.
Some concerns are high-level properties of a system (e.g., security, fault tolerance). Other
concerns affect functions (e.g., the application of business rules), while others are systemic
(e.g., task synchronization or memory management)
When concerns cut across multiple system functions, features, and information, they are
often referred to as crosscutting concerns.
Aspectual requirements define those crosscutting concerns that have an impact across the
software architecture.
Aspect-oriented software development (AOSD), often referred to as aspect-oriented
programming (AOP), is a software engineering paradigm that provides a process and
methodological approach for defining, specifying, designing, and constructing aspects—
“mechanisms beyond subroutines and inheritance for localizing the expression of a
crosscutting concern”
It will adopt characteristics of both evolutionary and concurrent process models.
The evolutionary model is appropriate as aspects are identified and then constructed.
The parallel nature of concurrent development is essential because aspects are engineered
independently of localized software components and aspects have a direct impact on these
components.
It is essential to instantiate asynchronous communication between the software process
activities applied to the engineering and construction of aspects and components

Verification and Validation

Verification refers to the set of activities that ensure that software correctly implements a
specific function.
Validation refers to a set of activities that ensure that the software that has been built is
traceable to customer requirements.
Verification: "Are we building the product right?"
Validation: "Are we building the right product?"

Introduction to Agility

• Agility is ability to move quickly and easily.

• It is a property consisting of quickness, lightness, & ease of movement;
• The ability to create and respond to change in order to profit in a turbulent global
business environment
• The ability to quickly reprioritize use of resources when requirements, technology,
and knowledge shift
• A very fast response to sudden market changes and emerging threats by intensive
customer interaction
• Use of evolutionary, incremental, and iterative delivery to converge on an optimal
customer solution
• Maximizing BUSINESS VALUE with right sized, just- enough, and just-in-time
processes and documentation
What is Agility?
Agile Process
• Agile software process addresses few assumptions
– Difficulty in predicting changes of requirements and customer priorities.
– For many types of software; design and construction are interleaved
(mixed).
– Analysis, design, construction and testing are not as predictable as we
might like.
• An agile process must be adaptable
• Requires customer feedback
Agility Principles

• Highest priority is to satisfy the customer through early & continuous delivery if
software
• Welcome changing requirements
• Deliver working software frequently
• Business people and developers must work together
• Build projects around motivated individuals
• Emphasize face-to-face conversation
• Working software is the measure of progress
• Continuous attention to technical excellence and good design
• Simplicity – the art of maximizing the amount of work done
• The best designs emerge from self-organizing teams
• The team tunes and adjusts its behaviour to become more effective
Agile Process Models

• Extreme Programming (XP)

• Adaptive Software Development (ASD)
• Dynamic Systems Development Method (DSDM)
• Scrum
• Feature Driven Development (FDD)
• Crystal
•
•
•
• A
gi
le

Modelling (AM)
Extreme Programming (XP)
• The most widely used approach to agile software development
• A variant of XP called Industrial XP (IXP) has been proposed to target process for
large organizations
• It uses object oriented approach as its preferred development model
XP Values
• Communication: To achieve effective communication, it emphasized close &
informal (verbal) collaboration between customers and developers
• Simplicity: It restricts developers to design for immediate needs not for future
needs
• Feedback: It is derived from three sources the implemented software, the customer
and other software team members, it uses Unit testing as primary testing
• Courage: It demands courage (discipline), there is often significant pressure to design
for future requirements, XP team must have the discipline (courage) to design for
today
• Respect: XP team respect among members

The XP Process