SOFTWARE ENGINEERING

Course Code: 22CSE141

MODULE 1 :
Software Product and Process
 Course Specification

Course: SOFTWARE ENGINEERING

Course Code: 22CSE141

By
Staff Room: 324- 8. Dr. M.K. Jayanthi Kannan, M.E.,MS.,MBA., M.Phil., Ph.D.,
Office Hours : 8.30 AM -4 PM Professor and HOD ISE,
Department of Computer Science and Faculty of Engineering & Technology,
Engineering, JAIN Deemed To-Be University,
FET Block, Bengaluru.
 Module 1: Software Product and Process
• Introduction –FAQs About Software Engineering,
• Definition Of Software Engineering,
• Difference Between Software Engineering And Computer Science,
• Difference Between Software Engineering And System Engineering,
• Software Process,
• Software Process Models
• The Waterfall Model,
• Incremental Process Models,
• Evolutionary Process Models
• Spiral Development, Prototyping,
• Component Based Software Engineering ,
• The Unified Process, Attributes Of Good Software,
• Key Challenges Facing By Software Engineering,
• Verification – Validation
• Computer Based System
• Business Process Engineering.
 What is Engineering?
 What is Software?
 What is Software Engineering?
 What is Software Process?
 Different types of Process models.
 Different models with strengths and
weaknesses.
 Alige Software Development.
 INTRODUCTION

• Software: Computer programs and associated documentation.

software products may be developed for a particular customer or
may be developed for a general market.

• Software engineering : Software engineering is an engineering

discipline which is concerned with all aspects of software
production.

• The definition in IEEE Standard

– The application of a systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software, that is, the
application of engineering to software.

• Software process: A set of activities whose goal is the development

or evolution of software.
 What is Engineering?

 Engineering is the application of scientific and

practical knowledge in order to invent, design,
build, maintain and improve systems,
processes, etc.
 What is Software?
 The software is collection of integrated programs
 The software consists of carefully—organized instructions and
code written by programmers in any of various special computer
languages
 Computer programs and associated documentation such as
requirements, design models and user manuals.
 Software engineering is an engineering discipline that is
concerned with all aspects of software production.
 According to IEEE's definition software engineering can be defined
as the application of a systematic, disciplined, quantifiable
approach to the development, operation, and maintenance of
software, and the study of these approaches; that is, the
application of engineering to software.
 What is Software Process?
 A framework that describes the activities performed
at each stage of a software development project.
 A set of activities whose goal is the development or
evolution of software.
 Generic activities in all software processes are:
 Specification - what the system should do and its
development constraints
 Development - production of the software system
 Validation - checking that the software is what the
customer wants
 Evolution - changing the software in response to changing
demands.
 Software Engineering –Key
Challenges
 Coping with legacy systems, coping with increasing
diversity and coping with demands for delivery
times.
 Legacy systems - old, valuable systems must be
maintained and updated.
 Heterogeneity - systems are distributed and
includes a mix of hardware and software
 Delivery - there is increasing pressure for faster
delivery of software.
 Software Engineering Paradigms and
Processes
 In SE ‘Paradigm’ is heavily used:
 Discussions of superiority “Object-oriented
paradigm is the best ever …”
 Discussions of suitability “Object-oriented
paradigm is/isn’t suitable for x y z domain/tasks”
 The meaning of paradigm is overloaded and vague
What exactly do we mean by paradigm?
 Why and how a paradigm influences the process
and product of SE?
 What is ‘paradigm’?

 Etymologically: “para-” (alongside) + “-deiknunai” (to

show)
 Greek: paradeigma = example
 Works of Plato and Aristotle: a third form of reasoning
 Induction, deduction, paradeigma (example)
 One of the constituents is more “knowable”
 Typical issues related to the category they define (e.g.
cheese paradigm)
 Not very favorite of philosophers until late 20th century
 Modern meaning coined by Foucault, and esp.
 SE Paradigms
 Major paradigms in software
