Software Engineering

Unit :1
Introduction to Software Engineering &
Process Models
Chapter :1
Software And Software
Engineering
[1.3, 1.4]
MCA SEMESTER 4
SUBJECT : 4659303-SOFTWAREENGINEERING (SE)
PREPAREDBY : JIGNESH J KARIYA
1

INTRODUCTION OF SOFTWARE
ENGINEERING.
 What is Software Engineering?
 [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.
 The seminal definition :
2

The IEEE definition:
Software Engineering: (1)The application of a systematic,
disciplined, quantifiable approach to the development,
operation, and maintenance of software; that is, the
application of engineering to software. (2)The study of
approaches as in(1).
3

WHAT IS SOFTWARE?
Software is:
(1) instructions(computer programs) that when executed
provide desired features, function, and performance;
(2) data structures that enable the programs to
adequately(suitable)manipulate information and
(3) documentation that describes the operation and use of
the programs
4

Characteristics of Software :
1)Software is developed or engineered, it is not
manufactured in the classical sense.
2)Software doesn't "wear out.“ [use or be used until
useless]
3)Although the industry is moving toward component-
based construction, most software continues to be
custom-built.
WHAT IS SOFTWARE?
5

Software is developed or engineered; it is not
manufactured in the classical sense:
 Although some similarities exist between 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 non existent for software.
 Both activities require the construction of a “product”, but
the approaches are different.
Characteristics...
6

Software doesn’t “Wear out”
Figure show failure rate as a function of time for hardware.
The relationship, often called the “bath tub 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 (hope fully, quite low) for some period of time. As time passes,
however, the failure rate rises again as hardware components suffer
from the cumulative effects of dust, vibration, abuse, temperature
extremes etc. Stated simply, the hardware begins to wear out.
Characteristics...
7

The failure rate curve for software should take the form of the “idealized
curve” shown in Figure.
Undiscovered defects will cause high failure rates early in the life of a program.
However, these are corrected and the curve flattens as shown.
The idealized curve is a gross over simplification of actual failure models for
software. However, the implication is clear—software doesn’t wearout. But it
does deteriorate [go down/weaken/become worse]
Characteristics...
8

When a hardware component wears out, it is replaced by a spare
part. There are no software spare parts. Every software failure
indicates an error in design or in the process through which
design was translated in to machine executable code. Therefore,
the software maintenance tasks that accommodate requests for
change involve considerably more complexity than hardware
maintenance
(3) Although the industry is moving toward component-based
construction, most software continues to be custom built
 A software component should be designed and implemented so
that it can be reused in many different programs. Modern
reusable components encapsulate both data and the processing
that is applied to the data, enabling the software engineer to
create new applications from reusable parts
Characteristics...
9

Q: SOFTWARE ENGINEERING LAYERS.
WHAT DO YOU MEAN BY THE TERM SOFTWARE ENGINEERING? EXPLAIN
SOFTWARE ENGINEERING AS A LAYERED TECHNOLOGY. [07]
 Introduction :
 Software Engineering is the application disciplined,
quantifiable approach to of a systematic, the
development, operation, and maintenance of software.
 Software engineering is a layered technology. As shown in
figure (On Next Slide), any engineering approach (including
software engineering) must remain on an organizational
commitment to quality
10

SOFTWARE ENGINEERING LAYERS…..
11

Process Layer :
The foundation for software engineering is the process
layer.
Process defines a frame work that must be established for
effective delivery of software engineering technology.
The software process forms the basis for management
control of software projects technical methods and
establishes the are applied, work Context in which products
(models, documents, data, reports, forms, etc.) are
produced, milestones are established, quality is ensured,
and change is properly managed. 12

• Method Layer:
• Software engineering methods provide the technical solution for
building software.
Methods encompass a broad array of tasks that include
•Communication,
•Requirements analysis,
•Design modelling,
•Program construction,
•Testing, and support.
• It is a set of basic principles that manage each area of the technology
and include modelling activities and other descriptive techniques.
13

• Tools Layer:
• Software engineering 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.
For Reference:
CASE(computer-aided software engineering) is the use of a computer-assisted method
to organize and control the development of software, especially on large, complex
projects involving many software components and people. Using CASE allows
designers, code writers, testers, planners, and managers to share a common view of
where a project stands at each stage of development.
14

