Chapter 1

Introduction to Software
Engineering and Process
Models

Megha V Gupta, NHITM

What is Software Engineering?

Software Engineering
Software is more than just a Engineering, on the other hand, is all
program code. A program is an about developing products, using
executable code, which serves well-defined, scientific principles and
some computational purpose. methods.
Software is considered to be a
collection of executable
programming code, associated
libraries, and documentation.
Software, when made for a
specific requirement is called a
software product

2
Software is:
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
and
(3) documentation that describes the operation and use of the programs

3
 Software Engineering - Defined
Fritz Bauer, a German computer scientist, defines software
engineering as:
(1969) Software engineering is the establishment and use of sound engineering
principles in order to obtain economically software that is reliable and works
efficiently on real machines

(IEEE) The application of a systematic, disciplined, quantifiable approach to the

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

We can define software engineering as an engineering branch associated with the

development of software product using well-defined scientific principles, methods and
procedures. The outcome of software engineering is an efficient and reliable software
product.
NEED OF SOFTWARE ENGINEERING

Quality
Large software Cost Management
1 3 5

2 4 6

Scalability Dynamic Nature Reduce

Complexity 9
 NEED OF SOFTWAREENGINEERING

The need for software engineering arises because of a higher rate of change in user
requirements and environment in which the software is working.

❖Large software - It is easier to build a wall than a house or building, likewise, as the
size of software becomes large, engineering has to step to give it a scientific process.

❖ Scalability- If the software process were not based on scientific and engineering
concepts, it would be easier to re-create new software than to scale an existing one.

❖Cost- As the hardware industry has shown its skills and huge manufacturing has
lowered the price of computer and electronic hardware. But the cost of the software
remains high if the proper process is not adapted.

6
 NEED OF SOFTWAREENGINEERING
❖Dynamic Nature- The always growing and adapting nature of software
hugely depends upon the environment in which the user works. If the nature of
software is always changing, new enhancements need to be done to the
existing one. This is where software engineering plays a good role.

❖Quality Management- The better process of software development provides

better and quality software products.

❖Reduce Complexity- Big software is always complicated and challenging to

progress. Software engineering has a great solution to reduce the complication of any
project. Software engineering divides big problems into various small issues. And
then start solving each small issue one by one. All these small problems are solved
independently of each other.
CHARACTERISTICS OF A GOOD
SOFTWARE

Operational

Transitional Maintenance

8
 Operational
In operational categories, the factors that decide the software performance in
operations. It can be measured on:

Usability Correctness Dependability Safety

Budget Efficiency Functionality Security

9
Transitional
When the software is moved from one platform to another, the factors deciding
the software quality:

Interoperability Adaptability

Portability Reusability

10
Maintenance
In this category all factors are included that describe how well a software has the
capabilities to maintain itself in the ever-changing environment:

Maintainability Scalability

Modularity Flexibility

11
Software Engineering: A Layered Technology

• Any engineering approach must rest on an organizational commitment to quality.

• The bedrock that supports Software Engineering is a quality focus.
• Quality is the “degree of goodness”. It cant be measured directly. It should have the following
characteristics: Correctness, Maintainability, Integrity, and Usability.
Software Engineering: A Layered Technology
A quality focus:
• It defines the continuous process improvement principles of
software.
• It provides integrity which 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.

Process:
• It is the foundation or base layer of software engineering.
• It is the 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.
Software Engineering: A Layered Technology
Method:
• During the process of software development the answers to all
“how-to-do” questions are given by method.
• It has the information on all the tasks which include
communication, requirement analysis, design modeling, program
construction, testing, and support.

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.
• Provide automated or semi-automated support for the process
and methods (i.e., Computer-aided software engineering CASE
tools)
What is a Process?
(Webster) A system of operations in producing something; a
series of actions, changes, or functions that achieve an end or a
result

(IEEE) A sequence of steps performed for a given purpose

•A process is a collection of activities, actions, and tasks that are performed when some
work product is to be created
• A process is not a rigid prescription for how to build thesoftware rather it is an adaptable
approach that enables the people doing the work to pick and choose the appropriate
set of work actions and tasks
Software Process/ Software Process
Framework
• A Software Engineering process is the model selected for managing the creation of software from
customer initiation to the release of the finished product.

• Software process models can be prescriptive or agile, complex or simple, all-encompassing or

targeted, but in every case, 5 key activities must occur.

• The framework activities are applicable to all projects and all applications domains, and they are a
template for every process model

The framework is a standard way to build and deploy applications.

▪ It is a foundation of the complete software engineering process.
▪ Includes a set of umbrella activities.

16
Process framework
• Each framework activity is populated by a set of
software engineering actions

• Each action is populated with individual work tasks

that accomplish some part of the work implied by the
action.

• Each Software Engineering action is represented by

a number of different task sets, each a collection of
Software Engineering work tasks, related work
products, quality assurance points, and project
milestones.

• The task set that best accommodates the needs of the

project and the characteristics of the team is chosen.
 Generic Process Framework
The following generic process framework is applicable to the vast majority of s/w
projects

