SUBJECT CODE : 22413

As per Revised Syllabus of

MSBTE - I Scheme
S.Y. Diploma Semester - IV
Computer Engineering Group & Information Technology
(CO / CM / IF / CW)

Software Engineering
Anuradha A. Puntambekar
M.E. (Computer)
Formerly Assistant Professor in
P.E.S. Modern College of Engineering,
Pune

Yogesh S. Gunjal
M. Tech (Computer Science and Engineering)
I/C Principal,
JCEI's Jaihind Polytechnic Kuran, Pune

Narendra S. Joshi
M.E. (CSE), Ph.D. (Pursuing),
HOD (Computer Engineering Department),
Assistant Professor,
Sandip Foundation's, Sandip Institute of Polytechnic (SIP),
Nashik

Yogesh B. Patil
M.Tech (I.T.), B.E. (I.T.)
HOD Computer Department,
G.M.Chaudhari Polytechnic, Shahada.

®
TECHNICAL
PUBLICATIONS
SINCE 1993 An Up-Thrust for Knowledge

(i)
Software Engineering
Subject Code : 22413

S.Y. Diploma Semester - IV

Computer Engineering Group & Information Technology (CO / CM / IF / CW)

First Edition : January 2019

Second Revised Edition : January 2020

ã Copyright with A. A. Puntambekar

All publishing rights (printed and ebook version) reserved with Technical Publications. No part of this book
should be reproduced in any form, Electronic, Mechanical, Photocopy or any information storage and
retrieval system without prior permission in writing, from Technical Publications, Pune.

Published by :
®

TECHNICAL Amit Residency, Office No.1, 412, Shaniwar Peth, Pune - 411030, M.S. INDIA
PUBLICATIONS P h . : + 9 1 - 0 2 0 - 2 4 4 9 5 4 9 6 / 9 7 , Te l e f a x : + 9 1 - 0 2 0 - 2 4 4 9 5 4 9 7
SINCE 1993 An Up-Thrust for Knowledge
Email : [email protected] Website : www.technicalpublications.org

ISBN 978-93-332-0046-2

9 789333 200462 MSBTE I

9789333200462 [2] (ii)

Syllabus
Software Engineering (22413)
Teaching Examination Scheme
Scheme

L T P Credit Theory Practical

(L+T+P)
Paper ESE PA Total ESE PA Total
Hrs.
Max Min Max Min Max Min Max Min Max Min Max Min

3 - 2 5 3 70 28 30* 00 100 40 25@ 10 25 10 50 20

Unit Unit Outcomes (UOs) Topics and Sub - topics

(in cognitive domain)
Unit - I 1a. Suggest the attributes that 1.1 Software, Software Engineering as layered
Software match with standards for approach and its characteristics, Types of
Development the given software software.
Process application. l.2 Software development framework.
1b. Recommend the relevant 1.3 Software Process Framework, Process
software solution for the models : Perspective Process Models,
given problem with Specialized Process Models.
justification.
1.4 Agile Software development : Agile Process
1c. Select the relevant software and its importance, Extreme Programming,
process model for the given Adaptive Software Development, Scrum,
problem statement with Dynamic Systems Development Method
justification. (DSDM), Crystal.
1d. Suggest the relevant 1.5 Selection criteria for software process
activities in Agile model.
Development Process in the
given situation with
justification.
Unit - II 2a. Apply the principles of 2.1 Software Engineering Practices and its
Software software engineering for the importance, Core principles.
Requirement given problem. 2.2 Communication Practices, Planning
Engineering 2b. Choose the relevant Practices, Modelling practices, construction
'requirement engineering' practices, software deployment (Statement
steps in the given problem. and meaning of each principle for each
2c. Represent the 'requirement practice).
engineering' model in the 2.3 Requirement Engineering : Requirement
given problem. Gathering and Analysis, Types of
2d. Prepare SRS for the given requirements (Functional, Product,
problem. organizational, External Requirements),
Eliciting Requirements, Developing Use -
cases, Building requirement models,
Requirement Negotiation, Validation.
2.4 Software Requirement Specification : Need
of SRS, Format, and its Characteristics.

(iv)
 Unit - III 3a. Identify the elements of 3.1 Translating Requirement model into design
Software analysis model for the given model : Data Modelling.
Modelling and software requirements. 3.2 Analysis Modelling : Elements of Analysis
Design 3b. Apply the specified design model.
feature for software 3.3 Design modelling : Fundamental Design
requirements modelling, Concepts (Abstraction, Information hiding,
3c. Represent the specified Structure, Modularity, Concurrency,
problem in the given design Verification, Aesthetics).
notation. 3.4 Design notations : Data Flow Diagram
3d. Explain the given (DFD), Structured Flowcharts, Decision
characteristics of software Tables.
testing. 3.5 Testing - Meaning and purpose, testing
3e. Prepare test cases for the methods - Black Box and White - box,
given module. Level of testing - Unit testing.
3.6 Test Documentation - Test Case Template,
test plan, Introduction to defect report, test
summary report.
Unit - IV 4a. Estimate the size of the 4.1 The management spectrum - 4P's.
Software Project software product using the 4.2 Metrics for Size Estimation : Line of Code
Estimation given method. (LoC), Function Points (FP).
4b. Estimate the cost of the 4.3 Project Cost Estimation Approaches :
software product using the Overview of Heuristic, Analytical, and
given empirical method. Empirical Estimation.
4c. Evaluate the size of the 4.4 COCOMO (Constructive Cost Model),
given software using COCOMO II.
CoCoMo model.
4.5 Risk Management : Risk Identification, Risk
4d. Apply the RMMM strategy Assessment, Risk Containment, RMMM
in Identified risks for the strategy.
given software development
problem.
Unit - V 5a. Use the given scheduling 5.1 Project Scheduling : Basic Principles, Work
Software Quality technique for the identified breakdown structure, Activity network and
Assurance and project. critical path Method, Scheduling tachniques
Security 5b. Draw the activity network (CPM, PERT).
for the given task. 5.2 Project Tracking : Timeline charts, Earned
5c. Prepare the timeline chart / Value Analysis, Gantt Charts.
Gantt chart to track progress 5.3 Software Quality Management vs. Software
of the given project. Quality Assurance
5d. Describe the given Software Phases of Software Quality Assurance :
Quality Assurance (SQA) Planning, Activities, audit, and review.
activity. 5.4 Quality Evaluation standards : Six Sigma,
5e. Describe features of the ISO for software, CMMI : Levels, Process
given software evaluation areas.
standard. 5.5 Software Security, Introduction to DevOps,
Secure software engineering.

(v)
(vi)
 Table of Contents
......................................2-1
Unit - I
2.2 Core Principles . . . . . . . . . . . . . . . . . . . . . . . . . 2 - 1
Chapter - 1 Software Development Process 2.3 Communication Practices . . . . . . . . . . . . . . . . . 2 - 2
(1 - 1) to (1 - 16)
2.4 Planning Practices. . . . . . . . . . . . . . . . . . . . . . . 2 - 2
1.1 Definition of Software and Software Engineering . . 2.5 Modeling Practices . . . . . . . . . . . . . . . . . . . . . . 2 - 3
......................................1-1
2.6 Construction Practices . . . . . . . . . . . . . . . . . . . 2 - 4
1.2 Software as Layered Approach . . . . . . . . . . . . . 1 - 1
2.7 Software Deployment . . . . . . . . . . . . . . . . . . . . 2 - 5
1.3 Characteristics of Software Engineering . . . . . . 1 - 2
Part II : Requirement Engineering
1.4 Types of Software . . . . . . . . . . . . . . . . . . . . . . . 1 - 3
1.5 Software Development Framework . . . . . . . . . . 1 - 3 2.8 Requirement Gathering and Analysis . . . . . . . . 2 - 5
2.8.1 Inception. . . . . . . . . . . . . . . . . . . . . . . . . . . 2 - 6
1.6 Software Process Framework . . . . . . . . . . . . . . 1 - 4
2.8.2 Elicitation . . . . . . . . . . . . . . . . . . . . . . . . . . 2 - 6
1.7 Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . 1 - 5
2.8.3 Elaboration . . . . . . . . . . . . . . . . . . . . . . . . . 2 - 6
1.7.1 Perspective Process Model . . . . . . . . . . . . . 1 - 5
2.8.4 Negotiation. . . . . . . . . . . . . . . . . . . . . . . . . 2 - 6
1.7.1.1 Waterfall Model . . . . . . . . . . . . . . . . . 1 - 5
2.8.5 Specification. . . . . . . . . . . . . . . . . . . . . . . . 2 - 6
1.7.1.2 RAD Model (Incremental Model) . . . 1 - 6
2.8.6 Validation. . . . . . . . . . . . . . . . . . . . . . . . . . 2 - 6
1.7.1.3 Spiral Model . . . . . . . . . . . . . . . . . . . 1 - 7
2.8.7 Requirement Management . . . . . . . . . . . . . 2 - 7
1.7.2 Specialized Process Model . . . . . . . . . . . . . 1 - 9
2.9 Types of Requirements . . . . . . . . . . . . . . . . . . 2 - 7
1.7.2.1 Component Based Development . . . . 1 - 9
2.9.1 Functional Requirements . . . . . . . . . . . . . 2 - 7
1.7.2.2 Formal Methods Model . . . . . . . . . . . 1 - 9
2.9.1.1 Problems Associated with Requirements.
1.8 Agile Software Development. . . . . . . . . . . . . . 1 - 10
.................................2-7
1.8.1 Agile Process and its Importance . . . . . . . 1 - 10
2.9.2 Non Functional Requirements . . . . . . . . . . 2 - 8
1.8.2 Extreme Programming . . . . . . . . . . . . . . . 1 - 11
2.9.2.1 Types of Non Functional Requirements
1.8.3 Adaptive Software Development . . . . . . . 1 - 12
.................................2-8
1.8.4 SCRUM. . . . . . . . . . . . . . . . . . . . . . . . . . . 1 - 12
2.9.2.2 Domain Requirements . . . . . . . . . . . 2 - 9
1.8.5 Dynamic System Development Method
2.9.3 Difference between Functional and Non
(DSDM) . . . . . . . . . . . . . . . . . . . . . . . . . . 1 - 14
Functional Requirements . . . . . . . . . . . . . 2 - 10
1.8.6 Crystal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 - 14
2.10 Eliciting Requirements . . . . . . . . . . . . . . . . . . 2 - 10
1.9 Selection Criteria for Software Process Model 1 - 15 2.10.1 Collaborative Requirements Gathering . . 2 - 10

Unit - II 2.10.2 Quality Function Deployment . . . . . . . . . 2 - 11

2.10.3 Usage Scenarios . . . . . . . . . . . . . . . . . . . 2 - 12
Chapter - 2 Software Requirement 2.10.4 Elicitation Work Product. . . . . . . . . . . . . 2 - 12
Engineering (2 - 1) to (2 - 18) 2.11 Developing Use Cases . . . . . . . . . . . . . . . . . . 2 - 12

Part I : Software Engineering Practices 2.12 Building Requirement Models . . . . . . . . . . . . 2 - 15

2.12.1 Overall Objectives. . . . . . . . . . . . . . . . . . 2 - 16
2.1 Software Engineering Practices and its Importance.

®
(vi)- An up thrust for knowledge
TECHNICAL PUBLICATIONS
TM
 (vii)

2.13 Definition of Software Requirement 4.1 Management Spectrum . . . . . . . . . . . . . . . . . . . 4 - 1

Specification (SRS). . . . . . . . . . . . . . . . . . . . . 2 - 16 4.1.1 The People . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1
2.14 Need for SRS . . . . . . . . . . . . . . . . . . . . . . . . . 2 - 16 4.1.2 The Product . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1
2.15 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 - 16 4.1.3 The Process . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1

2.16 Characteristics. . . . . . . . . . . . . . . . . . . . . . . . . 2 - 18 4.1.4 Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2

Part III : Software Requirement Specification 4.2 Metrics for Size Estimation . . . . . . . . . . . . . . . 4 - 2
4.2.1 LOC based Estimation . . . . . . . . . . . . . . . . . 4 - 2

Unit - III 4.2.2 Function Points. . . . . . . . . . . . . . . . . . . . . . . 4 - 3

4.3 Project Cost Estimation Approach . . . . . . . . . . 4 - 5
Chapter - 3 Software Modelling and Design 4.3.1 Overview of Heuristic Technique . . . . . . . 4 - 6
(3 - 1) to (3 - 24)
4.3.2 Analytical and Empirical Estimation . . . . . 4 - 6
3.1 Translating Requirement Model into 4.3.2.1 Halstead's Software Science . . . . . . . 4 - 6
Design Model . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1 4.4 COCOMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 8
3.1.1 Data Modeling. . . . . . . . . . . . . . . . . . . . . . 3 - 2
4.5 COCOMOII . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 11
3.1.1.1 Data Object, Attributes and Relationships
4.6 Risk Management . . . . . . . . . . . . . . . . . . . . . . 4 - 15
.................................3-2 4.6.1 Software Risks . . . . . . . . . . . . . . . . . . . . . . 4 - 15
3.1.2 Cardinality and Modality . . . . . . . . . . . . . 3 - 2
4.6.2 Risk Identification . . . . . . . . . . . . . . . . . . . 4 - 16
3.2 Analysis Modeling . . . . . . . . . . . . . . . . . . . . . . 3 - 3
4.6.3 Risk Projection . . . . . . . . . . . . . . . . . . . . . . 4 - 17
3.2.1 Elements of Analysis Model . . . . . . . . . . . 3 - 3
4.6.4 Risk Assessment. . . . . . . . . . . . . . . . . . . . . 4 - 17
3.3 Design Modeling. . . . . . . . . . . . . . . . . . . . . . . . 3 - 4
3.3.1 Fundamental Design Concepts . . . . . . . . . 3 - 4 4.6.5 Risk Containment. . . . . . . . . . . . . . . . . . . . 4 - 18

3.4 Design Notations. . . . . . . . . . . . . . . . . . . . . . . . 3 - 6 4.6.6 RMMM Strategy . . . . . . . . . . . . . . . . . . . . 4 - 18

3.4.1 Data Flow Diagram (DFD) . . . . . . . . . . . . 3 - 6
Unit - V
3.4.1.1 Data Flow Diagram . . . . . . . . . . . . . 3 - 6
3.4.2 Structured Flow Chart. . . . . . . . . . . . . . . 3 - 15 Chapter - 5 Software Quality Assurance and
3.4.3 Decision Tables. . . . . . . . . . . . . . . . . . . . 3 - 17 Security (5 - 1) to (5 - 14)
3.5 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 18 5.1 Project Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 1
3.5.1 Meaning and Purpose . . . . . . . . . . . . . . . 3 - 18 5.1.1 Basic Principle . . . . . . . . . . . . . . . . . . . . . . 5 - 1
3.5.2 Black Box and White Box Testing . . . . . 3 - 18 5.1.2 Work Breakdown Structure . . . . . . . . . . . . 5 - 1
3.5.3 Level of Testing . . . . . . . . . . . . . . . . . . . 3 - 19 5.1.3 Activity Network and Critical Path Method 5 - 2
3.5.3.1 Unit Testing . . . . . . . . . . . . . . . . . . 3 - 20 5.1.4 Scheduling Techniques . . . . . . . . . . . . . . . . 5 - 4
3.5.4 Test Documentation . . . . . . . . . . . . . . . . 3 - 21 5.2 Project Tracking. . . . . . . . . . . . . . . . . . . . . . . . . 5 - 5
3.5.4.1 Test Case Template . . . . . . . . . . . . 3 - 21 5.2.1 Time Line Chart (Gantt Chart) . . . . . . . . . . 5 - 5

3.5.4.2 Test Plan . . . . . . . . . . . . . . . . . . . . . 3 - 22 5.2.2 Earned Value Analysis . . . . . . . . . . . . . . . . 5 - 6

5.3 Software Quality Management Vs.
3.5.4.3 Introduction to Defect Report. . . . . 3 - 23 Software Quality Assurance . . . . . . . . . . . . . . . 5 - 7
3.5.4.4 Test Summary Report. . . . . . . . . . . 3 - 23 5.4 Phases of Software Quality Assurance . . . . . . . 5 - 8

Unit - IV 5.5 Software Quality Control. . . . . . . . . . . . . . . . . . 5 - 9

5.6 Quality Evaluation Standards . . . . . . . . . . . . . . 5 - 9
Chapter - 4 Software Project Estimation 5.6.1 Six Sigma . . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 9
(4 - 1) to (4 - 20)
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

 (viii)

5.6.2 ISO for Software . . . . . . . . . . . . . . . . . . . . 5 - 10

5.6.3 CMMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 11
5.7 Software Security. . . . . . . . . . . . . . . . . . . . . . . 5 - 12
5.8 Introduction to DEVOPs . . . . . . . . . . . . . . . . . 5 - 12
5.9 Secure Software Engineering. . . . . . . . . . . . . . 5 - 13
Solved Sample Test Papers (S - 1) to (S - 2)

Solved Sample Question Paper

(S - 3) to (S - 4)

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

 UNIT- I

1.1
1 Software Development Process

Definition of Software and Software 1.2 Software as Layered Approach

Engineering MSBTE : Winter-15, 16, Summer-15, 16, 17, Marks 6
MSBTE : Winter-15, Marks 4
· Software engineering is a layered technology. Any
Software : Software is nothing but a collection of software can be developed using these layered
computer programs and related documents that are approaches. Various layers on which the technology
intended to provide desired features, functionalities is based are quality focus layer, process layer,
and better performance. methods layer, tools layer.
Software Engineering : “Software engineering is a · A disciplined quality management is a backbone of
discipline in which theories, methods and tools are software engineering technology.
applied to develop professional software product.” · Process layer is a foundation of software
engineering. Basically, process defines the
Attributes of Good Software : There are some
framework for timely delivery of software.
essential attributes of good software and those are
· In method layer the actual method of
(1) Maintainability : Sometimes there is a need to implementation is carried out with the help of
make some modifications in the existing requirement analysis, designing, coding using
software. A good software is a software which desired programming constructs and testing.
can be easily modified in order to meet the · Software tools are used to bring automation in
changing needs of the customer. software development process.
· Thus software engineering is a combination of
(2) Usability : It is the ability of the software being
useful. For making the software useful it is process, methods, and tools for development of
necessary that it should have proper GUI and quality software.
documentation.
(3) Dependability : The dependability is a property Tools
that includes reliability, security and safety of
Methods
software. In other words the developed software
product should be reliable and safe to use; it Processes
should not cause any damage or destruction. Quality management
(4) Efficiency : The software should be efficient in
its performance and it should not waste the Fig. 1.2.1
memory.
Board Questions
1. Explain software engineering as a layered
Board Question
technology approach.
1. State any four attributes of a good software.
MSBTE : Winter-15, Summer-15,17, Marks 4,
MSBTE : Winter-15, Marks 4 Summer-16, Marks 6

2. Explain software engineering as a layered

technology approach with neat diagram.
MSBTE : Winter-16, Marks 4
®
(1 - -1)An up thrust for knowledge
TECHNICAL PUBLICATIONS
TM
Software Engineering 1-2 Software Development Process

1.3 Characteristics of Software Engineering 6) Thus the failure curve looks like a spike. Thus
MSBTE : Winter-15, 17, Summer-16, 18, Marks 8 frequent changes in software cause it to
· Software is engineered, not manufactured deteriorate.
1) Software development and hardware 7) Another issue with software is that there are no
development are two different activities. spare parts for software. If hardware component
wears out it can be replaced by another
2) A good design is a backbone for both the
component but it is not possible in case of
activities. software.
3) Quality problems that occur in hardware 8) Therefore software maintenance is more difficult
manufacturing phase cannot be removed easily. than the hardware maintenance.
On the other hand, during software development · Most software is custom built rather than being
process such problems can be rectified. assembled from components
4) In both the activities, developers are responsible 1) While developing any hardware product firstly
for producing qualitative product. the circuit design with desired functioning
· Software does not ware out properties is created. Then required hardware
components such as ICs, capacitors and registers
1) In early stage of hardware development process
are assembled according to the design, but this is
the failure rate is very high because of
not done while developing software product.
manufacturing defects. But after correcting such
defects the failure rate gets reduced. 2) Most of the software is custom built.
3) However, now the software development
2) The failure rate remains constant for some period
approach is getting changed and we look for
of time and again it starts increasing because of
reusability of software components.
environmental maladies (extreme temperature,
dusts, and vibrations). 4) It is practiced to reuse algorithms and data
structures.
3) On the other hand software does not get affected
5) Today software industry is trying to make library
from such environmental maladies. Hence ideally
of reusable components. For example : In today’s
it should have an “idealized curve”. But due to
software, GUI is built using the reusable
some undiscovered errors the failure rate is high components such as message windows, pull
and drops down as soon as the errors get down menus and many more such components.
corrected. Hence in failure rating of software the
6) The approach is getting developed to use in-built
“actual curve” is as shown below :
components in the software. This stream of
Failure curves software is popularly known as component
(Bath tub curves)
engineering.

Hardware curve Software curve

Board Questions
Side effect
Manufacturing of changes 1. Describe the characteristics of software.
defects
Failure

Failure

Actual MSBTE : Winter-15, Marks 4

Wear curve
out
Constant failure period Change
Idealized 2. Define software. State three characteristics of
Time curve
Time software. MSBTE : Summer-16, Marks 4
Fig. 1.3.1
3. Explain changing nature of software.
4) During the life of software if any change is MSBTE : Winter-17, Marks 4
made, some defects may get introduced. This 4. What is software ? What are its characteristics ?
causes failure rate to be high. MSBTE : Winter-17, Marks 8
5) Before the curve can return to original steady 5. Elaborate the software characteristic “Software
state another change is requested and again the does not wear out”. MSBTE : Summer-18, Marks 4
failure rate becomes high.
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 1-3 Software Development Process

1.4 Types of Software Board Questions

MSBTE : Winter-16, Summer-16, 17, 18, Marks 6 1. State and explain any four types of software.
Based on changing nature of software, various types MSBTE : Summer-16, Marks 4
of software are defined as follows -
2. Describe any four categories of software.
1. System software - MSBTE : Winter-16, Marks 4
¡ It is collection of programs written to service 3. What is software ? What is embedded software ?
other programs.
MSBTE : Summer-17, Marks 4
¡ Typical programs in this category are compiler,
editors and assemblers. 4. Elaborate any six types of software considering the
¡ The purpose of the system software is to changing nature. MSBTE : Summer-18, Marks 6

establish a communication with the hardware.

2. Application software - 1.5 Software Development Framework
¡ It consists of standalone programs that are · The Software Development Life Cycle (SDLC) is the
developed for specific business need. logical process of developing any system.
¡ This software may be supported by database · Using SDLC one can develop a system which
systems. satisfies customer needs, can be developed within
3. Engineering / Scientific software - the predefined schedule and cost.
¡ This software category has a wide range of · Normally the system analyst makes use of software
programs from astronomy to volcanology, from development life cycle for developing the
automatic stress analysis to space shuttle orbital information systems.
dynamics and from molecular biology to · The SDLC is a linear or sequential model in which
automated manufacturing. output of previous phase is given as input to next
¡ This software is based on complex numeric subsequent stage.
computations. · Various phases of software development life cycle
are - (Refer Fig. 1.5.1)
4. Embedded software -
1. Feasibility study : It is initial phase of software
¡ This category consists of program that can
development framework. In this phase, it is
reside within a product or system.
decided whether to built the system or not.
¡ Such software can be used to implement and
2. Requirement gathering and analysis : The basic
control features and functions for the end-user
requirements of the software project are
and for the system itself.
identified and analysed in this phase.
5. Web applications -
¡ Web application software consists of various Feasible solution
Feasibility Study
web pages that can be retrieved by a browser. System requirements

¡ The web pages can be developed using

programming languages like JAVA, PERL, CGI,
HTML, DHTML. Design
Testing and Reviews and modifications
maintenance
6. Artificial Intelligence software -
¡ This kind of software is based on knowledge
System
based expert systems. Working design
modules document
implementation
¡ Typically, this software is useful in robotics,
expert systems, image and voice recognition,
artificial neural networks, theorem proving and Fig. 1.5.1 Phases in SDLC
game playing.
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 1-4 Software Development Process

3. Design : The model of the software system is · Construction - The software design is mapped into
prepared in this phase. a code by :
4. Coding or implementation : Using the software n Code generation
design the coding is done in this phase. Thus the Testing
n
implementation model is prepared. · Deployment - The software delivered for customer
5. Testing and maintenance : The code is tested and evaluation and feedback is obtained.
modified if required. Task sets - The task set defines the actual work done
in order to achieve the software objective. The task
1.6 Software Process Framework set is used to adopt the framework activities and
MSBTE : Winter-15, 16, Summer-15, 17, Marks 4 project team requirements using :
· The process framework is required for representing n Collection of software engineering work tasks
the common process activities.
n Project milestones
· As shown in Fig. 1.6.1, the software process is
n Software quality assurance points
characterized by process framework activities, task
Umbrella activities - The umbrella activities occur
sets and umbrella activities.
throughout the process. They focus on project
management, tracking and control. The umbrella
Software Process
activities are
Process Framework 1. Software project tracking and control - This is
an activity in which software team can assess
Umbrella Activities
progress and take corrective action to maintain
Acttivity 1 schedule.
Tasksets Work Task
2. Risk management - The risks that may affect
Milestone
SQA Points project outcomes or quality can be analyzed.
3. Software quality assurance - These are activities
Acttivity n required to maintain software quality.
Tasksets Work Task
4. Formal technical reviews - It is required to
Milestone
SQA Points assess engineering work products to uncover
and remove errors before they propagate to next
activity.
5. Software configuration management - Managing
of configuration process when any change in the
Fig. 1.6.1 Software process framework
software occurs.
Process framework activities 6. Work product preparation and production - The
· Communication activities to create models, documents, logs,
forms and lists are carried out.
By
n communicating customer requirement
gathering is done. 7. Reusability management - It defines criteria for
· Planning - Establishes engineering work plan, work product reuse.
describes technical risks, lists resource requirements, 8. Measurement - In this activity, the process can
work products produced and defines work be defined and collected. Also project and
schedule. product measures are used to assist the software
· Modeling - The software model is prepared by : team in delivering the required software.
n Analysis of requirements
n Design
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 1-5 Software Development Process

Board Questions · The software development starts with requirements

1. What do you mean by process framework ? gathering phase. Then progresses through analysis,
Explain with suitable diagram. design, coding, testing and maintenance.
MSBTE : Summer-15,17, Winter-16, Marks 4 · Fig. 1.7.2 illustrates waterfall model.
2. Explain the basic process framework activities. · In requirement gathering and analysis phase the
MSBTE : Winter-15, Marks 4 basic requirements of the system must be
understood by software engineer.
1.7 Process Model · The design is an intermediate step between
MSBTE : Winter-15, 16, 17, Summer-14, 15, 17, 18, Marks 8
requirements analysis and coding. Design focuses
· Definition of process model : The process model on program attributes such as –i) Data structure
can be defined as the abstract representation of
ii) Software architecture iii) Interface representation
process. The appropriate process model can be
chosen based on abstract representation of process. iv) Algorithmic details.
· Coding is a step in which design is translated into
· The software process model is also known as
machine-readable form. Programs are created in this
Software Development Life Cycle (SDLC) model or
phase.
software paradigm.
· Testing begins when coding is done. The purpose
· Various types of process models are -
of testing is to uncover errors, fix the bugs and
Process model meet the customer requirements.
· Maintenance is the longest life cycle phase. When