Q:-THE SOFTWARE PROCESS
 Introduction :
• A process is a collection of activities, actions, and tasks that are
performed when some work product is to be created.
• An activity includes to achieve a broad objective (e.g., communication
with stake holders) and is applied regardless of the application domain,
size of the project, complexity of the effort which software engineering is
to be applied.
• An action (e.g., architectural design) encompasses a set of tasks that
produce a major work product (e.g., an architectural design model).
• A task focuses on a small, but well defined objective (e.g., conducting a
unit test) that produces a tangible outcome
15

THE SOFTWARE PROCESS...
 A generic process frame work for software engineering
encompasses five activities:
• Communication
• Planning
• Modelling
• Construction
• Deployment
16

Communication
 Before any technical work Can commence, it is critically important
to communicate and collaborate with the customer or
client.(Stakeholders).
 The objective is to understand stakeholders’ objectives for the
project and to gather requirements that help define software
features and functions
17

Planning:
It defines the software engineering work by
describing 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.
It is similar like a map which guide us about our
journey.
18

Modeling:
 It creates a “sketch” of the thing so that you’ll
understand the real picture—what it will look like
architecturally.
 A software engineer does the same thing by creating
models to better understand software requirements and
the design that will achieve those requirements.
Construction:
 This activity combines code generation (either manual
or automated) and the testing that is required to
uncover errors in the code.
19

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.
These five generic framework activities can be used during the
development of small, simple programs, the creation of large Web
applications, and for the engineering of large, complex computer-
based systems.
The details of the software process will be quite different in each
case, but the frame work activities remain the same.
20

21
 What do you mean by the term Software Engineering ?
Explain Software Engineering as a Layered Technology.[07]
 Explain software engineering as a layered technology.[07]
GTU EXAM QUESTIONS

Chapter :2
Process Model
[2.1 to 2.3]
22

INTRODUCTION OF PROCESS
MODEL
When you work to build a product or system, it’s important to
go through a series of predictable steps—a road map that helps
you create a timely, high-quality result.
The road map that you follow is called a “software process.”
Technical definition:
 software process as a framework for the activities, actions,
and tasks that are required to build high-quality software.
23

GENERIC PROCESS MODEL
Q: Explain different Generic Process Model
Process is defined as a collection of work activities, actions, and
tasks that are performed when some work product is to be created.
Each of these activities, actions, and tasks reside with in a framework
or model that defines their relationship with the process and with
one another.
The software process is represented schematically in Figure (Next
slide) Referring to the figure, each frame work activity is populated
by a set of software engineering actions.
Each software engineering action is defined by a task set that
identifies the work tasks that are to be completed,
The work products that will be produced, the quality assurance
points that will be required, and the milestones that will be used to
indicate progress 24

GENERIC PROCESS MODEL
A generic process frame work for software engineering frame
work activities—
 Communication,
 Planning,
 Modeling,
 Construction,
 Deployment.
Process Flow—It describes how the frame work activities and
the actions and tasks that occur with in each frame work
activity are organized with respect to sequence and time and is
illustrated in Figure (Next Slide)
26

(1) Linear Process Flow : Linear process flow executes
each of the five frame work activities in sequence,
beginning with communication and closing with
deployment.
27

(2) Iterative Process Flow: An iterative process flow
repeats one or more of the activities before
proceeding to the next process.
28

(3) Evolutionary Process Flow: It executes the activities in a
“circular” manner . Each circuit through the five activities leads to a
more complete version of the software.
29

(4) Parallel Process Flow: It 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)
30

PRESCRIPTIVE PROCESS MODEL
Prescriptive process models were originally proposed to bring order
to the chaos (disorder) of software development.
Prescriptive process models define a prescribed set of process
elements and a predictable process work flow.
The prescriptive process approach in which order and project
consistency are dominant (main) issues.
“prescriptive” means, they prescribe a set of process elements—
frame work 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
inter related to one another.
31

(1) The Waterfall Model
(2) Incremental Process Models
(3) Evolutionary Process Models
(4) Concurrent Model
PRESCRIPTIVE PROCESS MODEL
32

(1) The Waterfall Model
There are times when the requirements for a problem are well
understood—when work flows from communication through
deployment in a reasonably linear fashion.
This situation is sometimes encountered when well-defined
adaptations or enhancements to an existing system must be
made.
It may also occur in a limited number of new development efforts,
but only when requirements are well defined and reasonably
stable.
33