18
A generic process framework encompasses five
activities which are given below one by one:

1
2 3

19
A generic process framework encompasses five
activities which are given below one by one:

4
5

20
Umbrella Activities
• The framework described in the generic view of Software Engineering
is complemented by a number of umbrella activities

• Umbrella activities are a set of procedures that the software

engineering team follows to maintain the progress, quality, change
and risks of the overall development tasks.

• These steps of umbrella activities will evolve through the phases of a

generic view of software development.
Umbrella Activities
1. Software Project Tracking and 2. Formal Technical Reviews
Control

3. Software Quality Assurance 4. Software Configuration

Management

5. Document Preparation and 6. Re-usability Management

Production

7. Measurement and Metrics

8. Risk Management
Umbrella Activities
Immature Software Organizations
• Software processes are generally improvised
• If a process is specified, it is not rigorously followed or
enforced
• The software organization is reactionary
• Managers only focus on solving immediate (crisis) problems
• Schedules and budgets are routinely exceeded because they
are not based on realistic estimates
• When hard deadlines are imposed, product functionality and
quality are often compromised
• There is no basis for judging process quality or for solving
product or process problems
• Activities such as reviews and testing are curtailed or
eliminated when projects fall behind schedule
What is CMM?
• CMM: Capability Maturity Model
• Developed in 1987 by the Software Engineering Institute (SEI) at Carnegie-
Mellon University under the sponsorship of DARPA
• A methodology used to develop and refine an organization’s software
development process.
• Describes a 5-level evolutionary improvement path for software
organizations from an Adhoc, immature process to a mature, disciplined one.
• The Capability Maturity Model (CMM) was first defined in 1989 in the book
“Managing Software Processes” by Watts Humphrey.
• It was originally developed by the US Department of Defence to gauge
whether government contractors were able to successfully complete
software projects.
 Capability Maturity Model (CMM) Overview
❑Its core theory is based on the premise that high-quality software can only be produced by
high-quality processes. In theory, this allows developers to repeat their successes and avoid
repeating their failures.

❑Provides guidance on how to gain control of processes for developing and maintaining
software and how to evolve toward a culture of software engineering and management
excellence.

❑This concept of assessing an organization’s maturity on a specific capability can be applied

in any area of a business where processes are required to mature over time.

❑As an organization matures, the software process becomes better defined and more
consistently implemented throughout the organization

❑Software process maturity is the extent to which a specific process is explicitly defined,
managed, measured, controlled, and effective

29
5 Levels of CMM
Stage 1:
During the Initial stage, processes are ad-hoc,
inconsistent, and even chaotic. There are very
few formal processes and success is based upon
individual effort. This is the starting point of
defining processes.

Stage 2:
During the Repeatable stage, basic and
consistent processes are established. The
processes are repeated for similar projects.

Stage 3:
During the Defined stage, all processes are well
defined, documented, standardized, and
integrated usually into software for the entire
organization. Consistent practices are in place. 27
5 Levels of CMM
Stage 4: During the Managed
stage, strategic analysis is
performed through data collected
on the quality of processes.
Software and processes are clearly
quantified.

Stage 5: During the Optimizing

stage, pro-active process
improvement is implemented
through qualitative feedback. This
helps in developing new ideas and
technologies.
 Characteristics of Each Level
Initial Level (Level 1)
• Characterized as ad hoc, and occasionally even chaotic
• Few processes are defined, and success depends on individual effort
Repeatable (Level 2)
• Basic project management processes are established to track cost, schedule, and functionality
• The necessary process discipline is in place to repeat earlier successes on projects with similar
applications
Defined (Level 3)
• The software process for both management and engineering activities is documented,
standardized, and integrated into a standard software process for the organization
• All projects use an approved, tailored version of the organization's standard software process for
developing and maintaining software
Managed (Level 4)
• Detailed measures of the software process and product quality are collected
• Both the software process and products are quantitatively understood and controlled
Optimized (Level 5)
• Continuous process improvement is enabled by quantitative feedback from the process and from
piloting innovative ideas and technologies
Key Process Areas
LIMITATIONS OF THE CMM
The model was developed to evaluate the capability of government
contractors to develop software. In real life, however, well-
documented processes and procedures do not necessarily create
successful software projects.

32
Software Process Models
• To solve actual problems in an industry setting, a software engineer or a
team of engineers must incorporate a development strategy that
encompasses the process, methods, and tools layers and the generic
phases.
This strategy is often referred to as a process model or a software
engineering paradigm.

• A process model for software engineering is chosen based on the nature

of the project and application, the methods and tools to be used, and the
controls and deliverables that are required.

• A software process model is an abstract representation of a process. It

presents a description of a process.
Process description
• When we describe and discuss processes, we usually talk about the
activities in these processes such as specifying a data model, designing
a user interface, etc., and the ordering of these activities.

• Process descriptions may also include:

o Products, which are the outcomes of a process activity;
o Roles, which reflect the responsibilities of the people involved in the
process;
o Pre- and post-conditions, which are statements that are true before and
after a process activity has been enacted or a product produced.
o Notation: activities, products
 Prescriptive Process Models
