UNIT I

Introduction to Software Engineering

Delivered By

Prof.Hitesh Mohapatra
Dept. of Computer Engg.

Softwares Dual Role

Software is a product

Delivers computing potential

Produces, manages, acquires, modifies, displays, or transmits
information

Software is a vehicle for delivering a product

Supports or directly provides system functionality

Controls other programs (e.g., an operating system)
Effects communications (e.g., networking software)
Helps build other software (e.g., software tools)

What is Software?
Software is a set of items or objects
that form a configuration that
includes
programs
documents
data ...

What is Software?

software is engineered
software doesnt wear out
software is complex

Wear vs. Deterioration

Software Applications

system software
application software
engineering/scientific software
embedded software
product-line software
Web Apps (Web applications)
AI software

SoftwareNew Categories

Ubiquitous computingwireless networks

Net sourcingthe Web as a computing engine
Open sourcefree source code open to the computing
community (a blessing, but also a potential curse!)
Also (see Chapter 32)

Data mining
Grid computing
Cognitive machines
Software for nanotechnologies

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.

Software Myths

Management Myths

Customer myths

We have books of standards, my staff will have sufficient info.

I work very hard to put the latest, greatest, fastest, state-of-the-art
hardware in front of all my programmers.
We have the greatest CASE tools around.
If we get behind, we can just add more programmers.
A general statement of objectives is sufficient to start coding, fill in the
details later.
Project requirements change constantly, but change is easy because
software is flexible.

Programmer myths

Once the program is written and working, our job is done.

Until the program is running, there is no way to assess quality.
The only deliverable for a successful project is the working program.

Software Engineering
Practice
Software engineering practice
- Communication practices
- Planning practices
- Analysis modeling practices
- Design modeling practices
- Construction practices
- Deployment practices
-

Software Engineering Practice

Consists of a collection of concepts, principles, methods, and tools

that a software engineer calls upon on a daily basis
Equips managers to manage software projects and software
engineers to build computer programs
Provides necessary technical and management how tos in getting
the job done
Transforms a haphazard unfocused approach into something that is
more organized, more effective, and more likely to achieve success

The Essence of Problem Solving

Understand the problem (communication and analysis)

1)

Who has a stake in the solution to the problem?

What are the unknowns (data, function, behavior)?
Can the problem be compartmentalized?
Can the problem be represented graphically?

Plan a solution (planning, modeling and software design)

2)

Have you seen similar problems like this before?

Has a similar problem been solved and is the solution reusable?
Can sub problems be defined and are solutions available for the
sub problems?

The Essence of Problem Solving

(continued)
Carry out the plan (construction; code generation)

3)

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

traceable back to the design?
Is each component of the solution correct? Has the design and
code been reviewed?

Examine the results for accuracy (testing and quality

assurance)

4)

Is it possible to test each component of the solution?

Does the solution produce results that conform to the data,
function, and behavior that are required?

Seven Core Principles for Software Engineering

1)

Remember the reason that the software exists

2)

Keep it simple, stupid (KISS)

3)

Never design yourself into a corner; build software that can be easily
changed and adapted

Plan ahead for software reuse

7)

Always specify, design, and implement knowing that someone else will
later have to understand and modify what you did

Be open to the future

6)

A clear vision is essential to the projects success

Others will consume what you produce

5)

All design and implementation should be as simple as possible

Maintain the vision of the project

4)

The software should provide value to its users and satisfy the
requirements

Reuse of software reduces the long-term cost and increases the value
of the program and the reusable components

Think, then act

Placing clear, complete thought before action will almost always

produce better results

Communication Practices
(Requirements Elicitation)
Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling
Tracking

Modelling
Analysis
Design
Construction
Code Test

Deployment
Delivery
Support
Feedback
15

Communication Principles
1)
2)
3)
4)
5)
6)
7)
8)
9)

10)

Listen to the speaker and concentrate on what is being said

Prepare before you meet by researching and understanding the
problem
Someone should facility the meeting and have an agenda
Face-to-face communication is best, but also have a document or
presentation to focus the discussion
Take notes and document decisions
Strive for collaboration and consensus
Stay focused on a topic; modularize your discussion
If something is unclear, draw a picture
Move on to the next topic a) after you agree to something, b) if you
cannot agree to something, or c) if a feature or function is unclear
and cannot be clarified at the moment
Negotiation is not a contest or a game; it works best when both
parties win

Planning Practices
(Defining a Road Map)
Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling
Modelling
Tracking
Analysis
Design

Construction
Code
Test

Deployment
Delivery
Support
Feedback
17

Planning Principles
1)
2)
3)
4)
5)
6)
7)
8)
9)
10)

Understand the scope of the project

Involve the customer in the planning activity
Recognize that planning is iterative; things will change
Estimate based only on what you know
Consider risk as you define the plan
Be realistic on how much can be done each day by each person
and how well
Adjust granularity as you define the plan
Define how you intend to ensure quality
Describe how you intend to accommodate change
Track the plan frequently and make adjustments as required

Barry Boehms W5HH Principle

Why is the system being developed?