Perspective Specialized the system is installed and put in practical use then
process model process model error may get introduced, correcting such errors and
putting it in use is the major purpose of
Waterfall model Component based model
maintenance activity. Similarly, enhancing system’s
RAD model Formal methods model
services as new requirements are discovered is
Spiral model
again maintenance of the system.
Fig. 1.7.1 Types of process models
Advantages of waterfall model
1.7.1 Perspective Process Model
1. The waterfall model is simple to implement.
1.7.1.1 Waterfall Model 2. For implementation of small systems waterfall
· The waterfall model is also called as model is useful.
‘linear-sequential model’ or ‘classic life cycle model’.

Requirement
gathering and analysis

Design

Coding

Testing

Maintenance

Fig. 1.7.2 Waterfall model

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 1-6 Software Development Process

Disadvantages of waterfall model · Multiple teams work on developing the software

1. It is difficult to follow the sequential flow in system using RAD model parallely.
software development process. If some changes ¡ In the requirements gathering phase the
are made at some phases then it may cause some developers communicate with the users of the
confusion. system and understand the business process
and requirements of the software system.
2. The requirement analysis is done initially and
¡ During analysis and planning phase, the
sometimes it is not possible to state all the
requirements explicitly in the beginning. This analysis on the gathered requirements is made
and a planning for various software
causes difficulty in the project.
development activities is done.
3. The customer can see the working model of the ¡ During the design phase various models are
project only at the end. After reviewing of the created. Those models are business model, data
working model; if the customer gets dissatisfied model and process model.
then it causes serious problems.
¡ The build is an activity in which working code
1.7.1.2 RAD Model (Incremental Model) is generated. This code is well tested by its
team. The functionalities developed by all the
· The RAD Model is a type of incremental process
teams are integrated to form a whole.
model in which there is extremely short
¡ Finally the deployment of all the software
development cycle.
components (created by various teams working
· When the requirements are fully understood and on the project) is carried out. (Refer Fig. 1.7.3)
the component based construction approach is
adopted then the RAD model is used. Advantages of RAD Model
· Using the RAD model the fully functional system (1) Faster development cycle.
can be developed within 60 to 90 days.
(2) Visualization of related routines periodically.
· Various phases in RAD are Requirements Gathering,
Analysis and Planning, Design, Build or (3) Encourages user involvement.
Construction and finally Deployment. (4) Low maintenance cost.

Team#n

Design

Team#2
Build
Requirements Design
gathering
D
Build e
Team#1 p
l
Analysis o
Design
and planning y

Build

60 to 90 days period

Fig. 1.7.3 RAD model

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 1-7 Software Development Process

Disadvantages of RAD Model 1.7.1.3 Spiral Model

(1) It has reduced scalability. · This model possess the iterative nature of
(2) Not appropriate when technical risks are high. prototyping model and controlled and systematic
(3) This model requires heavily committed developer approaches of the linear sequential model.
and customers. If commitment is lacking then · This model gives efficient development of
RAD projects will fail. incremental versions of software. In this model, the
software is developed in series of increments.
Difference between Waterfall Model and
Incremental Model · The sprial model is divided into a number of
framework activities. These framework activities are
Sr. denoted by task regions.
Waterfall model Incremental model
No.
· Usually there are six tasks regions. The spiral
1 This model is used This model is used when model is as shown in Fig. 1.7.4.
when requirements there is possibility of
are clearly defined. change in requirements. · Spiral model is realistic approach to development of

2
large-scale systems and software. Because customer
There is no customer After each increment, the
interaction until the customer can take a and developer better understand the problem
last phase of the review of the product statement at each evolutionary level. Also risks can
waterfall model. generated so far.
be identified or rectified at each such level.
3 Depending upon the Less human resource is · In the initial pass, product specification is built and
requirements of the required.
project, the human in subsequent passes around the spiral the
resource is required. prototype gets developed and then more improved
4 Risk of failure of Risk of failure of project versions of software gets developed.
project is high. is low.

Planning Risk analysis

Customer
communication

Engineering
Concept
development
Project entry projects
point axis
New
product
development
projects
Product
enhancement
projects

Product
maintenance
projects
Customer evaluation Construction
and feedback and release

Fig. 1.7.4 Spiral model

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 1-8 Software Development Process

· During planning phase, the cost and schedule of 2. Requirement changes can be made at every stage
software can be planned and adjusted based on of new version.
feedback obtained from customer evaluation.
3. Risks can be identified and reduced before they
· In spiral model, project entry point axis is defined.
get problematic.
This axis represents starting point for different
types of projects. 4. The working model is available to the customer
at certain stage of iteration.
· For instance, concept development project will start
at core of spiral and will continue along the spiral
path. If the concept has to be developed into actual Disadvantages of spiral model
project then at entry point 2 the product 1. This model is based on customer communication.
development process starts. Hence entry point 2 is If the communication is not proper then the
called product development project entry point. The product being developed is not up to the mark.
development of the project can be carried out in
2. It demands considerable risk assessment. If the
iterations.
risk assessment is done properly then only
· The task regions can be described as :
successful product can be obtained.
i) Customer communication - In this region, it is
suggested to establish customer communication. Sr. No. Waterfall model Spiral model

ii) Planning - All planning activities are carried out 1 It requires well It is developed in
in order to define resources time line and other understanding of iterations. Hence the
project related activities. requirements and requirements can be
familiar technology. identified at new
iii) Risk analysis - The tasks required to calculate iterations.
technical and management risks are carried out. 2 Difficult to The required changes
iv) Engineering - In this task region, tasks required accommodate changes can be made at every
after the process has stage of new version.
to build one or more representations of started.
applications are carried out.
3 Can accommodate It is iterative model.
v) Construct and release - All the necessary tasks iteration but indirectly.
required to construct, test, install the application 4 Risks can be identified Risks can be
are conducted. Some tasks that are required to at the end which may identified and
provide user support are also carried out in this cause failure to the reduced before they
product. get problematic.
task region.
5 The customer can see The customer can see
vi) Customer evaluation - Customer’s feedback is
the working model of the working product
obtained and based on customer evaluation the project only at the at certain stages of
required tasks are performed and implemented at end. After reviewing of iterations.
the working model; if
installation stage.
the customer gets
· In each region, number of work tasks are carried dissatisfied then it
out depending upon the characteristics of project. causes serious
problems.
For a small project relatively small number of work
tasks are adopted but for a complex project large 6 Customers prefer this Developers prefer this
number of work tasks can be carried out. model. model.

· In spiral model, the software engineering team 7 This model is good for This model is good
small systems. for large systems.
moves around the spiral in a clockwise direction
beginning at the core. 8 It has sequential nature. It has evolutionary
nature.
Advantages of spiral model
1. This model has iterative nature. Hence
requirements can be identified at new iteration.
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 1-9 Software Development Process

1.7.2 Specialized Process Model

1.7.2.1 Component Based Development

· The commercial off-the-shelves components that are developed by the vendors are used during the
software built.
· These components have specialized targeted functionalities and well defined interfaces. Hence it is
easy to integrate these components into the existing software.
· The component based development model makes use of various characteristics of spiral model. This
model is evolutionary in nature. That means the necessary changes can be made in the software
during the each iteration of software development cycle.
· Before beginning the modeling and construction activity of software development the candidate
component must be searched and analyzed. The components can be simple functions or can be object
oriented classes or methods.
· Following steps are applied for component based development -
· Identify the component based products and analyze them for fitting in the existing application
domain.
· Analyze the component integration issues.
· Design the software architecture to accommodate the components
· Integrate the components into the software architecture.
· Conduct comprehensive testing for the developed software.
· Software reusability is the major advantage of component based development.
· The reusability reduces the development cycle time and overall cost.

1.7.2.2 Formal Methods Model

· This model consists of the set of activities in which the formal mathematical specification is used.
· The software engineers specify, develop and test the computer based systems using the mathematical
notations. The notations are specified within the formal methods.
· Cleanroom software engineering makes use of the formal method approach.
· The advantage of using formal methods model is that it overcomes many problems that we encounter
in traditional software process models. Ambiguity, incompleteness and inconsistency are those
problems that can be overcome if we use formal methods model.

System High
User Architectural Formal
requirement level
requirements definition design specification
specification design

Fig. 1.7.5 Formal methods model

· The formal methods model offers defect-free software. However there are some drawbacks of this
model which resists it from getting used widely. These drawbacks are
· The formal methods model is time consuming and expensive.
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 1 - 10 Software Development Process

· For using this model, the developers need the late in the software development process, the
strong mathematical background or some extensive agile process should help to accommodate them.
training. 3. Deliver working software quite often. Within the
· If this model is chosen for development then the shorter time span deliver the working unit.
communication with customer becomes very 4. Business people and developers must work
difficult. together throughput the project.

Board Questions 5. Motivate the people who are building the

1. Differentiate between waterfall model and projects. Provide the environment and support to
the development team and trust them for the job
incremental model.
to be done.
MSBTE : Summer-14, 18, Winter-16, Marks 4
6. The working software is the primary measure of
2. Write four drawback of RAD model.
the progress of the software development.
MSBTE : Summer-15, Marks 4
7. The agile software development approach
3. In which situation RAD model is applicable ?
promote the constant project development. The
Give its advantages and disadvantages.
constant speed for the development of the
MSBTE : Winter-15, Marks 4
product must be maintained.
4. Explain spiral model with neat diagram.
8. To enhance the agility there should be
MSBTE : Summer-15, Marks 4
continuous technical excellence.
5. With neat diagram, explain RAD model with its
9. Proper attention to be given to technical
advantages and disadvantages. (2 each)
excellence and good design.
MSBTE : Winter-16, Marks 6, Summer-17, Marks 8
10. Simplicity must be maintained while developing
6. Explain the waterfall model. the project using this approach.
MSBTE : Winter-17, Marks 4
11. The teams must be the self-organizing team for
7. Draw the neat labeled diagram of spiral model and getting best architecture, requirements and
list two disadvantages of spiral model. design.
MSBTE : Summer-18, Marks 4
12. At regular intervals the team thinks over the
issue of becoming effective. After the careful
1.8 Agile Software Development
MSBTE : Winter-15, 16, 17, Summer-15, 16, 17, Marks 4 review the team members adjusts their behavior
accordingly.
· The agile processes are the light-weight methods
are people-based rather than plan-based methods. 1.8.1 Agile Process and its Importance
· The agile process forces the development team to
Agile process is based on following assumptions
focus on software itself rather than design and
about software projects
documentation.
· The agile process make use of iterative method. 1. It is difficult to predict the software requirements
· The aim of agile process is to deliver the working in advance. Similarly the customer priority often
model of software quickly to the customer. get changed.
2. It is difficult to predict how much design is
Agile Principles
necessary before the implementation.
· There are famous 12 principles used as agility
principles - 3. All the software development activities such as
1. Satisfy the customer by early and continuous analysis, design, construction and testing are just
delivery of valuable software. difficult to predict.

2. The changes in the requirements must be

accommodated. Even though the changes occur
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 1 - 11 Software Development Process

Characteristics of agile process are - 2) The project can easily get off the track if customer
1. Agile processes must be adaptable to technical is not clear about his requirements.
and environmental changes. That means if any
technological changes occur, then the agile Difference between Prescriptive Process Model
and Agile Process Model
process must accommodate it.
2. The development of agile processes must be Prescriptive process
Sr. No. Agile process model
incremental. That means, in each development model
the increment should contain some functionality 1 It is a traditional It is a modern
that can be tested and verified by customer. approach of software approach of software
development. development.
3. The customer feedback must be used to create
the next increment of the process. 2 It is product oriented It is people oriented
process model process model.
4. The software increment must be delivered in
3 Sometimes it is It is easy to adapt the
short span of time.
difficult to adapt changes during
5. It must be iterative, so that each increment can changes during the software
software development.
be evaluated regularly.
development.

Features of agile process 4 Some models allow Customer

less involvement of involvement is
customers. important feature of
The features of agile process models agile process model.
The key features of an agile process model can be 5 Lengthy cycles of Quick delivery of the
summarised as follows : software development product.
may cause delayed
· The software itself is the important measure of the delivery of the
team’s progress, rather than documentation. product.

· The development team has autonomy to 6 Emphasis is on Less emphasis of

documentation. documentation
determine how to structure and handle the
during software
development work. development.
· Changes can be easily adapted. 7 Examples – Waterfall Examples – Extreme
model, spiral model. programming, Scrum.
· Customers can more easily examine the software
and provide feedback.
Process Models
Merits : There are various agile process models -
1) Customer satisfaction can be attained by rapid 1. Extreme Programming
and continuous delivery of useful software.
2. Adaptive Software Development
2) Customer, developer and tester interact with each
3. Dynamic System Development Method(DSDM)
other during software development process.
4. Scrum
3) Continuous attention can be given for excellent
technical design and software quality. 5. Crystal
4) Even late changes in requirements can be 1.8.2 Extreme Programming
accommodated.
Extreme Programming (XP) is one of the best known
Demerits : agile methods. The extreme programming approach
was suggested by Kent Beck in 2000. The extreme
1) There is lack of emphasis on necessary designing
programming process is explained as follows -
and documentation during software development
process.
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 1 - 12 Software Development Process

· Customer specifies and priorities the system · The life cycle of ASD consists of three phases of
requirements. Customer becomes one of the software development and those are -
important members of development team. The 1. Speculation 2. Collaboration 3. Learning.
developer and customer together prepare a
1. Speculation : This is an initial phase of the
story-card in which customer needs are mentioned.
adaptive software development process. In this
· The developer team then aims to implement the
phase the adaptive cycle planning is conducted.
scenarios in the story-card.
In this cycle planning mainly three types of
· After developing the story-card the development information is used such as - Customer's mission
team breaks down the total work in small tasks. statement, project constraints (delivery date, user
The efforts and the estimated resources required for description, budgets and so on) and basic
these tasks are estimated. requirements of the project.
· The customer priorities the stories for 2. Collaboration : The motivated people work in
implementation. If the requirement changes then collaboration to develop the desired software
sometimes unimplemented stories have to be product. In this phase collaboration among the
discarded. Then release the complete software in members of development team is a key factor.
small and frequent releases. For successful collaboration and coordination it is
· For accommodating new changes, new story-card necessary to have following qualities in every
must be developed. individual -
· Evaluate the system along with the customer. ¡ Assist each other without resentment
This process is demonstrated by the following ¡ Work hard.
Fig. 1.8.1. ¡ Posses the required skill set.
Create small ¡ Communicate problems and
Prepare Plan for
tasks from
story card release
story card help each other to accomplish
the given task.
¡ Criticize without any hate.
Perform software 3. Learning : As the team members go on
Evaluate
Release software integration
system performance developing the components, the emphasize is on
and testing
learning new skills and techniques. There are
Fig. 1.8.1 Extreme programming release cycle
three ways by which the team members learn -
1.8.3 Adaptive Software Development ¡ Focus groups : The feedback from the end-users
· The adaptive software development approach was
is obtained about the software component being
developed. Thus direct feedback about the
proposed by Jim Highsmith. This approach is useful
developed component can be obtained.
in building the complex software systems using
¡ Formal technical review : This review for
iterative apporach
software components is conducted for better
· The focus of this method is on working in
quality.
collaboration and team self organization.
¡ Postmortems : The team analyses its own
Speculation performance and makes appropriate
improvements.
Release
or Collaboration
software
1.8.4 SCRUM
increment
· SCRUM is an agile process model which is used
Learning for developing the complex software systems.

Fig. 1.8.2 Adaptive software development life cycle

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 1 - 13 Software Development Process

· It is a lightweight process framework that can be Development Activities

used to manage and control the software In SCRUM emphasize is on software process pattern.
development using iterative and incremental The software process pattern defines a set of
approach. Here the term lightweight means the development activities. Refer Fig. 1.8.3.
overhead of the process is kept as small as possible
Various development activities in SCRUM are -
in order to maximize productive time.
· This model is developed by Jeff Sutherland and Ken
1. Backlog : It is basically a list of project
requirements or features that must be provided
Schwaber in 1995.
to the customer. The items can be included in the
Principles backlog list at any time. The product manager
· Various principles using which the SCRUM works analyses this list and updates the priorities as per
are as given below - the requirements.
1. There are small working teams on the software 2. Sprint : These are the work units that are
development projects. Due to this there is needed to achieve the requirements mentioned in
maximum communication and minimum the backlogs. Typically the sprints have fixed
overhead. duration or time-box (typically of 2 to 4 weeks).
Thus sprints allow the team members to work in
2. The tasks of people must be partitioned into
stable and short-term environment.
small and clean packets or partitions.
3. Meetings : These are 15 minutes daily meetings
3. The process must accommodate the technical or
to report the completed activities, obstacles and
business changes if they occur.
plan for next activities. Following are three
4. The process should produce software questions that are mainly discussed during the
increments. These increments must be inspected, meetings
tested, documented and built on. i) What are the tasks done since last meeting ?

5. During the product building the constant testing ii) What are the issues (obstacles) that team is
facing ?
and documentation must be conducted.
iii) What are the next activities that are planned ?
6. The SCRUM process must produce the working
4. Demo : During this phase, the software
model of the product whenever demanded or increment is delivered to the customer. The
required. implemented functionality which is demonstrated
· Various development activities (requirements to the customer. Note that demo focuses on only
analysis, design, evolution and delivery) are guided implemented functionalities and not all the
by SCRUM principles. planned functionalities (and yet to get
implemented) of the software product.

15 min daily
meeting
1. What are
activities ?
2. Obstacles ?
24 Hour 3. Next meeting
plan ?

30 Days

Software
Sprint backlog
increment
Product backlog with
specific
functionality

Fig. 1.8.3 SCRUM workflow activities

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 1 - 14 Software Development Process

Roles : 3. Functional model iteration : The incremental

1. Scrum Master - The Scrum master leads the approach is adopted for development. The basic
meeting and analyses the response of each team functionalities are demonstrated to the customer
member. The potential problems are discussed by building the suitable increments. The intention
and solved in the meeting with the help of of iterative cycle is to gather additional
master. requirements by eliciting the requirements from
the customer as each prototype is being
2. Team Members - These are the persons working
developed.
in a team to develop the software solutions.
4. Design and build iteration : Each prototype is
Advantages and Disadvantages : revisited during the functional model iteration to
ensure that the business requirements are
Advantages : satisfied by each software component. Sometimes
1. SCRUM model brings transparency in project if possible, the design and build activities can be
development status. carried out in parallel.
2. It provides flexibility towards the changes. 5. Implementation : In this phase, the software
increment is placed in the working environment.
3. There is improved communication, minimum
If changes are suggested or if the end-user feels
overhead in development process.
it incomplete then the increment is placed in
4. The productivity can be improved. iteration for further improvement.

Disadvantages : The DSDM can be combined with XP method or ASD

concepts to create a combination model.
1. Some decisions are hard to track in fixed time
span. 1.8.6 Crystal
2. There are problems to deal with non-functional · Cockburn and Highsmith suggested the crystal
requirements of the system. family of agile methods.

1.8.5 Dynamic System Development Method · The primary goal of this method is to deliver useful
(DSDM) and working software.
In this agile method, the project deadline is met using · In this model, a set of methodologies are defined
the incremental prototyping approach. This is an which contains the core elements that are common
iterative development process. to all. These methodologies also contain roles,
The Dynamic System Development Method (DSDM) process patterns, work products and practice that
consortium has defined an agile process model called are unique to each.
DSDM life cycle. · Thus the crystal family is actually a set of agile
Various phases in this life cycle model are as processes that are useful for different types of
follows - projects. The agile team has to select the memebers
of the crustal family that is most approapriate for
1. Feasibility study : By analyzing the business
requirements and constraints the viability of thee their ongoing project and environment.
application is determined in this phase.
Board Questions
2. Business study : The functional and 1. Describe Agile process models in detail.
informational requirements are identified and
MSBTE : Summer-15, Marks 4
then the business value of the application is
determined. The basic application architecture is 2. Explain the features of Agile software development
decided in this phase. approach. MSBTE : Winter-15, 16, Marks 4

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 1 - 15 Software Development Process

3. Differentiate between Prescriptive Process Model Board Question

and Agile Process Model (any four points). 1. What is Waterfall Model ? State the practical
MSBTE : Summer-16, Winter-17, Marks 4 situations in which it can be used.
MSBTE : Summer-16, Marks 4
4. Explain the term scrum. MSBTE : Summer-17, Marks 4

5. What is agile process ? MSBTE : Summer-17, Marks 4

qqq

1.9 Selection Criteria for Software Process

Model MSBTE : Summer-16, Marks 4

Following table shows the situations in which

particular process model can be used

Type of the project Suggested model

l If a small project is to be Waterfall model

implemented.

l If the requirements of the project

are well understood.

l Existing manual system has to be

automated.

l If there is no need for customer

involvement in the project
development cycle.

l When project requirements are not RAD model

clear.

l The system will be operated by

novice users.

l The GUI of the project is very

important.

l Delivery of the project is expected

within a short period of time.

l The risk of long project is not Spiral model

affordable.

l Requirements are not known and

will be known only with time.

l Project is of large size.

l When the requirements are not Agile model

properly known.

l For the systems in which customer

involvement is must.

l The GUI of project is important.

l Quick delivery of the product is

expected.

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 1 - 16 Software Development Process

Notes

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

 UNIT - II

2 Software Requirement
Engineering
Principle 1. Reason it all Exists : The software
Part I : Software Engineering Practices
system that you are going to develop must give
value to its users. If your development is not going
2.1 Software Engineering Practices and its to add any value to its users then don't develop such
Importance system.
Definition : Software engineering practices includes -
concepts, principles, methods and tools that must be Principle 2. Keep it Simple, Stupid (KISS) : The
considered for planning and development of software software design must be simple, easy for
system. understanding and easy to maintain.

Principle 3. Maintain the Vision : There should be

Importance :
clear vision for the software system to be built. The
1) By following software engineering practices,
clear vision about the system helps to develop it
every concerned entity gets involved in software
development process. without any ambiguity.

2) The software engineering practices - provide Principle 4. What you will Produce, others will
detailed insight for software development Consume : The software system that you develop
process. will be used by users, software designers,

3) It acknowledges the software engineer about the programmers, testers and so on. So whenever you
principles that must be used during the software develop the system, develop in such a way that your
development. job will be easier for them to handle.

Principle 5. Be Open to the Future : Develop a

Essence of Software Engineering Practice :
· The problem solving activity is normally based on system in such a way that it will have longer life
following four steps - time. Develop the system in such a manner that it
1. Understanding of the problem (Communication will adapt any changes comfortably. Never design
and requirement analysis). the system for specific problems only, rather create it
2. Planning for possible solution (Modelling and for general purposes.
design). Principle 6. Plan ahead for Reuse : Reusability has
3. Execute the plan (Code generation). got vital importance in software industry. The
4. Check the accuracy of the solution (Testing and reusability can be achieved using the approaches like
quality assurance). object oriented programming. The software must be
developed and documented in such a way that
2.2 Core Principles reusability can be easier one.
MSBTE : Winter-15, 16, 17, Summer-15, 17, Marks 8

· David Hooker proposed seven core principles for Principle 7. Think : Think about the system that you
software engineering practice. These are as follows - are going to develop and acquire the required

®
(2 - -1)An up thrust for knowledge
TECHNICAL PUBLICATIONS
TM
Software Engineering 2-2 Software Requirement Engineering

knowledge. Thoughtfully, apply above six principles deciding the goals of the software system being
during the software development process. developed.

Principle 7 - Stay focused : During the

Board Questions
1. State and describe various core principles of communication and discussion, it is possible to
software engineering. switch frequently from one topic to another. The
MSBTE : Winter-15, 16, Marks 8 leader or facilitator of the communication must keep

2. List core principle of Software Engineering. the communication focused and must make every
MSBTE : Summer-15, 17, Winter-17, Marks 4 topic modular. The modular discussion means leave
one topic only after resolving the issues within in it
2.3 Communication Practices and then only switch to another topic.
MSBTE : Winter-15,16,17, Marks 4
Principle 8 - Make pictorial representation : If
· Communication is carried out in order to something is unclear, then make a drawing or sketch
understand the customer requirements. Following
of it for understanding.
are the principles that are used to make the
communication effective - Principle 9 - Move on : During the communication
just move on by resolving the issues and by
Principle 1 - Listen : It is important to listen the
understanding the things.
customer carefully. Ask for the clarifications
appropriately. Never interrupt him/her annoyingly Principle 10 - Negotiate : There are times when the
during the narration. developers and customer need to negotiate on some
of the issues such as some functionalities, delivery
Principle 2 - Prepare for communication : Do some
date, features priorities and so on.
research to understand the business domain. If you
are conducting the meeting, then prepare the agenda Board Questions
before the meeting. 1. Briefly describe the principles of communication.
Principle 3 - Have facilitator for communication : MSBTE : Winter-15, Marks 4

The facilitator or a leader is required for the 2. State and describe six principles of communication
communication for three reasons. Firstly to move the practices. MSBTE : Winter-16, Marks 4

conversation in productive direction, secondly to 3. What are communication principles ? Explain

resolve any conflicts and thirdly to ensure that the their meaning. MSBTE : Winter-17, Marks 4

designated principles and standards are being

followed. 2.4 Planning Practices
MSBTE : Summer-15, 17, 18, Marks 8
Principle 4 - Have face-to-face communication : The
· Planning is an activity that includes the set of
face to face communication is important to have
management and technical practices that software
effective communication.
has to follow in definite direction. Various
Principle 5 - Take notes and document the principles of planning are -
decisions : It is important to note down the
important points and decisions made during the Principle 1 - Understand the scope of the project :
communication. The scope of the project help the software team what

Principle 6 - Strive for collaborations : The collective

is the goal of development.

knowledge of the members of the team is combined

to understand the system. This makes a small
collaboration which help the team members in
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 2-3 Software Requirement Engineering

Principle 2 - Make the planning by involving the Board Questions

customer : Customers specify what they exactly
1. Describe eight principles of good planning.
want from the software system. The developer can
MSBTE : Summer-15, 17, Marks 8
negotiate order of delivery, some unrealistic
2. Explain principles of planning practices in
functionalities, cost and so on. Hence customers
software engineering (any four)
involvement in the project is must.
MSBTE : Summer-18, Marks 4
Principle 3 - Planning activity should be iterative :
Iterations help the developer to accommodate the 2.5 Modeling Practices MSBTE : Winter-17, Marks 4
changes in the system plan. · Models are created for understanding the system.
Principle 4 - Make estimation based on the During software development, there are two kinds
knowledge : Estimation of the project represents the of models that are developed - analysis model and
efforts, cost and duration based on current design model.
understanding of the work. But it is always vague. (1) Analysis Modeling Principles

