14 Lab Manual

SSIT 5TH SEM CE (SE)
SHREE SWAMINARAYAN INSTITUTE OF TECHNOLOGY
GANDHINAGAR, BHAT-382428.
Computer Engineering Department

SOFTWARE ENGINEERING
(3150711)
Laboratory Manual
Year: 2023-2024
Semester-5th
Prepared By: Prof. Khooshabu Vyas

Prof. Darshan Patel
Satsang Shiksha Parishad
Shree Swaminarayan Institute of Technology
Certificate
This is to Certify that Mr./Ms………………………………………………………...
Of Semester……………… and .................................................................................. Branch
Enrollment No ........................................................................................ has satisfactorily completed
his/her Practical and Term Work in the Subject …………………………………………
Academic year of 20 -20
Date of Submission
Subject In-charge Head of the Department
Approved By Principal
INDEX
Sr. No Experiment Signature
1 Study the complete Software Development Life
Cycle (SDLC) and analyze various activities
conducted as a part of various phases.
2 Study of software project management.
3 Study of COCOMO model.
4 Do requirement analysis and develop SRS for

suggested system
5 Design Data Flow Diagram of system.
6 Design Use-case Diagram for system
7 Design Activity Diagram for system.
8 Design Class Diagram for system.
9 Design E-R Diagram for system.
10 Prepare suitable test case for system testing

Experiment No 1
Aim: Study the complete Software Development Life Cycle (SDLC) and analyze various
activities conducted as a part of various phases.
Software life cycle models describe phases of the software cycle and the order in which those
phases are executed. Each phase produces deliverables required by the next phase in the life
cycle. Requirements are translated into design. Code is produced according to the design which
is called development phase. After coding and development the testing verifies the deliverable of
the implementation phase against requirements. The testing team follows Software Testing Life
Cycle (STLC) which is similar to the development cycle followed by the development team.
There are following six phases in every Software development life cycle model:
Requirement gathering and analysis
Design
Implementation or coding
Testing
Deployment
Maintenance
1) Requirement gathering and analysis: Business requirements are gathered in this phase. This
phase is the main focus of the project managers and stake holders. Meetings with managers,
1
stake holders and users are held in order to determine the requirements like; Who is going to use
the system? How will they use the system? What data should be input into the system? What
data should be output by the system? These are general questions that get answered during a
requirements gathering phase. After requirement gathering these requirements are analyzed for
their validity and the possibility of incorporating the requirements in the system to be
development is also studied.
Finally, a Requirement Specification document is created which serves the purpose of guideline
for the next phase of the model. The testing team follows the Software Testing Life Cycle and
starts the Test Planning phase after the requirements analysis is completed.
2) Design: In this phase the system and software design is prepared from the requirement
specifications which were studied in the first phase. System Design helps in specifying hardware
and system requirements and also helps in defining overall system architecture. The system
design specifications serve as input for the next phase of the model.
In this phase the testers comes up with the Test strategy, where they mention what to test, how to
test.
3) Implementation / Coding: On receiving system design documents, the work is divided in

