0% found this document useful (0 votes)
19 views190 pages

Notes On SFT ENGG. by Paramita Bhattacharya

The document provides guidelines on writing Software Requirement Specifications (SRS) with a focus on a Library Management System example, detailing sections like purpose, scope, and specific requirements. It also explains sequence diagrams in UML, illustrating how objects interact over time, and includes an overview of Halstead's Software Metrics for measuring software complexity and effort. The document emphasizes the importance of visualizing system interactions and provides a comprehensive breakdown of metrics for assessing software quality and maintainability.

Uploaded by

subhamgoswami16
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
19 views190 pages

Notes On SFT ENGG. by Paramita Bhattacharya

The document provides guidelines on writing Software Requirement Specifications (SRS) with a focus on a Library Management System example, detailing sections like purpose, scope, and specific requirements. It also explains sequence diagrams in UML, illustrating how objects interact over time, and includes an overview of Halstead's Software Metrics for measuring software complexity and effort. The document emphasizes the importance of visualizing system interactions and provides a comprehensive breakdown of metrics for assessing software quality and maintainability.

Uploaded by

subhamgoswami16
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 190

NOTES ON

SOFTWARE
ENGINEERING

BY

PARAMITA
BHATTACHARYA
HOW TO WRITE SOFTWARE REQUIREMENT SPECIFICATION
EXAMPLE: LIBRARY MANAGEMENT SYSTEM
Abstract:
1. Introduction
1.1 Purpose
1.2 Scope:
1.3 Developer’s responsibility
2.General description
2.1 Product function overview
2.2 User characteristics
2.3 General constraint
3. Specific requirements
3.1 input and output
3.2 functional Requirements
3.3 Performance requirement
3.4 design constraints
3.4.1 software constraints
3.4.2 hardware constrains
3.5 Acceptance criteria
What is a sequence diagram?
Sequence diagrams are a type of Universal Modeling Language (UML) diagram. They’re
used to show how objects in a system work together over time. A sequence diagram
helps the designer of a system visualize and understand the order in which these
interactions occur. This can make it easier to identify potential problems and optimize
how everything works.

Let’s quickly summarize the basic elements in a sequence diagram.

The sequence diagram moves from top to bottom to show the sequence of events in the
system. The objects included are shown at the top and bottom of the diagram as labeled
rectangles with a lifeline descending the full length of the diagram. The interactions
between objects are shown as horizontal arrows that go left or right. These represent
messages passing between the objects.

When a message hits an object’s lifeline, that object can be activated. A


vertical box called an activation bar is placed on the lifeline to indicate
that the object is processing the message or carrying out a command.
The length of the box tells you the duration of activity.
Unified Modelling Language (UML) is a modeling language in the field of
software engineering which aims to set standard ways to visualize the design of
a system. UML guides the creation of multiple types of diagrams such as
interaction , structure and behaviour diagrams. A sequence diagram is the
most commonly used interaction diagram. Interaction diagram – An
interaction diagram is used to show the interactive behavior of a system.
Since visualizing the interactions in a system can be a cumbersome task, we
use different types of interaction diagrams to capture various features and
aspects of interaction in a system. Sequence Diagrams – A sequence diagram
simply depicts interaction between objects in a sequential order i.e. the order in
which these interactions take place. We can also use the terms event diagrams
or event scenarios to refer to a sequence diagram. Sequence diagrams
describe how and in what order the objects in a system function. These
diagrams are widely used by businessmen and software developers to
document and understand requirements for new and existing systems.
Figure – notation symbol for actor, We use actors to depict various roles
including human users and other external subjects. We represent an actor in a
UML diagram using a stick person notation. We can have multiple actors in a
sequence diagram. For example – Here the user in seat reservation system is
shown as an actor where it exists outside the system and is not a part of the
system.

1. Figure – an actor interacting with a seat reservation system


