Software Engineering

BE-VIII Semester S-2014

Unit-1 PPT SLIDES
Text Books:1.Software Engineering, A practitioners approach
Roger s. Pressman 6th edition McGraw-Hill

01/21/16

Unit 1 Syllabus
Introduction to Software Engineering : The evolving role of
software, Changing Nature of Software, Software myths.
A Generic view of process : Software engineering- A layered
technology, a process framework.
Software process & process models: Linear sequential,
prototyping, RAD, Evolutionary Product & Process. Project
management concepts: People, Product, Process, Project.
W5HH principles, critical practice.

01/21/16

Introduction to software Engineering

The Evolving role of software
Dual role of Software
A Product
- Information transformer
- producing, managing and displaying
A Vehicle for delivering a product
- Control of computer(operating system),the communication of
information(networks) and the creation of other programs

01/21/16

Introduction to software Engineering

Software is defined as
1. Instructions
- Programs that when executed provide desired function
2. Data structures
-Enable the programs to sufficiently manipulate
information
3. Documents
-Describe the operation and use of the programs.

01/21/16

Introduction to software Engineering

Definition of Engineering
-Application of science, tools and methods to find cost
effective solution to problems

Definition of SOFTWARE ENGINEERING

- Software Engineering is defined as systematic, disciplined
and scientific approach for the development, operation and
maintenance of software
01/21/16

Introduction to software Engineering

Characteristics of software
Software is developed or engineered, it is not
manufactured in the classical sense.
Software does not wear out. However it disintegrate
due to change.
Software is custom built rather than assembling
existing components.
-Although the industry is moving towards component
based construction, most software continues to be
01/21/16

custom built

Failure rate

CHARACTERISTICS OF HARDWARE

Infant
mortality

Wear out

Time

Fig: FAILURE CURVE FOR HARDWARE

01/21/16

CHARACTERISTICS OF SOFTWARE

Fig: FAILURE CURVE FOR SOFTWARE

01/21/16

THE CHANGING NATURE OF SOFTWARE

Seven Broad Categories of software are challenges for
software engineers
System software
Application software
Engineering and scientific software
Embedded software
Product-line software
Web-applications

Artificial intelligence software

01/21/16

THE CHANGING NATURE OF SOFTWARE

System software. System software is a collection of programs

written to service other programs

Embedded software
-- resides in read-only memory
--is used to control products and systems for the consumer and
industrial markets.

Artificial intelligence software. Artificial intelligence (AI) software

makes use of nonnumeric algorithms to solve complex problems that
are not willing to computation or straightforward analysis

Engineering and scientific software. Engineering and scientific

software have been characterized by "number crunching" algorithms.

01/21/16

10

Software Evolution

Software evolves due to changes

Changes occur due to correction alteration and enhancement
8 Laws of unified theory
The Law of Continuing Change.
The Law of Increasing Complexity.
The Law of Self-Regulation
The Law of Conservation of Organizational Stability.
The Law of Conservation of Familiarity
The Law of Continuing Growth
The Law of Declining Quality
The Feedback System Law

01/21/16

11

SOFTWARE MYTHS
Software Myths had a no of attributes that made
them dangerous; for instance, they appeared to
be reasonable statements of fact.
Widely held but false view
Propagate misinformation and confusion
Three types of myth
- Management myth
- Customer myth
- Practitioners myth
01/21/16

12

MANAGEMENT MYTHS
Myth(1)
-The available standards and procedures for software are
enough.
Myth(2)
- Each organization feel that they have state-of-art software
development tools since they have latest computer.
Myth(3)
- Adding more programmers when the work is behind
schedule can catch up.
Myth(4)
- Outsourcing the software project to third party, we can
relax and let that party build it.
01/21/16

13

CUSTOMER MYTH
Myth(1)
- General statement of objective is enough to begin
writing programs, the details can be filled in later.
Myth(2)
-Software is easy to change because software is
flexible

01/21/16

14

PRACTITIONERS MYTH
Myth(1)
-Once the program is written, the job has been done.
Myth(2)
-Until the program is running, there is no way of assessing
the quality.
Myth(3)
-The only deliverable work product is the working program
Myth(4)
-Software Engineering creates huge and unnecessary
documentation and consistently slows down software
development.
01/21/16

