Chapter 4

Introduction to Software
Engineering

Prachi Shah
IT Dept.
BVM
Content
 Introduction to software
 Software characteristics
 Components
 Applications
 Layered technologies
◦ Processes, Methods and tools
◦ Generic view of software engineering
 Process models
◦ Waterfall model, Incremental model, RAD model
◦ Evolutionary process models: Prototype, Spiral and
concurrent development model
 Agile Development
◦ Agility and agile process
◦ Extreme programming
◦ Other agile process models: ASD, Scrum, DSDM, FDD
 Introduction to 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) descriptive information in both hard copy and virtual forms
that describes the operation and use of the programs.
 Software products may be:
1.Generic- That means developed to be sold to range of different
customers.
2.Custom- That means developed for a single customer
according to their specifications.
Software Characteristics
 Softwareis developed or engineered, not
manufactured.
◦ In software development process, problems can
be rectified.
 Software does not “wear out”.
◦ Software cant be replaced by another
components like Hardware.
 Most software is custom built rather than
being assembled from components.
◦ In Hardware components such as ICs,
capacitors and registers are assembled
according to design but this is not done while
building software.
Components
 Any software consist of three major
components – Programs, Documents,
Operating Procedure.
Program is one part of entire software.
Documentation consists of various
Manuals.(SRS and Different diagrams)
Procedure represent instructions for initial
setup.(User guide, Installation guide)
Applications
 System software
 Application software
 Engineering/scientific software
 Embedded software
 Product-line software
 WebApps (Web applications)
 AI software
What is 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).
 Layered Technologies
Software engineering is discipline in which theories,
methods and tools are applied to develop professional
software product.

Software Engineering Layers

Layered Technologies (Contd..)
 A quality management is a backbone of software
engineering technology (“degree of goodness”)

 Process defines the framework for timely delivery of

software (“what”)

 Here actual Method of implementation is carried out

with the help of analysis, design, coding and testing
(“how to”)

 Tools are used to bring automation in software

development process.
Some terms related to Software process

 Process
 Activity
 Action
 Task
Generic View of Software Engineering

A Software Process
 Generic View of Software Engineering
Common Process Framework:
It is characterized by Process Framework Activities, Task
sets and Umbrella Activities.
 Process Framework Activities:
1.Communication
2.Planning
3.Modeling
4. Constructions
5. Deployment (feedback of customer)
 Task Set:
The task set defines the actual work done in order to achieve the
software objective. It is divided to :
1.Collection of software engineering work task
2. Project milestones
3. Software quality assurance points
Common Process Framework
(Continued)
 Umbrella Activities:
1.Software project tracking and control (Progress and schedule)
2.Risk Management (may affect project outcomes)
3. SQA (to maintain quality)
4. Formal technical review (remove errors)
5. Software configuration management (effect of change)
6. Work product preparation and production (to create models,
log, documentation)
7. Reusability management
8. Measurement
Types of Process flows
 Linear Process flow
 Iterative Process flow
 Evolutionary Process flow
 Parallel Process flow
Process models
 Waterfall Model / Linear Sequential Model
 Incremental Model
 Rapid Application Development (RAD) Model
 Evolutionary Process Models:
◦ Prototype Model
◦ Spiral Model
◦ Concurrent Development Model
Waterfall Model
Waterfall Model
 The project is divided in to separate distinct phases
 Each next phase starts after finishing the previous
phase
 Each phase communicate to next through pre
specified output
 When an error is detected or revision is required it
is traced back to one previous phase at a time, until
it gets resolved at some earlier phase
Waterfall Strengths
 Easy to understand, easy to use
 Provides structure to inexperienced staff
 Milestones are well understood
 Sets requirements stability
 Good for management control (plan, staff, track)
 Works well when quality is more important than
cost or schedule
Waterfall deficiencies
 All requirements must be known upfront
 Deliverables created for each phase are
considered frozen(unmoving) – reduce
flexibility
 Can give a false impression of progress
 Does not reflect problem-solving nature of
software development – iterations of
phases
 Integration is one big bang at the end
 Little opportunity for customer to preview
the system (until it may be too late)
When to use the Waterfall Model
 Requirements are very well known
 Product definition is stable i.e. Deliverables of each
