CS8494 SOFTWARE ENGINEERING

UNIT I
SOFTWARE PROCESS AND AGILE DEVELOPMENT

Dr.N.Saravanan, Professor, Dept. of CSE,

II - CSE
M N M Jain Engineering College, Chennai.
 UNIT I
SOFTWARE PROCESS AND AGILE DEVELOPMENT
2
 Introduction to Software Engineering, Software
Process, Perspective and Specialized Process
Models –Introduction to Agility-Agile process-
Extreme programming-XP Process.
 TEXT BOOK:

Roger S. Pressman, “Software Engineering – A

Practitioner’s Approach”, Seventh Edition, Mc
Graw-Hill International Edition, 2010.
 Introduction to Software Engineering
3

 What is Software?
Software is:
(1) instructions (computer programs) that when
executed provide desired features, function,
and performance;
(2) data structures that enable the programs to
adequately manipulate information and
(3) documentation that describes the operation
and use of the programs.
 Introduction to Software Engineering …
4

What is Software?
 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.
 Wear vs. Deterioration
5
 Software Applications
6

 system software
 application software

 engineering/scientific software

 embedded software

 product-line software

 WebApps (Web applications)

 AI software
 Software—New Categories
7

 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
 Data mining

 Grid computing

 Cognitive machines

 Software for nanotechnologies

 Legacy Software
8

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.
 Software Engineering
9
 Some realities:
 a concerted effort should be made to understand the
problem before a software solution is developed
 design becomes a critical activity

 software should exhibit high quality

 software should be maintainable

 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.
10

 The IEEE definition

 Software Engineering: The application of a
systematic, disciplined, quantifiable
approach to the development, operation, and
maintenance of software; that is, the
application of engineering to software.
A Layered Technology

tools

methods

process model

a “quality” focus

Software Engineering Layers

11
 Elements of Software Engineering Approach
12

Engineering Approach uses … Software Engineering uses …

• Sequence of activities • Req. Development

Processes needed to produce the Processes
system • Software Design
• Software Construction
• Software Testing

• Development approach
Methods for expected quality Methods • Structured Methods
Copyright © 2014, Infosys Limited Confidential
outputs adhering budget • Object Oriented
and time Methods

• Provide support for • DesignTools

Tools executing processes Tools
• oding Tools
• Testing Tools
 15

Process
13

• To summarize: Process is PROCESS

a sequence of steps
executed for a given
TRANSFORMATION
purpose INPUT OUTPUT

• For every step there

are inputs and outputs Quality
checks

• Each process may

have sub-processes

• Road map that helps to

create a timely, high
quality result
 The Software Process…
14

Process framework
oFramework activities
Work tasks
work products
milestones & deliverables
QA checkpoints
oUmbrella Activities
 The Software Process…
15

Framework Activities Umbrella Activities

 Communication  SPM
 Planning  Formal technical reviews
 Modeling
 SQA
 Analysis of
 SCM
requirements
 Design  Work product preparation

 Construction and production

 Code generation  Reusability management

 Testing  Measurement

 Deployment  Risk management

 Generic Process Framework
16

 Communication
 Involves communication among the customer
and other stake holders; encompasses
requirements gathering
 Planning

 Establishes a plan for software engineering

work; addresses technical tasks, resources,
work products, and work schedule
 Generic Process Framework...
17

 Modeling (Analyze, Design)

 Encompasses the creation of models to
better under the requirements and the design
 Construction (Code, Test)

 Combines code generation and testing to

uncover errors
 Deployment

 Involves delivery of software to the

customer for evaluation and feedback
 Software Requirements Analysis
18

 Helps software engineers to better understand the

problem they will work to solve
 Encompasses the set of tasks that lead to an
understanding of what the business impact of the
software will be, what the customer wants, and
how end-users will interact with the software
 Uses a combination of text and diagrams to depict
requirements for data, function, and behavior
 Provides a relatively easy way to understand and
review requirements for correctness,
completeness and consistency
 Software Design
19

 Brings together customer requirements, business

needs, and technical considerations to form the
“blueprint” for a product
 Creates a model that that provides detail about
software data structures, software architecture,
interfaces, and components that are necessary to
implement the system
 Architectural design
 Represents the structure of data and program
components that are required to build the software
 Considers the architectural style, the structure and
properties of components that constitute the system,
and interrelationships that occur among all
architectural components
 Software Design...
20

 User Interface Design

 Creates an effective communication medium
between a human and a computer
 Identifies interface objects and actions and
then creates a screen layout that forms the
basis for a user interface prototype
 Component-level Design
 Defines the data structures, algorithms,
interface characteristics, and communication
mechanisms allocated to each software
component
 Software Process Model
21

•Representation of a software development