modules/units and actual coding is started. Since, in this phase the code is produced so it is the
main focus for the developer. This is the longest phase of the software development life cycle.
4) Testing: After the code is developed it is tested against the requirements to make sure that the
product is actually solving the needs addressed and gathered during the requirements phase.
During this phase all types of functional testing like unit testing, integration testing, system
testing, acceptance testing are done as well as non-functional testing are also done.
5) Deployment: After successful testing the product is delivered / deployed to the customer for
their use.
As soon as the product is given to the customers they will first do the beta testing. If any changes
are required or if any bugs are caught, then they will report it to the engineering team. Once
those changes are made or the bugs are fixed then the final deployment will happen.
6) Maintenance: Once when the customers starts using the developed system then the actual
problems comes up and needs to be solved from time to time. This process where the care is
taken for the developed product is known as maintenance.
2
Experiment No 2
Aim: Study of software project management.
Project management is solely based on the idea that a project goes through a number a phases
characterized by a distinct set of activities or tasks that take the project from conception to
conclusion. Projects are big and small, with constraints like cost, time and resources. As projects
become more complex, it‟s important to structure and define projects throughout the entire life-
cycle.
At the start of a project, the amount of planning and work required can seem overwhelming.
There may be dozens, or even hundreds of tasks that need to be completed at just the right time
and in just the right sequence.
Seasoned project managers know it is often easier to handle the details of a project and take steps
in the right order when you break the project down into phases. Dividing your project
management efforts into these five phases can help give your efforts structure and simplify them
into a series of logical and manageable steps.
1. Project Initiation
Initiation is the first phase of the project lifecycle. This is where the project‟s value and
feasibility are measured. Project managers typically use two evaluation tools to decide whether
or not to pursue a project:
o Business Case Document – This document justifies the need for the project, and it
includes an estimate of potential financial benefits.
3
o Feasibility Study – This is an evaluation of the project‟s goals, timeline and costs to
determine if the project should be executed. It balances the requirements of the project
with available resources to see if pursuing the project makes sense.
Teams abandon proposed projects that are labeled unprofitable and/or unfeasible. However,
projects that pass these two tests can be assigned to a project team or designated project office.
2. Project Planning
Once the project receives the green light, it needs a solid plan to guide the team, as well as keep
them on time and on budget. A well-written project plan gives guidance for obtaining resources,
acquiring financing and procuring required materials. The project plan gives the team direction
for producing quality outputs, handling risk, creating acceptance, communicating benefits to
stakeholders and managing suppliers.
The project plan also prepares teams for the obstacles they might encounter over the course of
the project, and helps them understand the cost, scope and timeframe of the project.
3. Project Execution
This is the phase that is most commonly associated with project management. Execution is all
about building deliverables that satisfy the customer. Team leaders make this happen by
allocating resources and keeping team members focused on their assigned tasks.
Execution relies heavily on the planning phase. The work and efforts of the team during the
execution phase are derived from the project plan.
4. Project Monitoring and Control
Monitoring and control are sometimes combined with execution because they often occur at the
same time. As teams execute their project plan, they must constantly monitor their own progress.
To guarantee delivery of what was promised, teams must monitor tasks to prevent scope creep,
calculate key performance indicators and track variations from allotted cost and time. This
constant vigilance helps keep the project moving ahead smoothly.
5. Project Closure
Teams close a project when they deliver the finished project to the customer, communicating
completion to stakeholders and releasing resources to other projects. This vital step in the project
lifecycle allows the team to evaluate and document the project and move on the next one, using
previous project mistakes and successes to build stronger processes and more successful teams.
4
Although project management may seem overwhelming at times, breaking it down into these
five distinct cycles can help your team manage even the most complex projects and use time and
resources more wisely.
5
Experiment No 3
Aim: Study of COCOMO model.
Constructive Cost Model (COCOMO)
 COCOMO is one of the most widely used software estimation models in the world.
 This model is developed in 1981 by Barry Boehm to give estimation of number of man-
months it will take to develop a software product.
 COCOMO predicts the efforts and schedule of software product based on size of
software.
 COCOMO has three different models that reflect complexity
1. Basic Model
2. Intermediate Model
3. Detailed Model
 Similarly, there are three classes of software projects.
1. Organic mode In this mode, relatively simple, small software projects with a small team
are handled. Such team should have good application experience to less rigid
requirements.
2. Semi-detached projects In this class intermediate project in which team with mixed
experience level are handled. Such project may have mix of rigid and less than rigid
requirements.
3. Embedded projects In this class, project with tight hardware, software and operational
constraints are handled.
 Each Model in detail
6
1. Basic Model
The basic COCOMO model estimate the software development effort using only Lines of
code
Various equations in this model are
E=abKLOCbbD=cbEdbE=abKLOCbbD=cbEbd
Where, E is the effort applied in person-months,
D is the development time in chronological months and
KLOC is the estimated number of delivered lines of code for the project
2. Intermediate Model
This is extension of COCOMO model.
This estimation model makes use of set of “Cost Driver Attributes” to compute the cost
of software.
I. Product attributes
a. required software reliability
b. size of application data base
c. complexity of the product
II. Hardware attributes
a. run-time performance constraints
b. memory constraints
c. volatility of the virtual machine environment
d. required turnaround time
III. Personnel attributes
a. analyst capability
b. software engineer capability
c. applications experience
7
d. virtual machine experience
e. programming language experience
IV. Project attributes
a. use of software tools
b. application of software engineering methods
c. required development schedule
Each of the 15 attributes is rated on a 6 point scale that ranges from "very low" to "extra
high" (in importance or value).
The intermediate COCOMO model takes the form
E=aiKLOCbi×EAFE=aiKLOCib×EAF
Where, E is the effort applied in person-months and
KLOC is the estimated number of delivered lines of code for the project
3. Detailed COCOMO Model
The detailed model uses the same equation for estimation as the intermediate Model.
But detailed model can estimate the effort (E), duration (D), and person (P) of each of
development phases, subsystem and models.
8
Experiment No 4
Aim: Do requirement analysis and develop SRS for suggested system
LIBRARY INFORMATION SYSTEM
PRODUCT PRESPECTIVE
The proposed Library Management System will take care of the current book detail at any point
of time. The book issue, book return will update the current book details automatically so that
user will get the update current book details.
FUNCTIONAL REQUIREMENT
1. Register
Description : First the user will have to register/sign up. There are two different type of users.
The library manager/head : The manager have to provide details about the name of library
,address, phone number, email id.
Regular person/student : The user have to provide details about his/her name of address, phone
number, email id.
2. Sign up
Input: Detail about the user as mentioned in the description.
Output: Confirmation of registration status and a membership number and password will be
generated and mailed to the user.
Processing: All details will be checked and if any error are found then an error message is
displayed else a membership number and password will be generated.
3. Login
Input: Enter the membership number and password provided.
Output : User will be able to use the features of software.
9
Manage books by user.
1. Books issued.
Description : List of books will be displaced along with data of return.
2. Search
Input : Enter the name of author's name of the books to be issued.
Output : List of books related to the keyword.
3. Issues book
State : Searched the book user wants to issues.
Input : click the book user wants.
Output : conformation for book issue and apology for failure in issue.
Processing : if selected book is available then book will be issued else error will be displayed.
4. Renew book
State : Book is issued and is about to reach the date of return.
Input : Select the book to be renewed.
Output : conformation message.
Processing : If the issued book is already reserved by another user then error message will be
send and if not then conformation message will be displayed.
5. Return
Input ; Return the book to the library.
Output : The issued list will be updated and the returned book will be listed out.
6. Reserve book
Input ; Enter the details of the book.
Output : Book successfully reserved.
10
Description : If a book is issued by someone then the user can reserve it ,so that later the user can
issue it.
6.Fine
Input : check for the fines.
Output : Details about fines on different books issued by the user.
Processing : The fine will be calculated, if it crossed the date of return and the user did not
renewed if then fine will be applied by Rs 10 per day.
Manage book by librarian
1.Update details of books
2.Add books
Input : Enter the details of the books such as names ,author ,edition, quantity.
Output : confirmation of addition.
3. Remove books
Input : Enter the name of the book and quantity of books.
Output : Update the list of the books available.
USER CHARACTERSTICS
We have 3 levels of users :
User module: In the user module, user will check the availability of the books.
 Issue book
 Reserve book
 Return book
 Fine details