Principle 5 - Consider risk while defining the plan : Following are analysis modeling principles -
The project plan must be flexible enough to 1. The information domain of the problem must
accommodate one or more risks. be represented and understood : The
information domain represents the data that
Principle 6 - Be realistic : Software development can flows in and out of the system. For designing the
not be 100 % perfect, there can be more or less analysis model it is necessary to understand this
ambiguities and omissions, budgets and schedule data flow.
may vary, developers may make mistakes and so on. 2. The functionality of the software must be
performed : There are various types off the
Such things might occur during the planning of the
functionality that must be present in the system.
system. Some functions can be directly beneficial to the
Principle 7 - Adjust granularity according to plan : user. Some functions are control functions, some
functions are for transforming the data and so
Granularity means how much detailed is your project
on.
plan. The fine granularity plan provides more work
3. The behavior of the software must be
plan details planed relatively short time increment.
represented by the model : By creating
On the other hand, the coarse granular plan provide appropriate model the behavior of the computer
broader work task planed over long period. The plan system for the input submitted by the user,
must be flexible enough for making the adjustments interaction of the system with the external system
are represented by the software.
about the granularity of the project.
4. The model should be created in such a way that
Principle 8 - Ensure the quality : The plan must it represents the details of the software in
help the software team to induce quality in their layered or hierarchical manner : Software
development. systems are usually created to solve the complex
problems. The large and complex problems are
Principle 9 - Describe the accommodated changes : solved using divide and conquer strategy. These
The plan must help the software team to induce sub-problems are relatively easy to understand.
required changes in their development. This process of dividing the problems into
smaller sub-problems is called partitioning.
Principle 10 - Track the plan frequently and make
the changes as per the requirements : The project 5. The analysis task must move from basic
plan must be adjusted frequently. information to the implementation of the
concept : Before creating the analysis model the
information gathered is from users' point of
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 2-4 Software Requirement Engineering

view. This information should be transformed in such systems become difficult. This denotes low
such a way that the implementation of the coupling property of design.
concept using the computer based system. 8. Design representations must be easy to
understand : The software design is used to
(2) Design Modeling Principles
generate the code. Hence it must be easy to
Following are design modeling principles - understand so that implementation of the system
1. Analysis model must be used to create design can be effectively done.
model : The analysis model describes the 9. Design development must be iterative : The
information domain, system behavior, user iterative development of the design model will
visible functionalities and so on. The design refine the work and errors can be corrected in
model translates this information into the system each iteration. But each after each iteration it
architecture. Hence the elements of design model becomes difficult to keep the software design
should be traceable to analysis model. simple.
2. Consider the architecture of the system to be
built : The skeleton of the system should be Board Question
prepared before creating the actual design of the 1. Explain modeling practice in software engineering
system. For creating such architecture the with principles. MSBTE : Winter-17, Marks 4
information present in the analysis model is
used. 2.6 Construction Practices
3. Design of data is an important activity : The MSBTE : Summer-16, Marks 4

data design is an important element of the · The construction practices are based on -
architectural design. It represents the flow of Preparation principles, coding principles and
information. validation principles.
4. Interfaces must be designed carefully : The (1) Preparation principles
interfaces are important for communication of
These are some important principles that software
two components and communication with the
developers must follow before writing the code.
external environment. Hence these need to be
designed carefully. 1. Firstly, understand the problem for which the
system is designed.
5. User interface designs must be as per the
needs : User interfaces basically assist the users 2. Know the basic design principles and concepts.
to interact with the system via user interfaces. 3. Choose appropriate programming language for
Hence the design of user interface must be by coding.
considering the users needs.
4. Select such a programming environment which is
6. Component level design must be functionally convenient to work.
independent : Functional independence is a
5. Prepare the set of unit tests for each component
quality that indicates the single mindedness of
of the code.
software component. Ideally every component
must focus on one functionality at a time. This is (2) Coding principles
called cohesiveness of the components. During
These are some important principles that software
component level design high cohesiveness
developers must follow while writing the code.
(functionally independence) is required.
7. Components must be loosely coupled : If the 1. Adopt structured or modular programming
components are tightly coupled then error approach for the algorithm.
propagation might get increased. The maintaining 2. Choose the appropriate data structures.

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 2-5 Software Requirement Engineering

3. By understanding the system architecture, create appropriately. Moreover, if any problem or

appropriate interfaces. query occurs then help the end-user to solve it.
4. Keep conditional logic very simple. 4. Appropriate instructional material must be
5. Create the nested loop in such a way that they given to the end user : Provide the user with
can be tested easily. instruction manuals, help material, training aids,
demo and so on for handling the system
6. Give meaningful variable names.
properly.
7. Make the code documented by adding
5. Do not deliver erroneous software : Never
appropriate comment statements within it.
provide the low quality or erroneous software
8. Make use of indentation and blank lines in to the customers.
between the code so that appropriate visual
layout of the code can be created. Board Questions
1. Explain deployment principle.
(3) Validation principles
MSBTE : Summer-15, Winter-15, Marks 4
These are some important principles that software
developers must follow after completion of writing 2. What is Software deployment ? State the
the code. principles to be followed while preparing to deliver
the software increment. MSBTE : Summer-16, Marks 8
1. Review the code thoroughly.
3. What is meant by software deployment ?
2. Perform unit tests and correct the errors. MSBTE : Summer-17, Marks 4
3. Refactor the code.
Part II : Requirement Engineering
Board Question
1. What is software coding ? State three principles of
code validation. MSBTE : Summer-16, Marks 4 2.8 Requirement Gathering and Analysis
MSBTE : Summer-15, 17, 18, Winter-15, 17, Marks 8

· Requirement engineering is the process of

2.7 Software Deployment
MSBTE : Summer-15, 16, 17, Winter-15, Marks 8 establishing the services that the customer requires
from a system. And the constraints under which it
· During deployment of the software component
three activities are carried out - i) Delivery operates and is developed.
ii) Support and iii) Feedback. Requirement Engineering Tasks
· Following are the set of principles that must be
· Requirement engineering is the process
followed while delivering the software
increment/release to the customer. characterized for achieving following goals -
1. Manage or fulfill the customer expectations : n Understanding customer requirements and their
Quiet often customers expect too much from the needs
delivered software product. To avoid this have a n Analyzing the feasibility of the requirement
clear communication with the customer about
n Negotiating the reasonable solutions
the functionalities of the product.
2. The delivery package must be assembled and n Specification of an unambiguous solution.
well tested : Provide CD-ROM or other media n Managing all the requirements of the project
to the customer containing all the executables of
n Finally transforming the requirements into the
the software components.
operational systems
3. The support service must be ready before · Requirement engineering process performs
delivery of the software system : Assist the
following seven distinct functions -
user to handle the software system
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 2-6 Software Requirement Engineering

Inception 2.8.3 Elaboration

· Elaboration is an activity in which the information
Elicitation
about the requirements is expanded and refined.
Elaboration This information is gained during inception and
elicitation.
Requirement
engineering Negotiation · The goal of elaboration activity is to prepare a
tasks
technical model of software functions, features and
Specification
constraints.

Validation
2.8.4 Negotiation

Requirement management · Sometimes customer may demand for more than

that is achieved or there are certain situations in
Fig. 2.8.1 Requirement engineering tasks
which customer demands for something which
cannot be achieved in limited business resources.
To handle such situations requirement engineers
Let us now discuss these tasks in detail -
must convince the customers or end users by
2.8.1 Inception solving various conflicts. For that purpose,
requirement engineers must ask the customers and
· The inception means specifying the beginning of
stakeholders to rank their requirements and then
the software project. Most of the software projects
priority of these requirements is decided. Using
get started due to business requirements. There may
iterative approach some requirements are
be potential demand from the market for a
eliminated, combined or modified. This process
particular product and then the specific software
continues until the users' satisfaction is achieved.
project needs to be developed.
· There exist several stakeholders who define the 2.8.5 Specification
business ideas. Stakeholders mean an entity that ·A specification can be a written document,
takes active participation in project development. In mathematical or graphical model, collection of use
software project development, the stakeholders that case scenarios or may be the prototypes.
are responsible for defining the ideas are business
· There is a need to develop a standard specification
managers, marketing people, product managers and
in which requirements are presented in consistent
so on. Their role is to do rough feasibility study
and understandable manner.
and to identify the scope of the project.
· For a large system it is always better to develop the
· During the inception a set of context free questions
specification using natural language and in a
is discussed. The purpose of inception is to -
written document form. The use of graphical
1. Establish the basic understanding of the project.
models is more useful for specifying the
2. Find out all possible solutions and to identify requirements.
the nature of the solution. · Specification is the final work product of
3. Establish an effective communication between requirement engineering process. It describes the
developer and the customer. functions, constraints and performance of computer
based systems.
2.8.2 Elicitation
· Before the requirements can be analyzed and 2.8.6 Validation
modelled they must undergo through the process of · Requirement Validation is an activity in which
elicitation process. Requirements elicitation means requirement specification is analyzed in order to
requirements discovery. Requirements elicitation is ensure that the requirements are specified
very difficult task. unambiguously. If any inconsistencies, omissions
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 2-7 Software Requirement Engineering

and errors are identified then those are corrected or 2.9 Types of Requirements
modified during the validation.
· The most commonly used requirement validation Functional and Non-Functional Requirements
mechanism is Formal Technical Review (FTR). In · Software system requirements can be classified as
FTR, the review team validates the software functional and non functional requirements.
requirements. The review team consists of
2.9.1 Functional Requirements
requirement engineers, customers, end users,
marketing person and so on. This review team · Purpose : Functional requirements should describe
basically identifies conflicting requirements, all the required functionality or system services.
inconstancies or unrealistic requirements. · The customer should provide statement of service.
It should be clear how the system should react to
2.8.7 Requirement Management particular inputs and how a particular system
Definition : Requirements management is the process should behave in particular situation.
of managing changing requirements during the · Functional requirements are heavily dependent
requirements engineering process and system upon the type of software, expected users and the
development. type of system where the software is used.
· Functional user requirements may be high-level
Why requirements get change ? statements of what the system should do but
· Requirements are always incomplete and functional system requirements should describe the
inconsistent. New requirements occur during the system services in detail.
process as business needs change and a better · For example : Consider a library system in which
understanding of the system is developed. there is a single interface provided to multiple
· System customers may specify the requirements databases. These databases are collection of articles
from business perspective that can conflict with end from different libraries. A user can search for,
user requirements. download and print these articles for a personal
study.
· During the development of the system, its business
· From this example we can obtain functional
and the technical environment may get changed.
requirements as,
Board Questions 1. The user shall be able to search either all of the
1. List seven tasks of requirement engineering. initial set of databases or select a subset from it.
MSBTE : Summer-15, Marks 4 2. The system shall provide appropriate viewers
2. With reference to requirement engineering, explain for the user to read documents in the document
i) Inception and ii) Elicitation store.
MSBTE : Winter-15, Marks 4 3. A unique identifier (ORDER_ID) should be
3. Explain following requirements engineering tasks : allocated to every order. This identifier can be
copied by the user to the account's permanent
i) Negotiation ii) Specification
storage area.
MSBTE : Summer-17, Marks 4

4. What are major tasks of requirement engineering ? 2.9.1.1 Problems Associated with Requirements
MSBTE : Winter-17, Marks 8 · Requirements imprecision
5. Explain following requirements of engineering 1. Problems arise when requirements are not
tasks : i) Negotiation ii) Validation precisely stated.
MSBTE : Summer-18, Marks 4 2. Ambiguous requirements may be interpreted in
different ways by developers and users.
3. Consider meaning of term 'appropriate viewers'
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 2-8 Software Requirement Engineering

· User intention - Special purpose viewer for each 2.9.2.1 Types of Non Functional Requirements
different document type; · The classification of non functional requirements is
· Developer interpretation - Provide a text viewer as given in Fig. 2.9.1.
that shows the contents of the document.
Product requirements
· Requirements completeness and consistency - · These requirements specify how a delivered product
The requirements should be both complete and should behave in a particular way. For instance:
consistent. Complete means they should include execution speed, reliability.
descriptions of all facilities required. Consistent
Organizational requirements
means there should be no conflicts or
· The requirements which are consequences of
contradictions in the descriptions of the system
organizational policies and procedures come under
facilities.
this category. For instance : Process standards used
Actually in practice, it is impossible to produce a implementation requirements.
complete and consistent requirements document.
External requirements
2.9.2 Non Functional Requirements · These requirements arise due to the factors that are
external to the system and its development process.
· Purpose : The non functional requirements define
For instance : Interoperability requirements,
system properties and constraints.
legislative requirements.
Various properties of a system can be : Reliability,
response time, storage requirements. And Performance requirements
· These requirements specify the performance or
constraints of the system can be : Input and output
durability of its functioning. For instance : Response
device capability, system representations etc.
to various events at particular instance.
· Process requirements may also specify programming · In short, non functional requirements arise through
language or development method. i) User needs
· Non functional requirements are more critical than ii) Because of budget constraints
functional requirements. If the non functional iii) Organizational policies
requirements do not meet then the complete system
iv) The need for interoperability with other
is of no use. software or hardware systems

Non functional
requirement

Product Organizational External

requirements requirements requirements

Efficiency Reliability Portability nteroperability Ethical

requirement requirement requirement requirement requirement

Usability Delivery mplementation Standard Legislative

requirement requirement requirement requirement requirement

Performance Size Safety

requirement requirement requirement

Fig. 2.9.1 Types of non functional requirement

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 2-9 Software Requirement Engineering

v) Because of external factors such as safety 13. The system should be efficient.
regulations.
· Metrics used for specifying the non functional Non functional requirements
requirements 1. Each of the transaction should be made within 60
seconds. If the time limit is exceeded, then cancel
Property Metric the transaction automatically.
Speed Events per response time processed 2. If there is no response from the bank computer
transactions per second. after request is made within the minutes then the
card is rejected with error message.
Size Kilobytes.
3. The bank dispenses money only after the
Reliability Mean time to failure. Rate of failure.
processing of withdrawal from the bank. That
Occurrence availability.
means if sufficient fund is available in user's
Robustness Time to restart after failure. Probability of account then only the withdrawal request is
events causing failure.
processed.
Portability Number of target statements. 4. Each bank should process the transactions from
several ATM centers at the same time.
Ex. 2.9.1 : Enlist various functional and non functional
5. The machine should be loaded with sufficient
requirements for the Bank ATM system.
fund in it.
Sol. : Functional requirements
2.9.2.2 Domain Requirements
1. There should be the facility for the customer to
· Domain requirements are derived from the
insert a card.
application domain of the system instead of specific
2. The system should first validate card and PIN. user needs.
3. The system should allow the customer to deposit · These requirements make use of domain
amount in the bank. terminologies specific to the existing domain
4. The system should dispense the cash on concept.
withdrawal. · The domain requirements may be in the form of
5. The system should provide the printout for the new functional requirements, constraints on existing
transaction. functional requirement or guidance on how to carry
out certain computation.
6. The system should make the record of the
transactions made by particular customer. · These are the specialised requirements and hence
software engineers find it difficult to co-relate the
7. On invalid PIN entry for three times the card
domain requirements with the system requirements.
should be retained by the system.
· It is important to specify the domain requirements
8. The cash withdrawal is allowed in multiple of
otherwise the system will not work properly.
100.
· Example : Domain requirements for the library
9. The cash deposition is allowed in multiple of system.
100.
· There should be user interface for handling the
10. The customer is allowed to transfer amount databases. These interfaces should be according to
between the two accounts. some international standard.
11. The customer is allowed to know the balance · If there is copyright restriction on some document
enquiry. then it should get printed locally on the server. The
12. The customer is allowed to get the printout for copies of such document should not get created.
desired transaction.

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 2 - 10 Software Requirement Engineering

2.9.3 Difference between Functional and Non Guideline for FAST approach -
Functional Requirements 1. A meeting should be conducted and attended by
Non functional both software engineers and customers. The place
Functional requirements of meeting should be a neutral site.
requirements

The functional The non functional 2. Rules for preparation and participation must be
requirements specify the requirements specify the prepared.
features of the software properties of the software
system. system. 3. An agenda should be prepared in such a way
that it covers all the important point as well as it
Functional requirements Non functional
allows all the new innovative ideas.
describe what the product requirements describe how
must do. the product should 4. A facilitator controls the meeting. He could be
perform.
customer, developer or outsider.
The functional The non functional
5. A definition mechanism is used. The mechanism
requirements specify the requirements specify the
actions with which the experience of the user can be work sheets, flip charts, wall stickers,
work is concerned. while using the system. electronic bulletin board, chart room, virtual
Example : For a library Example : For a library forum.
management system, management system, for a 6. The goal is to identify the problem, decide the
allowing user to read the user who wishes to read
article online is a the article online must be elements of solution, negotiate different
functional requirement. authenticated first. approaches and specify the preliminary set of
solution requirements.
· In FAST meeting each FAST attendee is asked to
2.10 Eliciting Requirements
MSBTE : Summer-16, Marks 4 prepare - a list of objects, list of services and a list
of constraints.
· Questioning is useful only at inception of the
project but for detailed requirement elicitation it is · The list of objects consists of all the objects used in
not sufficient. During requirement elicitation certain the system, the objects that are produced by the
activities such as problem solving, elaboration, system and the objects that surround the system.
negotiation and specification must be carried out. · The list of services contain all the required
Various ways by which the requirement elicitation functionalities that manipulate or interact with the
can be done are - objects.
1. Collaborative requirement gathering · The list of constraints consists of all the constraints
2. Quality function deployment of the system such as cost, rules, memory
requirement, speed accuracy etc.
3. Use scenarios
· As the FAST meeting begins, the very first issue of
4. Elicitation work product
discussion is the need and justification for the new
Let us discuss these aspects of requirement product. Once everyone agrees upon the fact that
elicitation in detail - the product is justified, each participant has to
present his lists.
2.10.1 Collaborative Requirements Gathering
· These lists are then discussed, manipulated and
· Collaborative requirement gathering is done using these modified or refined lists are combined by a
collaborative, team-oriented approach. group.
· Facility Application Specification Technique (FAST) · The combined list eliminates redundant entries adds
is an approach in which joint team of customers new ideas that come up during the discussion. The
and developers work together to identify the combined list is refined in such a way that it helps
problem, propose elements of solution, negotiate in building the system.
different approaches and prepare a specification for
preliminary set of solution requirements.
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 2 - 11 Software Requirement Engineering

· The combined list should be prepared in such a customer needs and wants into technical
way that a "consensus lists" can be prepared, for requirements. This technique was introduced in
object, services and constraints. Japan.
· A team is divided into subteams. Each subteam · Under quality function deployment three types of
develops a minispecification from each consensus requirements can be defined -
list.
Normal requirements
· Finally a complete draft specification is developed.

For example - Types of

requirements Expected requirements
· A FAST team is working on a commerical product. under QFD
A following product description is given as below -
n "Nowadays the market for video game is Excited requirements

growing rapidly. We would like to enter this Normal requirements

market with more features, like attractive GUI, · The requirements as per goals and objectives of the
multiple sound setting, realistic (3D) animations. system are called normal requirements. These
This product is tentatively called 'Gamefun'. At requirements can be easily identified during the
the end of game, scores of each player should be meeting with the customer.
displayed". · For example : Handling mouse and keyboard
n The FAST attendee prepare following lists - events for any GUI based system.
1) List of objects - Display, menu, a sound, an Expected requirements
event (moving from one level to another) · These types of requirements are such requirements
and so on. which system must be having even if customer did
2) List of services - Setting sounds, setting not mention about them. These are such
requirements that if they are not present then the
colors in GUI, HELP, instructions for
system will be meaningless.
players, score card etc.
· For example : A software package for presentation
3) List of constraints - Must be user friendly,
(like Microsoft Power Point) must have option of
must have high speed, must accommodate 'new slide insert', so that user will be able to insert
less size, should have less cost. a new slide at any position during his presentation.
· The minispecification for Menu (object) can be as
Exciting requirements :
given below -
· When certain requirements are satisfied by the
n Contains 'Start game' and 'exit' options.
software beyond customer's expectations then such
n List of all functional keys with corresponding requirements are called exciting requirements.
functionality. · For example : Spell check facility in Microsoft Word
n Software provides interaction guidance, quick is an exciting requirement. Various types of
tour, sound controls. deployments that can be conducted during software
n All players will play or interact through keys. development process are -
· Function deployment : For determining the value of
n Software provides facility for change in the look
each function this deployment can be done.
of GUI.
· Information deployment : After identifying various
n Software displays scores of each player.
functionalities events and data objects must be
2.10.2 Quality Function Deployment identified.

· Qualityfunction deployment is a quality · Task deployment : The task associated with each
management technique which translates the function must be identified.

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 2 - 12 Software Requirement Engineering

· Value analysis : Identify the priorities of · A list of various stakeholders such as customer,
requirements. The technique of QFD requires proper end-users, technical persons, and many others who
interaction with customer. participate during requirement elicitation.

2.10.3 Usage Scenarios · A technical description of system environment

· During requirement gathering overall vision for · A list of requirements and constraints.
systems functions and features get developed. · A set of usage scenarios along with operating
· In order to understand how these functions and conditions.
features are used by different classes of end users, · The prototype that may get developed for defining
developers and users create a set of scenarios. This
the requirements in better manner.
set identifies the usefulness of the system to be
These work products are then reviewed by all the
constructed. This set is normally called as use-cases.
people who participate in requirement elicitation.
· The use-cases provide a description of how the
system will be used.
Board Question
2.10.4 Elicitation Work Product 1. What is requirements elicitation ? What are the
problems faced in eliciting requirements ?
Following are some work products that get produced
MSBTE : Summer-16, Marks 4
during requirement elicitation -
· A statement of feasibility study performed in order
2.11 Developing Use Cases
to find the need of the project. MSBTE : Summer-16, 18, Marks 4

· Statement for the scope of the system.

Ex. 2.11.1 : Draw a use case diagram for a Bank
Management System. MSBTE : Summer-16, Marks 4

Sol. :

Banking System

Logging in

Deposit Amount

Withdrawal of
Amount

Customer Bank

Get Account
Balance

Transfer of
Amount

Fig. 2.11.1

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 2 - 13 Software Requirement Engineering

Ex. 2.11.2 Draw a use case diagram for music system.

MSBTE : Summer-16, Marks 4

Sol. :

Electronic Music Files Management System

Song Unavailable
<<extend>>
By artist
View songs
By title

Start play
By Album
User <<include>>
Play a library Play Song

Randomize Order Delete a Song

<<include>>
Destroy <<include>>
Library
Destroy a song
<<include>>

Delete Library

Add a Song
<<include>>

Create Library
CD

Create CD

Rip CD

Stop Play

Fig. 2.11.2

Ex. 2.11.3 : Draw the use case diagram for taking "photocopy of ans books from msbte" website.
MSBTE : Summer-18, Marks 4

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 2 - 14 Software Requirement Engineering

Sol. :

Enroll

Authenticate
<<extend>> User

Login

Fill up Form

Submit Form
Apply for
<<extend>> Revaluation
Student
Get Photocopy

Change
Password

logout

Fig. 2.11.3
Ex. 2.11.4 : Draw use case diagram for railway ticket reservation system.
Sol. :

Railway Ticket Reservation System

logs in
<<extend>> Seat Unavailable
ViewSeat
Availability

ViewSchedule

Reserve a Seat
<<include>> <<include>>

Fillup Form Submit form

Passenger Booking System

PaysFare

<<include>> Credit Card

Payment

<<include>>

Cancel reservation
CardValidation
Payment validation System

Fig. 2.11.4
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 2 - 15 Software Requirement Engineering

Ex. 2.11.5 : Consider an automated soda machine that gives cool drinks. Draw use case model of the soda machine.
Sol. :

Soda Vending Maching

Insert Coin

<<include>> Insufficient
Amount
<<extend>>
Verify Amount

Customer Select Cold

Drink Product

Dispense
Change

Dispense Service System

Soda

Fig. 2.11.5

2.12 Building Requirement Models

· Requirement analysis is an intermediate phase between system engineering and software design.
· Requirement analysis produces a software
specification. Analysis Design
model model
How is requirement analysis helpful ?
· Analyst - The requirement analysis helps the
'analyst' to refine software allocation. Using
requirement analysis various models such as
data model, functional model and behavioral
model can be defined.
· Designer - After requirement analysis, the
designer can design for data, architectural System Requirement Software
engineering analysis design
interface and component level designs.
· Developer - Using requirements specification
Fig. 2.12.1 Requirement analysis : An intermediate step
and design the software can be developed.

What are requirement analysis efforts ?

1. Problem recognition
· The requirement analysis is done for understanding the need of the system. The scope of the software
in context of a system must be understood.

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 2 - 16 Software Requirement Engineering

2. Evaluation and synthesis 2.14 Need for SRS

· Following are the tasks that must be done in · Following are some advantages of SRS which
evaluation and synthesis phase. clearly specify the need for SRS.
i) Define all externally observable data objects 1. SRS establishes an agreement between the client
evaluate data flow. and supplier about the nature of software
ii) Define software functions. product.
iii) Understand the behaviour of the system. 2. SRS can be used for validating the final product
iv) Establish system interface characteristics. because the software requirements are specified
in SRS. And whether the final product meets
v) Uncover the design constraints.
these requirements or not - this can be tested
3. Modelling using SRS.
· After evaluation and synthesis, using data, 3. For producing high quality software high
functional and behavioral domains the data model, quality SRS must be produced. Hence it is said
functional model and behavioral model can be built. that high quality SRS is a prerequisite for high
4. Specification quality software.
· The requirement specification (SRS) must be built. 4. High quality SRS reduces the cost of software
5. Review development.
· The SRS must be reviewed by project manager and
must be refined. 2.15 Format

2.12.1 Overall Objectives · Trackingthe team's progress throughout the

development activity.
· Following are three objectives of analysis model -
· Typically software designers use IEEE STD 830-1998
1. Describe customer requirement.
as the basis for the entire Software Specifications.
2. Create a basis for software design. The standard template for writing SRS is as given
3. Prepare valid requirements list. below.
· Analysis model bridges the gap between system Document Title
description and design model. The system Author(s)
description describes overall system functionality Affiliation
and design model describes the software Address
architecture, user interface and component level Date
structure. Document Version
· There is no clear division of analysis and design
1. Introduction
tasks. Some design can be carried out during
1.1 Purpose of this document : Describes the
analysis and some analysis might be conducted
purpose of the document.
during the design of the software.
1.2 Scope of this document : Describes the scope of
Part III : Software Requirement Specification this requirements definition effort. This section
also details any constraints that were placed
upon the requirements elicitation process, such as
2.13 Definition of Software Requirement schedules, costs.
Specification (SRS)
1.3 Overview : Provides a brief overview of the
· Software Requirements Specification (SRS) is a kind product defined as a result of the requirements
of document which includes both definition and elicitation process.
specification of requirements.

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 2 - 17 Software Requirement Engineering

2. General Description 4.1.3 API : Describes the application

· Describes the general functionality of the product programming interface, if present.
such as similar system information, user
4.2 Hardware Interfaces : Describes interfaces to
characteristics, user objective, general constraints
hardware devices.
placed on design team.
4.3 Communications Interfaces : Describes network
· Describesthe features of the user community,
interfaces.
including their expected expertise with software
systems and the application domain. 4.4 Software Interfaces : Describes any remaining
software interfaces not included above.
3. Functional Requirements : This section lists the
functional requirements in ranked order. A functional 5. Performance Requirements : Specifies speed and
requirement describes the possible effects of a memory requirements.
software system, in other words, what the system
6. Design Constraints : Specifies any constraints for
must accomplish. Each functional requirement should
be specified in following manner - the design team such as software or hardware
1. Description : A full description of the limitations.
requirement.
7. Other Non Functional Attributes : Specifies any
2. Criticality : Describes how essential this other particular non functional attributes required by
requirement is to the overall system.
the system. Such as :
3. Technical issues : Describes any design or 7.1 Security
implementation issues involved in satisfying this
7.2 Binary Compatibility
requirement.
7.3 Reliability
4. Cost and schedule : Describes the relative or
absolute costs of the system. 7.4 Maintainability

5. Risks : Describes the circumstances under which 7.5 Portability