2. Lifelines – A lifeline is a named element which depicts an individual
participant in a sequence diagram. So basically each instance in a sequence
diagram is represented by a lifeline. Lifeline elements are located at the top
in a sequence diagram. The standard in UML for naming a lifeline follows the
following format –

Instance Name : Class Name


Figure – lifeline We display a lifeline in a rectangle called head with its name
and type. The head is located on top of a vertical dashed line (referred to as the
stem) as shown above. If we want to model an unnamed instance, we follow the
same pattern except now the portion of lifeline’s name is left blank. Difference
between a lifeline and an actor – A lifeline always portrays an object internal
to the system whereas actors are used to depict objects external to the system.
The following is an example of a sequence diagram:

Messages – Communication between objects is depicted using messages. The


messages appear in a sequential order on the lifeline. We represent messages
using arrows. Lifelines and messages form the core of a sequence diagram.
Messages can be broadly classified into the following categories :

• Synchronous messages – A synchronous message waits for a reply before


the interaction can move forward. The sender waits until the receiver has
completed the processing of the message. The caller continues only when it
knows that the receiver has processed the previous message i.e. it receives
a reply message. A large number of calls in object oriented programming are
synchronous. We use a solid arrow head to represent a synchronous
message.
1.
Firstly the application is opened by the user.
2. The device then gets access to the web cam.
3. The webcam captures the image of the user.
4. The device uses algorithms to detect the face and predict the mood.
5. It then requests database for dictionary of possible moods.
6. The mood is retrieved from the database.
7. The mood is displayed to the user.
8. The music is requested from the database.
9. The playlist is generated and finally shown to the user.

Uses of sequence diagrams –

• Used to model and visualise the logic behind a sophisticated function,


operation or procedure.
• They are also used to show details of UML use case diagrams.
• Used to understand the detailed functionality of current or future systems.
• Visualise how messages and tasks move between objects or components in
a system.

First, let’s work out the objects that we want to represent in our diagram. We’re
designing a library management system, so we’ll need at least four basic elements:
Member, Librarian, Book, and Transaction.Our first interaction will be when a member
of the library requests a book from a librarian.

Member-request a book->+ Librarian

Let’s quickly break that down. Member and Librarian are straightforward. Those are
objects and will create rectangular boxes with vertical lifelines for them.
The message is “request a book” and that syntax will create a labeled
arrow. Finally, the plus symbol at the end tells that an activity bar
should be created on the Librarian lifeline, because that object has been
activated. But note that the activity bar won’t show up in our diagram
until the end, until we tell that it should be terminated.

Next, the librarian will check the system to see if the book is available. This means an
interaction with the Book object in the library management system. Again, we’ll use a
labeled arrow and the Book object will be created.

Librarian-check availability->Book
The librarian now needs to validate whether the member can borrow the book from the
library. This is a two-step process of validating membership and also checking the
number of books already issued.

Librarian-validate->Member

Librarian-check no. of issued books->Member


If the member is authorized to borrow the book, the librarian can now issue it.

Librarian-issue a book->Member
The librarian also needs to record the transaction in the library management system,
and that brings us to our final object, Transaction. The Librarian sends a “create”
message to Transaction. The message adds the member and book details to that
transaction and it is stored in the database so that it can be used to check up on the
member or book later on.

Librarian-<<create>>->Transaction

Librarian-add member and book details->Transaction


The librarian next needs to update the book’s status in the system, so it’s clear that it has
been borrowed and isn’t available until returned. The librarian also needs to update the
member’s record, to indicate that they have borrowed an additional book. That gives us
the final lines in our simple library management sequence diagram.

Librarian-update status->Book

Librarian-update member record->-Member