Note : In exam , write few lines of each above activities in Q Answer 34

The water fall model, sometimes called the classic life
cycle.
Sometimes called the‘ classic life cycle’.
It suggests a systematic, sequential approach to Software
development that begins with customer specification of
requirements and progresses through planning, modelling,
construction, and deployment, finish in on going support of
the completed software.
There are times when the requirements for a problem are
well understood—when work flows from communication
through deployment in a reasonably linear fashion. 35

A variation in the representation of the waterfall model is called the
V-model.
Represented in Figure ,the V-model represents the relationship of
quality assurance actions to the actions associated with
communication, modelling, and early construction activities.
36

This model is simple and easy to understand and use.
It is easy to manage due to–each phase has specific deliverables
and are view process.
Model phases are processed and completed one at a time. Phases
do not overlap.
Waterfall model works well for smaller projects where
requirements are very well understood & fixed.
Advantages of waterfall model
37

•Once an application is in the testing stage, it is
very difficult to go back and change some thing
that was not well-thought out in the concept
stage.
No working software is produced until late
during the life cycle.
Not a good model for complex and object-
oriented projects.
Poor model for long and ongoing projects.
Notsuitablefortheprojectswhererequirementsa
reatamoderatetohighriskofchanging.
38

When to use the waterfall model: [For Ref.]
This model is used only when the requirements are very well
known, clear and fixed. (asked in last exam examination)
Product definition is stable.
Technology is under stood.
There are no ambiguous requirements
sufficient resources with required expertise are available
freely
The project is short /small.
39

(2) INCREMENTAL PROCESS MODELS
40

Introduction:
There are many situations in which initial software requirements
are reasonably well defined, but the overall scope of the
development effort prevents a purely linear process.
In addition, there may be a forceful need to provide a limited set
of software functionality to users quickly and then refine and
expand on that functionality in later software releases.
In such cases, you can choose a process model that is designed to
produce the software in increments.
INCREMENTAL PROCESS MODELS...
41

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.
For example, word-processing software developed using the
incremental paradigm might deliver 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; and advanced page layout capability in the fourth
increment.
42

 The core product is used by the customer (or under goes
detailed evaluation). As a result of use and/ or evaluation 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.
 This process is repeated following the delivery of each
increment, until the complete product is produced.
 When an incremental model is used, the first increment is
often a core product. That is, basic requirements are
addressed but many supplementary features (some known,
others unknown) remain undelivered.
43

 Incremental development is particularly useful when staffing is
unavailable for a complete implementation by the business
deadline that has been established for the project.
 Early increments can be implemented with fewer people. If the
core product is well received, then additional staff (if required) can
be added to implement the next increment
44

 Generates working software quickly and early
during the software life cycle.
 This model is more flexible–less costly to change
scope and requirements.
 It is easier to test and debug during a smaller
iteration.
In this model customer can respond to each built.
Lowers initial delivery cost.
Easier to manage risk because risky pieces are
identified and handled during it’s iteration
45

 Needs good planning and design.
 Needs a clear and complete definition of
the whole system before
 it can be broken down and built
incrementally.
 Total cost is higher than waterfall.
46

When to use the Incremental model:[for refer.]
 This model can be used when the requirements of the complete
system are clearly defined and understood.
 Major requirements must be defined; however, some details can
evolve with time.
 There is a need to get a product to the market early.
 A new technology is being used
 Resources with needed skill set are not available
There are some high risk features and goals.
47

(3) EVOLUTIONARY PROCESS MODELS
Q: WRITE SHORT NOTE ON EVOLUTIONARY PROCESSMODELS
48

49
 Software, like all complex systems, evolves over a period of time.
 Sometimes, tight market dead lines make completion of a
comprehensive software product impossible, but a limited version
must be introduced to meet competitive or business pressure;
 A set of core product or system requirements is well understood, but
the details of product or system extensions have yet to be defined.
 In these situations, you need a process model that has been explicitly
designed to accommodate a product that evolves(develop gradually)
overtime.
 Evolutionary models are iterative. They are characterized in a
manner that enables you to develop increasingly more complete
versions of the software.
EVOLUTIONARY PROCESS MODEL...

