LAB MANUAL

Of

Software Engineering

Academic Year 2017-18

Semester VI
Department Computer Engineering
Syllabus Revision Year 2016

RIZVI EDUCATION SOCIETY’s

Rizvi College of Engineering

Off Carter Road, Bandra West, Mumbai- 400050

1|Page
Software Engineering Course Code: CSC601

 Program Objectives

PO1 Engineering knowledge: Apply the knowledge of mathematics, science, engineering

fundamentals, and an engineering specialization to the solution of complex engineering
problems.
PO2 Problem analysis: Identify, formulate, review research literature, and analyse complex
engineering problems reaching substantiated conclusions using first principles of
mathematics, natural sciences, and engineering sciences.
PO3 Design/development of solutions: Design solutions for complex engineering problems and
design system components or processes that meet the specified needs with appropriate
consideration for the public health and safety, and the cultural, societal, and environmental
considerations.
PO4 Conduct investigations of complex problems: Use research-based knowledge and
research methods including design of experiments, analysis and interpretation of data ,and
synthesis of the information to provide valid conclusions.
PO5 Modern tool usage: Create, select, and apply appropriate techniques, resources, and
modern engineering and IT tools including prediction and modelling to complex
engineering activities with an understanding of the limitations.
PO6 The engineer and society: Apply reasoning informed by the contextual knowledge to
assess societal, health, safety, legal and cultural issues and the consequent responsibilities
relevant to the professional engineering practice.
PO7 Environment and sustainability: Understand the impact of the professional engineering
solutions in societal and environmental contexts, and demonstrate the knowledge of, and
need for sustainable development.
PO8 Ethics: Apply ethical principles and commit to professional ethics and responsibilities and
norms of the engineering practice.
PO9 Individual and team work: Function effectively as an individual, and as a member or
leader in diverse teams, and in multidisciplinary settings.
PO10 Communication: Communicate effectively on complex engineering activities with the
engineering community and with society at large, such as, being able to comprehend and
write effective reports and design documentation, make effective presentations, and give
and receive clear instructions.
PO11 Project management and finance: Demonstrate knowledge and understanding of the
engineering and management principles and apply these to one’s own work, as a member
and leader in a team, to manage projects and in multi-disciplinary environments.
PO12 Life-long learning: Recognize the need for, and have the preparation and ability to engage
in independent and life-long learning in the broadest context of technological change.

 Program Specific Objectives

PSO1 Professional & Problem-Solving Skills: The ability to understand and analyse the problem
and develop algorithms & programs for the same, with efficient design and varying
complexity using lifelong learning and principles of computer engineering in the fields of
multimedia, web design, data management & analytics, networking &security, machine
learning & artificial intelligence etc. To apply standard practices and strategies in software
& hardware project development using open-source programming environments to deliver
a quality product for business success.
PSO2 Successful Career and Entrepreneurship: Ability to acquire logical thinking capability
and problem solving skill in computer engineering as well as diverse fields to achieve better
overall prospects of the employment or to be a successful entrepreneur and work as an
individual and as well as in a team to achieve solution within the budget and to communicate
effectively with the engineering community and the society and also to have a zest for higher
studies.

2|Page
Software Engineering Course Code: CSC601

 Course Objectives

The main objective of the course is to introduce to the students about the product that is to be
engineered and the processes that provides a framework for the engineering methodologies
and practices.
1. To provide the knowledge of software engineering discipline.
2. To apply analysis, design and testing principles to software project development.
3. To demonstrate and evaluate real time projects with respect to software engineering
principles.

 Course Outcomes

CO 1 Understand and demonstrate basic knowledge in software engineering.

CO 2 Identify requirements, analyse and prepare models.
CO 3 Plan, schedule and track the progress of the projects.
CO 4 Design & develop the software projects.
CO 5 Identify risks, manage the change to assure quality in software
projects.
CO 6 Apply testing principles on software project and understand the
maintenance concepts.

3|Page
Software Engineering Course Code: CSC601

INDEX
Sr. No. Name of Experiment Page No.
Prepare detailed statement (SRS) of problem for the selected / allotted 6-9
mini project and identify
1
suitable process model for the same with justification.

2 To study RMMM 10-12