Note that there’s a minus symbol after the last message. That’s to tell to
terminate the activation bar on the Library object. And that will also
show us the activation bar in the finished diagram.
Halstead’s Software Metrics
Halstead’s metrics are included in a number of current commercial tools that
count software lines of code. By counting the tokens and determining which are
operators and which are operands, the following base measures can be
collected :
n1 = Number of distinct operators.
n2 = Number of distinct operands.
N1 = Total number of occurrences of operators.
N2 = Total number of occurrences of operands.
In addition to the above, Halstead defines the following :
n1* = Number of potential operators.
n2* = Number of potential operands.

for example, in C language, any program must contain at least the


definition of the function main()), possibly as a function or as a procedure:
n1* = 2, since at least 2 operators must appear for any function or
procedure : 1 for the name of the function and 1 to serve as an
assignment or grouping symbol, and n2* represents the number of
parameters, without repetition, which would need to be passed on to the
function or the procedure. Halstead metrics –

Halstead metrics are :

 Halstead Program Length – The total number of operator occurrences and


the total number of operand occurrences.
N = N1 + N2
And estimated program length is, N = n1log n1 + n2log n2
^
2 2

The following alternate expressions have been published to estimate


program length:
 JN = log (n1!) + log (n2!)
2 2

 BN = n1 * log n2 + n2 * log n1
2 2

 CN = n1 * sqrt(n1) + n2 * sqrt(n2)
 SN = (n * log n) / 2
2

 Halstead Vocabulary – The total number of unique operator and unique


operand occurrences.
n = n1 + n2
 Program Volume – Proportional to program size, represents the size, in
bits, of space necessary for storing the program. This parameter is
dependent on specific algorithm implementation. The properties V, N, and
the number of lines in the code are shown to be linearly connected and
equally valid for measuring relative program size.
V = Size * (log vocabulary) = N * log (n)
2 2

The unit of measurement of volume is the common unit for size “bits”. It is
the actual size of a program if a uniform binary encoding for the vocabulary
is used. And error = Volume / 3000
 Potential Minimum Volume – The potential minimum volume V* is defined
as the volume of the most succinct program in which a problem can be
coded.
V* = (2 + n2*) * log (2 + n2*)
2

Here, n2* is the count of unique input and output parameters


 Program Level – To rank the programming languages, the level of
abstraction provided by the programming language, Program Level (L) is
considered. The higher the level of a language, the less effort it takes to
develop a program using that language.
L = V* / V
 The value of L ranges between zero and one, with L=1 representing a
program written at the highest possible level (i.e., with minimum size).
And estimated program level is L =2 * (n2) / (n1)(N2)
^

 Program Difficulty – This parameter shows how difficult to handle the


program is.
D = (n1 / 2) * (N2 / n2)
D=1/L
As the volume of the implementation of a program increases, the program
level decreases and the difficulty increases. Thus, programming practices
such as redundant usage of operands, or the failure to use higher-level
control constructs will tend to increase the volume as well as the difficulty.
 Programming Effort – Measures the amount of mental activity needed to
translate the existing algorithm into implementation in the specified program
language.
E = V / L = D * V = Difficulty * Volume
 Language Level – Shows the algorithm implementation program
language level. The same algorithm demands additional effort if it is
written in a low-level program language. For example, it is easier to
program in Pascal than in Assembler.
L’ = V / D / D
lambda = L * V* = L * V
2

 Intelligence Content – Determines the amount of intelligence presented


(stated) in the program This parameter provides a measurement of
program complexity, independently of the program language in which it
was implemented.
I=V/D
 Programming Time – Shows time (in minutes) needed to translate the
existing algorithm into implementation in the specified program language.
T = E / (f * S)

Counting rules for C language –

1. Comments are not considered.


