|| 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: 21CS61
VI semester, MODULE - 1
Faculty: DR.ABHILASH C N
Professor, Dept.of ISE, SJBIT
Syllabus overview
Contd…
Contd…
Contd…
 TERMINOLOGIES
Definition 1:ware Engineering
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.
 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
 To decrease time, Effectiveness
 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
 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.

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.
 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.

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. If 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.
5. Availability. Although expectation of 100 percent availability is unreasonable,
users of popular WebApps often demand access on a 24/7/365 basis.
 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 access the application. In order to
protect sensitive content and provide secure modes of data transmission,
strong security measures must be implemented.
 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 experience anything from
minor inconvenience to catastrophic failures. It follows that software should
exhibit high quality and needs maintainability.
 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 support for the
process and the methods.
 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.

 An ACTIVITY strives to achieve a broad objective (e.g.,

communication with stakeholders) and is applied regardless of the
application domain, size of the project, complexity of the effort, or
degree of rigor with which software engineering is to be applied.
 The Software Process – Foundational Layer for SE
 An ACTION (e.g., architectural design) encompasses a set
of tasks that produce a major work product (e.g., an
architectural design model).
 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 and choose the appropriate
set of work actions and tasks.
 The Software Process – Generic Framework
A generic process framework for software engineering encompasses
five activities:

 Communication
 Planning
 Modeling
 Construction
 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 be produced, and a work schedule.
 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 the design that will
achieve those requirements.
 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 changes in S/w
 Reusability management – criteria & mechanism for product reuse
 Work product preparation and production – models, logs, forms,
documents and lists required.
 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).
4. Examine results for accuracy (testing & quality assurance).
 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 understand?
 Can the problem be represented graphically? Can an analysis model
be created?
 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
apparent for the sub-problems?
 Can you represent a solution in a manner that leads to
effective implementation? Can a design model be created?
 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 been reviewed, or better, have
correctness proofs been applied to the algorithm?
 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
requirements?
 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
 The Sixth Principle: Plan Ahead for Reuse
 The Seventh principle: Think!
 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.

 The Third Principle: Maintain the Vision

 A clear vision is essential to the success of a
 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 reusable components
and the systems into which they are incorporated.
 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
 Customer myths
 Practitioner’s 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 still maintaining a focus on
quality? In many cases, the answer to all of these
questions is “no.
 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 software projects internally, it will
invariably struggle when it out-sources software projects.
 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 change, but
the impact of change varies with the time at which it is
introduced. When requirements changes are requested
 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 project—the technical review.
 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.
 Reality: Software engineering is not about creating
documents. It is about creating a quality product.
THANK YOU
HAPPY LEARNING, WRITE AND
PRACTICE TO GET BETTER OUTCOME