Lecture 1.

2
Software process model

Introduction to
Software Engineering
Software Application Domains
System
Softwar
e Point of Sale,
Artificial Customized
Application
intelligenc Software
Software
e
Software
Software
Application Engineering
Web Domains
Application / Scientific
Software

Product line Embedded

Software Software
 Software Engineering
Software engineering is the establishment and use of
sound engineering principles in order to obtain
economical software that is reliable and works
efficiently in real machines.

The IEEE definition: The application of a systematic, disciplined,

quantifiable approach to the development, operation, and maintenance
of software, that is the application of engineering to software.

Software Engineering is the science and art of building(designing

and writing programs) a software systems that are:
1) on time
2) on budget
3) with acceptable Quality With
4) full scope
Software Engineering Layered
Approach
Software Engineering Tools allows automation of activities
which helps to perform systematic activities. A system for
the
support of software development, called computer-aided
software engineering (CASE Examples: Testing Tools,
Tracking Tools etc… ). Bug/Issue

It provides technical how-to’s for building software, it

encompasses many tasks including communication,
requirement analysis, design modeling, program
construction, testing and support

It is a foundation of Software Engineering, It is the glue

the holds the technology layers, It defines a
framework activities

Defines continuous process improvement principles

Software Engineering Cont.
 Software Engineering is a layered technology
 Quality
• Main principle of Software Engineering is Quality Focus.
• An engineering approach must have a focus on quality.
• Total Quality Management (TQM), Six Sigma, ISO 9001, ISO
9000-CAPABILITY MATURITY MODEL(CMM) CMM & similar
,
approaches encourages a continuous , I
process improvement
culture
 Process
• layer
It is a foundation of Software Engineering
• It is the glue the holds the technology layers
• It defines a framework with activities for effective delivery
of
software engineering technology
Software Engineering Cont.
 Method
• It provides technical how-to’s for building software
• It encompasses many tasks including communication,
requirement analysis, design modeling, program construction,
testing and support
 Tools
• Computer-aided software engineering (CASE) the scientific
application of a set of tools and methods is to a software system
which is meant to result in high-quality, defect-free, and
maintainable software products.
• CASE tools automate many of activities involved in various
the life cycle phases
Software Myths

 Beliefs about software and the process used to build it.

 “Misleading Attitudes that cause problem” are myths.
serous
• Management Myths
• Customer Myths
• Practitioner's (Developer) Myths
Myth: A widely held but false belief or idea.
Management Myth - 1
We have standards and procedures to build a system,
which is enough.

 Reality:
• Are software practitioners aware of standard’s existence?
• Does it reflect modern software engineering practice?
• Is it complete?
• Is it streamlined to improve time to delivery while still
maintaining a focus on quality?
• In many cases, the answer to all of these questions is ”NO.“
Management Myth - 2
We have the latest computers and development tools
.

 Reality:
• It takes much more than the latest model computers to do high-
quality software development.
• Computer-aided software engineering (CASE) are more
important than hardware. tools
Management Myth - 3
We can add more programmers and can catch up the
schedule.

 Reality:
• Software development is not a mechanicle process like
manufacturing.
• In the words of Fred Brooks : "adding people to a late software
project makes it later."
• People who were working must spend time educating the
newcomers.
• People can be added but only in a planned and well-coordinated
manner.
Management Myth - 4
I outsourced the development activity, now I can relax
and can wait for the final working product.

 Reality:
• If an organization does not understand how to manage and
control software projects internally, it will invariably struggle
when it outsources software projects.
Customer Myth - 1
A general statement of objectives
(requirements) is sufficient to start a
development.

 Reality:
• Comprehensive (detailed) statements of requirements is not
always possible, an ambiguous (unclear) “statement of
objectives” can lead to disaster.
• Unambiguous (clear) requirements can be gathered only through
effective and continuous communication between customer and
developer.
Customer Myth - 2
Requirement Changes can be easily
accommodated because software is
very flexible.

 Reality:
• It is true that software requirements change, but the impact of
change varies with the time at which it is introduced.
• When requirements changes are requested early the cost impact
is relatively small.
Practitioner's (Developer) Myth - 1
Once we write the program, our
job is done.

 Reality:
• Experts say "the sooner you begin 'writing code', the longer it
will take you to get done."
• Industry data indicates that 60 to 80 % effort expended on
software will be after it is delivered to the customer for the first
time.
Practitioner's (Developer) Myth - 2
I can’t access quality until it is
running.

 Reality:
• One of the most effective software quality assurance
mechanisms can be applied from the beginning of a project - the
technical review.
• Software reviews are more effective “quality filter” than testing for
finding software defects.
Practitioner's (Developer) Myth - 3
Working program is the only
deliverable work product.

 Reality:
• A working program is only one part of a software
• configuration.
A variety of work products (e.g., models, documents, plans)
provide a foundation for successful engineering and, more
important, guidance for software support.
Practitioner's (Developer) Myth - 4
Software engineering is about
unnecessary documentation.

 Reality:
• Software engineering is not about creating documents. It is about
creating a quality product.
• Better quality leads to reduced rework. And reduced rework
results in faster delivery times.