2. The identifier and function declarations are not considered
3. All the variables and constants are considered operands.
4. Global variables used in different modules of the same program are counted as
multiple occurrences of the same variable.
5. Local variables with the same name in different functions are counted as unique
operands.
6. Functions calls are considered as operators.
7. All looping statements e.g., do {…} while ( ), while ( ) {…}, for ( ) {…}, all control
statements e.g., if ( ) {…}, if ( ) {…} else {…}, etc. are considered as operators.
8. In control construct switch ( ) {case:…}, switch as well as all the case statements are
considered as operators.
9. The reserve words like return, default, continue, break, sizeof, etc., are considered as
operators.
10. All the brackets, commas, and terminators are considered as operators.
11. GOTO is counted as an operator and the label is counted as an operand.
12. The unary and binary occurrence of “+” and “-” are dealt separately. Similarly “*”
(multiplication operator) are dealt separately.
13. In the array variables such as “array-name [index]” “array-name” and “index” are
considered as operands and [ ] is considered as operator.
14. In the structure variables such as “struct-name, member-name” or “struct-name ->
member-name”, struct-name, member-name are taken as operands and ‘.’, ‘->’ are
taken as operators. Some names of member elements in different structure variables
are counted as unique operands.
15. All the hash directive are ignored.
Example – List out the operators and operands and also calculate the values of software
science measures like

int sort (int x[ ], int n)


{
int i, j, save, im1;
/*This function sorts array x in ascending order */
If (n< 2) return 1;
for (i=2; i< =n; i++)
{
im1=i-1;
for (j=1; j< =im1; j++)
if (x[i] < x[j])
{
Save = x[i];
x[i] = x[j];
x[j] = save;
}
}
return 0;
}

Explanation –

operators occurrences operands occurrences

int 4 sort 1

() 5 x 7

, 4 n 3

[] 7 i 8

if 2 j 7
< 2 save 3

; 11 im1 3

for 2 2 2

= 6 1 3

– 1 0 1

<= 2 – –

++ 2 – –

return 2 – –

{} 3 – –

n1=14 N1=53 n2=10 N2=38

Therefore,
N = 91
n = 24
V = 417.23 bits
N^ = 86.51
n2* = 3 (x:array holding integer
to be sorted. This is used both
as input and output)
V* = 11.6
L = 0.027
D = 37.03
L^ = 0.038
T = 610 seconds
Advantages of Halstead Metrics:
 It is simple to calculate.
 It measures overall quality of the programs.
 It predicts the rate of error.
 It predicts maintenance effort.
 It does not require the full analysis of programming structure.
 It is useful in scheduling and reporting projects.
 It can be used for any programming language.

Disadvantages of Halstead Metrics:

 It depends on the complete code.


 It has no use as a predictive estimating model.
GANTT CHART FOR A PROJECT

ACTIVITY PREDECESSOR DURATION


A - 2
B A 3
C A 2
D B 3
E C 4
F D 2
G B 1
H D 3
I C 2
Prepared by
Prof. PARAMITA BHATTACHARYA
A

B
PROJECT ACTIVITY

C
D

1 2 3 4 5 6 7 8 9 10
TIME TAKEN ( IN DAYS )
ACTIVITY – A
A

C
D
ACTIVITY

ACTIVITY PREDECESSOR DURATION


H
A - 2
I
B A 3

C A 2 1 2 3 4 5 6 7 8 9 10 11 12
D B 3

E C 4
TIME TAKEN ( IN DAYS )
F D 2

G B 1

H D 3

I C 2
ACTIVITY – B
A

C
D
ACTIVITY

ACTIVITY PREDECESSOR DURATION


H
A - 2
I
B A 3
C A 2 1 2 3 4 5 6 7 8 9 10 11 12
D B 3

E C 4
TIME TAKEN ( IN DAYS )
F D 2

G B 1

H D 3

I C 2
ACTIVITY – C
A

C
D
ACTIVITY

ACTIVITY PREDECESSOR DURATION


H
A - 2

B A 3
I
C A 2 1 2 3 4 5 6 7 8 9 10 11 12
D B 3

E C 4
TIME TAKEN ( IN DAYS )
F D 2

G B 1

H D 3

I C 2
ACTIVITY – D
A

C
D
ACTIVITY

