SOFTWARE ENGINEERING –

MODULE 1
Dr Smrithy G S
[Link]@[Link]

1
Introduction

• Computer software is the product that software professionals build

and then support over the long term.
• It encompasses
• Programs that execute within a computer of any size and architecture,
• Content that is presented as the computer programs execute, and
• Descriptive information in both hard copy and virtual forms that encompass
virtually any electronic media

2
IEEE Definition
• “Software engineering is the application of a systematic, disciplined
and quantifiable approach to the development, operation and
maintenance of software; i.e., application of engineering to
software.”

3
Challenges in software development
• Developing large/complex software is very challenging
• Effort intensive
• High cost
• Long development time
• Changing needs of users
• High risk of failure, user acceptance, performance, maintainability..
• Quite different from one-time programs where authors and users are
same!!

4
Successful software system
• Software development projects have not always been successful
• When do we consider a software application successful?
• Development completed
• It is useful
• It is usable
• and it is used
• Cost-effectiveness, maintainability implied

5
Reasons for failure
• Schedule slippage
• Cost over-runs
• Does not solve user’s problem
• Poor quality of software
• Poor maintainability

6
Reasons for failure (contd..)
• Ad-hoc software development results in such problems
• No planning of development work (eg. No milestone defined)
• Deliverables to user not defined
• Poor understanding of user requirements
• No control or review
• Technical incompetence of developers
• Poor understanding of cost and effort by both developer and user

7
Software Engineering

8
Why is Software Engineering important?
 Software Engineering is important because
▪ It enables us to build complex systems in a timely manner and with high quality
▪ It imposes discipline to work that can become quite chaotic
▪ It also allows the people who build computer software to adapt their approach in a
manner that best suits their needs.
 Steps in Software Engineering
▪ We build computer software like we build any successful product,
• By applying an agile, adaptable process that leads to a high-quality result, which meets the
needs of the people who will use the product.
• We apply a Software Engineering approach

9
Nature of Software
• Software is engineered rather than manufactured: The cost of developing
software lies almost completely in the engineering of the software, and not
in the “manufacturing” of a “product” that customers can be hold in their
hands.
• Software does not wear out with use: A software program is continuously
changed over its lifetime. If these changes occur too frequently, the bugs
introduced by each change may slowly degrade the performance and utility
of the software as a whole. Also, when software degrades in quality, there
are no “spare parts” which can be used as replacements.
• Unlike hardware, most software remains custom built, rather than built
using “off the shelf” components.
10
Nature of Software – contd..
 Software takes on a dual role.
▪ It is a product, and at the same time, the vehicle for delivering a product.
▪ As a product,
• It delivers the computing potential embodied by computer hardware or more broadly, by a
network of computers that are accessible by local hardware
▪ As the vehicle used to deliver the product
• Software acts as the basis for
– The control of the computer (operating systems),
– The communication of information (networks), and
– The creation and control of other programs (software tools and environments)

11
Failure Curves for Software

▪ In theory, the failure rate curve for software should take the form of the “idealized curve”
• Undiscovered defects will cause high failure rates early in the life of a program. However, these
are corrected, and the curve flattens.
▪ The idealized curve is an oversimplification of actual failure models for software.
▪ However, the implication is clear - software doesn’t wear out. But it does deteriorate!

12
Contd..

▪ During its life, software will undergo change.

▪ As changes are made, it is likely that errors will be introduced, causing the failure rate
curve to spike as shown in the “actual curve”
▪ Before the curve can return to the original steady-state failure rate, another change is
requested, causing the curve to spike again
▪ Slowly, the minimum failure rate level begins to rise – the software is deteriorating due to
change.

13
Software Application Domains
• System software is software written to service and support other programs. Compilers,
editors, debuggers, operating systems, hardware drivers, are examples of such software.
• Application software are programs designed to solve a specific business need. Most
software operating with business and technical data are application software, as are
most real-time systems. When a user interacts directly with a piece of software, it is
called application software. The sole purpose of application software is to assist the user
in doing specified tasks. Microsoft Word and Excel are examples of application software.
• Engineering / scientific software supports the use and production of scientific and
engineering data sets. They are used in almost all engineering and scientific disciplines,
from simulating water flow, lighting conditions, and aerodynamics, to examining the
large scale structure of the universe. Engineering software is also used for design
purposes (such software is called CAD software, for Computer Aided Design) and for
automating the manufacturing of goods (CAM: Computer Aided Manufacturing).