What will be done?
When will it be accomplished?
Who is responsible for each function?
Where are they organizationally located?
How will the job be done technically and managerially?
How much of each resource is needed?

The answers to these questions lead to a definition of key

project characteristics and the resultant project plan.

Modeling Practices
(Analysis and Design)
Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling
Tracking

Modelling
Analysis
Design

Construction
Code
Test
Deployment
Delivery
Support
Feedback

Analysis Modeling Principles

1)
2)
3)
4)

5)

The information domain of a problem (the data that flows in and

out of a system) must be represented and understood
The functions that the software performs must be defined
The behavior of the software (as a consequence of external
events) must be represented
The models that depict information, function, and behavior must
be partitioned in a manner that uncovers detail in a layered (or
hierarchical) fashion
The analysis task should move from essential information toward
implementation detail

Design Modeling Principles

1)

2)
3)
4)
5)
6)
7)
8)
9)

The design should be traceable to the analysis model

Always consider the software architecture of the system to be built
Design of data is as important as design of processing functions
Interfaces (both internal and external) must be designed with care
User interface design should be tuned to the needs of the end-user
and should stress ease of use
Component-level design should be functionally independent (high
cohesion)
Components should be loosely coupled to one another and to the
external environment
Design representations (models) should be easily understandable
The design should be developed iteratively; with each iteration, the
designer should strive for greater simplicity

External quality factors: those properties that can be readily observed

Internal quality factors: those properties that lead to a high-quality design
from a technical perspective

Construction Practices
Communication
Project initiation
Requirements
gathering

Planning
Estimating
Scheduling
Tracking

Modelling
Analysis
Design

Construction
Code
Test
Deployment
Delivery
Support
Feedback

Coding Principles
(Preparation before coding)
1)
2)

3)
4)
5)

Understand the problem you are trying to solve

Understand basic design principles and concepts
Pick a programming language that meets the needs of the
software to be built and the environment in which it will operate
Select a programming environment that provides tools that will
make your work easier
Create a set of unit tests that will be applied once the component
you code is completed

Coding Principles
(As you begin coding)
1)
2)
3)
4)
5)
6)
7)
8)

Constrain your algorithms by following structured programming

practices
Select data structures that will meet the needs of the design
Understand the software architecture and create interfaces that
are consistent with it
Keep conditional logic as simple as possible
Create nested loops in a way that makes them easily testable
Select meaningful variable names and follow other local coding
standards
Write code that is self-documenting
Create a visual layout (e.g., indentation and blank lines) that aids
code understanding

Coding Principles
1)
2)
3)

(After completing the first round of

code)

Conduct a code walkthrough

Perform unit tests (black-box and white-box) and correct errors you
have uncovered
Refactor the code

Testing Principles
All tests should be traceable to the software requirements
Tests should be planned long before testing begins
The Pareto principle applies to software testing

1)
2)
3)

Testing should begin in the small and progress toward testing in

the large

4)

5)

80% of the uncovered errors are in 20% of the code

Unit testing --> integration testing --> validation testing --> system
testing

Exhaustive testing is not possible .

Test Objectives
1)
2)
3)

Testing is a process of executing a program with the intent of

finding an error
A good test case is one that has a high probability of finding an asyet undiscovered error
A successful test is one that uncovers an as-yet undiscovered
error

Deployment Practices
Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling
Tracking Modelling
Analysis
Design
Construction
Code
Deployment
Test
Delivery
Support
Feedback

Deployment Principles
1)

Customer expectations for the software must be managed

2)
3)
4)
5)

Be careful not to promise too much or to mislead the user

A complete delivery package should be assembled and tested

A support regime must be established before the software is
delivered
Appropriate instructional materials must be provided to end
users
Buggy software should be fixed first, delivered later

Software Process

Process Models

Waterfall model
Incremental Process Models

Evolutionary Process Models

Prototyping model
Spiral model

Specialized Process Models

Rapid application development model

Incremental model

Component-Based Development
Formal Method model

Comparison of life-cycle models

Waterfall model

Requirements are reasonably understood.

When work flow is linear in fashion
Systematic sequential approach

Incremental model

Evolution of waterfall model

New features added to 1st Increment(core product)
Incremental software development model may be
applicable to projects where:

Software Requirements are well defined, but realization may be

delayed.
The basic software functionality are required early

SW Functionality and features

Time

Inc 1

Inc 2

Inc 3

RAD Model

Rapid Application Development

Short development cycle
Faster development (60-90) days
High quality results
Use of (CASE) Tools
Component based construction
System delivered in short time (2 to 3 months)
Useful where requirements are well understood and
scope is limited

The RAD Model

Team # n
M o d e lin g
bus iness m odeling
dat a m odeling
process m odeling

C o n s t r u c t io n
com ponent reuse
aut om at ic code
generat ion
t est ing

Team # 2

Com m unicat ion

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

Team # 1

co m p o n e n t re u se
a u t o m a t i c co d e
g e n e ra t i o n
t e st i n g

Mode ling

De ploym e nt
int egrat ion
deliv ery
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

40

Process Models

Waterfall model
Incremental Process Models