Library module:
 Add new book
 Remove books
 Update details of book
11
Administration module:
The following are the sub module in the administration module :
 Register user
 Entry book details
 Book issue
12
Experiment No 5
Aim: Design Data Flow Diagram of system.
Data Flow Diagram:
Data Flow Diagram is a means of representing a system at any level of detail with a graphic
network of symbols showing data flows, data stores, data processes, and data
sources/destinations.
The purpose of data flow diagrams is to provide a semantic bridge between users and systems
developers. The diagrams are:
 graphical, eliminating thousands of words;
 logical representations, modelling WHAT a system does, rather than physical models
showing HOW it does it;
 hierarchical, showing systems at any level of detail; and
 Jargon less, allowing user understanding and reviewing.
The goal of data flow diagramming is to have a commonly understood model of a system. The
diagrams are the basis of structured systems analysis. Data flow diagrams are supported by other
techniques of structured systems analysis such as data structure diagrams, data dictionaries, and
procedure-representing techniques such as decision tables, decision trees, and structured English.
Data Flow Diagrams are composed of the four basic symbols shown below.
The External Entity symbol represents sources of data to the system or destinations of data from
the system.
The Data Flow symbol represents movement of data.
13
The Data Store symbol represents data that is not moving (delayed data at rest).
The Process symbol represents an activity that transforms or manipulates the data (combines,
reorders, converts, etc.).Any system can be represented at any level of detail by these four
symbols.
The procedure for producing a data flow diagram is to:
1. identify and list external entities providing inputs/receiving outputs from system;
2. identify and list inputs from/outputs to external entities;
3. create a context diagram with system at center and external entities sending and receiving
data flows;
4. identify the business functions included within the system boundary;
5. identify the data connections between business functions;
6. confirm through personal contact sent data is received and vice-versa;
7. trace and record what happens to each of the data flows entering the system (data
movement, data storage, data transformation/processing)
8. attempt to connect any diagram segments into a rough draft;
9. verify all data flows have a source and destination;
10. verify data coming out of a data store goes in;
11. redraw to simplify--ponder and question result;
12. review with "informed";
13. explode and repeat above steps as needed.
14
DFD level 0:
Library
Update details of books
Register/login Register/login Member
Issue, search, return, reserve books
Library Management
System
LIBRARY DATABASE
15
Experiment No 6
Aim: Design Use-case Diagram for system
Elements of the use case diagram
 In use case diagrams, we work with the following elements:
Actor
You can picture an actor as a user of the IT system, for example Mr. Steel or Mrs Smith from
check-in. Because individual persons are irrelevant for the model, they are abstracted. So the
actors are called “check-in employee” or “passenger”
Actors represent roles that users take on when they use the IT system, e.g., the role of a check-in
employee. One person can act in more than one role toward the IT system. It is important for the
IT system in which role a person is acting. Therefore, it is necessary to log on to many IT
systems in a certain role, for instance, as a normal user or as an administrator. In each case
access to the appropriate functionalities (use cases) is granted.
Actors themselves are not part of the IT system. However, as employees they can be part of the
business system.
16
Use Case:
Use cases describe the interactions that take place between actors and IT systems during the
execution of business processes:
A use case represents a part of the functionality of the IT system and enables the user (modelled
as an actor) to access this functionality.
Anything that users would like to do with the IT system has to be made available as a use case
(or part of a use case). Functionalities that exist in the IT system, but that are not accessed by
means of use cases, are not available to users.
Even though the idea behind use cases is to describe interactions, flows of batch processing,
which generally do not include interactions, can also be described as use cases. The actor of such
a batch use case is then the one who initiates batch processing. For instance, generating check-in
statistics would be a batch use case.
Association
An association is a connection between an actor and a use case. An association indicates that an
actor can carry out a use case. Several actors at one use case mean that each actor can carry out
the use case on his or her own and not that the actors carry out the use case together:
According to UML, association only means that an actor is involved in a use case. We use
associations in a restricted manner.
Include Relationships
An include relationship is a relationship between two use cases:
17
It indicates that the use case to which the arrow points is included in the use case on the other
side of the arrow. This makes it possible to reuse a use case in another use case. Figure 4.9 shows
an example of this relationship. In the flow of the use case, express check-in is a point at which
the use case generating boarding pass is included. This means that at this point the entire process
generating boarding pass is carried out. Include relationships can be viewed as a type of call to
a subprogram:
Include relationships between use cases
USE CASE MODEL DESCRIPTION:
Use Case selection Description
Use Case name Add student and library record
Level Sub-Functional level
Primary actor Student, Library
Stakeholders and interest Student: wants to register into the system.
Library: wants to register into the system and update

book details.
Administrator: responsible for the management of

the transaction of fine and also login and register
18
details.
Pre-condition Students and Library have submitted their

registration form.
Post-condition Record for a student/library has been added.
Main success scenario 1 Student/Library opens the application to access

the services of the LMS
2 Student/Library sign-up to get registered online.
3 He/She provides correct information and secret

password.
4 He/She got registered.
Alternative flow 1 Student/Library opens the application in their

phone 2 He/She tries to sign-up
3 He/She fails and receives an error
4 He/She will report an error and the error will be

rectified as soon as possible.
Specific requirement  The response time for registration is 1 minute.
 The response time for login is 1 minute
19
USE CASE DIAGRAM
Library information system
login
update book record
«extends» «extends»
library
add book remove book
member
search book
issue book
reserve book
return book
admin
maintain record
fine
«uses» «uses»
bill fine calculation
20
Experiment No 7
Aim: Design Activity Diagram for system.
Activity Diagram:
Activity diagram is another important diagram in UML to describe dynamic aspects of the
system.
Activity diagram is basically a flow chart to represent the flow form one activity to another
activity. The activity can be described as an operation of the system.
So the control flow is drawn from one operation to another. This flow can be sequential,
branched or concurrent. Activity diagrams deals with all type of flow control by using different
elements like fork, join etc.
Purpose:
The basic purposes of activity diagrams are similar to other four diagrams. It captures the
dynamic behaviour of the system. Other four diagrams are used to show the message flow from
one object to another but activity diagram is used to show message flow from one activity to
another.
Activity is a particular operation of the system. Activity diagrams are not only used for
visualizing dynamic nature of a system but they are also used to construct the executable system
by using forward and reverse engineering techniques. The only missing thing in activity diagram
is the message part.
It does not show any message flow from one activity to another. Activity diagram is some time
considered as the flow chart. Although the diagrams looks like a flow chart but it is not. It shows
different flow like parallel, branched, concurrent and single.
So the purposes can be described as:
 Draw the activity flow of a system.
 Describe the sequence from one activity to another.
 Describe the parallel, branched and concurrent flow of the
system. How to draw Activity Diagram?
Activity diagrams are mainly used as a flow chart consists of activities performed by the system.
But activity diagram are not exactly a flow chart as they have some additional capabilities. These
additional capabilities include branching, parallel flow, swim lane etc.
21
Before drawing an activity diagram we must have a clear understanding about the elements used
in activity diagram. The main element of an activity diagram is the activity itself. An activity is a
function performed by the system. After identifying the activities we need to understand how
they are associated with constraints and conditions.
So before drawing an activity diagram we should identify the following elements:
 Activities
 Association
 Conditions
 Constraints
Once the above mentioned parameters are identified we need to make a mental layout of the
entire flow. This mental layout is then transformed into an activity diagram.
The following is an example of an activity diagram for order management system. In the diagram
four activities are identified which are associated with conditions. One important point should be
clearly understood that an activity diagram cannot be exactly matched with the code. The activity
diagram is made to understand the flow of activities and mainly used by the business users.
The following diagram is drawn with the four main activities:
 Send order by the customer 
 Receipt of the order
 Confirm order
 Dispatch order