14
Software Application Domains – Contd..
• Embedded software that resides directly within some hardware component
in order to provide control over the component or other vital features
required for it to function.
• A web application is an application accessed via a web browser over a
network. Web applications offer a variety of functions, and some
application software are now implemented as web applications, such as
Google Docs.
• Artificial intelligence software (AI) has been defined as "the science and
engineering of making intelligent machines" (John McCarthy). Application
domains that make use of AI software include robotics, expert systems,
pattern recognition, theorem proving and game playing.
15
Software myths
• All people who come into contact with software may suffer from
various myths associated with developing and using software. Here
are a few common ones.
• Management myths
• Our company has books full of standards, procedures, protocol, and
so on, related to programming software. This provides everything
that our programmers and managers need to know.
• While company standards may exist, one must ask if the standards are
complete, reflect modern software practice, and are — importantly —
actually used.

16
Software Myths – Contd..
• If we fall behind schedule in developing software, we can just put
more people on it.
• If software is late, adding more people will merely make the problem worse.
• This is because the people already working on the project now need to spend
time educating the newcomers, and are thus taken away from their work.
• The newcomers are also far less productive than the existing software
engineers, and so the work put into training them to work on the software
does not immediately meet with an appropriate reduction in work.

17
Software Myths – Contd..
• Customer / end-user myths
• A vague collection of software objectives is all that is required to
begin programming. Further details can be added later.
• If the goals / objectives for a piece of software are vague enough to become
ambiguous, then the software will almost certainly not do what the customer
requires.
• Changing requirements can be easily taken care of because software
is so flexible.
• The longer that development on the software has proceeded for, the more
work is required to incorporate any changes to the software requirements.

18
Software Myths – Contd..
• Programmer myths
• Once the software is written, and works, our job is done.
• A large portion of software engineering occurs after the customer has the software,
since bugs will be discovered, missing requirements uncovered, and so on.
• The only deliverable for a project is the working program.
• At the very least there should also be documentation, which provides support to
both the software maintainers, and to the end-users.
• Software engineering will make us create a lot of unnecessary
documentation, and will slow us down.
• Software engineering is not about producing documents. Software engineering
increases the quality of the software. Better quality reduces work load and speeds
up software delivery times.

19
The software crisis
• There were many difficulties in the development of large software
systems during the 1960s and 1970s.
• The term “software crisis” dates from that time. The problems
stemmed from an inability to apply the techniques used to build small
software systems to the development of larger and more complex
systems.
• The typical way to develop small systems can be described as “code-
and-fix”.

20
The code-and-fix approach to software
development
• Code-and-fix development occurs when software
engineers come together with a vague set of
requirements and start producing software, fixing it,
and changing it until the correct product appears.
• But for anything other than small software projects,
code-and-fix is a disaster for a number of reasons:
• There is no way to estimate time-scales or budgets.
• There is no assessment of possible risks and design flaws:
you may come close to a finished product only to find an
insurmountable technical problem which sets the whole
project back.

21
The code-and-fix approach to software
development – Contd..
• Many project failures resulted from the inability to scale the techniques
employed when developing small software systems to handle larger, more
complex systems. This failure leads to:
• never completed systems
• missed deadlines
• exceeded budgets
• a system that does not do all that is required of it
• a system that works but is difficult to use
• a system difficult to modify to meet changes in organizational needs and practices
• a loss of trust from users, who may experience many problems with using the
software.
• These problems were largely due to the lack of any framework for the
planning and organisation of software development projects.

22
Software engineering and the software
process
• Recognizing these problems, work was carried out to understand the
process of software development and to transform it into a reliable
and rigorous discipline, like architecture or engineering.
• An improved process should produce software that is correct,
reliable, usable and maintainable.
• By understanding the process, it should be possible to plan projects
with more accurate predictions of cost and time, and provide ways of
monitoring intermediate stages of project progress, to be able to
react and re-plan if a project begins to go off budget or timescale.

23
Software engineering and the software
process
• Much research has been put into the study of past systems that were both
successful and unsuccessful. This can be summarized as:
• Some software development activities appear to be common for all successful
projects.
• Some activities need to occur before others.
• There is a need to both understand that requirements change, and to manage this
change.
• Any existing systems need to be understood before working on the design of a new
one.
• It is wise to delay decisions that will constrain the final system — this can be
achieved by initially designing an implementation-independent logical design,
before committing to a detailed design for a particular physical set of hardware and
software.