ACTIVITY PREDECESSOR DURATION


H
A - 2

B A 3
I
C A 2
1 2 3 4 5 6 7 8 9 10 11 12
D B 3
E C 4
TIME TAKEN ( IN DAYS )
F D 2

G B 1

H D 3

I C 2
ACTIVITY – E
A

C
D
ACTIVITY

ACTIVITY PREDECESSOR DURATION


H
A - 2

B A 3
I
C A 2
1 2 3 4 5 6 7 8 9 10 11 12
D B 3

E C 4
TIME TAKEN ( IN DAYS )
F D 2

G B 1

H D 3

I C 2
ACTIVITY – F
A

C
D
ACTIVITY

ACTIVITY PREDECESSOR DURATION


H
A - 2

B A 3
I
C A 2
1 2 3 4 5 6 7 8 9 10 11 12
D B 3

E C 4
TIME TAKEN ( IN DAYS )
F D 2
G B 1

H D 3

I C 2
ACTIVITY – G
A

C
D
ACTIVITY

ACTIVITY PREDECESSOR DURATION


H
A - 2

B A 3
I
C A 2
1 2 3 4 5 6 7 8 9 10 11 12
D B 3

E C 4

F D 2
TIME TAKEN ( IN DAYS )
G B 1
H D 3

I C 2
ACTIVITY – H
A

C
D
ACTIVITY

ACTIVITY PREDECESSOR DURATION


H
A - 2

B A 3
I
C A 2
1 2 3 4 5 6 7 8 9 10 11 12
D B 3

E C 4

F D 2
TIME TAKEN ( IN DAYS )
G B 1

H D 3
I C 2
ACTIVITY – I
A

C
D
ACTIVITY

ACTIVITY PREDECESSOR DURATION


H
A - 2

B A 3
I
C A 2
1 2 3 4 5 6 7 8 9 10 11 12
D B 3

E C 4

F D 2
TIME TAKEN ( IN DAYS )
G B 1

H D 3

I C 2
GANTT CHART
A

C
D
ACTIVITY

H
ACTIVITY PREDECESSOR DURATION

A - 2
I
B A 3

C A 2 1 2 3 4 5 6 7 8 9 10 11 12
D B 3

E C 4
TIME TAKEN ( IN DAYS )
F D 2

G B 1

H D 3

I C 2
SIX SIGMA

Six Sigma methodologies


DMAIC and DMADV

Compiled by
Prof. PARAMITA BHATTACHARYA
• Six Sigma is a set of techniques and tools for process improvement.

• It was developed by Motorola in 1986.

• Six Sigma uses of statistics and data analysis to analyze and reduce
errors or defects.

• In this process, the purpose is to improve cycle times while reducing


manufacturing defects to no more than 3.4 defects per million units or
events.
The Six Sigma Methodology

The two main Six Sigma methodologies are


DMAIC and DMADV.

Each has its own set of recommended procedures to be implemented for


business transformation.

The two methodologies are used in different business settings, and professionals
seeking to master these methods and application scenarios would do well to take
an online certificate program taught by industry experts.
DMAIC

DMAIC is a data-driven method used to


improve existing products or services for
better customer satisfaction.
It is the acronym for the five phases:
• D – Define,
• M – Measure,
• A – Analyse,
• I – Improve,
• C – Control.
DMAIC is applied in the manufacturing of a
product or delivery of a service.
DMADV

DMADV is a part of the Design for Six Sigma (DFSS) process used to design or re-design
different processes of product manufacturing or service delivery.
The five phases of DMADV are:
• D – Define,
• M – Measure,
• A – Analyse,
• D – Design,
• V – Validate.

DMADV is employed when existing processes do not meet customer


conditions, even after optimization, or when it is required to develop new
methods. It is executed by Six Sigma Green Belts and Six Sigma Black Belts and
under the supervision of Six Sigma Master Black Belts.

You might also like