Module 1

Introduction to software Engineering process Models

1.1 Software Engineering Process Framework, Capability Maturity Model (CMM)
Advanced Trends in Software Engineering
1.2 Prescriptive Models: Waterfall Model, Incremental Model
Evolutionary Process Model Spiral and RAD Model
1.3 Agile Process Model: Extreme Programming (XP), Scrum ,Kanban model

Software Process
● A process is a collection of activities, actions, and tasks that are performed when some
work product is to be created.
● An activity strives to achieve a broad objective (e.g.communication with stakeholders)
and is applied regardless of the application domain, size of the project, complexity of
the effort, or degree of rigor with which software engineering is to be applied.
● An action (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.

1.1 Software Engineering Process Framework

A process was 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 within a framework or model that
defines their relationship with the process and with one another.
● The software process is represented schematically in Figure 2.1.

1
A generic process framework for software engineering defines five framework
activities—communication, planning, modeling, construction, and deployment.
● Communication- Before any technical work can commence, it is critically important to
communicate and collaborate with the customer (and other stakeholders). The intent is
to understand stakeholders’ objectives for the project and to gather requirements that
help define software features and functions.
● Planning- Any complicated journey can be simplified if a map exists. A software
project is a complicated journey, and the planning activity creates a “map” that helps
guide the team as it makes the journey. The map—called a software project
plan—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.
● Modeling- Whether you’re a landscaper, a bridge builder, an aeronautical engineer, a
carpenter, or an architect, you work with models every day. You create a “sketch” of the
thing so that you’ll understand the big picture—what it will look like architecturally,
how the constituent parts fit together, and many other characteristics. If required, you
refine the sketch into greater and greater detail in an effort to better understand the
problem and how you’re going to solve it. 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.
2
 ● 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

Process flow—describes how the framework activities and the actions and tasks that occur
within each framework activity are organized with respect to sequence and time and is
illustrated in Figure 2.2.

● A linear process flow executes each of the five framework activities in sequence,
beginning with communication and culminating with deployment (Figure 2.2a).
● An iterative process flow repeats one or more of the activities before proceeding to the
next (Figure 2.2b).
● 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
(Figure 2.2c).
● A parallel process flow (Figure 2.2d) 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).

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

1.1 Capability Maturity Model (CMM)

● A maturity model is applied within the context of an SPI (Software Process
Improvement) framework.
● The intent of the maturity model is to provide an overall indication of the “process
maturity” exhibited by a software organization. That is, an indication of the quality of
the software process, the degree to which practitioner’s understand and apply the
process, and the general state of software engineering practice.
● This is accomplished using some type of ordinal scale.
The Software Engineering Institute’s Capability Maturity Model suggests five levels of
maturity-
● Level 1, Initial—Few processes are defined, and success depends more on individual
heroic efforts than on following a process and using a synergistic team effort.
● Level 2, Repeatable—Basic project management processes are established to track
cost, schedule, and functionality. Planning and managing new products is based on
experience with similar projects.
● Level 3, Defined—Processes for management and engineering are documented,
standardized, and integrated into a standard software process for the organization. All

4
 projects use an approved, tailored version of the organization’s standard software
process for developing software.
● Level 4, Managed—Detailed software process and product quality metrics establish the
quantitative evaluation foundation. Meaningful variations in process performance can
be distinguished from random noise, and trends in process and product qualities can be
predicted.
● Level 5, Optimized—The organization has quantitative feedback systems in place to
identify process weaknesses and strengthen them proactively. Project teams analyze
defects to determine their causes; software processes are evaluated and updated to
prevent known types of defects from recurring.

● The original CMM was developed and upgraded by the Software Engineering Institute
throughout the 1990s as a complete SPI framework.
● Today, it has evolved into the Capability Maturity Model Integration (CMMI), a
comprehensive process meta-model that is predicated on a set of system and software
engineering capabilities that should be present as organizations reach different levels of
process capability and maturity.
● The CMMI represents a process meta-model in two different ways:
(1) as a “continuous” model and
(2) as a “staged” model.
● The continuous CMMI meta-model describes a process in two dimensions as illustrated
in Figure 30.2.