this requirement might not able to be satisfied. 7.6 Extensibility
6. Dependencies with other requirements : 7.7 Reusability
Describes interactions with other requirements. 7.8 Application Compatibility
7. Any other appropriate. 7.9 Resource Utilization

4. Interface Requirements : This section describes 7.10 Serviceability

how the software interfaces with other software ... others as appropriate.
products or users for input or output. Examples of
8. Operational Scenarios : This section should
such interfaces include library routines, token
describe a set of scenarios that illustrate, from the
streams, shared memory, data streams and so forth.
user's perspective, what will be experienced when
4.1 User Interfaces : Describes how this product
interfaces with the user. utilizing the system under various situations.

4.1.1 GUI : Describes the graphical user 9. Preliminary Schedule : This section provides an
interface if present. This section should initial version of the project plan, including the major
include a set of screen dumps to illustrate tasks to be accomplished, their interdependencies,
user interface features.
and their tentative start/stop dates.
4.1.2 CLI : Describes the command-line interface
if present. For each command, a 10. Preliminary Budget : This section provides an
description of all arguments and example initial budget for the project.
values and invocations should be provided.
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 2 - 18 Software Requirement Engineering

11. Appendices 5. Stability : In SRS, it is not possible to specify all

11.1 Definitions, Acronyms, Abbreviations : the requirements. The SRS must contain all the
Provides definitions terms and acronyms, can essential requirements. Each requirement must
be provided. be clear and explicit.
11.2 References : Provides complete citations to all 6. Verifiable : The SRS should be written in such
documents and meetings referenced. a manner that the requirements that are
specified within it must be satisfied by the
2.16 Characteristics software. For instance - "The GUI should look
MSBTE : Summer-15,16,17, Winter-16, 17, Marks 4 good". This requirement is not verifiable because
· Following are some characteristics of a good SRS - one cannot specifically define "what is mean by
good ?".
1. Correct : The SRS must be correct. That means
all the requirements must be correctly 7. Modifiable : Writing SRS is an iterative process.
mentioned, or the requirements must be realistic Even after specifying the requirements they can
by nature. For instance : While developing a be modified later on if there is a change in user
word processing software, if there is a requirements. While modifying the SRS it is
requirement for spell check facility and if important to preserve the completeness and
software cannot find the spelling errors from the consistency in requirements.
document, then that means requirement is 8. Traceable : If origin of requirement is properly
incorrect. given or references of the requirements are
2. Complete : To make the SRS complete, it should correctly mentioned then such a requirement is
specify the purpose of SRS. called as traceable requirement.
3. Unambiguous : When requirements are
understood correctly then only unambiguous Board Questions
SRS can be written. Unambiguous specification 1. What is SRS ? MSBTE : Summer-15,17,Marks 4
means only one interpretation can be made 2. What is SRS ? Explain importance of SRS.
from the specified requirements. If for particular MSBTE : Summer-16, Marks 4
term there are multiple meanings then, those
3. Explain general format of Software Requirement
terms should be mentioned in glossary with
Specification (SRS). MSBTE : Winter-16, 17, Marks 4
proper meaning.
4. Consistent : If there are not conflicts in the
specified requirements then SRS is said to be qqq
consistent.

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

 UNIT- III

3
3.1 Translating Requirement Model into
Software Modelling and Design

used to achieve the requirements defined for the

Design Model system.
MSBTE : Winter-16,17, Summer-15, 16, 17, Marks 8
· The interface design describes how software
· Software design is at the core of software communicates with systems. These systems are
engineering and it is applied irrespective of any interacting with each other as well as with the
process model. humans who operate them. Thus interface design
· After analysing and modelling the requirements, represents the flow of information and specific type
software design is done which serves as the basis of behaviour. The usage scenarios and behavioural
for code generation and testing. models of analysis modelling provide the
· Software designing is a process of translating information needed by the interface design.
analysis model into the design model. · The component-level design transforms structural
· The analysis model is manifested by scenario based, elements of software architecture into procedural
class based, flow oriented and behavioural elements description of software module. The information
and feed the design task. used by the component design is obtained from
· The classes and relationships defined by CRC index class based model, flow based model and
cards and other useful class based elements provide behavioural model.
the basis for the data or class design. · Software design is important to assess the quality

· The architectural design defines the relationship of software. Because design is the only way that we
between major structural elements of the software. can accurately translate the user requirements into
The architectural styles and design patterns can be the finished software product.

Mapping of analysis to design model

ts Flow · Class-based
m en ori elements
d ele en Component
· Data flow te · Flow-oriented Com-
se · Usecases d level
ba diagram el elements ponent
design
-

· Usecase diagram · Control flow level

r io

em

· Behavioral
na

design
en

· Activity diagram diagram elements

S ce

ts

· Processing · Scenario-based
· Swimlane Interface
narratives elements
diagram design
Analysis · Flow-oriented Interface
· Class diagram model elements design
· State
· Behavioral
· Analysis diagrams Architectural design
elements
Cla

package · Sequence
diagram · Flow-oriented
sbs

· CRC models elements Architectural

ts
as

· Collaboration · Class-based design

en

d Data/class diagram
e

ele m
diagrams le elements
me
nts ra le
vio · Class-based Data/ class
Beha elements diagram Design model

Fig. 3.1.1 Translating analysis model into the design model

®
(3 - -1)An up thrust for knowledge
TECHNICAL PUBLICATIONS
TM
Software Engineering 3-2 Software Modelling and Design

· Without design unstable system may get developed. · Roles such as manager, engineer, customer.
Even if some small changes are made then those · Organizational units such as division, departments.
changes will go fail. It will become difficult to test
· Places such as manufacturing floor, workshops.
the product. The quality of the software product can
· Structures such as student records, accounts, file.
not be assessed until late in the software process.
What are attributes ?
3.1.1 Data Modeling Attributes define properties of data object
· Data modelling is the basic step in the analysis Typically there are three types of attributes -
modelling. In data modelling the data objects are
examined independently of processing. 1. Naming attributes - These attributes are used to
name an instance of data object. For example : In
· The data domain is focused. And a model is created
a vehicle data object make and model are naming
at the customer’s level of abstraction.
attributes.
· The data model represents how data objects are
2. Descriptive attributes - These attributes are used
related with one another.
to describe the characteristics or features of the
3.1.1.1 Data Object, Attributes and Relationships data object. For example : In a vehicle data object
What is data object ? color is a descriptive attribute.

· Data object is a set of attributes (data items) that 3. Referential attribute - These are the attributes
will be manipulated within the software (system). that are used in making the reference to another
instance in another table. For example : In a
· Each instance of data object can be identified with
vehicle data object owner is a referential attribute.
the help of unique identifier. For example : A
student can be identified by using his roll number. What is relationship ?
Relationship represents the connection between the
· The system cannot perform without accessing to the
data objects. For example
instances of object.
The relationship between a shopkeeper and a toy is
· Each data object is described by the attributes which
as shown below
themselves are data items.
Here the toy and shopkeeper are two objects that
Data object is a collection of attributes that act as an share following relationships -
aspect, characteristic, quality or descriptor of the object. · Shopkeeper orders toys. · Shopkeeper sells toys.
· Shopkeeper shows toys. · Shopkeeper stocks toys.
Object : Vehicle
3.1.2 Cardinality and Modality
Attributes:
Make Cardinality in data modeling, cardinality specifies how
Model the number of occurrences of one object is related to the
Color number of occurrences of another object.
Owner
Price · One to one (1 : 1) - One object can relate to only
one other object.
Fig. 3.1.2 Object
· One to many (1 : N) - One object can relate to
The vehicle is a data object which can be defined or
many objects.
viewed with the help of set of attributes. · Many to many (M : N) - Some number of
occurrences of an object can relate to some other
Typical data objects are number of occurrences of another object.
· External entities such as printer, user, speakers.
· Things such as reports, displays, signals. Modality indicates whether or not a particular data
object must participate in the relationship.
· Occurrences or events such as interrupts, alarm,
telephone call.
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 3-3 Software Modelling and Design

Cardinality : Single customer Cardinality : Many purchase

waiting for purchase actions is possible.

is provided with Purchase

Customer
action

Modality : It is optional,
Modality : For purchase action there may not be
customer is must any purchasing
(modality 1) (modality 0)

Fig. 3.1.3 Cardinality and modality

Modality of a relationship is 0 (zero) if there is no 1. Describe customer requirement.

explicit need for the relationship to occur or the 2. Create a basis for software design.
relationship is optional. The modality is 1 (one) if an
3. Prepare valid requirements list.
occurrence of the relationship is mandatory.
· Analysis model bridges the gap between system
Example : Refer Fig. 3.1.3.
description and design model. The system
Board Questions description describes overall system functionality
1. With neat diagram explain translation of analysis and design model describes the software
model into design model. MSBTE : Summer-15, Marks 8 architecture, user interface and component level
structure.
2. Describe data objects and data attributes.
· There is no clear division of analysis and design
MSBTE : Summer-15, Marks 4
tasks. Some design can be carried out during
3. Explain cardinality and modality with example.
analysis and some analysis might be conducted
MSBTE : Summer-15, Marks 4
during the design of the software.
4. What is data modeling ? Explain the terms
cardinality and modality. MSBTE : Summer-16, Marks 4 3.2.1 Elements of Analysis Model

5. Compare cardinality and modality. Analysis modelling approach

MSBTE : Winter-16,Summer-17, Marks 4
Structured approach Object oriented approach
6. Explain modality with the help of example.
MSBTE : Winter-17, Marks 4
The analysis is made on The analysis is made on
data and processes in the classes and interaction
which data is transformed among them in order to
as separate entities. meet the customer
3.2 Analysis Modeling requirements.
MSBTE : Winter-16,17, Summer-15, 16, 17, 18, Marks 8
Data objects are modelled Unified Modelling
Requirement anslysis produces a software in such a way that data Language (UML) and
specification. attributes and their unified processes are used
relationship is defined in in object oriented
The requirement analysis helps the 'analyst' to refine structured approach modelling approach.
software allocation. Using requirement analysis
various models such as data model, functional model But the commonly used analysis model combines
and behavioral model can be defined. features of both these approaches because the best
· Following are three objectives of analysis model -
suitable analysis model bridges the software
requirements and software design.
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 3-4 Software Modelling and Design

Following are the elements of analysis model - Characteristics of Good Design

· Scenario based elements 1. The good design should implement all the
· Flow-oriented elements requirements that are explicitly mentioned in the
· Behavioural elements analysis model. It should accommodate all the
· Class based elements implicit requirements demanded by the customer.
Following Fig. 3.2.1 illustrates the elements of
analysis model. 2. The design should be simple enough so that the
code developer, code tester as well as those who
ent s Flow
e lem orie are supporting the software will find it readable
d · Data flow nte
se d
ba · Use cases diagram el and understandable.
io
· Control flow

em
ar

· Use case diagrams 3. The design should be comprehensive. That

en

diagram

en
Sc

· Activity diagrams

t
means it should provide a complete picture of

s
· Swim lane software, addressing the data, functional and
diagram behavioural domains from an implementation
The
analysis perspective.
model · State
· Class diagram diagram
· Sequence
3.3.1 Fundamental Design Concepts
· Analysis
diagram
ts

packages The software design concept provides a framework

en

Be
em

· CRC models
ha

for implementing the right software.

vi
el

or
ed · Collaboration le a
as
ss
b diagrams ent
le m Various issues that must be considered during
Cla s
software design are -
Fig. 3.2.1 Analysis model
(1) Abstraction
Board Questions
1. Write importance of analysis modeling. The abstraction means an ability to cope up with the
MSBTE : Summer-15, 17, Marks 4
complexity. Software design occurs at different levels
of abstraction. At each stage of software design
2. With a neat diagram explain analysis model.
process levels of abstractions should be applied to
MSBTE : Winter-15, Marks 4
refine the software solution. At the higher level of
3. Explain the various elements of analysis modeling abstraction, the solution should be stated in broad
in detail. MSBTE : Winter-15, Marks 6 terms and in the lower level more detailed
4. Describe the terms : Analysis modeling and design description of the solution is given.
modeling. MSBTE : Summer-16, Marks 4
(2) Modularity
5. Describe four principles of analysis modeling.
· The software is divided into separately named
MSBTE : Winter-16, Summer-18, Marks 4
and addressable components that called as
6. Explain analysis modeling. MSBTE : Winter-17, Marks 4 modules.
7. List and explain the elements of analysis model · Monolithic software is hard to grasp for the
with neat labeled diagram. software engineer, hence it has now become a
MSBTE : Summer-18, Marks 8
trend to divide the software into number of
products. But there is a co-relation between the
3.3 Design Modeling
MSBTE : Winter-15, 16,Summer-15, 17, Marks 4 number of modules and overall cost of the

Software design is model of software which translates software product.

the requirements into finished software product in (3) Architecture
which the details about software data structures, · Architecture means representation of overall
architecture, interfaces and components that are structure of an integrated system.
necessary to implement the system are given.
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 3-5 Software Modelling and Design

· In architecture various components interact and · Pattern can be used for current work.
the data of the structure is used by various · Pattern can be used to solve similar kind of
components. problem with different functionality.
· In architectural design various system models can (6) Information Hiding
be used and these are - Information hiding is one of the important property
of effective modular design. The term information
Model Functioning hiding means the modules are designed in such a
way that information contained in one module cannot
Structural model Overall architecture of the system
can be represented using this be accessible to the other module (the module which
model. does not require this information). Due to information
hiding only limited amount of information can be
Framework model This model shows the architectural
framework and corresponding passed to other module or to any local data structure
applicability. used by other module.

Dynamic model This model shows the reflection of The advantage of information hiding is basically in
changes on the system due to testing and maintenance. Due to information hiding
external events. some data and procedures of one module can be
Process model The sequence of processes and their hidden from another module. This ultimately avoids
functioning is represented in this introduction of errors module from one module to
model. another. Similarly one can make changes in the
Functional model The functional hierarchy occurring desired module without affecting the other module.
in the system is represented by this (7) Functional Independence
model.
· The functional independence can be achieved by
developing the functional modules with
(4) Refinement single-minded approach.
· Refinement is actually a process of elaboration. · By using functional independence functions may
· Stepwise refinement is a top-down design strategy be compartmentalized and interfaces are
proposed by Niklaus WIRTH. simplified.
· The architecture of a program is developed by · Independent modules are easier to maintain with
successively refining levels of procedural detail. reduced error propagation.
· The process of program refinement is analogous · The major benefit of functional independence is in
to the process of refinement and partitioning that achieving effective modularity.
is used during requirements analysis. · The functional independence is assessed using two
· Abstraction and refinement are complementary
qualitative criteria - Cohesion and coupling.
· Cohesion : A cohesive module performs only "one
concepts. The major difference is that - In the
task" in software procedure with little interaction
abstraction low-level details are suppressed.
with other modules. In other words cohesive
Refinement helps the designer to elaborate
module performs only one thing.
low-level details.
· Coupling : Coupling effectively represents how
(5) Pattern the modules can be "connected" with other
module or with the outside world.Coupling is a
According to Brad Appleton the design pattern can
measure of interconnection among modules in a
be defined as - It is a named nugget (something
program structure.
valuable) of insight which conveys the essence of
proven solution to a recurring problem within a (8) Refactoring
certain context. · It is defined refactoring as "The process of
In other words, design pattern acts as a design changing a software system in such a way that
solution for a particular problem occurring in specific the external behaviour of the design do not get
domain. Using design pattern designer can determine changed, however the internal structure gets
whether- improved".
· Pattern can be reusable.
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 3-6 Software Modelling and Design

· Benefits of refactoring are -

1. The redundancy can be achieved.
2. Inefficient algorithms can be eliminated or can be replaced by efficient one.
3. Poorly constructed or inaccurate data structures can be removed or replaced.
4. Other design failures can be rectified.

Board Question
1. What are the characteristics of good design ? MSBTE : Summer-15,17,Marks 4

2. With reference to software design give the meanings of

i) Modularity ii) Functional independence iii) Refactoring iv) Information hiding MSBTE : Winter-15, Marks 4

3. Explain following with reference to design concepts in design modeling.

i) Abstraction ii) Functional independence MSBTE : Winter-16, Marks 4

3.4 Design Notations MSBTE : Winter-17, Summer-15, 17, Marks 4

3.4.1 Data Flow Diagram (DFD)

· Behavioral models are used to describe the overall behavior of a system. There are two types of
models that depict the behavior of the system
· The data flow model represents the flow of data and state chart diagram represent the states that are
occurring in the system.
Data flow model
· These models can be used separately on together depending upon nature
of application.
· Let us discuss these models in detail – State chart diagram

3.4.1.1 Data Flow Diagram

· The data flow diagrams depict the information flow and the transforms that are applied on the data
as it moves from input to output.
· The symbols that are used in data flow diagrams are -
· The data flow diagrams are used to represent the system at any level of abstraction.
· The DFD can be partitioned into levels that represent increase in information flow and detailed
functionality.
· A level 0 DFD is called as ‘fundamental system model’
or ‘context model’. In the context model the entire
software system is represented by a bubble with input
Process
and output indicated by incoming and outgoing
arrows.
· Each process shown in level 1 represents the sub
functions of overall system. Data store
· The number of levels in DFD can be increased until
every process represents the basic functionality.
Flow of data (may be input
· As the number of levels gets increased in the DFD, data of output data)
each bubble gets refined. The following figure shows
the leveling in DFD. Note that the information flow External
continuity must be maintained. entity

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 3-7 Software Modelling and Design

Designing Data Flow Diagrams

· The data flow diagrams are used to model the information and function domain. Refinement of DFD
into greater levels helps the analyst to perform functional decomposition.
· The guideline for creating a DFD is as given in Fig. 3.4.1.

Level 0 DFD

0
x
z
Entity A nformation Entity B
y system

Level 1 DFD
1
x
Process
Entity A
P Entity B
y 2 3 z
R Q
Data store Process Process

Level 2 DFD 2.1

P

Process

V W

2.3 2.2
y
Q
T
Process Process
R
Data store
U

Level 3 DFD
S

2.2.1

Process
U
S3
S1
2.2.2 2.2.3
T S2 Q
Process Process

Fig. 3.4.1 Levels of DFD

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 3-8 Software Modelling and Design

1. Level 0 DFD i.e. Context level DFD should depict the system as a single bubble.
2. Primary input and primary output should be carefully identified.
3. While doing the refinement isolate processes, data objects and data stores to represent the next level.
4. All the bubbles (processes) and arrows should be appropriately named.
5. One bubble at a time should be refined.
6. Information flow continuity must be maintained from level to level.
· A simple and effective approach to expand the level 0 DFD to level 1 is to perform “grammatical
parse” on the problem description. Identify nouns and verbs from it. Typically nouns represent the
external entities, data objects or data stores and verbs represent the processes. Although grammatical
parsing is not a foolproof but we can gather much useful information to create the data flow
diagrams.

Rules for designing DFD

1. No process can have only outputs or only inputs. The process must have both outputs and inputs.

xy xy

xy xy

Fig. 3.4.2

2. The verb phrases in the problem description can be identified as processes in the system.

Fig. 3.4.3

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 3-9 Software Modelling and Design

Fig. 3.4.4

3. There should not be a direct flow between data stores and external entity. This flow should go
through a process.
4. Data store labels should be noun phrases from problem description.
5. No data should move directly between external entities. The data flow should go through a
process.

Source Sink Source Sink

Fig. 3.4.5

6. Generally source and sink labels are noun phrases.

7. Interactions between external entities is outside scope of the system and therefore not represented
in DFD.
8. Data flow from process to a data store is for updation/insertion/deletion.
9. Data flow from data store to process is for retrieving or using the information.
10. Data flow labels are noun phrases from problem description.

Ex. 3.4.1 : Draw a dataflow diagram level 0 and level 1 for a Book Publishing House. MSBTE : Summer-16, Marks 6

Sol.:

Level 0 DFD :

Request for Book Book Publishing House Response

Customer Order Processing Customer
System

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 3 - 10 Software Modelling and Design

Level 1 DFD :

Get Book
Request for Book Process Information Books
Customer
order Database
Credit Check
Customer Information
Books Order
Database

Assemble Bunch of
Purchase Orders Orders
to send to
Warehouse

Shipping Order Response

Warehouse Customer

Ex. 3.4.2 Draw DFD level 0 and level 1 for Hotel management system. MSBTE : Winter-16, Marks 6

Sol. : Level 0 DFD

In this level, the system is designed globally with input and output. The input to food ordering system
are -

1. As customer orders for the food. Hence food order is an input.

The output to food ordering system

are - Order For Food 0.0
Food
Kitchen
Order
1) Receipt. Hotel
Customer Management
2) The food order should be further System
given to kitchen for processing the
Restaurant
order. Receipt Management Manager
Report
3) Bill and management report is
given to restaurant manager. Fig. 3.4.6 Level 0 DFD

Level 1 DFD

In this level, the bubble 0.0 is shown in more detail by various processes. The process 1.0 is for
processing an order. And processes 2.0, 3.0 and 4.0 are for housekeeping activities involved in food
ordering system. To create a management report there should be some information of daily sold items.
At the same time inventory data has to be maintained for keep track of 'instock' items. Hence we have
used two data stores in this DFD -

1. Database of sold items 2. Inventory database.

Finally management report can be prepared using daily sold details and daily inventory deplition
amount. This management report is given to restaurant manager.

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 3 - 11 Software Modelling and Design

1.0
Processing
of
Order for food Order Food
Customer Kitchen
order

2.0
Sold Inventory
Update items data 3.0
Data base Sold
of sold items Items Update
Inventory
File

Inventory
data Inventory
Info. about
daily 4.0 database
sold items Generate Info. about daily inventory
Management
Report Depletion Amount

Management Restaurant
Report Manager

Fig. 3.4.7 Level 1 DFD

The processing unit can be globally given as

Ex. 3.4.3 For library management system draw level 0
and level 1 DFD. MSBTE : Winter-15, Summer-17, Marks 4 shown in Fig. 3.4.8.

Sol. : In this DFD the whole system is represented Library information system
with the help of input, processing and output. The The system will produce following outputs -
input can be -
i) The demanded book will be given to student.
i) Student requests for a book hence Book request.
Hence Book will be the output.
ii) To show identity of the student he/she has to
ii) The library information system should display
submit his/her Library card, hence Library card.
demanded book information which can be used
by customer while selecting the book.

0.0

Book request
Library Demanded
Student Library card Information Display of
System book Info Book

Book

Fig. 3.4.8 Level 0 DFD (Context level DFD)

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 3 - 12 Software Modelling and Design

Level 1 DFD

Book selves
1.0 k
Boo
Book request
Student Delivery Author (s) List of
Library card
of Book Authors
Title
Book List of
Titles
demanded
Topic Book
Info
List of topics

Topic
Display of
Book request Book
2.0
(By topic)
Demanded
Book Search Book
(Based on topic) by Topic Info

Fig. 3.4.9 Level 1 DFD

In this level, the system is exposed with more processing details. The processes that need to carried out
are -

i) Delivery of Book.

ii) Search by Topic.

These processes require certain information such as List of Authors, List of Titles, List of Topics, the
book selves from which books can be located. This kind of information is represented by data store.

Ex. 3.4.4 Draw and explain level 0 and level 1 Dataflow diagram for "Online examination Win17 of form filling on
MSBTE website". MSBTE : Summer-18, Marks 6

Sol. :

0.0
Request Online Icard
Student exam W17 Student
for logging
system

Fig. 3.4.10 Level 0 DFD

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 3 - 13 Software Modelling and Design

0.0 Validate
Request Student
Student Logs in Status
for logging Registration info.

Fills form

1.1
Inputting Form
data to
form fields Validation
Status

Checked
Form
1.2
Entry
Deposit Registration
Exam Fees acknowlege Account

Request
for issueing
Icard
1.3
Icard Issue entry Icard
Icard Student
Register Issue

Fig. 3.4.11 Level 1 DFD

Ex. 3.4.5 : Draw Level 0 and Level 1 DFD for railway reservation system
Sol. : Problem description : For an online railway reservation system, passenger can make online booking for
the seats, by specifying the requirements. These requirements are - type of reservation A/C coach, non A/C coach,
two tier or three tier number of seats, name of the train, start and destination of journey. The system then checks
for availability of such requirements. If such a reservation is possible then system generates availability of
reservation. The passengers checks for availability and the charges are then calculated for the selected
requirement, and these are acknowledged to the passenger. If the passenger is satisfied then he confirms the
reservation.
The required DFD can be drawn in levels as follows -

0.0
Reservation Online Reservation
Passenger railway Railway
details details reservation details office
system
Fare amount

Fig. 3.4.12 Level 0 DFD

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 3 - 14 Software Modelling and Design

1.0

Reservation Passenger
Passenger Processing Passenger database
details request details

Calculated Ra
ilw
fare amount ay
Sta na
tion me
s s
Sea
t, tim
Cha e
rges
Suitable ava Reservation
Info. ilabilit details
details y

1.1
Confirmation
Reservation of Reservation
details Railway office
reservation details
of reserved
seats

Fig. 3.4.13 Level 1 DFD

Ex. 3.4.6 : Draw Level 0 and Level 1 DFD for ATM system.
Sol.: The level 0 DFD is the context level DFD in which only inputs and outputs that are interacting with the
system are given.

Accounts database

Customer
keypad Screen

Printout
ATM
dispenser

Control Cash
system dispenser

Card
reader

Fig. 3.4.14 Level 0 DFD

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 3 - 15 Software Modelling and Design

More detailing is done in level 1.

Invalid Card reader

returns card

Screen
Verify
Card
pin and
reader Ac. no and AC. No.
PIN On
N
PI validity
a nd of card Control
o
.n system
Ac
Customer Command Display
keypad customer
for service options
selection

Selects Balance Prepare Printout

service enquiry printout dispenser

Request Checks
availability Update Cash Cash
for withdrawal of amount database dispenser
details

Account
info Account
info
Account database

Fig. 3.4.15

3.4.2 Structured Flow Chart

· The structure chart is a principle tool of structured design.
· The basic element in the structured chart is module. Module is defined as a collection of program
statement with four attributes.
· Input and output : What the module gets from the invoker is called input and what the receiver gets
from the module is called output.
· Function : The function processes the input and
produces the output. Get student Calling module (Superordinate)
details
· Mechanics : The code or the logic by which the
function is carried out.
· Internal data : It is the own workspace. Final student name Called module (Subordinate)
and marks
· The two modules can be connected to each other
by a connector as shown below.
Fig. 3.4.16 Connector

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 3 - 16 Software Modelling and Design

· The module uses data and flags. The data is processed by different modules. The flag is used as a
control signal. It can be set or reset.
· For example if we have two modules one for getting the employee detail(subordinate) and another
module is for finding the employee name(superordinate). Then the caller module will sent the data as
employee's ID and using that ID the called module will find the name of employee. If the employee
ID is valid then that message will be given by the called module to a caller module. The use of data
and flag can be as shown below.

Flag going from superordinate to subordinate

Get
employees
details Data going from superordinate to subordinate

Employee Flag going from subordinate to superordinate

Name
Employee
ID Data going from subordinate to superodinate
Employee 10
is valid

Find
employee
name

Fig. 3.4.17 Use of flag

· The iterations and decisions on a structured chart is as shown below.

Symbol for showing

decisions

Symbol for showing

Issue tickets to iteration
all passengers

Get Calculate fare Calculate fare

reservation for general first for second Print ticket
details class passenger class passenger

Fig. 3.4.18 Interaction

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 3 - 17 Software Modelling and Design

