CSE 305 SOFTWARE ENGINEERING

Dr. Sobin C C
Associate Professor
Dept. of CSE
SRM AP

1
What is Software ?
• A program is set of instructions

• Software can define as:

■ Set of Instructions/ programs – executed provide
desire features, function & performance
■ Documentation
■ Operation Manuals

2
• Write a program to print your name
(any language)

3
Simple Program
#include <stdio.h>
void main()
{
char name [20];
printf(“Enter your name”);
scanf(“%s”, &name);
printf(“your name is: %s”, name);
}
4
Software
• Documentation manuals:
■ Requirement Analysis
⬥ Formal specification, context-diagram, DFD
■ Software Design
⬥ Flow charts, ER
■ Implementation
⬥ Source code, Cross Reference listing
■ Testing
⬥ Test data, Test results
• Operation Manuals :
■ User manuals
■ System overview, Beginners user tutorial, reference guide,
reference guide
■ Operation manuals
■ Installation guide, System administration guide
5
WELL-KNOWN
SOFTWAREENGINEERING FAILURES
• On 4 June 1996 the maiden
flight of the Ariane 5 launcher
ended in a failure. Only about
40 seconds after initiation of
the flight sequence, at an
altitude of about 3700 m, the
launcher diverted off its flight
path, broke up and exploded

6
Reason for Failure -Ariane 5 Rocket
• Integer Over flow
■ An integer overflow occurs when
an arithmetic operation attempts
to create a numeric value that is
outside of the range that can be
represented with a given number
of digits – either higher than the
maximum or lower than the
minimum representable value
■ E.g x= 2147483647 + 1

7
 Y2K (1999-2000)

• Cost–$500,000,000,000
• Cause
■ To save computer storage space, old software
systems often stored the years as two-digit numbers
■ The software interpreted “00” to mean 1900 rather 8
Software Product Vs Process

• Software Product: what is delivered to the

customer. It may include source code,
specification document, manuals,
documentation, etc.

• Software Process: Process is the way in which

produce the software.

9
Software Process
• Reasons why it is difficult to improve
the process
■ No enough time
■ Lack of knowledge
■ Wrong motivations
■ Insufficient commitment

10
Software Process

11
Hardware vs. Software
Hardware Software

□ Manufactured □ Developed/ engineered

□ wear out □ deteriorate
□ Built using components □ Custom built
□ Relatively simple □ Complex

12
Manufacturing vs. Development
• Once a hardware product has been manufactured, it
is difficult or impossible to modify. In contrast,
software products are routinely modified and
upgraded.
• In hardware, hiring more people allows you to
accomplish more work, but the same does not
necessarily hold true in software engineering.
• Unlike hardware, software costs are concentrated in
design rather than production.

13
Failure curve for Hardware

14
 Failure curve for Software

When a hardware component wears out, it is replaced by a spare part.

There are no software spare parts. Every software failure indicates an error in
design or in the process through which design was translated into machine
executable code.
15
Software characteristics

• Software is developed or engineered; it is not

manufactured.
• Software does not “wear out” but it does
deteriorate.
• Software continues to be custom built, as
industry is moving toward component based
construction.
• Reusability of components.
• Software is flexible.
16
Software Application Domains
• System software
• Application software
• Engineering/scientific software
• Embedded software
• Product line software
• Web applications
• Artificial intelligence software
17
Software Application Domains
• System Software:
■ System software is a collection of programs written to service other
programs.
■ It is characterized by heavy interaction with computer hardware;
heavy usage by multiple users; concurrent operation that requires
scheduling, resource sharing, and sophisticated process
management; complex data structures; and multiple external
interfaces.
■ Ex. Compilers, operating system, drivers etc.
• Business Software :
■ Application software consists of standalone programs that solve a
specific business need.
■ Application software is used to control the business function in
real-time.
• Engineering /Scientific software:
■ Characterized by "number crunching" algorithms.
■ Applications range from astronomy to volcano logy, from automotive
stress analysis to space shuttle orbital dynamics, and from molecular
biology to automated manufacturing.
■ Ex. Computer Aided Design (CAD), system stimulation etc.
18
Software Application Domains
• Embedded Software:
■ It resides in read-only memory and is used to control products and systems
■ Embedded software can perform limited functions.
■ Ex. keypad control for a microwave oven.

• Personal Computer software:

■ Designed to provide a specific capability for use by many different
customers, product line software can focus on a limited and esoteric
marketplace.
■ Ex. Word processing, spreadsheet, CG, multimedia, etc.
• Web Applications:
■ Web apps can be little more than a set of linked hypertext files.
■ It is evolving into sophisticated computing environments that not only
provide standalone features, functions but also integrated with corporate
database and business applications.
• Artificial Intelligence software
■ AI software makes use of non-numerical algorithms to solve complex
problems that are not amenable to computation or straightforward analysis
■ Ex. Robotics, expert system, game playing, pattern Recognition, ANN etc.

