|| Jai Sri Gurudev ||

SJB Institute of Technology

Department of Information Science & Engineering

With the Blessings of

His Divine Soul Jagadguru Padmabushana His Holiness Jagadguru

Sri Sri Sri Dr. Balagangadharanatha
Revered
Sri Sri Sri Dr. Nirmalanandanatha
Maha Swamiji, Maha Swamiji, Sri Sri Dr. Prakashanath Swamiji,
Founder President, President, Chief Pontiff Managing Director,
Sri Adichunchanagiri Shikshana Trust ® Sri Adichunchanagiri Shikshana Trust ® SJB and BGS Group of Institutions

2
Program: B.E. ISE
Course name: SOFTWARE ENGG.
and
PROJECT
MANAGEMENT
Course code: BCS501
VI semester, MODULE -1
Faculty: DR.ABHILASH C N
Professor, Dept.of ISE, SJBIT
 TERMINOLOGIES
The Software is a collection of integrated
programs.
 Engineering is the application of scientific and
practical knowledge to invent, design, build,
maintain, and improve frameworks, processes, etc.
Definition 1:ware
 Software Engineering is an engineering branch
related to the evolution of software product using
well-defined scientific principles, techniques, and
procedures.
The result of software engineering is an effective
and reliable software product.
 TERMINOLOGIES
Fundamentals of Software Engg.:ware
Engineering
 Software Engg. deals with all aspects of
software production from initial concepts to
working and maintenance.
 Software specification, Software development,
Software validation and Software evolution.
 Key challenges in Software Engineering:
 Increasing diversity, Reduced delivery times
and Trustworthy software.
 60% for development cost, 40% testing cost.
 TERMINOLOGIES
Definition 2:ware Engineering
Software engineering is an engineering
discipline that’s applied to the development of
software in a systematic approach.
It’s the application of theories, methods, and
tools to design, build a software that meets the
specifications efficiently, cost-effectively, and
ensuring quality.
 It also includes activities to manage the
project, develop tools, methods and theories
that support the software production.
 Introduction
Why is Software Engineering required?
Need of Software Engineering ?(Where do we
require?)
Huge Programming - measure of programming become extensive
engineering.
Adaptability - simpler to re-create new software than to scale an
existing one.
Cost - huge manufacturing has let down the cost of computer, but
programming remains high.
Dynamic Nature - new upgrades need to be done in the existing
one.
Quality Management - Better software development provides a
quality software product.
 For more Scalability, Reliability
 Computer Science Vs Software
Engineering
 Computer science focuses on the theory and
fundamentals, like algorithms, programming
languages, theories of computing, artificial
intelligence, and hardware design.
while Software Engineering is concerned with the
activities of developing and managing software.

 The job of a software engineer is difficult. It has to

balance between different people involved, such as
 Dealing with users/customers/clients
 Dealing with technical people
 Dealing with management
 Overview
 There are many different types of software systems
from simple to complex systems.
These systems may be developed:
 for a particular customer
 to support a particular business process or
 developed for a general purpose like any software for
our computers such as word processors.
 Good Attributes of a software –
 should deliver the required functionality &
performance to the user.
 Overview- NATURE OF SOFTWARE
 Software is a collection of executable program codes
associated with libraries and documentation. Engineering is the
application of science, tools and methods to find a cost effective
solution to a problem.
 Software Engineering is a well defined process with
systematic, disciplined and quantifiable approach for the
development and maintenance of software.
 Software can be defined as – Instructions (computer
programs) that provide desired features, function and
performance.
 It can be data structures – as it can be manipulate the info.
 It can be descriptive information to describe the use &
operation.
 Characteristics of Software
1. Software is developed or Engineered. (not
manufactured)

 Both the hardware & software are fundamentally

different.
 Similarities are:
High Quality achieved through good design
 Dependent on people but the relationship is entirely
different.
 Construction of a product but approaches are different.
 Software costs are concentrated in Engineering. (it
can’t be managed like a manufacturing project)
 Characteristics of Software
2. Software does not “wear out”.
 For a hardware, - failure curve or bath tub curve
exists, where hardware exhibits relatively high
failure.
 In that case, defects are corrected and failure rate
drops.
 As the time passes, cumulative effects of dust, over
usage, temperature variation, vibration or
environmental disorders begins to wear out.
Software does not undergo this phase, it will have
idealized curve. Only undiscovered defects/bugs will
lead to high failure rate, later these are corrected
and it normalizes.
 Characteristics of Software