50
There are two common evolutionary process
models:
(1) Prototyping
(2) The Spiral Model
A prototype is an early
sample, model, or release
of a product built to test a
concept or processor to
act as a thing to be
replicated or learned
from.

51
Prototyping:
Generally, 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 un sure of the efficiency of an
algorithm, the adaptability of an operating system, or the form that
human-machine inter action should take.
 In these, and many other situations, a prototyping paradigm may offer
the best approach.
 (The Prototyping Model is a systems development method (SDM) in
which a prototype (a nearly approximation of a final system or product)
is built, tested, and then reworked as necessary until an acceptable
prototype is finally achieved from which the complete system or
product can now be developed.)

52
 The prototyping paradigm (In Figure) begins with communication.
You meet with other stakeholders to define the overall objectives for
the software, identify whatever requirements are known, and out
line are as 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 format)
The quick design leads to the construction of a prototype. The
prototype is deployed and evaluated by stake holders, 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.

53
The Spiral Model:
 It is an evolutionary software process model that Proposed by Boehm AND its
is couple of 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

54
Divided into set of framework activities defined by
software engineering team
Each Framework activities represents 1 segment of spiral path
As evolutionary process begins software performs activities
implied by circuit around clockwise direction
Begins at center
Risk is considered at each revolution
Milestone: Combination of work product + conditions with spiral
model in each evolutionary process

55
o1st circuit– development of a product specification
o2nd circuit–prototype (trial product)
o3rd and rest–sophisticated versions of software
Each pass through planning: Adjustment of project plan is
done
Cost & schedule: Adjusted based on feedback of customer
after delivery
Project manager: Adjusts number of iteration to complete
software.
 1stcircuit-“concept development project” starts with core
 “New project development”- multiple iteration until project
completes
 Last spiral-represents “project enhancement project

56
The spiral development model is a risk-driven process model generator.
It has two main distinguishing features.
One is a cyclic approach for incrementally growing a system’s
degree of definition and implementation while decreasing its degree
of risk.
The other is a set of anchor point milestones for ensuring
stakeholder commitment to feasible and mutually satisfactory
system solutions.
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

57
Phases Of Spiral Model (Tasks Regions)
Customer communication-tasks required to Establish effective
communication between developer and customer.
Planning-tasks required to define resources, timelines and other
project related information.
Modeling : To prepare architectural model of software
Construction and release tasks required to construct coding, testing
Deployment : tasks required to , install, and provide user support.

58
Advantages Of Spiral Model:
The spiral model is a realistic approach to the development of
large-scale systems and software.
Estimates ( i.e. budget, schedule, etc) become more realistic as
work progresses, because more important issues are discovered
earlier.
It is more able to handle with the changes that software
development generally involve.
Disadvantages Of Spiral Model:
Highly customized limiting re-usability.
Applied differently for each application.
Risk of not meeting budget or schedule.

59
CONCURRENT MODEL…….
The concurrent development model, sometimes called concurrent
engineering.
It allows a software team to represent iterative and concurrent of the
process model.
For example, the modeling activity defined for the spiral model is
accomplished by invoking one or more of the software engineering actions:
prototyping, analysis, and design.
The activity—modeling—may be in any one of the states noted at any given
time.
Similarly, other activities, actions, or tasks (e.g., communication or
construction) can be represented in an similar manner.
All software engineering activities exist concurrently but reside in
Different states

61
 This model is suited to all types of software but is generally used for client
server applications
 In real life the software development activities do not take place in
sequence
 Most activities will be going on concurrently but reside in different states.
 The states will change when some event occurs
 So in this model all the activities are shown along with their states at any
point of time.
 As time goes on the states of the activities will change.
 It provides an accurate picture of the current state of a project. Rather than
confining software engineering activities, actions and tasks to a sequence of
events, it defines a process network. Each activity, action or task on the
network exists simultaneously with other activities, actions or tasks. Events
generated at one point trigger transitions among the states.

62
It defines software engineering as a network of activities
each in a different state, each dependent on one another
and each going on concurrently.
Definition:
 None state– while initial communication is carried out(modeling
activity)
 Under development state– after the communication is
completed.
 Awaiting changes state– if any changes in the requirement must
be made

