SOFTWARE ENGINEERING

L T P C
BCSE301L - 3 0 0 3
BCSE301P - 0 0 2 1

Dr. S M SATAPATHY
Associate Professor Sr.,
School of Computer Science and Engineering,
VIT Vellore, TN, India – 632 014.
 Module – 1

OVERVIEW OF SOFTWARE ENGINEERING

1. Nature of Software

2. Software Process, Project and Product

3. Classical Evolutionary Models

4. Agile Process

2
INTRODUCTION

3
 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 manipulate
information and (3) documentation that describes the operation and
use of the programs.

 Software is developed or engineered, it is not manufactured in the

classical sense.
 Software doesn't “wear out”.

 Although the industry is moving toward component-based

construction, most software continues to be custom-built.
4
Wear vs. Deterioration

5
 Software Applications

 system software

 application software

 engineering/scientific software

 embedded software

 product-line software

 WebApps (Web applications)

 AI software (robotics, neural nets, game playing)

6
 Software Applications – New Categories
 Open world computing - pervasive, distributed computing
 Ubiquitous computing - wireless networks
 Netsourcing - the Web as a computing engine
 Open source – “free” source code open to the computing
community (a blessing, but also a potential curse!)

 Also …
 Data mining
 Grid computing
 Cognitive machines
 Software for nanotechnologies

7
 Legacy Software

 Why must it change?

 software must be adapted to meet the needs of new computing

environments or technology.

 software must be enhanced to implement new business

requirements.

 software must be extended to make it interoperable with other

more modern systems or databases.

 software must be re-architected to make it viable within a

network environment.
8
What do you mean by Software Engineering?

9
 Software Engineering

 The seminal definition:

[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 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).

10
Software Engineering

11
Software Engineering

12
 Software Engineering

STANDISH CHAOS REPORT 2015

 Traditional Definition: The project was resolved within a reasonable

estimated time, stayed within budget, and contained a good number

of the estimated features and functions.

13
 Software Engineering

STANDISH CHAOS REPORT 2015

 Modern Definition: The project was resolved within a reasonable

estimated time, stayed within budget, and delivered customer and

user satisfaction regardless of the original scope.

14
A Layered Technology

tools

methods

process model

a “quality” focus

Software Engineering

15
 Process Framework

 Process framework

 Framework activities

 work tasks

 work products

 milestones & deliverables

 QA checkpoints

 Umbrella Activities

16
 Framework Activities

 Communication

 Planning

 Modeling

 Analysis of requirements

 Design

 Construction

 Code generation

 Testing

 Deployment
17
 Umbrella Activities

 Software project tracking and control

 Risk management

 Software quality assurance

 Formal technical reviews (Decision Maker, Review Leader, Recorder, Technical

Staff, Management Staff, Customer / User Representative).

 Measurement

 Software configuration management

 Reusability management

 Work product preparation and production

18
 The Essence of Practice

 George Polya outlined the essence of problem solving and

consequently, the essence of software engineering practices:

1. Understand the problem (communication and analysis).

2. Plan a solution (modeling and software design).

3. Carry out the plan (code generation).

4. Examine the result for accuracy (testing and quality assurance).

19
 Understand the Problem

 Who has a stake in the solution to the problem? That is, who are

the stakeholders?

 What are the unknowns? What data, functions, and features are

required to properly solve the problem?

 Can the problem be compartmentalized? Is it possible to

represent smaller problems that may be easier to understand?

 Can the problem be represented graphically? Can an analysis

model be created?

20
 Plan the Solution

 Have you seen similar problems before? Are there patterns that

are recognizable in a potential solution? Is there existing software

that implements the data, functions, and features that are required?

 Has a similar problem been solved? If so, are elements of the

solution reusable?

 Can sub-problems be defined? If so, are solutions readily

apparent for the sub-problems?

 Can you represent a solution in a manner that leads to effective

implementation? Can a design model be created?

21
 Carry out the Plan

 Does the solution conform to the plan? Is source code traceable

to the design model?

 Is each component part of the solution provably correct? Has

the design and code been reviewed, or better, have correctness

proofs been applied to algorithm?

