SOFTWARE ENGINEERING

TO MAKE SUCCESSFUL SOFTWARE

 SOFTWARE ENGINEERING- why?
• The goal is to make a software that succeeds:
• That meets the needs of the people who use
it
• That performs flawlessly over a long period of
time
• That is easy to modify ,maintain and upgrade
• and even easier to use.
 SE -DEFINITION
• The IEEE definition :
• 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).
• [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.
 Software Engineering – what do you
do?
• Software engineering is the application of engineering
practices to the development of software in a systematic
method.
• A concerted effort should be made to understand the
problem before a software solution is developed, therefore
DESIGN becomes a pivotal activity.
• Software should always exhibit high quality.
• Software engineering encompasses a process, methods for
managing and engineering software and tools.
• Software engineering: “the application of a systematic,
disciplined, quantifiable approach to the development, and
maintenance of software.
 SOFTWARE -DEFINITION
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.
 characteristics of software
• Software is a logical rather than a physical system element.
Therefore, software has characteristics that are considerably
different than those of hardware:
• Software is developed or engineered; it is not manufactured in the
classical sense.
• Software delivers the most important product of our time—
information.
• Although the industry is moving toward component-based
construction, most software continues to be custom built.
• Today, software takes on a dual role. It is a product, and at the
same time, the vehicle for delivering a product.
• software would slowly evolve from a product to a service as “on-
demand” software companies deliver just-in-time functionality via a
Web browser;
• Software doesn’t “wear out.” But it does deteriorate!, BECOMES
OBSOLETE.
Software Failure Curve
Hardware Failure Curve
Hardware Failure Curve
 Changing Nature of Software
• As compared to hardware – software is very flexible –
subjected to change.
• Advantage or disadvantage… ??
• Actually ..biggest risk.
• Whenever change is done too many errors enter in to the
code.
• Again we need to work very hard to get rid of the bugs, and
make the code error free.
• Therefore we need well defined processes (SE)to control the
change, for building and maintaining software.
• This is the single most important characteristic of software
that worries the practitioners and programmers and
Software engineering is focused around this problem, it
solves these problem by developing good processes.
 Software Application Domains

• System software
• Application software
• Engineering/scientific software
• Embedded software
• Product-line software
• Web applications
• Artificial intelligence software
 Legacy Software
• Legacy software systems . . . were developed decades ago
and have been continually modified to meet changes in
business requirements and computing platforms.
• software is characterized by longevity and business
criticality.
• core business functions and are indispensable to the
business.”
legacy systems often evolve for one or more of the following
reasons:
• The software must be adapted to meet the needs of new
computing environments or technology.
• The software must be enhanced to implement new
business requirements.
• Eg: Mainframe Systems, COBOL, Y2K Problem.
 Legacy Software
• The software must be extended to make it interoperable
with other more
• modern systems or databases.
• The software must be re-architected to make it viable
within a network
• environment
• When these modes of evolution occur, a legacy system
must be reengineered so that it remains viable into the
future.
• The goal of modern software engineering is to “devise
methodologies that are founded on the notion of
evolution”; that is, the notion that software systems
continually change, new software systems are built from
the old ones, and all must interoperate and cooperate with
each other”.
 Software is very difficult to measure-
Hence the need for process framework
• A problem can be solved by different
programmers in totally different way- using
different language, OS, tools etc.
• The size of code can is very difficult to measure
software.
• Therefore it is very important to define a process
, for software development.
• A good process guarantees a good software, even
though the people following the process are
totally different.
 THE SOFTWARE PROCESS
• A process is a collection of activities, actions, and
tasks that are performed when some work product is
to be created.
• In the context of software engineering, a process is
not a rigid prescription for how to build computer
software.
• Rather, it is an adaptable approach that enables the
people doing the work (the software team) to pick
and choose the appropriate set of work actions and
tasks. The intent is always to deliver software in a
timely manner and with sufficient quality to satisfy
those who have sponsored its creation and those
who will use it.
 process framework
• A process framework establishes the foundation
for a complete software engineering process by
identifying a small number of framework
activities that are applicable to all software
projects, regardless of their size or complexity.
• For many software projects, framework activities
are applied iteratively as a project progresses.
That is, communication, planning, modeling,
construction, and deployment are applied
repeatedly through a number of project
iterations.
 Process framework
• Process framework encompasses 5 activities:
• Communication -Understand the problem
(communication and analysis)
• Planning - Plan a solution
• Modeling - modeling and software design
• Construction - Carry out the plan, code
generation
• Deployment - Examine the result for accuracy,
and deploy (testing and quality assurance).
 umbrella activities
• Software engineering process framework activities are
complemented by a number of umbrella activities.
Typical umbrella activities include:
• Software project tracking and control
• Risk management
• Software quality assurance
• Technical reviews
• Measurement
• Software configuration management
• Reusability management
• Work product preparation and production
 software engineering practice
1. Always check will the software be able to sell on the
market, does it have any value.
2. KISS – keep it strictly simple
3. Maintain the clear vision
4. Always implement like it will be used by some psycho
who knows where you live.
5. Be open to the future, because changes are to happen.
6. Make it reusable.
7. Think. Complete you thought before you proceed to
the action. Understand the idea before you start.
 Practitioner’s myths
• Once we write the program and get it to work,
our job is done.
• Until I get the program “running” I have no way
of assessing its quality.
• The only deliverable work product for a successful
project is the working program.
• Software engineering will make us create
voluminous and unnecessary.
• documentation and will invariably slow us down.
 Customer myths
• A general statement of objectives is sufficient
to begin writing programs—we can fill in the
details later.
• Software requirements continually change,
but change can be easily accommodated
because software is flexible.
 SOFTWARE MYTHS
• Management myths.
• If we get behind schedule, we can add more
programmers and catch up everything they
need to know?
• If I decide to outsource the software project to
a third party.
 Process Models
• Waterfall Model - 1972.
• Spiral Model- 1982.
• Incremental Process Model- 1990.
• RAD Model- 1995
• Unified Process Model -2000.
• Concurrent Process Models 2002
• Component Base Models 2002.
• Agile Models- 2007.