It gives an overview/ introduction to software engineering

1. Software Engineering
By:
Ashok Mohanty
Reader, Dept. of Mechanical Engg.
College of Engg. & technology, Bhubaneswar
This ppt is based on:
1. Software Engineering, Jibitesh Mishra & Ashok Mohanty, Pearson
Education
2. Software Engineering, Pressman, McGrawHill
3. Guide to Software Engineering Body of Knowledge (SWEBOK),
IEEE Computer Society’s Professional Practices Committee, 2004
©Ashok Mohanty,
<amohanty01@yahoo.com> 1

2. Topics to be discussed
• Characteristics of commercial software
• Emergence of Software Engineering
• Core aspects of software engineering
• Software processes
• Software Development Life Cycle Models
• Types of software requirements
• Methods and Activities in Requirement Engineering
• Structure of Software Requirement Specification (SRS)
• Approaches to Software Engineering
• Function Oriented (FO) approach
• Object Oriented (OO) approach
©Ashok Mohanty,
<amohanty01@yahoo.com> 2

3. Software is a general term for Programs & Data
Characteristics of commercial Software
• Developed for some clients under formal contracts
• Software is designed based on some specification
• Developed in teams and not by individuals
• Includes detailed documentation
• Meant for users
• Requires some modification from time to time.
• Does not wear out but has a lifespan, after which it becomes
obsolete.
• Software failure may create catastrophe. So software is designed
for utmost reliability.
• A computer system is prone to misuse or sabotage. So software
is designed to be temper-proof
©Ashok Mohanty,
<amohanty01@yahoo.com> 3

4. Software Development
Design and development of software requires great amount of
effort, time and money
Computer programming is just one part of the process.
It requires a systematic approach that includes
• Comprehensive methods
• Tools for efficient execution of methods
• Procedures for quality assurance
• Coordination and control
It also involves people and their management.
All these engineering aspects relating to software development
have combined together to evolve as a discipline
called Software Engineering.
Manufactured product Industrial Engineering
Software product Software Engineering ©Ashok Mohanty,
<amohanty01@yahoo.com> 4

5. Software Crisis
During 1970s, large numbers of software projects failed mostly
due to human factors. This problem was referred to as the
“software crisis”.
Study by Comptroller General of the United States (1979):
2% of software worked on delivery
3% worked only after some corrections
45% delivered, but never successfully used
20% used, only after major modification/ reworked
30% were paid for, never completed/ delivered
Software Crisis led to Software Engineering
Software Engineering
• Systematic approach to software development
• Application of engineering principles
• Provides a set of methods, tools, and procedures
• Ensures consistent software quality ©Ashok Mohanty,
<amohanty01@yahoo.com> 5

6. Core Aspects of SE
The subject ‘Software Engineering’ is
inter-disciplinary in nature.
Software development requires
active involvement and participation of software
users and developers.
It requires domain knowledge of various fields including
computer science and area for which software being made.
Product, Process, People, and Project are the four core
aspects of software development.
©Ashok Mohanty,
<amohanty01@yahoo.com> 6

7. SE includes 10 Knowledge Areas
1. Software requirements 6. Software configuration mgmt.
2. Software design 7. Software engg. Management
3. Software construction 8. Software engg. process
4. Software testing 9. Software engg. tools &methods
5. Software maintenance 10. Software quality
SE knowledge derived from 8 subject areas
1. Computer Engineering 5. Project Management
2. Computer Science 6. Quality Management
3. Management 7. Software Ergonomics
4. Mathematics 8. Systems Engineering
©Ashok Mohanty,
<amohanty01@yahoo.com> 7

8. Software Process
refers to methods of developing software
It has four major component processes
1. Software Development Process
2. Software Project Management Process
3. Software Configuration Management Process
4. Software Process Management Process
Software Development Process
It is a structured set of activities that transform the user
requirements into a quality software product.
©Ashok Mohanty,
<amohanty01@yahoo.com> 8

9. Process Model
Sequential Process Model Iterative Process Model
Sequential Process Models Iterative Process Models
Software is developed in a A prototype is developed using the
sequence of stages sequential process.
Stages are: After one part is completed, all
Analysis, Design, activities are repeated for
developing the next part.
Coding, Testing, etc.
©Ashok Mohanty,
<amohanty01@yahoo.com> 9

10. Sequential Process Models
The Waterfall model
Traditional sequential process model
Software development takes place in well defined phases
1. System Engineering 4. Implementation or Coding
2. Requirement Analysis 5. Verification or testing
3. Design 6. Maintenance
The V-model
Extension of Waterfall model
Stipulates various kinds of testing, like unit (module) testing and
integration testing.
Information from earlier phases also used for testing
©Ashok Mohanty,
<amohanty01@yahoo.com> 10