• Defines a distinct set of activities, actions, tasks, milestones, and work products that are
required to engineer high-quality software.

• Prescriptive process models advocate an orderly approach to Software Engineering.

1) The Waterfall model
2) Incremental model
3) Evolutionary process model
4) Specialized process model

• These process models are called “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.

• Each process model also prescribes a process flow (also called a workflow)—that is, the
manner in which the process elements are interrelated to one another.

35
Waterfall Model
(Diagram)
Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling
Tracking Modeling
Analysis
Design Construction
Code
Test Deployment
Delivery
Support
Feedback
36
 Waterfall Model
(Description)
• Oldest software lifecycle model and best understood by upper
management

• Used when requirements are well understood and risk is low

• Work flow is in a linear (i.e., sequential) fashion

• Used often with well-defined adaptations or enhancements to

current software
Many people dismiss the waterfall as obsolete and it certainly does have problems. But this
model can still be used in some situations.
37
 Waterfall Model
(Problems)
• Doesn't support iteration, so changes can cause confusion

• Difficult for customers to state all requirements explicitly and

upfront

• Requires customer patience because a working version of

the program doesn't occur until the final phase

• Problems can be somewhat alleviated in the model through

the addition of feedback loops (see the next slide)38
Waterfall Model with Feedback
(Diagram)
Communication
Project initiation
Requirements
gathering

Planning
Estimating
Scheduling
Tracking Modeling
Analysis
Design Construction
Code
Test Deployment
Delivery
Support
Feedback
39
Incremental Process
Models
• Tend to be among the most widely used (and effective) in the industry.
• It combines elements of the waterfall model applied in an iterative fashion. The model
applies linear sequences in a staggered fashion as calendar time progresses.
• Each linear sequence produces deliverable “increments” of the software. (Ex: a Word
Processor delivers basic file mgmt., and editing, in the first increment; more
sophisticated editing, and document production capabilities in the 2nd increment;
spelling and grammar checking in the 3rd increment.
• When an increment model is used, the 1st increment is often a core product. The core
product is used by the customer.
• As a result of use and/or evaluation, a plan is developed for the next increment.
• The plan addresses the modification of the core product to better meet the needs of
the customer and the delivery of additional features and functionality.

40
 Incremental Model
(Diagram)
Increment #1
Communication
Planning
Modeling
Construction
Deployment

Increment #2
Communication
Planning
Modeling
Construction
Deployment

Increment #3

Communication
Planning
Modeling
Construction
Deployment

41
 Incremental Model
(Description)
• Used when requirements are well understood
• Multiple independent deliveries are identified
• Work flow is in a linear (i.e., sequential) fashion within an increment
and is staggered between increments
• Iterative in nature; focuses on an operational product with each
increment
• Provides a needed set of functionality sooner while delivering optional
components later
• Useful also when staffing is too short for a full-scale development

42
Incremental Process Model

• The process is repeated following the delivery of each increment until the
complete product is produced.
• If the customer demands delivery by a date that is impossible to meet, suggest
delivering one or more increments by that date and the rest of the Software
later.
43
Incremental Process Model
❖Once the customer assesses the core product, there is a plan developed for the next increment. Thus,
in every increment, the needs of the client are kept in mind, more features and functions are added, and
the core product is updated.

❖This process continues until the complete product is produced.

❖The increments earlier to the main increment are called “stripped down” versions of the final product.
These increases form a base for customer evaluation. On this basis, the client can suggest new
requirements if required.

❖If there are a smaller number of employees to work on the project, the Incremental development model
is extremely useful to complete the project before the deadline. In a project, early increments can be
done with a smaller number of people.

❖In case the core product is well-defined and understood, more employees could be added if needed in
future increments.

❖ One of the benefits of the Incremental process model is that it can be planned to manage
technical risks.
44
Advantages of Incremental Model Disadvantages of Incremen ta l Model
❖ Initial product delivery is faster.
❖ Requires good analysis.
❖ Lower initial delivery cost.
❖ Resulting cost may exceed
❖ The core product is developed first i.e. main functionality is added in
the first increment. the cost of the organization.

❖After each iteration, regression testing should be conducted. During ❖ Each phase of an iteration is
this testing, faulty elements of the software can be quickly identified
because few changes are made within any single iteration.
rigid and does not overlap
each other
❖It is easier to test and debug than other methods of software
development because smaller changes are made during each iteration. ❖As additional functionality is
This allows for more targeted and rigorous testing of each element
within the overall product. added to the product, problems
may arise related to system
❖ With each release, a new feature is added to theproduct. architecture which was not
evident in earlier prototypes.
❖ Customers can respond to features and review the product.

❖ Risk of changing requirements is reduced

❖ The workload is less.

45
What are the advantages of an incrementalmodel?
• Customer feedback is received after the delivery of each component.
• Risk of requirement changes is reduced
• More flexible
• Easy to test and debug
• Give quick results

What are the disadvantages of an incrementalmodel?

• Needs a proper plan to integrate the components
• Needs a proper design to integrate the components
• More expansive as compared to the waterfall model.

When to use the incremental model?

•When major requirements are understood but some requirements can evolve
within the passage of time.
• When product launch in the market is gettinglate.
•When a customer has no problem with the budget but he demands more and
more quality in software.

46
Difference Between Waterfall and Incremental Model

47
RAD Model
• Rapid Application Development (RAD) is an incremental
software process model that emphasizes a short
development cycle.

• RAD is a “high-speed” adaptation of the waterfall model, in

which rapid development is achieved by using a component-
based construction approach.

• If requirements are well understood and project scope is

constrained, the RAD process enables a development team
to create a fully functional system within a short period of
time.
RAD Model Team # n
M o d e lin g
bus ines s m odeling
dat a m odeling
proc es s m odeling

C o n s t r u c t io n
c om ponent reus e
Team # 2 aut om at ic c ode
Com m unicat ion generat ion
t es t ing
Mo d el i ng
b u si n e ss m o d e l i n g
dat a m odeling
p ro ce ss m o d e l i n g

Planning
Co nst r uct i o n De ploym e nt
Team # 1 co m p o n e n t re u se int egrat ion
a u t o m a t i c co d e
g e n e ra t i o n deliv ery
Mode ling t e st i n g f eedback
business modeling
dat a modeling
process modeling

Const r uct ion

component reuse
aut omat ic code
generat ion
t est ing

6 0 - 9 0 days
What are the drawbacks of the
RAD model?
• For large, but scalable projects, RAD requires sufficient
human resources to create the right number of RAD teams.

• If developers and customers are not committed to the rapid-

fire activities necessary to complete the system in a much
abbreviated time frame, the RAD project will fail.

• If a system cannot properly be modularized, building the

components necessary for RAD will be problematic.
 Evolutionary Process Models
• Software evolves over a period of time; business and product
requirements often change as development proceeds, making
a straight-line path to an end product unrealistic.

• Software Engineering needs a process model that has been

explicitly designed to accommodate a product that evolves
over time.

• Evolutionary process models are iterative. They produce

increasingly more complete versions of the Software with
each iteration
Quiz
RAD stands for

a) Relative Application Development