15

SOFTWARE ENGINEERING-A LAYERED

TECHNOLOGY

Fig: Software Engineering- A layered technology

01/21/16

16

SOFTWARE ENGINEERING-A LAYERED

TECHNOLOGY
Quality focus
- foundation that supports software Engineering.
Process
- Foundation for software Engineering
Methods
- Provide technical support How tools for building
software
Tools
- Provide semi-automatic and automatic support to
methods
01/21/16

17

A PROCESS FRAMEWORK
Establishes the foundation for a complete
software process
Identifies a number of framework activities
applicable to all software projects
Also include a set of umbrella activities that
are applicable across the entire software
process.
01/21/16

18

A PROCESS FRAMEWORK
Common process framework
Framework activities

TTTasks
Milestones
SQA points
Umbrella activities
01/21/16

19

A PROCESS FRAMEWORK
Used as a basis for the description of
process models
Generic process activities
Communication
Planning
Modeling
Construction
Deployment
01/21/16

20

A PROCESS FRAMEWORK
Generic view of engineering complimented
by a number of umbrella activities.

01/21/16

Software project tracking and control

Formal technical reviews
Software quality assurance
Software configuration management
Document preparation and production
Reusability management
Measurement
Risk management
21

The linear sequential model(Waterfall Model)

The linear sequential model, sometimes called the classic life cycle or
the waterfall model, suggests a systematic, sequential approach
to software development that begins at the system level and
progresses through communication, planning, modeling, construction
and deployment. The following figure shows the linear sequential
model for software engineering.

01/21/16

22

i) Communication

: This activity involves heavy communication with

customers and other stakeholders in order to gather requirements and

other related activities.
ii) Planning : Here a plan to be followed will be created which will describe
the technical tasks to be conducted, risks, required resources, work
schedule etc.
iii) Modeling : A model will be created to better understand the requirements
and design to achieve these requirements.
iv) Construction : Here the code will be generated and tested.
v) Deployment : Here, a complete or partially complete version of the
software is represented to the customers to evaluate and they give
feedbacks based on the evaluation.
01/21/16

23

The Prototyping Model

Software prototyping, refers to the activity of
creating prototypes of software applications, i.e.
incomplete versions of the software program being
developed.
Prototype model should be used when the desired
system needs to have a lot of interaction with the
end users.
01/21/16

24

The Prototyping Model Figure

01/21/16

25

THE INCREMENTAL PROCESS MODEL

Linear sequential model is not suited for projects
which are iterative in nature.
Used when initial requirements are reasonably welldefined and forceful need to provide limited
functionality quickly,
Functionality expanded further in later releases.

01/21/16

26

THE INCREMENTAL MODEL

Software releases in increments

1st increment compose of Core product
Basic requirements are addressed
Core product undergoes detailed evaluation by
the customer
As a result, plan is developed for the next
increment. Plan addresses the modification of
core product to better meet the needs of customer
Process is repeated until the complete product is
produced
01/21/16

27

Software functionality and features

The Incremental Model

Communication
Planning
Modeling
Construction
Deployment

Increment # n
Communication
Planning

Modeling
Analysis
design

Construction
Code
test

Deployment
Delivery
Support
feedback

delivery of
nth increment

Increment#2
Communication
Planning

Modeling

Construction

Analysis
design

Increment # 1

Code
test

Deployment
Delivery
Support
feedback

Delivery of
2nd increment

Communication
Planning

Modeling
Analysis
design

Construction
Code
test

Deployment
Delivery
Support
feedback

delivery of
1ST increment

Project calendar time

01/21/16

28

THE RAD MODEL

(Rapid Application Development)
An incremental software process model
Having a short development cycle
High-speed implementation 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
01/21/16

29

THE RAD MODEL

Multiple software teams work in parallel on different
functions
Modeling include three major phases: Business
modeling, Data modeling and process modeling
Construction uses reusable components, automatic
code generation and testing
Problems in RAD

Requires a number of RAD teams

Requires commitment from both developer and customer
for rapid-fire completion of activities
Requires modularity
Not suited when technical risks are high