19
Software Applications – New
• 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!)
• And also …
• Data mining
• Grid computing
• Cognitive machines
• Software for nanotechnologies 20
Engineering
• “The systematic and regular application of scientific and
mathematical knowledge to the design, construction, and
operation of machines, systems, and so on of practical use
and, hence, of economic value.

• Particular characteristic of engineers is that they take

seriously their responsibility for correctness, suitability, and
safety of the results of their efforts.

• In this regard they consider themselves to be responsible

to their customer (including their employers where
relevant), to the users of their machines and systems, and
to the public at large.”

21
Engineering

22
Software Engineering
• Engineering is the use of scientific principles to
design and build machines, structures, and other
items, including bridges, tunnels, roads, vehicles, and
buildings.

• According to Fritz Bauer :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.

• According to IEEE : Software Engineering is a a

systematic, disciplined, quantifiable approach to the
development, operation, and maintenance 23of
Why need Software
Engineering?
• It allows you to improve the quality of the software
products.
• To increase productivity & provide job satisfaction to
software professionals.
• It will enable you to control software schedules and to
plan effectively.
• It helps to reduce the cost of software development.
• Allow you to meet the customers' needs and
requirements.
• It helps you to support the engineers' activities
systematically and efficiently.
24
Software myths
• Software is easy to change.
• Computers provide greater reliability than the devices
they replace.
• Testing software can remove all the errors.
• Reusing the software increases the safety.
• Software can work right the first time.
• Software can be designed thoroughly enough to avoid
most integration problems.
• Software with more features is better software.
• Addition of more software engineers will make up the
delay.
• Aim to develop working programs.

25
26
Breakout
Software Process

• Software Process: Process is the way in which

produce the software.

28
Software Engineering: A
Layered Technology

29
Layered Technology
A quality Focus
• Every organization is rest on its commitment to quality.
• Total Quality Management, Six Sigma, or similar continuous
improvement culture and it is this culture ultimately leads to
development of increasingly more effective approaches to
software engineering.
• The bedrock that supports software engineering is a quality
focus.
Process:
• It is a foundation layer for software engineering.
• It defines framework for a set of Key Process Areas for
effectively manage and deliver quality software in a
cost-effective manner
• The processes define the tasks to be performed and the order
in which they are to be performed 30
 Layered Technology

Methods:
• It provides the technical how-to's for building software.
• Methods encompass a broad array of tasks that include
requirements analysis, design, program construction, testing, and
support.
• There could be more than one technique to perform a task and
different techniques could be used in different situations.

Tools:
• Provide automated or semi-automated support for the process,
methods and quality control.
• When tools are integrated so that information created by one tool
can be used by another, a system for the support of software
development, called Computer-Aided Software Engineering (CASE)
A Generic Software Process Model

A software process – as
a framework for the tasks
that are required to build
high-quality software.

32
 Process framework
Why process :
• A process defines who is doing what, when and how
to reach a certain goal.

• To build complete software process.

• Identified a small number of framework activities that

are applicable to all software projects, regardless of
their size or complexity.

• It encompasses a set of umbrella activities that are

applicable across the entire software process.
33
Process Framework

•Each framework
activities is populated
by a set for software
engineering actions – a
collection of related
tasks.
• Each action has
individual work task.

34
Generic Process Framework Activities

1. Communication:
■ Heavy communication with customers, stakeholders,
team members

■ Encompasses requirements gathering and related

activities

2. Planning:
■ Workflow that is to follow
■ Software project plan- describe technical task, likely
risk, resources will require, work products to be
produced and a work schedule.

35
Generic Process Framework Activities
3. Modeling:
■ Help developer and customer to understand
requirements (analysis of requirements) & design of
software
4. Construction:
■ Code generation: either manual or automated or both
■ Testing – to uncover error in the code
5. Deployment:
■ Delivery to the customer for evaluation
■ Customer provide feedback

36
Umbrella Activities

• Software project tracking and control

■ Assessing progress against the project plan
■ Take adequate action to maintain schedule
• Formal technical reviews
■ Assessing software work products in an effort to uncover
and remove errors before goes into next action or activity
• Software quality assurance
■ Define and conducts the activities required to ensure
software quality
• Software configuration management
■ Manages the effects of change
37
Umbrella Activities
• Document preparation and production
■ Help to create work products such as models, documents, logs,
form and list.
• Reusability management
■ Define criteria for work product reuse
■ Mechanisms to achieve reusable components.
• Measurement
■ Define and collects process, project, and product measures
■ Assist the team in delivering software that meets customer’s
needs.
• Risk management
38
■ Assesses risks that may affect that outcome of project or quality
 Process Flow