process
•Also called as Software Development Life Cycle
(SDLC) models
•Prescriptive Process Models
•Specialized process Models
•Prescriptive Process Models
Examples
–Waterfall model
–Incremental/
–Prototype model
–Spiral model
 Scenarios and Models
# Scenario Observations Model
22
Customer has provided you all the requirements • No change in
and has assured that there will not be any change requirements
1 in the requirements. He expects the deliverables • Deliverables expected Waterfall
from you at every stage of development. You have at every stage
carried out a similar project earlier and you are • Systematic execution
sure that the project could be executed
systematically.
Customer wants you to start developing the • Complete
software for a remote controlled electronic toy. requirements
Customer is not sure of all requirements of the unavailable
2 product. She has provided you an initial set of • Start development Incremental
requirements with which she wants to have a feel with a set of
of the product. She has informed you that few requirements
more requirements will be provided later • Initial feel of the
product expected
Customer and the development team foresee • Many risks are expected
many risks at every stage of software • There are alternatives
3 development. At each stage of development there at each stage Spiral
are alternatives and you have to make right • Not fixed budget project
decisions. You and customer are in agreement
that the project is not fixed budget project
 Prescriptive Process Model
23

 Defines a distinct set of activities, actions,

tasks, milestones, and work products that are
required to engineer high-quality software
 The activities may be

 linear,

 incremental, or

 evolutionary
 Waterfall Model
24

 Oldest software lifecycle Problems/Drawbacks

model and best understood by  Doesn‘t support
upper management iteration, so changes
can cause confusion
 Used when requirements are
 Difficult for customers
well understood and risk is low
to state all
 Work flow is in a linear (i.e., requirements explicitly
sequential) fashion and up front
 Used often with well-defined  Requires customer

adaptations or enhancements to patience because a

current software working version of the
program doesn't occur
until the final phase
 Waterfall Model...
25

Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling
Tracking Modeling
Analysis
Design Construction
Code
Test Deployment
Delivery
Support
Feedback
 Waterfall Model with Feedback
26
Communication
Project initiation
Requirements
gathering

Planning
Estimating
Scheduling
Tracking Modeling
Analysis
Design Construction
Code
Test Deployment
Delivery
Support
Feedback
 Incremental Model
27

 Used when requirements are well understood

 Multiple independent deliveries are identified
 Work flow is in a linear (i.e., sequential) fashion within
an increment and is staggered between increments
 Iterative in nature; focuses on an operational product
with each increment
 Provides a needed set of functionality sooner while
delivering optional components later
 Useful also when staffing is too short for a full-scale
development
 Incremental Model...
28

Increment #1
Communication
Planning
Modeling
Construction
Deployment
Increment #2

Communication Planning
Modeling
Construction
Deployment
Increment #3

Communication
Planning
Modeling
Construction
Deployment
28
 Prototyping Model
29

 Follows an evolutionary and iterative approach

 Used when requirements are not well
understood
 Serves as a mechanism for identifying software

requirements
 Focuses on those aspects of the software that
are visible to the customer/user
 Feedback is used to refine the prototype
 Prototyping Model...
30

Potential Problems
 The customer sees a "working version" of the software,
wants to stop all development and then buy the
prototype after a "few fixes" are made
 Developers often make implementation compromises to
get the software running quickly (e.g., language choice,
user interface, inefficient algorithms)
 Lesson learned
 Define the rules up front on the final disposition of the
prototype before it is built
 In most circumstances, plan to discard the prototype and
engineer the actual production software with a goal toward
quality
 Prototyping Model ...
31

Quick
Planning
Communication
Start
Modeling
Quick
Deployment, Design
Delivery,
and Feedback
Construction
of Prototype
 Spiral Model
32

 Invented by Dr. Barry Boehm in 1988 while

working at TRW
 Follows an evolutionary approach

 Used when requirements are not well understood

and risks are high
 Especially designed for those with higher chances
of failure.
 Combines iterative model, emphasizes risk
assessment, customer participation, prototyping,
and more
 Spiral Model...
33

 Serves as a realistic model for large-scale

software development
 Inner spirals focus on identifying software
requirements and project risks; may also
incorporate prototyping
 Outer spirals take on a classical waterfall
approach after requirements have been
defined, but permit iterative growth of the
software
34
Source: After Boehm 1988 (© 1988 IEEE)
 Spiral Model...

Can see each spiral includes:

Planning
Risk Analysis / Resolution
Engineering activities
(design, code, test…)
Customer Evaluation
(errors, changes, new requirements…)

35
 Model Advantages Disadvantages
Summarizing Models
• Simple and Systematic
• Limited or no scope for
Waterfall accommodating new
36
• Disciplined Approach requirements
• Potential delay in identifying
risks
• Part of the product
is visible at early • Time consuming
Increment stage • Expensive at times
al • Scope for
accommodating new
requirements
• Requires good
• Model for other models expertise in risk
Spiral • Iterative and realistic management
• Model is not suitable
for fixed budget
projects
 General Weaknesses of Evolutionary