engineering/design:
 the procedural paradigm (emphasis on algorithm),
 the data-hiding paradigm (emphasis on data
organization),
 the data-abstraction paradigm (emphasis on types
and operations),
 and the object-oriented paradigm (emphasis on
commonality between types)
 New approaches having potential to be regarded
as paradigms in the future:
 The component-based paradigm (emphasis on reuse
through integration),
 the aspect-oriented paradigm,
 and the agent-oriented paradigm (emphasis on goal
oriented ness)

The choice of paradigm effects the quality of the process and

the product. Some apparent readings of quality parameters
might be related inherently to paradigms.
 Software Engineering process
Paradigms(SDLC)

 SDLC: SDLC is a step by step

procedure or systematic
approach to develop software
and it is followed within a
software organization.
 It consists of various phases
which describe how to design,
develop, enhance and maintain
particular software.
 Phase 1: Requirement collection and analysis:
 In this phase mainly focus on gathering the business needs from the customer. Business
Analyst collects the requirement from the customer and prepares the BRS (Business
Requirement Specification) which has the requirement in the business form. Then a
group of people sits together and determines the requirements like;
 What should be input data to the system?
 Who is going to use the system?

 What should be output data by the system?

 These questions are getting answered during this phase. After this, a
Requirement Specification document is created
 which gives the guideline for the upcoming phase of the model.

17
Phase 2: Feasibility study
 Once the BRS document is completed, a set of people like
Human Resource department, Finance department, Business
analyst, Architect and Project manager are sit together and
analyse if the project is do able or not. This decision is taken
based on the cost, time, resources and etc.

Phase 3: Design
 In this phase system design specification is prepared
from the requirement document. Design is a blue
print of the application and it helps in specifying
hardware and requirements of the system and helps
in defining architecture of the system
Phase 5:Testing:
 Once the software is ready and is deployed in the testing environment, test
engineers starts testing, if the functionality of an application is working according
to requirement or not.
 During this phase test engineers may encounter some bugs/defects which need to
be sent to developers, the developers fix the bug and sent back to test engineers
for testing.
 This process continuous until the software is bug free/stable/working according to
the requirement.

Phase 6: Installation/Deployment:

 Once the product developed, tested and works according to the

requirement it is installed / deployed at customer place for their use.

Phase 7: Maintenance:
 When the customers starts using the software they may face some issues and
needs to be solved, to fix those issue, tested and handed over back to the
customer as soon as possible, which is done in the maintenance phase.

21
 Attributes of good
software
• The software should deliver the required functionality
and performance to the user and should be
maintainable, dependable and usable.
 What is the work Product?
• From the point of view of a software engineer, the work product is the
programs, documents, and content.
• From the user’s viewpoint, the work product is the resultant information
that somehow makes the user’s world better.

• The Product
– Is the engine that drives business decision making.
– Software serves as the basis for modern scientific investigation and
engineering problem solving.
– It is embedded in systems of all kinds: transportation, medical,
telecommunications, military, industrial processes, entertainment, office
products…
 VERIFICATION AND VALIDATION
• Verification: "Are we building the product right”, The software should
conform to its specification.
• Validation: "Are we building the right product”., The software should do
what the user really requires.
 V&V
• Verification refers to the set of tasks that ensure that
software correctly implements a specific function.
• Validation refers to a different set of tasks that ensure that
the software that has been built is traceable to customer
requirements. Boehm [Boe81] states this another way:
– Verification: "Are we building the product right?"
– Validation: "Are we building the right product?"

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.
 The V & V process

• Is a whole life-cycle process - V & V must be applied at each

stage in the software process.
• Has two principal objectives
• The discovery of defects in a system;
• The assessment of whether or not the system is useful and
useable in an operational situation
 V & V goals
• Verification and validation should establish confidence that the software is
fit for purpose.

• This does NOT mean completely free of defects.

• Rather, it must be good enough for its intended use and the type of use will
determine the degree of confidence that is needed.
 SOFTWARE LIFE CYCLE