b) Rapid Application Development
c) Rapid Application Document
d) None of the mentioned
Quiz
If you were a lead developer of a software company and
you are asked to submit a project/product within a
stipulated time-frame with no cost barriers, which model
would you select?

a) Waterfall
b) Spiral
c) RAD
d) Incremental
Quiz
Which of the following activities of a Generic Process
framework provides a feedback report?

a) Communication
b) Planning
c) Modeling & Construction
d) Deployment
Quiz
Which one of the following is not an Umbrella Activity

a) Reusability management
b) Risk management
c) Measurement
d) User Reviews
 Prototyping Model
(Diagram)
Quick
Planning

Communication
Start

Modeling
Quick Design
Deployment,
Delivery,
and Feedback

Construction
Of Prototype
56
Prototyping Model
• Customers often define a set of general objectives for software but don’t identify detailed input, processing, or input
requirements.

• Prototyping paradigm assists the Software engineering and the customer to better understand what is to be built
when requirements are fuzzy.

• The prototyping paradigm begins with communication where the requirements and goals of Software are defined.

• Prototyping iteration is planned quickly and modeling in the form of quick design occurs.

• Follows an evolutionary and iterative approach

• Used when requirements are not well understood

• Serves as a mechanism for identifying software requirements

• Focuses on those aspects of the software that are visible to the customer/user

• Feedback is used to refine the prototype

 Prototyping Model (Description)
• The quick design focuses on a representation of
those aspects of the Software that will be visible
to the customer “Human interface”. Qu ick p lan

Com m unicat ion

• The quick design leads to the Construction of

Mo d e lin g
the Prototype. Qu ick d e sig n

• The prototype is deployed and then evaluated

by the customer.

Deployment
• Feedback is used to refine requirements for the De live r y
Software. & Fe e dback Const r uct ion
of
pr ot ot ype

• Iteration occurs as the prototype is tuned to

satisfy the needs of the customer while enabling
the developer to better understand what needs
to be done. 58
Prototyping Model (Problems and Lessons)
The prototype can serve as the “first system”. Both customers and developers like
the prototyping paradigm as users get a feel for the actual system, and developers
get to build Software immediately. Yet, prototyping can be problematic:
a. The customer sees a "working version" of the software, wants to stop all
development, and then buys the prototype after a "few fixes" are made
b. Developers often make implementation compromises to get the software running
quickly (e.g., language choice, user interface, operating system choice,
inefficient algorithms)
Lesson learned
• Define the rules upfront on the final disposition of the prototype before it is
built
• In most circumstances, plan to discard the prototype and engineer the actual
production software with a goal of quality
 Spiral Model The spiral model is an evolutionary software
process model that couples the iterative nature of
prototyping with the controlled and systematic
planning aspects of the waterfall model.
estimation
scheduling It has two distinguishing features:
risk analysis
a. A cyclic approach for incrementally growing
communication a system’s degree of definition and
implementation while decreasing its degree
modeling of risk.
analysis
b. A set of anchor point milestones for ensuring
design
stakeholder commitment to feasible and
start
mutually satisfactory solutions.