01/21/16

30

The RAD Model

01/21/16

31

THE SPIRAL MODEL

An evolutionary model which combines the best
feature of the classical life cycle and the iterative
nature of prototype model
Include new element : Risk element
Starts in middle and continually visits the basic
tasks of communication, planning, modeling,
construction and deployment
01/21/16

32

A Typical : The Spiral

01/21/16

33

THE SPIRAL MODEL

A spiral model is divided into a number of framework activities,
also called task regions. Typically, there are between three and
six task regions.
Customer communicationtasks required to establish effective
communication between developer and customer.
Planningtasks required to define resources, timelines, and
other project related information.
Risk analysistasks required to assess both technical and
management risks.
Engineeringtasks required to build one or more
representations of the application.
Construction and releasetasks required to construct, test,
install, and provide user support (e.g., documentation and
training).
01/21/16

34

THE SPIRAL MODEL

Realistic approach to the development of large scale

system and software.
Software evolve as process progresses.
Better understanding between developer and customer.
The first circuit might result in the development of a
product specification.
Subsequent circuits develop a prototype.
And standard version of software.
01/21/16

35

Unit No:- 1(Chapter:3)

Project Management Concept

36
01/21/16

Project Management Concept

Manager concept includes following issues:
Product quality
Risk Assessment
Measurement
Cost Estimation
Project Schedule
Customer Communication
Staffing
Other Resources
Project Monitoring
01/21/16

37

Why Project Fail?

Changing customer requirement

Incomplete requirement

Unrealistic deadline

An honest underestimate of effort

Predictable and/or unpredictable risks

Technical difficulties

Miscommunication among project staff

01/21/16

38

Management Spectrum
Effective project management focuses on four aspects of the
project known as the 4 Ps:

People -

The most important element of a successful

project. (recruiting, selection, performance management,
training, compensation, career development, organization,
work design, team/culture development)

Product -

The software to be built (product objectives,

scope, alternative solutions, limitation)

Process -

The set of framework activities and software

engineering tasks to get the job done (framework activities
populated with tasks, milestones, work products, and QA
points)

Project -

All work required to make the product a reality.

(planning, monitoring, controlling)

01/21/16

39

People
Player of the project:

The Stakeholders (Players)

Team leaders
The Software Team
Alert Team (Implementer)
Coordination and Communication Issues.
01/21/16

40

Stakeholders (Players)
Senior managers

who define the business issues that

often have significant influence on the project.

Project (technical) managers

who must plan,

motivate, organize, and control the practitioners who do
software work.

Practitioners

who deliver the technical skills that are

necessary to engineer a product or application.

Customers

who specify the requirements for the software

to be engineered and other stakeholders who have a peripheral
interest in the outcome.

End-users

who interact with the software once it is

released for production use.

01/21/16

41

Team Leaders
MOI model for leadership

Motivation

The ability to encourage (by push or pull)

technical people to produce to their best ability.

Organization

The ability to mold existing processes (or invent

new ones) that will enable the initial concept to be translated into a
final product.

Ideas or Innovation.

The ability to encourage people to

create and feel creative even when they must work within bounds
established for a particular software product or application.

Characteristics of effective project managers (problem solving,

managerial identity, achievement, influence and team building)
01/21/16

42

Software Teams
How to lead?
How to organize?
How to collaborate?

How to motivate?
01/21/16

How to create good ideas?

43

Software Teams
The following factors must be considered when selecting a
software project team structure ...
The difficulty of the problem to be solved
The size of the resultant program(s) in lines of code or function
points
The time that the team will stay together (team lifetime)
The degree to which the problem can be modularized
The required quality and reliability of the system to be built
The firmness of the delivery date
The degree of communication required for the project
01/21/16

44

Organizational Paradigms
Closed paradigm structures a team along a traditional

hierarchy of authority. Less likely to be innovative when

working within the closed paradigm.

Random paradigm structures a team loosely and

depends on individual idea of the team members. It struggles

when orderly performance is required.

Open paradigm attempts to structure a team in a

manner that achieves some of the controls associated with the

closed paradigm but also much of the innovation that occurs
when using the random paradigm

Synchronous paradigm relies on the natural problem