● Each process area (e.g., project planning or requirements management) is formally

assessed against specific goals and practices and is rated according to the following
capability levels:
● Level 0: Incomplete—the process area (e.g., requirements management) is either not
performed or does not achieve all goals and objectives defined by the CMMI for level 1
capability for the process area.

5
 ● Level 1: Performed—all of the specific goals of the process area (as defined by the
CMMI) have been satisfied. Work tasks required to produce defined work products are
being conducted.
● Level 2: Managed—all capability level 1 criteria have been satisfied. In addition, all
work associated with the process area conforms to an organizationally defined policy;
all people doing the work have access to adequate resources to get the job done;
stakeholders are actively involved in the process area as required; all work tasks and
work products are “monitored, controlled, and reviewed; and are evaluated for
adherence to the process description”.
● Level 3: Defined—all capability level 2 criteria have been achieved. In addition, the
process is “tailored from the organization’s set of standard processes according to the
organization’s tailoring guidelines, and contributes work products, measures, and other
process-improvement information to the organizational process assets”.
● Level 4: Quantitatively managed—all capability level 3 criteria have been achieved.
In addition, the process area is controlled and improved using measurement and
quantitative assessment. “Quantitative objectives for quality and process performance
are established and used as criteria in managing the process”.
● Level 5: Optimized—all capability level 4 criteria have been achieved. In addition, the
process area is adapted and optimized using quantitative (statistical) means to meet
changing customer needs and to continually improve the efficacy of the process area
under consideration.

1.2 Prescriptive Models: Waterfall Model, Incremental Model

● Prescriptive process models were originally proposed to bring order to the chaos of
software development.
● History has indicated that these traditional models have brought a certain amount of
useful structure to software engineering work and have provided a reasonably effective
road map for software teams.
● However, software engineering work and the product that it produces remain on “the
edge of chaos.”

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 (e.g., an adaptation to accounting
software that has been mandated because of changes to government regulations).
● It may also occur in a limited number of new development efforts, but only when
requirements are well defined and reasonably stable.

6
 ● The waterfall model, sometimes called the classic life cycle, suggests a systematic,
sequential approach to software development that begins with customer specification of
requirements and progresses through planning, modeling, construction, and
deployment, culminating in ongoing support of the completed software (Figure 2.3)

● A variation in the representation of the waterfall model is called the V-model.

● Represented in Figure 2.4, the V-model depicts the relationship of quality assurance
actions to the actions associated with communication, modeling, and early construction
activities.

● As a software team moves down the left side of the V, basic problem requirements are
refined into progressively more detailed and technical representations of the problem
and its solution.
● Once code has been generated, the team moves up the right side of the V, essentially
performing a series of tests (quality assurance actions) that validate each of the models
created as the team moved down the left side.
● In reality, there is no fundamental difference between the classic life cycle and the
V-model.
● The V-model provides a way of visualizing how verification and validation actions are
applied to earlier engineering work.
● The waterfall model is the oldest paradigm for software engineering.
The problems that are sometimes encountered when the waterfall model is applied are:
7
 1. Real projects rarely follow the sequential flow that the model proposes. Although the
linear model can accommodate iteration, it does so indirectly. As a result, changes can
cause confusion as the project team proceeds.
2. It is often difficult for the customer to state all requirements explicitly. The waterfall
model requires this and has difficulty accommodating the natural uncertainty that exists
at the beginning of many projects.
3. The customer must have patience. A working version of the program(s) will not be
available until late in the project time span. A major blunder, if undetected until the
working program is reviewed, can be disastrous.
● The linear nature of the classic life cycle leads to “blocking states” in which some
project team members must wait for other members of the team to complete dependent
tasks.
● In fact, the time spent waiting can exceed the time spent on productive work!
● The blocking states tend to be more prevalent at the beginning and end of a linear
sequential process.
● Today, software work is fast-paced and subject to a never-ending stream of changes (to
features, functions, and information content). The waterfall model is often inappropriate
for such work.
● However, it can serve as a useful process model in situations where requirements are
fixed and work is to proceed to completion in a linear manner.

Incremental Process Models