Process Models
37

1) Prototyping poses a problem to project planning

because of the uncertain number of iterations required
to construct the product
2) Evolutionary software processes do not establish the
maximum speed of the evolution
• If too fast, the process will fall into chaos
• If too slow, productivity could be affected
3) Software processes should focus first on flexibility and
extensibility, and second on high quality
• We should prioritize the speed of the development over
zero defects
• Extending the development in order to reach higher quality
could result in late delivery
 Specialized Process Models
38

1. Component-based Development Model

 Consists of the following process steps

 Available component-based products are

researched and evaluated for the application
domain in question
 Component integration issues are
considered
 A software architecture is designed to
accommodate the components
 Specialized Process Models...
39

1. Component-based Development Model...

 Consists of the following process steps...

 Components are integrated into the

architecture
 Comprehensive testing is conducted to ensure
proper functionality
 Relies on a robust component library

 Capitalizes on software reuse, which leads to

documented savings in project cost and time
 2. Formal Methods Model
40

 Encompasses a set of activities that leads to formal

mathematical specification of computer software
 Enables a software engineer to specify, develop,
and verify a computer-based system by applying a
rigorous, mathematical notation
 Ambiguity, incompleteness, and inconsistency can
be discovered and corrected more easily through
mathematical analysis
 Offers the promise of defect-free software
 Used often when building safety-critical systems
 2. Formal Methods Model...
41

 Formal Methods Model- Challenges

 Development of formal methods is currently
quite time-consuming and expensive
 Because few software developers have the
necessary background to apply formal methods,
extensive training is required
 It is difficult to use the models as a
communication mechanism for technically
unsophisticated customers
 Software Development Approaches
42

•Approaches are the practices adopted in the

industry for software development
 Popular approaches are
 Prototype
 Rapid Application Development
 Agile
The above approaches may be used in the context
of some of the SDLC models
 RAD Approach
43

Why RADApproach ?
• Tight deadlines
• High Pressure from Customer
• Quick time to Market
What is RADApproach ?
•Rapid Application Development
•Emphasis is on short development time. Completing system
development within a short time (60 days to 90days)
•Each major function addressed by a separate RAD team
•Users are involved throughout the development life cycle
 Agile Approach What is “Agility”?
44

• Supports development for  Effective (rapid and

frequently changing adaptive) response to
system requirements change
• Customer involvement is  Effective communication

more frequent among all stakeholders

• Uses an iterative approach  Drawing the customer

to evolve the product onto the team

• Quality assured periodic  Organizing a team so

deliveries happen for each that it is in control of the

work performed
distinct feature
• Features are cumulatively Yielding …
 Rapid, incremental
integrated
delivery of software
 Agile Life Cycle
45

Requirements List
Priority 1 Priority 2 Priority 3 Priority 4
Analysis

Design

Code

Test
Production
Agility and the Cost of Change

46
 An Agile Process
47

 Is driven by customer descriptions of what is

required (scenarios)
 Recognizes that plans are short-lived

 Develops software iteratively with a heavy

emphasis on construction activities
 Delivers multiple ‘software increments’

 Adapts as changes occur

 Agility Principles
48

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.
 Agility Principles …
49

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, and users should be able
to maintain a constant pace indefinitely.
 Agility Principles …
50

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.
 Human Factors
51

 the process molds to the needs of the people and team,

not the other way around
 key traits must exist among the people on an agile team
and the team itself:
 Competence.

 Common focus.
 Collaboration.

 Decision-making ability.

 Fuzzy problem-solving ability.

 Mutual trust and respect.

 Self-organization.
 Extreme Programming (XP)
52

 The most widely used agile process, originally

proposed by Kent Beck
 XP Planning
 Begins with the creation of “user stories” by listening
 Customer assigns a value to the story.

 Agile team assesses each story and assigns a cost

 Stories are grouped to for a deliverable increment

 A commitment is made on delivery date

 After the first increment “project velocity” is used to

help define subsequent delivery dates for other
increments
 Extreme Programming (XP)…
53

 XP Design
Follows the KIS principle
Encourage the use of CRC cards
For difficult design problems, suggests the
creation of “spike solutions”—a design
prototype
Encourages “refactoring”—an iterative
refinement of the internal program design
 Extreme Programming (XP)…
54

 XP Coding
Recommends the construction of a unit test
for a story before coding commences
Encourages “pair programming”
 XP Testing

All unit tests are executed daily (whenever

code is modified)
“Acceptance tests” are defined by the
customer and executed to assess customer
visible functionality
 Extreme Programming (XP)…
55
spike solut ions
simple design
prot ot ypes
CRC cards
user st ories
values
accept ance t est crit eria
it erat ion plan

refact oring

pair
programming

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

accept ance t est ing

 Questions and Discussion
56