Unit 1- Introduction

to Software and
Subject : Software
Software Engineering Engineering
Subject Code: 01IT0601
Semester: 6th

Asst. Prof. Mitesh Patel

Teaching Scheme
Topics
Introduction to Software and Software Engineering
The Evolving Role of Software, Software: A Crisis on the Horizon and Software
Myths, Software Engineering: A Layered Technology, Software Process Models, The
Linear Sequential Model, The Prototyping Model, The RAD Model, Evolutionary
Process Models, Agile Process Model, Component-Based Development, Process,
Product and Process.
Why to Study Software Engineering?
Software Development Life Cycle without Software Engineering

1 2 3 4 5
How the How the How the How the How the
Customer Project System Programmer Business
Explains Leader Analyst Works Consultant
Requirement understand design it on it describe it
it
Why to Study Software Engineering?
Software Development Life Cycle without Software Engineering

6 7 8 9 10

How the What How the How it What the

Project Operations Customer was customer
documented Installed billed supported really
needed
SDLC without Software Engineering
Customer The software
Solution
Requirement development
• Have one trunk • Have one trunk
process needs to be
• Have four legs • Have four legs
• Should carry load both • Should carry load both
engineered
passenger & cargo passenger & cargo to avoid the
• Black in color • Black in color communication gap
• Should be herbivorous • Should be herbivorous & to meet the actual
requirements of
customer
Our value
within stipulated
added, budget
also gives & time
milk

6
Software Engineering
Engineerin
g

Design Build Product

Engineering
Software
Software is dead…..!
• The old School view of Software
• You buy it
• You own it &
• It’s your job to manage it
• That is coming to an end

• Because of web 2.0 & extensive computing

power, there is a different generation of
software
• It is delivered via Internet
• It looks exactly like it’s residing on each user’s
computing device
• Actually it reside on far away server
What is Software?
Software is
1) Computer program that when executed provide desired features, function & performance
2) Data Structure that enable programs to easily manipulate information
3) Descriptive information in both hard and soft copy that describes the operation and use
of programs

+ +
Computer Data Documents
Program Structure Soft & Hard
List of documentation & manuals
Formal Specification
Documentation
Analysis / Manuals
Context Diagram
Specification
Data Flow Diagram
User Manuals Operational
Documentation

Flow Charts Manuals

Manuals

Design
ER Diagram System Installation
Overview Guide
Implementat Source Code Listings Beginner’s
ion Cross-Reference Guide
Tutorials System
Listings Administration
Test Data Reference Guide
Testing Guide
Test Results
Software Application Domains
System
• System Software Software
Point of Sale,
• Application Artificial
Application Customized
intelligenc Software
Software e Software
Software
• Engineering /
Software
Scientific Software Application
• Embedded Domains Engineering
Web
/ Scientific
Application
Software Software
• Product line
Software Product Embedded
line Software
• Web Application Software
• Artificial
intelligence sw
Software Engineering
• Software Engineering is the application of a systematic, disciplined, quantifiable
approach to the development, operation, and maintenance of software; that is, the
application of engineering to software.
• "Quantifiable methods" refer to techniques or practices that can be measured or
expressed using numbers, in order to ensure a high level of precision, accuracy, and
control in software engineering.
The Evolving Role Of Software
• Software takes on a dual role. It is a product and, at the same time, the vehicle for
delivering a product.
• As a product, it delivers the computing potential embodied by computer hardware or,
more broadly, a network of computers that are accessible by local hardware, software is
an information transformer—producing, managing, acquiring, modifying, displaying, or
transmitting information that can be as simple as a single bit or as complex as a
multimedia presentation.
• As the vehicle used to deliver the product, software acts as the basis for the control of the
computer (operating systems), the communication of information (networks), and the
creation and control of other programs (software tools and environments).
The Evolving Role Of Software
• Computer software has evolved greatly in 50 years due to advancements in hardware,
computing architecture, memory, storage and input/output options leading to more
sophisticated and complex systems. This can result in great success but also pose
challenges for those developing complex systems.
• The individual programmer of the past has been replaced by a team of software
specialists, each responsible for a specific aspect of creating complex computer
applications.
• Despite the team approach, the same questions that were asked of the individual
programmer still need to be addressed -
The Evolving Role Of Software
• Why does software take so long to complete?
• Why are development expenses so high?
• Why can't all errors be found before customer release?
• Why is it hard to track progress during software development?