Process Flow– describes

how framework activities
and actions (in it) are
organized w.r.t sequence
and time.

39
Process Flow (Contd.)
• Linear process flow executes each of the five
activities in sequence.

• An iterative process flow repeats one or more of the

activities before proceeding to the next.

40
 Process Flow (Contd.)
• An evolutionary process flow executes the activities in a
circular manner. Each circuit leads to a more complete
version of the software.

• A parallel process flow executes one or more activities

in parallel with other activities modeling for one aspect
of the software in parallel with construction of another
aspect of the software.

41
Identifying a Task Set
• Before proceeding with the process model: what
actions are appropriate for a framework activity
given the nature of the problem, the characteristics
of the people and the stakeholders?
• A task set defines the actual work to be done to
accomplish the objectives of a software engineering
action.
■ A list of the task to be accomplished

■ A list of the work products to be produced

■ A list of the quality assurance

42
filters to be applied
 Identifying a Task Set
• For example, requirements gathering (elicitation) is
an important software engineering action that occurs
during the communication activity.

• Requirements gathering is also to understand what

various stakeholders want from the software that is
to be built.

43
 Example of a Task Set
• The task sets for requirements gathering action for a
simple project may include:
■ Make a list of stakeholders for the project.
■ Invite all stakeholders to an informal meeting.
■ Ask each stakeholder to make a list of features and
functions required.
■ Discuss requirements and build a final list.
■ Prioritize requirements.
■ Note areas of uncertainty.

44
 Example of a Task Set
• The task sets for requirements gathering action for a
big project may include:
1. Make a list of stakeholders for the project.
2. Interview each stakeholder separately to determine
overall wants and needs.
3. Build a preliminary list of functions and features based
on stakeholder input.
4. Schedule a series of facilitated application specification
meetings.
5. Conduct meetings.
6. Produce informal user scenarios as part of each meeting.
45
 Example of a Task Set
7. Refine user scenarios based on stakeholder feedback.
8. Build a revised list of stakeholder requirements.
9. Use quality function deployment techniques to prioritize
requirements.
10. Package requirements so that they can be delivered
incrementally.
11. Note constraints and restrictions that will be placed on
the system.
12. Discuss methods for validating the system.

46
Project Activity -1
• Make a list of stakeholders for the
project.

• Identify the basic requirements.

48
Process Patterns

• A process pattern:
■ describes a process-related problem that is
encountered during software engineering work,

■ identifies the environment in which the problem

has been encountered, and

■ suggests one or more proven solutions to the

problem.
• It provides a template, a consistent method for
describing problem solutions within the context
of the software process.
49
Process Pattern Types

• Stage patterns—defines a problem associated with a

framework activity for the process.

• Task patterns—defines a problem associated with a

software engineering action or work task and
relevant to successful software engineering practice.

• Phase patterns—define the sequence of framework

activities that occur with the process, even when
the overall flow of activities is iterative in nature.

50
Process Assessment & Improvement

• Standard CMMI Assessment Method for Process

Improvement (SCAMPI) — provides a five step
process assessment model that incorporates five
phases: initiating, diagnosing, establishing, acting
and learning.

• CMM-Based Appraisal for Internal Process

Improvement (CBA IPI)—provides a diagnostic
technique for assessing the relative maturity of a
software organization; uses the SEI CMM as the
basis for the assessment [Dun01]

51
Process Assessment and Improvement

• SPICE—The SPICE (ISO/IEC15504) standard

defines a set of requirements for software process
assessment. The intent of the standard is to assist
organizations in developing an objective
evaluation of the efficacy of any defined software
process. [ISO08]

• ISO 9001:2000 for Software—a generic standard

that applies to any organization that wants to
improve the overall quality of the products,
systems, or services that it provides. Therefore, the
standard is directly applicable to software
organizations and companies. [Ant06]
52
53
Process Models
 Software process model
• Process models prescribe a distinct set of activities,
actions, tasks, milestones, and work products required
to engineer high quality software.

• Process models are not perfect but provide roadmap for

software engineering work.

• Software models provide stability, control, and

organization to a process that if not managed can easily
get out of control.

• Software process models are adapted to meet the needs

of software engineers and managers for a specific
project.
Build and Fix Model
Build and Fix Model
• The earlier approach.
• Product is constructed without specification or any
attempt at design.

• Developers simply build a product that is reworked as

many times as necessary to satisfy the client.

• Model may work for small projects (e.g.,100-200

LOC) but is totally unsatisfactory for products of any
reasonable size.

• Maintenance is high.
Prescriptive Model
• Prescriptive process models advocate an orderly
approach to software engineering
■ Organize framework activities in a certain order

• Process framework activity with set of software

engineering actions.