3 Use project management tool to schedule project plan 13-19
4 Identify scenarios & develop UML Use case for the given scenarios 20-25
5 To develop class diagram for the given scenarios 26-32
6 To develop sequence diagram for the given scenarios 33-38
7 Develop Activity / State Transition diagram for the given scenarios 38-44
8 To study COCOMO model 45-48
9 To design test cases 49-52
10 To study Bug tracking tool 53-56

4|Page
Software Engineering Course Code: CSC601

Attainment of PO’s & PSO’s

Sr. Name of Experiment PO’s Attained PSO’s Attained
No.
Prepare detailed statement (SRS) of problem for PO1,PO2, PO9 PSO1
the selected / allotted mini project and identify
1 suitable process model for the same with
justification.

2 To study RMMM PO1 PSO1

Use project management tool to schedule project PO5, PO9, PSO2
3 PO11
plan
Identify scenarios & develop UML Use case for PO2, PO3, PSO1
4 PO5
the given scenarios
PO2, PO3, PSO1
5 To develop class diagram for the given scenarios PO5
To develop sequence diagram for the given PO2, PO3, PSO1
6 PO5
scenarios
Develop Activity / State Transition diagram for PO2, PO3, PSO1
7 PO5
the given scenarios
8 To study COCOMO model PO1 PSO1
PO2, PO3, PSO2
9 To design test cases PO9
10 To study Bug tracking tool PO1, PO5 PSO1

5|Page
Software Engineering Course Code: CSC601

Experiment No. 1

Title: Software Requirement Specification.

Date : ____ / ____ / ________

Subject In-charge Sign:

…………………………….

6|Page
Software Engineering Course Code: CSC601

Experiment No. 1
Aim: To learn Software Requirement Specification (SRS) and design the documentation for
given project.

Background: A software requirement specification (SRS) is a comprehensive description of

the intended purpose and environment for software under development. The SRS fully
describes what the software will do and how it will be expected to perform.

SRS Format:
The general format of SRS consists of:
i. Functional Requirements Definition
➢Functional requirements are a subset of the overall system requirement.

➢These requirements are used to consider system behavior.

➢Trade-offs may be between hardware and software issues.

ii. Non-functional Requirements Definition

➢It measures the documentation and the inputs for the various requirements
In thesystem.

iii. System Evolution

➢Starting from the specification and the data base schema, on how the
System should bedesigned.

4. SRS Template for documentation

<Project Name>

Software Requirements
Specification

<Version>

<Date>

<Your Name>

1.0.
Introduction

1.1 Purpose

7|Page
Software Engineering Course Code: CSC601

1.2 Scope of Project

3
1.3
Glossary

Term Definition

1.4 References

1.5 Overview

2.0. Overall
Description

2.1 Product Perspective

2.2 Product Functions

2.3 User Characteristics

2.4 Constraints

2.5 Assumptions and Dependencies

3.0. Specific
Requirements

3.1 Functional Requirements

Report
Generation:

Database:

3.2 Performance Requirements

3.3 Non - Functional Requirements

3.4 Diagrams: Use – Case, UML as per the requirement of the project.

Problem Statement: Design a SRS for any one of the systems and develop the documentation
as given in the SRS template (Any other system that student can take)

1. Library management system

2. Railway reservation system

3. Online ticket booking system

4. Hospital management system

8|Page
Software Engineering Course Code: CSC601

5. Student admission system

6. College administration system

Pre Lab Questions:

1. What is a Software?
2. What is Software Engineering?
3. Define Waterfall Model. Or. What are the steps of developing a software?
Post Lab Questions:
1. Define SRS.
2. What is the structure of SRS?
3. Why do we need SRS?
Conclusion: Thus the SRS for the given system has been designed and documented.

9|Page
Software Engineering Course Code: CSC601

Experiment No. 2

Title: To Study RMMM.

Date : ____ / ____ / ________

Subject In-charge Sign:

…………………………….

10 | P a g e
Software Engineering Course Code: CSC601

Experiment No. 2
Aim: To study RMMM RISK MANAGEMENT