These questions reflect the concern over software development and have led to the
implementation of software engineering practices.
Software: A Crisis On The Horizon?
• The issues with software development have been called a "crisis" by many experts.
• There have been numerous books documenting the impact of past software failures,
however the industry has also seen great success leading some to question if the term
"crisis" is still appropriate.
• According to Webster's Dictionary, crisis is defined as a decisive moment in a course of
events.
• However, in regards to software quality and development speed, there has not been a
clear turning point, but rather gradual and evolving change with occasional
technological advancements in related fields.
Software: A Crisis On The Horizon?
• The word "affliction" means anything causing pain or distress, while the word "chronic"
means lasting a long time or recurring often.
• It is more fitting to call the problems faced in software development a chronic affliction
rather than a crisis.
• The set of problems that are encountered in the development of computer software is not
limited to software that "doesn't function properly."
• Rather, the affliction encompasses problems associated with how we develop software,
how we support a growing volume of existing software, and how we can expect to keep
pace with a growing demand for more software.
Software Myths
• Nowadays, knowledgeable professionals understand that myths are false beliefs that have
created difficulties for both managers and technical personnel.
• However, changing old attitudes and beliefs is challenging and some outdated myths
about software development are still prevalent.

 Management Myths

 Customer Myths

 Practitioner's (Developer) Myths

Software Myths
• Management myths. Managers with software responsibility, like managers in most
disciplines, are often under pressure to maintain budgets, keep schedules from slipping,
and improve quality, a software manager often grasps at belief in a software myth, if that
belief will lessen the pressure (even temporarily).
Software Myths
• 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 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."
Software Myths
• Myth: My people have state-of-the-art software development tools, after all, we buy
them the newest computers.
• Reality: It takes much more than the latest model mainframe, workstation, or PC to do
high-quality software development. Computer-aided software engineering (CASE)
tools are more important than hardware for achieving good quality and productivity, yet
the majority of software developers still do not use them effectively.
Software Myths
• Myth: If we get behind schedule, we can add more programmers and catch up
(sometimes called the Mongolian horde concept).
• Reality: Software development is not a mechanistic 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.
Software Myths
• 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 outsources software projects.
Software Myths
• Customer myths. A customer who requests computer software may be an outside
company that has requested software under contract. In many cases, the customer believes
myths about software because software managers and practitioners do little to correct
misinformation. Myths lead to false expectations (by the customer) and ultimately,
dissatisfaction with the developer.
Software Myths
• Myth: A general statement of objectives (requirement) is sufficient to begin writing
programs—we can fill in the details later.
• Reality: A poor up-front definition is the major cause of failed software efforts. A formal
and detailed description of the information domain, function, behavior, performance,
interfaces, design constraints, and validation criteria is essential. These characteristics can
be determined only after thorough communication between customer and developer.
Software Myths
• Myth: Project requirements continually change, but change can be easily accommodated
because software is flexible.
• Reality: The impact of software requirements change varies with timing, with early
changes having low cost impact and later changes increasing in cost rapidly. and changes
in production can be over 10 times more expensive.
Software Myths
Software Myths
• Practitioner's myths. Myths that are still believed by software practitioners have been
fostered by 50 years of programming culture. During the early days of software,
programming was viewed as an art form.
• Myth: Once we write the program and get it to work, our job is done.
• Reality: Industry statistics show that 60-80% of software development effort will occur
after the initial delivery to the customer. This means that a significant portion of
development work happens after the initial delivery and can include maintenance,
updates, and modifications.
Software Myths
• Myth: Until I get the program "running" I have no way of assessing its quality.
• Reality: The formal technical review is an effective software quality assurance
mechanism that can be applied from the start of a project. It functions as a "quality filter"
and has been found to be more effective than testing in identifying certain types of
software defects.
• 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. Documentation provides a foundation for successful engineering and,
more important, guidance for software support.
Software Myths
• 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
quality. Better quality leads to reduced rework. And reduced rework results in faster
delivery times.
Software Engineering: A Layered Technology
Software Engineering: A Layered Technology
• Software engineering is a layered technology with a focus on quality as its foundation.
• Total quality management leads to continuous process improvement, which supports the
software engineering process.
• The process layer is the foundation and glue that holds the technology layers together,
defining a framework for key process areas to ensure effective software delivery,
management control, and quality assurance.
• Software engineering methods provide technical guidance for building software, covering
tasks such as requirements analysis, design, programming, testing, and support. These
methods rely on basic principles and modeling activities.
Software Engineering: A Layered Technology
• Software engineering tools provide automated support for these methods, and when
integrated, form a system called computer-aided software engineering (CASE).
Examples: Testing Tools, Bug/Issue Tracking Tools etc…
Software Process
• A process is a collection of activities, actions and tasks that are performed when
some work product is to be created
• An activity try to achieve a broad objective (e.g., communication with stakeholders)
and it is applied regardless of the application domain, size of the project, complexity
of the effort, or degree of accuracy with which software engineering is to be applied.
• 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 noticeable outcome.
• Each of these activities, actions & tasks reside within a framework or model
Software Process
• Each framework activity is Software Process Framework
populated by set of software Process framework
Umbrella activities
engineering actions
framework activity #1