· The example of a structure chart is as given below.

Get fees from

all students
Total for one Total for all
student students
Valid student Total for one
entry made student

Calculate total
Calculate fees Calculate total
number of
for one student fees
students
Record
Valid student Total number
is valid Total fees
record of students

Get valid student

PRINT
record

Students Field
record Field valid

READ EDIT FIELD

Fig. 3.4.19 Structure chart

3.4.3 Decision Tables

Many software applications possess certain modules in which certain complex conditions occur and
such conditions should be responded by taking appropriate actions. Hence decision tables are used in
which complex conditions and corresponding actions are stored in a tabular form. Such decision table
can be used by software program to model the complicated logic. And therefore it is almost impossible
to mis-interpret the decision table.

The decision table is divided into four sections as given below.

Rules

Conditions Condition alternatives

Actions Action entries

The decision tables can associate many independent conditions with several actions in an elegant way.
The rules can be shown by numbering them.

For example : we can create a decision table for following scenario

“ A nationalised bank gives housing loan to his customers with fixed and floating rate of interset. If
the customer chooses the fixed rate of interest and takes a loan of an amount which is less than one
lakhs then apply scheme A structure to him and if the customer chooses floating rate for a loan
amount less than 1 lakhs then apply scheme B structure to him and at the same time apply monthly

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 3 - 18 Software Modelling and Design

charges to him.If the cutomer chooses Goals of Testing

floating rate with loan amount > 1 lakhs The testing goals are,
then apply monthly charges and give him
1. Testing is a process of executing a program with
other scheme”.
the intend of finding an error.

Condition 1 2 3 4 5 2. A good test case is one that has high probability

of finding an undiscovered error.
Fixed rate T F F F
3. A successful test is one that uncovers an as-yet
Floating rate F T T T undiscovered error.
Loan amount < 1 lakh F F T F The major testing objective is to design tests that
Action
systematically uncover types of errors with minimum
time and effort.
Min monthly charge F T T F
Testing Principles
Apply scheme A T F F F
Every software engineer must apply following testing
Apply scheme B F T F F
principles while performing the software testing.
Other mode of charge F F T F
1. All tests should be traceable to customer
In above given decision table T indicates condition is requirements.
true and F indicates condition is false. Thus decision 2. Tests should be planned long before testing
table is useful for representing the conditions and begins.
corresponding actions.
3. The Pareto principle can be applied to software
testing - 80 % of all errors uncovered during
Board Questions testing will likely be traceable to 20 % of all
1. What is DFD ? Explain level 1 DFD with program modules.
example. MSBTE : Summer-15, Marks 4
4. Testing should begin "in the small" and progress
2. What is DFD ? Explain its symbol. toward testing "in the large".
MSBTE : Summer-17, Marks 4 5. Exhaustive testing is not possible.
3. Explain DFD with example. 6. To be most effective, testing should be conducted
MSBTE : Winter-17, Marks 4 by an independent third party.

3.5 Testing 3.5.2 Black Box and White Box Testing

MSBTE : Summer-15, 16, 17, 18, Winter-15, 16, 17, Marks 4 Black Box Testing
· The black box testing is also called as behavioural
3.5.1 Meaning and Purpose
testing.
Definition : Software testing is an activity performed · Black box testing methods focus on the functional
to uncover errors. It is a critical element of software requirements of the software. Test sets are derived
quality assurance and represents the ultimate review that fully exercise all functional requirements.
of specification, design and coding.
· The black box testing is not an alternative to white
The purpose of software testing is to ensure whether box testing and it uncovers different class of errors
the software functions appear to be working than white box testing.
according to specifications and performance · Objective : Black box testing uncovers following
requirements. types of errors.
1. Incorrect or missing functions
2. Interface errors 3. Errors in data structures
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 3 - 19 Software Modelling and Design

4. Performance errors Disadvantages :

5. Initialization or termination errors 1. All the independent paths within a module

cannot be tested.
White Box Testing 2. Logical decisions along with their true and false
· In white box testing the procedural details are sides cannot be tested.
closely examined.
3. All the loops and the boundaries of these loops
· In this testing the internals of software are tested to cannot be exercised with black box testing.
make sure that they operate according to
4. Internal data structure cannot be validated.
specifications and designs.
Advantages and disadvantages of white box testing
· Objective : The major focus of white box testing is
on internal structures, logic paths, control flows,
Advantages :
data flows, internal data structures, conditions,
loops, etc. 1. Each procedure can be tested thoroughly. The
internal structures, data flows, logical paths,
Difference between black box testing and white
box testing conditions and loops can be tested in detail.
2. It helps in optimizing the code.
Sr.
Black box testing White box testing
No. 3. White box testing can be easily automated.
1. Black box testing is called White box testing is called 4. Due to knowledge of internal coding structure it
behavioural testing. glass box testing.
is easy to find out which type of input data can
2. Black box testing In white box testing the help in testing the application efficiently.
examines some procedural details, all the
fundamental aspect of the logical paths, all the
system with little regard internal data structures Disadvantages :
for internal logical are closely examined.
structure of the software. 1. The knowledge of internal structure and coding
3.
is desired for the tested. Thus the skilled tester is
During black box testing White box testing lead to
the program cannot be test the program required for whitebox testing. Due to this the
tested thoroughly.
testing cost is increased.
100 percent.

4.
2. Sometimes it is difficult to test each and every
This type of testing is This type of testing is
suitable for large projects. suitable for small projects. path of the software and hence many paths may
go untested.
Advantages and disadvantages of black box
3. Maintaining the white box testing is very difficult
testing
because it may use specialized tools like code
Advantages : analyzer and debugging tools are required.
1. The black box testing focuses on fundamental 4. The missing functionality can not be identified.
aspect of system without being concerned for
internal logical structure of the software. 3.5.3 Level of Testing

2. The advantage of conducting black box testing is We begin by ‘testing-in-the-small’ and move toward
to uncover following types of errors. ‘testing-in-the-large’.

i. Incorrect or missing functions Various testing strategies for conventional software

are
ii. Interface errors
iii. Errors in external data structures 1. Unit testing 2. Integration testing

iv. Performance errors 3. Validation testing 4. System testing

v. Initialization or termination errors

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 3 - 20 Software Modelling and Design

Testing Software
strategies development stages

System
testing System engineering

Validation
Requirements
testing

Integration
Design
testing
Unit
testing Code

Fig. 3.5.1 Testing strategy

1. Unit testing - In this type of testing techniques · The various tests that are conducted during the unit
are applied to detect the errors from each test are described as below.
software component individually. 1. Module interfaces are tested for proper
2. Integration testing - It focuses on issues information flow in and out of the program.
associated with verification and program 2. Local data are examined to ensure that integrity
construction as components begin interacting is maintained.
with one another.
3. Boundary conditions are tested to ensure that the
3. Validation testing - It provides assurance that module operates properly at boundaries
the software validation criteria (established established to limit or restrict processing.
during requirements analysis) meets all
4. All the basis (independent) paths are tested for
functional, behavioural and performance
ensuring that all statements in the module have
requirements.
been executed only once.
4. System testing - In system testing all system
5. All error handling paths should be tested.
elements forming the system is tested as a whole.
6. Drivers and stub software need to be developed
3.5.3.1 Unit Testing to test incomplete software. The “driver” is a
· In unit testing the individual components are tested program that accepts the test data and prints the
independently to ensure their quality. relevant results. And the “stub” is a subprogram
that uses the module interfaces and performs the
· The focus is to uncover the errors in design and
implementation.
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 3 - 21 Software Modelling and Design

Things to be tested
Source program

Interfaces
Module Local data
to be Generating
structures
Various tested Boundary condition
modules
in program Independent path
Error handling paths
Test
cases

Fig. 3.5.2 Unit testing

minimal data manipulation if required. This is illustrated by following Fig. 3.5.3.

Driver Interface
Local data structures
Boundary conditions
Independent paths
Module Error handling paths
Results

Stub Stub Stub

Test
cases

Fig. 3.5.3 Unit testing environment

7. The unit testing is simplified when a component with high cohesion (with one function) is designed. In such
a design the number of test cases are less and one can easily predict or uncover errors.

3.5.4 Test Documentation

3.5.4.1 Test Case Template

· Test cases are used to determine the presence of fault in the program. Sometimes even if there is
some fault in our program the correct output can be obtained for some inputs. Hence it is necessary
to exercise those set of inputs for which faults (if any) can be exposed off.
· Executing test cases require money because - i) machine time is required to execute test cases ii)
human efforts are involved in executing test cases. Hence in the project testing minimum number of
test cases should be there as far as possible.
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 3 - 22 Software Modelling and Design

· The testing activity should involve two goals - · Test case specification is the major activity in the
i) Maximize the number of errors detected. testing process. Careful selection of test cases will
help in conducting proper testing.
ii) Minimize the number of test cases.
· The selection of test case should be such that faulty There are two basic reasons why test case
module or program segment must be exercised by specification should be before using them for testing -
at least one test case. Firstly it will assist the tester to reveal as many errors
as possible from the program and secondly the high
· Selection of test cases is determined by some criteria
quality code can be produced.
which is called as test selection criterion. Hence the
test selection criterion T can be defined as the set of 3.5.4.2 Test Plan
conditions that must be satisfied by the set of test
Test plan is not a static document. It gets generated
cases.
during the development. The main purpose of test
· Testing criterion are based on two fundamental planning is to describe the product tests and to
properties - reliability and validity. establish the standards in testing process. The
· A test criterion is reliable if all the test cases detect structure of test plan is as given below.
same set of errors.
1. Testing process
· A test criterion is valid if for any error in the
program there is some set which causes error in the In this section various phases of testing process are
program. described.
· For testing criteria there is an important theorem -
2. Requirements traceability
"if testing criterion is valid and reliable if a set
satisfying testing criterion succeeds then that means Testing should be planned to meet all the
program contains no errors". requirements.
· Generating test cases to satisfy criteria is complex
3. Tested items
task.
The tested products of software are tested.
· The test case specification records the results of the
testing, the conditions used for testing particular
4. Testing schedule
unit. It also specifies the expected test results. It
records the outcome of test cases (Pass/Fail). The It includes testing schedule and resource allocation
sample structure of a test case specification is as for this schedule.
given below -
5. Test recording procedures
Precondition : After running the tests, it is necessary to record those
tests in order to check whether tests are conducted
Test Test steps Test systematically or not.
Test Test case case
Test Defect
case case de- status
priority severity
id name scrip- (Pass/ 6. Hardware and software requirements
tion Step Expected Actual Fail)
The required software tools and hardware utilization
is specified under this section.
1

7. Constraints
2
All the factors affecting the testing process are listed
under this section.
3

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 3 - 23 Software Modelling and Design

3.5.4.3 Introduction to Defect Report Assigned to The name of the person who is
Defect report is a document that identifies and assigned to fix the defect.
describes the defects detected by the tester. Status Specify the status of the defect.
The purpose of defect report is to state the problem Fixed build no. Specify the version of the product
as clearly as possible so that the developer can fix it where the defect was fixed.
easily.
3.5.4.4 Test Summary Report
In most of the software companies defect report is
used as a tool in defect management process. · Test summary report is a document which contains
summary of test activities and final test results.
The template of commonly used defect report is as
· After completion of testing cycle, it is very
follows -
important to communicate the test results and
findings to project stakeholders(Stakeholders are
ID Unique identifier given to the defect.
people who take part in developing the software
Project Name of the Project product) so that decisions can be made for the
software release.
Product Name of the product
Template : The IEEE template for Test Summary
Release version Specify the release version of the
Report is as given below -
product.

Module Specify the module name in which Test Summary Report Identifier
defect is detected.
[Enter Some type of unique company generated number to
Build version Specify the build version of the identify this summary report, its level and the level of
product where the defect was
detected. software that it is related to.]

Summary Specify clear and concise summary Summary

of defect.
[Include basic information about what was tested and what
Description Specify the detailed description of
the defect. Describe the defect in happened.]
simple words. It should be
comprehensive. Project Name : [Project name]
· System Name : [System name]
Steps to replicate Step by step description of the way
to reproduce the defect. · Version Number : [Version number]
· Test Item : [This should match the item definitions
Actual results Specify the actual results you
received when you followed the from the appropriate level test plan that this report
steps. is covering. Any variance from the items specified
Expected results Specify the expected results from the in the test plan should be identified.]
steps to replicate. · Additional Comments : [Enter any additional
Attachment Attach any additional information comments]
like screenshots and logs.
Variances
Remarks Mention any additional comments
on defect. Document any changes from those areas agreed on in
the reference documents, especially in areas that may
Defect severity Mention the severity of defect.
cause concern to the group accepting the test results.
Defect priority Mention the priority of the defect.
Support materials and documents for-
Reported by The name of the person who report
the defect. 1) Change requests
2) Enhancement requests
3) Incident reports
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 3 - 24 Software Modelling and Design

Comprehensive assessment Signature: Date: ____________

[Enter a comprehensive assessment of your interpretation Print Name: _________________
of how adequate the test was in light of how thorough the
test plan said it should be ? What wasn't tested well Title: _______________________
enough ?] Role: ________________________
Summary of resultss
[Summarize the test results. Include a detailed Board Questions
description of any deviations from the original test 1. List four objectives of testing.
plan, design, test case, or expected results. Include MSBTE : Summer 15, Winter-17,Marks 4
any issues or bugs discovered during the test.]
2. State eight characteristics of software bugs.
Evaluation
MSBTE : Summer-15,18, Winter-17, Marks 4
· Based on evaluation of testing, each identified test
item should be covered in the evaluation. 3. Describe the attributes of a good test.
MSBTE : Winter-15, Marks 4
· Evaluate exist criteria mentioned in the test plan.
4. Explain the testing concept with its Testing
· Evaluate final defect status
Principles. (any four principles)
· Identify and evaluate product risk, quality of test
MSBTE : Summer-18, Marks 4
object, and testing process.
5. Compare white box and black box testing.
Summary of activities
MSBTE : Summer 15,18,Marks 4
Cover the planned activities and the changes to those
plans especially in areas where the amount of actual 6. Explain white box testing.
effort greatly exceeded the planned effort. Include the MSBTE : Winter-15, Marks 4

reasons for the variances and the possible impact on 7. Describe white box and black box testing of
the testing staff. software. MSBTE : Winter-16, Marks 4

[Include 8. List the objective of black box testing.

· Staff time used in Hours per day/week MSBTE : Summer-17, Marks 4

· Elapsed time versus staff time 9. Explain unit testing. MSBTE : Winter-15,17, Marks 4

· Is staff working excess hours per week 10.What aspects of the software are tested in Unit
· Costs - planned versus actual Testing ? MSBTE : Summer-16, Marks 4

· Variances and the reasons for the change such as - 11.Describe in brief four level testing process in test
change in project scope, requirements changes, execution. MSBTE : Winter-16, 17, Marks 4
newly introduced defects, and so on.] 12.Draw stub and driver mechanism of unit testing
Approvals and enlist various types of errors detected by unit
The undersigned acknowledge they have reviewed testing. MSBTE : Summer-18, Marks 4
the <Project Name> Test Summary Report and agree
13.Explain test case design in detail.
with the approach it presents. Changes to this Test
MSBTE : Summer-17, Marks 4
Summary Report will be coordinated with and
approved by the undersigned or their designated 14.List various testing characteristics.
representatives. MSBTE : Summer-17, Marks 4

[List the individuals whose signatures are desired. 15.What do you mean by good test ?
Examples of such individuals are Quality Manager or MSBTE : Winter-17, Marks 4

Tester. Add additional lines for signature as necessary.

Although signatures are desired, they are not always qqq
required to move forward with the practices outlined
within this document.]
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

 UNIT- IV

4
4.1 Management Spectrum
Software Project Estimation

(1) Product objectives and scope must be

MSBTE : Winter-16, Summer-18
established.
Effective software project management focuses four
(2) Alternative solutions should be considered.
P’s i.e. people, product, process and project. The
successful project management is done with the help (3) Technical and management constraints must
of these four factors where the order of these be identified.
elements is not arbitrary. Project manager has to · The software developer and customer must
motivate the communication between stakeholders. communicate with each other in order to define the
He should also prepare a project plan for the success objectives and scope of the product.
of the product. · This is done as the first step in requirement
gathering and analysis.
4.1.1 The People
· The scope of the project identifies primary data,
People factor is an important issue in software
functions and behaviour of the product.
industry. There is a strong need for motivated and
· After establishing the objectives and scope of the
highly skilled people for developing the software
product. The Software Engineering Institute (SEI) has product the alternative solutions are considered.
developed the People Management Capability · Finally, the constraints imposed by - delivery
Maturity Model (PM-CMM) deadline or budgetary restrictions, personal
availability can be identified.
By using PM-CMM model software organizations
become capable for undertaking complex applications 4.1.3 The Process
which ultimately attracts or motivates the talented
· The software process provides the framework from
people.
which the software development plan can be
Following are some key practice areas for software established.
people - · There are various framework activities that needs to
· Recruitment be carried out during the software development
· Selection process. These activities can be of varying size and
· Performance management complexities.

· Training compensation · Different task sets-tasks, milestones, work products

and quality assurance points enable framework
· Career development
activities to adapt the software requirements and
· Organization and work design certain characteristics of software project.
· Culture development. · Finally, umbrella activities such as software quality
assurance (SQA) and Software Configuration
4.1.2 The Product Management (SCM) are conducted. These umbrella
· Before planning the project three important tasks activities depend upon the framework activities.
need to be done -

®
(4 - -1)An up thrust for knowledge
TECHNICAL PUBLICATIONS
TM
Software Engineering 4-2 Software Project Estimation

4.1.4 Project 4.2.1 LOC based Estimation

For a successful software project, it is necessary to · Size oriented measure is derived by considering the
understand the mistakes in the project and how to size of software that has been produced.
correct them. John Reel defined ten symptoms to · The organization builds a simple record of size
indicate why the software projects fail - measure for the software projects. It is built on past
1. Software developers do not understand the experiences of organizations.
customer's need. · It is a direct measure of software

2. The scope of the project is not defined properly. Cost Doc.

Project LOC Effort Errors Defects People
($) (pgs.)
3. Change management is done poorly.
4. Business needs change very often. ABC 10,000 20 170 400 100 12 4

5. The technological changes are quite often. PQR 20,000 60 300 1000 129 32 6

6. Users are not co-operative. XYZ 35,000 65 522 1290 280 87 7

7. Unrealistic deadlines are set. M M M M M M M M

8. Projects do not get sponsored or Sponsorship Table 4.2.1 Size measure

gets lost. · A simple set of size measure that can be developed
is as given below :
9. Lack of skilled people in the project.
n Size = Kilo Lines of Code (KLOC)
10. Project managers do not adopt the best practices
for the projects. n Effort = Person/month
n Productivity = KLOC/person-month
Board Questions n Quality = Number of faults/KLOC
1. Define management spectrum and enlist n Cost = $/KLOC
characteristics of software.
nDocumentation = Pages of documentation /
MSBTE : Summer-18, Marks 4
KLOC
2. Explain 4 P's software project spectrum. · The size measure is based on the lines of code
MSBTE : Summer-18, Marks 4 computation. The lines of code is defined as one
3. Explain the following management spectrum : line of text in a source file.
i) The Process ii) The Project · While counting the lines of code the Simplest
MSBTE : Winter-16, Marks 4 Standard is :
n Don’t count blank lines.
4.2 Metrics for Size Estimation n Don’t count comments.
There are two types of metrics used for size Count everything else.
n

estimation of the project - · The size oriented measure is not universally

accepted method.

Metrics for size

Advantages
estimation 1. Artifact of software development which is easily
counted.
2. Many existing methods use LOC as a key input.
3. A large body of literature and data based on
LOC based Function point
estimation based estimation LOC already exists.

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 4-3 Software Project Estimation

Disadvantages

1. This measure is dependent upon the programming language.

2. This method is well designed but shorter program may get suffered.
3. It does not accommodate non procedural languages.
4. In early stage of development it is difficult to estimate LOC.

4.2.2 Function Points

· The oriented model is based on functionality of the delivered application.
· These are generally independent of the programming language used.
· This method is developed by Albrecht in 1979 for IBM. It uses function points.
· Function points are derived using :
1. Countable measures of the software requirements domain
2. Assessments of the software complexity.

How to calculate function point ?

· The data for following information domain characteristics are collected :
1. Number of user inputs - Each user input which provides distinct application data to the software
is counted.
2. Number of user outputs - Each user output that provides application data to the user is counted,
e.g. screens, reports, error messages.
3. Number of user inquiries - An on-line input that results in the generation of some immediate
software response in the form of an output.
4. Number of files - Each logical master file, i.e. a logical grouping of data that may be part of a
database or a separate file.
5. Number of external interfaces - All machine-readable interfaces that are used to transmit
information to another system are counted.
· The organization needs to develop criteria which determine whether a particular entry is simple,
average or complex.
· The weighting factors should be determined by observations or by experiments.

Weighting factor
Domain Characteristics Count Count
Simple Average Complex

Number of user input X 3 4 6

Number of user output X 4 5 7

Number of user inquiries X 3 4 6

Number of files X 7 10 15

Number of external interfaces X 5 7 10

Count Total

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 4-4 Software Project Estimation

· The count table can be computed with the help of n Quality = Number of faults/FP
above given table. n Cost = $/FP
· Now the software complexity can be computed by
n Documentation = Pages of documentation/FP.
answering following questions. These are
complexity adjustment values. Advantages
1. Does the system need reliable backup and 1. This method is independent of programming
recovery ? languages.

2. Are data communications required ? 2. It is based on the data which can be obtained in
early stage of project .
3. Are there distributed processing functions ?
4. Is performance of the system critical ? Disadvantages
5. Will the system run in an existing, heavily 1) This method is more suitable for business
utilized operational environment ? systems and can be developed for that domain.

6. Does the system require on-line data entry ? 2) Many aspects of this method are not validated.

7. Does the on-line data entry require the input 3) The functional point has no significant meaning.
transaction to be built over multiple screens It is just a numerical value.

or operations ?
Comparison between size oriented and function
8. Are the master files updated on-line ? oriented metrics

9. Are the inputs, outputs, files or inquiries Function oriented

Sr. No. Size oriented metrics
complex ? metrics

10. Is the internal processing complex ? 1. Size oriented software Function oriented
metrics is by metrics use a measure
11. Is the code which is designed being reusable ? considering the size of functionality
of the software that delivered by the
12. Are conversion and installation included in
has been produced. software.
the design ?
2. For a size oriented Most widely used
13. Is the system designed for multiple metric the software function oriented
installations in different organizations ? organization metric is the function
maintains simple point (FP)
14. Is the application designed to facilitate change records in tabular computation of the
form. The typical function point is
and ease of use by the user ? table entries are : based on
· Rate each of the above factors according to the Project name, LOC, characteristics of
Effort, Pages of software’s information
following scale : documents, errors, domain and
· Function Points (FP) = Count total x (0.65 + defects, total number complexity.
of people working on
(0.01 x Sum(Fi)) project.

0 1 2 3 4 5 Ex. 4.2.1 Study of requirement specification for ABC

project has produced following results : Need for 7 inputs,
No Incidental Moderate Average Significant Essential
influence 10 outputs, 6 inquiries, 17 files and 4 external interfaces.
Input and external interface function point attributes are
of average complexity and all other function points
· Once the functional point is calculated then we can attributes are of low complexity.
compute various measures as follows Determine adjusted function points assuming complexity
n Productivity = FP/person-month adjustment value is 32.

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 4-5 Software Project Estimation

Sol. : Given that :

7 inputs

10 Outputs

6 inquiries

17 files

4 external interfaces

Average complexity for inputs and external interfaces. Low complexity for remaining parameters.

Adjusted function point value å (Fi ) = 32.

Let us calculate count total value.

Weighting factor
Measurement
Count
parameters
X Simple Average complex

Number of 7 X 4 28
user inputs.

Number of 10 X 4 40
user
outputs.

Number of 6 X 3 18
user
inquiries.

Number of 17 X 7 119
files

Number of 4 X 7 28
external
interfaces.

Count total. 233

Function point = Count total ´ [0.65 + 0.01 ´ å (Fi )]

= 233 ´ [0.65 + 0.01 ´ 32]

= 233 ´ [0.65 + 0.32]

= 233 ´ 0.97

FP = 226.01

Hence adjusted function point is 226.01.

4.3 Project Cost Estimation Approach

Project estimation is one of the basic activity in project planning and measurement. There are three
categories of estimation techniques -

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 4-6 Software Project Estimation

5. The co-ordinator then calls a group meeting. In

Cost estimation approaches this meeting the experts mainly discuss the
points where their estimates vary widely.
6. The experts again fill out forms anonymously.
7. Again co-ordinator edits and summarizes the
Heuristic Empirical Analytical forms, repeating the steps 5 and 6 until the
technique technique technique
coordinator is satisfied with overall prediction
synthesized from experts.
4.3.1 Overview of Heuristic Technique · The key to this technique is in expert co-ordinator.

· This method makes use of previous project's The co-ordinator must be talented enough to
estimated cost. synthesize the diverse and wide ranging statements.
· This method is successful for technical forecasting.
· This method assumes the relationships among the
different project parameters. These parameters are Analytical Estimation
then correlated using suitable mathematical
In analytical estimation technique, the results are
expressions.
derived by making certain basic assumptions about
· Once the basic parameters are known, the other
the project. Hence analytical estimation technique
parameters can be easily determined by substituting have some scientific basis. Halstead's software
the value of basic parameters in mathematical science is based on analytical estimation model.
expression.
· COCOMO model is an example of Heuristic 4.3.2.1 Halstead's Software Science
technique. Halstead's complexity measurement was developed to
measure a program module’s complexity directly
4.3.2 Analytical and Empirical Estimation from source code, with emphasis on computational
complexity.
Empirical Estimation
· In empirical estimation technique an educated guess The Halstead's measures are based on four scalar
of project parameters is made. Hence empirical numbers derived directly from a program’s source
estimation model is based on common sense. code :
· However as there are many activities involved in n 1 is number of distinct operators,
empirical estimation techniques, this technique is
formalized. n 2 is number of distinct operands,

· Delphi technique is used for empirical estimation N 1 is total number of operators,

techniques. N 2 is total number of operands,
· This method involves more interactions and
From these numbers, five measures are derived :
communications between those who are
participating. The procedure is as follows. Measure Symbol Formula
1. The co-ordinator presents a specification and
estimation form to each expert. Program length N N = N1 + N2

2. Co-ordinator calls a group meeting in which the Program n n = n1 + n 2

vocabulary
experts discuss estimation issues with the
coordinator and each other. Volume V V = N * (log 2 n)

3. Experts fill out forms anonymously. Difficulty D D = (n1/2) * (N2 /2)

4. Co-ordinator prepares and distributes a summary Effort E E=D*V
of the estimates.

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 4-7 Software Project Estimation

Halstead's uses certain measures such as program 5. The reserve words, return, default, continue,
length, program vocabulary, volume, difficulty and break, sizeof are all operators.
effort for the given algorithm. By this Halstead's is 6. The brackets, commas, semicolons are operators.
trying to show that the program length can be
7. The unary and binary operators are considered
calculated, volume of the algorithm can be estimated.
as operators. The & is considered as operator.
The above given table shows how actually these
measures can be obtained. 8. In arrays, array name and index are considered
as operands and [ ] is considered as operator.
The Halstead's measures are applicable to operational
systems and to development efforts once the code has 9. All hash directives can be ignored.
been written. Thus using Halstead's measurement 10. Comments are not considered.
experimental verification can be performed in 11. In Goto statement, goto is considered as operator
software science. and label as operand.

Program length
Ex. 4.3.1 Obtain Halstead's length and volume measure
The length of a program is total usage of operators for following C function.
and operands in the program. void swap (int a [ ], int i)
{
Length = N 1 + N 2 int temp ;
temp = a[i] ;
Program vocabulary a[i] = a[i+1] ;
The program vocabulary is the number of unique a[i+1] = temp ;
operators and operands used in the program. }
Sol. : We will first find out the operands and
Vocabulary × n = n 1 + n 2 operators from above function along with their
occurrences.
Program volume
Operands Occurrences Operators Occurrences
The program volume can be defined as minimum
swap 1 () 1
number of bits needed to encode the program.
a 5 {} 1
V = N log 2 n
i 5 void 1

Length estimation temp 3 int 3

1 2 [] 5
N = n 1 log 2 n 1 + n 2 log 2 n 2
, 1

Guideline for calculating operands and operators : ; 4

1. All the variables and constants are considered as = 3
operands.
+ 2
2. Local variables with same name, if occuring in
different functions are counted as unique n1 = 5 N1 = 16 n2 = 9 N2 = 21
operand.
N = N 1 + N 2 = 16 + 21 = 37 n = n 1 + n 2 = 14
3. Function calls are considered as operators.
Estimated length = n 1 log 2 n 1 + n 2 log 2 n 2
4. The looping statements, do ... while, while, for
are operators. The statements if, if ... else are = 5 log2 5 + 9 log2 9
operators. The switch ... case statements are
= 5 * 2.32 + 9 * 2.19
considered as operators.
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 4-8 Software Project Estimation

= 11.60 + 19.77 = 31.37 D is the development time in chronological months.

Volume = N ´ log 2 n KLOC means kilo line of code for the project.

= 37 * log2 (14) P is total number of persons required to accomplish

the project.
Volume = 37 * 2.63 = 97.64
The coefficients a b , b b , c b , d b for three modes are as
given below.
4.4 COCOMO
Software projects ab bb cb db
COCOMO is one of the most widely used software
estimation models in the world. This model is Organic 2.4 1.05 2.5 0.38
developed in 1981 by Barry Boehm to give an Semi-detached 3.0 1.12 2.5 0.35
estimate of the number of man-months it will take to
Embedded 3.6 1.20 2.5 0.32
develop a software product. COCOMO predicts the
efforts and schedule of a software product based on Table 4.4.1
size of the software. COCOMO stands for
Merits of basic COCOMO model
"COnstructive COst MOdel".
Basic COCOMO model is good for quick, early,
COCOMO has three different models that reflect the rough order of magnitude estimates of software
complexity - project.
· Basic model
· Intermediate model Limitations of basic model
· Detailed model. 1. The accuracy of this model is limited because it
Similarly there are three classes of software projects. does not consider certain factors for cost
estimation of software. These factors are
1) Organic mode : In this mode, relatively small, hardware constraints, personal quality, and
simple software projects with a small team are experience, modern tachniques and tools.
handled. Such a team should have good application
2. The estimates of COCOMO model are within a
experience to less rigid requirements.
factor of 1.3 only 29 % of the time and within the
2) Semi-detached projects : In this class an factor of 2 only 60 % of time.
intermediate projects in which teams with mixed
Example
experience level are handled. Such projects may have
Product attributes
mix of rigid and less than rigid requirements. · Required software reliability
· Size of application database
3) Embedded projects : In this class, projects with · Complexity of software
tight hardware, software and operational constraints
are handled. Hardware attributes
· Run-time performance constraints
Let us understand each model in detail. · Memory constraints
Cost
· Volatility of virtual machine
1) Basic Model : The basic COCOMO model driver
attributes · Computer turnabout time
estimates the software development effort using only
Personnel attributes
Lines of Code. Various equations in this model are -
· Analyst capability
· Software engineer capability
E = a b (KLOC) bb · Applications experience
· Virtual machine experience
D = C b (E) d b · Programing language experience
Project attributes
P = E/D · Use of software tools
· Applications of software
Where E is the effort applied in person-months. engineering methods
· Required development schedule
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 4-9 Software Project Estimation