and organizes team members to work on pieces of the problem
with little active communication among themselves

01/21/16

45

Alert Team

Small, Highly motivated project team also called alert

Team, adopts many of the characteristics of successful
software projects.
Team members must have trust in one another.
The distribution of skills must be appropriate to the
problem.
Alternative person may have to be excluded from the
team, if team organized is to be maintained.
Team is self-organizing
An adaptive team structure
Uses elements of organizational paradigms random,
open, and synchronous paradigms
Significant dependence

01/21/16

46

Team Coordination & Communication

Formal, impersonal approaches
include software engineering documents and
work products (including source code),
technical
memos,
project
milestones,
schedules, and project control tools, change
requests and related documentation, error
tracking reports, and repository data.
Formal, interpersonal procedures
focus on quality assurance activities applied to
software engineering work products. These
include status review meetings and design and
code inspections.
01/21/16

47

Team Coordination & Communication

Informal, interpersonal procedures
Include group meetings for information distribution
and
problem
solving
and
collocation
of
requirements and development staff.
Electronic communication
Include electronic mail, electronic bulletin boards,
and by extension, video-based conferencing
systems.
Interpersonal networking
Includes informal discussions with team members
and those outside the project who may have
experience or insight that can assist team
members.
01/21/16

48

49
01/21/16

The Product
Software Scope:
Context How does the software to be built fit into a
larger system, product, or business context and
what constraints are imposed as a result of the
context?
Information objectives What customer-visible data
objects are produced as output from the software?
What data objects are required for input?
Function and performance What function does the
software perform to transform input data into
output?
Are
any
special
performance
characteristics to be addressed?
Software project scope must be definite and
understandable at the management and technical levels.
01/21/16

50

Problem Decomposition
Sometimes
called
partitioning
or
problem
explanation
Decomposition is applied in 2 major areas
Functionality that must be delivered.
Process that will be used to deliver it.
Once scope is defined
It is decomposed into basic functions
It is decomposed into user-visible data objects

or
It is decomposed into a set of problem classes

Decomposition process continues until all functions

or problem classes have been defined
Decomposition will make planning easier.
01/21/16

51

The Process
Process model chosen must be appropriate for the:
Customers and developers,
Characteristics of the product, and
Project development environment
Once a process framework has been established
Consider project characteristics
Determine the degree of carefulness required
Define a task set for each software engineering
activity
Task set =
Software engineering tasks
Work products
Quality assurance points
52
Milestones
01/21/16

Melding the product and process

53
01/21/16

Melding the Product and Process

Project planning begins with melding the product
and the process
Each function to be engineered must pass
through the set of framework activities defined
for a software organization
The job of the project manager is to estimate the
resources required to move each function
through the framework activities to produce each
work product
01/21/16

54

Process decomposition
Process decomposition begins when the project
manager try to determine how to accomplish
each activity.
E.g. A small, relatively simple project might require
the following work tasks for the communication
activity:
1. Develop list of clarification issues.
2. Meet the customer to address clarification issues.
3. Jointly develop a statement of scope.
4. Review the
concerned.

statement

of

scope

with

all

5. Modify the statement of scope as required.

01/21/16

55

The Project
Projects get into risk when
Software people dont understand their customers
needs.
The product scope is poorly defined.
Changes are managed poorly.
The chosen technology changes.
Business needs change.
Deadlines are unrealistic.
Users are opposing.
Sponsorship is lost [or was never properly
obtained].
The project team lacks people with appropriate
skills.
Managers [and practitioners] avoid best practice
and lessons learned.
01/21/16

56

W5HH Approach
This Approach addresses project objectives, milestones and
schedules,
responsibilities,
management
and
technical
approaches, and required resources.

Why is the system being developed?

Enables all parties to assess the validity of business reasons for
the software work
What will be done?
Establish the task set that will be required.
When will it be accomplished?
Project schedule to achieve milestone.
Who is responsible?
Role and responsibility of each member.
Where are they organizationally located?
Customer, end user and other stakeholders also have
responsibility.
How will the job be done technically and managerially?
Management and technical strategy must be define.
How much of each resource is needed?
Develop estimation.
57

01/21/16