Software Process
• Each software engineering action is Software Engineering action #1.1
Task Sets Work tasks
defined by a task set that identifies … Work products
Quality assurance points
…
work to be completed, product to be
Software Engineering action #1.k
produced, quality assurance points Task Sets Work tasks
… Work products
& milestones to indicate progress … Quality assurance points

The purpose of software process framework activity #n

is to deliver software on time with

quality.
Process Framework Activities (CPMCD)
A process framework establishes the foundation for complete software engineering process, it encompasses
five activities
Communication Communication with Planning
Software Project Plan which
Customers / stockholders defines workflow that is to follow.
to understand project It describes technical task, risks,
requirements for defining resources, product to be
software features produced & work schedule

Modeling Construction
Creating models to Code Generation
understand requirements (manual or automated)
and shows design of &
software to achieve Testing
requirements (to uncover errors in the code)

Deliver Software to Customer

Deployment Collect feedback from customer based on evaluation
Software Support
Umbrella Activities
• Umbrella activities applied throughout the software project &
help a software team to manage and control progress,
quality, change & risks
 Umbrella activities are those which
keep running in the background
throughout the software development

Software project Risk Software quality

Tracking & Control Management assurance
It establish
a skeleton
Technical Reviews Measurement
Reusability
architecture
Management for software
Software Configuration Management
engineering
Work product preparation and production work.
Umbrella Activities Cont.

• Software project tracking and control: allows the software team to assess
progress against the project plan and take any necessary action to maintain the
schedule.
• Risk management: assesses (evaluates) risks that may affect the outcome of
the project or the quality of the product.
• Software quality assurance: defines and conducts the activities required to
ensure software quality.
• Technical reviews: assesses software engineering work products in an effort to
uncover and remove errors before they are propagated to the next activity.
• Measurement: defines and collects process, project and product measures that
assist the team in delivering software that meets stakeholders’ needs.
• Software configuration management: it manages the effects of change
throughout the software process.
Umbrella Activities Cont.
• Reusability management: it defines criteria for work product reuse
(including software components) and establishes mechanisms to
achieve reusable components.
• Work product preparation and production: it encompasses (includes)
the activities required to create work products such as models,
documents, logs, forms and lists.
Software Process Models

• In industry, a software engineer or team must