• Often used as another name for the software
process.
• Originally coined to refer to the waterfall model of
the software process.
• The Waterfall model sometimes called the classic life cycle, suggests a systematic,
sequential approach to software development.

• It is a oldest paradigm for software engineering.

• Most widely used though no longer state-of-art.

• Each step results in documentation.

• May be suited to for well-understood developments using familiar technology.

• Not suited to new, different systems because of specification uncertainty

• Difficulty in accommodating change after the process has started.

• Can accommodate iteration but indirectly.

• Working version not available till late in process.

• Often get blocking states.

THE INCREMENTAL PROCESS MODELS
• There are many situations in which initial software
requirements are reasonably well defined, but the overall scope
of the development effort precludes a purely linear process.

• In addition, there may be a compelling need to provide a

limited set of software functionality to users quickly and then
refine and expand on that functionality in later software
releases.

• In such cases, a process model that is designed to produce

the software in increments is chosen.
The Incremental Model :
• Applies an iterative philosophy to the waterfall model.

• Divide functionality of system into increments and use a liner

sequence of development on each increment.

• First increment delivered is usually the core product, i.e. only

basic functionality.

• Reviews of each increment impact on design of later

increments.

• Manages risk well.

• Extreme Programming (XP), and other Agile Methods, are

incremental, but they do not implement the waterfall model
steps in the standard order.
The Rapid Application Development (RAD) Model
• Similar to waterfall but uses a very short development cycle
(60to90 days to completion).

• Uses component-based construction and emphasizes reuse

and code generation.

• Use multiple teams on scalable projects.

• Requires heavy resource.

• Requires developers and customers who are heavily

committed.

• Performance can be a problem.

• Difficult to use with new technology .

 EVOLUTIONARY MODELS
• Evolutionary models are iterative. They are characterized in a manner that enables
software engineers to develop increasingly more complete versions of the software.
• PROTOTYPING :
PROTOTYPING :
• Ideally mock-up serves as mechanism for identifying
requirements.
• Users like the method, get a feeling for the actual system.
• Less ideally may be the basis for completed.
• Prototypes often ignore quality/performance/maintenance issues.
• May create pressure from users on deliver earlier.
• May use a less-than-ideal platform to deliver e.g Visual Basic –
excellent for prototyping, may not be as effective in actual
operation.
• Specifying requirements is often very difficult.
• Users don’t know exactly what they want until they see it.
• Prototyping involves building a mock-up of the system and using
to obtain for user feedback.
• Closely related to what are now called “Agile Methods”
The Spiral Model
Development cycles through multiple (3-6) task regions
(6 stage version).
• Customer communication
• Planning
• Risk analysis
• Engineering
• Construction and release
• Customer evaluation.

Incremental releases :
– Early releases may be paper or prototypes.
– Later releases become more complicated
– Models software until it is no longer used
– Not a silver bullet, but considered to be one of the best
approaches.
– Requires excellent management and risk assessment
skills.
 Concurrent Development Model
• The concurrent development model, sometimes
called concurrent engineering, can be
represented schematical series of framework
activities, software engineering as a g actions and
tasks, and their associated states.
• The concurrent process model defines a series of
events that will trigger transitions from state to
state for each of the software engineering
activities, action, or tasks.
• The concurrent process model is applicable to all
types of software development and provides an
accurate picture of the current state of a project.
• Rather than confining software engineering
activities, actions, and tasks to a sequence of
events, it defines a network of activities.
• Each activity, action, or task on the network exists
simultaneously with other activities, actions, or
tasks.
• Events generated at one point in the process
network trigger transitions among the states.
 Software Engineering- Computer Based Systems
The word system is possibly the most overused and abused term in the
technical lexicon. We speak of political systems and educational
systems, of avionics systems and manufacturing systems, of banking
systems and subway systems. Webster's Dictionary defines system in
the following way:

1. a set or arrangement of things so related as to form a unity or organic