Phase can be frozen.
 Technology is understood
 New version of an existing product
 Porting an existing product to a new platform.
Incremental SDLC Model
Incremental SDLC Model
 Combines elements of Linear and Parallel process
flows
 Construct a partial implementation of a total system
 Then slowly add increased functionality
 The incremental model prioritizes requirements of the
system and then implements them in groups
 Each subsequent release of the system adds
function to the previous release, until all designed
functionality has been implemented
Incremental Model Strengths
 Develop high-risk or major functions first
 Each release delivers an operational product
 Customer can respond to each build
 Uses “divide and conquer” breakdown of tasks
 Initial product delivery is faster
 Customers get important functionality early
 Risk of changing requirements is reduced
Incremental Model Weaknesses
 Requires good planning and design
 Requires early definition of a complete and
fully functional system to allow for the
definition of increments
 Well-defined module interfaces are required
(some will be developed long before others)
 Total cost of the complete system is not
lower
When to use the Incremental Model
 Funding, schedule, program complexity, or need for
early realization of benefits.
 Most of the requirements are known up-front but are
expected to evolve over time
 A need to get basic functionality to the market early
 On projects which have lengthy development
schedules
 On a project with new technology
Rapid Application Development
(RAD) Model Team # n
M o d e lin g
business m odeling
dat a m odeling
process m odeling

C o n s t r u c t io n
com ponent reuse
Team # 2 aut om at ic code
Com municat ion generat ion
t est ing
Mo d eling
b u si n e ss m o d e l i n g
dat a m odeling
p ro ce ss m o d e l i n g

Planning
Co nst r uct io n De ployme nt
Team # 1 co m p o n e n t re u se int egrat ion
au t o m a t i c co d e
g e n e ra t i o n deliv ery
Mode ling t e st i n g feedback
business modeling
dat a modeling
process modeling

Const r uct ion

component reuse
aut omat ic code
generat ion
t est ing

6 0 - 9 0 days
Rapid Application Development
Model (RAD)
 An incremental software process model
 Having a short development cycle
 High-speed adoption of the waterfall model using a
component based construction approach
 Creates a fully functional system within a very short
span time of 60 to 90 days
 Multiple software teams work in parallel on different
functions
 Modeling encompasses three major phases:
Business modeling, Data modeling and process
modeling
 Construction uses reusable components, automatic
code generation and testing
 RAD Strengths
 Reduced cycle time and improved productivity with
fewer people means lower costs
 Time-box approach reduce cost and schedule risk
 Customer involved throughout the complete cycle
minimizes risk of not achieving customer satisfaction
and business needs
 Focus moves from documentation to code
 Uses modeling concepts to capture information about
business, data, and processes.
RAD Weaknesses
 Requires a number of RAD teams
 Requires commitment from both developer and
customer for rapid-fire completion of activities
 Not suited when technical risks are high
 Accelerated development process must give quick
responses to the user
 Hard to use with inherited systems
 Requires a system that can be modularized
When to use RAD
 Reasonably well-known requirements
 When we have CASE and other modeling tools
 User involved throughout the life cycle
 Project can be time-boxed
 Functionality delivered in increments
 High performance not required
 Low technical risks
 System can be modularized
Evolutionary Process models
 Prototyping model
 Spiral model
 Concurrent Development model
Prototyping Model
 Prototyping Model
 This model uses constant user interaction, early in
the requirements gathering stage to produce a
prototype.
 Developers build a prototype during the requirements
phase
 Prototype is evaluated by end users
 Users give corrective feedback
 Developers further refine the prototype
 When the user is satisfied, the prototype code is
brought up to the standards needed for a final
product.
Prototyping Steps
 A preliminary project plan is developed
 An partial high-level paper model is created
 The model is source for a partial requirements
specification
 A prototype is built with basic and critical attributes
to show how the eventual software system look like,
how input screens and output reports would look
like.
 The designer builds
◦ the database
◦ user interface
◦ algorithmic functions
Prototyping Steps (continued)
 The designer demonstrates the prototype, the user
reviews and evaluates for problems, more features
and suggests improvements.
 Based on feedback the prototype is improved and
sent for review.
 This loop continues until the user is satisfied

 Finally software product is created based on the