22
 Examine the Result

 Is it possible to test each component part of the solution? Has a

reasonable testing strategy been implemented?

 Does the solution produce results that conform to the data,

functions, and features that are required? Has the software been

validated against all stakeholder requirements?

23
 David Hooker’s General Principles

1: The Reason It All Exists

2: KISS (Keep It Simple, Stupid!)

3: Maintain the Vision

4: What You Produce, Others Will Consume

5: Be Open to the Future

6: Plan Ahead for Reuse

7: Think!

24
 Software Myths

 Affect managers, customers (and other non-technical stakeholders)

and practitioners

 Are believable because they often have elements of truth,

 but …

 Invariably lead to bad decisions,

 therefore …

 Insist on reality as you navigate your way through software

engineering

25
 Software Myths (Management Perspectives)

 We already have a book that’s full of standards and procedures for

building software. Won’t that provide my people with everything they

need to know.

 If we get behind schedule, we can add more programmers and catch

up sometimes called the “Mongolian Horde” concept.

 Brooks : “Adding people to a late software project makes it

later.”

 If I decide to outsource the software project to a third party, I can just

relax and let that form build it.

26
 Software Myths (Customer Perspectives)

 A general statement of objectives is sufficient to begin writing

programs- We can fill in the details later.

 Software requirements continually change, but change can be easily

accommodated because software is flexible.

27
 Software Myths (Practitioner Perspectives)

 Once we write the program and get it to work, our job is done.

 “The sooner you begin ‘writing code’, the longer it’ll take you to

get done.”

 Until I get the program “running” I have no way of assessing its

quality.

 The only deliverable work product for a successful project is the

working program.

 Software engineering will make us create voluminous and

unnecessary documentation and will invariably slow us down.

28
 Software Crisis
It was in late 1960’s

 Many software projects failed.

 Many software projects late, over budget, providing unreliable
software that is expensive to maintain.
 Many software projects produced software which did not satisfy the
requirements of the customer.
 Complexities of software projects increased as hardware capability
increased.
 Larger software system is more difficult and expensive to maintain.
 Demand of new software increased faster than ability to generate
new software.
29
 Software Crisis
 Software is unmaintainable due to:
 poor design, poor documentation (most software can be
understood only by its author, and then only within a few months
of writing it)
 Software is inefficient (new versions of complex software require
machine upgrades)
 Software is unreliable due to:
 poor design , inadequate testing (market pressures, beta
releases), impossible testing.
 Software is too complex.
 Complexity does not scale linearly: a 1000 line program is more
than 10 times as complex as a 100 line program
30
 Software Bug Examples
 The Explosion of Ariane 5 – 1996 – Faulty Data Conversion
 Therac-25 – 1985-1987
 USS Yorktown Incident – 1997 – Divide by Zero
 Sony CD Malicious Copy Protection – 2005 - rootkit
 Patriot Missile Bug – 1991 – resetting system clock
 Millennium Bug – 2000 – Y2K problem
 Year 2038 – 19th Jan 2038

31
 Cost of Software Production

• Roughly 60% of costs are development costs, 40% are testing

costs. For custom software, evolution costs often exceed

development costs.

• Costs vary depending on the type of system being developed and

the requirements of system attributes such as performance and

system reliability.

• Distribution of costs depends on the development model that is

used.

32
 Attributes of Good Software
 The software should deliver the required functionality and
performance to the user and should be maintainable, dependable
and acceptable.
 Maintainability
 Software must evolve to meet changing needs;
 Dependability
 Software must be trustworthy;
 Efficiency
 Software should not make wasteful use of system resources;
 Acceptability
 Software must accepted by the users for which it was designed.
This means it must be understandable, usable and compatible
with other systems. 33
 Key Challenges of Software Engineering

 Heterogeneity, delivery and trust.

 Heterogeneity

 Developing techniques for building software that can cope with

heterogeneous platforms and execution environments;

 Delivery

 Developing techniques that lead to faster delivery of software;

 Trust

 Developing techniques that demonstrate that software can be

trusted by its users.

34
 System Engineering
 Systems engineering is an interdisciplinary field of engineering that