2. Software does not “wear out”.

 During its life, Software will undergo many

changes, errors will be introduced causing the
failure curve to spike and return to steady state
and if change is requested vice-versa continues
the cycle.
 Every software failure indicates – error in design
or in the process, in that case design must be
translated into machine executable code.
“Software maintenance is more complex than the
hardware maintenance”.
 Characteristics of Software
3. Software continues to be custom built.
 In Engineering discipline, a collection of standard
design components is created. (Mech & Electrical
Engineers)
 The reusable components are focused more so that
engineer can concentrate on innovative elements of a
design.
 Reusable is a natural part of the Engineering Process
in Hardware, but in software it has only begun.
 So, Software component must be designed and
implemented in such a way that it is reused in different
programs.
 Characteristics of Software
3. Software continues to be custom built.
 In Engineering discipline, Reusable components
encapsulate the data and the processing involved.
 Ex: Creation of graphics, pull-down menus, interaction
mechanisms, mouse hovering etc.
Failure Rate Curve
 Software Application Domains
There are 7 broad categories of Computer Software:

1. System Software – OS components, Drivers, Networking

Software
2. Application Software
3. Engineering/Scientific Software
4. Embedded Software
5. Product-line Software
6. Web Applications
7. Artificial Intelligence Software
 Software Application Domains
1. System Software – OS components, Drivers, Networking Software
Collection of programs to service other programs.
They are mainly used for more interaction with computer hardware.
Multiple users, Concurrent operations, etc.

2.Application Software – Transaction processing, Real-time Manufacturing

Stand-alone programs to solve a specific business requirement.
Top 25 core banking software companies and systems (virtuaq.com)
3. Engineering/Scientific Software – No. Crunching Algorithms
The applications can range from MS Office to Adobe, Biology to
Automation, Space shuttle to Dynamics, Interactive Gestures etc.
Top 15 Space Companies in the World [2024] (spaceimpulse.com), Space Mission Design Tools – NASA
Gesture Recognition Companies in India | Gesture Recognition Development (dreamworth.in),
Top 10 startups in Gesture Recognition in India in Sep, 2024 - Tracxn
 Software Application Domains – Contd…

4. Embedded Software – resides within a product & perform limited

actions
They are used to implement and control the features.
Ex: Keypad in Mobile/Oven, Dashboard systems, Display systems.
Exploring the Top 50 Indian Companies for Embedded System Engineers - Embed Threads
5. Product-Line Software – designed to provide for a specific
functionality by many customers.
Ex: Inventory Control, Consumer markets (word-processor,
spreadsheet,
graphics, multimedia, business financial etc.)

6. Web Application Software – has a wide category of

applications, which is of HTML files with graphics.
Ex: Web page for business application, corporate databases,
computing
functions etc.
 Software Application Domains – Contd…

7. Artificial Intelligence Software – makes use for non-

numerical algorithms to solve complex problems
Ex: Applications in this area –Robotics, Expert systems,
Pattern recognition,
Game development etc.
Not Limited to, there are many more challenges for software
engineer in this fast growing industry with new technology
changes.
 Open-world computing – handheld devices, wireless technologies
 Net-Sourcing – WWW as a computing engine, dashboard
 Open Source – distribution of source code,
self-descriptive, self-manifest
 Legacy Software
 Legacy software systems . . . were developed decades ago and have
been continually modified to meet changes in business requirements
and computing platforms.
 large organizations find them costly to maintain and risky to evolve

REASONS to Evolve :

• 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.
• 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.
 Attributes for Web Apps
1. Network intensiveness. A WebApp resides on a network and
must serve the needs of a diverse community of clients.
2. Concurrency. A large number of users may access the WebApp
at one time.
3. Unpredictable load. The number of users of the WebApp may
vary by orders of magnitude from day to day.
4. Performance. In a WebApp, user must not wait too long (for
access, for server-side processing, for client-side formatting
and display), he or she may decide to go elsewhere (mirror
sites).
 Attributes for Web Apps
6. Data driven. The primary function of many WebApps is to use
hypermedia to present text, graphics, audio, and video content
to the end user.
7. Content sensitive. The quality and aesthetic nature of content
remains an important determinant of the quality of a WebApp.
8. Continuous evolution. Unlike conventional application software
that evolves over a series of planned, chronologically spaced
releases, Web applications evolve continuously. It is not to be
independently computed for each request.
9. Immediacy. the compelling need to get software to market
quickly—is a characteristic of many application domains.
10.Security. Because WebApps are available via network access,
it is difficult to limit the population of end users who may
 To Build a Software - Reality checks for Software