63
 For example, early in a project the communication activity (not shown in
the figure) has completed its first iteration and exists in the awaiting
changes state.
 The modelling activity (which existed in the in active state while initial
communication was completed, now makes a transition in to 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 in to the awaiting changes state.
 Concurrent modeling defines a series of events that will trigger
transitions from state to state for each of the software engineering
activities, actions, or tasks

64
GTU Examination questions…

65
 What do you under stand by evolutionary process models. Explain Spiral
model in detail.[04]
 Define the term software process model. Compare the spiral models of
software development with prototyping model. [07]
 Explain the waterfall process model in detail. Why does a waterfall model
fail at times ?[07]
 Explain waterfall and spiral process model. List the differences between
them.[07]
 What do you mean by “Software Engineering”. Write a brief note on
Prescriptive Process Models.[06]
 Explain incremental model for system development. Differentiate it with
spiral model.[07]
 Define “Software Engineering” in your words. Explain Cyclic and anchor
point milestone related to Bo hem’s Spiral model.[07]

66
Chapter :3
Agile Development
[3.3, 3.4, 3.5.1, 3.5.2]

67
Agile means swift, alert, responsive(able to move quickly and easily )
 Agile is a time boxed, iterative approach to software delivery that
builds software incrementally from the start of the project, instead
of trying to deliver it all at once near the end.

68
 It is related to method of Project Management.
 Used especially for software development, that is characterized by the
division of tasks in to short phases of work and frequent reassessment
and adaptation of plans.
 "agile methods replace high-level design with frequent redesign“.
 Agility is more than an effective response to change It encourages
team structures and attitudes that make communication (among team
members, between technologists and business people, between
software engineers and their managers) more facile(easily).
 Agility can be applied to any software process.
 An agile process reduces the cost of change because software is
released in increments and change can be better controlled with in an
increment

69
 Any agile software process is characterized in a manner that
addresses a number of key assumptions about the majority of
software projects:
 It is difficult to predict in advance which software requirements
will persist and which will change. It is equally difficult to predict
how customer priorities will change as the project proceeds.
For many types of software, design and construction are
interleaved. That is, both activities should be performed in cycle so
that design models are proven as they are created. It is difficult to
predict how much design is necessary before construction is used to
prove the design.
 Analysis, design, construction, and testing are not as predictable
(from a planning point of view)as we might like.

70
 Given these three assumptions, an important question arises: How do
we create a process that can manage un predictability? The answer, as,
lies in process adaptability (to rapidly changing project and technical
conditions ). An agile process, therefore, must be adaptable.
 Ref: Agile development is an alternative to traditional project
management where emphasis is placed on empowering people to
collaborate and make team decisions in addition to continuous
planning, continuous testing and continuous integration…..

71
Agility principles for those who want to achieve agility:
 1. Customer Satisfaction - Our highest priority is to satisfy the customer
through early and continuous delivery of valuable software.
 2. Welcome Change - Welcome changing requirements, even late in
development. Agile processes control change for the customer’s competitive
advantage.
 3. Deliver a Working Software - Deliver working software frequently, from
a couple of weeks to a couple of months, with a preference to the shorter
time scale.
 4. Collaboration - Business people and developers must work together
daily through out the project.
 5. Motivation - Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the job done.

72
 6. Face-to-face Conversation - The most efficient and effective method of
conveying information to and with in a development team is face-to-face
conversation.
 7. Measure the Progress as per the Working Software - Working software is
the primary measure of progress.
 8. Maintain Constant Pace - Agile processes promote sustainable
development.
 9. Monitoring - Continuous attention to technical excellence and good design
enhances agility.
 10. Simplicity- the art of maximizing the amount of work not done—is
essential.
 11. Self-organized Teams- The best architectures, requirements and designs
materialize from self–organizing teams.
 12. Review the Work Regularly - At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts its behaviour accordingly.

73
Not every agile process model applies these 12 principles with equal weight,
and some models choose to ignore the importance of one or more of the
principles.
However, the principles define an agile spirit that is maintained in each of the
process models

74
 There is considerable debate about the benefits and applicability of agile
software development as opposed to more conventional software
engineering processes.
 Like all software technology arguments, this methodology debate risks
degenerating in to a religious war. If warfare breaks out, rational thought
disappears and beliefs rather than facts guide decision making.
 You don’t have to choose between agility and software engineering.
Rather, define a software engineering approach that is agile.
There are no absolute answers to either of these questions. Even with in
the agile school itself, there are many proposed process models each with a
cleverly different approach to the agility problem. With in each model there
is a set of “ideas that represent a significant departure from traditional
software engineering.

75
 Proponents (supporters) of agile software development take great pains to
emphasize the importance of “people factors.”
 “Agile development focuses on the talents and skills of individuals, molding
the process to specific people and teams.”
 A number of key characteristic must exist among the people on an agile
team and the team itself:
FACTORS:
1.Competence (skill, capability):
In an agile development context, “competence” encompasses (includes) innate (natural)
talent, specific software-related skills, and over all knowledge of the process that the team
has chosen to apply.
2.Common Focus:
Although members of the agile team may perform different tasks and bring different skills
to the project, all should be focused on one goal—to deliver a working software increment
to the customer with in the time promised. To achieve this goal, the team will also focus on
continual adaptations (small and large) that will make the process fit the needs of the team

76
3. Collaboration:
Software engineering is about assessing, analyzing, and using
information that is communicated to the software team; creating
information and building information that provides business value
for project and the customer. To accomplish the set asks,
team members must collaborate—with one another and all other
stake holders.
4. Decision-making ability:
Any good software team (including agile teams) must be allowed
the freedom to control its own destiny. This implies that the
team is given autonomy (analysis or inspection)—decision-
making authority for both technical and project issues.
5. Fuzzy (unclear) problem-solving ability:
Software managers must recognize that the agile team will
continually have to deal with ambiguity and will continually
be buffeted (trouble) by change. Lessons learned from any
problem-solving activity may be of benefit to the team later in
the project

77
6.Mutual trust and respect:
The agile team must become “jelled (together)” team which exhibits
the trust and respect that are necessary to make them “so strongly
knit(join) that the whole is greater than the sum of the parts.”
7.Self-Organization:
Self-organization implies three things:
(1) the agile team organizes itself for the work to be done,
(2) the agile team organizes the process to best accommodate its
local environment,
(3) the team organizes the work schedule to best achieve (complete)
delivery of the software increment.

78
 There are various methodologies that are collectively known as agile, as
they promote the values of the agile consists to and they are consistent
with the principles. The most popular ones are:
DSDM (Dynamic Systems Development Method) is probably the original
agile development method.
 Scrum is also an agile development method, which concentrates
particularly on how to manage tasks with in a team-based development
environment.
 XP (Extreme Programming) is a more radical (fundamental) agile
methodology, focusing more on the software engineering process and
addressing the analysis, development and test phases with novel (new)
approaches that make a substantial (important) difference to the quality
of the end product.

79
 It is the most widely used approach to agile software development.
 More recently, a variant of XP, called Industrial XP (IXP) has been
proposed.IXP refines XP and targets the agile process specifically for use
within large organizations.
 XP Values:
set of five values that establish a foundation for all work
performed as part of XP.
•Communication,
•Simplicity,
•Feedback,
•Courage,
•Respect.
 Each of these values is used as a driver for specific XP activities,
actions, and tasks.

80
 XP Programming Values (in detail..)
Communication:
In order to achieve effective communication between software
engineers and other stakeholders (e.g., to establish required features
and functions for the software), XP emphasizes close,
Informal (verbal) collaboration between customers and developers,
The establishment of effective metaphor for communicating
important concepts
Continuous feedback, and the avoidance of large documentation as a
communication medium.
In the XP context, the metaphor is “A story that everyone – customers,
programmers, and managers – can tell about how the system works..”

81
Simplicity:
 To achieve simplicity, XP restricts developers to design only for immediate
needs, rather than consider future needs.
 The objective is to create a simple design that can be easily implemented
in code. If the design must be improved, it can be refactored at a later
time.
Feedback is derived from three sources:
 The implemented software itself,
 The customer,
 Other software team members.
By designing and implementing an effective testing strategy (Chapters17),
the software (via test results) provides the agile team with feedback.
XP makes use of the unit test as its primary testing method.

82
A better word might be discipline.
 For example, there is often significant pressure to design for future
requirements. Most software teams arguing that “designing for tomorrow” will
save time and effort in the long run.
 An agile XP team must have the discipline (courage) to design for today,
recognizing that future requirements may change dramatically, thereby
demanding substantial rework of the design and implemented code.
Respect :
 By following each of these values, the agile team impress respect among it
members, between other stakeholders and team members, and indirectly, for the
software itself.
 As they achieve successful delivery of software increments, the team develops
growing respect for the XP process.

84
 Extreme Programming uses an object-oriented approach.
 As its preferred development paradigm and includes a set of
rules and practices that occur within the context of four frame
work activities:
 Planning,
 Design,
 Coding,
 Testing.

85
PLANNING :
 The planning activity (also called the planning game) begins with listening—a
requirements gathering activity that enables the technical members of the XP
team to understand the business context for the software and feel for
required output and major features and functionality.
 Listening leads to the creation of a set of “stories” (also called user stories)
that describe required output, features, and functionality for software to be
built.
 The customer assigns a value (i.e., a priority) to the story based on the
overall business value of the feature or function.
 Members of the XP team then assess each story and assign a cost—measured
in development weeks—to it. If the story is estimated to require more than
three development weeks, the customer is asked to split the story in to
smaller stories and the assignment of value and cost occurs again.

86
Customers and developers work together to decide how to group stories in
to the next release (the next software increment) to be developed by the XP
team.
 Once a basic commitment (agreement on stories to be included, delivery
date, and other project matters) is made for a release, the XP team orders the
stories that will be developed in one of three ways:
 (1) All stories will be implemented immediately (within a few weeks),
 (2) The stories with highest value will be moved up in the schedule and
implemented first,
 (3) The riskiest stories will be moved up in the schedule and implemented
first.
 After the first project release (also called a software increment) has been
delivered, the XP team computes project velocity.
 Project velocity is the number of customer stories implemented during the
first release

87
 DESIGN:
 XP design strictly follows the KIS (keep it simple)principle.
A simple design is always preferred over a more complex representation.
In addition, the design provides implementation guidance for a story as it is
written—nothing less, nothing more.
XP encourages the use of CRC cards (Class-responsibility Collaborator) (Chapter7)
as an effective mechanism for thinking about the software in an object-oriented
context.
 CRC cards identify and organize the object-oriented classes that are relevant to the
current software increment.
 A central notion in XP is that design occurs both before and after coding
commences.
 Refactoring means that, design occurs continuously as the system is constructed.
In fact, the construction activity itself will provide the XP team with guidance on
how to improve the design.

89
 CODING :
 After stories are developed and preliminary design work is done,
the team does not move to code, but rather develops a series of
unit tests that will exercise each of the stories that is to be included
in the current release (software increment).
 Once the unit test has been created, the developer is better able
to focus on what must be implemented to pass the test.
Once the code is complete, it can be unit-tested immediately, there
by providing instantaneous feed back to the developers.

90
Key concept during the coding activity in XP is pair programming.
 XP recommends that two people work together at one computer work
station to create code for a story. This provides a mechanism for real
time problem solving real-time quality assurance (the code is reviewed
as it is created).
 It also keeps the developers focused on the problem at hand. In
practice, each person takes on as lightly different role.
 For example, one person might think about the coding details of a
particular portion of the design while the other ensures that coding
standards (a required part of XP) are being followed or that the code for
the story will satisfy the unit test that has been developed to validate
the code against the story.

91
What is Pair Programming?
 Pair programming (sometimes referred
to as peer programming) is an agile
software development technique in which
two programmers work as a pair
together on one workstation. One, the
driver, writes code while the other, the
observer, pointer or navigator, reviews
each line of code as it is typed in…

92
 TESTING:
The creation of unit tests before coding commences is a key element of
the XP approach.
As the individual unit tests are organized in to a “universal testing suite”
[Wel99], integration and validation testing of the system can occur on a
daily basis. This provides the XP team with a continual indication of
progress and also can raise warning flags early if things go wrong.
 Wells [Wel99] states:“ Fixing small problems every few hours takes less
time than fixing huge problems just before the dead line.”
 XP acceptance tests, also called customer tests, are specified by the
customer and focus on over all system features and functionality that are
visible and review able by the customer

93
 The most widely used of all agile process models is Extreme Programming
(XP). But many other agile process models have been proposed and are in
use across the industry. Among the most common are
 Adaptive Software Development(ASD)
 Scrum
 Dynamic Systems Development Method(DSDM)
 Crystal
 Feature Drive Development(FDD)
 Lean Software Development(LSD)
 Agile Modeling(AM)
 Agile Unified Process(AUP)

94
 Adaptive Software Development (ASD) has been proposed by Jim
Highsmith [Hig00] as a technique for building complex software and
systems.
 The philosophical underpinnings of ASD focus on human
collaboration and team self-organization.
 ASD “life cycle” (Figure on next slide) that incorporates three phases,
SPECULATION, (ASSUMPTION)
 COLLABORATION (GROUP EFFORT)
LEARNING

96
SPECULATION: is to assume that all stakeholders are comparably
wrong for certain aspects of the project’s mission, while trying to define it.
 During speculation, The project is initiated and adaptive cycle planning is
conducted.
 Adaptive cycle planning uses project initiation information—
 The customer’s mission statement,
 Project constraints (e.g., delivery dates or user descriptions),
 Basic requirements –to define the set of release cycles (software
increments) that will be required for the project.
Based on information obtained at the completion of the first cycle, the
plan is reviewed and adjusted so that planned work better fits the reality
in which an ASD team is working.

97
COLLABORATION:
Motivated people use collaboration in a way that multiplies their
talent and creative output beyond their absolute numbers.
This approach is a recurring theme in all agile methods. But
collaboration is not easy.
 It includes communication and team work, but it also emphasizes
individualism, because individual creativity plays an important role
in collaborative thinking. It is, above all, a matter of trust.

98
LEARNING:
 As members of an ASD team begin to develop the components that
are part of an adaptive cycle, the emphasis is on “learning” as much
as it is on progress toward a completed cycle.
 In fact, software developers often overestimate their own
understanding (of the technology, the process, and the project) and
that learning will help them to improve their level of real
understanding.
 ASD teams learn in three ways: focus groups (Chapter5), technical
reviews (Chapter14), and project post-mortems.

99
Introduction:
Scrum is an iterative and incremental agile software development
frame work for managing product development.
 It defines "a flexible product development strategy where a
development team works as a unit to reach a common goal“.
 It incorporates the following frame work activities:
requirements , analysis, design, evolution, and delivery.
 With in each framework activity, work tasks occur with in a process
pattern is called sprint.

102
 Backlog (collection of un completed
work)
 A prioritized list of project requirements
or features that provide business value for
the customer.
 Items can be added to the backlog at
any time. The product manager assesses
the backlog and updates priorities as
required

103
Sprints(A scrum sprint is a regular,
repeatable work cycle):
 It consist of work units that are required
to achieve a requirement defined in the
backlog that must be fit in to a predefined
time-box (typically 30 days).
 Changes (e.g., backlog work items) are
not introduced during the sprint. Hence,
the sprint allows team members to work
in a short-term, but stable environment.

104
Scrum meetings:
 It is short (typically 15 minutes) meetings held daily by the Scrum
team. Three key questions are asked and answered by all team
members:
 What did you do since the last team meeting?
 What problems are you encountering?
 What do you plan to accomplish by the next team meeting?
 A team leader, called a Scrum master, leads the meeting and
assesses the responses from each person. The Scrum meeting helps
the team

105
Demos:
 Delivers the software increment to the customer so that
functionality that has been implemented can be demonstrated and
evaluated by the customer.
 It is important to note that the demo may not contain all planned
functionality, but rather those functions that can be delivered with in
the time –box that was established.
 Scrum process patterns enable a software team to work
successfully in a world where the elimination of uncertainty is
impossible.

106
 Explain term : Scrum[02]
 Define term : Agile process[02]
 Write short note on Adaptive Software Development (ASD)[04]
 Explain the following terms in brief :[04]
(i) Phases of Extreme Programming (XP) (ii)Scrum
 Write a short note in context of agile process:[07]
1) Extreme programming
2) Scrum
 In XP activity how many types of Values are consider?[04]
 Write any 4 Issues that are continue to trouble in Extreme Programming.[3]
FINAL EXAM QUESTIONS

Software Engineering

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Software Engineering

Similar to Software Engineering (20)

More from Jignesh Kariya

More from Jignesh Kariya (15)

Recently uploaded

Recently uploaded (20)

Software Engineering