After receiving the order request condition checks are performed to check if it is normal or
special order. After the type of order is identified dispatch activity is performed and that is
marked as the termination of the process.
22
Where to use Activity Diagrams?
The basic usage of activity diagram is similar to other four UML diagrams. The specific usage is
to model the control flow from one activity to another. This control flow does not include
messages.
The activity diagram is suitable for modelling the activity flow of the system. An application can
have multiple systems. Activity diagram also captures these systems and describes flow from one
system to another. This specific usage is not available in other diagrams. These systems can be
database, external queues or any other system.
Now we will look into the practical applications of the activity diagram. From the above
discussion it is clear that an activity diagram is drawn from a very high level. So it gives high
level view of a system. This high level view is mainly for business users or any other person who
is not a technical person.
This diagram is used to model the activities which are nothing but business requirements. So the
diagram has more impact on business understanding rather implementation details.
Following are the main usages of activity diagram:
 Modelling work flow by using activities.
 Modelling business requirements.
 High level understanding of the system's functionalities. 
 Investigate business requirements at a later stage.
23
24
Experiment No 8
Aim: Design Class Diagram for system.
Class diagram:
The class diagram is a static diagram. It represents the static view of an application. Class
diagram is not only used for visualizing, describing and documenting different aspects of a
system but also for constructing executable code of the software application.
The class diagram describes the attributes and operations of a class and also the constraints
imposed on the system. The class diagrams are widely used in the modelling of object oriented
systems because they are the only UML diagrams which can be mapped directly with object
oriented languages.
The class diagram shows a collection of classes, interfaces, associations, collaborations and
constraints. It is also known as a structural diagram.
Purpose:
The purpose of the class diagram is to model the static view of an application. The class
diagrams are the only diagrams which can be directly mapped with object oriented languages and
thus widely used at the time of construction.
The UML diagrams like activity diagram, sequence diagram can only give the sequence flow of
the application but class diagram is a bit different. So it is the most popular UML diagram in the
coder community.
So the purpose of the class diagram can be summarized as:
 Analysis and design of the static view of an application.
 Describe responsibilities of a system. 
 Base for component and deployment diagrams. 
 Forward and reverse engineering. 
How to draw Class Diagram?
Class diagrams are the most popular UML diagrams used for construction of software
applications. So it is very important to learn the drawing procedure of class diagram.
Class diagrams have lot of properties to consider while drawing but here the diagram will be
considered from a top level view.
25
Class diagram is basically a graphical representation of the static view of the system and
represents different aspects of the application. So a collection of class diagrams represent the
whole system.
The following points should be remembered while drawing a class diagram:
 The name of the class diagram should be meaningful to describe the aspect of the system. 
 Each element and their relationships should be identified in advance.
 Responsibility (attributes and methods) of each class should be clearly identified. 
 For each class minimum number of properties should be specified. Because unnecessary
properties will make the diagram complicated.
 Use notes whenever required to describe some aspect of the diagram. Because at the end
of the drawing it should be understandable to the developer/coder.
 Finally, before making the final version, the diagram should be drawn on plain paper and
rework as many times as possible to make it correct.
Now the following diagram is an example of an Order System of an application. So it describes a

particular aspect of the entire application.
 First of all Order and Customer are identified as the two elements of the system and they
have a one to many relationship because a customer can have multiple orders.
 We would keep Order class is an abstract class and it has two concrete classes
(inheritance relationship) SpecialOrder and NormalOrder.
 The two inherited classes have all the properties as the Order class. In addition they have
additional functions like dispatch () and receive ().
So the following class diagram has been drawn considering all the points mentioned above:
26
Where to use Class Diagrams?
Class diagram is a static diagram and it is used to model static view of a system. The static view
describes the vocabulary of the system.
Class diagram is also considered as the foundation for component and deployment diagrams.
Class diagrams are not only used to visualize the static view of the system but they are also used
to construct the executable code for forward and reverse engineering of any system.
Generally UML diagrams are not directly mapped with any object oriented programming
languages but the class diagram is an exception.
Class diagram clearly shows the mapping with object oriented languages like Java, C++ etc. So
from practical experience class diagram is generally used for construction purpose.
So in a brief, class diagrams are used for:
 Describing the static view of the system. 
 Showing the collaboration among the elements of the static view. 
 Describing the functionalities performed by the system.
 Construction of software applications using object oriented languages.
27
28
Experiment No 9
Aim: Design E-R Diagram for system.
E-R Diagram
29
Experiment No 10
Aim: Prepare suitable test case for system testing
Unit Testing:
Unit testing of software applications is done during the development (coding) of an