focuses on how to design and manage complex engineering projects
over their life cycles.

 It is the sub discipline of engineering which deals with the overall

management of engineering projects during their life cycle (focusing
more on physical aspects).

 It deals with logistics, team coordination, automatic machinery

control, work processes and similar tools. Most of the times, System
Engineering overlaps with the concepts of industrial engineering,
control engineering, organizational and project management and
even software engineering. 35
 System Engineering Process
 Requirements Definition
 System Design
 Sub-System Development
 System Integration
 System Installation
 System Evolution
 System Decommissioning

36
 System Engineering vs. Software Engineering

 The difference between System Engineering and Software

Engineering is not very clear.

 However, it can be said that the System Engineers focus more on

users and domains, while Software Engineering focus more on n

implementing quality software.

 System Engineer may deal with a substantial amount of hardware

engineering, but typically software engineers will focus solely on

software components.
37
 Practice Questions
1. Why can’t we find all errors before we give the software to our
customers?

2. Why do we continue to have difficulty in measuring progress as

software is being developed and maintained?

3. Provide at least two number of examples (both positive and

negative) that indicate the impact of software on our society?

4. Many modern applications change frequently before they are

presented to the end user and then after the first versions have
been used. Suggest few ways to build software to stop deterioration
due to change. 38
 Practice Questions
5. Describe process framework in your own words. When we say that
framework activities are applicable to all projects, does this mean
that the same work tasks are applied for all projects regardless of
size and complexity? Explain.

6. Add two more additional myths considering present day software

industries and also state the reality that accompanies the myth.

39
SOFTWARE PROCESS

40
Generic Process Model

41
Process Flow

42
Classical Waterfall Model

43
 Shortcomings of Classical Waterfall Model
 No feedback Paths

 Difficult to accommodate change request

 Inefficient error corrections

 No overlapping of phases

44
 Iterative Waterfall Model
 Classical waterfall model is idealistic:

 assumes that no defect is introduced during any development

activity.

 in practice:

defects do get introduced in almost every phase of the life

cycle.

 Defects usually get detected much later in the life cycle:

For example, a design defect might go unnoticed till the coding or

testing phase.

45
 Iterative Waterfall Model

 Once a defect is detected:

 we need to go back to the phase where it was introduced

 redo some of the work done during that and all subsequent

phases.

 Therefore we need feedback paths in the classical waterfall model.

46
 Iterative Waterfall Model

Feasibility Study

Req. Analysis

Design

Coding

Testing

Maintenance

47
 Shortcomings of Iterative Waterfall Model

 Incremental Delivery not Supported

 Phase Overlap not Supported

 Limited Customer Interactions

 No Support for risk handling and code reuse

48
 Phase Containment of Errors

 The principle of detecting errors as close to its point of introduction

as possible is known as phase containment of errors.

 Phase containment of errors means detect and correct the errors

within the phase where it’s actually lives.

 That is a design error should be detected and corrected within the

design phase itself rather than detecting it in the coding phase.

 To achieve phase containment of errors we have to take periodic

reviews.

49
 Phase Containment of Errors

 Phase containment is used for defect prevention so that the defects

are found at each phase of the application, and are not multiplied

further; we do it by taking JAD sessions, performing reviews after

each phase, by participating in walkthroughs and inspection.

50
 When to use Waterfall Model

 Requirements are very well known

 Product definition is stable

 Technology is understood

 New version of an existing product

 Porting an existing product to a new platform.

51
V Model

52
 V Model

 Variant of Waterfall Model

 In this model, verification and validation activities are carried out
throughout the development life cycle.
 Hence suitable for projects concerned with development of safety-
critical software that are required high reliability.

 Consists of two phases: Development / Verification and Validation.

 The activities carried out during verification phase are Development

of work product, Test case design and Plan for testing the work
product.

 Validation phase activities carried out in four steps – unit, integration,

system and acceptance testing.

53
 Strengths of V Model

 Much of testing activities are carried out in parallel with development

activities.

 Quality of test cases are usually better.

 Test team is reasonably occupied throughout the development cycle.

 Test team is associated with the project from the beginning.

 Emphasize planning for verification and validation of the product in