use a development strategy that includes the
process, methods, and tools layers, and
generic phases, to solve real-world problems.
This strategy is known as a process model or
software engineering paradigm.
• Also known as Software development life
cycle (SDLC) or Application development
life cycle Models Process models are not
perfect, but provide roadmap for software
engineering work.
Software Process Models
• Software development is a problem-solving loop that involves four stages:
• status quo, problem definition, technical development, and solution integration.
• Status quo represents the current state, problem definition identifies the problem,
technical development solves it through technology, and solution integration delivers the
results to the requester.
• The generic software engineering phases and steps fit into these stages.
Software Process Models

SDLC
Communi Phases
cation

Deployment
SDLC Planning

Software
Development
Life
Cycle
Construction Modeling
Different Process Models
 Process model is selected based
on different parameters

Process Models
Type of the project & people
 Complexity of the project
• Waterfall Model (Linear Sequential
 Size of team Model)
 Expertise of people in team
• Incremental Process Model
 Working environment of team
 • Prototyping Model
Software delivery deadline
• The Spiral Model
• Rapid Application Development Model
• Agile Model
The Linear Sequential Model
The Linear Sequential Model
• Sometimes called the classic life cycle or the waterfall model, the linear sequential
model suggests a systematic, sequential approach to software development.
• It is very simple to understand and use.
• In a waterfall model, each phase must be completed before the next phase can begin and
there is no overlapping in the phases.
• In this Waterfall model, typically, the outcome of one phase acts as the input for the next
phase sequentially.
The Linear Sequential Model

• Requirement Gathering and analysis − All possible requirements of the system to be

developed are captured in this phase and documented in a requirement specification
document.
• System Design − The requirement specifications from first phase are studied in this
phase and the system design is prepared. This system design helps in specifying
hardware and system requirements and helps in defining the overall system architecture.
• Implementation − With inputs from the system design, the system is first developed in
small programs called units, which are integrated in the next phase. Each unit is
developed and tested for its functionality, which is referred to as Unit Testing.
The Linear Sequential Model

• Integration and Testing − All the units developed in the implementation phase are
integrated into a system after testing of each unit. Post integration the entire system is
tested for any faults and failures.
• Deployment of system − Once the functional and non-functional testing is done; the
product is deployed in the customer environment or released into the market.
• Maintenance − There are some issues which come up in the client environment. To fix
those issues, patches are released. Also to enhance the product some better versions are
released. Maintenance is done to deliver these changes in the customer environment.
The Linear Sequential Model

Application:

• Every software developed is different and requires a suitable SDLC approach to be followed based on
the internal and external factors. Some situations where the use of Waterfall model is most appropriate
are :

• Requirements are very well documented, clear and fixed.

• Product definition is stable.

• Technology is understood and is not dynamic.

• There are no ambiguous requirements.

• Ample resources with required expertise are available to support the product.

• The project is short.

The Linear Sequential Model

Advantage:

• Simple and easy to understand and use

• Easy to manage due to the rigidity of the model. Each phase has specific deliverables and a
review process.
• Phases are processed and completed one at a time.
• Works well for smaller projects where requirements are very well understood.
• Clearly defined stages.
• Well understood milestones.
• Easy to arrange tasks.
• Process and results are well documented.
The Linear Sequential Model

Disadvantage:

• No working software is produced until late during the life cycle.