Theory:
What is it?
• Analysis and management are a serious of steps that helps a software team to understand
and manage uncertainty.
• Many problems can plague a software project.
• A risk is a potential problem ‐ it might happen, it might not. But, regardless of the
outcomes, it’s a really good idea to identify it assess its probability of occurrence, estimate its
impact, and establish a contingency plan should the problem actually occur.
Why is it important?
Be prepared software is a difficult under taking. Lots of things can go wrong, and frankly,
many often do. It’s for this reason that being prepared‐ understanding the risk and taking
proactive measures to avoid or manage them‐is a key element of good software project
management [1]
A risk management strategy can be defined as a software project plan or the risk management
steps. It can be organized into a separate Risk Mitigation, Monitoring and Management Plan.
The RMMM plan documents all work performed as part of risk analysis and is used by the
project manager as part of the overall project plan.
Teams do not develop a formal RMMM document. Rather, each risk is documented
individually using a risk information sheet. In most cases, the RIS is maintained using a
database system, so that creation and information entry, priority ordering, searches, and other
analysis may be accomplished easily.
Once RMMM has been documented and the project has begun, risk mitigation and
monitoring steps commence. As we have already discussed, risk mitigation is a problem
avoidance activity. Risk monitoring is a project tracking activity with three primary
objectives:
(1) To assess whether predicted risks occur.
(2) To ensure that risk aversion steps defined for the risk are being properly applied; and
(3) To collect information that can be used for future risk analysis.
Effective strategy must consider three issues:
 Risk avoidance
 Risk monitoring
 Risk management and contingency planning. Proactive approach to risk – avoidance
strategy. Develop risk mitigation plan. Develop a strategy to mitigate this risk for

11 | P a g e
Software Engineering Course Code: CSC601

reducing turnover. Meet with current staff to determine causes for turnover. Mitigate
those causes that are under our control before the project starts.
 Organize project teams so that information about each development activity is widely
dispersed.
 Define documentation standards and establish mechanisms to be sure that documents
are developed in a timely manner. Project manager monitors for likelihood of risk,
Project manager should monitor the effectiveness of risk mitigation steps. Risk
management and contingency planning assumes that mitigation efforts have failed and
that the risk has become a reality. RMMM steps incur additional project cost.
THE RMMM PLAN
Risk Mitigation, Monitoring and Management Plan (RMMM) – documents all work
performed as part of risk analysis and is used by the project manager as part of the overall
project plan. RIS is maintained using a database system, so that creation and information
entry, priority ordering, searches, and other analysis may be accomplished easily. Risk
monitoring is a project tracking activity
Three primary objectives:
 assess whether predicted risks do, in fact, occur
 ensure that risk aversion steps defined for the risk are being properly applied
 collect information that can be used for future risk analysis.[2]
REFRENCES
http://cmstest.srmuniv.ac.in/sites/default/files/files/Risk%20Management.pdf
http://www.ques10.com/p/24877/explain-rmmm-also-explain-rmmm-plan/
Pre Lab Questions:
1. What are the steps in developing a software?
2. What are the steps involved in developing a SRS?

Post Lab Questions:

1. Define RMMM
2. What are the possible risks involved in software development?
3. How to overcome Risk in software development? Or. What is RMMM Plan?

Conclusion: Thus we have studied Risk Management, Mitigation and Monitoring.

12 | P a g e
Software Engineering Course Code: CSC601

Experiment No. 3

Title: Use Project Management Tool to Schedule

Project Plan

Date : ____ / ____ / ________

Subject In-charge Sign:

…………………………….

13 | P a g e
Software Engineering Course Code: CSC601

Aim: To Use Project Management Tool to Schedule Project Plan

Software Used: MS Project 2016

Theory: Microsoft Project is a project management software product, developed and sold
by Microsoft. It is designed to assist a project manager in developing a plan,
assigning resources to tasks, tracking progress, managing the budget, and analysing workloads.
Microsoft Project was the company's third Microsoft Windows-based application, and within
a couple of years of its introduction it became the dominant PC-based project management
software.[1]
It is part of the Microsoft Office family but has never been included in any of the Office suites.
It is available currently in two editions, Standard and Professional. Microsoft
Project's proprietary file format is .mpp.

Features of Microsoft project