whole;
2. a set of facts, principles, rules, etc., classified and arranged in an
orderly form so as to show a logical plan linking the various parts;
3. a method or plan of classification or arrangement;
4. an established way of doing something; method; procedure .

Five additional definitions are provided in the dictionary, yet no precise

synonym is suggested. System is a special word.

Borrowing from Webster's definition, we define a computer-based system

as
A set or arrangement of elements that are organized to accomplish some
predefined goal by processing information.
Software Engineering- Computer Based Systems
The goal may be to support some business function or to develop a
product that can be sold to generate business revenue. To accomplish the
goal, a computer-based system makes use of a variety of system
elements:

Software. Computer programs, data structures, and related

documentation that serve to effect the logical method, procedure, or
control that is required.
Hardware. Electronic devices that provide computing capability, the
interconnectivity devices (e.g., network switches, telecommunications
devices) that enable the flow of data, and electromechanical devices (e.g.,
sensors, motors, pumps) that provide external world function.
People. Users and operators of hardware and software.
Database. A large, organized collection of information that is accessed via
software.
Documentation. Descriptive information (e.g., hardcopy manuals, on-line
help files, Web sites) that portrays the use and/or operation of the system.
Procedures. The steps that define the specific use of each system
element or the procedural context in which the system resides.
The elements combine in a variety of ways to transform information
 SPECIALIZED PROCESS MODELS

• Component based development—the process to

apply when reuse is a development objective.

• Formal methods—emphasize the mathematical

specification of requirements.

• AOSD—provides a process and methodological

approach for defining, specifying, designing, and
constructing aspects
THE UNIFIED PROCESS (UP)
• A “use-case driven, architecture-centric, iterative and incremental” software
process closely aligned with the Unified Modeling Language (UML)

Unified Process Phases

• The inception phases of the up encompass both customer communication and

planning activities and emphasize the development and refinement of use-
cases as a primary model.

• An elaboration phase that encompasses the customer’s communication and

modeling activities focusing on the creation of analysis and design models
with an emphasis on class definitions and architectural representations.

• A construction phase that refines and translates the design model into
implemented software components.

• A transition phase that transfers the software from the developer to the end-
user for beta testing and acceptance.

• A production phase in which on-going monitoring and support are conducted.

 System Engineering
• Systems engineering is the activity of specifying, designing, implementing,
validating, deploying and maintaining socio-technical systems.
• Systems engineers are not just concerned with software but also with
hardware and the system's interactions with users and its environment.
• They must think about the services that the system provides, the constraints
under which the system must be built and operated and the ways in which
the system is used to fulfill its purpose.
• System engineering is concerned with all aspects of computer-based
systems development, including hardware, software and process
engineering. Software engineering is part of this process.
• System engineering is an older discipline than software engineering.
• People have been specifying and assembling complex industrial systems
such as aircraft and chemical plants for more than a hundred years.
• However, as the percentage of software in systems has increased, software
engineering techniques such as use-case modeling and configuration
management are being used in the systems engineering process.
 SYSTEM ENGINEERING PROCESS

Requirements System
definition decommissioning

System System
design evolution

Sub-system System
development installation

System
integration
 System design problems
• Requirements partitioning to hardware,
software and human components may involve a lot of
negotiation

• Difficult design problems are often assumed to be readily

solved using software

• Hardware platforms may be inappropriate for

software requirements so software must compensate for this
 Sub-system development
• Typically parallel projects developing the
hardware, software and communications

• May involve some COTS (Commercial Off-the-Shelf) systems

procurement

• Lack of communication across implementation

teams

• Bureaucratic and slow mechanism for

proposing system changes means that the development schedule may be
extended because of the need for rework
 System integration
• The process of putting hardware, software and
people together to make a system

• Should be tackled incrementally so that sub-systems are integrated one at

a time

• Interface problems between sub-systems are usually found at this stage

• May be problems with uncoordinated deliveries

of system components
 System installation
• Environmental assumptions may be incorrect

• May be human resistance to the introduction of

a new system

• System may have to coexist with alternative

systems for some time