early stages of product development.

 Each deliverable must be testable

 Project management can track progress by milestones.

54
 Weaknesses of V Model

 Does not easily handle concurrent events

 Does not handle iterations or phases

 Does not easily handle dynamic changes in requirements

 Does not contain risk analysis activities

55
 When to use V Model

 Excellent choice for systems requiring high reliability – hospital

patient control applications

 All requirements are known up-front

 When it can be modified to handle changing requirements beyond

analysis phase

 Solution and technology are known

56
 Prototyping Model

 Before starting actual development,

 a working prototype of the system should first be built.

 A prototype is a toy implementation of a system:

 limited functional capabilities,

 low reliability,

 inefficient performance.

57
 Why Prototyping Model?

 Illustrate to the customer:

 input data formats, messages, reports, or interactive dialogs.
 Examine technical issues associated with product development:
 Often major design decisions depend on issues like:
 response time of a hardware controller,
 efficiency of a sorting algorithm, etc.

 The third reason for developing a prototype is:

 it is impossible to “get it right” the first time,

 we must plan to throw away the first product

 if we want to develop a good product.

58
 Prototyping Model
Build Prototype

Requirements Customer Customer satisfied

Gathering Evaluation of
Quick Design Prototype Design

Refine Implement
Requirements

Test

Maintain

59
 Prototyping Model

Quick
Q u i ck p l an
plan
Co m m u n icat io n
communication

Modeling
Mo d e lin g
Q u i ck
Quick d e si g n
design

Deployment
Deployment
De live r y
delivery &
& feedback
Fe e d b ack Co n st r u ct io n
Construction
of
of prototype
p r o t o t yp e

60
 Prototyping Model Steps
 Start with approximate requirements.

 Carry out a quick design.

 Prototype model is built using several short-cuts:

 Short-cuts might involve using inefficient, inaccurate, or dummy

functions.

 A function may use a table look-up rather than performing

the actual computations.

 The developed prototype is submitted to the customer for his

evaluation:

 Based on the user feedback, requirements are refined.

 This cycle continues until the user approves the prototype.

61
 Prototyping Model Steps
 The actual system is developed using the classical waterfall
approach.

 Requirements analysis and specification phase becomes redundant:

 final working prototype (with all user feedbacks incorporated)

serves as an animated requirements specification.

 Design and code for the prototype is usually thrown away:

 However, the experience gathered from developing the

prototype helps a great deal while developing the actual product.

62
 Prototyping Model Strengths
 Users are actively involved in the development

 Since in this methodology a working model of the system is

provided, the users get a better understanding of the system being

developed.

 Errors can be detected much earlier.

 Quicker user feedback is available leading to better solutions.

 Missing functionality can be identified easily

 Confusing or difficult functions can be identified Requirements
validation, Quick implementation of, incomplete, but functional,
application.
63
 Prototyping Model Strengths
 Even though construction of a working prototype model
involves additional cost --- overall development cost might be
lower for:

 systems with unclear user requirements,

 systems with unresolved technical issues.

 Many user requirements get properly defined and technical

issues get resolved:

 these would have appeared later as change requests and

resulted in incurring massive redesign costs.

64
 Disadvantages of Prototyping Model

 Leads to implementing and then repairing way of building systems.

 Practically, this methodology may increase the complexity of the

system as scope of the system may expand beyond original plans.

 Incomplete application may cause application not to be used as the

full system was designed with Incomplete or inadequate problem

analysis

65
 When to use Prototyping Model

 Requirements are unstable or have to be clarified

 Technical issues need to be resolved.

 Short-lived demonstrations

66
 Incremental Model

delivered
system

design build install evaluate

increment
first incremental delivery 1

design build install evaluate increment

2
second incremental delivery

increment
design build install evaluate
3

third incremental delivery

67
Incremental Process

68
 Advantages of Incremental Model
 Users get a chance to experiment with a partially developed system:
 much before the full working version is released,
 Helps finding exact user requirements:
 much before fully working system is developed.
 Core modules get tested thoroughly:
 reduces chances of errors in final product.

 Training can start on an earlier release

 customer feedback taken into account

 Markets can be created:

 for functionality that has never been offered.

 Frequent releases allow developers to fix unanticipated problems