Project creates budgets based on assignment work and resource rates. As resources are assigned
to tasks and assignment work estimated, the program calculates the cost, equal to the work
times the rate, which rolls up to the task level and then to any summary tasks and finally to the
project level. Resource definitions (people, equipment and materials) can be shared between
projects using a shared resource pool. Each resource can have its own calendar, which defines
what days and shifts a resource is available. Resource rates are used to calculate resource
assignment costs which are rolled up and summarized at the resource level. Each resource can
be assigned to multiple tasks in multiple plans and each task can be assigned multiple resources,
and the application schedules task work based on the resource availability as defined in the
resource calendars. All resources can be defined in label without limit. Therefore, it cannot
determine how many finished products can be produced with a given amount of raw materials.
This makes Microsoft Project unsuitable for solving problems of available materials
constrained production. Additional software is necessary to manage a complex facility that
produces physical goods.
The application creates critical path schedules, and critical chain and event chain
methodology third-party add-ons also are available. Schedules can be resource levelled, and
chains are visualized in a Gantt chart. Additionally, Microsoft Project can recognize different
classes of users. These different classes of users can have differing access levels to projects,
views, and other data. Custom objects such as calendars, views, tables, filters, and fields are
stored in an enterprise global which is shared by all users.

14 | P a g e
Software Engineering Course Code: CSC601

Screenshots:
Task View

15 | P a g e
Software Engineering Course Code: CSC601

Gantt Chart

Network Chart

16 | P a g e
Software Engineering Course Code: CSC601

Resource Sheet

Project Overview

Work Overview

17 | P a g e
Software Engineering Course Code: CSC601

Cost Overview

Pre Lab Questions:

1. What are the steps to build a project?
2. How can you avoid risk in a project?

Post Lab Questions:

18 | P a g e
Software Engineering Course Code: CSC601

1. What do you mean by project management?

2. What measures can be taken to prevent from exceeding the cost of the project?
3. What measures can be taken to complete the project on time?
Conclusion: Thus the project has been scheduled using MS project 2016.

19 | P a g e
Software Engineering Course Code: CSC601

Experiment No. 4

Title: Develop UML Use cases for the given

Scenarios.

Date : ____ / ____ / ________

Subject In-charge Sign:

…………………………….

20 | P a g e
Software Engineering Course Code: CSC601

Aim: Identify the scenarios & develop UML Use-case for the given scenarios:
1. Airport Check-in and Security Screening
2. Restaurant Management
3. Ticket Booking System
4. Bank ATM
5. Library Management System
6. Online Shopping
7. Credit Card Processing
8. Hospital Management System

Software Used: Rational Rose

Theory:

A use case diagram at its simplest is a representation of a user's interaction with the system
that shows the relationship between the user and the different use cases in which the user is
involved. A use case diagram can identify the different types of users of a system and the
different use cases and will often be accompanied by other types of diagrams as well. The use
cases are represented by either circles or ellipses.

The purpose of the use case diagrams is simply to provide the high level view of the system
and convey the requirements in laypeople's terms for the stakeholders. Additional diagrams
and documentation can be used to provide a complete functional and technical view of the
system.

Screenshots:

Airport Check-in and Security Screening

21 | P a g e
Software Engineering Course Code: CSC601

Resturant Management

Ticket Booking System

22 | P a g e
Software Engineering Course Code: CSC601

Bank ATM

Library Management System

23 | P a g e
Software Engineering Course Code: CSC601

Online Shopping System

Credit card Processing

24 | P a g e
Software Engineering Course Code: CSC601

Hospital Management System

Pre Lab Questions:

1. What is a use case diagram?
2. What is the purpose of use case diagram?
Post Lab Questions:
1. Who is an actor? What is his role?
2. What are the components of use case diagram?

Conclusion: Thus the UML Use-case Diagrams haven been developed for the given scenarios.

25 | P a g e
Software Engineering Course Code: CSC601

Experiment No. 5

Title: Develop UML Class Diagrams for the

given Scenarios.

Date : ____ / ____ / ________

Subject In-charge Sign:

…………………………….

26 | P a g e
Software Engineering Course Code: CSC601

Aim: Identify the scenarios & develop UML Class Diagrams for the given scenarios:
1. Airport Check-in and Security Screening
2. Restaurant Management
3. Ticket Booking System
4. Bank ATM
5. Library Management System
6. Online Shopping
7. Credit Card Processing
8. Hospital Management System

Software Used: Rational Rose

Theory:
In software engineering, a class diagram in the Unified Modeling Language (UML) is a type
of static structure diagram that describes the structure of a system by showing the
system's classes, their attributes, operations (or methods), and the relationships among objects.
The class diagram is the main building block of object-oriented modeling. It is used for
general conceptual modeling of the structure of the application, and for detailed modeling
translating the models into programming code. Class diagrams can also be used for data
modelling. The classes in a class diagram represent both the main elements, interactions in the
application, and the classes to be programmed.
In the diagram, classes are represented with boxes that contain three compartments:

 The top compartment contains the name of the class. It is printed in bold and centered, and