• Each action in terms of a task set that identifies the

work to be accomplished to meet the goals.
Prescriptive Model
• The resultant process model should be adapted to
accommodate the nature of the specific project,
people doing the work, and the work environment.

• Software engineer choose process framework that

includes activities like;
■ Communication

■ Planning

■ Modeling

■ Construction

■ Deployment
The Waterfall Model

• Also called as classical/linear model.

• It is the oldest paradigm for SE.
• When requirements are well defined and
reasonably stable, it leads to a linear fashion.

60
Waterfall Model (contd.)
• Requirement Analysis and Definition: systems
services, constraints and goals are defined by
customers with system users.
• Scheduling tracking:
■ Assessing progress against the project plan.
■ Require action to maintain schedule.

■ System and Software Design: establishes and overall

system architecture. Software design involves
fundamental system abstractions and their
relationships.
Waterfall Model (contd.)
• Integration and system testing: The individual
program unit or programs are integrated and tested
as a complete system to ensure that the software
requirements have been met. After testing, the
software system is delivered to the customer.

• Operation and Maintenance: Normally this is the

longest phase of the software life cycle. The system
is installed and put into practical use. Maintenance
involves correcting errors which were not discovered
in earlier stages of the life-cycle.
Waterfall Model - Examples
• In the olden days, Waterfall model was used to
develop enterprise applications like Customer
Relationship Management (CRM) systems, Human
Resource Management Systems (HRMS), Supply Chain
Management Systems, Inventory Management
Systems, Point of Sales (POS) systems for Retail
chains etc.
• Waterfall is still widely used in traditional
organizational environments and processes. Research
shows that 51% of organizations still use Waterfall,
based on a 2017 report from the Project Management
Institute.
Waterfall Model - Advantages
• All phases are clearly defined.

• One of the most systemic methods for software

development.

• Being oldest, this is one of the time-tested models.

• It is simple and easy to use.

Waterfall Model - Drawbacks
• Difficult to define the all the requirements at the
beginning of the project.

• Model is not suitable for accommodating any change.

• A working version of the system is not seen until late

in the project’s life.

• It does not scale up well to large projects.

• Real projects are rarely sequential.

The V-Model
• A variation of waterfall model depicts the relationship of
quality assurance actions to the actions associated with
communication, modeling and early code construction
activates.
■ Team first moves down the
left side of the V to refine V
the problem requirements. E V
R A
■ Once code is generated, I L
F
the team moves up the I
I
D
right side of the V, C A
performing a series of tests A T
T I
that validate each of the I O
models created as the O N
team moved down the left N
side. 10
67
Incremental Process Model

C- Communication
P - Planning
M – Modeling
C - Construction
D - Deployment

• Delivers software in small but usable pieces, each

piece builds on pieces already delivered
The Incremental Model
• Rather than deliver the system as a single delivery,
the development and delivery is broken down into
increments with each increment delivering part of the
required functionality.
• First Increment is often core product
■ Includes basic requirement
■ Many supplementary features (known & unknown)
remain undelivered
• A plan of next increment is prepared
■ Modifications of the first increment
■ Additional features of the first increment
The Incremental Model

• It is particularly useful when enough staffing is not

available for the whole project.

• Increment can be planned to manage technical risks.

• Incremental model focusses more on delivery of

operation product with each increment.
Incremental Model - Advantages

• Rigid nature of sequential approach.

• This method is great help when organization is low on
staffing.
• Generate working software quickly and early during the
software life cycle.
• More flexible – less costly to change scope and
requirements.
• Easier to test and debug during a small iteration.
• Easier to manage risk because risky pierces are
identified and handled during its iteration.
• Each increment is an easily managed milestone.
Incremental Model -Disadvantages

• This model could be time consuming.

• Each phase of an increment is rigid and do not

overlap each other.

• Problems may arise in system architecture; all the

requirements are not gathered up entire software life
cycle.
Evolutionary Process Model
• Produce an increasingly more complete version of
the software with each iteration.

• Evolutionary Models are iterative.

• Evolutionary models are:
■ Prototyping

■ Spiral Model

■ Concurrent Development Model

Evolutionary Models:
Prototyping

Quick
plan
communicatio
n
Modeling
Quick design

Deployment Constructio
delivery & n
feedback Constructio
of prototype
n
of prototype

74
Prototyping cohesive
• Best approach when:

■ Objectives defines by customer are general but

does not have details like input, processing, or
output requirement.

■ Developer may be unsure of the efficiency of an

algorithm, O.S., or the form that human machine
interaction should take.

• It can be used as standalone process model.

• Model assist software engineer and customer to better

understand what is to be built when requirement is
Prototyping cohesive
• Prototyping start with communication, between a
customer and software engineer to define overall
objective, identify requirements and make a boundary.

