UNIT 1

Introduction to Software & software engineering

Prepared by :
Dr. Pooja M. Bhatt
Computer Engineering Department
MBIT,CVM University
Index
 SDLC
 Evolving Role of Software
 What is software?
 Program vs. software
 Characteristics of Software
 Hardware vs. Software
 Changing nature of software
 Software myths
 Software Process
 What is software engineering?
 Layered Approach
 Software Process models
 Product & Process
SDLC
Evolving Role of Software

Software is a product
 Transforms information - produces, manages, acquires,
modifies, displays, or transmits information
 Delivers computing potential of hardware and networks
Software is a vehicle for delivering a product
 Controls other programs (operating system)
 Effects communications (networking software)
 Helps build other software (software tools &
environments)
What is software?
 Software can define as:
❑ Instruction – executed provide desire features, function & performance.
❑ Data structure – to adequately manipulate operation.

❑ Documents – operation and use of the program.

Software products may be developed for a particular customer or may be

developed for a general market.
❑ Software products may be
❑ Generic - developed to be sold to a range of different customers

e.g. PC software such as Excel or Word.

❑ Bespoke (custom) - developed for a single customer according

to their specification.
 Difference between Program and Software

Program Software
Small in size Large in size.
Authors himself is user-soul. Large number.
Single developer Team developer.
Adopt development. Systematic development.
Lack proper interface. Well define interface.
Lack of proper documentation. Well documented
Characteristics of software
1) Software is developed or engineered; it is not manufactured.
2) Software does not “wear out” but it does deteriorate.
3) Software continues to be custom built, as industry is moving
toward component based construction.
Manufacturing vs. Development
 Once a hardware product has been manufactured, it is
difficult or impossible to modify. In contrast, software
products are routinely modified and upgraded.
 In hardware, hiring more people allows you to
accomplish more work, but the same does not
necessarily hold true in software engineering.
 Unlike hardware, software costs are concentrated in
design rather than production.
Failure curve for Hardware
Failure curve for Software

When a hardware component wears out, it is replaced by a spare part.

There are no software spare parts. Every software failure indicates an error in
design or in the process through which design was translated into machine
executable code. Therefore, software maintenance involves considerably more
complexity
Component Based vs. Custom Built
 Hardware products typically employ many standardized
design components.
 Most software continues to be custom built.
 The software industry does seem to be moving (slowly)
toward component-based construction
Types of software
 System software
 Application software
 Engineering/scientific software
 Embedded software
 Product line software
 Web applications
 Artificial intelligence software
System Software:
 System software is a collection of programs written to service other programs.
 It is characterized by heavy interaction with computer hardware; heavy usage by multiple
users; concurrent operation that requires scheduling, resource sharing, and sophisticated
process management; complex data structures; and multiple external interfaces.

Ex. Compilers, operating system, drivers etc.

Application Software :
 Application software consists of standalone programs that solve a specific business need.
 Application software is used to control the business function in real-time.

Engineering /Scientific software:

 Characterized by "number crunching" algorithms.
 Applications range from astronomy to volcano logy, from automotive stress analysis to space
shuttle orbital dynamics, and from molecular biology to automated manufacturing.
Ex. Computer Aided Design (CAD), system stimulation etc.
Embedded Software:
 It resides in read-only memory and is used to control products and systems
 Embedded software can perform limited and esoteric functions.
Ex. keypad control for a microwave oven.
Product line software:
 Designed to provide a specific capability for use by many different customers, product line
software can focus on a limited and esoteric marketplace.
Ex.Word processing, spreadsheet, CG, multimedia, etc.
Web Applications:
 Web apps can be little more than a set of linked hypertext files.
 It evolving into sophisticated computing environments that not only provide standalone
features, functions but also integrated with corporate database and business applications.
Artificial Intelligence software
 AI software makes use of non-numerical algorithms to solve complex problems that are not
amenable to computation or straightforward analysis
Ex. Robotics, expert system, game playing, etc.
Software Myths

 Software myths are beliefs about software and the process used to build it.
(1) Management Myths:
 Myth 1: 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.
 Myth 2: If we get behind schedule, we can add more programmers and catch up.
 Reality:
 Software development is not a mechanistic process like manufacturing.
 As new people are added, people who were working must spend time educating the
newcomers, thereby reducing the amount of time spent on productive development
effort.
 People can be added but only in a planned and well-coordinated manner.
 Myth 3:
 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 outsources software projects.
(2) Customer Myths:
 Myth 1:
 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.
 Unambiguous requirements are developed only through effective
and continuous communication between customer and
developer.
 Myth 2:
 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 early the cost impact is
relatively small.
 However, as time passes, the cost impact grows rapidly—resources
have been committed, a design framework has been established, and
change can cause disruption that requires additional resources and
major design modification.
Customer Myths
(3) Practitioner’s Myths:
 Myth 1:
 Once we write the program and get it to work, our job is done.
 Reality:
 Industry data indicate that between 60 and 80 percent of all effort
