ATMIYA UNIVERSITY

Faculty of Engineering and Technology

Department of Computer Engineering

SUBJECT: SOFTWARE ENGINEERING

SEMESTER : 5

STUDENT NAME:YAGNIK SAKHIYA J.

ENROLLMENT NUMBER:190002098
DIVISION:BY

LIST OF TUTORIALS
Sr. Experiments SIGN DATE
1. Study the complete Software
Development Life Cycle
(SDLC) and analyze various
activities conducted as apart of
various phases. For each SDLC
phase, identify the objectives
and summaries outcomes.
2. To perform the system analysis:
Requirement analysis, SRS.
3. To perform the function oriented
diagram: DFD and Structured
chart.
4. To perform the user’s view
analysis: Use case diagram for
railway reservation system.
5. To draw the structural view
diagram: Class diagram for
library management system.
6. To draw the behavioural view
diagram: Activity diagram for
flight control system.
7. To study Selenium Tool with a real
time example.
8. To perform sequence diagram for
Library management system.
9. Capability Maturity Model (CMM)
& it’s Levels in Software
Engineering
10. Calculate cyclomatic complexity
for given Code. Identify
number of Independent path
require for testing.               
11. Generate a test suite using the
white box testing strategies.
12. Apply basic and intermediate
COCOMO technique.
 TUTORIAL

Name : yagnik sakhiya J.

Division : BY
Roll No. : 29
Enrollment No. : 190002098

1. Study The Complete Software Development Life Cycle And Analyse

Various Activities Conducted An Apart Of Various Phases For Each SDLC
Phase; Identify The Objectives And Summaries Outcomes.
Sol.:

• SDLC Life cycle:

SDLC is a process followed for a software project, within a software organization. It consists of
a detailed plan describing how to develop, maintain, replace and alter or enhance specific
software. The life cycle defines a methodology for improving the quality of software and the
overall development process.
• 7 Stages of the System Development Life Cycle:

There are seven primary stages of the modern system development life cycle.

• Planning stage
 • Feasibility or Requirements of Analysis Stage

• Design and Prototyping Stage

• Software Development Stage

• Software Testing Stage

• Implementation and Integration

• Operations and Maintenance Stage

1. Planning Stage:

→ The planning stage (also called the feasibility stage) is exactly what it sounds like: the
phase in which developers will plan for the upcoming project.

→It helps to define the problem and scope of any existing systems, as well as determine the
objectives for their new systems.

→Perhaps most importantly, the planning stage sets the project schedule, which can be of key
importance if development is for a commercial product that must be sent to market by a
certain time.

2. Analysis Stage:

→The analysis stage includes gathering all the specific details required for a new system as
well as determining the first ideas for prototypes.

→Developers may:

• Define any prototype system requirements

• Evaluate alternatives to existing prototypes

• Perform research and analysis to determine the needs of end-users.

3. Design Stage:

→The design stage is a necessary precursor to the main developer stage.

→Developers will first outline the details for the overall application, alongside specific
aspects, such as its:

• User interfaces

• System interfaces

• Network and network requirements

• Databases

→Once complete, development managers will prepare a design document to be referenced

throughout the next phases of the SDLC.

4. Development Stage:

→The development stage is the part where developers actually write code and build the
application according to the earlier design documents and outlined specifications.

→Developers will follow any coding guidelines as defined by the organization and utilize
different tools such as compilers, debuggers, and interpreters.

→Programming languages can include staples such as C++, PHP, and more. Developers will
choose the right programming code to use based on the project specifications and
requirements.

5. Testing Stage:
 →Now it must be tested to make sure that there aren’t any bugs and that the end-user
experience will not negatively be affected at any point.

→During the testing stage, developers will go over their software with a fine-tooth comb,
noting any bugs or defects that need to be tracked, fixed, and later retested.
6. Implementation and Integration Stage:

→After testing, the overall design for the software will come together. Different modules or
designs will be integrated into the primary source code through developer efforts, usually
by leveraging training environments to detect further errors or defects.

→The information system will be integrated into its environment and eventually installed.
After passing this stage, the software is theoretically ready for market and may be
provided to any end-users.

7. Maintenance Stage:

→The SDLC doesn’t end when software reaches the market. Developers must now move into
a maintenance mode and begin practicing any activities required to handle issues reported
by end-users.

→Furthermore, developers are responsible for implementing any changes that the software
might need after deployment.

• Objectives:

The SDLC methodology will help to achieve these goals by:

• Establishing appropriate levels of management authority to provide timely direction, coordination,