Engineering

1. Understand the problem before you build a solution.

When a new application or embedded system is to be built,
many voices must be heard. And it sometimes seems that each of
them has a slightly different idea of what software features and
functions should be delivered.
2. Design is a pivotal software engineering activity
Large teams of people now create computer programs that were
once built by a single individual. Sophisticated software that was
once implemented in a predictable, self-contained, computing
environment is now embedded.
3. Both quality & maintainability are an outgrowth of good
design.
 If the software fails, people and major enterprises can
 To Build a Software - Reality checks for Software
Engineering
“Software in all of its forms and across all of its
application domains should be engineered”.

 Software engineering is a layered technology.

 The bedrock that supports software engineering is a Quality
focus.
 The foundation is the Process layer – defines the framework.
 Next, the Methods encompass a broad array of tasks that
include communication, requirements analysis, design
modeling, program construction, testing, and support.
 Finally the Tools provide automated or semi-automated
 The Software Process – Foundational Layer for
SE
The software process holds the technology layers
together and enables rational and timely development
of computer software.

 A process is a collection of activities, actions,

and tasks that are performed when some work
product is to be created.

1. An ACTIVITY strives to achieve a broad objective

(e.g., communication with stakeholders) and is
applied regardless of the application domain, size of
 The Software Process – Foundational Layer for
SE
2. An ACTION (e.g., architectural design)
encompasses a set of tasks that produce a
major work product (e.g., an architectural
design model).
3. A TASK focuses on a small, but well-defined
objective (e.g., conducting a unit test) that
produces a tangible outcome.

It is an adaptable approach that enables the

people doing work (the software team) to pick
 The Software Process – Generic Framework
A generic process framework for software engineering
encompasses five activities:

1. Communication
2. Planning
3. Modeling
4. Construction
5. Deployment
 Generic Framework – Communication &
Planning
1. It is critically important to communicate and
collaborate with the customer and
stakeholders.
It helps to define software features and functions.
2. A software project is a complicated journey,
and the planning activity creates a “map” that
helps guide the team as it makes the journey.
Software project plan—defines the software
engineering work by describing the technical tasks to
be conducted, the risks that are likely involved, the
resources that will be required, the work products to
 Generic Framework – Modelling
 If you’re a landscaper, a bridge builder, an
aeronautical engineer, a carpenter, or an
architect, you work with models every day.
You need to create a “sketch” of the thing so that
you’ll understand the big picture.
 How the constituent parts fit together, and many
other characteristics. If needed refine the sketch with
more detail to solve it.

So a software engineer does the same thing by creating

models to better understand software requirements and
 Generic Framework – Construction &
Deployment
 Construction: This activity combines code
generation (either manual or automated) and
the testing that is required to uncover errors in
the code.

 Deployment: The software (as a complete

entity or as a partially completed increment) is
delivered to the customer who evaluates the
delivered product and provides feedback based
on the evaluation.
 Activities under the Software Process

 Software project tracking & control – assess progress

& take action
 Risk management – assess the risk to get quality
product
 Software quality assurance – required activity
conduction
 Technical reviews – assess SE & debug errors before
proceeding
 Measurement – assist team in software delivery to
customer needs
 Software configuration management – manage the
 Software Engineering – How to make it as a
Practice ?
He was a professor of mathematics from 1914 to 1940 at
ETH Zürich and from 1940 to 1953 at Stanford University. He
made fundamental contributions to combinatorics,
number theory, numerical analysis and probability theory.

 George Polya outlined the Software Engg.

Practice as:
1. Understand the problem (communication and
analysis).
2. Plan a solution (modeling and software
design)
3. Carry out the plan (code generation).
 1. Understand the problem (communication and
analysis).
We listen for a few seconds and then think,
“Oh yeah, I understand, let’s get on with solving
this thing”.
 We always have to spend time and think about
these Qs:
 Who has a stake in the solution to the problem? who
are the stakeholders?
 What are the unknowns? What data, functions, and
features are required to properly solve the problem?
 Can the problem be compartmentalized? Is it possible
to represent smaller problems that may be easier to
 2. Plan a solution (modeling and software
design)
 Have you seen similar problems before? Is
there existing
software that implements the data, functions,
and features
that are required?
 Has a similar problem been solved? If so, are
elements of
the solution reusable?
 Can sub-problems be defined? If so, are