Consider a software project using semi-detached mode with 30,000 lines of code. We will obtain
estimation for this project as follows -

i) Effort estimation

E = a b (KLOC) bb

i.e. E = 3.0 (30)1.12 where lines of code = 30000 = 30 KLOC

E = 135 person-month

ii) Duration estimation

D = C b (E) d b

= 2.5 (135) 0. 35

D = 14 months

iii) Persons estimation

P = E/D

= 135/14

P = 10 persons approximately

2) Intermediate Model

This is an extension of Basic COCOMO model. This estimation model makes use of set of "Cost driver
attributes" to compute the cost of software.

Now these 15 attributes get a 6-point scale ranging from "very low" to "extra high". These ratings can
be viewed as

The effort multipliers for each cost driver attribute is as given in following table. The product of all
effort multipliers result in "Effort Adjustment Factor" (EAF).

Ratings
Cost drivers
Very low Low Nominal High Very high Extra high

Product attributes

Required software reliability 0.75 0.88 1.00 1.15 1.40

Size of application database 0.94 1.00 1.08 1.16

Complexity of software 0.70 0.85 1.00 1.15 1.30 1.65

Hardware attributes

Run-time performance 1.00 1.11 1.30 1.66

constraints
Memory constraints 1.00 1.06 1.21 1.56

Volatility of virtual machine 0.87 1.00 1.15 1.30

Computer turnabout time 0.87 1.00 1.07 1.15

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 4 - 10 Software Project Estimation

Personnel attributes

Analyst capability 1.46 1.19 1.00 0.86 0.71

Software engineer capability 1.42 1.17 1.00 0.86 0.70

Applications experience 1.29 1.13 1.00 0.91 0.82

Virtual machine experience 1.21 1.10 1.00 0.90

Programming language 1.14 1.07 1.00 0.95

experience
Project attributes

Use of software tools 1.24 1.10 1.00 0.91 0.82

Applications of software 1.24 1.10 1.00 0.91 0.83

engineering methods
Required development 1.23 1.08 1.00 1.04 1.10
schedule
Table 4.4.2
The formula for effort calculation can be -
E = a i (KLOC) bi × EAF person-months
The values for ai and bi for various class of software projects are -

Software project ai bi

Organic 3.2 1.05

Semi-detached 3.0 1.12

Embedded 2.8 1.20

Table 4.4.3
The duration and person estimate is same as in basic COCOMO model. i.e.
D = c b (E) d b months i.e. use values of cb and db coefficients that are in Table 4.4.1

P = E/D persons

Merits of Intermediate Model

1. This model can be applied to almost entire software product for easy and rough cost estimation
during early stage.
2. It can also be applied at the software product component level for obtaining more accurate cost
estimation.

Limitations of Intermediate Model

1. The estimation is within 20 % of actual 68 % of the time.

2. The effort multipliers are not dependent on phases.
3. A product with many components is difficult to estimate.
Example

Consider a project having 30,000 lines of code which is an embedded software with critical area hence
realiability is high. The estimation can be
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 4 - 11 Software Project Estimation

E = a i (KLOC) bi × EAF 4.5 COCOMOII

As reliability is high, EAF = 1.15 (product attribute) COCOMO II is applied for modern software
a i = 2.8 ü development practices addressed for the projects in
ý for embedded software
b i = 1.20þ 1990’s and 2000’s.
\ E = 2 . 8 (30) 1.20 * 1.15 The sub-models of COCOMO II model are –
= 191 person-month
1. Application composition model
db
D = c b (E) ) 0. 32
= 2 . 5 (191 · For estimating the efforts required for the
prototyping projects and the projects in which the
= 13 months approximately
existing software components are used
P = E/D application-composition model is introduced.
· The estimation in this model is based on the
= 191/13
number of application points. The application points
P = 15 persons approximately are similar to the object points.
3) Detailed COCOMO Model · This estimation is based on the level of difficulty of
object points.
The detailed model uses the same equations for
Boehm has suggested the object point productivity
estimation as the Intermediate Model. But detailed
in the following manner.
model can estimate the effort (E), duration (D) and
persons (P) of each of development phases, Developers Very Low Nominal High Very
subsystems, modules. experience low high
and capability
The experimentation with different development
strategies is allowed in this model. CASE Very Low Nominal High Very
maturity low high
Four phases used in detailed COCOMO model are -
Productivity 4 7 13 25 50
1. Requirements planning and product design (RPD) (NOP/Month)

2. Detailed design (DD)

· Effort computation in application-composition model
3. Code and unit test (CUT) can be done as follows -
4. Integrate and test (IT) PM = (NAP(1–%reuse/100)) / PROD
where
The effort multipliers for detailed COCOMO are
PM means effort required in terms of
Very Very
Phases Low Nominal High person-months.
low high
NAP means number of application
RPD 1.80 0.85 1.00 0.75 0.55
points required.
DD 1.35 0.85 1.00 0.90 0.75
% reuse indicates the amount of reused
CUT 1.35 0.85 1.00 0.90 0.75 components in the project. These
IT 1.50 1.20 1.00 0.85 0.70 reusable components can be screens,
reports or the modules used in
Using these detailed cost drivers, an estimate is previous projects.
determined for each phase of the lifecycle. PROD is the object point productivity.
These values are given in the above
table.

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 4 - 12 Software Project Estimation

2. An early design model 3. A reuse model

· This model is used in the early stage of the project
This model considers the systems that have
development. That is after gathering the user
significant amount of code which is reused from the
requirements and before the project development
earlier software systems. The estimation made in
actually starts, this model is used. Hence
reuse model is nothing but the efforts required to
approximate cost estimation can be made in this
integrated the reused models into the new systems.
model.
· There are two types of reusable codes : black box
· The estimation can be made based on the functional
code and white box code. The black box code is a
points.
kind of code which is simply integrated with the
· In early stage of development different ways of new system without modifying it. The white box
implementing user requirements can be estimated.
code is a kind of code that has to be modified to
· The effort estimation (in terms of person month) in some extent before integrating it with the new
this model can be made using the following system, and then only it can work correctly.
formula :
· There is third category of code which is used in
Effort = A ´ size B ´ M reuse model and it is the code which can be
where generated automatically. In this form of reuse the
standard templates are integrated in the generator.
Boehm has proposed the value of coefficient To these generators, the system model is given as
A = 2.94. input from which some additional information
Size should be in terms of Kilo Source Lines Of about the system is taken and the code can be
Code i.e. KSLOC. The lines of code can be generated using the templates.
computed with the help of function point. · The efforts required for automatically the generated
The value of B is varying from 1.1 to 1.24 and code is
depends upon the project. PM = (ASLOC ´ AT/100)/ATPROD
M is based on the characteristics such as where
1. Product reliability and complexity (RCPX)
AT is percentage of automatically generated code.
2. Reuse required (RUSE)
ATPROD is the productivity of engineers in
3. Platform difficulty (PDIF) estimating such code
4. Personnel capability (PERS) · Sometimes in the reuse model some white box code
5. Personnel experience (PREX) is used along with the newly developed code. The
size estimate of newly developed code is equivalent
6. Schedule (SCED)
to the reused code. Following formula is used to
7. Support facilities (FCIL) calculate the effort in such a case –
These characteristics values can be computed on the · ESLOC = ASLOC ´ (1–AT/100) X AAM
following scale -
where

1 6 ESLOC means equivalent number of lines of new

source code.
Very Very
low high
ASLOC means the source lines of code in the
component that has to be adapted.
· Hence the effort estimation can be given as
AAM is adaptation Adjustment multiplier. This factor
PM = 2.94 ´ size B ´ M is used to take into account the efforts required to
reuse the code.
M = RUSE ´ PDIF ´ PERS ´ PREX ´ SCED ´ FCIL

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 4 - 13 Software Project Estimation

4. Post architecture model Team cohesion Represents the working

· This model is a detailed model used to compute the environment of the team.
efforts. The basic formula used in this model is Very low cohesion means
poor communication or
Effort = A ´ Size B ´ M interaction between the team
members and extra high
· In this model efforts should be estimated more means there is no
accurately. In the above formula A is the amount of communication problem and
code. This code size estimate is made with the help team can work in a good
spirit.
of three components –
Process maturity This factor affects the process
1. The estimate about new lines of code that is maturity of the organisation.
added in the program. This value can be computed
using Capacity Maturity
2. Equivalent number of source lines of code Model (CMM) questionnaire,
(ESLOC) used in reuse model. for computing the estimates
CMM maturity level can be
3. Due to changes in requirements the lines of subtracted from 5.
code get modified. The estimate of amount of
· Add up all these rating and then whatever value
code being modified.
you get, divide it by 100. Then add the resultant
The exponent term B has three possible values that value to 1.01 to get the exponent value.
are related to the levels of project complexity. The
· This model makes use of 17 cost attributes instead
values of B are continuous rather than discrete. It
of seven. These attributes are used to adjust initial
depends upon the five scale factors. These scale
estimate.
factors vary from very low to extra high (i.e. from
5 to 0). Cost attribute Type of attribute Purpose
· These factors are –
RELY Product System reliability
that is required
Scale factor for
Description
component B CPLX Product Complexity of
system modules
Precedentedness This factor is for previous
experience of organisation. DATA Product Size of the data
Very low means no previous used from
experience and high means database
the organisation knows the
application domain. DOCU Product Some amount of
documentation
Development flexibility Flexibility in development used
process. Very low means the
typical process is used. Extra RUSE Product Percentage of
high means client is reusable
responsible for defining the components
process goals.
TIME Computer Amount of time
Architecture/risk Amount of risk that is required for
resolution allowed to carry out. Very execution
low means little risk analysis
is permitted and extra high PVOL Computer Volatility of
means high risk analysis is development
made. platform

STOR Computer Memory

constraint

ACAP Personnel Project analyst’s

capability to
analyse the
project

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 4 - 14 Software Project Estimation

PCAP Personnel Programmer 1) Given that, System = Semi detached

capability
Lines of code = 2000 lines = 2 KLOC
PCON Personnel Personnel
continuity \ E = a b (KLOC) bb
PEXP Personnel Programmer’s
experience in E = 3.0 (2) 1.15
project domain
E = 6.65 person-month
LTEX Personnel Experience of
languages and \ D = c b (E) d b
tools that are
used D = 4.8 months
AEXP Personal Analyst’s \ P = E/D
experience in
project domain. P = 1.3 » 1 person
TOOL Project Use of software Thus 1 person can handle this project within
tools
approximately 5 months.
SCED Project Project schedule
compression 2) Given that, System = Embedded
SITE Project Quality of Lines of code = 30,000 lines = 30 KLOC
inter-site and
multi-site \ E = a b (KLOC) bb
working
= 3.6 (30) 1.20
E » 213 person - month
Ex. 4.5.1 Using COCOMO, estimate time required for
the following : D = c b (E) d b
1) A semi-detached model of software project of 2000 lines. = 2.5 (213) 0.32
2) An embedded model of software of 30,000 lines.
3) An organic model of software of one lakh lines. \ D » 14 months
4) An organic model of software of 10 lakh lines. P = E/D
Sol. : To estimate time using basic model of
» 213/14
COCOMO following formula can be used.
» 15 persons.
E = a b (KLOC) bb That means 15 persons can complete this project
where E is the effort in person-month. within approximately 14 months.
3) Given that, System = Organic
D = c b (E) d b
Lines of code = 1 lakh = 100 KLOC
where D is development time in chronological
months. \ E = a b (KLOC) bb

P = E/D = 2.4 (100) 1.05

where P is total number of persons involved in the E » 302 person-month

project. The constants are D = c b (E) d b = 2.5 (302) 0.38
System ab bb cb db \ » 21 months

Organic system 2.4 1.05 2.5 0.38 P = E/D

Semidetached system 3.0 1.12 2.5 0.35 » 302/21
Embedded system 3.6 1.20 2.5 0.32 » 14 persons.
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 4 - 15 Software Project Estimation

That means this project can be completed within 21 Different types of risk
months by 14 persons, approximately, 1. Project risk
4) Given that, System = Organic Project risks arise in the software development
Lines of code = 10 lakh = 1000 KLOC process then they basically affect budget,
schedule, staffing, resources, and requirements.
\ E = a b (KLOC) bb When project risks become severe then the total
cost of project gets increased.
= 2.4 (1000) 1.05
2. Technical risk
» 3390 person - month
These risks affect quality and timeliness of the
D = c b (E) d b
project. If technical risks become reality then
» 2.5 (3390) 0.38 potential design implementation, interface,
verification and maintenance problems gets
» 55 months created. Technical risks occur when problem
\ P = E/D becomes harder to solve.

» 3390/55 3. Business risk

» 61 persons When feasibility of software product is in suspect

then business risks occur. Business risks can be
This project can be completed within 55 months by further categorized as
61 people approximately.
i) Market risk - When a quality software product
is built but if there is no customer for this
4.6 Risk Management
MSBTE : MSBTE : Summer-15, 16, 17, 18, Winter-15, 16 product then it is called market risk (i.e. no
market for the product).
Definition of risk : The risk denotes the uncertainty
that may occur in the choices due to past actions and ii) Strategic risk - When a product is built and if
risk is something which causes heavy losses. it is not following the company’s business
policies then such a product brings strategic
Definition of risk management : Risk management
risks.
refers to the process of making decisions based on an
evaluation of the factors that threats to the business. iii) Sales risk - When a product is built but how
to sell is not clear then such a situation brings
Various activities that are carried out for risk
sales risk.
management are -
iv) Management risk - When senior management
1. Risk identification 2. Risk projection or the responsible staff leaves the organization
3. Risk refinement then management risk occurs.

4. Risk mitigation, monitoring and management. v) Budget risk - Losing the overall budget of the
project is called budget risk.
4.6.1 Software Risks
There are two characteristics of the risks
1. The risk may or may not happen. It shows the
uncertainty of the risks.
2. When risks occur, unwanted consequences or
losses will occur.

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 4 - 16 Software Project Estimation

Project risk Technical risk Business risk

Market risk

Strategic risk

Sales risk

Management risk

Budget risk

Fig. 4.6.1 Categorization of risk

Another categorization of risk proposed by Charette

4.6.2 Risk Identification
is -

Known risks are those risk that are identified after Risk identification can be defined as the efforts
evaluating the project plan. These risks can also be taken to specify threats to the project plan. Risks
identified from other sources such as environment in identification can be done by identifying the known
which the product gets developed, unrealistic dead and predictable risks.
lines, poor requirement specification and software
scope. There are two types of known risks - The risk identification is based on two approaches
predictable and unpredictable risks. 1. Generic risk identification - It includes potential
threat identification to software project.
Predictable risks
2. Product-specific risk identification - It includes
product specific threat identification by
Known risks understanding people, technology and working
environment in which the product gets built.
Normally the risk identification is done by the project
Unpredictable risks
manager who follows following steps -
Fig. 4.6.2
Step 1 : Preparation of risk item check list
Predictable risks are those risks that can be identified
in advance based on past project experience. For The risk items can be identified using following
example : Experienced and skilled staff leaving in known and predictable components
between or improper communication with customer i) Product size - The risk items based on overall
resulting in poor requirement specification. size of the software product is identified.
Unpredictable risks are those risks that can not be ii) Business impact - Risk items related to the
guessed earlier. marketplace or management can be predicted.
For example certain changes in Government policies iii) Customer characteristics - Risks associated with
may affect the business project. customer-developer communication can be
identified.
iv) Process definition - Risks that get raised with the
definition of software process. This category
exposes important risks items because whichever
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 4 - 17 Software Project Estimation

is the process definition made, is then followed These steps help to prioritize the risks. Once the risks
by the whole team. are prioritized then it becomes easy to allocate the
v) Development environment - The risks associated resources for handling them.
with the technology and tool being used for
4.6.4 Risk Assessment
developing the product.
· Risk assessment is done during the project
vi) Staff size and experience - Once the technology
planning.
and tool related risks items are identified it is
· In this phase the risks are identified, analysed and
essential to identify the risk associated with
sufficient highly experienced and skilled staff then prioritized on the basis of analysis.
who will do the development. · The risk assessment is done throughout the project.
It is most needed at the starting phases of project.
vii) Technology to be built - complexity of the system
should be understood and related risk items · The goal of the risk assessment is to prioritize the
needs to be identified. risks that require an attention.

After preparing a risk item checklist a questionnaire Risk identification

is prepared. These set of questions should be · Risk identification is the first step in risk
answered and based on these answers the impact or assessment, which identifies all the different risks
seriousness of particular risk item can be judged. for a particular project.
· Various methods that can be used to identify the
Step 2 : Creating risk components and drivers
list. risks are -
¡ Preparing checklists for identifying the risks,
The set of risk components and drivers list is
¡ Conducting surveys and meetings,
prepared along with their probability of occurrence.
Then their impact on the project can be analysed. ¡ Having brainstorming sessions,
¡ Reviewing of plans, processes, and work
Let us understand which are the risk components and
drivers. products.
· Based on the surveys, Bohem has produced a list of
4.6.3 Risk Projection top 10 risks items. This list helps in identifying the
The risk projection is also called risk estimation. risks in the project.

There are two ways by which risk can be rated Sr.

Risk Item Management Technique
No.

1. Personnel Shortfall Training the people,

Probability that the risk is real Consequences of problems associated recruiting top talent
with the risk people, Key personnel
Fig. 4.6.3 agreement.

The project planner, technical staff, project manager 2. Unrealistic schedule Detailed schedule and
or budget. cost estimation, Software
performs following steps to perform following steps reuse.
for risk projection -
3. Developing wrong Making user survey,
· Establish a scale that indicates the probability of functions. understanding the
risk being real. concepts, adopting
prototyping techniques.
· Enlist the consequences of the risk.
4. Gold Plating i.e. Reviewing the
· Estimate the impact of the risk on the project and
adding features to the requirements,
product. project. prototyping.
· Maintain the overall accuracy of the risk projection 5. Developing wrong Performing prototyping,
in order to have clear understanding of the software user interface. task analysis
that is to be built.
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 4 - 18 Software Project Estimation

6. Requirement changes Incremental · Another approach of risk analysis is making

occur frequently. development. analysis of various things like -
7. ¡ Outcome of various decisions(Decision analysis)
Shortfalls in externally Reference checking,
done tasks. auditing, prototyping. ¡ Risks on various factors such as reliability and
8. Shortfall in externally Reference checking and usability(quality factor analysis)
developed inspections.
¡ Performance constraints(performance analysis).
components.

9. Real-time performance Simulation, modelling, Risk Prioritization

shortfalls. prototyping.
· After risk analysis the impact of each risk on the
10. Straining computer Technical analysis, project can be analysed. Based on this impact risks
knowledge capability. reference checking,
can be prioritised.
prototyping.
· Risk exposure computing is done for prioritising
· Apart from preparing a checklist, other methods of
the risks. Risk exposure is also called as risk
risk identification are decision driver analysis, impact.
assumption analysis and decomposition.
· The risk exposure can be calculated by following
· In decision driver analysis technique, there is
formula,
questioning and analyzing of all the major decisions
Risk Exposure = Probability of occurrence of risk
taken for the project. If the decisions are driven by
*Loss due to unsatisfactory outcome
some non technical factors such as politics or
· Thus risk exposure for each risk from risk table is
marketing then the probability of occurrence of risk
calculated. The total risk exposure of all risks helps
is very high.
in determining the final cost of the project.
· For identifying the risks assumptions about the
project are compared with the pat experiences of 4.6.5 Risk Containment
the project.
· Risk containment means reduction of risk.
· In decomposition technique the large project is
· The project manager and team will be able to
broken down into small parts and analysis is made
identify strategies to minimize or eliminate the risk
in order to identify the risks.
factors.
· The next task after risk identification is risk analysis
· For example - If a project is facing high risk due to
and prioritization.
lack of experience in development platform, then
Risk Analysis the recruiter or hiring expert contractor can control
· Risk analysis is the process in which probability of this risk by hiring the skilled and experienced
occurrence of risk and the corresponding losses are employee for the desired project.
estimated. · Lot of high risk factors can be eliminated or
· If cost models are used for cost and schedule reduced during the risk assessment.
estimation, then the same models can be used to
4.6.6 RMMM Strategy
assess the cost and schedule risk. For example
COCOMO model can be used for to analyse the RMMM stands for risk mitigation, monitoring and
cost and schedule risks. management. There are three issues in strategy for
· Risk analysis can be done by estimating the handling the risk is
worst-case value of size and all the cost drivers. 1. Risk avoidance 2. Risk monitoring
From these values the project cost can be estimated.
3. Risk management.
This will give us the worst-case analysis. Then
using the worst-case effort estimate, the
worst-case schedule can easily be obtained.

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 4 - 19 Software Project Estimation

Risk mitigation 2. To ensure the steps defined to avoid the risk are
Risk mitigation means preventing the risks to applied properly or not.
occur(risk avoidance). Following are the steps to be 3. To gather the information which can be useful
taken for mitigating the risks. for analyzing the risk.
1. Communicate with the concerned staff to find of
Risk management
probable risk.
Project manager performs this task when risk
2. Find out and eliminate all those causes that can
becomes a reality. If project manager is successful in
create risk before the project starts.
applying the project mitigation effectively then it
3. Develop a policy in an organization which will becomes very much easy to manage the risks.
help to continue the project even though some
staff leaves the organization. For example, consider a scenario that many people
are leaving the organization then if sufficient
4. Everybody in the project team should be
additional staff is available, if current development
acquainted with the current development activity.
activity is known to everybody in the team, if latest
5. Maintain the corresponding documents in timely and systematic documentation is available then any
manner. This documentation should be strictly as ‘new comer’ can easily understand current
per the standards set by the organization. development activity. This will ultimately help in
6. Conduct timely reviews in order to speed up the continuing the work without any interval.
work.
7. For conducting every critical activity during Board Questions
software development, provide the additional 1. What is risk projection ? Enlist steps of risk
staff if required. projection. MSBTE : Summer-15, Marks 4

2. Describe RMMM strategy in detail.

Risk monitoring
MSBTE : Summer-15,Winter-15, Marks 4
In risk monitoring process following things must be
3. What is software risk ? Explain types of software
monitored by the project manager,
risks. MSBTE : Summer-16, Marks 4
1. The approach or the behaviour of the team 4. Describe the following with respect to Risk
members as pressure of project varies. assessment :
2. The degree in which the team performs with the i) Risk identification ii) Risk analysis
spirit of “team-work”. iii) Risk prioritization MSBTE : Winter-16, Marks 8
3. The type of co-operation among the team 5. Explain following terms w.r.t. risk management :
members.
i) Risk identification ii) Risk analysis
4. The types of problems that are occurring. MSBTE : Summer-17, Marks 4

5. Availability of jobs within and outside the 6. Enlist and explain different types of Software
organization. Risks. (four points)
The project manager should monitor certain MSBTE : Summer-18, Marks 4
mitigation steps. For example.

If the current development activity is monitored

qqq
continuously then everybody in the team will get
acquainted with current development activity.

The objective of risk monitoring is

1. To check whether the predicted risks really occur

or not.
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 4 - 20 Software Project Estimation

Notes

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

 UNIT- V