application.
The objective of unit testing is to isolate a section of code and verify its correctness. In
procedural programming a unit may be an individual function or procedure
The goal of unit testing is to isolate each part of the program and show that the individual parts
are correct. Unit testing is usually performed by the developer.
Why do Unit Testing? Why it is important? :
Sometimes software developers attempt to save time by doing minimal unit testing. This is a
myth because skimping on unit testing leads to higher defect fixing costs during system testing,
integration testing and even beta testing after the application is completed. Proper unit testing
done during the development stage saves both time and money in the end.
Building unit Test Cases:
Unit testing is commonly automated, but may still be performed manually. The IEEE does not
favour one over the other. A manual approach to unit testing may employ a step-by-step
instructional document.
Under the automated approach-
 A developer could write another section of code in the application just to test the
function. They would later comment out and finally remove the test code when the
application is done.
 They could also isolate the function to test it more rigorously. This is a more thorough
unit testing practice that involves copy and pasting the function to its own testing
environment to other than its natural environment. Isolating the code helps in revealing
unnecessary dependencies between the code being tested and other units or data spaces in
the product. These dependencies can then be eliminated.
30
A coder may use a Unit Test Framework to develop automated test cases. Using an automation
framework, the developer codes criteria into the test to verify the correctness of the unit. During
execution of the test cases, the framework logs those that fail any criterion. Many frameworks
will also automatically flag and report in a summary these failed test cases. Depending upon the
severity of a failure, the framework may halt subsequent testing.
Mock Objects:
Unit testing relies on mock objects being created to test sections of code that are not yet part of a
complete application. Mock objects fill in for the missing parts of the program. For example, you
might have a function that needs variables or objects that are not created yet. In unit testing,
those will be accounted for in the form of mock objects created solely for the purpose of the unit
testing done on that section of code.
Unit testing benefits:
 Developers looking to learn what functionality is provided by a unit and how to use it can
look at the unit tests to gain a basic understanding of the unit API.
 Unit testing allows the programmer to refactor code at a later date, and make sure the
module still works correctly (i.e. Regression testing). The procedure is to write test cases
for all functions and methods so that whenever a change causes a fault, it can be quickly
identified and fixed.
 Due to the modular nature of the unit testing, we can tests parts of project without waiting
for others to be completed.
Integration testing:
In Integration Testing, individual software modules are integrated logically and tested as
a group.
A typical software project consists of multiple software modules, coded by different

programmers. Integration testing focuses on checking data communication amongst these
modules.
Hence it is also termed as ‘I & T’ (Integration and Testing), ‘String Testing’ and
sometimes „Thread Testing‟.
Need of Integration Testing:
Although each software module is unit tested, defects still exist for various reasons like
31
 A Module in general is designed by an individual software developer who understanding

and programming logic may differ from other programmers. Integration testing becomes
necessary to verify the software modules work in unity
 At the time of module development, there wide chances of change in requirements by the
clients. These new requirements may not be unit tested and hence integration testing
becomes necessary.
 Interfaces of the software modules with the database could be erroneous
 External Hardware interfaces, if any, could be erroneous
 Inadequate exception handling could cause issues.
Integration Test Case:
Integration Test case differs from other test cases in the sense it focuses mainly on the
interfaces & flow of data/information between the modules. Here priority is to be given for
the integrating links rather than the unit functions which are already tested.
Sample Integration Test Cases for the following scenario: Application has 3 modules say „Login
Page‟, „Mail box‟ and „Delete mails‟ and each of them are integrated logically.
Here do not concentrate much on the Login Page testing as it‟s already being done. But check
how it‟s linked to the Mail Box Page.
Similarly Mail Box: Check its integration to the Delete Mails Module.
Test Case Test Case Test Case Expected Result

ID Objective Description
1 Check Login Enter login To be directed to the home page

Interface credentials and
click on the
Login button
32
2 Check Interface From books Selected book should disappear

between library select the book from the book list
and delete book and click
delete button
Approaches/Methodologies/Strategies of Integration Testing:
The Software Industry uses variety of strategies to execute Integration testing , viz.
 Big Bang Approach :
 Incremental Approach: which is further divided into following
o Top Down Approach

o Bottom Up Approach
o Sandwich Approach - Combination of Top Down and Bottom Up
Below are the different strategies, the way they are executed and their limitations as well
advantages.
Big Bang Approach:
Here all component are integrated together at once, and then tested.
Advantages:
 Convenient for small systems.
33
Disadvantages:
 Fault Localization is difficult.
 Given the sheer number of interfaces that need to be tested in this approach, some
interfaces links to be tested could be missed easily.
 Since the integration testing can commence only after “all” the modules are designed,
testing team will have less time for execution in the testing phase.
 Since all modules are tested at once, high risk critical modules are not isolated and tested
