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,

1. SOFTWARE ENGINEERING
Course Code: 22CSE141
MODULE 1 :
Software Product and Process

2. By
Dr. M.K. Jayanthi Kannan, M.E.,MS.,MBA., M.Phil., Ph.D.,
Professor and HOD ISE,
Faculty of Engineering & Technology,
JAIN Deemed To-Be University,
Bengaluru.
Staff Room: 324- 8.
Office Hours : 8.30 AM -4 PM
Department of Computer Science and
Engineering,
FET Block,
Course Specification
Course: SOFTWARE ENGINEERING
Course Code: 22CSE141

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

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

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

6. What is Engineering?
 Engineering is the application of scientific and
practical knowledge in order to invent, design,
build, maintain and improve systems,
processes, etc.

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

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

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

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

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

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

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

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

15. Attributes of good
software
• The software should deliver the required functionality and performance to
the user and should be maintainable, dependable and usable.

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

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

19. These slides are designed to accompany Software Engineering:
A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides
copyright 2009 by Roger Pressman. 19
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?"

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

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

22. SOFTWARE LIFE CYCLE
• Often used as another name for the software
process.
• Originally coined to refer to the waterfall
model of the software process.

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

26. THE INCREMENTAL PROCESS MODELS

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

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

29. The Rapid Application Development (RAD) Model

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

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

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

33. The Spiral Model

34. Development cycles through multiple (3-6) task regions (6stage 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

35. Concurrent Development Model
• The concurrent development model, sometimes called concurrent engineering,
can be represented schematically as a series of framework activities, software
engineering 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.

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

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

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

42. SYSTEM ENGINEERING PROCESS
System
integration
Sub-system
development
System
design
Requirements
definition
System
installation
System
evolution
System
decommissioning

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

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

45. • 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 integration

46. • 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 installation

47. • 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 operation

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

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

50. ATC System Engineering

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

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

53. Common guiding principles for the stages are as follows:
• Step 0: Preparation and Coordination
• Step 1: Set the Vision
• Step 2: Assemble the Team
• Step 3: Determine the Processes
• Step 4: Redesign

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

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