24
Software engineering and the software
process
• Analysis of such findings led to a model of what is called the software
process, or system life cycle.
• The software process is the process of engineering and developing
software; a process model, or life cycle model is a descriptive model
giving the best practices for carrying out software development (i.e.,
for carrying out the software process).

25
Software engineering and the software
process
• Software engineering is exactly the discipline of producing such
software.
• Fritz Bauer defined software engineering to be: “the establishment
and use of sound engineering principles in order to obtain
economically software that is reliable and works efficiently on real
machines. ”

26
The layers of software engineering
 Software engineering is a layered technology.
• Any engineering approach (including software engineering) must rest on
an organizational commitment to quality - Total quality management
• The software process is the foundation of the software engineering. The
process is the framework on which the rest of software engineering is built.
The process defines how management occurs, what the required input and
output products are, what milestones should be reached, and so on. The
process also describes how quality should be ensured. The software
engineering process is the glue that holds the technology layers together
and enables rational and timely development of computer software

27
The layers of software engineering – Contd..
• On top of process, software
engineering consists of methods.
These describe how the various
portions that make up the software
process should be carried out. For
instance, how to communicate with
clients, how to test the software, to
gather requirements, and so on. This
makes up the process model.
• Software engineering tools provide
automated or semi- automated
support for the process and the
methods

28
 The Software Process
 Software Process
▪ The systematic approach that is used in software engineering
▪ The set of activities, actions, and tasks that are performed to create some work product
• An activity strives to achieve a broad objective
– Example: Communication with stakeholders
– It is applied regardless of the application domain, size of the project, complexity of the
effort, etc.
• An action encompasses a set of tasks that produce a major work product
• A task focuses on a small, but well-defined objective that produces a tangible outcome
– Example: Conducting a unit test

29
 The Software Process – Contd.
 In the context of Software Engineering
▪ A process is not a rigid prescription for how to build computer software.
▪ It is an adaptable approach that enables the people doing the work (the software
team) to pick and choose the appropriate set of work actions and tasks

30
 Software Product
 Products or deliverables are the outcomes of a process activity.
▪ For example, the outcome of architectural design (activity) may be the software
architecture model (deliverable)
 From the point of view of a software engineer, the work products are
▪ The programs, documents, and data that are produced as a consequence of the
activities and tasks defined by the process

31
 Software Process – Basic Activities
 Four fundamental activities are common to all software processes
▪ Software Specification
• Customers and engineers define the software that is to be produced and the constraints
on its operation
▪ Software Development
• The software that meets the specification is designed and programmed for production
▪ Software Validation
• The software is validated to ensure that it does what the customer requires
▪ Software Evolution
• The software is modified to reflect changing customer and market requirements

32
Software Process – Basic Activities – Contd..
• It is important to realize that the activities outlined in the process
models should be modified, based on:
• The problem having to be solved.
• The characteristics of the project.
• The nature of the development team.
• The organizational culture.

33
 Software Process Models
 A Software Process Model
▪ Also called as Software Development Life Cycle or SDLC
▪ A simplified representation of a software process

34
A Generic Process Model
• A generic process framework for software engineering defines five
framework activities—communication, planning, modeling, construction,
and deployment.
• A linear process flow executes each of the five framework activities in
sequence, beginning with communication and culminating with
deployment.
• 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.

35
A Generic Process Model – Contd..
• A parallel process flow executes one or more activities in parallel with
other activities (e.g., modeling for one aspect of the software might
be executed in parallel with construction of another aspect of the
software).

36
A Generic Process Model – Contd..

37
 Waterfall Model

▪ In this approach, the fundamental process activities of specification, development,

validation, and evolution are represented as separate process phases such as
requirements specification, software design, implementation, and testing, and
maintenance.
▪ This model is sometimes also called the “linear sequential” model.
38
Waterfall Model – Contd..
• The features of the waterfall model are as follows:
• The system development process is broken into distinct stages.
• Each stage involves a particular project activity — such as “communication” or
“construction”.
• Each stage, when completed, results in a deliverable (also called a product).
• The input to any particular stage are the deliverables from the previous stage.
• The model presents the stages in a strict, one-way sequence — a project
cannot go back to repeat a stage once that stage has been completed. Any
required re-work (as a result, for example, of changing software
requirements) is very limited