• Going ahead, planned quickly and modeling (software

layout visible to the customers/end-user) occurs.

• Quick design leads to prototype construction.

• Prototype is deployed and evaluated by the

customer/user.

• Feedback from customer/end user will refine

requirement and that is how iteration occurs during
prototype to satisfy the needs of the customer.
Prototyping (cont..)
• Prototype can be serve as “the first system”.

• Both customers and developers like the prototyping

paradigm.

■ Customer/End user gets a feel for the actual system

■ Developer get to build something immediately.

Prototyping - Disadvantages
• Customer cries foul and demand that “a few fixes” be
applied to make the prototype a working product, due
to that software quality suffers as a result.

• Developer often makes implementation in order to get

a prototype working quickly without considering other
factors in mind like OS, Programming language, etc.

• Customer and developer both must be agree that the

prototype is built to serve as a mechanism for defining
requirement.
Evolutionary Models: The
Spiral

79
Spiral Model
• Combines iterative nature of prototyping with the
controlled and systematic aspects of the linear
sequential model.

• It provides potential for rapid development of

increasingly more complete version of the software.

• Using spiral, software developed in as series of

evolutionary release.
■ Early iteration, release might be on paper or
prototype.
■ Later iteration, more complete version of software.
Spiral Model
• Divided into framework activities (C,P,M,C,D). Each
activity represents one segment.
• Evolutionary process begins in a clockwise direction,
beginning at the center risk.
• First circuit around the spiral might result in
development of a product specification. Subsequently,
develop a prototype and then progressively more
sophisticated version of software.
• Unlike other process models that end when software is
delivered.
• It can be adapted to apply throughout the life of
software.
Spiral Model - Advantages
• It is realistic approach for development for large
scale system.

• High amount of risk analysis.

• Good for large and mission-critical projects.

• Software is produced early in the software life

cycle.
Spiral Model - Disadvantages
• It is not widely used and can be a costly to use.

• Risk analysis requires highly specific expertise.

• Project’s success is highly dependent on the risk

analysis phase.

• Doesn’t work well for smaller projects.

• It demands considerable risk assessment

expertise and relies on this expertise for success.

• It may be difficult to convince customers that the

evolutionary approach is controllable.
84
Quiz 2
Breakout
 Data Flow Diagram
• A Data Flow Diagram (DFD) is a graphical
representation of the "flow" of data through an
information system.

• It differs from the system flowchart as it shows the

flow of data through processes instead of computer
hardware.

• Data flow diagrams were invented by Larry

Constantine, developer of structured design, based
on Martin and Estrin's "data flow graph" model of
computation.
 Data Flow Diagram
• It is common practice to draw a System Context
Diagram first which shows the interaction between
the system and outside entities.

• The DFD is designed to show how a system is

divided into smaller portions and to highlight the
flow of data between those parts.

• This context-level Data flow diagram is then

"exploded" to show more detail of the system being
modeled.
DFD Notations
 Creating Data Flow Diagrams
• Creating DFDs is a highly iterative process of gradual refinement.
• General steps:
• Create a preliminary Context Diagram
• Identify Use Cases, i.e., the ways in which users most
commonly use the system
• Create DFD fragments for each use case
• Create a Level 0 diagram from fragments
• Decompose to Level 1,2,…
• Go to step 1 and revise as necessary
• Validate DFDs with users.
Context Diagram– DFD ATM

request User
Transaction requests

Bank
Database display

Balance ATM
Informatio
n
receipt

Printer
Account data
Informatio
n
request
User
Database
A level 0 DFD
Printer/dis
Bank Customer’s play
Database Card
details Rejection
message
1.0
Validate
Customer 2.0
access Reject
transaction
Access \and end session
PI
map
N
Access
authorizatio Network
n
directory
Rejection
Access
custome 3.0
permissions
message

r Obtain
Details of
transaction
select 4.0
Validate
options transaction
Transactio
n
request
User
Database
A level 1 DFD
Card Customer’s
Card
Reader details Cannot
1.1
Read
Read card
Details
From
card Card Printer/dis
data play
Encoded
pin
1.2
Check
Expiry date
custom PIN
1.3
And bank group
Request
er Pin
And match Card
Max 3 attempts Validation
data
Access
map
Invalid
pin
Access
authorizatio Network
n User directory
Database
Context Diagram
• Shows the context into which the
business process fits
• Shows the overall business process as
just one process
• Shows all the outside entities that
receive information from or contribute
information to the system

Slide 94
Level 0 Diagram
• Shows all the processes that comprise
the overall system
• Shows how information moves from and
to each process
• Adds data stores
Level 1 Diagrams
• Shows all the processes that comprise a
single process on the level 0 diagram
• Shows how information moves from and to
each of these processes
• Shows in more detail the content of higher
level process
• Level 1 diagrams may not be needed for all
level 0 processes