• High amounts of risk and uncertainty.
• Not a good model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a moderate to high risk of changing.
So, risk and uncertainty is high with this process model.
• It is difficult to measure progress within stages.
• Cannot accommodate changing requirements.
• Adjusting scope during the life cycle can end a project.
The Incremental Model
The Incremental Model
• The incremental model combines elements of the linear sequential model (applied
repetitively) with the iterative philosophy of prototyping. incremental model applies
linear sequences in a staggered fashion as calendar time progresses.
• Each linear sequence produces a deliverable “increment” of the software For example,
word-processing software developed using the incremental paradigm might deliver basic
file management, editing, and document production functions in the first increment; more
sophisticated capabilities in the second increment; and advanced page layout capability in
the fourth increment.
• It should be noted that the process flow for any increment can incorporate the prototyping
paradigm.
The Incremental Model
• When an incremental model is used, Basic requirements are addressed, but many
supplementary features remain undelivered.
• The core product is used by the customer (or undergoes detailed review).
• As a result of use and/or evaluation, a plan is developed for the next increment.
• The plan addresses the modification of the core product to better meet the needs of the
customer and the delivery of additional features and functionality.
• This process is repeated following the delivery of each increment, until the complete
product is produced
The Incremental Model
• The incremental process model, like prototyping and other evolutionary approaches, is
iterative in nature.
• But unlike prototyping, the incremental model focuses on the delivery of an operational
product with each increment.
• Early increments are stripped down versions of the final product, but they do provide
capability that serves the user and also provide a platform for evaluation by the user.
• Incremental development is particularly useful when staffing is unavailable for a complete
implementation by the business deadline that has been established for the project.
The Incremental Model
• Early increments can be implemented with fewer people. If the core product is well
received, then additional staff (if required) can be added to implement the next increment.
In addition, increments can be planned to manage technical risks.
• For example, a major system might require the availability of new hardware that is under
development and whose delivery date is uncertain.
• It might be possible to plan early increments in a way that avoids the use of this hardware,
thereby enabling partial functionality to be delivered to end-users without inordinate
delay.
Evolutionary Process Models
• When a set of core product or system requirements is well understood but the details of
product or system extensions have yet to be defined.
• In this situation there is a need of process model which specially designed to accommodate
product that evolve with time.
• Evolutionary Process Models are specially meant for that which produce an increasingly
more complete version of the software with each iteration.
• Evolutionary Models are iterative.
• They are characterized in a manner that enables you to develop increasingly more complete
versions of the software.
• Evolutionary models are
• Prototyping Model
• Spiral Model
The Prototyping Model
The Prototyping Model
• The prototyping paradigm begins with requirements gathering.
• Developer and customer meet and define the overall objectives for the software,
identify whatever requirements are known.
• A "quick design" then occurs. It focuses on a representation of those aspects of the
software that will be visible to the customer/user (e.g.,input approaches and output
formats).
• The quick design leads to the construction of a prototype. It is evaluated by the
customer/user and used to refine requirements for the software to be developed.
• Iteration occurs as the prototype is tuned to satisfy the needs of the customer, while at
the same time enabling the developer to better understand what needs to be done.
The Prototyping Model
• If a working prototype is built, the developer attempts to use existing program
fragments that enable working programs to be generated quickly.
• Users get a feel for the actual system and developers get to build something
immediately. Yet, prototyping can also be problematic for the following reasons:
1. A customer thinks a prototype software is working, but it's actually just held together
temporarily without consideration for quality or maintenance. When told it needs to be
rebuilt, the customer protests and demands only fixes.
2. A developer sacrifices proper implementation for a quick working prototype, using
available and familiar resources, even if they are inefficient.
The Prototyping Model
• Prototyping can be effective in software engineering with clear definition of goals from
the start, where the prototype is used to define requirements. After that, the actual
software is developed with focus on quality and maintainability, discarding parts of the
prototype.
The Spiral Model

• A spiral model is divided into a number

of framework activities, also called task
regions. Typically, there are between
three and six task regions.
 The Spiral Model
• The spiral model, originally proposed by Boehm (evolutionary model) that couples the
iterative nature of prototyping with the aspects of the linear sequential model.
• It provides the potential for rapid development of incremental versions of the software.
Using the spiral model, software is developed in a series of incremental releases.
• During early iterations, the incremental release might be a paper model or prototype.
During later iterations, increasingly more complete versions of the engineered system are
produced.
• Each pass through the planning region results in adjustments to
• the project plan
• Cost & schedule based on feedback
The Spiral Model

When to use Spiral Model?

• For development of large scale / high-risk projects.
• When costs and risk evaluation is important.
• Users are unsure of their needs.
• Requirements are complex.
• New product line.
• Significant (considerable) changes are expected.
The Spiral Model
• Customer communication—tasks required to establish effective communication
between developer and customer.
• Planning—tasks required to define resources, timelines, and other project related
information.
• Risk analysis—tasks required to assess both technical and management risks.
• Engineering—tasks required to build one or more representations of the application.
• Construction and release—tasks required to construct, test, install, and provide user
support (e.g., documentation and training).
• Customer evaluation—tasks required to obtain customer feedback based on evaluation
of the software representations created during earlier stage.
The WINWIN Spiral Model
 The WINWIN Spiral Model