solutions readily
 3. Carry out the plan (code generation).
 The design you’ve created serves as a road map for
the system you want to build. – it can take a detour to
somewhere else.
 But the “plan” will allow you to proceed without
getting lost.

 Does the solution conform to the plan? Is

source code traceable to the design model?
 Is each component part of the solution
provably correct? Have the design and code
 4. Examine results for accuracy (testing &
quality assurance).

“You can’t be sure that your solution is perfect”

 Is it possible to test each component part of

the solution? Has a reasonable testing strategy
been implemented?
 Does the solution produce results that conform
to the data,
functions, and features that are required?
Has the software been validated against all
stakeholder
 Software Engineering Practice – 7 Principles
David Hooker [Hoo96] has proposed seven
principles that focus on software engineering
practice as a whole.
Partner, Hybrid Cloud Services - Global CTO Office, IBM Consulting
Partner, Hybrid Cloud Services - Global CTO Office, IBM Consulting
IBM · Full-time. (20) David Hooker | LinkedIn

 The First Principle: The Reason It All Exists

 The Second Principle: KISS (Keep It Simple,
Stupid!)
 The Third Principle: Maintain the Vision
 The Fourth Principle: What You Produce, Others
Will Consume
 The Fifth Principle: Be Open to the Future
 Software Engineering Practice – 7 Principles
 The First Principle: The Reason It All
Exists
 One Reason is : to provide value to its
users

 The Second Principle: KISS (Keep It

Simple, Stupid!)
 All design should be as simple as
possible, but no simpler.


 Software Engineering Practice – 7 Principles
 The Fourth Principle: What You Produce,
Others Will Consume So, always specify,
design, and implement knowing someone else
will have to understand what you are doing.
 The Fifth Principle: Be Open to the
Future
 Never design yourself into a corner.
 The Sixth Principle: Plan Ahead for
Reuse
 Planning ahead for reuse, reduces the cost
and increases the value of both the
 Software Engineering Practice – 7
Principles
 The Seventh principle: Think!
 Placing clear, complete thought before
action almost always produces better
results.

After following these principles,

“Many of the difficulties we experience in
building complex computer based systems
would be eliminated”.
 Software Myths & its Reality
 Software myths—erroneous beliefs
about software and the process that is
used to build it.
 Today, most knowledgeable software
engineering professionals recognize
myths for what they are—misleading
attitudes that have caused serious
problems for managers and
practitioners.
 Management myths
 Management Myths & its Reality
 Software Myth: We already have a book
that’s full of standards and procedures
for building software. Won’t that provide
my people with everything they
need to know?
 Reality: The book of standards may very well
exist, but is it used? Are software
practitioners aware of its existence? Does it
reflect modern software engineering practice?
Is it complete? Is it adaptable? Is it
streamlined to improve time-to-delivery while
 Management Myths & its Reality
 Software Myth: If we get behind schedule, we
can add more programmers and catch up.
 Reality: Software development is not a
mechanistic process like manufacturing. In
the words of Brooks [Bro95]: “adding people
to a late software project makes it later.”
 Myth: If I decide to outsource the software
project to a third party, I can just relax and let
that firm build it.
 Reality: If an organization does not
understand how to manage and control
 Customer Myths & its Reality
 Myth: A general statement of objectives is
sufficient to begin writing programs—we can
fill in the details later.
 Reality: Although a comprehensive and stable
statement of requirements is not always
possible, an ambiguous “statement of
objectives” is a recipe for disaster.
 Myth: Software requirements continually
change, but change can be easily
accommodated because software is flexible.
 Reality: It is true that software requirements
 Practitioner Myths & its Reality
 Myth: Once we write the program and
get it to work, our job is done.
 Reality: Someone once said that “the
sooner you begin ‘writing code,’ the
longer it’ll take you to get done.”
 Myth: Until I get the program “running” I
have no way of assessing its quality.
 Reality: One of the most effective
software quality assurance mechanisms
can be applied from the inception of a
 Practitioner Myths & its Reality
 Myth: The only deliverable work product for a
successful project is the working program.
 Reality: A working program is only one part of
a software configuration that includes many
elements. A variety of work products (e.g.,
models, documents, plans) provide a
foundation for successful engineering.
 Myth: Software engineering will make us
create voluminous and unnecessary
documentation and will invariably slow us
down.
THANK YOU
HAPPY LEARNING, WRITE AND
PRACTICE TO GET BETTER OUTCOME