Slide 96
Level 2 Diagrams

• Shows all processes that comprise a single

process on the level 1 diagram
• Shows how information moves from and to
each of these processes
• Level 2 diagrams may not be needed for all
level 1 processes
• Correctly numbering each process helps the
user understand where the process fits into
the overall system
Slide 97
Relationship Among DFD
levels

Slide 98
Decomposition Diagram
 Class Work

✧ Prepare Context Diagram for your project.

✧ Convert into Level 0 & Level1 DFD

✧ https://www.visual-paradigm.com/tutorials/data-flow-diag
ram-example-cs-system.jsp

100
More Process Models
Concurrent Development Model
• It represented schematically as series of major
technical activities, tasks, and their associated states.

• It is often more appropriate for system engineering

projects where different engineering teams are
involved.

• The activity-modeling may be in any one of the states

for a given time.
Evolutionary Models: Concurrent

103
Concurrent Development Model
• All activities exist concurrently but reside in different
states.
■ The analysis activity (existed in the none state while
initial customer communication was completed) now
makes a transition into the under-development state.

■ Analysis activity moves from the under-development

state into the awaiting changes state only if customer
indicates changes in requirements.

■ Series of event will trigger transition from state to

state.

■ E.g. during initial stage there was inconsistency in

design which was uncovered. This will trigger the
analysis action from the done state into awaiting
changes state.
 Specialized Process Models
• Component based development—the process to apply when
reuse is a development objective

• Formal methods—emphasizes the mathematical

specification of requirements

• Aspect Oriented software development (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)

105
Component Based Development

• Component-Based Development (CBD) model

incorporates many of the characteristics of the spiral
model.

• It is evolutionary by nature and iterative approach to

create software.

• CBD model creates applications from prepackaged

software components (called classes).
SDLC: Component Based
Development
 CBD model (cont.)

• Modeling and construction activities begin with identification

of candidate components.
• Classes created in past software engineering projects are
stored in a class library or repository.
• Once candidate classes are identified, the class library is
searched to determine if these classes already exist.
• If class is already available in library extract and reuse it.
• If class is not available in library, it is engineered or
developed using object-oriented methods.
• Any new classes built to meet the unique needs of the
application.
• Now process flow return to the spiral activity.
CBD model - Advantages
• CBD model leads to software reusability.

• Based on studies, CBD model leads to 70 %

reduction in development cycle time.

• 84% reduction in project cost.

• Productivity is very high.

Unified Process

• Good Start => Unified Process (UP) is a standard

development process within the object-oriented and
component-based software communities.

• Product => Rational Unified Process (RUP)

• More Needed => Enterprise Unified Process (EUP) is

a software process that reflects the full lifecycle of
software-based systems.
3 Key Aspects of UP
1. Use-case driven

2. Architecture-centric

3. Iterative and incremental

I. Use-Case Driven
• Use-Case driven means, development process
proceeds through a series of workflows that
derive from use cases.

• The phrase “use case driven” refers to the fact

that the project team uses the use cases to drive
all development work, from initial gathering and
negotiation of requirements through code
3 Terminologies
• Users: someone or something that interact with
system.

• Use Case: interaction between users and system.

■ what is the system supposed to do for each user?

■ Use Case Model: collection of use cases; description

of complete functionality.
Example of Use-Case Diagram
II. Architecture-Centric
• Architecture is the view of the whole design with
key characteristics and without too many details.

■ Only 5-10% use cases

■ Growth with use case in parallel (structure and
function)
Use case & Architecture

Use case

driv influenc
e e

System
architecture
III. Iterative and Incremental
• Iteration: Steps in the workflow (mini-project)

■ Create a design for relevant use cases

■ Implement with components

■ Required iteration in logical order for economy

■ Increments: Growth in the product (might not

be additive)
Benefits to controlled iteration
• Reduce the cost risk to the expenditures on a
single increment

• Reduce the risk of delayed product delivery (find

the risks earlier)

• Speed up the tempo of the whole development

effort

• Easier to adapt to the requirement modification

The Unified Process (UP)

119
UP Phases

120
 Inception Phase
• Encompasses both customer communication and
planning activities of the generic process
• Business requirements for the software are identified
• A rough architecture for the system is proposed
• A plan is created for an incremental, iterative
development
• Fundamental business requirements are described
through preliminary use cases
■ A use case describes a sequence of actions that are
performed by a user 121
 Elaboration Phase
• Encompasses both the planning and modelling activities
of the generic process
• Refines and expands the preliminary use cases

• Often results in an executable architectural baseline that

represents a first cut executable system

• The baseline demonstrates the viability of the

architecture but does not provide all features and
functions required to use the system

122
 Construction Phase