1. Identification of ‘stakeholders’.

2. Determination of stakeholders to make great efforts to achieve or obtain a win condition.

3. Negotiations of stakeholders struggling vigorously for win condition. Software project team
conciliate for a win-win result with concern. Then determine next level objectives, constraints, and
alternatives.

4. Evaluation of the process and product and then analyzing and resolving or reducing the risks to
make it easy.

5. Defining the next level of product and process for proper working.

6. Validation of process and product definitions is must.

7. Reviewing of the product and giving the necessary and important comments on it.
The RAD Model
The RAD Model
• Rapid Application Development (RAD) is a software development process with a short
development cycle, achieved by using components.
• It's a fast version of the linear sequential model. If requirements are clear and scope is
limited, it can result in a fully functional system in a short period of time (60-90 days). It
includes specific phases.
• Business modeling involves modeling the flow of information among business functions
to understand the source, generation, destination, and processing of information.
• Data modeling involves refining the information flow defined in business modeling into
a set of data objects with defined attributes and relationships between them to support the
business.
The RAD Model
• Process modeling involves transforming the data objects defined in data modeling to
achieve the necessary information flow for implementing business functions. It involves
creating processing descriptions for actions such as adding, modifying, deleting, or
retrieving data objects.
• Application generation aims to reuse existing program components or create reusable
ones, using automated tools to facilitate software construction.
• Testing and turnover. Since the RAD process emphasizes reuse, many of the program
components have already been tested. This reduces overall testing time. However, new
components must be tested.
The RAD Model
• If a business application can be modularized in a way that enables each major function to
be completed in less than three months (using the approach described previously), it is a
candidate for RAD.
• Each major function can be addressed by a separate RAD team and then integrated to
form a whole.
• Like all process models, the RAD approach has drawbacks
• requires sufficient human resources, committed developers and customers,
• require appropriate applications that can be modularized.
• It may not be suitable for systems with high technical risks, such as heavy use of new
technology or high interoperability requirements.
 The Concurrent Development Model

• The concurrent process model can be

represented schematically as a series of
major technical activities, tasks, and
their associated states.
• For example, the engineering activity
defined for the spiral model is
accomplished by invoking the
following tasks: prototyping and/or
analysis modeling, requirements
specification, and design.
COMPONENT-BASED DEVELOPMENT
COMPONENT-BASED DEVELOPMENT
• It incorporates many of the characteristics of the spiral model.
• It is evolutionary in nature, the component-based development model composes
applications from prepackaged software components (called classes).
• The component-based development model leads to software reuse, and reusability
provides software engineers with a number of measurable benefits.
• Hence, software development can be done using iterative approach. In CBD model,
multiple classes can be used. These classes are basically the prepackaged components.
 COMPONENT-BASED DEVELOPMENT

The model works in following manner:

• Step-1: First identify all the required candidate components, i.e., classes with the help of application
data and algorithms.
• Step-2: If these candidate components are used in previous software projects then they must be present
in the library.
• Step-3: Such preexisting components can be excited from the library and used for further development.
• Step-4: But if the required component is not present in the library then build or create the component as
per requirement.
• Step-5: Place this newly created component in the library. This makes one iteration of the system.
• Step-6: Repeat steps 1 to 5 for creating n iterations, where n denotes the number of iterations required to
develop the complete application.
PRODUCT AND PROCESS
• If the process is weak, the end product will undoubtedly suffer, but an obsessive
overreliance on process is also dangerous.
• People derive as much (or more) satisfaction from the creative process as they do from
the end product.
• A creative software professional should derive as much satisfaction from the process as
the end-product.
• The duality of product and process is one important element in keeping creative people
engaged as the transition from programming to software engineering is finalized.
“I know what I have given to you...
I do not know what you have received.”

a n
Th
k
Y o u