● There are many situations in which initial software requirements are reasonably well
defined, but the overall scope of the development effort precludes a purely linear
process.
● In addition, there may be a compelling 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.
● The incremental model combines elements of linear and parallel process flows.
● Referring to Figure 2.5, the incremental model applies linear sequences in a staggered
fashion as calendar time progresses.

8
● Each linear sequence produces deliverable “increments” of the software in a manner
that is similar to the increments produced by an evolutionary process flow.
● 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.
● It should be noted that the process flow for any increment can incorporate the
prototyping paradigm.
● 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.
● The core product is used by the customer (or undergoes detailed evaluation).
● 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.
● This process is repeated following the delivery of each increment, until the complete
product is produced.
● The incremental process model focuses on the delivery of an operational product with
each increment.
● 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. In addition, increments can be planned to manage technical risks.
● For example, a major system might require the availability of new hardware that is
under development and whose delivery date is uncertain.

9
 ● It might be possible to plan early increments in a way that avoids the use of this
hardware, thereby enabling partial functionality to be delivered to end users without
inordinate delay.

1.3 Evolutionary Process Model- Spiral and RAD Model

Evolutionary Process Models

● Software, like all complex systems, evolves over a period of time.
● Business and product requirements often change as development proceeds, making a
straight line path to an end product unrealistic; tight market deadlines 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 and similar situations, you need a process model that has been explicitly
designed to accommodate a product that evolves over time.
● Evolutionary models are iterative.
● They are characterized in a manner that enables you to develop increasingly more
complete versions of the software.

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.
● It provides the potential for rapid development of increasingly more complete versions
of the software.
● The spiral development model is a risk-driven process model generator that is used to
guide multi-stakeholder concurrent engineering of software intensive systems.
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.
● A spiral model is divided into a set of framework activities defined by the software
engineering team.

10
● Each of the generic framework activities represent one segment of the spiral path
illustrated in Figure 2.7.

● 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.
● 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.
● 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.”

11
 ● In essence, the spiral, when characterized in this way, remains operative until the
software is retired.
● There are times when the process is dormant, but whenever a change is initiated, the
process starts at the appropriate entry point (e.g., product enhancement).
● The spiral model is a realistic approach to the development of large-scale systems and
software.
● Because 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 importantly,
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.
But like other paradigms, the spiral model is not a panacea.
● It may be difficult to convince customers (particularly in contract situations) that the
evolutionary approach is controllable.
● It demands considerable risk assessment expertise and relies on this expertise for
success.
● If a major risk is not uncovered and managed, problems will undoubtedly occur.

RAD (Rapid Application Development)

RAD is a concept that products can be developed faster and of higher quality through:

● Gathering requirements using workshops or focus groups

● Prototyping and early, reiterative user testing of designs

● The re-use of software components

● A rigidly paced schedule that refers design improvements to the next product version

● Less formality in reviews and other team communication

12
1. Business Modelling: The information flow among business functions is defined by
answering questions like what data drives the business process, what data is generated, who
generates it, where does the information go, who processes it and so on.

2. Data Modelling: The data collected from business modeling is refined into a set of data
objects (entities) that are needed to support the business. The attributes (character of each
entity) are identified, and the relation between these data objects (entities) is defined.

3. Process Modelling: The information objects defined in the data modeling phase are
transformed to achieve the data flow necessary to implement a business function. Processing
descriptions are created for adding, modifying, deleting, or retrieving a data object.

4. Application Generation: Automated tools are used to facilitate construction of the software;
even they use the 4th GL techniques.

5. Testing & Turnover: Many of the programming components have already been tested since
RAD emphasis reuse. This reduces the overall testing time. But the new part must be tested,
and all interfaces must be fully exercised.

13
Advantage of RAD Model

● This model is flexible for change.

● In this model, changes are adoptable.

● Each phase in RAD brings highest priority functionality to the customer.

Disadvantage of RAD Model

● It required highly skilled designers.

● All applications are not compatible with RAD.
● For smaller projects, we cannot use the RAD model.
● On the high technical risk, it's not suitable.
● Required user involvement.

