Software Engineering

Introduction
• Software is part of almost all business operations
so new software is developed quickly to take
advantage of new opportunities and to respond to
competitive pressure.
• Rapid development and delivery is therefore now
often the most critical requirement for software
systems.

Coming up: An Agile Process 2

 Introduction
• Software development processes that plan on
completely specifying the requirements and then
designing, building, and testing the system are not
geared to rapid software development.
• As the requirements change or as requirements
problems are discovered, the system design or
implementation has to be reworked and retested.
As a consequence, a conventional waterfall or
specification-based process is usually prolonged
and the final software is delivered to the customer
long after it was originally specified.

Coming up: An Agile Process 3

 Introduction
• For some types of software, such as safety-critical
control systems, where a complete analysis of the
system is essential, a plan-driven approach is the
right one.
• However, in a fast-moving business environment,
this can cause real problems. By the time the
software is available for use, the original reason for
its procurement may have changed so radically
that the software is effectively useless.

Coming up: An Agile Process 4

 Introduction
• Rapid software development processes are
designed to produce useful software quickly.
• The software is not developed as a single unit but
as a series of increments, with each increment
including new system functionality.
• Although there are many approaches to rapid
software development, they share some
fundamental characteristics.

Coming up: An Agile Process 5

 Introduction
• Agile methods are incremental development
methods in which the increments are small and,
typically, new releases of the system are created
and made available to customers every two or
three weeks.
• They involve customers in the development
process to get rapid feedback on changing
requirements.
• They minimize documentation by using informal
communications rather than formal meetings with
written documents.

Coming up: An Agile Process 6

 Agile methods
• The philosophy behind agile methods is reflected in
the agile manifesto that was agreed on by many of
the leading developers of these methods. This
manifesto states:
• We are uncovering better ways of developing software by doing it
and helping others do it.
• Through this work we have come to value:
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
• That is, while there is value in the items on the right, we value the
items on the left more.

Coming up: An Agile Process 7

 Agile methods
• Agile methods have been very successful for some
types of system development.
• 1. Product development where a software company
is developing a small or medium-sized product for
sale.
• 2. Custom system development within an
organization, where there is a clear commitment
from the customer to become involved in the
development process and where there are not a lot
of external rules and regulations that affect the
software.

Coming up: An Agile Process 8

Agile Method

Coming up: An Agile Process 9

 Plan-driven VS agile development
• Agile approaches to software development consider
design and implementation to be the central
activities in the software process.
• They incorporate other activities, such as
requirements elicitation and testing, into design and
implementation.
• By contrast, a plan-driven approach to software
engineering identifies separate stages in the
software process with outputs associated with each
stage.
• The outputs from one stage are used as a basis for
planning the following process activity
Coming up: An Agile Process 10
 Plan-driven VS agile development
• In a plan-driven approach, iteration occurs within
activities with formal documents used to
communicate between stages of the process.
• For example, the requirements will evolve and,
ultimately, a requirements specification will be
produced.
• This is then an input to the design and
implementation process.
• In an agile approach, iteration occurs across
activities. Therefore, the requirements and the
design are developed together, rather than
separately.
Coming up: An Agile Process 11
Plan-driven VS agile development

Coming up: An Agile Process 12

 Plan-driven VS agile development
• 1. Is it important to have a very detailed
specification and design before moving to
implementation? If so, you probably need to use a
plan-driven approach.
• 2. Is an incremental delivery strategy, where you
deliver the software to customers and get rapid
feedback from them, If so, consider using agile
methods.
• 3. How large is the system that is being
developed? Agile methods are most effective when
the system can be developed with a small co-
located team who can communicate informally.
Coming up: An Agile Process 13
 Plan-driven VS agile development
• 4. What type of system is being developed?
Systems that require a lot of analysis before
implementation (e.g., real-time system with
complex timing requirements) usually need a fairly
detailed design to carry out this analysis. A plan
driven approach may be best in those
circumstances.
• 5. What technologies are available to support
system development? Agile methods often rely on
good tools to keep track of an evolving design.

Coming up: An Agile Process 14

 Plan-driven VS agile development
• 6. How is the development team organized? If the
development team is distributed or if part of the
development is being outsourced, then you may
need to develop design documents to
communicate across the development teams.
• 7. How good are the designers and programmers
in the development team? It is sometimes argued
that agile methods require higher skill levels than
plan-based approaches in which programmers
simply translate a detailed design into code.

Coming up: An Agile Process 15

 Extreme Programming (XP)
• Extreme programming (XP) is perhaps the best
known and most widely used of the agile methods.
• In extreme programming, requirements are
expressed as scenarios (called user stories), which
are implemented directly as a series of tasks.
• Programmers work in pairs and develop tests for
each task before writing the code.
• All tests must be successfully executed when new
code is integrated into the system.

Coming up: An Agile Process 16

Extreme Programming (XP)

Coming up: An Agile Process 17

 Extreme Programming (XP)
• Extreme programming involves a number of
practices.
• 1. Incremental development is supported through
small, frequent releases of the system.
Requirements are based on simple customer
stories.
• 2. Customer involvement is supported through the
continuous engagement of the customer in the
development team.
• 3. People, not process, are supported through pair
programming

Coming up: An Agile Process 18

 Extreme Programming (XP)
• 4. Change is embraced through regular system
releases to customers.
• 5. Maintaining simplicity is supported by constant
refactoring that improves code quality and by using
simple designs.

Coming up: An Agile Process 19

 Extreme Programming (XP)
• The story cards are the main inputs to the XP
planning process.
• Once the story cards have been developed, the
development team breaks these down into tasks and
estimates the effort and resources required for
implementing each task.
• This usually involves discussions with the customer
to refine the requirements.
• The customer then prioritizes the stories for
implementation, choosing those stories that can be
used immediately to deliver useful business support

Coming up: An Agile Process 20

 Extreme Programming (XP)
• Of course, as requirements change, the
unimplemented stories change or may be
discarded.
• If changes are required for a system that has
already been delivered, new story cards are
developed and again, the customer decides
whether these changes should have priority over
new functionality.

Coming up: An Agile Process 21

Coming up: An Agile Process 22
 Extreme Programming (XP)
• Sometimes, during the planning game, questions
that cannot be easily answered come to light and
additional work is required.
• In XP terms, this is a ‘spike’, an increment where
no programming is done.
• There may also be ‘spikes’ to design the system
architecture or to develop system documentation.
• In XP Release deadlines are never slipped; if there
are development problems, the customer is
consulted and functionality is removed from the
planned release.

Coming up: An Agile Process 23

Coming up: An Agile Process 24