control, review, and approval of the system development project.
• Ensuring project management accountability.
• Documenting requirements and maintaining trace ability of those requirements throughout the
development and implementation process.
• Ensuring that projects are developed within the current and planned information technology
infrastructure.
• Identifying project risks early.

2. To perform the system analysis: Requirement analysis, SRS.

Sol.:

Software systems analysis is a field in which analysts continually learn new techniques and
approaches to properly capture, maintain, understand, and develop more efficient and effective
software systems.

•Software Requirement Specification (SRS):

→Software Requirements Specifications (SRS) is also called a requirements document.

→Software requirement specification is a kind of document which is created by a software

analyst after the requirements collected from the various sources - the requirement received
by the customer written in ordinary language. It is the job of the analyst to write the
requirement in technical language so that they can be understood and beneficial by the
development team.
→The SRS is a specification for a specific software product, program, or set of applications that
perform particular functions in a specific environment. It serves several goals depending on
who is writing it.
→First, the SRS could be written by the client of a system. Second, the SRS could be written by
a developer of the system. The two methods create entirely various situations and establish
different purposes for the document altogether.
→The first case, SRS, is used to define the needs and expectation of the users. The second case,
SRS, is written for various purposes and serves as a contract document between customer
and developer.
•Properties of a good SRS document:

The essential properties of a good SRS document are the following:

Concise:The SRS report should be concise and at the same time, unambiguous, consistent, and
complete. Verbose and irrelevant descriptions decrease readability and also increase error
possibilities.

Structured:It should be well-structured. A well-structured document is simple to understand and

modify. In practice, the SRS document undergoes several revisions to cope up with the user
requirements. Often, user requirements evolve over a period of time. Therefore, to make the
modifications to the SRS document easy, it is vital to make the report well-structured.
Black-box view:It should only define what the system should do and refrain from stating how to
do these. This means that the SRS document should define the external behaviour of the system
and not discuss the implementation issues. The SRS report should view the system to be
developed as a black box and should define the externally visible behaviour of the system. For
this reason, the SRS report is also known as the black-box specification of a system.

Conceptual integrity:It should show conceptual integrity so that the reader can merely
understand it. Response to undesired events: It should characterize acceptable responses to
unwanted events. These are called system response to exceptional conditions.

Verifiable: All requirements of the system, as documented in the SRS document, should be
correct. This means that it should be possible to decide whether or not requirements have been
met in an implementation.

•Characteristics of good SRS:

3. To perform the function oriented diagram: DFD and Structured chart.
Sol.:
• Function Oriented Design:

Function Oriented design is a method to software design where the model is decomposed into a
set of interacting units or modules where each unit or module has a clearly defined function.
Thus, the system is designed from a functional viewpoint.

• Data Flow Diagram:

→Data-flow design is concerned with designing a series of functional transformations that

convert system inputs into the required outputs. The design is described as data-flow
diagrams. These diagrams show how data flows through a system and how the output is
derived from the input through a series of functional transformations.
 →Data-flow diagrams are a useful and intuitive way of describing a system. They are generally
understandable without specialized training, notably if control information is excluded.
They show end-to-end processing. That is the flow of processing from when data enters the
system to where it leaves the system can be traced.
→Data-flow design is an integral part of several design methods, and most CASE tools support
data-flow diagram creation. Different ways may use different icons to represent data-flow
diagram entities, but their meanings are similar.

→The notation which is used is based on the following symbols:

Example:
• Structured Charts :
Structure Chart represents hierarchical structure of modules. It breaks down the entire system
into lowest functional modules; describe functions and sub-functions of each module of a system
to a greater detail. Structure Chart partitions the system into black boxes (functionality of the
system is known to the users but inner details are unknown). Inputs are given to the black boxes
and appropriate outputs are generated.

→Structured Chart is a graphical representation which shows:

oSystem partitions into modules oHierarchy

of component modules oThe relation
between processing modules o Interaction
between modules o Information
passed between modules

→The following notations are used in structured chart:

Example: Structure chart for an Email server
4. To perform the user’s view analysis: Use case diagram for

Sol.:

• Use case diagram for railway reservation system

5. To draw the structural view diagram: Class diagram for library management system.

Sol.:

• Class diagram for library management system

6. To draw the behavioral view diagram: Activity diagram for flight
control system.

Sol.:
7. . To study Selenium Tool with a real time example.

Sol.:

•Selenium tool:

→Selenium is one of the most widely used open source Web UI (User Interface) automation testing suite. It was
originally developed by Jason Huggins in 2004 as an internal tool at Thought Works. Selenium supports
automation across different browsers, platforms and programming languages.
→Selenium can be easily deployed on platforms such as Windows, Linux, Solaris and Macintosh. Moreover, it
supports OS (Operating System) for mobile applications like iOS, windows mobile and android.
→Selenium supports a variety of programming languages through the use of drivers specific to each language.
Languages supported by Selenium include C#, Java, Perl, PHP, Python and Ruby.
→Currently, Selenium Web driver is most popular with Java and C#. Selenium test scripts can be coded in any of
the supported programming languages and can be run directly in most modern web browsers.
→Browsers supported by Selenium include Internet Explorer, Mozilla Firefox, Google Chrome and Safari.

8. To perform sequence diagram for Library management system.

Sol.:

•Sequence diagram for library management system

9. Capability Maturity Model (CMM) & it’s Levels in Software Engineering.

Sol.:

• Capability Maturity Model

→The Capability Maturity Model (CMM) is a procedure used to develop and refine an organization's software
development process.
→The model defines a five-level evolutionary stage of increasingly organized and consistently more mature
processes.
→CMM was developed and is promoted by the Software Engineering Institute (SEI), a research and development
centre promote by the U.S. Department of Defence (DOD).
→Capability Maturity Model is used as a benchmark to measure the maturity of an organization's software process.
 • Levels of Capability Maturity Model

1. Initial:

→Ad hoc activities characterize a software development organization at this level. Very few or no processes are
described and followed. Since software production processes are not limited, different engineers follow their
process and as a result, development efforts become chaotic.
→Therefore, it is also called a chaotic level.

2. Repeatable

→At this level, the fundamental project management practices like tracking cost and schedule are established.
→Size and cost estimation methods, like function point analysis, COCOMO, etc. are used.

3. Defined

→At this level, 2 methods for both management and development activities are defined and documented.
→There is a common organization-wide understanding of operations, roles, and responsibilities.
→The ways through defined, the process and product qualities are not measured. 4.Managed

→At this level, the focus is on software metrics. Two kinds of metrics are composed.

1. Product metrics measure the features of the product being developed, such as its size, reliability, time
complexity, understandability, etc.

2. Process metrics follow the effectiveness of the process being used, such as average defect correction
time, productivity, the average number of defects found per hour inspection, the average number of failures
detected during testing per LOC, etc.

oThe software process and product quality are measured, and quantitative quality requirements for the
product are met. oVarious tools like Pareto charts, fishbone diagrams, etc. are used to measure the product
 and process quality. oThe process metrics are used to analyze if a project performed satisfactorily. Thus, the
outcome of process measurements is used to calculate project performance rather than improve the process.

5.Optimizing

→At this phase, process and product metrics are collected. Process and product measurement data are evaluated for
continuous process improvement.

10. Calculate cyclomatic complexity for given Code. Identify number of Independent path require for testing.

{ inti, j, k;
  for (i=0 ;i<=N ; i++)
  p[i] = 1;
  for (i=2 ;i<=N ; i++)
  {
     k = p[i]; j=1;
     while (a[p[j-1]] > a[k] {
         p[j] = p[j-1];
         j--;
  }
     p[j]=k;
}

Method-01:
 
Cyclomatic Complexity
= Total number of closed regions in the control flow graph + 1
=3+1
=4
 
Method-02:
 
Cyclomatic Complexity
=E–N+2
= 16 – 14 + 2
=4
Following are the properties of Cyclomatic complexity:

1. V (G) is the maximum number of independent paths in the graph

2. V (G) >=1
3. G will have one path if V (G) = 1
4. Minimize complexity to 10

Method-01:
 
Independent Paths
11.Generate
= Total number a oftest suite
closed usinginthe
regions the white box testing
strategies.
control flow graph + 1
=2+1
=3
Sol.:
 
1)Method-02:
Statement coverage:
 
InIndependent
a programmingPathslanguage, a statement is nothing but the line of code or
instruction
=E–N+2 for the computer to understand and act accordingly. A statement
becomes
=8–7+ an2executable statement when it gets compiled and converted into the
object
=3 code and performs the action when the program is in a running mode.
Hence “Statement Coverage”, as the name itself suggests, it is the method
of validating whether each and every line of the code is executed at least once.
Example
INPUT A & B
C=A+B
IF C>100
PRINT “ITS DONE”
For Statement Coverage – we would only need one test case to check all the lines of the code.
That means If I consider TestCase_01 to be (A=40 and B=70), then all the lines of code will be executed.
Now the question arises: Is that sufficient?
What if I consider my Test case as A=33 and B=45?
Because Statement coverage will only cover the true side, for the pseudo code, only one test case would NOT be
sufficient to test it. As a tester, we have to consider the negative cases as well.
Hence for maximum coverage, we need to consider “Branch Coverage”, which will evaluate the “FALSE” conditions.
In the real world, you may add appropriate statements when the condition fails.
2) Branch Coverage:
“Branch” in a programming language is like the “IF statements”. An IF statement has two branches: True and False. So
in Branch coverage (also called Decision coverage), we validate whether each branch is executed at least once. 
In case of an “IF statement”, there will be two test conditions:
One to validate the true branch and, Other to validate the false branch.
Hence, in theory, Branch Coverage is a testing method which is when executed ensures that each and every branch
from each decision point is executed.
INPUT A & B
C=A+B
IF C>100
PRINT “ITS DONE”
ELSE