39
 Waterfall Model – Contd..
• Requirements analysis and definition: The system’s services, constraints, and goals are
established by consultation with system users. They are then defined in detail and serve as a
system specification.
• System and software design: The systems design process allocates the requirements to either
hardware or software systems. It establishes an overall system architecture.
• Implementation and unit testing: During this stage, the software design is realized as a set of
programs or program units. Unit testing involves verifying that each unit meets its
specification.
• Integration and system testing: The individual program units or programs are integrated and
tested as a complete system to ensure that the software requirements have been met. After
testing, the software system is delivered to the customer.
• Operation and maintenance: Normally, this is the longest life-cycle phase. The system is
installed and put into practical use. Maintenance involves correcting errors that were not
discovered in earlier stages of the life cycle, improving the implementation of system units,
and enhancing the system’s services as new requirements are discovered.

40
 Waterfall Model – Contd.
 Examples of software applications where waterfall model is appropriate
▪ Embedded Systems where the software has to interface with hardware systems.
• Because of the inflexibility of hardware, it is not usually possible to delay decisions on the
software’s functionality until it is being implemented.
▪ Critical Systems
• There is a need for extensive safety and security analysis of the software specification and
design.
• In such systems, the specification and design documents must be complete so that this
analysis is possible
▪ Large Software Systems
• Several companies are involved
• Complete specifications may be needed to allow for the independent development of
different subsystems

41
Advantages of Waterfall Model
• The stages consist of well-defined tasks which promotes good
scheduling and cost estimation (if all stages occur in the expected
sequence once only).
• The deliverables provide targets or milestones to see how far a team
has reached in the development process.
• The life cycle is broken into well defined stages — so staff expertise
can be used efficiently (e.g., a data modeler only needs to work on
certain stages, a programmer only on other stages, and so on).
• At any one time the project team knows what should be happening
and the deliverable(s) they are to produce.
42
Disadvantages of Waterfall Model
• It is rare that a software development project will follow the sequential
process that the waterfall model uses.
• Although the requirements are specified early on, user understanding and
feedback of the software will not occur until after the system is
implemented, which is possibly too late (or very costly) to change.
• The user may not be able to describe the requirements of the desired
system in any detail early on.
• The model does not easily allow for the anticipation of change — some
systems take years to develop, but once the early stages have been
completed the model commits the project to a fixed specification of the
system.
43
Disadvantages of Waterfall Model – Contd..
• If a problem is identified at a later stage, the model does not make it
easy (or cheap) to return to an earlier stage to rectify the mistake
(since all intermediate steps will need to be repeated, resulting in
significant, unplanned, time and resource costs).

44
Incremental Model

• The system is developed as a series of versions (increments), with

each version adding functionality to the previous version
8/5/2024 45
Incremental Model – Contd..
• Provide a limited set of software functionality to users quickly and
then refine and expand on that functionality in later software
releases.
• The incremental model combines elements of linear and parallel
process flows
• The incremental model applies linear sequences in a staggered
fashion as calendar time progresses.
• Each linear sequence produces deliverable “increments” of the
software. A parallel process flow executes one or more activities in
parallel with other activities.
46
Incremental Model – Contd..

47
Incremental Model - Contd
• Idea is to develop an initial implementation, getting feedback from users and
others, and evolving the software through several versions until the required
system has been developed.
• When an incremental model is used, the first increment is often a core product.
• Basic requirements are addressed but many supplementary features (some
known, others unknown) remain undelivered.
• The core product is used by the customer (or undergoes detailed evaluation).
• This approach interleaves the activities of specification, development, and
validation.
• Each increment or version of the system incorporates some of the functionality
that is needed by the customer.
• The customer or user can evaluate the system at a relatively early stage in the
development to see if it delivers what is required.
8/5/2024 48
Incremental Model – Contd.
 Advantages over the waterfall model
▪ Cost of implementing requirements changes is reduced
▪ It’s easier to get customer feedback on the development work that has been done
▪ Early delivery and deployment of useful software to the customer is possible

This approach can be either plan-driven, agile or, more usually, a mixture of these approaches. In a
plan-driven approach, the system increments are identified in advance; if an agile approach is
adopted, the early increments are identified, but the development of later increments depends on
progress and customer priorities