quickly. 69
 Disadvantages of Incremental Model
 Often, difficult to subdivide problems into functional units:
 which can be incrementally implemented and delivered.
 useful for very large problems,
 where it is easier to find modules for incremental
implementation.
 Needs good planning and design.
 Total cost is higher than waterfall.

70
 When to use Incremental Model

 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.

71
 Which step first?
 some steps will be pre-requisite because of physical dependencies
 others may be in any order
 value to cost ratios may be used
V/C where
 V is a score 1-10 representing value to customer
 C is a score 0-10 representing value to developers

72
 V/C ratios: an example

step value cost ratio

profit reports 9 1 9 2nd
online database 1 9 0.11 5th
ad hoc enquiry 5 5 1 4th
purchasing plans 9 4 2.25 3rd
profit- based pay 9 0 inf 1st
for managers

73
 Spiral Model
 Proposed by Boehm in 1988.

 Each loop of the spiral represents a phase of the software process:

 the innermost loop might be concerned with system feasibility,

 the next loop with system requirements definition,

 the next one with system design, and so on.

 The team must decide:
 how to structure the project into phases.
 Start work using some generic model:
 add extra phases - for specific projects or when problems are
identified during a project.
 There are no fixed phases in this model, the phases shown in the
figure are just examples.
74
 Spiral Model

Determine Identify &

Objectives Resolve Risks

Customer
Evaluation of Develop Next
Prototype Level of Product

75
 Spiral Model
planning
estimation
scheduling
risk analysis

communication

modeling
analysis
design
start

deployment
construction
delivery cod e
feedback test

76
 Objective Setting (First Quadrant)
 Identify objectives of the phase,

 Examine the risks associated with these objectives.

 Risk:

 any adverse circumstance that might hamper successful

completion of a software project.

 Find alternate solutions possible.

 Objectives: functionality, performance, hardware/software
interface, critical success factors, etc.
 Alternatives: build, reuse, buy, sub-contract, etc.
 Constraints: cost, schedule, interface, etc.

77
 Risk Assessment and Reduction (Second Quadrant)
 For each identified project risk,

 a detailed analysis is carried out.

 Steps are taken to reduce the risk.

 For example, if there is a risk that the requirements are