• May be physical installation problems (e.g.

cabling problems)

• Operator training has to be identified

 System operation
• Will bring unforeseen requirements to light

• Users may use the system in a way which is

not anticipated by system designers

• May reveal problems in the interaction with

other systems

• Physical problems of incompatibility

• Data conversion problems

• Increased operator error rate because of inconsistent interfaces

 System Evolution
• Large systems have a long lifetime. They must evolve to meet changing
requirements
• Evolution is inherently costly
– Changes must be analysed from a technical and business perspective
– Sub-systems interact so unanticipated problems can arise
– There is rarely a rationale for original design decisions
– System structure is corrupted as changes are made to it
• Existing systems which must be maintained are sometimes called legacy
systems
 System decommissioning
• Taking the system out of service after its useful lifetime

• May require removal of materials (e.g. dangerous chemicals) which pollute

the environment

– Should be planned for in the system design by encapsulation

• May require data to be restructured and converted to be used in some other

system
ATC System Engineering
 computer-based systems
• Technical computer-based systems are systems that include
hardware and software components but not procedures and
processes.
• Examples of technical systems include televisions, mobile
phones and most personal computer software.
• Individuals and organizations use technical systems for some
purpose but knowledge of this purpose is not part of the
system.
• For example, the word processor.
 BUSINESS PROCESS ENGINEERING
• Business process engineering is a structured approach to improving a company’s
performance in areas such as cost, service, quality, and speed through changes in
(appropriately) processes.
• Organize around the outcome, not the specific task. One person owns a whole
process, performing or coordinating all steps.
• Those closest to the process should perform the process. Instead of farming
out different types of easily managed work, the people who need the quick
outcomes from simple tasks take ownership.
• Have the people who produce the information process it. This streamlines the
outcome of the information gathered into usable data.
• Centralize resources. Databases and other technology systems can consolidate
resources to cut down on redundancies and increase flexibility.
• Integrate corresponding activities, not merely their results. This keeps the
content cohesive, without the gaps and miscommunication that could cause
delays.
• Control the decision points and where the work is done. Built-in controls
enable the employees who perform the work to self-manage, so managers can
become supportive rather than directive.
• Information should be collected once and at the source. You can erase data
redundancies when processes are connected in a central database
 Business Process Engineering

Business process Common guiding principles for

engineering is a way in the stages are as follows:
which organizations • Step 0: Preparation and
study their current Coordination
business processes and
• Step 1: Set the Vision
develop new methods to
improve productivity, • Step 2: Assemble the Team
efficiency, and • Step 3: Determine the
operational costs. Processes
• Step 4: Redesign
 What is Business Process Engineering?
• Business process engineering is a way in which
organizations study their current business
processes and develop new methods to improve
productivity, efficiency, and operational costs.
• As a business process engineer, you will examine
the way an organization operates, its long-term
performance goals, and recommend ways it can
work more seamlessly to achieve overall
improvement.
• Many business process engineers work as
consultants contracted by companies seeking
improvements to their methodology and
infrastructure.
 PRODUCT ENGINEERING
• Product Engineering is the process of innovating, designing, developing, testing and
deploying a software product.

• The various phases of product engineering are:

– Product Ideation
– Product Architecture
– Product Design
– Product Testing
– Product Migration and Porting
– Technical Support
– Sustaining Engineering
– Professional Services
 SUMMARY
Module 1: Software Product and Process
In Module 1 we discussed the following topics like,
 Introduction –FAQs About Software Engineering,
 Definition Of Software Engineering,
 Difference Between Software Engineering And Computer Science,
 Difference Between Software Engineering And System Engineering,
 Software Process,
 Software Process Models
 The Waterfall Model,
 Incremental Process Models,
 Evolutionary Process Models
 Spiral Development, Prototyping,
 Component Based Software Engineering ,
 The Unified Process, Attributes Of Good Software,
 Key Challenges Facing By Software Engineering,
 Verification – Validation
 Computer Based System
 Business Process Engineering.