PRINT “ITS PENDING”

3) condition Coverage
Design test cases such that each possible outcome of each condition in each decision occurs at least once. Test case
designed to make each component of composite conditional expression to ensure both true and false values.
In condition coverage, the number of test cases increase exponentially with large number of component condition.
Example:
decision ( i< value ) AND (result <= maxint ) consists of two conditions : ( i< value ) AND (result <= maxint )
test cases should be designed such that each gets value true and false at least once

4) Path Coverage
Path coverage tests all the paths of the program. This is a comprehensive technique which ensures that all the paths of
the program are traversed at least once. Path Coverage is even more powerful than Branch coverage. This technique is
useful for testing the complex programs.
INPUT A & B
C=A+B
IF C>100
PRINT “ITS DONE”

END IF
IF A>50
PRINT “ITS PENDING”
END IF

12. Apply basic and intermediate COCOMO technique.

Sol.:

 Basic COCOMO Model :

 The basic COCOMO model provide anaccurate size of the project parameters.
 The following expressions give the basic COCOMO estimation model:

Effort=a1*(KLOC) a2 PM

Tdev=b1*(efforts)b2 Months

Where,

o KLOC is the estimated size of the software product indicate in Kilo Lines
of Code
o a1,a2,b1,b2 are constants for each group of software products
o Tdev is the estimated time to develop the software, expressed in months
o Effort is the total effort required to develop the software product,expressed
in person months (PMs).
 Estimation Of Development Effort

 For the three classes of software products, the formulas for estimating the effort
based on the code size are shown below:

o Organic:
Effort = 2.4(KLOC) 1.05 PM

o Semi-detached:
Effort = 3.0(KLOC) 1.12 PM

o Embedded:

Effort = 3.6(KLOC) 1.20 PM

 Estimation Of Development Time

 For the three classes of software products, the formulas for estimating
thedevelopment time based on the effort are given below:

o Organic:
Tdev = 2.5(Effort) 0.38 Months

o Semi-detached:
 Tdev = 2.5(Effort) 0.35 Months

o Embedded:
Tdev = 2.5(Effort) 0.32 Months

Example: Suppose a project was estimated to be 400 KLOC. Calculate the effort and
development time for each of the three model i.e., organic,semi-detached & embedded.

The basic COCOMO equation takes the form:

Effort=a1*(KLOC) a2 PM

Tdev=b1*(efforts)b2 Months

Estimated Size of project= 400 KLOC

(1) Organic Mode

E = 2.4 * (400)1.05 = 1295.31 PM

D = 2.5 * (1295.31)0.38=38.07 PM

(2) Semidetached Mode

E = 3.0 * (400)1.12=2462.79 PM

D = 2.5 * (2462.79)0.35=38.45 PM

(3) Embedded Mode

E = 3.6 * (400)1.20 = 4772.81 PM

D = 2.5 * (4772.8)0.32 = 38 PM

 Intermediate Model:
 The basic Cocomo model considers that the effort is only a function of the number of
lines of code and some constants calculated according to the various software systems.

 The intermediate COCOMO model recognizes these facts and refines theinitial estimates
obtained through the basic COCOMO model by using a set of 15 cost drivers based on
various attributes of software engineering.

 Classification of Cost Drivers and their attributes:

(i) Product attributes -

o Required software reliability extent
o Size of the application database
o The complexity of the product

(ii) Hardware attributes -

o Run-time performance constraints(Execution Speed)
o Memory constraints
o The volatility of the virtual machine environment
o Required turn about time

(iii) Personnel attributes -

o Analyst capability
o Software engineering capability
o Applications experience
o Virtual machine experience
o Programming language experience

(iv) Project attributes -

o Use of software tools
o Application of software engineering methods
o Required development schedule