8/5/2024 49
Incremental Model – Contd.
• Incremental Development Vs Incremental Delivery
• Incremental development: Develop a system incrementally and
expose it to customers and other stakeholders for comment, without
necessarily delivering it and deploying it in the customer’s
environment.
• Incremental delivery means that the software is used in real,
operational processes, so user feedback is likely to be realistic.

50
Incremental Model – Contd.
 Problems & Drawbacks
▪ The process is not visible. It’s not cost effective to produce documents that
reflect every version of the system
▪ System structure tends to degrade as new increments are added
▪ The problems become acute for large, complex, long-lifetime systems, where
different teams develop different parts of the system.
• Large systems need a stable framework or architecture
• Responsibilities of the different teams working on parts of the system need to be clearly
defined with respect to that architecture.
• This has to be planned in advance rather than developed incrementally

8/5/2024 51
Integration and Configuration

▪ This approach relies on the availability of reusable components or systems.

▪ The system development process focuses on configuring these components for
use in a new setting and integrating them into a system.

8/5/2024 52
Integration and Configuration – Contd.
 Three types of software components are frequently reused
▪ Stand-alone application systems
• Configured for use in a particular environment
▪ Collections of objects
• Developed as a component or as a package to be integrated with a component framework
▪ Web services
• Developed according to service standards

8/5/2024 53
Integration and Configuration – Contd.
• Requirements specification: The initial requirements for the system are
proposed. These do not have to be elaborated in detail but should include
brief descriptions of essential requirements and desirable system features.
• Software discovery and evaluation: Given an outline of the software
requirements, a search is made for components and systems that provide
the functionality required. Candidate components and systems are
evaluated to see if they meet the essential requirements and if they are
generally suitable for use in the system.
• Requirements refinement: During this stage, the requirements are refined
using information about the reusable components and applications that
have been discovered. The requirements are modified to reflect the
available components, and the system specification is re-defined.

8/5/2024 54
Integration and Configuration – Contd.
• Application system configuration: If an off-the-shelf application
system that meets the requirements is available, it may then be
configured for use to create the new system.
• Component adaptation and integration: If there is no off-the-shelf
system, individual reusable components may be modified and new
components developed. These are then integrated to create the
system

55
Evolutionary Software 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 unrealistic.
Evolutionary models are iterative.
They are characterized in a manner that enables you to
develop increasingly more complete versions of the software.

8/5/2024 56
57
58
59
60
61
62
63
64
65
66
67
68
Evolutionary Software Process Models -
Contd.
 Two common evolutionary process models
▪ Prototype Software Development or Prototyping
▪ The Spiral Model

8/5/2024 69
Prototyping
• Often, a customer defines a set of general objectives for software, but does not
identify detailed requirements for functions and features. 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.

• Prototyping paradigm assists the stakeholders to better understand what is to be

built when requirements are fuzzy.

70
Prototyping – Contd..

71
Prototyping – Contd..
• The prototyping paradigm begins with communication. You meet with
other stakeholders to 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 a “quick design”) occurs.
• A quick design focuses on a representation of those aspects of the
software that will be visible to end users (e.g., human interface layout
or output display formats.)

72
Prototyping – Contd..
• The quick design leads to the construction of a prototype.
• The prototype is deployed and evaluated by stakeholders, who provide
feedback that is used to further refine requirements.
• Iteration occurs as the prototype is tuned to satisfy the needs of various
stakeholders, while at the same time enabling you to better understand
what needs to be done
• Ideally, the prototype serves as a mechanism for identifying software
requirements.
• Although some prototypes are built as “throwaways,” others are
evolutionary in the sense that the prototype slowly evolves into the actual
system.

73
Prototyping – Contd..
• Advantages of prototyping include:
• Users get an early idea of the final system features.
• The prototype provides an opportunity to identify problems early and to change the
requirements appropriately.
• The prototype is a model that all users and customers should be able to understand and
provide feedback on, thus the prototype can be an important tool to improve
communication between users and developers.
• It may be possible to use aspects of the prototype specification and design in the final
system specification and design, thus some of the prototype development resources can
be recouped.
• A major problem with developing “disposable” prototypes is that the customer may
believe it to be the final product. Customers may not understand the need to re-engineer
the software and restart development, and may ask that the prototype be “cleaned up”
and released to them.
74
The Spiral Model