deployment • Anchor-point milestones – a combination of work

construction
delivery code products and conditions that are attained along the path
feedback test of the spiral- are noted for each evolutionary pass.

60
 Spiral Model (Description)
• Invented by Dr. Barry Boehm in 1988

• Follows an evolutionary approach

• Used when requirements are not well understood and risks are high

• Inner spirals focus on identifying software requirements and project risks; may also
incorporate prototyping. Outer spirals take on a classical waterfall approach after
requirements have been defined, but permit iterative growth of the software

• Operates as a risk-driven model…a go/no-go decision occurs after each complete

spiral in order to react to risk determinations

• Requires considerable expertise in risk assessment

61
• Serves as a realistic model for large-scale software development
Quiz

__________ is not suitable for accommodating any change?

a) RAD Model
b) Waterfall Model
c) Build & Fix Model
d) Prototyping Model
Quiz

The major drawback of RAD model is __________.

1.It requires highly skilled developers/designers.
2.It necessitates customer feedbacks.
3.It increases the component reusability.
4.Both (a) & (c)
Quiz

The spiral model was originally proposed by

a) IBM
b) Barry Boehm
c) Pressman
d) Royce
Spiral Model
• During the early stages, the release might be a
paper model or prototype.

• During later iterations, increasingly more

complete versions of the engineered system
are produced.

• A spiral model is divided into a set of

framework activities divided by the Software
engineering team.

• As this evolutionary process begins, the

Software team performs activities that are
implied by a circuit around the spiral in a
clockwise direction, beginning at the center.

• Risk is considered as each revolution is made.

Spiral Model
• The first circuit around the spiral might result in planning
estimation
the development of a product specification; scheduling
risk analysis
subsequent passes around the spiral might be
communication
used to develop a prototype and then
progressively more sophisticated versions of modeling
analysis

the Software. start

design

• Each pass through the planning region results in

adjustments to the project plan. Cost and
deployment
schedule are adjusted based on feedback delivery
construction
code
feedback
derived from the customer after delivery. test

• Unlike other process models that end when

Software is delivered, the spiral model can be
adapted to apply throughout the life of the
Software.
Agile Methodologies
• The professional goal of every software engineer, and every development team, is to
deliver the highest possible value to our employers and customers. And yet, our projects
fail or fail to deliver value, at a dismaying rate.
• Though well-intentioned, the upward spiral of process inflation is culpable for at least
some of this failure.
• The principles and values of agile software development were formed as a way to help
teams break the cycle of process inflation and focus on simple techniques for reaching
their goals.
• At the time of this writing there were many agile processes to choose from. These
include
SCRUM,
Crystal,
Feature Driven Development (FDD),
Adaptive Software Development (ADP), and most significantly,
Extreme Programming (XP).
Others…
Agile Methodologies
• As we came to know that traditional software development approaches are more
mechanistic and concentrate more on Processes, tools, contracts, and plans. In
contrast to traditional methods, agile methods keep the emphasis on interaction,
working software, embracing change at any moment of the project, and customer
relationships.
• The method can be agile if it is:
Incremental
Cooperative
Straightforward
Adaptive
• “Agile view is more people-centric rather than plan-centric.” Agile methods are not
defined by a small set of principles, practices, and techniques. It creates a strategic
capability that has the capability of responding to change, the capability to balance the
structure and flexibility, capability of innovation and creation through development team
and uncertainty.
Agile methods
• Dissatisfaction with the overheads involved in
software design methods of the 1980s and 1990s led
to the creation of agile methods. These methods:
• Focus on the code rather than the design
• Are based on an iterative approach to software development
• Are intended to deliver working software quickly and evolve this quickly
to meet changing requirements.
• The aim of agile methods is to reduce overheads in
the software process (e.g. by limiting documentation)
and to be able to respond quickly to changing
requirements without excessive rework.
Agile manifesto
• We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
• That is, while there is value in the items on the
right, we value the items on the left more.
12 Principles of Agile Manifesto
1. The first principle is to take a customer-oriented approach and keep them updated.
2. Make changes whenever and wherever required, even at the end of the development stage
for any competitive changes.
3. Delivering the software to customers on time with more flexibility.
4. Collaboration between Business and development teams.
5. Give support and motivation to the team member who shows interest in the project. Give
them that extra work they would like to do, and trust them to get the job done.
6. Have a face-to-face interaction with the team.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development for all.
9. Continuous attention to technical excellence and good design enhancesagility.
10.The simplicity of the agile environment.
11.The best practices come from self-organizing teams.
12.Work effectively within cross-functional teams.
72
Important Aspects of Agile Project Management
To create a meaningful iteration asking with the Software development cycles. The 4 major
points created a way more transparency in the project approach for success.
● Team Interaction: In the software development process, rather than just told and
processes, there is a need for team Interaction. That is when a project can lead to
success in a very efficient way.

● Simplified Approach: Agile methodology is based on working on chunks called