expended on software will be expended after it is delivered to the
customer for the first time.
 Myth 2:
 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.
 Software reviews are a “quality filter” that have been found to be more
effective than testing for finding certain classes of software defects.
 Myth 3:
 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 and, more important, guidance for software support.
 Myth 4:
 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.
 Better quality leads to reduced rework.
 Reduced network results in faster delivery times.
Software process
 What? A software process – as a framework for the
tasks that are required to build high-quality software.
 Who? Managers, software engineers, and customers.
 Why? Provides stability, control, and organization to an
otherwise disordered activity.
 Steps? A handful of activities are common to all
software processes, details vary.
 Work product? Programs, documents, and data.
 What is software engineering?
“The application of systematic, disciplined, quantifiable
approach to the development, operation, and maintenance
of software”
 Its a discipline that is concerned with all aspects of software
production.
 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 performance
4) with correct operation
What is software engineering?
 Software engineers should adopt systematic and
organized approach to their work, Use appropriate
tools and techniques depending on the problem to be
solved and the development constraints and the
resources available.
 Apply Engineering Concepts to developing Software.
 Challenge for Software Engineers is to produce high
quality software with finite amount of resources & within a
predicted schedule.
Software Engineering – Layered
Technology

Tools: CASE preferred

Methods: technical “how to’s”

Process model: the “framework”

A quality focus: the “bedrock”

A quality Focus
 Every organization is rest on its commitment to quality.
 Total quality management, Six Sigma, or similar continuous
improvement culture and it is this culture ultimately leads to
development of increasingly more effective approaches to
software engineering.
 The bedrock that supports software engineering is a quality
focus.
Process:
 It’s a foundation layer for software engineering.
 It’s define framework for a set of key process areas (KRA) for
effectively manage and deliver quality software in a cost effective
manner
 The processes define the tasks to be performed and the order in
which they are to be performed
Methods:
 It provide the technical how-to's for building software.
 Methods encompass a broad array of tasks that include requirements
analysis, design, program construction, testing, and support.
 There could be more than one technique to perform a task and
different techniques could be used in different situations.
Tools:
 Provide automated or semi-automated support for the process,
methods and quality control.
 When tools are integrated so that information created by one tool can
be used by another, a system for the support of software development,
called computer-aided software engineering (CASE)
Process Models
 Process models prescribe a distinct set of activities, actions,
tasks, milestones, and work products required to engineer
high quality software.
 Process models are not perfect, but provide roadmap for
software engineering work.
 Software models provide stability, control, and organization to a process
that if not managed can easily get out of control
 Software process models are adapted to meet the needs of software
engineers and managers for a specific project.
 Why Models are needed?
Symptoms of inadequacy: the software crisis
1. scheduled time and cost exceeded
2. user expectations not met
3. poor quality
Different process models
 Waterfall Model (Linear Sequential Model)
 Incremental Process Model
 1)Incremental model 2) RAD model
 Evolutionary process model
 1)Prototyping Model
 2)The Spiral Model
 3)Concurrent development model
 Specialized process model
 1) Component based development model
Water fall model (Classic Life Cycle or
linear sequential model)
 Requirement Analysis and Definition: What - The systems services,
constraints and goals are defined by customers with system users.
 Scheduling tracking -
 Assessing progress against the project plan.
 Require action to maintain schedule.
 System and Software Design: How –It establishes and overall system
architecture. Software design involves fundamental system abstractions and
their relationships.
 Integration and system testing: The individual program unit or programs are
integrated and tested as a complete system to ensure that the software
requirements have been met. After testing, the software system is delivered
to the customer.
 Operation and Maintenance: Normally this is the longest phase of the
software life cycle. The system is installed and put into practical use.
Maintenance involves correcting errors which were not discovered in earlier
stages of the life-cycle.
 When requirements for a problems are well understood
then this model is used in which work flow from
communication to deployment is linear
 This Model also called as the Classic life cycle or linear
sequential model.
 When to use ?
 Requirements are very well known, clear and fixed
 Product definition is stable
 Technology is understood
 There are no ambiguous (unclear) requirements
 Ample (sufficient) resources with required expertise are available
freely
 Short project
The Waterfall Model cont…

 Advantages
 Simple to implement and manage

 Drawbacks
 Unable to accommodate changes at later stages, that is
required in most of the cases.
 Working version is not available during development.
Which can lead the development with major mistakes.
 Deadlock can occur due to delay in any step.
 Not suitable for large projects.
 Assignment 1
SR Questions
NO
1 What is Software Engineering? What is the role of software engineer?
2 Explain Software Engineering as a Layered Technology.
3 Explain software myth for customers, practitioners and project manager.
What is reality in each case?
4 Explain Waterfall model in detail or explain linear sequential model in detail
or explain classic life cycle model in detail. Or Explain the process model
which is used in situations where the requirements are well defined.
5 Compare Hardware and Software product characteristics.
Extra
 introductions
 https://nptel.ac.in/courses/106/101/106101061/
 Models:
 https://www.youtube.com/watch?v=kwsKr1MObxs