1.3 Agile Methodology, Agility Principles, Extreme Programming ,Scrum and & Kanban
model
Agile Methodology
● Agile software engineering combines a philosophy and a set of development guidelines.
● The philosophy encourages customer satisfaction and early incremental delivery of
software; small, highly motivated project teams; informal methods; minimal software
engineering work products; and overall development simplicity.
● The development guidelines stress delivery over analysis and design (although these
activities are not discouraged), and active and continuous communication between
developers and customers.
● Who does it? Software engineers and other project stakeholders (managers, customers,
end users) work together on an agile team—a team that is self-organizing and in control
of its own destiny.
● An agile team fosters communication and collaboration among all who serve on it.
● Why is it important? The modern business environment that spawns computer-based
systems and software products is fast-paced and ever-changing.
● Agile software engineering represents a reasonable alternative to conventional software
engineering for certain classes of software and certain types of software projects.
● It has been demonstrated to deliver successful systems quickly.
● What are the steps? Agile development might best be termed “software engineering
lite.”
● The basic framework activities—communication, planning, modeling, construction, and
deployment—remain.

14
● But they morph into a minimal task set that pushes the project team toward construction
and delivery (some would argue that this is done at the expense of problem analysis and
solution design).
● What is the work product? Both the customer and the software engineer have the
same view—the only really important work product is an operational “software
increment” that is delivered to the customer on the appropriate commitment date.
● If the agile team agrees that the process works, and the team produces deliverable
software increments that satisfy the customer, you’ve done it right.

● Any agile software process is characterized in a manner that addresses a number of key
assumptions about the majority of software projects:
1. It is difficult to predict in advance which software requirements will persist and
which will change. It is equally difficult to predict how customer priorities will change
as the project proceeds.
2. For many types of software, design and construction are interleaved. That is, both
activities should be performed in tandem so that design models are proven as they are
created. It is difficult to predict how much design is necessary before construction is
used to prove the design.
3. Analysis, design, construction, and testing are not as predictable (from a planning
point of view) as we might like.
● Given these three assumptions, an important question arises: How do we create a
process that can manage unpredictability? The answer lies in process adaptability (to
rapidly changing project and technical conditions).
● An agile process, therefore, must be adaptable.
● But continual adaptation without forward progress accomplishes little.
● Therefore, an agile software process must adapt incrementally.
● To accomplish incremental adaptation, an agile team requires customer feedback (so
that the appropriate adaptations can be made).
● An effective catalyst for customer feedback is an operational prototype or a portion of
an operational system.
● Hence, an incremental development strategy should be instituted.
● Software increments (executable prototypes or portions of an operational system) must
be delivered in short time periods so that adaptation keeps pace with change
(unpredictability).
● This iterative approach enables the customer to evaluate the software increment
regularly, provide necessary feedback to the software team, and influence the process
adaptations that are made to accommodate the feedback.

15
Agility Principles
● The Agile Alliance 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.
5. Build projects around motivated individuals. Give them the environment and support
they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, an user
should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity—the art of maximizing the amount of work not done—is essential.
11. The best architectures, requirements, and designs emerge from self–organizing
teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes
and adjusts its behavior accordingly.

Not every agile process model applies these 12 principles with equal weight, and some
models choose to ignore (or at least downplay) the importance of one or more
of the principles.

Extreme Programming (XP)

● Extreme Programming (XP), is the most widely used approach to agile software
development.
XP Values
● A set of five values that establish a foundation for all work performed as part of
XP—communication, simplicity, feedback, courage, and respect.
● 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, yet informal (verbal) collaboration between customers and
developers, the establishment of effective metaphors for communicating important
concepts, continuous feedback, and the avoidance of voluminous documentation as a
communication medium.
● To achieve simplicity, XP restricts developers to design only for immediate needs,
rather than consider future needs.
16
 ● The intent 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,
and other software team members.
● By designing and implementing an effective testing strategy, the software (via test
results) provides the agile team with feedback.
● XP makes use of the unit test as its primary testing tactic.
● As each class is developed, the team develops a unit test to exercise each operation
according to its specified functionality.
● As an increment is delivered to a customer, the user stories or use cases that are
implemented by the increment are used as a basis for acceptance tests.
● The degree to which the software implements the output, function, and behavior of the
use case is a form of feedback.
● Finally, as new requirements are derived as part of iterative planning, the team provides
the customer with rapid feedback regarding cost and schedule impact.