5
5.1 Project Scheduling
Software Quality Assurance
and Security
(7) Defined Milestones : Every task or group of tasks
MSBTE : Winter-15, 16, 17, Summer-15, 16, 17, Marks 4 should be associated with a project milestone.
Definition : Project scheduling is an activity the
estimated efforts are distributed across the planned 5.1.2 Work Breakdown Structure
project duration by allocating effort to specific · Work breakdown Structure(WBS) is a process of
software engineering tasks. dividing the complex projects to simpler and
manageable tasks.
In project the scheduling can be done using two
simple activities - · In WBS, the large tasks are broken down into
manageable chunks of work. These chunks can be
1. Determining overall schedule by using different easily examined and analysed.
important milestones.
· The project manager is responsible for creation of
2. Developing detailed schedule for different tasks. WBS.

5.1.1 Basic Principle Construction of Work Breakdown Structure

Following are basic principles used in project (1) The first step in creation of work breakdown
scheduling - structure is to identify the main deliverable of
(1) Compartmentalization : The project is partitioned the project.
or compartmentalized into number of activities, (2) Then the high level tasks are identified and they
actions and tasks. are broken down into smaller chunks of work.

(2) Interdependency : The interdependency of each (3) In the process of breaking down the tasks, one
compartmentalized activity, task and action must be can break them down into different levels of
determined. Some tasks execute in sequence and detail. One can detail a high-level task into ten
some might execute in parallel. sub-tasks while another can detail the same
high-level task into 20 sub-tasks. Thus there is no
(3) Time Allocation : For each scheduled task, some
standard rule for breaking down of task into
number of work units must be allocated. The start
chunks. In general there is a simple rule is that -
date and end date of each allocated task must be
The smallest tasks of WBS is should not be
specified.
smaller than two weeks worth of work.
(4) Effort Validation : The number of people Another rule is - no task should be smaller than 8
allocated for the scheduled tasks must be validated hours of work and should not be larger than 80
by the project manager. hours of work.
(5) Defined Responsibilities : Every task that is (4) There are many forms of displaying the work
scheduled should be assigned to specific team breakdown structure - it can be in tree like form,
member. table or list form. For example -
(6) Defined Outcomes : Every scheduled task must
have definite outcome.

®
(5 - -1)An up thrust for knowledge
TECHNICAL PUBLICATIONS
TM
Software Engineering 5-2 Software Quality Assurance and Security

Project

Task 1 Task 2 Task 3

Sub task 1.1 Sub task 1.2 Sub task 1.3

Work package 1.1.1 Work package 1.1.2 Work package 1.1.3

Fig. 5.1.1 Work breakdown structure in tree form

Example of WBS : The work breakdown structure for a simple product development is as shown
below -

1.4 (a)
Technical 1.6 (a)
risks Implementation

1.1
1.2 1.3 1.5
Checking
Scoping the Product Proof of Integrate a,b
feasibility
product planning product
of product

1.4 (b) 1.6 (b)

Technical Implementation
risks

1.7
Customer
feedback

Fig. 5.1.2 Work breakdown structure in tree form

5.1.3 Activity Network and Critical Path Method

Bar charts and activity networks are graphical representation of project schedule. The beginning and
end of the activity, responsible staff for corresponding activity is shown by bar chart.

Activity network show dependencies between different activities. There are some automating project
management tools using which bar chart and activity network can be generated. These tools require
database of project information as an input.

Ex. 5.1.1 Consider, some hypothetical tasks, duration and dependencies. Draw the activity network and find the critical
path.

Task Duration Dependencies

T1 10

T2 15 T1(M1)

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 5-3 Software Quality Assurance and Security

T3 15 T1(M2)

T4 7 T1,T2(M3)

T5 20 T1(M1)

T6 5 T4,T5(M4)

T7 4 T6(M6)

T8 8 T7(M5)

T9 10 T6,T8(M7)

T10 12 T9(M8)

Sol. : The T1, T2, … represent various tasks. The milestones of various tasks is shown by M1, M2, … The activity
network for these activities can be as shown below.

M6 T7

T5 M4 T6 M5

T8
T1 M1 T2 M2 T3

M7
START

T9
M3

M8
T4

END T10

Fig. 5.1.3 Activity network

The minimum amount of time required by the project can be computing the longest possible path to
reach from begin to end. This path is referred as the critical path in the project and the activities along
this path are referred as the critical activities. In Fig. 5.1.3 critical path is shown by thick edge.

Ex. 5.1.2 For a software project different activities and their durations are listed as below. Draw the activity network and
find the critical path.

Task T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12

Duration 8 15 15 10 10 5 20 25 15 15 7 10
(in days)

Dependencies – – T1 – T2 , T4 T1 , T2 T3 T4 T3 , T6 T5 , T7 T9 T11

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 5-4 Software Quality Assurance and Security

Sol. :

8 days 15 days 20 days 15 days

T1 T3 T7 T10

15 days 5 days 15 days 7 days 10 days

START T2 T6 T9 T11 T12

10 days 10 days
END
T4 T5

25 days
T8

Fig. 5.1.4 Activity chart

A thick line denotes the critical path. A critical path ¡ Assign time and cost to each activity.
is a longest possible path which starts from the ¡ Compute critical path.
beginning and reaches at the end and which requires ¡
Use network to help plan, schedule, monitor
minimum amount of time.
and control the project.
5.1.4 Scheduling Techniques · Example -
· The formula used in PERT to calculate number of
· There are two commonly used scheduling
working days is based on three point estimate.
techniques - PERT and CPM.
· The three point estimates are optimistic, most likely
· The PERT stands for Project management and
and pessimistic estimates.
Review Technique. This technique is used for the
projects where time needed to complete different · Formula is
activities are not known. PERT weighted average
· The CPM stands for Critical Path Method. This Optimistic time+ 4 ´ Most likely time
technique is used in conjunction with PERT and is + Pessimistic time
used for managing the well defined activities of the =
6
project.
· Example : Given that
· The PERT and CPM technique is used for -
Optimistic time = 6 days
¡ Prediction of deliverables.
¡
Most likely time = 9 days
Planning resource requirements
¡ Controlling resource allocation Pessimistic time = 12 days
¡ Internal and external program review then
¡ Performance evaluation 6 + ( 4 ´ 9) + 12
PERT weighted average = =9
· Various framework activities in PERT/CPM are - 6
¡ Define the project. The project should have · Thus it would be 9 days using PERT.
single start activity and single finish activity.
· The main advantage of PERT is that it attempts to
¡ Develop relationships among the activities. address the risk associated with duration estimates.
¡ Draw the network diagram for connecting all
the activities.
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 5-5 Software Quality Assurance and Security

Difference between PERT and CPM 2. Evaluate results of all the project reviews.

Sr. 3. Compare 'actual start date' and 'scheduled start

PERT CPM
No. date' of each of the project task.
1. PERT is a project CPM is a statistical 4. Determine if the milestones of the project is
management technique technique of project achieved on scheduled date.
used to manage management that
uncertain activities of manages well defined 5. Meet informally the software practioners. This
project. activities. will help the project manager to solve many
2. This technique of A method to control problems. This meeting will also be helpful for
planning and control of cost and time. assessing the project progress.
time.
6. Assess the progress of the project quantitatively.
3. This technique is event This technique is · Thus for tracking the schedule of the project the
oriented. activity oriented.
project manager should be an experienced person.
4. It is non repetitive in It is repetitive in In fact project manager is the only responsible
nature. nature.
person who is controlling the software project.
· When some problems occur in the project then
Board Questions addition resources may be demanded, skilled and
1. List four basic principles of project scheduling. experienced staff may be employed or project
MSBTE : Summer-15,16, Winter-15, Marks 4 schedule can be redefined.
2. Differentiate between PERT and CPM.
5.2.1 Time Line Chart (Gantt Chart)
MSBTE : Summer-15, Winter-16, 17, Marks 4
· In software project scheduling the timeline chart is
3. With an example, explain how CPM and PERT
created. The purpose of timeline chart is to
are useful in software project management.
emphasize the scope of individual task. Hence set of
MSBTE : Winter-15, Marks 4
tasks are given as input to the time line chart.
4. What is the concept of task network ?
· The time line chart is also called as Gant chart.
MSBTE : Summer-17, Marks 4
· The time line chart can be developed for entire
5. Write meaning of PERT and CPM. project or it can be developed for individual
MSBTE : Summer-17, Marks 4
functions.
6. What is project scheduling ? · In time line chart
MSBTE : Winter-17, Marks 4
1) All the tasks are listed at the leftmost column.
2) The horizontal bars indicate the time required by
5.2 Project Tracking
the corresponding task.
MSBTE : Winter-17, Summer-16, 18, Marks 8

· Project schedule is the most important factor for 3) When multiple horizontal bars occur at the same
software project manager. It is the duty of project time on the calendar, then that means
manager to decide the project schedule and track concurrency can be applied for performing the
the schedule. tasks.
· Tracking the schedule means determine the tasks 4) The diamonds indicate the milestones.
and milestones in the project as it proceeds. · In most of the projects, after generation of time line
· Following are the various activities conducted chart the project tables are prepared. In project
during tracking of the project schedule - tables all the tasks are listed along with actual start
and end dates and related information.
1. Conduct periodic meetings. In this meeting
various problems related to the project get
discussed. The progress of the project is reported
to the project manager.
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 5-6 Software Quality Assurance and Security

Example

Sept. Oct. Nov. Dec. Jan.

Task
6 13 20 27 3 10 17 24 31 7 14 21 28 4 11 18 25 1 8 15 22

1. 2 Software development
1. 2. 1 Requirements analysis
1. 2. 2 Architectural design
1. 2. 3 Procedural design
1. 2. 4 Code
1. 3 Testing
1. 3. 1 Unit test
1. 3. 2 Integration test
1. 3. 3 Acceptance test
1. 4 Operations
1. 4. 1 Packaging
1. 4. 2 Customer training

Fig. 5.2.1 Time line chart

Project table

Tasks Planned start Actual start Planned end Actual end Effort assignment
Requirement analysis 6 Sept’05
th 6 Sept’05
th 20 Sept’05
th 22 nd Sept’05 Jayashree, Padma, Lucky
Architectural design 27 Sept’05
th 27 Sept’05
th 3 Oct’05
rd 7 Oct’05
th Trupti, Varsha
Procedural design 10 Oct’05
th 12 Oct’05
th 24 Oct’05
th 25 Oct’05
th Varsha, Sachin, Devendra
M M M M M M
Customer training 1st Jan’06 4th Jan’06 22nd Jan’06 25th Jan’06 Smita, Yogita

5.2.2 Earned Value Analysis

· The Earned Value Analysis (EVA) takes into consideration the project context for planned and actual
expenditure.
· This analysis is made to find out project scope, schedule and resource characteristics.
· The EVA acts as a measure for software project progress.
· Various measures are determined during EVA. These measures are -
1) Planned Value (PV) : It denotes the planned cost of the work. The planned value is developed by
first determining all of the work, that must be accomplished for successful project result.
2) Actual Cost (AC) : It represents the actual amount that the business has to expend on the project.
AC = å Efforts expended on work task that have been completed by time t.
3) Earned Value (EV) : It is project manager’s estimate of the amount of originally budgeted work
completed.
4) Budget At Completion (BAC) : It represents total budget for the project.
5) Schedule Variance (SV) : It indicates the status of the schedule. It represents whether work is
ahead or behind the plan. If SV is negative the project is behind schedule, if it is positive then
project is ahead of schedule. If SV is equal to zero, then project is on schedule.
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 5-7 Software Quality Assurance and Security

6) Cost Variance (CV) : It is the difference between 27

= ´ 50000
/ / = 13, 500
earned value and actual cost. //
100

\ The earned value is $ 13,500

If CV = 0 then project is on budget.

If CV < 0 then project is over budget Board Questions

If CV > 0 then project is under budget 1. List different ways in which the project schedule
can be tracked. MSBTE : Summer-16, Marks 4
7) Schedule Performance Index (SPI) : It is a
measure of schedule efficiency on a project. If 2. What is project scheduling and tracking ? State
SPI = 1.0, project is on schedule. four reasons why project deadlines cannot be
met ? MSBTE : Summer-16, Marks 8
If SPI is greater than 1 then project is ahead of
the schedule. 3. Explain the concept of Gantt chart.
MSBTE : Winter-17, Marks 4
IF SPI is less than 1 then project is getting
delayed and it is behind the schedule. 4. Explain different activities done to track the
software. MSBTE : Summer-18, Marks 4
8) Cost Performance Index (CPI) : It is a measure
of cost efficiency on a project. The value 1.0
represents that project is within the given budget. 5.3 Software Quality Management Vs.
Software Quality Assurance
If CPI < 1.0 then that means project is over
· Definition of Quality : The International
budgeted.
Organization for Standardization (ISO) defines
If CPI > 1.0 then that means project is under quality as the totality of characteristics of an entity
budgeted and we require most cost to that bear on its ability to satisfy stated or implied
accomplish the project. needs.
Formula used during (EVA) : · The project quality management is a process which
ensures that the project will satisfy the needs for
PV = Planned Completion (%)
which it was undertaken.
* Budget At Completion (BAC) · The main principle of project quality management is

EV = Actual Completion (%) * BAC to ensure the project will meet or exceed
stakeholder's needs and expectations.
SV = EV – PV
· The project team must develop a good relationship
CV = EV – AC with key stakeholders.
· The project quality management is performed using
SPI = EV/PV
following three key processes.
CPI = EV/AC 1. Planning Quality Management

2. Performing Quality Assurance

Ex. 5.2.1 Mr. Koushan is the project manager on a
project to build a new cricket stadium in Mumbai, India. 3. Controlling Quality
After six months of work, the project is 27 % complete. At
the start of the project, Koushan estimated that it would
Quality Management
cost $ 50,000.000, What is the Earned value ?
Sol. : The formula for Earned value is -

Earned value = % of work × Budget

Planning Quality Quality Controlling
= 27 % × 50000 Management Assurance Quality

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 5-8 Software Quality Assurance and Security

5.4 Phases of Software Quality Assurance

MSBTE : Winter-16, 17, Summer-15, 16, 17, 18, Marks 8 Defects occurred
during software
· Definition of quality assurance : It is planned and development process
systematic pattern of activities necessary to provide
a high degree of confidence in the quality of a Collection of defects
product. It provides quality assessment of the occurs at two stages

quality control activities and determines the validity

of the data or procedures for determining quality. Defects occurred after
· The quality assurance consists of set of reporting delivering the product
to end - user
and auditing functions.
· These functions are useful for assessing and
Fig. 5.4.1
controlling the effectiveness and completeness of
Software Quality Assurance Activities
quality control activities.
· The goal of quality assurance is to ensure the Let us list out the SQA activities conducted by SQA
management of data which is important for product group.
quality.
1. Create a SQA plan.
Statistical Quality Assurance
A SQA plan is developed while planning the project.
· Statistical software quality assurance is a simple
Quality assurance activities are conducted that are
concept which represents that changes in the
indicated in this plan. This plan basically
software can be made in order to improve those
· Identifies evaluations to be performed.
elements of the process that introduce error.
· Audits and reviews to be performed, standards that
· Statistical
software quality assurance can be
should be adopted for the project.
performed with the help of following steps -
1. Collect the information about software defects. · Procedures for error reporting and tracking.
Categorize them. · It also specifies documents to be produced by SQA
2. Make an attempt to trace each defect to its root group.
cause. · Amount of feedback provided to the software
3. Isolate the vital few causes of the major source project team.
of all errors by using the 80-20 principle(known
2. Participates in description of software process.
as Pareto principle). This principle is “80 % of
the defects can be traced to 20 % of all possible The process selected by the software team is
causes”. reviewed by the SQA group. This review is for
4. Then move to correct the problems that have · Process description to ensure that it follows the
caused the defects organizational policy.

Software Quality Assurance (SQA) tasks are associated with

Software engineers SQA group

(Responsible for developing (Responsible for performing
the product) quality assurance planning,
oversight, record keeping,
analysis and reporting)

Fig. 5.4.2
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 5-9 Software Quality Assurance and Security

· Internal software standards. 6. Prepare any four software quality assurance

· Some standards that are adopted by the guidelines and describe them.
organization. MSBTE : Summer-18, Marks 4

3. Reviews software engineering activities.

5.5 Software Quality Control
The SQA group identifies and documents the MSBTE : Summer-17, Marks 4
processes. The group also verifies the correctness of
· Quality control is a process in which activities are
software process.
conducted in order to maintain the quality of
product. These activities are series of inspections,
4. Authenticate designated software work
products. reviews and tests used throughout the software
process. These activities ensure whether each work
The SQA group performs following tasks -
product is satisfying the requirements imposed on
· Reviews selected work product it.
· Identifies the process · While applying the quality control there should be a
· Documents them feedback loop to the process which generates the
work product. With the help of such feedback we
· Tracks deviations
can tune the process if it does not satisfy the
· Verifies the correctness made in the processes requirements. The feedback loop helps in
· Regular reporting of results of its work to the minimizing the defects in the software product.
project manager. · The quality control activities can be fully automated
or it can be completely manual or it can be a
5. Ensure the deviations in software work. combination of automated tools and manual
Document work products
procedures.
The deviations in software work are identified from
project plan. These processes are identified and Board Question
handled according to documented procedure. 1. What is quality control ? MSBTE : Summer-17, Marks 4

6. Identify any noncompliance and reports to

senior management. 5.6 Quality Evaluation Standards
MSBTE : Winter-15, 16, 17, Summer-15, 16, 17, 18, Marks 8
Non compliance items are identified and pursued
until they get resolved. The periodic reporting about 5.6.1 Six Sigma
it is done to project manager.
Six sigma is widely used statistical software quality
assurance strategy. It is a business driven approach to
Board Questions
process improvement, reduced costs and increased
1. What steps are required to perform statistical profit. The word “six sigma” is derived from six
SQA ? MSBTE : Summer-15, Marks 4 standard deviations - 3.4 defects per million
2. What is Software Quality Assurance ? What are occurrences. Six Sigma originated at Motorola in the
the activities carried out in SQA. early 1980s.
MSBTE : Summer-16, Marks 4
There are three core steps in six sigma method -
3. List various activities of SQA.
Define - The customer requirements, project goals
MSBTE : Summer-17, Marks 4
and deliverables are defined by communicating the
4. What is Quality Assurance ? Describe various customers.
SQA activities. MSBTE : Winter-16, Marks 8
Measure - The existing process and its output is
5. Explain about software quality assurance. measured in order to determine current quality
MSBTE : Winter-17, Marks 4 performance.
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 5 - 10 Software Quality Assurance and Security

Define Measure Analyze Improve Control

Fig. 5.6.1 Six sigma framework

Analyze - In this phase defect metrics are analyzed in operation. This process is called registration to ISO
order to determine the few causes. 9000.

If an improvement is needed to an existing software · On successful registration, the company gets a

then there are additional two methods in six sigma - certification from accreditation bodies of ISO. Such a
company is then called “ISO certified company”.
Improve - By eliminating the root causes of defects
· ISO 9001:2000 is a quality assurance standard which
the process can be improved.
is applied to software engineering systems.
Control - The process can be controlled in such a · It focuses on process flows, customer satisfaction,
way that the causes of defects can not be and the continual improvement of quality
reintroduced. management systems.
These steps can sometimes be referred as DMAIC. · ISO 9001:2000 specifies requirements for a quality

For a newly developing software, some organizations system that can be applied to any size or type of
are suggesting following two alternating steps - organization.
· The guideline steps for ISO 9001:2000 are
Design - In this step avoid root causes of defects and
¡ Establish quality management system - Identify
meet the customer requirements.
and manage the processes in the quality
Verify - To verify the process, avoid defects and management system.
meet customer requirements. ¡ Document the quality management system
These steps can sometimes be referred as DMADV. ¡ Support the quality
¡ Satisfy the customers
5.6.2 ISO for Software
¡ Establish quality policy
· In order to bring quality in the product and service,
¡ Conduct quality planning
many organizations are adopting the quality
assurance system. ¡ Control quality systems
· The quality assurance systems are the organizational ¡ Perform management reviews
structures that are used to bring quality in ¡ Provide quality resources
responsibilities, procedures, processes and resources.
¡ Provide quality personnel
· ISO 9000 is a family of quality assurance system. It
¡ Provide quality infrastructure
can be applied to all types of organizations. It
¡ Provide quality environment
doesn’t matter what size they are or what they do.
It can help both product and service oriented ¡ Control realization planning
organizations to achieve standards of quality. ¡ Control customer processes
· ISO 9000 is maintained by ISO, the International ¡ Control product development
Organization for Standardization and is
¡ Control purchasing functions
administered by accreditation and certification
¡ Control operational activities
bodies.
· In ISO 9000, company’s quality system and ¡ Control monitoring devices
operations are scrutinized by third-party auditors ¡ Control non confirming products
for a complaince to the standard and effective ¡ Analyze quality information
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 5 - 11 Software Quality Assurance and Security

¡ Make quality improvement Level 3 : Defined - The process is standardized,

· The ISO 9000 helps in creating organisational documented and followed. All the projects use
quality manuals. These quality manuals identify the documented and approved version of software
organisational quality processes. process which is useful in developing and
· Using these quality manuals, the project quality supporting software.
plan can be prepared for every individual project. Level 4 : Managed - Both the software process and
Thus project quality management can be done. product are quantitatively understood and
This is illustrated by following Fig. 5.6.2. controlled using detailed measures.
Level 5 : Optimizing - Establish mechanisms to
ISO 9000 quality plan and implement change. Innovative ideas
model
and technologies can be tested.
Converted to
Thus CMM is used for improving the software
Organisational Defines Organisational
quality manuals quality process project.

Project n Comparison between ISO and SEI CMM Models

quality plan Works
for
Creates Project 3
quality plan
Sr. No. ISO CMM
Project 2
quality plan Project quality
management
Project 1 1. ISO 9001 addresses In CMM, emphasis is
quality plan
minimum criteria for on continuous process
an acceptable quality improvement.
system.
Supports

2. ISO 9001 focuses on CMM focuses strictly

Fig. 5.6.2 ISO 9000 helps in quality management hardware, software, on software.
processed material
5.6.3 CMMI and services.

· The Software Engineering Institute (SEI) has 3. The basis of ISO 9001 The basis of CMM is :
developed a comprehensive process meta-model is : "Say what you do "Say what you do and
emphasizing process maturity. It is predicated on a and do what you do what you say".
say."
set of system and software capabilities that should
be present when organizations reach different levels
4. Servicing activities are CMM does not have
of process capability and maturity. considered as separate maintenance as a
· The Capability Maturity Model (CMM) is used in maintenance process separate process.
in ISO.
assessing how well an organization’s processes
allow to complete and manage new software
5. ISO 9001 maintains a The CMM emphasizes
projects. quality record the need to record
· Various process maturity levels are document which information for later
clearly shows whether use in the process and
Level 1 : Initial - Few processes are defined and or not required for improvement of
individual efforts are taken. quality is achieved. the process.
This document also
Level 2 : Repeatable - To track cost schedule and indicates whether or
functionality basic project management not existing quality
system operates
processes are established. Depending on earlier effectively.
successes of projects with similar applications
necessary process discipline can be repeated.

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 5 - 12 Software Quality Assurance and Security

Optimizing

Managed

Defined

Repeatable

Initial

Fig. 5.6.3

By providing software security - the integrity,

Board Questions
authentication and availability is provided to the
1. Describe six sigma for software engineering.
software system.
MSBTE : Summer-15,18, Marks 4

2. Explain CMMI model with neat diagram. Basic Principles of Software Security
MSBTE : Summer-15,Marks 8 1. Protection from disclosure
3. Give the outline that defines basic elements of ISO 2. Protection from alteration
9001 : 2000 for software quality assurance.
3. Protection from destruction
MSBTE : Winter-15, Marks 4
4. Who is making the request
4. What is six sigma ? Describes the core steps of
DMAIC in detail. MSBTE : Winter-15, Marks 4
5. What rights and privileges does the requester
have
5. What is CMMI ? State two objectives of CMMI.
Briefly explain the CMMI maturity levels. 6. Ability to build historical evidence
MSBTE : Summer-16, Marks 8 7. Management of configuration, sessions and
6. Explain CMMI with its levels and neat diagram. errors/exceptions
MSBTE : Winter-16, Marks 4
5.8 Introduction to DEVOPs
7. What is philosophy of six sigma ? Explain six
sigma strategies. MSBTE : Summer-17, Marks 8 Definition : Devops is a practice in which
development and operation engineers participate
8. Describe six sigma for software engineering.
together in entire lifecycle activities of system
MSBTE : Winter-17, Marks 4
development from design, implementation to product
9. State eight benefit of ISO standards. support.
MSBTE : Winter-17, Marks 4
· The term Devops is derived from "Software
10.Explain different levels of Capability Maturity DEVelopment " and "information technology
Model Integration technique. (CMMI) OPerationS".
MSBTE : Summer-18, Marks 8 · Devops promotes a set of processes and methods
from the three department Development, IT
5.7 Software Security operations and Quality assurance that communicate
and collaborate together for development of
Software security is a concept which is implemented
software system.
to protect software against malicious attack and other
hacker risks so that the software continues to function
correctly under such potential risks.

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 5 - 13 Software Quality Assurance and Security

2. Fast delivery of product.

3. Lower failure rate of new releases.
Development Quality
assurance 4. Shortened lead time between fixes.
5. Faster mean time to recovery.
6. Increases net profit of organization.
7. To standardize development environment.
Devops
8. To reduce work in progress.
Operations
9. To reduce operating expenses.

Fig. 5.8.1 10. To set up automated environment.

Need for DEVOPs Benefits

· Devops enhances the organization's performance, Various benefits of Devops are -
improves the productivity and efficiency of · Technical Benefits
development and operations teams. 1. Continuous software delivery is possible
· Bringing the two teams together centralizes the
2. There is less complexity to manage the
responsibility on the entire team and not specific
project.
individuals working.
· The problems in the project gets resolved faster.
· Devops is more than just a tool or a process change.
· Cultural benefits
It inherently requires an organizational culture shift.
1. The productivity of teams get increased.
· This cultural change is especially difficult, because
of the conflicting nature of departmental roles : 2. There is higher employee engagement.

1. Operations - seeks organizational stability; 3.There arise greater professional development

opportunities.
2. Developers - seek change; · Business benefits
3. Testers - seek risk reduction. 1. The faster delivery of the product is possible.
· Adoption of Devops is driven by various factors. 2. The operating environment becomes stable.
These factors are -
3. The communication and collaboration gets
1. Demand for an increased rate of production improved among the teams members and
releases - from application and business unit customer.
stakeholders. 4. More time is available for innovation rather
2. Increased usage of data center automation and than fixing and maintaining.
configuration management tools.
3. Use of agile and other development processes 5.9 Secure Software Engineering
and methods. · Secure Software engineering is concerned with
4. Increased focus on test automation and developing and maintaining software systems that
continuous integration methods. behave reliably and efficiently by satisfying all the
5. Wide availability of virtualized and cloud requirements of its customers.
infrastructure. · The secure software -
(1) prevents loss of data.
Goals
(2) prevents premature leaks of data.
The Goals of Devops are as follows -
(3) Prevents downtime of resources.
1. To make simple processes increasing
programmable and dynamic.
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering 5 - 14 Software Quality Assurance and Security