• The spiral model is an evolutionary software process model that

couples the iterative nature of prototyping with the controlled and
systematic aspects of the waterfall model.
75
The Spiral Model – Contd..
• Using the spiral model, software is developed in a series of
evolutionary releases.
• During early iterations, the release might be a 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 defined by
the software engineering team.
• Each of the framework activities represent one segment of the spiral
path illustrated in Figure.

76
The Spiral Model – Contd..
• 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.
• Anchor point milestones—a combination of work products and conditions
that are attained along the path of the spiral—are noted for each
evolutionary pass.
• The first circuit around the spiral might result in the development of a
product specification; subsequent passes around the spiral might be used
to develop a prototype and then progressively more sophisticated versions
of the software.

77
The Spiral Model – Contd..
• Each pass through the planning region results in adjustments to the project
plan.
• Cost and schedule are adjusted based on feedback derived from the
customer after delivery.
• In addition, the project manager adjusts the planned number of iterations
required to complete the software.
• Unlike other process models that end when software is delivered, the spiral
model can be adapted to apply throughout the life of the computer
software.
• Therefore, the first circuit around the spiral might represent a “concept
development project” that starts at the core of the spiral and continues for
multiple iterations until concept development is complete.

78
The Spiral Model – Contd..
• If the concept is to be developed into an actual product, the process
proceeds outward on the spiral and a “new product development
project” commences.
• The new product will evolve through a number of iterations around
the spiral.
• Later, a circuit around the spiral might be used to represent a
“product enhancement project.” In essence, the spiral, when
characterized in this way, remains until the software is retired.
• Whenever a change is initiated, the process starts at the appropriate
entry point (e.g., product enhancement).
79
Advantages
• The spiral model is a realistic approach to the development of large-scale systems
and software.
• Software evolves as the process progresses, the developer and customer better
understand and react to risks at each evolutionary level.
• The spiral model uses prototyping as a risk reduction mechanism but, more
important, enables you to apply the prototyping approach at any stage in the
evolution of the product.
• It maintains the systematic stepwise approach suggested by the classic life cycle but
incorporates it into an iterative framework that more realistically reflects the real
world.
• The spiral model demands a direct consideration of technical risks at all stages of the
project and, if properly applied, should reduce risks before they become
problematic.
80
AGILE

81
AGILITY AND THE COST OF CHANGE
• A well-designed agile process “flattens” the
cost of change curve allowing a software
team to accommodate changes late in a
software project without dramatic cost and
time impact.
• Agile process encompasses incremental
delivery.
• 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.

82
Plan-driven Vs Agile development

83
Plan-driven Vs Agile development – Contd..
• Agile approaches to software development consider design and
implementation to be the central activities in the software process.
They incorporate other activities, such as requirements elicitation and
testing, into design and implementation.
• By contrast, a plan-driven approach to software engineering identifies
separate stages in the software process with outputs associated with
each stage. The outputs from one stage are used as a basis for
planning the following process activity.
• In a plan-driven software development process, iteration occurs
within activities, with formal documents used to communicate
between stages of the process.

84
Plan-driven Vs Agile development – Contd..
• In an agile approach, iteration occurs across activities. Therefore, the
requirements and the design are developed together rather than
separately.
• Agile methods are incremental development methods in which the
increments are small, and, typically, new releases of the system are
created and made available to customers every two or three weeks.
• They involve customers in the development process to get rapid
feedback on changing requirements. They minimize documentation
by using informal communications rather than formal meetings with
written documents

85
Agile methods

86
Agile methods –Contd.

87
Agile Manifesto
• The Agile Manifesto is a set of guiding values and principles for Agile
software development.
• The purpose of the manifesto was to define a more flexible and
responsive approach to software development that prioritizes
individuals, collaboration, and the ability to adapt to change.
• The Agile Manifesto consists of four key values and twelve principles.
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

88
Agility Principles
The Agile Alliance defines 12 agility 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.

89
Agility Principles – Contd..
• Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the job
done.
• The most efficient and effective method of conveying information to
and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace
indefinitely.

90
Agility Principles – Contd..
• Continuous attention to technical excellence and good design
enhances agility.
• Simplicity—the art of maximizing the amount of work not done—is
essential.
• The best architectures, requirements, and designs emerge from self–
organizing teams.
• At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly.

91
The Road to Mastery

92
The Road to Mastery –Contd..

93