The XP Process
● Extreme Programming uses an object-oriented approach as its preferred development
paradigm and encompasses a set of rules and practices that occur within the context of
four framework activities: planning, design, coding, and testing.
● Figure 3.2 illustrates the XP process and notes some of the key ideas and tasks that are
associated with each framework activity.

17
Key XP activities are summarized as follows
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 to get a broad 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.
● Each story is written by the customer and is placed on an index card.
● 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 into smaller stories and the assignment of value and cost occurs
again.
● It is important to note that new stories can be written at any time.
● Customers and developers work together to decide how to group stories into 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, or (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 (the number of customer stories implemented during the
first release.)
● Project velocity can then be used to (1) help estimate delivery dates and schedule for
subsequent releases and (2) determine whether an overcommitment has been made for all
stories across the entire development project.
● If an overcommitment occurs, the content of releases is modified or end delivery dates are
changed.
● As development work proceeds, the customer can add stories, change the value
● of an existing story, split stories, or eliminate them.
● The XP team then reconsiders all remaining releases and modifies its plans accordingly.

Design
● XP design rigorously follows the KIS (keep it simple) principle.
18
● 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.
● The design of extra functionality (because the developer assumes it will be required later)
● XP encourages the use of CRC cards as an effective mechanism for thinking about the
software in an object-oriented context.
● CRC (class-responsibility-collaborator) cards identify and organize the object-oriented
classes that are relevant to the current software increment.
● The XP team conducts the design exercise.
● The CRC cards are the only design work product produced as part of the XP process.
● If a difficult design problem is encountered as part of the design of a story, XP
recommends the immediate creation of an operational prototype of that portion of the
design.
● Called a spike solution, the design prototype is implemented and evaluated.
● The intent is to lower risk when true implementation starts and to validate the original
estimates for the story containing the design problem.
● In the preceding section, we noted that XP encourages refactoring—a construction
technique that is also a method for design optimization.
● Refactoring is the process of changing a software system in such a way that it does not
alter the external behavior of the code yet improves the internal structure.
● It is a disciplined way to clean up code [and modify/simplify the internal design] that
minimizes the chances of introducing bugs.
● In essence, when you refactor you are improving the design of the code after it has been
written.
● Because XP design uses virtually no notation and produces few, if any, work products
other than CRC cards and spike solutions, design is viewed as a transient artifact that can
and should be continually modified as construction proceeds.
● The intent of refactoring is to control these modifications by suggesting small design
changes that “can radically improve the design”.
● It should be noted, however, that the effort required for refactoring can grow dramatically
as the size of an application grows.
● 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.

Coding

19
● 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.
● Nothing extraneous is added (KIS).
● Once the code is complete, it can be unit-tested immediately, thereby providing
instantaneous feedback to the developers.
● A key concept during the coding activity (and one of the most talked about aspects of XP)
is pair programming.
● XP recommends that two people work together at one computer workstation to create
code for a story.
● This provides a mechanism for real-time problem solving (two heads are often better than
one) and 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 a slightly 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.
● As pair programmers complete their work, the code they develop is integrated with the
work of others.
● In some cases this is performed on a daily basis by an integration team. In other cases, the
pair programmers have integration responsibility.
● This “continuous integration” strategy helps to avoid compatibility and interfacing
problems and provides a “smoke testing” environment that helps to uncover errors early.

Testing
● The unit tests that are created should be implemented using a framework that enables them
to be automated (hence, they can be executed easily and repeatedly).
● This encourages a regression testing strategy whenever code is modified (which is often,
given the XP refactoring philosophy).
● As the individual unit tests are organized into a “universal testing suite” 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 awry.
● Wells [Wel99] states: “Fixing small problems every few hours takes less time than fixing
huge problems just before the deadline.”
● XP acceptance tests, also called customer tests, are specified by the customer and focus on
overall system features and functionality that are visible and reviewable by the customer.

20
● Acceptance tests are derived from user stories that have been implemented as part of a
software release.

Scrum
● Scrum (the name is derived from an activity that occurs during a rugby match) is an
agile software development method that was conceived by Jeff Sutherland and his
development team in the early 1990s.
● Scrum principles are consistent with the agile manifesto and are used to guide
development activities within a process that incorporates the following framework
activities: requirements, analysis, design, evolution, and delivery.
● Within each framework activity, work tasks occur within a process pattern (discussed in
the following paragraph) called a sprint.
● The work conducted within a sprint (the number of sprints required for each framework
activity will vary depending on product complexity and size) is adapted to the problem
at hand and is defined and often modified in real time by the Scrum team.
● The overall flow of the Scrum process is illustrated in Figure 3.4

● Scrum emphasizes the use of a set of software process patterns that have proven
effective for projects with tight timelines, changing requirements, and business
criticality.
● Each of these process patterns defines a set of development actions:

21
 Backlog—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 (this is how
changes are introduced). The product manager assesses the backlog and updates
priorities as required.
Sprints—consist of work units that are required to achieve a requirement defined in the
backlog that must be fit into a predefined time-box. 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.
Scrum meetings—are 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 obstacles 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 to uncover potential problems as early as possible.
● Also, these daily meetings lead to “knowledge socialization” and thereby promote a
self-organizing team structure.
● Demos—deliver 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 within the time-box that was established.
● The Scrum process patterns enable a software team to work successfully in a world
where the elimination of uncertainty is impossible.

Kanban model
● Kanban is a popular framework which is used to implement agile software development. It
takes real time communication of capacity and complete transparency of work. The work
items are represented in a kanban board visually, allowing team members to see the state of
every piece of work at any time.
● Kanban Boards- The kanban board is the agile project management tool that designs the
necessary visualized work, limited work-in-progress, and maximizes flow (or efficiency).
It uses cards, columns, and provides continuous improvement to help technology and
service teams who commit the right amount of work and get it done.he Kanban board −
● Provides easy access to everyone involved in the project.
● Facilitates communication as and when necessary.
● Progress of the tasks are visually displayed.
● Bottlenecks are visible as soon as they occur.
● Elements of a kanban board
● A person called David Anderson divides the kanban board into five different components.
22
● These are Visual signals, columns, work-in-progress limits, a commitment point, and a
delivery point.

Visual Signals: The kanban board is a visual card (stickies, tickets, or otherwise). Kanban
team write their projects and work items onto cards, usually per person each card. For agile
teams, each card could be encapsulated into one user story. Once the board is completed,
this visual team helps team members and stock members quickly to understand what the
team is working on.

Columns: The column represents the specific activities that compose a "workflow" together.
The card flows through a workflow until its completion. The workflow may be as simple
as "To Do," "In Progress," "Complete," or much more complicated.

Work in progress (WIP) Limits: The work in progress limits are the maximum number of
cards which can be in one column. This is at any given time. It gives the alert signal that
you committed too much work.

Commitment point: Kanban teams also maintain a backlog for their board. This is where the
customers and team members put ideas for projects that the team can pick up. The team
members pick up plans when they are ready. The committed point is a movement where the
design is picked up by the team, and work starts on the project.

Delivery point: It is the end point of a kanban team's workflow. Mostly the delivery point for
every team is when the product and services are handed to the customer.

● Advantages of Kanban board

● Empowerment of Team −
Team is allowed to take decisions as and when required.
Team collaboratively resolves the bottlenecks.
Team has access to the relevant information.
Team continually communicates with customers.
● Continuous Delivery −
Focus on work completion.
Limited requirements at any point of time.
Focus on delivering value to the customer.
Emphasis on the whole project.

23
● Kanban vs Scrum board
The following are the differences between Kanban and Scrum board:
Kanban Scrum

Kanban is an ongoing process. Scrum sprints have a start and stop dates

Kanban has no formal roles. Role is clearly defined for each team in the

scrum (product owner, development team, and

scrum master). Both teams are self-organized.

A kanban board is used throughout the lifecycle of Scrum board is cleared and recycled after each

a project sprint.

This board is more flexible with regards to tasks This board has the number of tasks and a strict

and timing. Its task can be reprioritized, deadline to complete them.

reassigned, or updated as needed.

24