the first letter is capitalized.
 The middle compartment contains the attributes of the class. They are left-aligned and the
first letter is lowercase.
 The bottom compartment contains the operations the class can execute. They are also left-
aligned and the first letter is lowercase.
In the design of a system, a number of classes are identified and grouped together in a class
diagram that helps to determine the static relations between them. With detailed modelling, the
classes of the conceptual design are often split into a number of subclasses.

27 | P a g e
Software Engineering Course Code: CSC601

Screenshots:
Airport Check-in and Security Screening

Resturant Management

28 | P a g e
Software Engineering Course Code: CSC601

Ticket Booking System

Bank ATM

29 | P a g e
Software Engineering Course Code: CSC601

Library Management System

Online Shopping System

30 | P a g e
Software Engineering Course Code: CSC601

Credit card Processing

Hospital Management System

Pre Lab Questions:

1. What is a class diagram?
2. What is the purpose of class diagram?
Post Lab Questions:
1. Define a class.
2. What are the components of class diagram?
Conclusion: Thus the UML Class Diagrams haven been developed for the given scenarios.

31 | P a g e
Software Engineering Course Code: CSC601

Experiment No. 6

Title: Develop UML Sequence Diagrams for the

given Scenarios.

Date : ____ / ____ / ________

Subject In-charge Sign:

…………………………….

32 | P a g e
Software Engineering Course Code: CSC601

Aim: Identify the scenarios & develop UML Sequence Diagrams for the given scenarios:
1. Airport Check-in and Security Screening
2. Restaurant Management
3. Ticket Booking System
4. Bank ATM
5. Library Management System
6. Online Shopping
7. Credit Card Processing
8. Hospital Management System

Software Used: Rational Rose

Theory:
A sequence diagram shows object interactions arranged in time sequence. It depicts the objects
and classes involved in the scenario and the sequence of messages exchanged between the
objects needed to carry out the functionality of the scenario. Sequence diagrams are typically
associated with use case realizations in the Logical View of the system under development.
Sequence diagrams are sometimes called event diagrams or event scenarios.
A sequence diagram shows, as parallel vertical lines (lifelines), different processes or objects
that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in
the order in which they occur. This allows the specification of simple runtime scenarios in a
graphical manner.
Screenshots:
Airport Check-in and Security Screening

33 | P a g e
Software Engineering Course Code: CSC601

Resturant Management

Ticket Booking System

34 | P a g e
Software Engineering Course Code: CSC601

Bank ATM

Library Management System

35 | P a g e
Software Engineering Course Code: CSC601

Online Shopping System

Credit card Processing

36 | P a g e
Software Engineering Course Code: CSC601

Hospital Management System

Pre Lab Questions:

1. What is a sequence diagram?
2. What are the purpose of sequence diagram?
Post Lab Questions:
1. What are the components of sequence diagram?

Conclusion: Thus the UML Sequence Diagrams haven been developed for the given scenarios.

37 | P a g e
Software Engineering Course Code: CSC601

Experiment No. 7

Title: Develop UML Activity Diagrams for the

given Scenarios.

Date : ____ / ____ / ________

Subject In-charge Sign:

…………………………….

38 | P a g e
Software Engineering Course Code: CSC601

Aim: Identify the scenarios & develop UML Activity Diagrams for the given scenarios:
1. Airport Check-in and Security Screening
2. Restaurant Management
3. Ticket Booking System
4. Bank ATM
5. Library Management System
6. Online Shopping
7. Credit Card Processing
8. Hospital Management System

Software Used: Rational Rose

Theory:
Activity diagrams are graphical representations of workflows of stepwise activities and
actions with support for choice, iteration and concurrency. In the Unified Modelling Language,
activity diagrams are intended to model both computational and organizational processes (i.e.,
workflows), as well as the data flows intersecting with the related activities. Although activity
diagrams primarily show the overall flow of control, they can also include elements showing
the flow of data between activities through one or more data stores.
Activity diagrams are constructed from a limited number of shapes, connected with
arrows. The most important shape types:

 ellipses represent actions;

 diamonds represent decisions;
 bars represent the start (split) or end (join) of concurrent activities;
 a black circle represents the start (initial node) of the workflow;
 An encircled black circle represents the end (final node).