Secure Software Engineering Life Cylce · It is better to integrate security concerning activities
· A Software Development Life Cycle (SDLC) is a across the SDLC to help discover and reduce
framework that defines the process used by vulnerabilities early, effectively building security in.
organizations to build an application. Over the
·A Secure SDLC process ensures that security
years, multiple standard SDLC models have been
assurance activities such as penetration testing, code
proposed (Waterfall, Iterative, Agile, etc.) and used
review, and architecture analysis are an integral
in various ways to fit individual circumstances.
part of the development effort.
· In general, SDLCs include the following phases:
· The primary advantages of secure software
1. Planning and requirements. development Life cycle is -
2. Architecture and design.
(1) More secure software as security is a
3. Test planning. continuous concern.
4. Coding.
(2) Awareness of security considerations by
5. Testing and results. stakeholders.
6. Release and maintenance.
(3) Early detection of flaws in the system.
· In the past, it was common practice to perform
security-related activities only as part of testing. (4) Cost reduction as a result of early detection
This technique usually resulted in a high number of and resolution of issues.
issues discovered too late. (5) Overall reduction of business risks for the
organization.

qqq

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

 SUMMER - 2015
Software Engineering Solved Paper
Semester - IV (Civil) (21415)

Time : 3 Hours] [Total Marks : 100

Note : 1) All questions are compulsory.

2) Answer each next main question on a new page.

3) Illustrate your answers with neat sketches wherever necessary.

4) Figures to the right indicate full marks.

5) Assume suitable data, if necessary.

Q.1 Answer any five of the following : 20

a) Explain software engineering as a layered technology approach.

b) Enlist core principles of software engineering practice.
c) Describe data objects and data attributes.
d) List four objectives of testing.
e) List four basic principles of project scheduling.
f) What steps are required to perform statistical SQA ?
g) State any four attributes of a good software.
Q.2 Answer any four of the following : 16

a) Differentiate between waterfall model and incremental model.

b) What is SRS ?
c) Write importance of analysis modeling.
d) State eight characteristics of software bugs.
e) Enlist the features of SCM.
f) Describe six sigma for software engineering.
Q.3 Answer any four of the following : 16

a) What do you mean by process framework ? Explain with suitable diagram.

b) Write four drawback of RAD model.
c) Explain deployment principle.
d) What are the characteristics of good design ?
e) Differentiate between validation and verification.
f) What is risk projection ? Enlist steps of risk projection.
Q.4 Answer any four of the following : 16

a) Explain different decomposition techniques.

®
(S - -1)An up thrust for knowledge
TECHNICAL PUBLICATIONS
TM
Software Engineering S-2 Solved Board Question Papers

b) Describe integration testing.

c) What is DFD ? Explain level 1 DFD with example.
d) Explain cardinality and modality with example.
e) Explain spiral model with neat diagram.
f) Describe Agile process models in detail.
Q.5 Answer any two of the following : 16

a) Describe eight principles of good planning.

b) With neat diagram explain translation of analysis model into design model.
c) Explain CMMI model with neat diagram.
Q.6 Answer any four of the following : 16

a) Compare PSP and TSP.

b) List seven tusk of requirement engineering.
c) Differentiate between alpha and beta testing.
d) Compare white box and black box testing.
e) Describe RMMM strategy in detail.
f) Differentiate between PERT and CPM.

WINTER - 2015
Software Engineering Solved Paper
Semester - IV (Civil) (15116)

Time : 3 Hours] [Total Marks : 100

Note : 1) All questions are compulsory.

2) Illustrate your answers with neat sketches wherever necessary.

3) Figures to the right indicate full marks.

4) Assume suitable data, if necessary.

5) Preferably write the answers in sequential order.

Q.1 A) Attempt any THREE of the following : 12

a) Describe the characteristics of software.

b) Briefly explain software engineering as a layered technology.
c) With reference to requirement engineering, explain
i) Inception and ii) Elicitation
d) With reference to software design give the meanings of
i) Modularity ii) Functional independence iii) Refactoring iv) Information hiding

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering S-3 Solved Board Question Papers

b) Answer any ONE of the following : 6

i) With a neat diagram, explain the nature and general steps of spiral model. Also give its advantages and
disadvantages.ii)Explain the various elements of analysis modeling in detail.
Q.2 Answer any four of the following : 16

a) Define PSP and TSP. Give advantages of TSP.

b) Explain the features of Agile software development approach.
c) In which situation RAD model is applicable ? Give its advantages and disadvantages.
d) Describe the principles of deployment.
e) Explain PSPEC with an example.
f) Draw level 'O' and level 'I' DFD for library management system. Make suitable assumptions.
Q.3 Attempt any FOUR of the following : 16

a) Explain the basic process framework activities.

b) Briefly describe the principles of communication.
c) Briefly describe the principles of coding.
d) With a neat diagram explain analysis model.
e) Explain domain analysis with a neat diagram.
f) Explain unit testing.
Q.4 A) Attempt any THREE of the following : (12)
a) Differentiate between alpha-testing and beta-testing.
b) Describe the following debugging strategies :
i) Brute force ii) Back tracking
c) With an example, explain how CPM and PERT are useful in software project management.
d) Give the outline that defines basic elements of ISO 9001 : 2000 for software quality assurance.
B) Answer any ONE : 6

a) Explain the basic principles of project scheduling.

b) Explain the McCall's Quality factors.
Q.5 Answer any TWO of the following : 16

a) Explain the core principles of software engineering in detail.

b) Explain in detail RMMM strategy.
c) What is six sigma ? Describes the core steps of DMAIC in detail.
Q.6 Answer any FOUR of the following : 16

a) Explain white box testing.

b) Explain Top-Down integration testing.
c) Describe the attributes of a good test.
d) Why do the software projects fail ? Give reasons.
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering S-4 Solved Board Question Papers

e) Describe the four elements of software configuration management system.

SUMMER - 2016
Software Engineering Solved Paper
Semester - IV (Civil) (15162)

Time : 3 Hours] [Total Marks : 100

Note : 1) All questions are compulsory.

2) Answer each next main question on a new page.

3) Illustrate your answers with neat sketches wherever necessary.

4) Figures to the right indicate full marks.

5) Assume suitable data, if necessary.

Q.1 A) Attempt any three of the following : 12

a) Define software. State three characteristics of software.

b) What is software coding ? State three principles of code validation.
c) Describe the terms : Analysis Modeling and Design Modeling.
d) Differentiate between Prescriptive Process Modell and Agile Process Model (any four points).
Q. B) Attempt any one of the following : 6

a) Describe the layered technology approach of Software Engineering.

b) Draw a dataflow diagram level 0 and level 1 for a Book Publishing House.
Q.2 Attempt any four of the following : 16

a) Define the terms software process, software product, software work product and software engineering.
b) What is SRS ? Explain importance of SRS.
c) What is domain analysis ? Explain with suitable examples.
d) Describe the relationship between systems engineering and software engineering.
e) Draw a use case diagram for a Bank Management System.
f) What is Waterfall Model ? State the practical situations in which it can be used.
Q.3 Attempt any four of the following : 16

a) State and explain any four types of software.

b) What is Requirements Elicitation ? What are the problems faced in eliciting requirements ?
c) Explain the importance of SRS.
d) What is Data Modeling ? Explain the terms cardinality and modality.
e) Draw a use case diagram for music system.

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering S-5 Solved Board Question Papers

Q.4 A) Attempt any three of the following : 16

a) What aspects of the software are tested in Unit Testing ?

b) State any four basic principles to be followed for project scheduling.
c) Define the terms : Software Reliability and Software Availabiliy.
d) Compare Alpha Testing and Beta Testing.
Q.4 B) Attempt any one of the following : 6

a) What are the activities involved in SCM ?

b) What is Software Quality Assurance ? What are the activities carried out in SQA.
Q.5 Attempt any two of the following : 16

a) What is Software deployment ? State the principles to be followed while preparing to deliver the software
increment.
b) What is project scheduling and tracking ? State four reasons why project deadlines cannot be met ?
c) What is CMMI ? State two objectives of CMMI. Briefly explain the CMMI maturity levels.
Q.6 Attempt any four of the following : 16

a) Compare top - down and bottom - up approach used for integrating testing.
b) Describe different debugging strategies.
c) What is software risk ? Explain types of software risks.
d) List different ways in which the project schedule can be tracked.
e) Compare software verification and software validation.

WINTER - 2016
Software Engineering Solved Paper
Semester - IV (Civil) (16117)

Time : 3 Hours] [Total Marks : 100

Note : 1) All questions are compulsory.

2) Answer each next main question on a new page.

3) Illustrate your answers with neat sketches wherever necessary.

4) Figures to the right indicate full marks.

5) Assume suitable data, if necessary.

6) Mobile Phone, Pager and any other Electronic Communication devices are not permissible in
Examination Hall.
Q.1 A) Answer any three of the following : 12

a) Describe any four categories of software.

b) State and describe six principles of communication practices.
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering S-6 Solved Board Question Papers

c) With neat diagram, describe inputs and output of domain analysis.

d) Write any four features of Agile Software Development approach.
B) Answer any one of the following : 6

a) With neat diagram, explain RAD model with its advantages and disadvantages. (2 each)
b) Draw DFD level 0 and level 1 for Hotel management system.
Q.2 Answer any four of the following : 16

a) Explain process framework with suitable diagram.

b) Describe in brief four level testing process in test execution.
c) Differentiate between cardinality and modality. (Any four points)
d) Differentiate between waterfall and incremental model. (any four points)
e) Explain following with reference to design concepts in design modeling.i) Abstractionii) Functional independence
f) Explain software engineering as a layered technology approach with neat diagram.
Q.3 Answer any four of the following : 16

a) Describe Team Software Process (TSP) model in detail.

b) Describe dour principles of analysis modeling.
c) Explain general format of Software Requirement Specification (SRS).
d) Describe Data Dictionary. Write any four advantages.
e) Explain :i) Component - level design elementsii) Deployment level design elementswith respect to design model.
Q.4 A) Answer any three of the following : 12

a) What do you mean by testing strategies ?

b) Explain basic principles of project planning.
c) Write steps to perform statistical SQA.
d) Explain smoke testing with its advantages and disadvantages (2 each).
Q.4 B) Answer any one of the following : 4

a) Explain CPM. How is it different from PERT ?

b) Explain CMMI with its levels and neat diagram.
Q.5 Answer any two of the following : 16

a) State and describe various core principles of software engineering.

b) Describe the following with respect to Risk assessment :
i) Risk identification ii) Risk analysis iii) Risk prioritization
c) What is Quality Assurance ? Describe various SQA activities.
Q.6 Answer any four of the following : 16

a) Differentiate between verification and validation.

b) Explain Brute force approaches used in debugging strategies.

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering S-7 Solved Board Question Papers

c) Explain any four features of SCM.

d) Explain the following management spectrum :
i) The Process ii) The Project
e) Describe white box and black box testing of software.

SUMMER - 2017
Software Engineering Solved Paper
Semester - IV (Civil) (16172)

Time : 3 Hours] [Total Marks : 100

Note : 1) All questions are compulsory.

2) Answer each next main question on a new page.

3) Illustrate your answers with neat sketches wherever necessary.

4) Figures to the right indicate full marks.

5) Assume suitable data, if necessary.

6) Mobile Phone, Pager and any other Electronic Communication devices are not permissible in
Examination Hall.
Q.1 Attempt any five of the following : 20

a) What is software ? What is embedded software ?

b) Explain the term scrum.
c) List core principle of Software Engineering.
d) Write importance of analysis modeling.
e) List various testing characteristics.
f) What is change control ?.
g) List various activities of SQA.
Q.2 Attempt any four of the following : 16

a) What is quality control ?

b) Explain following terms w.r.t. risk management :
i) Risk identification ii) Risk analysis
c) Describe debugging process.
d) Compare cardinality and modality.
e) Explain essence of practice.
f) What do you mean by process framework ? Explain with suitable diagram.
Q.3 Attempt any four of the following : 16

a) Explain software engineering as a layered approach.

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering S-8 Solved Board Question Papers

b) Explain following requirements engineering tasks :

i) Negotiation ii) Specification
c) What is DFD ? Explain its symbol.
d) How can project scheduling affect integration testing ?
e) What is the concept of task network ?
f) Explain SCM in short.
Q.4 Attempt any four of the following : 16

a) Give possible reasons of why software is delivered late.

b) Explain test case design in detail.
c) Explain scenario based modeling in detail.
d) What is meant by software deployment ?
e) What is SRS ?
f) What is agile process ?
Q.5 Attempt any two of the following : 16

a) Explain RAD model with its advantages and disadvantages.

b) Describe in detail eight principles of good planning.
c) What is philosophy of six sigma ? Explain six sigma strategies.
Q.6 Attempt any four of the following : 16

a) Write meaning of PERT and CPM.

b) Explain the steps of bottom up integration.
c) List the objective of black box testing.
d) For library management system draw level 0 and level 1 DFD.
e) What are the characteristics of good design ?
f) State advantages of PSP and TSP.

WINTER - 2017
Software Engineering Solved Paper
Semester - IV (Civil) (11718)

Time : 3 Hours] [Total Marks : 100

Note : 1) All questions are compulsory.

2) Answer each next main question on a new page.

3) Illustrate your answers with neat sketches wherever necessary.

4) Figures to the right indicate full marks.

5) Assume suitable data, if necessary.

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering S-9 Solved Board Question Papers

Q.1 Answer any five of the following : 20

a) Explain changing nature of software.

b) What are communication principles ? Explain their meaning.
c) List four objectives of testing.
d) Explain briefly unit testing.
e) What is alpha - beta testing ?
f) Describe six sigma for software engineering.
g) Explain analysis modeling.
Q.2 Answer any four of the following : 16

a) Explain the waterfall model.

b) Explain modeling practice in software engineering with principles.
c) What do you mean by good test ?
d) Describe integration testing approach.
e) Explain Mccalls quality factor.
f) What is an object oriented analysis ?
Q.3 Answer any four of the following : 16

a) Difference between prescriptive and agile process model.

b) Describe any two core principles of software engineering.
c) What is test plan ?
d) Describe regression testing.
e) Explain modality with the help of example.
f) What is SPM ? Why is it needed ?
Q.4 Answer any four of the following : 16

a) Explain the concept of software requirement specification.

b) Explain characteristics of software testing.
c) State eight benefit of ISO standards.
d) Explain DFD with example.
e) Explain the concept of Gantt chart.
f) Explain CPM. How is it different from pert ?
Q.5 Answer any two of the following : 16

a) What is software ? What are its characteristics ?

b) What are major task of requirement engineering ?
c) Explain the term debugging. Explain different debugging.

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering S - 10 Solved Board Question Papers

Q.6 Answer any four of the following : 16

a) Explain Deployment principle .

b) Differentiate between validation and verification.
c) Explain about software quality assurance.
d) Describe behavioral model.
e) What is project scheduling ?
f) Explain SCM.

SUMMER - 2018
Software Engineering Solved Paper
Semester - IV (Civil) (21718)

Time : 3 Hours] [Total Marks : 100

Note : 1) All questions are compulsory.

2) Answer each next main question on a new page.

3) Illustrate your answers with neat sketches wherever necessary.

4) Figures to the right indicate full marks.

5) Assume suitable data, if necessary.

6) Mobile Phone, Pager and any other Electronic Communication devices are not permissible in
Examination Hall.
Q.1 a) Attempt any three of the following : 12

i) Define management spectrum and enlist characteristics of software.

ii) Draw stub and driver mechanism of unit testing and enlist various types of errors detected by unit testing.
iii) Describe five steps for successfulness of project.
iv) Draw the neat labeled diagram of spiral model and list two disadvantages of spiral model.
Q.1 b) Attempt any one of the following : 6

i) Elaborate any six types of software considering the changing nature.

ii) Draw and explain level 0 and level 1 Dataflow diagram for "Online examination Win17 of form filling on
MSBTE website".
Q.2 Attempt any four of the following : 16

a) Elaborate the software characteristic "Software does not wear out".

b) List and explain three principles of analysis modeling.
c) Draw the usecase diagram for taking "photocopy of ansbooks from msbte" website.
d) Enlist advantages and disadvantages of smoke testing. (four points)
e) Enlist and explain different types of Software Risks. (four points)
®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering S - 11 Solved Board Question Papers

f) Explain qualities of software considering :

i) Quality of design ii) Quality of conformance
Q.3 Attempt any four of the following : 16

a) Give difference between waterfall model and incremental model. (four points)
b) Explain following requirements of engineering tasks :
i) Negotiation ii) Validation
c) Explain Architectural Design Elements.
d) State eight characteristics of software bugs.
e) Explain the functions of Software Configuration Management repository. (SCM)
Q.4 a) Attempt any three of the following : 12

i) Explain the testing concept with its Testing Principles. (any four principles)
ii) Compare Bottom - up integration testing and top - down integration software testing. (four points)
iii) Explain the factors that Delay Project Schedule.
iv) Explain the six sigma for software engineering.
b) Attempt any one of the following : 6

i) List and explain five framework activities defined in PSP (Personal software process).
ii) Explain 4 P's software project spectrum.
Q.5 Attempt any two of the following : 16

a) Draw the behavioral analysis model for small hospital management system and illustrate the working of it.
b) List and explain the elements of analysis model with neat labeled diagram.
c) Explain different levels of Capability Maturity Model Integration technique. (CMMI)
Q.6 Attempt any four of the following : 16

a) Explain principles of planning practices in software engineering (any four)

b) Explain input and output of domain analysis.
c) Define white box testing and black box testing with its need and characteristics. (two points)
d) Explain different activities done to track the software.
e) Prepare any four software quality assurance guidelines and describe them.

qqq

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

 Solved Sample Test Paper - I
Software Engineering
S.Y. Diploma Semester - IV (Computer Engineering Group & Information Technology) (CO/CM/IF/CW)

Time : 1 Hour] [Total Marks : 20

Instructions :
(1) All questions are compulsory.
(2) Illustrate your answers with neat sketches wherever necessary.
(3) Figures to the right indicate full marks.
(4) Assume suitable data if necessary.
(5) Preferably, write the answers.

Q.1 Attempt Any Four. [8]

(a) What is application software ? (Refer section 1.4(2))

(b) Give any two advantages of RAD model. (Refer section 1.7.1.2)
(c) Explain the concept of agile process in brief. (Refer section 1.8)
(d) What is the meaning of the term software elicitation ? (Refer section 2.8.2)
(e) What is use case ? (Refer section 2.11)
(f) What are the elements of analysis model ? (Refer section 3.2)
Q.2 Attempt any THREE. [12]

(a) List and explain any four attributes of a good software. (Refer section 1.1)
(b) Explain waterfall model in detail. (Refer section 1.7.1.1)
(c) Explain functional and non functional requirements. (Refer section 2.9)
(d) What is SRS ? Explain its importance. (Refer section 2.13)
(e) Explain the concept of cohesion and coupling in software design. (Refer section 3.3.1(7))
(f) Give any four rules used during data flow design. (Refer section 3.4.1.1)

Solved Sample Test Paper - II

Software Engineering
S.Y. Diploma Semester - IV (Computer Engineering Group & Information Technology) (CO/CM/IF/CW)

Time : 1 Hour] [Total Marks : 20

Q.1 Attempt Any Four. [8]

(a) Enlist four P’s in management spectrum. (Refer section 4.1)

(b) Give any two causes of software project failure. (Refer section 4.1.4)
(c) Explain the term - functional point. (Refer section 4.2.2)

®
(S - -1)An up thrust for knowledge
TECHNICAL PUBLICATIONS
TM
Software Engineering S-2 Solved Sample Test Papers

(d) What are three commonly used cost estimation approaches used in software projects ? (Refer section 4.3)
(e) Explain - work break down structure. (Refer section 5.1.2)
(f) Give the full forms of PERT and CPM. (Refer section 5.1.4)
Q.2 Attempt any THREE. [12]

(a) Explain LOC based estimation method. (Refer section 4.2.1)

(b) Enlist and explain different types of software risks (Four Points). (Refer section 4.6.1)
(c) Explain the term risk mitigation. (Refer section 4.6.6)
(d) List four basic principles of project scheduling. (Refer section 5.1.4)
(e) Write short note on - Earned Value Analysis. (Refer section 5.2.2)
(f) What are steps required to perform statistical SQA ? (Refer section 5.4)

qqq

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

 Solved Sample Question Paper
Software Engineering
S.Y. Diploma Semester - IV (Computer Engineering Group & Information Technology) (CO/CM/IF/CW)

Time : 3 Hours] [Total Marks : 70

Instructions :
(1) All questions are compulsory.
(2) Illustrate your answers with neat sketches wherever necessary.
(3) Figures to the right indicate full marks.
(4) Assume suitable data if necessary.
(5) Preferably, write the answers in sequential order.

Q.1 Attempt Any FIVE of the Following : [10]

(a) Define the terms - Software and Software engineering (Refer section 1.1)
(b) State and explain any two types of software (Refer section 1.4)
(c) List core principles of software engineering (Refer section 2.2)
(d) What is data object? (Refer section 3.1.1.1)
(e) What are two types of size estimation (Refer section 4.2)
(f) Define the term- Risk (Refer section 4.6)
(g) What is software quality assurance (Refer section 5.4)
Q.2 Attempt Any THREE of the Following : [12]

(a) Explain software engineering as a layered technology approach. (Refer section 1.2)
(b) Explain the essence of software engineering practice (Refer section 2.1)
(c) Explain cardinality and modality with example. (Refer section 3.1.2)
(d) Prepare any four software quality assurance guidelines and describe them. (Refer section 5.4)
Q.3 Attempt Any THREE of the Following : [12]

(a) Give the difference between size oriented metrics and function oriented metrics. (Refer section 4.2.2)
(b) Explain following with reference to design concepts in design modeling.
i) Abstraction ii) Functional independence (Refer section 3.3.1)
(c) Explain deployment principle (Refer section 2.7)
(d) Enlist basic principles of software security (Refer section 5.7)
Q.4 Attempt Any THREE of the Following : [12]

(a) Enlist various functional and non functional requirements for the bank ATM system (Refer example 2.9.1)
(b) Elaborate the software characteristic: "Software is engineered, not manufactured " (Refer section 1.3)
(c) Explain 4 P's software project spectrum (Refer section 4.1)
(d) Write short note on - Unit testing (Refer section 3.5.3.1)

®
(S - -3)An up thrust for knowledge
TECHNICAL PUBLICATIONS
TM
Software Engineering S-4 Solved Sample Model Question Paper

Q.5 Attempt any TWO of the Following : [12]

(a) Explain COCOMO estimation model in detail (Refer section 4.4)
(b) Draw DFD level 0 and level 1 for Hotel Management System (Refer example 3.4.2)
(c) Describe six sigma for software engineering (Refer section 5.6.1)
Q.6 Attempt any TWO of the Following : [12]

(a) What is DEVOPs ? Explain its needs and benefits of DEVOPs (Refer section 5.8)
(b) Explain Risk management procedure in detail (Refer section 4.6)
(c) What are major tasks of requirement engineering? (Refer section 2.8)

qqq

®
TM

TECHNICAL PUBLICATIONS - An up thrust for knowledge

 SUMMER - 2019
Software Engineering Solved Paper
S.Y. Diploma Semester - IV (Computer Engg. Group & Information Technology) I - Scheme
(CO/CM/IF/CW) (21819)

Time : 3 Hours] [Total Marks : 70

Instructions :
1) All questions are compulsory.

2) Answer each next main question on a new page.

3) Illustrate your answers with neat sketches wherever necessary.
4) Assume suitable data if necessary.

5) Use of Non-programmable Electronic Pocket Calculator is permissible.

6) Mobile phone, pager and any other electronic communication devices are not permissible
in Examination Hall.
7) Preferably, write the answers in sequential order.
Q.1 Attempt any Five of the following : [10]

a) Enlist and explain software characteristics (any two) (Refer section 1.3)
b) Define software on engineering. (Refer section 1.1)
c) State need of Software Requirement Specification (SRS). (Refer section 2.14)
d) Define Reactive Risk strategies.
Ans. : Reactive Risk Strategy is a strategy in which certain action occurs in response to the risk.
e) Specify following cost directives of cocomo : (Refer section 4.4)
i) Product attributes (any two) ii) Hardware attributes (any two).
f) Differentiate between software quality management and software quality assurance (any two points).
(Refer section 5.3)
g) Define software quality assurance. (Refer section 5.4)
Q.2 Attempt any Three of the following : [12]

a) Explain software engineering as layered technology approach. (Refer section 1.2)

b) Explain with example decision table. (Refer section 3.4.3)
c) Explain following elements of management spectrum : (Refer section 4.1)
i) People ii) Process iii) Product iv) Project
d) List and explain basic principles of project scheduling. (Refer section 5.1.1)
Q.3 Attempt any Three of the following : [12]

a) Distinguish between perspective process model and agile process model. (Refer section 1.8)
b) Describe any four principles of communication for software engineering. (Refer section 2.3)

(S - 5)
R

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering S-6 Solved Board Question Papers

c) Draw proper labeled “LEVEL I Data Flow Diagram” (DFD) for student attendance system.
Ans. :

Login
Student Student Attendance
System
Response

Fig. 1 Level 0 DFD

1.0
Login Check details
Student Login Student info
Response Response

Submit query 1.1

Check details
View Attendance record
Attendance
Response Response

1.2
Submit query update
Apply for Leave record
leave
Response acknowledge

1.3 Insert New

Submit query password
Change Student Info
password
Response acknowledge

Fig. 2 Level 1 DFD

d) State importance of “Function Point (FP)” and “Lines of Codes (LOC)” in concerned with project estimation.
(Refer section 4.2)
Q.4 Attempt any Three of the following : [12]

a) Describe extreme programming with proper diagram. (Refer section 1.8.2)

b) List and explain any “four core principles” of software engineering. (Refer section 2.2)
c) Explain RMMM plan with example. (Refer section 4.6)
d) Explain any one project cost estimation approach. (Refer section 4.3)

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering S-7 Solved Board Question Papers

e) Prepare time line chart for Library Managements System (five days a week) Consider phases of SDLC.
(Refer section 5.2.1)
Q.5 Attempt any Two of the following : [12]

a) Enlist Requirement Gathering and Analysis for web based project for registering candidates for contest (any six
points).
Ans. :
(1) The candidate must enter personal information for user name, and password, email_id.
(2) The system should validate his/her email_id.
(3) The system should sent the system generated user name and password to the user through his email.
(4) The system should sent the "Successful registration" message to the user. If the registration gets failed the
system should send the appropriate message to the user and it should consider such candidate as invalid.
(5) The candidate must be able to log-in with the user name and password.
(6) If the user forgets the password, the system should provide the assistance to the candidate with the help of
his/her authorized email-id
b) Differentiate between White box and Black box testing (any six points). (Refer section 3.5.2)
c) Describe Co-Como II model for evaluating size of software project with any three parameters in detail.
(Refer section 4.6)
Q.6 Attempt any Two of the following : [12]

a) Draw and explain transition diagram from requirement model to design model. (Refer section 5.3.1)
b) Describe CMMI. Give significance of each level. (Refer section 5.6.3)
c) Identify and enlist requirement for given modules of employee management software :
i) Employee detail ii) Employee salary iii) Employee performance
Ans. : (i) Employee details

1. The employee details fields must be completely filled up by the employee.

2. The employee information must be validated and then the information is entered in the database.

(ii) Employee salary

1. The appropriate salary information must be entered in the employee database of employee management
software.
2. The salary must be non-negative and non-zero.

(iii) Employee performance

1. Employee performance record must be updated periodically in the employee management software.
2. On the lowering the performance, the employee should get the system generated notification.

qqq

TECHNICAL PUBLICATIONS - An up thrust for knowledge

Software Engineering S-8 Solved Board Question Papers

Notes

TECHNICAL PUBLICATIONS - An up thrust for knowledge