prototype.
Prototyping Strengths
 Customers can “see” the system requirements as
they are being gathered
 Developers learn from customers
 A more accurate end product
 Unexpected requirements accommodated
 Allows for flexible design and development
 Steady, visible signs of progress produced
 Interaction with the prototype stimulates awareness
of additional needed functionality
Prototyping Weaknesses
 The customer may want the prototype delivered.
 Insufficient analysis
 User confusion of prototype and finished system
 Developer misunderstanding of user objectives
 Excessive development time of the prototype
 Expense of implementing prototyping
When to use Prototyping
 Requirements are unstable or have to be clarified
 Where we have a user who can give feedback.
 Can be used as the requirements clarification
stage of a waterfall model
 Develop user interfaces
 New, original development
Spiral Model
 Spiral Model
 It is an evolutionary software process model that
◦ couples the iterative nature of prototyping and
◦ the controlled and systematic aspects of the linear sequential
model
 It provides the potential for rapid development of
incremental versions of the software.
 Software is developed in a series of incremental
releases.
 During early iterations, the incremental release might
be a paper model or prototype.
 During later iterations, increasingly more complete
versions of the engineered system are produced.
Spiral Model Task Regions
1. Customer communication —tasks required to
establish effective communication between
developer and customer.

2. Planning —tasks required to define resources,

timelines, and other project related information.

3. Risk analysis —tasks required to assess both

technical and management risks.

4. Engineering —tasks required to build one or more

representations of the application.
Continue…
Spiral Model Task Regions
(continued..)
5. Construction and release —tasks required to
construct, test, install, and provide user support
(e.g., documentation and training).

6. Customer evaluation —tasks required to obtain

customer feedback based on evaluation of the
software representations created during the
engineering stage and implemented during the
installation stage.
 Alternative view of Spiral model
 Examine the project entry point axis
 Concept development project – starts at the core of
the spiral
 New development project – If the concept is to be
developed into an actual product
 Product enhancement project – when process is
inactive, but starts when change is initiated
 Product maintenance project – using customer
feedback
Spiral Model
 Spiral Model Strengths
 Provides early indication of risks, without much cost
 Users see the system early because of rapid
prototyping tools
 Critical high-risk functions are developed first
 The design does not have to be perfect
 Users can be closely tied to all lifecycle steps
 Early and frequent feedback from users
 Cumulative costs assessed frequently
 Spiral Model Weaknesses
 Time spent for evaluating risks too large for small or
low-risk projects
 Time spent planning, resetting objectives, doing risk
analysis and prototyping may be excessive
 The model is complex
 Risk assessment expertise is required
 Spiral may continue indefinitely
 Developers must be reassigned during non-
development phase activities
 May be hard to define objective, verifiable milestones
that indicate readiness to proceed through the next
iteration
 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)
Real-time examples:

Process Model Name Example

Waterfall model making of Tea

musician may start with one

Incremental model version of a song and refine
it
Including more functionalities
RAD model
in Employee registration
making of an E-Commerce
Prototyping model
website

Spiral model making of missiles

Concurrent Development model
 Also called concurrent engineering
 Constitutes a series of framework activities, software
engineering action, tasks and their associated states
 All activities exist concurrently but reside in different
states
 It defines a network of activities. Each activity on the
network exists simultaneously with other activities
 Event generated at one point in the process trigger
transitions among the states
Concurrent Development model
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
Agility and the Cost of Change
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
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. 57
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.

58
Extreme Programming (XP)
 The most widely used agile process, originally
proposed by Kent Beck
 More recently, a variant of XP, called Industrial XP
(IXP) has been proposed
 IXP refines XP and targets the agile process
specifically for use within large organizations
Extreme Programming (XP)
Values
1. Communication
◦ Verbal collaboration between customers & developers
◦ The establishment of effective metaphors for communicating
important concepts
◦ continuous feedback
◦ avoidance of voluminous documentation as a communication
medium