Evolutionary Process Models

Prototyping model
Spiral model

Specialized Process Models

Rapid application development model

Incremental model

Component-Based Development
Formal Method model

Unified Process
Comparison of life-cycle models

Prototyping

Early approximation of a final system

Linear and iterative
Customer is unable to define the system
Requirements are not freezed
a prototype is built to understand the requirements

Evolutionary Models: Prototyping

Qu ick
p lan
Quick

Com m unicat ion

plan

communication
Mo
d e lin g
Modeling
Qu ick d e sig n

Quick design

Deployment
Deployment
De live r y
delivery &
& Fe e dback

feedback

Const r uct ion

Construction
of
ofot
prototype
pr
ot ype

43

Spiral Model

Simplified form

Precede each phase by

Waterfall model plus risk analysis

Alternatives
Risk analysis

Follow each phase by

Evaluation
Planning of next phase

Quadrant of spiral model:

First quadrant (Objective Setting)

During the first quadrant, it is needed to identify the objectives of the phase.
Examine the risks associated with these objectives.
Second Quadrant (Risk Assessment and Reduction)
A detailed analysis is carried out for each identified project risk.
Steps are taken to reduce the risks. For example, if there is a risk that the
requirements are inappropriate, a prototype system may be developed.

Third Quadrant (Development and Validation)

Develop and validate the next level of the product after resolving the
identified risks.
Fourth Quadrant (Review and Planning)
Review the results achieved so far with the customer and plan the next
iteration around the spiral.
Progressively more complete version of the software gets built with each
iteration around the spiral.

Evolutionary Models: The Spiral

planning
estimation
scheduling
risk analysis

communication
modeling
analysis
design
start

deployment
delivery
feedback

construction
code
test

47

Specialized Process Models

1)Component Based Development

COTS

Commercial off-the-shelf software components developed by

vendors who offer them as products.

Decomposition of the engineered systems into functional

or logical components with well-defined interfaces used
for communication across the components.

2) Formal Methods Model

Mathematically based techniques for representing and

analysis of software.
Formal methods include

Formal specification
Specification analysis and proof
Transformational development
Program verification

Formal Methods Model

Reduces requirements errors as it forces a detailed

analysis of the requirements
Incompleteness and inconsistencies can be
discovered and resolved
Currently very time consuming and expensive
Extensive training required
Difficult to use this model to communicate with the
customer.

Unified Process

Contains features of OOA and OOD.

UML- Unified Modeling Language

It was created to support the OO design and modeling.

iterative and incremental process

Phases of Unified process

All the phases are concurrent in nature
Inception
Elaboration
Construction
Transition
Production

The Unified Process (UP)

Elab
o r at io n
elaboration
Incep t io n
inception

inception

co nst r uct io n
Release
soft ware increment

t r ansit io n

p r o d uct io n
54

UP (contd)

Inception

Customer communication
Planning

Business requirements are identified

Identify resources, assess risks, defines schedule

In the form of use cases.

Rough architecture

A tentative outline of major sub-systems, functions and features that

populate them.

UP (contd)

Elaboration

Customer communication
Modeling activity
Expands the use cases.
Expands the architecture to:

Use case model, analysis model, design model, implementation

model and deployment model.

Review plan and make modifications

Evaluate scope, risks, project delivery dates

UP (contd)

Construction

Develop software components (that make the use cases

operational).
Complete the analysis and design models.
Implement all functions and features for that increment.
Conduct unit testing for the components
Integrate components.

UP (contd)

Transition

Create user manuals, guidelines, installation procedures.

Software is given to users for beta testing.
Get user feedback
The increment is now a useable software release.

UP Work Products
Incept ion phase
Vision document
Init ial use-case model
Init ial project glossary
Init ial business case
Init ial risk assessment .
Project plan,
phases and it erat ions.
Business model,
if necessary .
One or more prot ot y pes
I nc e pt i o
n

Elaborat ion phase

Use-case model
Supplement ary requirement s
including non-funct ional
Analy sis model
Soft ware archit ect ure
Descript ion.
Execut able archit ect ural
prot ot y pe.
Preliminary design model
Rev ised risk list
Project plan including
it erat ion plan
adapt ed workflows
milest ones
t echnical work product s
Preliminary user manual

Const ruct ion phase

Design model
Soft ware component s
Int egrat ed soft ware
increment
Test plan and procedure
Test cases
Support document at ion
user manuals
inst allat ion manuals
descript ion of current
increment

Transit ion phase

Deliv ered soft ware increment
Bet a t est report s
General user feedback

59

Agile Software Development

Is a group of software development methodologies

based on iterative and incremental development, where
requirements and solutions evolve through collaboration
between self-organizing, cross-functional teams.
Self Organization: is the process where a structure or
pattern appears in a system without central authority.
Cross-Functional team : is a group of people with
different functional expertise working toward a common
goal.

Extreme Programming

Is a software development methodology which is

intended to improve software quality and responsiveness
to changing customer requirements.
It releases product in short development cycles (time
boxing)
Pair Programming: Driver and Observer
Time Boxing
Code Review
Unit Testing