11. Iterative Process Models
Prototyping Model
It is of two types
Throw-away prototyping Evolutionary prototyping
Used for checking software Initial working model of software based
requirement specification on outline specification. This prototype
is evaluated and refined in number of
stages to get final product.
Spiral model: Each cycle consists of four step
1. Planning 2. Risk Analysis 3. Engineering 4.Validation
Spiral model emphasizes on risk management.
Iterative Waterfall Model: It overcomes the limitations of
Waterfall Model by adding an “iterative” loop. After end of each phase, its
previous phases are revisited to modify requirements and to remove errors.
©Ashok Mohanty,
<amohanty01@yahoo.com> 11

12. Software is developed to perform certain Functions.
Functions is stipulated by Software requirements
(It provides the basis for software development.)
Requirement Engineering (RE)
is a systematic approach for determining
Software Requirement Specifications (SRS)
6 types of software requirement specifications
• Functional requirement
• Design requirement
• Implementation requirement
• Interface requirement
• Performance requirement
• Physical requirement.
©Ashok Mohanty,
<amohanty01@yahoo.com> 12

13. Requirement Engineering Activities
1. Inception Understanding the situation that have initiated
the software project
Identification of stakeholders
2. Elicitation Seeking information about the software,
system and business (through interview,
questionnaire, record review, observation, etc).
Provides initial user requirements
3. Elaboration Developing a refined technical model of
software functions, features & constraints
4. Negotiation Making tradeoff & fixing priorities
5. Validation Requirement specification assessed for
correctness & quality
©Ashok Mohanty,
<amohanty01@yahoo.com> 13

14. Requirement Engineering Process
©Ashok Mohanty,
<amohanty01@yahoo.com> 14

15. Typical Structure of SRS Document
1. Introduction
1.1 Name & purpose of software; 1.2 Scope, benefits, objectives, and goals; 1.3 Types
of audience/ users
2. Overall Description
2.1 Product Perspective: Context and origin (how initiated?); Block diagram of overall
system to which software relates; 2.2 Product Features: Major features and significant
functions; Organization of functions/ modules; 2.3 Category/ types of users; 2.4
Performance Requirements; 2.5 Operating Environment: Hardware platform, operating
system, database system, etc.; 2.6 Design and Implementation Constraints; 2.7 Security,
safety and privacy Requirements; 2.8 User Documentation; 2.9 Assumptions
3. Software Features: (Detailed software features)
3.1 Name of feature; 3.2 Description of feature & its priority; 3.3 Sequences of user
actions & system responses; 3.4 Functional Requirements
4. External Interface Requirements
4.1 User Interfaces; 4.2 Hardware Interfaces; 4.3 Software Interfaces; 4.4
Communications Interfaces
5. Other Non-functional Requirements
5.1 Performance Requirements; 5.2 Safety and Security Requirements; 5.3 Software
quality attributes; 5.4 Other requirements if any
6. Appendix:
©Ashok Mohanty,
6.1 Glossary of terms; 6.2 List of issues; 6.3 Figures and diagrams
<amohanty01@yahoo.com> 15

16. Software development process
Comprises of following activities.
System Analysis or Requirement Analysis
Software Design
Implementation or Coding
Testing or Inspection
Maintenance or Adaptation
Activities are performed according to a plan.
©Ashok Mohanty,
<amohanty01@yahoo.com> 16

17. Approaches to Software
Engineering
System for which software is to be developed is
successively broken down (decomposed) into parts
and arranged in to hierarchy.
Decomposition is a convenient way of handling any
complex problem.
TWO approaches to Software Engineering
1. Function-Oriented (FO) Approach
2. Object-Oriented (OO) Approach
Similarity: System factored into parts in both approaches
Difference: lies in the basis on which the system is factored
17

18. Function Oriented vs Object Orient
FO approach focus is on functions or processes
Functions Sub-functions more Sub-functions
OO approach focus is on objects or entities
Object Parts (child-objects) more parts (child-objects)
FO emphasis on ‘what system does (verb)
OO emphasis on ‘what system consists of (noun)’.
©Ashok Mohanty,
<amohanty01@yahoo.com> 18

19. Example of academic institution
Functions Entities that do the functions
Impart teaching on theory Teachers, Classroom, Syllabus
Impart teaching on practical Teachers, Laboratories, Syllabus
Conduct examination Examination section, Classroom,
Question-setter, Invigilators, etc.
Evaluate students’ Examination section, Examiners,
performance etc.
FO approach concentrates on functions.
OO approach focuses on objects that do the functions.
©Ashok Mohanty,
<amohanty01@yahoo.com> 19

20. Function Oriented Approach
FO approach is traditional. It supports structured
programming
A structured program consists of functions (modules) organized in a
hierarchy.
Higher level function invokes lower level function.
Data is either local or global
Function 1
Local Data
Calls
Function 2
Operates on
Local Data
Calls Global Data
Function 3
Local Data
Operates on
©Ashok Mohanty,
<amohanty01@yahoo.com> 20

21. FO methodology is also called
‘Structured System Analysis and Design (SSAD)’.
Structured analysis is done to determine:
– Functions to be performed
– Data to be manipulated
– Constraints on functions and data
Functional specification specifies ‘what the software is expected to
do?’ It provides the basis for design of software.
Structured Design is done to develop design
specification.
Design specification is the blue print for constructing the
software.
Design specification is translated into a program code.
©Ashok Mohanty,
<amohanty01@yahoo.com> 21