Arrows run from the start towards the end and represent the order in which activities happen.

39 | P a g e
Software Engineering Course Code: CSC601

Screenshots:
Airport Check-in and Security Screening

Resturant Management

40 | P a g e
Software Engineering Course Code: CSC601

Ticket Booking System

Bank ATM

41 | P a g e
Software Engineering Course Code: CSC601

Library Management System

Online Shopping System

42 | P a g e
Software Engineering Course Code: CSC601

Credit card Processing

Hospital Management System

43 | P a g e
Software Engineering Course Code: CSC601

Pre Lab Questions:

1. What is activity diagram?
2. What is the purpose of activity diagram?
Post Lab Questions:
1. At what stage in the project activity diagram is build?
2. What are components of activity diagram?

Conclusion: Thus the UML Activity Diagrams haven been developed for the given scenarios.

44 | P a g e
Software Engineering Course Code: CSC601

Experiment No. 8

Title: Study of COCOMO model.

Date : ____ / ____ / ________

Subject In-charge Sign:

…………………………….

45 | P a g e
Software Engineering Course Code: CSC601

Aim: To study COCOMO Model.

Theory:
The Constructive Cost Model (COCOMO) is a procedural software cost estimation
model developed by Barry W. Boehm. The model parameters are derived from fitting
a regression formula using data from historical projects
The constructive cost model was developed by Barry W. Boehm in the late 1970 and published
in Boehm's 1981 book Software Engineering Economics as a model for estimating effort, cost,
and schedule for software projects. It drew on a study of 63 projects at TRW Aerospace where
Boehm was Director of Software Research and Technology. The study examined projects
ranging in size from 2,000 to 100,000 lines of code, and programming languages ranging
from assembly to PL/I. These projects were based on the waterfall model of software
development which was the prevalent software development process in 1981.
References to this model typically call it COCOMO 81. In 1995 COCOMO II was developed
and finally published in 2000 in the book Software Cost Estimation with COCOMO
II.[3]COCOMO II is the successor of COCOMO 81 and is claimed to be better suited for
estimating modern software development projects; providing support for more recent software
development processes and was tuned using a larger database of 161 projects. The need for the
new model came as software development technology moved from mainframe and overnight
batch processing to desktop development, code reusability, and the use of off-the-shelf
software components.
COCOMO consists of a hierarchy of three increasingly detailed and accurate forms. The first
level, Basic COCOMO is good for quick, early, rough order of magnitude estimates of software
costs, but its accuracy is limited due to its lack of factors to account for difference in project
attributes (Cost Drivers). Intermediate COCOMO takes these Cost Drivers into account
and Detailed COCOMO additionally accounts for the influence of individual project phases.
Intermediate COCOMO computes software development effort as function of program size
and a set of "cost drivers" that include subjective assessment of product, hardware, personnel
and project attributes. This extension considers a set of four "cost drivers", each with a
number of subsidiary attributes:-

 Product attributes
 Required software reliability extent
 Size of application database
 Complexity of the product
 Hardware attributes
 Run-time performance constraints
 Memory constraints
 Volatility of the virtual machine environment
 Required turnabout time
 Personnel attributes
 Analyst capability
 Software engineering capability
 Applications experience
 Virtual machine experience
 Programming language experience

46 | P a g e
Software Engineering Course Code: CSC601

 Project attributes
 Use of software tools
 Application of software engineering methods
 Required development schedule
Each of the 15 attributes receives a rating on a six-point scale that ranges from "very low" to
"extra high" (in importance or value). An effort multiplier from the table below applies to the
rating. The product of all effort multipliers results in an effort adjustment factor (EAF).
Typical values for EAF range from 0.9 to 1.4.

The Intermediate COCOMO formula now takes the form:

E=ai(KLoC)(bi)(EAF)
where E is the effort applied in person-months, KLoC is the estimated number of
thousands of delivered lines of code for the project, and EAF is the factor calculated above.
The coefficient ai and the exponent bi are given in the next table

The Development time D calculation uses E in the same way as in the Basic COCOMO.

47 | P a g e
Software Engineering Course Code: CSC601

Pre Lab Questions:

1. Why is cost estimation important for a project?
2. At which stage of the project the cost estimation should be done?
Post Lab Questions:
1. Define COCOMO.
2. What is the purpose of COCOMO?
3. What are other cost estimation models?
Conclusion: Thus, we have studied the COCOMO Model.

48 | P a g e
Software Engineering Course Code: CSC601

Experiment No. 9

Title: To write test case on a given topic.

Date : ____ / ____ / ________

Subject In-charge Sign:

…………………………….

49 | P a g e
Software Engineering Course Code: CSC601

Aim: To write test case on a given topic

Theory: A test case is a specification of the inputs, execution conditions, testing procedure,
and expected results that define a single test to be executed to achieve a particular software
testing objective, such as to exercise a particular program path or to verify compliance with a
specific requirement.[1] Test cases underlie testing that is methodical rather than haphazard. A
battery of test cases can be built to produce the desired coverage of the software being tested.
Formally defined test cases allow the same tests to be run repeatedly against successive
versions of the software, allowing for effective and consistent regression testing.

Formal test cases

In order to fully test that all the requirements of an application are met, there must be at least
two test cases for each requirement: one positive test and one negative test. If a requirement
has sub-requirements, each sub-requirement must have at least two test cases. Keeping track
of the link between the requirement and the test is frequently done using a traceability matrix.
Written test cases should include a description of the functionality to be tested, and the
preparation required to ensure that the test can be conducted.
A formal written test-case is characterized by a known input and by an expected output, which
is worked out before the test is executed. The known input should test a precondition and the
expected output should test a post condition.

Informal test cases

For applications or systems without formal requirements, test cases can be written based on the
accepted normal operation of programs of a similar class. In some schools of testing, test cases
are not written at all but the activities and results are reported after the tests have been run.
In scenario testing, hypothetical stories are used to help the tester think through a complex
problem or system. These scenarios are usually not written down in any detail. They can be as
simple as a diagram for a testing environment or they could be a description written in prose.
The ideal scenario test is a story that is motivating, credible, complex, and easy to evaluate.
They are usually different from test cases in that test cases are single steps while scenarios
cover a number of steps of the key.

Typical written test case format

A test case is usually a single step, or occasionally a sequence of steps, to test the correct
behaviour/functionality, features of an application. An expected result or expected outcome is
usually given.
Additional information that may be included:

 test case ID
 test case description
 test step or order of execution number
 related requirement(s)

50 | P a g e
Software Engineering Course Code: CSC601

 depth
 test category
 author
 check boxes for whether the test can be or has been automated
 pass/fail
 remarks
Larger test cases may also contain prerequisite states or steps, and descriptions.
A written test case should also contain a place for the actual result.
These steps can be stored in a word processor document, spreadsheet, database or other
common repository.
In a database system, you may also be able to see past test results and who generated the results
and the system configuration used to generate those results. These past results would usually
be stored in a separate table.
Test suites often also contain

 Test summary
 Configuration
Besides a description of the functionality to be tested, and the preparation required to ensure
that the test can be conducted, the most time consuming part in the test case is creating the tests
and modifying them when the system changes.
Under special circumstances, there could be a need to run the test, produce results, and then a
team of experts would evaluate if the results can be considered as a pass. This happens often
on new products' performance number determination. The first test is taken as the base line for
subsequent test / product release cycles.
Acceptance tests, which use a variation of a written test case, are commonly performed by a
group of end-users or clients of the system to ensure the developed system meets the
requirements specified or the contract. User acceptance tests are differentiated by the inclusion
of happy path or positive test cases to the almost complete exclusion of negative test cases.
Topics: Write a test case on:
1. Pen
2. Login Page
3. Lift
4. Gmail
5. ATM
6. Android Phone
7. Bottle
Pre Lab Questions:
1. What is Software Testing?
2. Why is testing of software important?
Post Lab Questions:

51 | P a g e
Software Engineering Course Code: CSC601

1. What is test case and test bed?

2. What is a test suite?
3. What is the structure of writing a test case?

Conclusion: Thus we have studied how to write test cases.

52 | P a g e
Software Engineering Course Code: CSC601

Experiment No. 10

Title: To Study Bug Tracking Tool.

Date : ____ / ____ / ________

Subject In-charge Sign:

…………………………….

53 | P a g e
Software Engineering Course Code: CSC601

Aim: To study Bug Tracking Tool

What is Bugzilla?