”sprints”. This leads to a simplified approach to continuous development.

● Customer Collaboration: The customer’s involvement in the project plays a very

important role in Agile management so that the project is customer-oriented.

● Respond to the Immediate Changes: If there are any changes made during any of
the development stages. Immediate changes can be implemented in agile. 75
 Extreme Programming
• A very influential agile method, developed in the late 1990s, that
introduced a range of agile development techniques.

• Extreme Programming (XP) takes an ‘extreme’ approach to iterative

development.

New versions may be built several times per day;

Increments are delivered to customers approx. every 2 weeks;

All tests must be run for every build and the build is only accepted if tests run
successfully.
15
Extreme Programming
❖ XP is a lightweight, Efficient, Low risk, Flexible, predictable,
scientific, and fun way to develop a software

❖ Small to a medium team that works under vague and rapidly

changing requirements

❖ It follows Object Oriented Approach

Values of extreme programming
XP has simple rules that are based on 5 values to guide teamwork:

1. Communication. XP stresses the importance of the appropriate kind of

communication – face-to-face discussion with the aid of a whiteboard or other drawing
mechanism.

2.Simplicity. Developers strive to write simple code bringing more value to a product, as
it saves time and effort. Simplicity also means address only the requirements that you
know about; don’t try to predict the future.

3.Feedback. Team members deliver software frequently, get feedback about it, and
improve a product according to the new requirements.

4.Courage. Programmers objectively evaluate their own results without making excuses
and are always ready to respond to changes. You need the courage to raise
organizational issues that reduce your team’s effectiveness. You need the courage to
stop doing something that doesn’t work and try something else. You need the courage
to accept and act on feedback, even when it’s difficult to accept.

Respect. The members of your team need to respect each other in order to
communicate with each other, provide and accept feedback that honors your
relationship, and work together to identify simple designs and solutions.
 XP Fundamentals by Kent Beck
• Write unit tests before programming; keeping all tests running at all times.

• Integrating and testing the whole system--several times a day.

• Producing all software in pairs, two programmers at one screen.

• Starting projects with simple design. A simple design can evolve.

• Putting a minimal system into production quickly and growing it in whatever

directions prove most valuable.
 XP and Agile Principles
Incremental development is supported through small, frequent system
releases.

Customer involvement means full-time customer engagement with the

team.

People not process through pair programming, collective ownership,

and a process that avoids long working hours.

Change supported through regular system releases.

Maintaining simplicity through constant refactoring of code. 16

Influential XP practices
• Extreme programming has a technical focus and is not easy to
integrate with management practice in most organizations.

• Consequently, while agile development uses practices from XP, the

method as originally defined is not widely used.

• Key practices
• User stories for specification
• Refactoring
• Test-first development
• Pair programming
1.User stories for requirements
• In XP, a customer or user is part of the XP team and is responsible
for making decisions on requirements.

• User requirements are expressed as user stories or scenarios.

• These are written on cards and the development team breaks them
down into implementation tasks. These tasks are the basis of
schedule and cost estimates.

• The customer chooses the stories for inclusion in the next release
based on their priorities and the schedule estimates.
2. Refactoring
XP proposes constant code improvement (refactoring) to make changes
easier when they have to be implemented.

Programming team looks for possible software improvements and makes

these improvements even where there is no immediate need for them.

This improves the understandability of the software and so reduces the need
for documentation.

Changes are easier to make because the code is well-structured and clear.

However, some changes require architecture refactoring and this is much

more expensive.
RISK:
Changes the user does not test
Changes to working software break it
Examples of refactoring
Re-organization of a class hierarchy to remove duplicate code.

Tidying up and renaming attributes and methods to make them

easier to understand.

The replacement of inline code with calls to methods that have been
included in a program library.
3. Test-first development
Instead of following the normal path of:
develop code -> write tests -> run tests

The practice of Test-First Programming follows the path of:

Write failing automated test -> Run failing test -> develop code
to make test pass -> run test -> repeat

Test-First Programming reduces the feedback cycle for

developers to identify and resolve issues, thereby decreasing the
number of bugs that get introduced into production.
Problems with test-first development
• Programmers prefer programming to testing and sometimes they
take shortcuts when writing tests. For E.g. they may write incomplete
tests that do not check for all possible exceptions that may occur.

• Some tests can be very difficult to write incrementally. E.g., in a

complex user interface, it is often difficult to write unit tests for the
code that implements the ‘display logic’ and workflow between
screens.

• It is difficult to judge the completeness of a set of tests. Although you

may have a lot of system tests, your test set may not provide
complete coverage.
4. Pair programming
• Pair programming involves programmers working in pairs,
and developing code together.

• This helps develop common ownership of code and

spreads knowledge across the team.

• It serves as an informal review process as each line of

code is looked at by more than 1 person.

• It encourages refactoring as the whole team can benefit

from improving the system code.
 Pair Programming
In pair programming, programmers sit together at the same
workstation to develop the software.

Pairs are created dynamically so that all team members work with
each other during the development process.

The sharing of knowledge that happens during pair programming is