on priority. Peripheral modules which deal with user interfaces are also not isolated and
tested on priority.
Incremental Approach:
In this approach, testing is done by joining two or more modules that are logically related. Then
the other related modules are added and tested for the proper functioning. Process continues until
all of the modules are joined and tested successfully.
This process is carried out by using dummy programs called Stubs and Drivers. Stubs and
Drivers do not implement the entire programming logic of the software module but just simulate
data communication with the calling module.
Stub: Is called by the Module under Test.
Driver: Calls the Module to be tested.
Incremental Approach in turn is carried out by two different Methods:
o Bottom Up
o Top Down
Bottom up Integration
In the bottom up strategy, each module at lower levels is tested with higher modules until
all modules are tested. It takes help of Drivers for testing
Diagrammatic Representation:
34
Advantages:
 Fault localization is easier.
 No time is wasted waiting for all modules to be developed unlike Big-bang approach
Disadvantages:
 Critical modules (at the top level of software architecture) which control the flow of
application are tested last and may be prone to defects.
 Early prototype is not possible
Top down Integration:
In Top to down approach, testing takes place from top to down following the control flow of the
software system.
Takes help of stubs for testing.
Diagrammatic Representation:
Advantages:
 Fault Localization is easier.
 Possibility to obtain an early prototype.
 Critical Modules are tested on priority; major design flaws could be found and fixed first.
Disadvantages:
 Needs many Stubs.
 Modules at lower level are tested inadequately.
Integration Testing Procedure
The integration test procedure irrespective of the test strategies (discussed above):
1. Prepare the Integration Test Plan
2. Design the Test Scenarios, Cases, and Scripts.
3. Executing the test Cases followed by reporting the defects.
35
4. Tracking & re-testing the defects.
5. Steps 3 and 4 are repeated until the completion of Integration is successfully.
Brief Description of Integration Test Plans:
It includes following attributes:
 Methods/Approaches to test (as discussed above).
 Scopes and Out of Scopes Items of Integration Testing.
 Roles and Responsibilities.
 Pre-requisites for Integration testing.
 Testing environment.
 Risk and Mitigation Plans.
Entry and Exit Criteria:
Entry and Exit Criteria to Integration testing phase in any software development model
Entry Criteria:
 Unit Tested Components/Modules
 All High prioritized bugs fixed and closed
 All Modules to be code completed and integrated successfully.
 Integration test Plan, test case, scenarios to be signed off and documented.
 Required Test Environment to be set up for Integration testing
Exit Criteria:
 Successful Testing of Integrated Application.
 Executed Test Cases are documented
 All High prioritized bugs fixed and closed
 Technical documents to be submitted followed by release Notes.
36
Practical 11
Aim: Study of various CASE tools.
CASE stands for Computer Aided Software Engineering. It means, development and
maintenance of software projects with help of various automated software tools.
CASE Tools
CASE tools are set of software application programs, which are used to automate SDLC
activities. CASE tools are used by software project managers, analysts and engineers to develop
software system.
There are number of CASE tools available to simplify various stages of Software Development
Life Cycle such as Analysis tools, Design tools, Project management tools, Database
Management tools, Documentation tools are to name a few.
Use of CASE tools accelerates the development of project to produce desired result and helps to
uncover flaws before moving ahead with next stage in software development.
Components of CASE Tools
CASE tools can be broadly divided into the following parts based on their use at a particular
SDLC stage:
 Central Repository - CASE tools require a central repository, which can serve as a
source of common, integrated and consistent information. Central repository is a central
place of storage where product specifications, requirement documents, related reports and
diagrams, other useful information regarding management is stored. Central repository
also serves as data dictionary.
37
 Upper Case Tools - Upper CASE tools are used in planning, analysis and design stages
of SDLC.
 Lower Case Tools - Lower CASE tools are used in implementation, testing and
maintenance.
 Integrated Case Tools - Integrated CASE tools are helpful in all the stages of SDLC,
from Requirement gathering to Testing and documentation.
 CASE tools can be grouped together if they have similar functionality, process activities
and capability of getting integrated with other tools.
Scopeof CaseTools
The scope of CASE tools goes throughout the SDLC.
CaseToolsTypes
Now we briefly go through various CASE tools
Diagram tools
These tools are used to represent system components, data and control flow among various
software components and system structure in a graphical form. For example, Flow Chart Maker
tool for creating state-of-the-art flowcharts.
Process Modeling Tools
Process modeling is method to create software process model, which is used to develop the
software. Process modeling tools help the managers to choose a process model or modify it as
per the requirement of software product. For example, EPF Composer
Project Management Tools
These tools are used for project planning, cost and effort estimation, project scheduling and
resource planning. Managers have to strictly comply project execution with every mentioned
step in software project management. Project management tools help in storing and sharing
project information in real-time throughout the organization. For example, Creative Pro Office,
Trac Project, Basecamp.
Documentation Tools
Documentation in a software project starts prior to the software process, goes throughout all
phases of SDLC and after the completion of the project.
Documentation tools generate documents for technical users and end users. Technical users are
mostly in-house professionals of the development team who refer to system manual, reference
manual, training manual, installation manuals etc. The end user documents describe the
38
functioning and how-to of the system such as user manual. For example, Doxygen, DrExplain,
Adobe RoboHelp for documentation.
Analysis Tools
These tools help to gather requirements, automatically check for any inconsistency, inaccuracy in
the diagrams, data redundancies or erroneous omissions. For example, Accept 360, Accompa,
CaseComplete for requirement analysis, Visible Analyst for total analysis.
Design Tools
These tools help software designers to design the block structure of the software, which may
further be broken down in smaller modules using refinement techniques. These tools provides
detailing of each module and interconnections among modules. For example, Animated Software
Design
Configuration Management Tools
An instance of software is released under one version. Configuration Management tools deal
with –
 Version and revision management
 Baseline configuration management
 Change control management