• Encompasses the construction activity of the generic
process
• Uses the architectural model from the elaboration phase
as input
• Develops or acquires the software components that
make each use-case operational
• Analysis and design models from the previous phase are
completed to reflect the final version of the increment
• Use cases are used to derive a set of acceptance tests
that are executed prior to the next phase
123
 Transition Phase
• Encompasses the last part of the construction activity
and the first part of the deployment activity of the
generic process

• Software is given to end users for beta testing and user

feedback reports on defects and necessary changes

• The software teams create necessary support

documentation (user manuals, trouble-shooting guides,
installation procedures)

• At the conclusion of this phase, the software increment

becomes a usable software release 124
 Production Phase
• Encompasses the last part of the deployment activity of
the generic process

• On-going use of the software is monitored

• Support for the operating environment (infrastructure) is

provided

• Defect reports and requests for changes are submitted

and evaluated

125
UP strengths
• Based on sound Software Engineering principles.

• Mechanisms that provide management visibility

into the development process.

• HTML-based description of the UP.

UP weaknesses
• Only developing process, not the entire software
process.

• Not supporting multi-system infrastructure

development efforts.

• Iterative nature foreign to experienced developers.

• Tool-driven approach, not sufficient for complex

system.
128
Quiz 3
Agile Process
AGILE MANIFESTO

131
 What is “Agility”?
• Motivation for Agile—modern economy requirements
• Agile combines a philosophy and 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

132
 What is “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
• Yielding …
• Rapid, incremental delivery of software

133
 What is “Agility”?

• Agile is a time boxed, iterative approach to software

delivery that builds software incrementally from the
start of the project, instead of trying to deliver it all at
once near the end.
• It works by breaking projects down into little bits of
user functionality called user stories, prioritizing them,
and then continuously delivering them in short
two-week cycles called iterations.
134
Why Use Agile Methods

• Improve Customer Involvement

• Increase Quality

• Simplify Releases

• Drive Down Risk

135
WATERFALL vs AGILE

136
WATERFALL vs AGILE

137
Agile Vs Traditional Methods

138
Agility and the Cost of Change

139
An Agile Process
• 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

140
Agility Principles - I
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. 141
Agility Principles - II
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.
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.
142
Agile Methods
• Scrum
• Extreme Programming (XP)
• Adaptive Software Development (ASD)
• Dynamic System Development Method (DSDM)
• Agile modeling
• Agile Unified Process (AUP)
• Crystal Clear Methods
• Disciplined agile delivery
• Feature-driven development (FDD)
• Lean software development
• Kanban (development)
143
Extreme Programming (XP)

144
 Extreme Programming (XP)
• The most widely used agile process, originally proposed
by Kent Beck
1. XP Planning
■ Begins with the creation of “user stories”

■ 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

145
 Extreme Programming (XP)
2. XP Design
■ Follows the K.I.S (Keep It Simple) principle
■ Encourage the use of CRC cards (Class Responsibility Collaborator)
■ For difficult design problems, suggests the creation of “spike
solutions”—a design prototype
■ Encourages “refactoring”—an iterative refinement of the internal
program design
3. XP Coding
■ Recommends the construction of a unit test for a store before coding
commences
■ Encourages “pair programming”
4. XP Testing
■ All unit tests are executed daily
■ “Acceptance tests” are defined by the customer and executed to
assess customer visible functionality
146
Core Values of XP
• Communication
• Simplicity
• Feedback
• Courage
• Respect

147
XP Values: Communication
• Poor communication in software teams is one
of the root causes of failure of a project
• Stress on good communication between all
stakeholders--customers, team members,
project managers
• Customer representative always on site
• Paired programming

148
XP Values: Simplicity
• ‘Do the Simplest Thing That Could Possibly
Work’
■ Implement a new capability in the simplest
possible way
■ Refactor the system to be the simplest possible
code with the current feature set
• ‘You Aren’t Going to Need It’
■ Never implement a feature you don’t need now
• Developers strive to write simple code
bringing more value to a product, as it saves
time and effort.
149
XP Values: Feedback
• Always a running system that delivers
information about itself in a reliable way
• The system and the code provides feedback
on the state of development
• Catalyst for change and an indicator of
progress

150
XP Values
• Courage. Programmers objectively evaluate their
own results without making excuses and are
always ready to respond to changes.

• Respect. The agile team inculcates respect

among it members, between other stakeholders
and team members, and indirectly, for the
software itself.