very important as it reduces the overall risks to a project when team
members leave.

Pair programming is not necessarily inefficient and there is evidence

that a pair working together is more efficient than 2 programmers
working separately.
The extreme programming release cycle
Extreme programming practices (a)
Principle or practice Description

Incremental planning Requirements are recorded on story cards and the stories to be
included in a release are determined by the time available and their
relative priority. The developers break these stories into development
‘Tasks’.

Small releases The minimal useful set of functionality that provides business value is
developed first. Releases of the system are frequent and incrementally
add functionality to the first release.

Simple design Enough design is carried out to meet the current requirements and no
more.

Test-first development An automated unit test framework is used to write tests for a new piece
of functionality before that functionality itself is implemented.

Refactoring All developers are expected to refactor the code continuously as soon
as possible code improvements are found. This keeps the code simple
and maintainable.
Extreme programming practices (b)
Pair programming Developers work in pairs, checking each other’s work and providing the
support to always do a good job.

Collective ownership The pairs of developers work on all areas of the system, so that no islands
of expertise develop and all the developers take responsibility for all of the
code. Anyone can change anything.

Continuous integration As soon as the work on a task is complete, it is integrated into the whole
system. After any such integration, all the unit tests in the system must
pass.

Sustainable pace Large amounts of overtime are not considered acceptable as the net effect
is often to reduce code quality and medium term productivity

On-site customer A representative of the end-user of the system (the customer) should be
available full time for the use of the XP team. In an extreme programming
process, the customer is a member of the development team and is
responsible for bringing system requirements to the team for
implementation.
Scrum
The term scrum is borrowed from rugby, where it is a formation of players. The
term scrum was chosen by the paper's authors because it emphasizes
teamwork. The software development term scrum was first used in a 1986
paper titled "The New New Product Development Game" by Hirotaka
Takeuchi and Ikujiro Nonaka. The paper was published in the Jan 1986 issue
of Harvard Business Review.
• Scrum is an agile method that focuses on managing iterative development rather than specific agile
practices.
• Three phases in Scrum.
• The initial phase is an outline planning phase where you establish the general objectives for the
project and design the software architecture.

• This is followed by a series of sprint cycles, where each cycle develops an increment of the system.

• The project closure phase wraps up the project, completes required documentation such as system
help frames and user manuals, and assesses the lessons learned from the project.
•
Scrum
• Scrum is a highly iterative agile framework that operates in
sprints of 2-4 weeks.

• It defines features and objectives prior to each sprint and is

designed to reduce risk while providing value to customers as
quickly as possible.

• In each sprint, a team commits to completing several user

stories – brief descriptions of what a user needs to be able to
achieve with the software.
Scrum Framework
The primary stages in the scrum process are:
1.Creating a product backlog – a prioritized list of development tasks, defined as user
stories. The work required for each user story is estimated using hours or story points.

2.Sprint planning – creating a sprint backlog – a subset of the product backlog planned for
a specific sprint, and estimated to fit into the fixed time scope of the sprint.

3.Sprint work – developing working software within the sprint. The team carries out a daily
stand-up meeting to share progress and resolve problems experienced by the team.

4.Testing and product demonstration – towards the end of a sprint, the focus shifts to
stabilizing and finalizing features, and conducting acceptance testing with product owners
and customers.

5.Retrospective – at the end of the sprint, sharing lessons learned from the previous sprint
and using it to plan or adjust the backlog for the next sprint.
The Scrum sprint cycle
• The starting point for planning is the product backlog,
which is the list of work to be done on the project.

• The selection phase involves all of the project team who

work with the customer to select the features and
functionality from the product backlog to be developed
during the sprint.

• Once these are agreed upon, the team organizes

themselves to develop the software.
Scrum sprint cycle
The Sprint cycle

• During this stage the team is isolated from the customer and the
organization, with all communications channeled through the ‘Scrum
master’.

• The role of the Scrum master is to protect the development team

from external distractions.

• At the end of the sprint, the work done is reviewed and presented to
stakeholders. The next sprint cycle then begins.
Teamwork in Scrum
• The ‘Scrum master’ is a facilitator who arranges daily meetings, tracks the
backlog of work to be done, records decisions measures progress against
the backlog, and communicates with customers and management outside of
the team.

• The whole team attends short daily meetings (Scrums) where all team
members share information, describe their progress since the last meeting,
problems that have arisen, and what is planned for the following day.

• This means that everyone on the team knows what is

going on and, if problems arise, can re-plan short-term
work to cope with them.
 Sprint Retrospective
This exercise allows you to
reallocate time and resources
to where it matters the most.
Scrum benefits
The product is broken down into a set of manageable and understandable
chunks.

Unstable requirements do not hold up progress.

The whole team has visibility of everything and consequently team

communication is improved.

Customers see on-time delivery of increments and gain feedback on how

the product works.

Trust between customers and developers is established and a positive