22. Tools used in SSAD
Tools Purpose
Data Flow Diagram Process mapping of system
(DFD)
Data Dictionary List of different data items used in
system
ER Diagram Data modelling
Process Specification Depicts procedures used in system
Tools
State Transition Diagram Depicts chronological events and
(ST Diagram) corresponding system states
Structure chart Depicts modular design of a program
Structured English/ Depicts logic of program
Pseudocode 22

23. Structured Analysis
Environmental Model
• Statement of Purpose Structured Design
• Context Diagram
• Event List Implementation Model
Behavioural Model •Structure chart
•Interface design
•Data design
• Data Flow Diagram •Module specification
• Data Dictionary
• ER diagram
• Process specification
• State Transition Diagram
Function Oriented Approach to Software Development
©Ashok Mohanty,
<amohanty01@yahoo.com> 23

24. Overview of Object Oriented Approach
World is made up of entities or objects.
So analysis and design a system in terms of objects is closer to the
real world modelling.
The object oriented approach uses object oriented programming
concepts.
Object consists of data structures combined with relevant
functions (method)
An object is invoked by its method.
Invocation of a method may change either the properties of the
object or invoke some other object.
©Ashok Mohanty,
<amohanty01@yahoo.com> 24

25. Object 1 Object 2
Methods Methods
Data Data
All arrows represent Invokes
Object 3 Object 4
Methods Methods
Data Data
Messages passing within Objects
In OO approach, system functionality is expressed in terms of
operations or services associated with each object.

26. Object Oriented Analysis & Design (OOAD)
The OOAD comprises of
Object Oriented Analysis (OOA)
Object Oriented Design (OOD)
Documentation Tool
• Unified Modelling Language (UML)’ is a
documentation tool used in OOAD methodology
• UML has evolved from the work of Grady Booch,
James Rumbaugh, Ivar Jacobsen, and others at
Rational Corporation in 1997.
• At present, the UML has almost become an industry
standard documentation tool.
• UML comprises of number of diagrams
©Ashok Mohanty,
<amohanty01@yahoo.com>

27. Steps of OOA
•Define User View of Requirements
•Identify Analysis Objects and their Characteristics
•Determine Object Dynamics
•Determine Object Interactions and relationship
Diagrams used in OOA.
Use case diagram Describes how users interact with processes
Class diagram It is used to refine the use case diagram and define a
detailed design of the system
State diagram Represents different states that objects in the system
undergo during their life cycle
Activity diagram Describes the process flow of the system
Sequence diagram Represents interaction between objects
Collaboration diagram Groups together interactions between objects.
27

28. Fundamental questions in OOD
•What objects do we need?
•What behaviours are required?
•How do we distribute behaviour over the set of objects?
Static Modelling’
Classes, Attributes, Methods
and Associations
Identified in OOA Designed for
implementation in OOD
Objects also perform some action. Defining the
behaviour (methods) of objects is called the
‘Dynamic Modelling’. ©Ashok Mohanty,
<amohanty01@yahoo.com> 28

29. Diagrams in OOD
Name of diagram Purpose
Component Represents high-level parts that make up the
diagram system.
Deployment Captures configuration of runtime elements
diagram of application
Package Holds model elements such as classes, state
machines and use cases.
Subsystem Represents a portion of a system that can be
implemented as a distinct component
©Ashok Mohanty,
<amohanty01@yahoo.com> 29

30. The OOAD comprises of
Object Oriented Analysis (OOA)
Object Oriented Design (OOD)
But there is overlapping of both these phases
e.g, Class diagram and Object diagram are included in
OOA. But these are also useful in OOD..
OO Analysis OO Design OO Coding
©Ashok Mohanty,
<amohanty01@yahoo.com> 30

31. SSAD vs OOAD
Same basic steps
– Understand the problem
– Specify requirements (WHAT)
– Design the solution (HOW)
– Write the code
– Test and deploy
Similar types of tasks
– Elicitation of requirements
– Documentation of requirements
– Identification of software modules
– Design of software modules
– Acceptance tests
Similar project management issues
e.g. Planning, Estimating, Monitoring & Control, Communicating
31

32. How OO Approach is different?
• Different View of the System
• Integration of Data and Method
• Different Documentation Tools
• Real World Focus
• Approach to Project Life Cycle
• Approach to Program Coding
• Approach to Component Reuse
• Approach to Software Maintenance
FO methodology is more suitable for data intensive software
projects, whereas OO methodology is more suitable for
software project that requires complex algorithm/ processing
logic.
©Ashok Mohanty,
<amohanty01@yahoo.com> 32

33. References
1. Software Engineering,
Jibitesh Mishra & Ashok Mohanty,
Pearson Education
2. Software Engineering,
Pressman,
McGrawHill
3. Guide to Software Engineering Body of Knowledge,
IEEE Computer Society’s Professional Practices Committee, 2004
©Ashok Mohanty,
<amohanty01@yahoo.com> 33