151
Agile Model- Advantages
• Speedy and continuous delivery of the software ensures
customer satisfaction.
• All the stakeholders (customers, developers, and testers)
are involved in the process which leads to technical
excellence and good design.
• It facilitates close interaction between business people and
developers.
• Its flexibility ensures the adaptation to changing
circumstances. Changes added at the last moment or at a
later stage of development can be incorporated without
any problem.
152
Agile Model- Disadvantages
• The development team should be highly professional and
client-oriented.
• New requirement may be a conflict with the existing
architecture.
• With further correction and change, there may be chances
that the project will cross the expected time.
• There may be difficult to estimate the final cost of the
project due to constant iteration.
• A defined requirement is absent.
153
154
Quiz 4
Breakout
XP Practices

(Source: http://www.xprogramming.com/xpmag/whatisxp.htm)
157
 XP Practices: Planning Game
• Planning for the upcoming iteration
• Uses stories provided by the customer
• Technical persons determine schedules,
estimates, costs, etc
• A result of collaboration between the
customer and the developers
• Advantages
■ Reduction in time wasted on useless features
■ Greater customer appreciation of the cost of a
feature
■ Less guesswork in planning
• Disadvantages
■ Customer availability
158
■ Is planning this often necessary?
XP Practices: Planning Game
• XP Release Planning
■ Customer presents required features
■ Programmers estimate difficulty
■ Imprecise but revised regularly
• XP Iteration Planning
■ Two week iterations
■ Customer presents features required
■ Programmers break features down into tasks
■ Team members sign up for tasks
■ Running software at end of each iteration

159
XP Practices: Small Releases
• Small in terms of functionality
• Team releases running, tested software every iteration
• The Customer can evaluate or in turn, release to end users,
and provide feedback
• Important thing is that the software is visible and given to
the Customer at the end of every iteration
• Advantages
■ Frequent feedback
■ Tracking
■ Reduce chance of overall project slippage
• Disadvantages
■ Not easy for all projects
■ Versioning issues

160
XP Practices: Metaphor
• The oral architecture of the system
• XP Teams develop a common vision of the
system
• Define common system of names
• Ensure everyone understands how the
system works, where to look for functionality,
or where to add functionality
• Advantages
■ Encourages a common set of terms for the system
■ A quick and easy way to explain the system 161
XP Practices: Simple Design
• Build software to a simple design
• Through programmer, testing and design improvement, keep
the software simple and the design suited to current
functionality
• Not a one-time thing nor an up-front thing
• Design steps in release planning and iteration planning
• Teams design and revise design through refactoring, through
the course of the project
• Advantages
■ Easier to understand what is going on

■ Refactoring and collective ownership is made possible

■ Helps keeps programmers on track

162
XP Practices: Pair Programming
• Two Developers, One monitor, One Keyboard
• One “drives” and the other thinks
• Switch roles as needed
• Research into pair programming shows that
pairing produces better code in the same time
as programmers working singly
• Pairing also communicates knowledge
throughout the team

163
XP Practices: Test-Driven
Development
• Teams practice TDD by working in short
cycles of adding a test, and then making it
work
• Easy to produce code with 100 percent test
coverage
• These programmer tests or unit tests are all
collected together
• Each time a pair releases code to the
repository, every test must run correctly
164
XP Practices: Design
Improvement/ Refactoring
• Continuous design improvement process called
‘refactoring’:
■ Removal of duplication
■ Increase cohesion
■ Reduce coupling
• Refactoring is supported by comprehensive
testing--customer tests and programmer tests
• Prompts developers to proactively improve the
product as a whole
• Increases developer knowledge of the system
165
XP Practices: Continuous Integration
• New features and changes are worked
into the system immediately
• Teams keep the system fully integrated
at all times
• Daily, or multiple times a day builds
• Avoid ‘integration hell’
• Avoid code freezes
166
XP Practices: Collective Code
Ownership
• Any pair of programmers can improve any
code at any time
• No ‘secure workspaces’
• All code gets the benefit of many people’s
attention
• Avoid duplication
• Programmer tests catch mistakes
• Pair with expert when working on unfamiliar
code

167
XP Practices: Coding Standard
• Use common coding standard
• All code in the system must look as
though written by an individual
• Code must look familiar, to support
collective code ownership

168
XP Practices: Sustainable
Pace/40-Hour Week
• The work week should be limited to 40
hours
• Team will produce high quality product
when not overly exerted
• ‘Death march’ projects are unproductive
and do not produce quality software
• Work at a pace that can be sustained
indefinitely
169
XP Practices: Whole Team
• All contributors to an XP project are one team
• Must include a business representative--the
‘Customer’
■ Provides requirements
■ Sets priorities
■ Steers project
• Team members are programmers, testers,
analysts, coach, manager
• Best XP teams have no specialists
170
XP Practices: Customer
Tests/Testing
• The Customer defines one or more
automated acceptance tests for a feature
• Team builds these tests to verify that a
feature is implemented correctly
• Once the test runs, the team ensures that
it keeps running correctly thereafter
• System always improves, never backslides
• Unit testing
• Test-first design
• All automated 171