Bugzilla is server software designed to help you manage software development. It is a

very popular, actively maintained and free bug tracking system, used and developed together
with Mozilla, giving it considerable credibility. Bugzilla is based on Perl and once it is set up,
it seems to make its users pretty happy. It’s not highly customizable, but in a odd way, that
may be one of its features: Bugzilla installations tend to look pretty much the same wherever
they are found, which means many developers are already accustomed to its interface and will
feel they are in familiar territory. Bugzilla has a system that will send you, another user, or a
group that you specify the results of a particular search on a schedule that you specify. Bugzilla
has very advanced reporting systems and you can create different types of charts including line
graph, bar graph or pie chart.

Features:

 Optimized database structure for increased performance and scalability

 Excellent security to protect confidentiality
 Advanced query tool that can remember your searches
 Integrated email capabilities
 Editable user profiles and comprehensive email preferences
 Comprehensive permissions system
 Proven under fire as Mozilla's bug tracking system

Requirements:

Bugzilla's system requirements include:

 A compatible database management system
 A suitable release of Perl 5
 An assortment of Perl modules
 A compatible web server
 A suitable mail transfer agent, or any SMTP server

Currently supported database systems are MySQL, PostgreSQL, Oracle, and SQLite. Bugzilla
is usually installed on Linux using the Apache HTTP Server, but any web server that
supports CGI such as Lighttpd, Hiawatha, Cherokee can be used. Bugzilla's installation
process is command line driven and runs through a series of stages where system requirements
and software capabilities are checked.

History of Bugzilla:

Bugzilla was originally devised by Terry Weissman in 1998 for the

nascent Mozilla.org project, as an open source application to replace the in-house system then
in use at Netscape Communications for tracking defects in the Netscape Communicator suite.

54 | P a g e
Software Engineering Course Code: CSC601

 Bugzilla 2.0 was the result of that port to Perl, and the first version was released to the
public via anonymous CVS.
 Bugzilla 3.0 was released on May 10, 2007 and brought refreshed UI, XML-
RPC interface, custom fields and resolutions, mod_perl support, shared saved searches,
and improved UTF-8 support, along with other changes.
 Bugzilla 4.0 was released on February 15, 2011 and Bugzilla 5.0 was released in July
2015.

Benefits of using Bugzilla:

 Improve communication
 Increase product quality
 Improve customer satisfaction
 Ensure accountability
 Increase productivity
 Bugzilla can adapt to multiple situations

The software isn't designed to diagnose or repair developed applications; however, users can
categorize, track and detail debugging procedures -- and other similar actions. This can be done
in both the predevelopment and post-development stages of the application. Additionally,
collaboration and reporting features simplify defect tracking, reduce deployment delays and
prevent app downtime.

The Bugzilla issue tracking system contains an interactive tracking spreadsheet that allows
users to submit new bug reports or other data that requires tracking or updating. The
spreadsheets provide options for basic information such as title, summary, description, status,
severity and resolution, but they also allow for more detailed input such as product, component,
version, operating system and keywords. Users can also use the Bugzilla tool to assign a bug
submission so they are notified of future changes to the report -- like when a resolution to the
bug is found.

Another useful feature of the Bugzilla software is automatic duplicate detection. If users
attempt to file a duplicate bug in the system, the software automatically checks for similar
existing bugs based off of the previously submitted summary details. If a duplicate bug is
detected, Bugzilla will then notify users and allow them to add themselves to the notification
list for future updates on the bug.
Other notable features offered in the Bugzilla tool include its advanced data reporting tools that
allow users to create custom tables and charts based on bug data, roles-based access modes,
advanced search functions and the ability to create or modify bugs by email. A detailed list of
the tool's features can be seen on the Bugzilla website.

References:

 https://en.wikipedia.org/wiki/Bugzilla
 https://www.bugzilla.org/
 https://searchsoftwarequality.techtarget.com/feature/Track-project-changes-using-the-
Bugzilla-bug-tracking-tool

55 | P a g e
Software Engineering Course Code: CSC601

Pre Lab Questions:

1. What is a bug?
2. What is the difference between bug and failure?
Post Lab Questions:
1. What are the other tools used for bug tracking?
2. What procedure should be followed to report a bug?
3. What measures should be taken once a bug is recorded?

Conclusion: Thus we have studies the bug tracking tool: Bugzilla.

56 | P a g e