2. Simplicity
◦ XP restricts developers to design only for immediate needs,
rather than consider future needs
Extreme Programming (XP)
Values (Contd.)
3. Feedback
◦ Derived from three sources: the implemented software itself,
the customer, and other software team members
◦ XP makes use of the unit test as its primary testing technique
◦ After new requirements are derived, the team provides the
customer with rapid feedback regarding cost and schedule
impact
4. Courage
◦ An agile XP team must have the discipline (courage) to design
for today, instead for tomorrow
5. Respect
◦ As they achieve successful delivery of software increments,
the team develops growing respect for the XP process
Extreme Programming (XP) Process
XP Process
 XP Planning
o Begins with the creation of “user stories”
o Agile team assesses each story and assigns a cost
o Stories are grouped to for a deliverable increment
o A commitment is made on delivery date
o After the first increment “project velocity” is used to help define
subsequent delivery dates for other increments
o Project velocity is the number of customer stories implemented
during the first release
 XP Design
o Follows the “Keep It Simple” principle
o Encourage the use of CRC cards
o CRC (class responsibility collaborator) cards identify and organize the
object-oriented classes that are relevant to the current software
7

increment
o For difficult design problems, suggests the creation of “spike
solutions”—a design prototype
o Encourages “refactoring”—an iterative refinement of the internal
program design
XP Process (Continued..)
 XP Coding
◦ Recommends the construction of a unit test for a store before
coding commences
◦ Encourages “pair programming”

 XP Testing
◦ All unit tests are executed daily
◦ “Acceptance tests” are defined by the customer and executed to
assess customer visible functionality
Issues related to XP
 Requirements volatility
 Conflicting customer needs
 Requirements are expressed informally
 Lack of formal design
Other Agile Process Models
 Adaptive Software Development
 Scrum
 Dynamic Systems Development Method
 Feature Driven Development
Adaptive Software Development
Adaptive Software Development
 Originally proposed by Jim Highsmith
 It is a technique for building complex software and
systems
 Three phases:
◦ “Speculation” for project initiation
◦ “Collaboration” for requirements gathering
◦ “Learning” throughout the process
 ASD — distinguishing features
◦ Mission-driven planning
◦ Uses time-boxing
◦ Communication, Teamwork, Individualism and Trust
◦ Component-based focus
◦ Produces software project teams having higher success
likelihood
Scrum
Scrum
 Originally proposed by Schwaber and Beedle
 Scrum—distinguishing features
◦ Development work is partitioned into “packets”
◦ Testing and documentation are on-going as the
product is constructed
 Each process patterns defines a set of
development actions:
◦ Backlogs
◦ Sprints
◦ Scrum meetings
◦ Demos
Dynamic Systems Development
Method
Dynamic Systems Development
Method
 Promoted by the DSDM Consortium
 DSDM is an iterative software process, in which
only enough work is required for each increment to
facilitate movement to the next increment
 DSDM—distinguishing features
◦ 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
◦ Can be combined with XP and ASD model
Feature Driven Development
(FDD)
 Originally proposed by Peter Coad et al
 FDD describes an adaptive, agile process
that can be applied to moderately sized and
larger software projects
 FDD philosophy:
◦ Emphasizes collaboration among people on an
FDD team
◦ manages problem and project complexity using
feature-based decomposition
◦ communication of technical detail using verbal,
graphical and text-based means
Feature Driven Development
Model
Features in FDD
 Emphasis is on defining “features” - a client-valued function that
can be implemented in two weeks or less
 Features are small blocks of deliverable functionality, can be
described easily
 Features can be organized into a hierarchical business-related
grouping
 Since a feature is the FDD deliverable software increment, the
team develops operational features every two weeks
 Project planning, scheduling, and tracking are driven by the
feature hierarchy, instead of an arbitrarily adopted software
engineering task set.
 Uses a feature template
<action> the <result> <by | for | of | to> a(n) <object>
For example,
◦ Add the product to shopping cart
◦ Display the technical-specifications of the product
◦ Store the shipping-information for the customer
Feature Driven Development
Model
 A features list is created and plan by feature is
conducted
 The FDD approach defines five “collaborating”
framework activities
 If deadline pressure is significant, it is critical to
determine if software increments (features) are
properly scheduled.
 To accomplish this, FDD defines six milestones
during the design and implementation of a feature:
“design walkthrough, design, design inspection, code,
code inspection, promote to build”
Comparison of Agile and
Traditional Approaches