CASE tools help in this by automatic tracking, version management and release management.
For example, Fossil, Git, Accu REV.
Change Control Tools
These tools are considered as a part of configuration management tools. They deal with changes
made to the software after its baseline is fixed or when the software is first released. CASE tools
automate change tracking, file management, code management and more. It also helps in
enforcing change policy of the organization.
Programming Tools
These tools consist of programming environments like IDE (Integrated Development

Environment), in-built modules library and simulation tools. These tools provide comprehensive
aid in building software product and include features for simulation and testing. For example,
Cscope to search code in C, Eclipse.
Prototyping Tools
39
Software prototype is simulated version of the intended software product. Prototype provides
initial look and feel of the product and simulates few aspect of actual product.
Prototyping CASE tools essentially come with graphical libraries. They can create hardware
independent user interfaces and design. These tools help us to build rapid prototypes based on
existing information. In addition, they provide simulation of software prototype. For example,
Serena prototype composer, Mockup Builder.
Web Development Tools
These tools assist in designing web pages with all allied elements like forms, text, script, graphic
and so on. Web tools also provide live preview of what is being developed and how will it look
after completion. For example, Fontello, Adobe Edge Inspect, Foundation 3, Brackets.
Quality Assurance Tools
Quality assurance in a software organization is monitoring the engineering process and methods
adopted to develop the software product in order to ensure conformance of quality as per
organization standards. QA tools consist of configuration and change control tools and software
testing tools. For example, SoapTest, AppsWatch, JMeter.
Software maintenance includes modifications in the software product after it is delivered.

Automatic logging and error reporting techniques, automatic error ticket generation and root
cause Analysis are few CASE tools, which help software organization in maintenance phase of
SDLC. For example, Bugzilla for defect tracking, HP Quality Center.
40

14 Lab Manual

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

14 Lab Manual

Uploaded by

Copyright:

Available Formats

SSIT 5TH SEM CE (SE)

SHREE SWAMINARAYAN INSTITUTE OF TECHNOLOGY

Computer Engineering Department

Prepared By: Prof. Khooshabu Vyas

Of Semester……………… and .................................................................................. Branch

Enrollment No ........................................................................................ has satisfactorily completed

his/her Practical and Term Work in the Subject …………………………………………

Academic year of 20 -20

Subject In-charge Head of the Department

2 Study of software project management.

3 Study of COCOMO model.

4 Do requirement analysis and develop SRS for

5 Design Data Flow Diagram of system.

6 Design Use-case Diagram for system

7 Design Activity Diagram for system.

8 Design Class Diagram for system.

9 Design E-R Diagram for system.

10 Prepare suitable test case for system testing

Requirement gathering and analysis

3) Implementation / Coding: On receiving system design documents, the work is divided in

4. Project Monitoring and Control

Constructive Cost Model (COCOMO)

 Similarly, there are three classes of software projects.

 Each Model in detail

Various equations in this model are

Where, E is the effort applied in person-months,

D is the development time in chronological months and

This is extension of COCOMO model.

a. required software reliability

b. size of application data base

c. complexity of the product

II. Hardware attributes

a. run-time performance constraints

c. volatility of the virtual machine environment

d. required turnaround time

III. Personnel attributes

b. software engineer capability

d. virtual machine experience

e. programming language experience

IV. Project attributes

a. use of software tools

b. application of software engineering methods

c. required development schedule

The intermediate COCOMO model takes the form

Where, E is the effort applied in person-months and

3. Detailed COCOMO Model

LIBRARY INFORMATION SYSTEM

,address, phone number, email id.

Input: Detail about the user as mentioned in the description.

Output : User will be able to use the features of software.

Manage books by user.

Description : List of books will be displaced along with data of return.

Input : Enter the name of author's name of the books to be issued.

Output : List of books related to the keyword.

State : Searched the book user wants to issues.

Input : click the book user wants.

State : Book is issued and is about to reach the date of return.

Input : Select the book to be renewed.

Output : conformation message.

Input ; Return the book to the library.

Input ; Enter the details of the book.

Output : Book successfully reserved.

Input : check for the fines.