inappropriate:

 a prototype system may be developed.

 Study alternatives relative to objectives and constraints
 Identify risks (lack of experience, new technology, tight schedules,
poor process, etc.
 Resolve risks (evaluate if money could be lost by continuing system
development
78
 Development and Validation (Third Quadrant)
 develop and validate the next level of the product.
 Typical activities:
 Create a design
 Review design
 Develop code
 Inspect code
 Test product

79
 Review and Planning (Fourth Quadrant)
 review the results achieved so far with the customer and plan the
next iteration around the spiral.
 Typical activities
 Develop project plan
 Develop configuration management plan
 Develop a test plan
 Develop an installation plan

With each iteration around the spiral:

progressively more complete version of the software gets
built.

80
 When to use Spiral Model

 When creation of a prototype is appropriate

 When costs and risk evaluation is important

 For medium to high-risk projects

 Long-term project commitment unwise because of potential changes

to economic priorities

 Users are unsure of their needs

 Requirements are complex

 New product line

 Significant changes are expected (research and exploration)

81
 Spiral Model as Meta Model
 Subsumes all discussed models:

 a single loop spiral represents waterfall model.

 uses an evolutionary approach --

 iterations through the spiral are evolutionary levels.

 enables understanding and reacting to risks during each

iteration along the spiral.

 uses:
 prototyping as a risk reduction mechanism
 retains the step-wise approach of the waterfall model.

82
 RAD Model

 Requirements planning phase (a workshop utilizing structured

discussion of business problems)

 User description phase – automated tools capture information from

users

 Construction phase – productivity tools, such as code generators,

screen generators, etc. inside a time-box. (“Do until done”)

 Cutover phase -- installation of the system, user acceptance testing

and user training

83
 RAD Model
 It is a type of incremental model.
 In RAD model the components or functions are developed in parallel
as if they were mini projects.
 The developments are time boxed, delivered and then assembled
into a working prototype.
 This can quickly give the customer something to see and use and to
provide feedback regarding the delivery and their requirements.
 Prototypes are constructed, incrementally features are developed
and delivered to the customer.
 But prototypes are not thrown away rather enhanced and used in the
software construction.

84
 Phases of RAD Model

Communication:

 Understand the business problem and information characteristics.

Planning:

 Multiple teams works in parallel

Modeling:

 Establishes design representation

Construction:

 Use of pre existing components and application of automated code

generation.
85
 Modeling

 Business modeling: The information flow is identified between

various business functions.

 Data modeling: Information gathered from business modeling is

used to define data objects that are needed for the business.

 Process modeling: Data objects defined in data modeling are

converted to achieve the business information flow to achieve some

specific business objective.

86
Modeling

87
 Advantages of RAD Model

 Reduced development time.

 Increases reusability of components

 Quick initial reviews occur

 Encourages customer feedback

 Integration from very beginning solves a lot of integration issues.

88
 Disadvantages of RAD Model

 Depends on strong team and individual performances for identifying

business requirements.

 Only system that can be modularized can be built using RAD

 Requires highly skilled developers/designers.

 High dependency on modeling skills

 Inapplicable to cheaper projects as cost of modeling and automated

code generation is very high.

89
 When to use RAD Model

 When costs and risk evaluation is important

 For medium to high-risk projects

 Long-term project commitment unwise because of potential changes

to economic priorities

 Users are unsure of their needs

 Requirements are complex

 New product line

 Significant changes are expected (research and exploration)

90
 Applicability of RAD Model

 Customized software

 Non-critical software

 Highly constrained project schedule

 Large software

91
 Applications where RAD unsuitable

 Generic Products

 Requirement of optimal performance and/or reliability

 Lack of similar products

 Monolithic Entity

92
 Evolutionary Model: Concurrent

none

Modeling act ivit y

rep resent s t he st at e
Under o f a so f t ware eng ineering
act ivit y o r t ask
development

A wait ing
changes

Under review

Under
revision

Baselined

Done

93
 Comparison of Life Cycle Model

Sl # Model Strength Weakness

1 Classical Waterfall Disciplined Approach, No mechanism to Correct

Model Document Driven Errors
2 Iterative Waterfall Simple to Understand and Most Not suitable for very large
Model Widely Used projects and projects suffer
from large number of Risks
3 Prototyping Model Suitable for projects for which All the risks can not be
either the user requirements or identified before the project
the underlying technical starts
aspects are not well
understood
4 Evolutionary Suitable for large problems and Can only be used, if
Model support incremental incremental delivery is
development and delivery. acceptable to customer.
5 Spiral Model Meta Model, which is suitable Very complex, hence very
for developing technically less used.
challenging and large software
those prone to several kind of
Risks.
94
 Other Process Models

 Component based development—the process to apply when reuse

is a development objective

 Formal methods—emphasizes the mathematical specification of

requirements

 AOSD—provides a process and methodological approach for

defining, specifying, designing, and constructing aspects

 Unified Process—a “use-case driven, architecture-centric, iterative

and incremental” software process closely aligned with the Unified

Modeling Language (UML)

95
Unified Process

96
 Unified Process Model
 Pros
 Quality documentation emphasized.
 Continuous customer involvement.
 Accommodates requirements changes.
 Works well for maintenance projects.
 Cons
 Use cases are not always precise.
 Tricky software increment integration.
 Overlapping phases can cause problems.
 Requires expert development team.

97
 Agility
 Effective (rapid and adaptive) response to change.
 Effective communication among all stakeholders.
 Drawing the customer onto the team.
 Organizing a team so that it is in control of the work performed.
 Rapid, incremental delivery of software.

98
 Agile Software Development
 Agile software development emphasizes on:
 Good communication between the client and developers
 Rapid delivery of software
 Change of Demand
 It promotes adaptive planning, evolutionary development and
delivery, a time-boxed iterative approach

 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

99
 Agility Principles
 Customer satisfaction is achieved by providing value through
software that is delivered to the customer as rapidly as possible.
 Develop recognize that requirements will change and welcome
changes.
 Deliver software increments frequently (weeks not months) to
stakeholders to ensure feedback on their deliveries is meaningful.
 Agile team populated by motivated individuals using face-to-face
communication to convey information.
 Team process encourages technical excellence, good design,
simplicity, and avoids unnecessary work.

100
 Agility Principles
 Working software that meets customer needs is the primary goal.
 Pace and direction of the team’s work must be “sustainable,”
enabling them to work effectively for long periods of time.
 An agile team is a “self-organizing team”—one that can be trusted
develop well-structured architectures that lead to solid designs and
customer satisfaction.
 Part of the team culture is to consider its work introspectively with
the intent of improving how to become more effective its primary
goal (customer satisfaction).

101
 Types of Agile Methodologies
 Adaptive Software Development (ASD)
{J. Highsmith and S. Bayer, 1992}
 Crystal Methods (Crystal Clear)
{Alistair Cockburn, 1992}
 Extreme Programming (XP)
{Kent Beck, 1999}
 Feature Driven Development (FDD)
{Jeff De Luca, 1997}
 Lean Software Development
{Mary Poppendieck and Tom Poppendieck, 2003}
 Agile Unified Process (AUP)
{Scott Ambler, 2000}
 Scrum
{Ken Schwaber, Jeff Sutherland, 1991}
 Disciplined Agile Delivery
{Scott Ambler and Mark Lines, 2012}
 Dynamic Systems Development Method (DSDM)
{DSDM Consortium, 1994}
102
Agile Software Development

103
Agile Software Development

104
 Extreme Programming
 The name of this model reflects the fact that it recommends taking
these best practices that have worked well in the past in program
development projects to extreme levels.
 It is based on simple philosophy: “If something is known to be
beneficial, why not put it to constant use?”
 The software development team determines the various features
(stories) the client would like the product to support.
 A user story is a simplistic statement of customer about a
functionality he needs.
 It does not mention about finer details such as different scenarios
that can occur, the precondition (state at which the system) to be
satisfied before the feature can be invoked, etc.
105
 Extreme Programming
 Based on the features (stories) the client wants:
 The development team estimates the duration and cost of each
feature
 The client selects the features for next build using cost-benefit
analysis
 The proposed build is broken down into smaller pieces termed
tasks
 The programmer draws up test cases for a task  Test-driven
development (TDD)
 Pair Programming: The programmer works together with a partner
on one screen to implement the task and ensure that all the test
cases work correctly.
106
 Extreme Programming
 Continuous integration of tasks since a number of pairs implement
tasks in parallel
 The TDD test cases used for the task are retained and utilized in all
further integration testing.
 A spike solution is a very simple program to explore potential
solutions. Build the spike to only addresses the problem under
examination and ignore all other concerns.
 Framework Activities in XP Process Model:
 Planning
 Design
 Coding
 Testing
107
 Extreme Programming

spike solut ions

simple design
prot ot ypes
CRC cards
user st ories
values
accept ance t est crit eria
it erat ion plan

ref act oring

pair
programming

Release
sof t ware increment unit t est
project v elocit y comput ed cont inuous int egrat ion

accept ance t est ing

108
 Extreme Programming
 XP is applicable for :
 Projects involving new technology or research projects
 Small projects

 Non suitable Project characteristics:

 Stable requirements
 Mission critical or safety critical systems

109
 Scrum
 Scrum is very popular and very widely used today.
 Developed based on the concept that software development is
o not a defined process but an empirical process
o with complex input/output transformations that
o may or may not be repeated under differing circumstances.
 Scrum—distinguishing features
 Development work is partitioned into “packets”
 Testing and documentation are on-going as the product is
constructed
 Work occurs in “sprints” and is derived from a “backlog” of existing
requirements
 Meetings are very short and sometimes conducted without chairs
 “demos” are delivered to the customer with the time-box allocated
110
Scrum

111
Scrum

112
 Adaptive Software Development

 ASD — distinguishing features

 Mission-driven planning

 Component-based focus

 Uses “time-boxing”

 Explicit consideration of risks

 Emphasizes collaboration for requirements gathering

 Emphasizes “learning” throughout the process

113
 Adaptive Software Development
adapt ive cycle planning Requirement s gat hering
uses mission st at ement JAD
project const raint s mini-specs
basic requirement s
t ime-boxed release plan

Release
sof t ware increment
adjust ment s f or subsequent cy cles
component s implement ed/ t est ed
f ocus groups f or f eedback
f ormal t echnical reviews
post mort ems

114
 Dynamic Systems Development Method
 DSDM—distinguishing features (Nine Guiding Principles)
 Similar in most respects to XP and/or ASD

 Active user involvement is imperative.

 DSDM teams must be empowered to make decisions.

 The focus is on frequent delivery of products.

 Fitness for business purpose is the essential criterion for

acceptance of deliverables.

 Iterative and incremental development is necessary to

converge on an accurate business solution.

 All changes during development are reversible.

 Requirements are baselined at a high level

 Testing is integrated throughout the life-cycle. 115

Dynamic Systems Development Method

116
 Crystal
 Crystal—distinguishing features
 Actually a family of process models that allow “maneuverability”
based on problem characteristics
 Face-to-face communication is emphasized
 Suggests the use of “reflection workshops” to review the work
habits of the team

117
 Feature Driven Development
 FDD—distinguishing features
 Emphasis is on defining “features”
 a feature “is a client-valued function that can be implemented in
two weeks or less.”
 Uses a feature template
 <action> the <result> <by | for | of | to> a(n) <object>
 A features list is created and “plan by feature” is conducted
 Design and construction merge in FDD

118
Feature Driven Development

119
 Kanban
 Visualizing workflow using a Kanban board.
 Limiting the amount of work in progress at any given time.
 Managing workflow to reduce waste by understanding the current
value flow.
 Making process policies explicit and the criteria used to define
“done”.
 Focusing on continuous improvement by creating feedback loops
where changes are introduced.
 Make process changes collaboratively and involve all stakeholders
as needed.

120
Kanban

121
 Kanban
Pros
 Lower budget and time requirements.
 Allows early product delivery.
 Process policies written down.
 Continuous process improvement.

Cons
 Team collaboration skills determine success.
 Poor business analysis can doom the project.
 Flexibility can cause developers to lose focus.
 Developer reluctance to use measurement.

122
 DevOps
 DevOps is a combination of software development (dev) and
operations (ops).
 It is defined as a software engineering methodology which aims to
integrate the work of development teams and operations teams by
facilitating a culture of collaboration and shared responsibility.
 Continuous development: Software delivered in multiple sprints.
 Continuous testing: Automated testing tools used prior to integration.
 Continuous integration: Code pieces with new functionality added to
existing code running code.
 Continuous deployment: Integrated code is deployed to the
production environment.
 Continuous monitoring: Team operations staff members proactively
monitor software performance in the production environment. 123
DevOps

124
 DevOps
Pros
 Reduced time to code deployment.
 Team has developers and operations staff.
 Team has end-to-end project ownership.
 Proactive monitoring of deployed product.

Cons
 Pressure to work on both old and new code.
 Heavy reliance on automated tools to be effective.
 Deployment may affect the production environment.
 Requires an expert development team.

125
 Practice Questions
1. Is it possible to combine process models? If so, provide an
example.
2. Describe agility for software projects in your own words. Try to
come up with more agility principle that would help a software
engineering team become more manoeuvrable.
3. Describe the XP concept of refactoring, pair programming and
spike solution with your own words citing an example.
4. Is it possible to complete a project in just one iteration and still be
agile? Explain your answer.
5. Discuss the reasons for which it can be difficult to introduce agile
methods into large companies.
6. How does XP model differ from the spiral model in its treatment of
incremental prototypes? 126
 Disclaimer

The material for the presentation has been compiled

from various sources such as prescribed text books by
Roger S pressman and Ian Sommerville and other
tutorials and lecture notes. The information contained in
this lecture/ presentation is for educational purpose only.

127
Thank You for Your Attention !

128