culture is created in which everyone expects the project to succeed.
Scrum terminology (a)
Scrum term Definition
Development team A self-organizing group of software developers, which should be no more than 7
people. They are responsible for developing the software and other essential
project documents.
Potentially shippable The software increment that is delivered from a sprint. The idea is that this should
product increment be ‘potentially shippable’ which means that it is in a finished state and no further
work, such as testing, is needed to incorporate it into the final product. In
practice, this is not always achievable.

Product backlog This is a list of ‘to-do’ items that the Scrum team must tackle. They may be
feature definitions for the software, software requirements, user stories, or
descriptions of supplementary tasks that are needed, such as architecture
definition or user documentation.

Product owner An individual (or possibly a small group) whose job is to identify product features
or requirements, prioritize these for development and continuously review the
product backlog to ensure that the project continues to meet critical business
needs. The Product Owner can be a customer but might also be a product
manager in a software company or other stakeholder representative.
Scrum terminology (b)
Scrum term Definition
Scrum A daily meeting of the Scrum team that reviews progress and prioritizes work to be
done that day. Ideally, this should be a short face-to-face meeting that includes the
whole team.

ScrumMaster The ScrumMaster is responsible for ensuring that the Scrum process is followed
and guides the team in the effective use of Scrum. He or she is responsible for
interfacing with the rest of the company and for ensuring that the Scrum Team is not
diverted by outside interference. The Scrum developers are adamant that the
ScrumMaster should not be thought of as a project manager. Others, however, may
not always find it easy to see the difference.

Sprint A development iteration. Sprints are usually 2-4 weeks long.

Velocity An estimate of how much product backlog effort that a team can cover in a single
sprint. Understanding a team’s velocity helps them estimate what can be covered in
a sprint and provides a basis for measuring improving performance.
Quiz
2. According to Agile manifesto –

A Individuals and interactions over people and technique

B Individuals and interactions over projects and tools
C Individuals and interactions over processes and tools.
D Individuals and interactions over products and tools
Quiz
Which of the following is not an Agile methodology?

A. Scrum
B. PMBOK® 3
C. Crystal Clear
D. Extreme programming (XP)
Quiz
There are ........... phases in Scrum
A. 2
B. 3
C. 4
D. 5
Quiz
Which of the following is responsible for sprint meeting?
A. Scrum team
B. Scrum master
C. Product Owner
D. None of the above
Kanban
• The Japanese word “kanban”, meaning “visual board” or a “sign”, has been
used in the sense of a process definition since the 1950s. It was first
developed and applied by Toyota as a scheduling system for just-in-time
manufacturing. The approach represents a pull system. This means that
production is based on customer demand rather than the standard push
practice to produce goods and push them to the market.

• Kanban is considered a “lean production” technique, or one that eliminates

labor and inventory waste.

• One of the ways Kanban reduces waste is through the “pull production” model
that regulates item production based on consumer supply and demand.
Kanban

• It is a large to-do list, which helps manage work according to priority.

• A central principle of Kanban is that the tasks and their status are
visualized as cards on a board, visible to all project staff.

• In Kanban, when a developer, tester, or other team member is ready

for more work, they pull a task on the board by moving it to “Doing”
or a specific work status like “Testing”.
Stages of Kanban
1.Visualize Work – define the process followed by the project
team (for example, Not Started > Development > Dev Testing
> Acceptance Testing > Done). Setup a board with a column
for each process stage, and post the tasks on the board as
sticky notes.

2.Limit Work in Progress (WIP) – a key principle of lean

manufacturing, Kanban enforces a limit on the number of
tasks the team works on concurrently – usually no more than
2-3.

3.Pull Don’t Push – each team member finishes their current

task and then “pulls” an additional assignment from the
board. This prevents bottlenecks when one part of the team
has a higher throughput than another.

4.Monitor and Improve – visualizations like the cumulative

flow chart below help understand how work is progressing
and identify bottlenecks in the process.
Kanban
● Kanban is an incremental process. It fulfills all the 12 different
principles of agile methodologies. The main aspect of Kanban is the
transparency in the software development cycle. Kanban boards and
tools are used for project traceability. This board is used in a 3 step
process:
❑To do
❑In Progress
❑Done
● To track any work in a project, the cards are used on the board to
represent the state of every work. This gives a clear picture of the
workflow and progress of a team.
11
The Kanban Methodology
depends on various
principles, such as:
❖ Visualize Work
❖ Limit Work in Progress
❖ Pulling New Work
❖ Measure and Learn
❖ Manage the Workflow
❖ Process improvement
❖ Working Together
❖ Deliver with new Ideas
❖ Just in Time Development
❖ Welcome to Incremental
Change
Advantages Of Kanban Methodology
❖ It increases the Productivity of the team.
❖ It provides a flexibility and sustainable development.
❖ It deals with continous process improvement and delivery.
❖ Kanban methodology eradicates the bugs from the process.
❖ Increase the efficiency of deliver a high quality product.
❖ It depends on just in time development.
❖ It limits the work in progress, so enhance the output.
❖ It focuses on one task at time.
❖ It provides the status of project in Kanban Board, its open for all.
❖ It improves the workflow and limits the time cycle.
❖ It maintains workflow status, collaboration on the team and sustainable development.