Silver Oak College of Engineering

Technology

GUJARAT TECHNOLOGICAL UNIVERSITY

BACHELOR OF ENGINEERING

SOFTWARE ENGINEERING
(3150711)
5th SEMESTER

COMPUTER ENGINEERING DEPARTMENT

Laboratory Manual
 COMPUTER ENGINEERING DEPARTMENT
VISION
To be recognized for the quality education and research in the field of Information Technology
known for its accomplished graduates.
MISSION
The mission of Computer Engineering Department, Silver Oak College of Engineering and
Technology, Ahmedabad is to:
1. Continually improve the standard of our graduates by engaging in innovative teaching
learning methods with high caliber motivated faculty members keeping in-line with the rapid
technological advancements.
2. Promote and support research activities over a wide range of academic interests among
students and staff for growth of individual knowledge and continuous learning.
3. Provide an education system that promotes innovation, creativity, entrepreneurial spirit,
leadership as well as freedom of thought with emphasis on professionalism and ethical
behavior.

Program Educational Objectives (PEO):

PEO1: To provide fundamental knowledge of science and engineering for an IT professional and
equipped with proficiency of mathematical foundations and algorithmic principles and inculcate
competent problem-solving ability.
PEO2: To implant ability in creativity & design of IT systems and transmit knowledge and skills to
analyze, design, test and implement various software applications.
PEO3: To exhibit leadership capability, triggering social and economical commitment and inculcate
community services.
PEO4: To inculcate professional-social ethics, teamwork in students and acquaint them with
requisite technical and managerial skills to attain a successful career.

ii
 PROGRAM OUTCOMES (POs)
Engineering Graduates will be able to:
1. Engineering knowledge: Apply the knowledge of mathematics, science, engineering fundamentals, and an
engineering specialization to the solution of complex engineering problems.
2. Problem analysis: Identify, formulate, review research literature, and analyze complex engineering problems
reaching substantiated conclusions using first principles of mathematics, natural sciences, and engineering
sciences.
3. 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.
4. 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.
5. Modern tool usage: Create, select, and apply appropriate techniques, resources, and modern engineering and IT
tools including prediction and modeling to complex engineering activities with an understanding of the
limitations.
6. 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.
7. 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.
8. Ethics: Apply ethical principles and commit to professional ethics and responsibilities and norms of the
engineering practice.
9. Individual and team work: Function effectively as an individual, and as a member or leader in diverse teams,
and in multidisciplinary settings.
10. 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.
11. 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 multidisciplinary environments.
12. 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.
iii
 SOFTWARE ENGINEERING PRACTICAL BOOK

COMPUTER ENGINEERING DEPARTMENT

PREFACE

It gives us immense pleasure to present the second edition of Software Engineering Practical Book
for the B.E. 3rd year students of Silver Oak College of Engineering Technology.

The theory and laboratory course of Software Engineering, at Silver Oak College of Engineering
Technology, Ahmedabad, is designed in such a manner that students can develop the basic
understanding of the subject during theory classes and gain the hands-on practical experience during
their laboratory sessions. Software engineering is a field that is vitally important to computer
technology as a whole. Software engineering is the application of engineering principles to the
design, development and implementation of software.

The Laboratory Manual presented here to you takes you onto learning journey of various software
development lifecycle processes including waterfall (linear), incremental approaches (such as
Unified process), and agile approaches. In this course you will explore how to prepare technical
documentations and make presentations on various aspects of a software development project,
including the technical aspects (architecture, design, quality assurance) as well as the managerial
aspects (planning, scheduling, and delivery). You will experience how to work collaboratively in a
small team environment to develop a moderate-sized software system from conceptualization to
completion, including requirements elicitation, system modelling, system design, implementation,
unit and system testing, integration, source code management configuration management, and release
management. The lab manual course also covers software testing and quality assurance techniques at
the module level, and understand these techniques at the system and organization level.

Lab Manual Revised by:

Lab Manual Revision No.: SOCET_3150711_LM_2020-21_1

iv
 INSTRUCTIONS TO STUDENTS

1. Be prompt in arriving to the laboratory and always come well prepared for the experiment.
2. Students need to maintain a proper decorum in the computer lab. Students must use the equipment with
care. Any damage is caused is punishable.
3. Students are instructed to come to lab in formal dresses only.
4. Students are supposed to occupy the systems allotted to them and are not supposed to talk or make noise
in the lab.
5. Students are required to carry their observation book and lab records with completed exercises while
entering the lab.
6. Lab records need to be submitted every week.
7. Students are not supposed to use pen drives in the lab.
8. The grades for the Software Engineering Practical course work will be awarded based on your
performance in the laboratory, regularity, recording of experiments in the Software Engineering practical
Final Notebook, lab quiz, regular viva-voce and end-term examination.
9. Find the answers of all the questions mentioned under the section ‘Find the Answers’ at the end of each
experiment in the Software Engineering Practical Book.

v
 CERTIFICATE

This is to certify that

SHAIKH
Mr. ANNANAHMED
Priyal S. Dalal with enrolment no. 190770107264
180770107508 from Semester 55-DIV-A
Div. f
FURKANAHMED

has successfully completed his/her laboratory experiments in the SOFTWARE

ENGINEERING (3150711) from the department of Computer Engineering

during the academic year 2020

2021-22.

Date of Submission: ......................... Staff Incharge: ...........................

Head of Department: ...........................................

vi
 TABLE OF CONTENT

Page No Marks
Sr. Date of Date of
Experiment Title Sign (out of
No Start Completion
10)
To From
Study complete software development
life cycle and analyze various
1
activities conducted as a part of each
phase.
Study software requirements and
identify the requirements from any
2
problem statement and develop
Software Requirement Specification.
Study Object Oriented Design using
3 UML and prepare Use-Case, ER,
Activity, Sequence, Class diagrams.
Study System Modelling using Data
4
Flow Diagrams.
Study Project Estimation techniques,
5
FP analysis and COCOMO model.
Study Project Scheduling Techniques
/Tools. Critical Path Method (CPM),
6 Project Evaluation and Review
Technique (Pert), Gantt Chart And
Work-Breakdown Structure.
Study Software Risk Analysis and
7
Management.
Study Software Testing and designing
8
Test Suites.
Study Estimation of Test Coverage
9
Metrics and Structural Complexity.
Prepare Case Study of any one topic
given below.
1. Project Management Tools
10 2. SCM Tools
3. SQA Tools
4. Testing Tool

vii
 PRACTICAL SET - 1
STUDY COMPLETE SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC) AND
ANALYZE VARIOUS ACTIVITIES CONDUCTED AS A PART OF EACH PHASE.

What is SDLC?

The Software Development Lifecycle is a systematic process for building software that ensures
the quality and correctness of the software built. SDLC process aims to produce high-quality
software which meets customer expectations. The software development should be complete in
the pre-defined time frame and cost.
SDLC consists of a detailed plan which explains how to plan, build, and maintain specific
software. Every phase of the SDLC lifecycle has its own process and deliverables that feed into
the next phase.

Why SDLC?

Here, are prime reasons why SDLC is important for developing a software system.

 It offers a basis for project planning, scheduling, and estimating

 Provides a framework for a standard set of activities and deliverables
 It is a mechanism for project tracking and control
 Increases visibility of project planning to all involved stakeholders of the development
process
 Increased and enhance development speed
 Improved client relations
 Helps you to decrease project risk and project management plan overhead

SDLC Phases

The entire SDLC process divided into the following stages:

 Phase 1: Requirement Analysis

 Phase 2: Feasibility study
 Phase 3: Design
 Phase 4: Coding
 Phase 5: Testing
 Phase 6: Installation/Deployment
 Phase 7: Maintenance

1
Phase 1: Requirement Analysis:

The requirement is the first stage in the SDLC process. It is conducted by the senior team
members with inputs from all the stakeholders and domain experts in the industry. Planning for
the quality assurance requirements and recognization of the risks involved is also done at this
stage.

This stage gives a clearer picture of the scope of the entire project and the anticipated issues,
opportunities, and directives which triggered the project.

Requirements Gathering stage need teams to get detailed and precise requirements. This helps
companies to finalize the necessary timeline to finish the work of that system.

Phase 2: Feasibility study:

Once the requirement analysis phase is completed the next step is to define and document
software needs. This process conducted with the help of 'Software Requirement Specification'
document also known as 'SRS' document. It includes everything which should be designed and
developed during the project life cycle.

There are mainly five types of feasibilities checks:

 Economic: Can we complete the project within the budget or not?

 Legal: Can we handle this project as cyber law and other regulatory framework/
compliances?
 Operation feasibility: Can we create operations which are expected by the client?
 Technical: Need to check whether the current computer system can support the software
 Schedule: Decide that the project can be completed within the given schedule or not.

Phase 3: Design:

In this third phase, the system and software design documents are prepared as per the
requirement specification document. This helps define overall system architecture. This design
phase serves as input for the next phase of the model.

There are two kinds of design documents developed in this phase:

High-Level Design (HLD)

 Brief description and name of each module

 An outline about the functionality of every module
 Interface relationship and dependencies between modules
 Database tables identified along with their key elements
 Complete architecture diagrams along with technology details
2
Low-Level Design (LLD)

 Functional logic of the modules

 Database tables, which include type and size
 Complete detail of the interface
 Addresses all types of dependency issues
 Listing of error messages
 Complete input and outputs for every module

Phase 4: Implementation / Coding:

Once the system design phase is over, the next phase is implementation. In this phase, developers
start building the entire system by writing code using the chosen programming language. In the
coding phase, tasks are divided into units or modules and assigned to the various developers. It is
the longest phase of the Software Development Life Cycle process.

In this phase, Developer needs to follow certain predefined coding guidelines. They also need to
use programming tools like compiler, interpreters, debugger to generate and implement the code.

Phase 5: Testing:

Once the software is complete, and it is deployed in the testing environment. The testing team
starts testing the functionality of the entire system. This is done to verify that the entire
application works according to the customer requirement.

During this phase, QA and testing team may find some bugs/defects which they communicate to
developers. The development team fixes the bug and send back to QA for a re-test. This process
continues until the software is bug-free, stable, and working according to the business needs of
that system.

Phase 6: Deployment/ Installation:

Once the software testing phase is over and no bugs or errors left in the system then the final
deployment process starts. Based on the feedback given by the project manager, the final
software is released and checked for deployment issues if any.

Phase 7: Maintenance:

Once the system is deployed, and customers start using the developed system, following 3
activities occur

 Bug fixing - bugs are reported because of some scenarios which are not tested at all
 Upgrade - Upgrading the application to the newer versions of the Software
 Enhancement - Adding some new features into the existing software
3
The main focus of this SDLC phase is to ensure that needs continue to be met and that the
system continues to perform as per the specification mentioned in the first phase.

SDLC models

Various SDLC models are listed below:

 Prescriptive Model
o Waterfall Model

 Incremental Process Models

o Incremental Model
o RAD Model

 Evolutionary Process Models

o Prototyping Model
o Spiral Model
o Concurrent Development Model

 Specialized Process Models

o Component Based Development Model
o Formal Methods Model
o Aspect-Oriented Software Development Model

 Agile Process Models

o Extreme Programming (XP) Model
o Adaptive Software Development (ASD) Model
o Dynamic System Development Method (DSDM) Model
o Scrum Model
o Crystal Model
o Feature Driven Development (FDD) Model
o Agile Model (AM)

References:

[1] Roger S.Pressman, Software engineering- A practitioner’s Approach, McGraw-Hill

International Editions
[2] https://nptel.ac.in/courses/106105087/pdf/m02L03.pdf

4
Aim: Study and document any two process model with its introduction, diagram, advantages and
disadvantages.

The Waterfall Model

The best known process model

o dates from 1970’s

o though widely derided, it remains widely used
 and its terminology forms the basis for almost all discussions
of other SDPMs
 Defining characteristic: movement from phase to phase is always forward
(downhill), irreversible
 Milestones are set at each phase transition
o schedule deadlines
o required reports
o required approval to move on

The waterfall model gets its name from the fact that the first diagrams of this
process illustrated it as a series of terraces over which a stream flowed, cascading
down from one level to another. The point of this portrayal was that water always
flows downhill — it can’t reverse itself. Similarly, the defining characteristic of
the waterfall model is the irreversible forward progress from phase to phase.

Waterfall is often criticized as inflexible, in large part because of that irreversible

forward motion. Many organizations, in practice, will do a kind of “waterfall with
appeals”, allowing developers to revisit and revise decisions
anddocuments from earlier phases after jumping through a number of
eliberately restrictive hoops.

5
 Advantages:-

 Linear structure is easy to understand

 Development progress is easily estimated and explicitly documented
 Widely known
 Scales well

Disadvantage:-

 Inflexible: corrections limited to current phase

 In some projects, requirements are not known or understood early in
the life-cycle
 Working version of system is only available near the end
 Often becomes a documentation mill

Iterative/Incremental Development

 A variety of related approaches

o a counter-reaction to what many believe to be an overly rigid,
management-focused, waterfall model
 emphasize quick cycles of development, usually with earlier and
more user-oriented validation
 Requirements specification, design and implementation are
interleaved.
 Each version adds a small amount of additional functionality.

As a counter-reaction to what many believe to be an overly rigid

waterfall model, there are a variety of incremental approaches that
emphasize quick cycles of development, usually with earlier and more
user-oriented validation.

6
 There is a greater emphasis on producing intermediate versions, each
adding a small amount of additional functionality. Some of these
are releases, either external (released outside the team) or internal (seen
only by the team), which may have been planned earlier.

What’s the difference between iterative and incremental?

 “Iterative” means that we can re-visit decisions, design, and code

produced in earlier iterative steps.
 “Incremental” means that each iteration produces just a small unit of
additional functional behavior. We don’t try to build major subsystems
of the project in a single pass.
o This often requires a more “vertical” view in which we implement
a bit of high level control code and pieces of related low-level
code.

As opposed to the “horizontal” approach of working “bottom up” and implementing

the low-level ADTS, then the code that calls, upon them, then …, ending with the top-
level interface ot the whole program

o Or the “horizontal” approach of working “top down” and implementing the most
abstract code (the GUI or command-line interfaces), then functions that they call,
then the … ending with the lowest-level ADTS that don’t call on anything else.

Advantages:-

 Ability to explore poorly understood requirements

 Flexibility
 Working implementation is available early.

Disadvantages:-

 Poor process visibility (e.g., are we on schedule?),

 Continual small drifts from the main architecture leading to poorly structured
systems.
 Dead-ends (the local optimization problem)

7
Post Practical Questions:
1. Selection of a model is based on
a) Requirements
b) Development team & Users
c) Project type and associated risk
d) All of the mentioned
2. Which two models doesn’t allow defining requirements early in the cycle?
a) Waterfall & RAD
b) Prototyping & Spiral
c) Prototyping & RAD
d) Waterfall & Spiral
3. What is the major advantage of using Incremental Model?
a) Customer can respond to each increment
b) Easier to test and debug
c) It is used when there is a need to get a product to the market early
d) Easier to test and debug when there is a need to get a product to the market early
4. What is the major drawback of using RAD Model?
a) Highly specialized & skilled developers/designers are required
b) Increases reusability of components
c) Encourages customer/client feedback
d) Increases reusability of components, Highly specialized & skilled developers/designers
are required
5. If you were lead developer of Software Company and you are asked to submit project
/product within a stipulated time-frame with no cost barriers, which model you select?
a) Waterfall
b) Spiral
c) RAD
d) Incremental
6. Which one of the following models is not suitable for accommodating any change?
a) Build & Fix Model
b) Prototyping Model
c) RAD Model
d) Waterfall Model

8
 7. Choose the correct option from given below:
a) Prototyping Model facilitates reusability of components
b) RAD Model facilitates reusability of components
c) Both RAD & Prototyping Model facilitates reusability of components
d) None
8. A company is developing an advance version of their current software available in the
market, what model approach would they prefer?
a) RAD
b) Iterative Enhancement
c) Both RAD & Iterative Enhancement
d) Spiral
9. Agile Software Development is based on
a) Incremental Development
b) Iterative Development
c) Linear Development
d) Both Incremental and Iterative Development
10. Which of the following does not apply to agility to a software process?
a) Uses incremental product delivery strategy
b) Only essential work products are produced
c) Eliminate the use of project planning and testing
d) All of the mentioned

Conclusion:

Here we conclude Study and document any two process model with its introduction, diagram,
advantages and disadvantages.

9
 PRACTICAL SET– 2
STUDY SOFTWARE REQUIREMENTS IN DETAIL.

What is Software Requirements?

Sommerville defines "requirement" as a specification of what should be implemented.

Requirements specify how the target system should behave. It specifies what to do, but not how
to do. Requirements engineering refers to the process of understanding what a customer expects
from the system to be developed, and to document them in a standard and easily readable and
understandable format. This documentation will serve as reference for the subsequent design,
implementation and verification of the system.

Requirement is a condition or capability possessed by the software or system component in order

to solve a real world problem. The problems can be to automate a part of a system, to correct
shortcomings of an existing system, to control a device, and so on.

IEEE defines requirement as (1) A condition or capability needed by a user to solve a problem
or achieve an objective. (2) A condition or capability that must be met or possessed by a system
or system component to satisfy a contract, standard, specification, or other formally imposed
documents. (3) A documented representation of a condition or capability as in (1) or (2).

Why Software Requirements?

Requirements describe how a system should act, appear or perform. For this, when users request
for software, they provide an approximation of what the new system should be capable of doing.
Requirements differ from one user to another and from one business process to another.

It is necessary and important that before we start planning, design and implementation of the
software system for our client, software development team must be clear about it's requirements.
If they don't have a clear vision of what is to be developed and what all features are expected,
there would be serious problems and customer dissatisfaction as well.

Characteristics of Requirements

Requirements gathered for any new system to be developed should exhibit the following three
properties:

 Unambiguousness: There should not be any ambiguity what a system to be developed

should do. For example, consider you are developing a web application for your client.
10
 The client requires that enough number of people should be able to access the application
simultaneously. What's the "enough number of people"? That could mean 10 to you, but,
perhaps, 100 to the client. There's an ambiguity.
 Consistency: To illustrate this, consider the automation of a nuclear plant. Suppose one
of the clients say that it the radiation level inside the plant exceeds R1, all reactors should
be shut down. However, another person from the client side suggests that the threshold
radiation level should be R2. Thus, there is an inconsistency between the two end users
regarding what they consider as threshold level of radiation.

 Completeness: A particular requirement for a system should specify what the system
should do and also what it should not. For example, consider software to be developed
for ATM. If a customer enters an amount greater than the maximum permissible
withdrawal amount, the ATM should display an error message, and it should not dispense
any cash.

 Atomic: Means it should be at very low level of details which should not be possible to
separate out into components.

 Traceable: One should be able to trace a requirement to a design component and then to
a code segment in the program. Similarly, one should be able to trace a requirement to the
corresponding test cases.

 Prioritized: There should a criterion to classify the requirements as less or more

important or more specifically as desirable or essential. An identifier mark can be used
with every requirement to indicate its rank or stability.

 Testable: Testers should be able to verify whether the requirement is implemented

correctly. The test should either pass or fail. To be testable, requirements should be clear,
precise, and unambiguous.

Categorization of Requirements

Based on the target audience or subject matter, requirements can be classified into different
types, as stated below:

 User requirements: They are written in natural language so that both customers can
verify their requirements have been correctly identified
 System requirements: They are written involving technical terms and/or specifications,
and are meant for the development or testing teams

Requirements can be classified into two groups based on what they describe:

 Functional requirements (FRs):

 Non-functional requirements (NFRs):
11
 Functional requirements (FRs):

IEEE defines functional requirements as 'a function that a system or component must be
able to perform.' These requirements describe the interaction of software with its
environment and specify the inputs, outputs, external interfaces, and the functions that
should be included in the software. Also, the services provided by functional
requirements specify the procedure by which the software should react to particular
inputs or behave in particular situations.

 Non-functional requirements (NFRs):

The non-functional requirements (also known as quality requirements) are related to

system attributes such as reliability and response time, etc. Non-functional requirements
are not directly related what functionalities are expected from the system but it could
typically define how the system should behave under certain situations. For example, a
Non-functional requirements could say that the system should work with 128MB RAM.
Under such condition, Non-functional requirements could be more critical than a
functional requirement.

Non-functional requirements arise due to user requirements, budget constraints,

organizational policies, and so on. Non-functional requirements are not related directly to
any particular function provided by the system. Non-functional requirements should be
accomplished in software to make it perform efficiently.

Non-functional requirements could be further classified into different types like:

 Product/Performance requirements: These requirements specify how software

product performs. Product requirements comprise the following.

o Efficiency requirements: Describe the extent to which the software makes

optimal use of resources, the speed with which the system executes, and the
memory it consumes for its operation. For example, the system should be able to
operate at least three times faster than the existing system.

o Reliability requirements: Describe the acceptable failure rate of the software.

For example, the software should be able to operate even if a hazard occurs.

o Portability requirements: Describe the ease with which the software can be
transferred from one platform to another. For example, it should be easy to port
the software to a different operating system without the need to redesign the entire
software.

12
 o Usability requirements: Describe the ease with which users are able to operate
the software. For example, the software should be able to provide access to
functionality with fewer keystrokes and mouse clicks.

 Organizational requirements: These requirements are derived from the policies and
procedures of an organization. Organizational requirements comprise the following.

o Delivery requirements: Specify when the software and its documentation are to
be delivered to the user.

o Implementation requirements: Describe requirements such as programming

language and design method.

o Standards requirements: Describe the process standards to be used during

software development. For example, the software should be developed using
standards specified by the ISO and IEEE standards.

 External requirements: These requirements include all the requirements that affect
the software or its development process externally. External requirements comprise
the following.

o Interoperability requirements: Define the way in which

different computer based systems will interact with each other in one or more
organizations.

o Ethical requirements: Specify the rules and regulations of the software so that
they are acceptable to users.

o Legislative requirements: Ensure that the software operates within the legal
jurisdiction. For example, pirated software should not be sold.

References:
[1] Rajib Mall, Fundamentals of software Engineering, Prentice Hall of India.
[2] https://nptel.ac.in/courses/pdf_link/106105182/lec16.pdf

13
Aim: Identify the requirements from any one problem domain given below in group of two
and develop software requirement specification - SRS document.
1. LIBRARY INFORMATION SYSTEM
2. HOTEL MANAGEMENT SYSTEM
3. FLIGHT PLANNING AND MANAGEMENT SYSTEM
4. AMBULANCE DISPATCHING SYSTEM
5. ONLINE SHOPPING SYSTEM
6. HOSPITAL MANAGEMENT SYSTEM
7. BANKING SYSTEM
8. STUDENT MANAGEMENT SYSTEM
9. ATTENDANCE MANAGEMENT SYSTEM
10. EXAMINATION SYSTEM
11. SOCIAL SECURITY DETAILS MANAGEMENT SYSTEM
12. ONLINE TICKET BOOKING SYSTEM

What is SRS?

A Software Requirements Specification (SRS) is a complete description of the behavior of the

system to be developed. The SRS is prepared by the service provider, and verified by its client.
This document serves as a legal agreement between the client and the service provider. It
includes a set of use cases that describe all the interactions the users will have with the software.
Use cases are also known as functional requirements. In addition to use cases, the SRS also
contains non-functional (or supplementary) requirements. Non-functional requirements are
requirements which impose constraints on the design or implementation (such as performance
engineering requirements, quality standards, or design constraints).

Once the concerned system has been developed and deployed, and a proposed feature was not
found to be present in the system, the client can point this out from the SRS. Also, if after
delivery, the client says a new feature is required, which was not mentioned in the SRS, the
service provider can again point to the SRS.

Preparing Software Requirements Specifications

Collect all possible FRs and non-FRs for any one system mentioned above, which are complete,
consistent, and non-ambiguous, the Software Requirements Specification (SRS) is to be prepared
by each student in group of two. IEEE provides a template for SRS and its outline is also
available here, which must be used.

14
Software Requirement Specification
Table of Contents
Table of Contents .................................................................................................................... 15
Revision History ............................................................................ Error! Bookmark not defined.
1. Introduction ............................................................................. Error! Bookmark not defined.
1.1 Purpose.................................................................................... Error! Bookmark not defined.
1.2 Document Conventions ............................................................ Error! Bookmark not defined.
1.3 Intended Audience and Reading Suggestions ........................... Error! Bookmark not defined.
1.4 Product Scope .......................................................................... Error! Bookmark not defined.
1.5 References ............................................................................... Error! Bookmark not defined.
2. Overall Description ................................................................. Error! Bookmark not defined.
2.1 Product Perspective ................................................................. Error! Bookmark not defined.
2.2 Product Functions .................................................................... Error! Bookmark not defined.
2.3 User Classes and Characteristics .............................................. Error! Bookmark not defined.
2.4 Operating Environment ............................................................ Error! Bookmark not defined.
2.5 Design and Implementation Constraints ................................... Error! Bookmark not defined.
2.6 User Documentation ................................................................ Error! Bookmark not defined.
2.7 Assumptions and Dependencies ............................................... Error! Bookmark not defined.
3. External Interface Requirements ........................................... Error! Bookmark not defined.
3.1 User Interfaces ......................................................................... Error! Bookmark not defined.
3.2 Hardware Interfaces ................................................................. Error! Bookmark not defined.
3.3 Software Interfaces .................................................................. Error! Bookmark not defined.
3.4 Communications Interfaces ...................................................... Error! Bookmark not defined.
4. Domain Model ......................................................................... Error! Bookmark not defined.
5. System Features (Use Cases) ................................................... Error! Bookmark not defined.
5.1 Use Case 1 ............................................................................... Error! Bookmark not defined.
5.1.1 Name:.................................................................................. Error! Bookmark not defined.
5.1.2 Goal: ................................................................................... Error! Bookmark not defined.
5.1.3 Input:................................................................................... Error! Bookmark not defined.
5.1.4 Output: ................................................................................ Error! Bookmark not defined.
5.1.5 Main Scenario: .................................................................... Error! Bookmark not defined.
5.1.6 Pre-condition: ...................................................................... Error! Bookmark not defined.
5.1.7 Steps: .................................................................................. Error! Bookmark not defined.
5.1.8 Post-condition ..................................................................... Error! Bookmark not defined.
5.1.9 Exceptional Scenario 1 ........................................................ Error! Bookmark not defined.
5.1.10 Example .............................................................................. Error! Bookmark not defined.
5.2 Use Case 2 (and so on)............................................................. Error! Bookmark not defined.
6. Other Nonfunctional Requirements ....................................... Error! Bookmark not defined.
6.1 Performance Requirements ...................................................... Error! Bookmark not defined.
6.2 Safety Requirements ................................................................ Error! Bookmark not defined.
6.3 Security Requirements ............................................................. Error! Bookmark not defined.
6.4 Software Quality Attributes ..................................................... Error! Bookmark not defined.
7. Other Requirements ................................................................ Error! Bookmark not defined.
Appendix A: Glossary ................................................................... Error! Bookmark not defined.
Appendix B: Analysis Models ....................................................... Error! Bookmark not defined.
Appendix C: To Be Determined List ............................................ Error! Bookmark not defined.

15
Aim : Consider any project to be developed in any technology as a Software Architect or Project
Manager. Construct Software Requirement Specification (SRS) document for the project.

SRS

AMBULANCE DISPATCH SYSTEM

SHAIKH ANNANAHMED FURKANAHMED

Prepared by:

Contents

16
1 Introduction
............................................................................................................................................................2 1.1
Purpose
............................................................................................................................................................2 1.2
Scope of the System
c......................................................................................................................................2 1.3 Objectives
and Success Criteria of the Project...............................................................................................2 1.4
Acronyms and
Abbreviations..........................................................................................................................2 1.5
References...................................................................................................................................................
.....2 2 OVERALL DISCRIPTION
........................................................................................................................................3 2.1 ER
diagram........................................................................................................................................................
.....3 2.2 Current
System......................................................................................................................................................3
2.3 Operating
Environment........................................................................................................................................3 2.4
Assumptions and Dependencies
..........................................................................................................................3 3 Feasibility
Analysis...................................................................................................................................................3
3.1 Requirement Analysis and Specification (SRS):
.................................................................................................. 4 4 Requirements:
......................................................................................................................................................... 4 4.1
Functional Requirements
..................................................................................................................................... 4 4.2 Non-
functional
Requirements............................................................................................................................. 4 4.3
Other Requirements:
............................................................................................................................................5 5.1 Intended
Audience:................................................................................................................................................5
5.2 Intended Use:
........................................................................................................................................................5 5.3
Technical
Implementation....................................................................................................................................5 6
Testing.........................................................................................................................................................
............ 6 6.1 Unit testing:-
......................................................................................................................................................... 6 6.2
Integration Testing:-
............................................................................................................................................ 6 6.3 System
Testing:-................................................................................................................................................... 6
7 Acceptance, installation,
deployment:....................................................................................................................7 8
Maintenance................................................................................................................................................
.............7 9 Conclusion
...............................................................................................................................................................7 10

17
Future Scope
...........................................................................................................................................................7

PAGE 1
1 Introduction

The Ambulance Dispatch System (ADS) is a web based tool to allow the administration
of emergency response system. It maintains locations of ambulances that can be
dynamically configured at administration time. The system maintains a history of
response results for analysis.

1.1 PURPOSE

The purpose of the ADS is to enhance the capabilities of 911 ambulance dispatchers in
the timely displacement of ambulance(s) to injury scenes in an efficient manner.

1.2 SCOPE OF THE SYSTEM C

The scope of the ADS starts at the moment the dispatcher gathers information from the
caller and ends at the patient(s) arrival to a hospital.

1.3 OBJECTIVES AND SUCCESS CRITERIA OF THE PROJECT

The ADS will enable an ambulance dispatcher to monitor the whereabouts of

dispatched ambulance(s).

1.4 ACRONYMS AND ABBREVIATIONS

Table 1: Acronyms and Abbreviations

ADS Ambulance Dispatch System

RAD Requirements Analysis Document, this document.

MTBF Mean Time Between Failure

MTTR Mean Time To Repair

GPS Global Positioning System - uses satellites to triangulate positions on earth.

18
1.5 REFERENCES

[1] http://www.utdallas.edu/~chung/CS6354/
PAGE 2
[2] http://wwwbruegge.informatik.tu
muenchen.de/twiki/bin/view/OOSE/RequirementsAnalysisDocumentTemplate

[3] http://en.wikipedia.org/wiki/Dispatcher

2 OVERALL DISCRIPTION
2.1 ER DIAGRAM
Shown in Practical 3

2.2 CURRENT SYSTEM

The current system is a manual, paper-trail process. The 911 operator would take in the
emergency call, write down necessary information from the caller, & manually locate a free/idle
ambulance. Without having an automated computer system, there is no guarantee the operator
will locate a nearest available ambulance on time. The operator will have to call each
ambulance to see which one can be dispatched to the site. This process is time consuming &
risky depending on the severity of the emergency situation.

2.3 OPERATING ENVIRONMENT

Hardware Platform:
• PROCESSOR: Intel core i3 @ 2.40 GHz
• RAM: 3GB
• HARDDISK: 500GB
• System Type : 32-bit Operating System
• LAN: High Speed up to 10 mbps

Software Components:
• PLATFORM: NetBeans IDE 7.2.1
• THE OPERATING SYSTEM: Windows 7 Ultimate
• FRONT-END : HTML5
• Middle : Java Server Pages
• BACK-END : MySQL

19
2.4 ASSUMPTIONS AND DEPENDENCIES

• This project assumes that the users who like to register must have at least one valid
email account.
• This project assumes that the system is connected to network

3 FEASIBILITY ANALYSIS

PAGE 3
Feasibility Analysis of a project is performed with the aim to determine that whether it would
technically and economically feasible to undertake the project. In other words, is there sufficient
resources, technical and economical, available to develop the product. It involves the analysis
of the problem and collection of all the relevant information relating to the project such as inputs
to the system, processing of the inputs, the output required to be produced by the system and
various constraints on the behaviour of the system.

Feasibility Analysis is mainly of two types:

1) Technical Feasibility:
Technical feasibility refers to the analysis that whether the technical support required to
develop the product is available in sufficiency or not. In this, we opted for the J2EE platform to
develop the product because it seemed ideal for the project to be developed in J2EE platform
due to its unmatched features and very much user-friendliness. Moreover, using HTML5, JSP
to develop the front-end provide an excellent layout to the project. At the back-end, MySQL as
the database as it in the most commonly used database and most people could access it with
ease. Thus, it is quite obvious that the project is technically feasible.

2) Economic Feasibility:
Whether the project to be undertaken is economically feasible or not is determined by
the Economic Feasibility Analysis. It involves the study that if there is sufficient finance
available to complete the project. It is quite obvious that in order to develop a product, technical
backup alone is not sufficient. Adequate capital is very much necessary for the successful
completion of the project. Moreover, it also has to be determined that whether the capital spent
on developing the project would fetch handsome returns or not; otherwise there is no point in
developing the product, if it does not fetch any profit at all. In this case, the software is
scheduled to develop with optimized cost in order to make the project economically feasible.

3.1 REQUIREMENT ANALYSIS AND SPECIFICATION (SRS):

The designing of the project is done with the text based graphics which causes creation of
curses windows. User simply use mouse to control the basic functioning of project up to his/her
convenience.
20
4 REQUIREMENTS:
There are three types of requirements. 1Functional Requirements , 2 Non-functional
Requirements 3 Other Requirements

4.1 FUNCTIONAL REQUIREMENTS

• The database must be in a workable state.
• The registered users must have a valid email id for getting updated.
• There should be proper interconnectivity between different pages in the website. • Different
commands for different functions will ensure reliability.

4.2 NON-FUNCTIONAL REQUIREMENTS

This application can be used in all sectors where the file transfer is an important task to be
performed. Some of its quality attribute includes:-
PAGE 4
1. Checking:- Authentication Checking: With this checking, the system will not allow
unauthorized user to perform functionalities that he/she does not allowed to do.
2. Portability: - The system must be portable between Microsoft Windows and Linux.
Both intranet and internet version of the system should be portable.
3. Maintainability: - The system should be modular. Specifically, file contents should be easy
to maintain as the contents of the database change often.
4. Performance: - The system should be able to support multiple users at a time.

4.3 OTHER REQUIREMENTS:

The other requirement related to this SRS is not needed. The different appendixes are given. In
case of more knowledge related to this SRS one can concern with these statements given
below:- The definition of the words that are frequently used in this SRS is as follows:
• Client – One who uses the project
• Database- In which data is stored
• DFD- Data Flow Diagram
• MySQL- A basic database already present in many s/w
• Hardware- That can be touched
• Interface- Through which client send request
• Server- That serves request
• Software- That can be seen and not touched

5.1 INTENDED AUDIENCE:

• Developers
• Tester

21
• Project Manager
• Database Designer
• Sales Team
• Marketing Team
• Stockholders

5.2 INTENDED USE:

• To know the base of the Application.
• To plan the project plan.
• Analyse the Risk of the system.
• Design the interface component.
• To know the system requirement.

5.3 TECHNICAL IMPLEMENTATION

• The design must be translated into a machine-readable form.
• The code generation step performs this task.
• If the design is performed in a detailed manner, code generation can be accomplished
without much complication.
• Programming tools like Compilers, Interpreters and Debuggers are used to generate the
code. Different high level programming languages like C, C++, Pascal and Java are used for
coding. In
PAGE 5
the development of our site “Ambulance Tracking System”, we chose Java as the
Programming language.

6 TESTING
• The aim of testing is to identify all defects in a software product.
• However, in practice even after thorough testing one cannot guarantee that the software is
error free.
• Testing does however expose many errors:
✓ Testing provides a practical way of reducing defects in a system
✓ Increases the users' confidence in a developed system.
• Software products are tested at three levels:
✓ Unit testing
✓ Integration testing
✓ System testing

22
6.1 UNIT TESTING:-
• During unit testing, modules are tested in isolation:
• If all modules were to be tested together it may not be easy to determine which module has
the error.
• Unit testing reduces debugging effort several folds.
• Programmers carry out unit testing immediately after they complete the coding of a module.

6.2 INTEGRATION TESTING:-

• After different modules of a system have been coded and unit tested:
◦ modules are integrated in steps according to an integration plan
◦ Partially integrated system is tested at each integration step.
◦ There are various approach for doing the integration testing
◦ Big Bang approach
◦ Top down approach
◦ Bottom approach
◦ Mixed approach

6.3 SYSTEM TESTING:-

• System testing involves:
◦ Validating a fully developed system against its requirements.
◦ System testing is done against the requirements in the SRS
◦ This is the last phase of testing before the product is delivered
◦ System testing consists of three kinds
◦ Alpha testing
◦ Beta testing
◦ Acceptance testing
• System testing involves:
• Validating a fully developed system against its requirements.
• System testing is done against the requirements in the SRS
• This is the last phase of testing before the product is delivered
PAGE 6
System testing consists of three kinds
Alpha testing, Beta testing and Acceptance testing

• Alpha - System testing is carried out by the test team within the developing organization. •
Beta - System testing performed by a select group of friendly customers.
• Acceptance - System testing performed by the customer himself to determine whether the
system should be accepted or rejected.

7 ACCEPTANCE, INSTALLATION, DEPLOYMENT:

23
This is the final stage of the development of the software where the developed software is
installed at the client’s place and all the applications are deployed so as to enable the client to
use the software for his intended requirement.

8 MAINTENANCE
• Maintenance refers to any changes made to the product after it has been delivered to the
customer. Maintenance of software products is concerned with correction of errors; enhance
features, part to new platforms etc.
• Software maintenance is an important activity of a large number of organizations. • It is quite
natural that the customers would prefer using the existing software products to run on newer
platforms, in newer environments and with enhanced features.
• Moreover, maintenance of a software product is essential to rectify the bugs observed while
the system is in use.
• Thus, software maintenance is quite an important activity in the development of the
product because it is almost certain that the customer would ask for further rectification of the
product after its delivery and thus one has to be prepared to meet the customers’
requirements.

9 CONCLUSION
• The main objective of this web application was to utilize the benefits of global positioning
system and incorporate it into tracking software for the benefit of common people.
• Though this version does not contain an interface for common users, it can be added later. •
Proper usage of applications like this can bring about a lot of improvement in emergency
health services.
• It helps in saving a lot of time which is of prime importance.
• Also proper management of staff and other resources helps in optimizing funds thereby
maintains smooth functioning of the unit or organization.

10 FUTURE SCOPE
There is scope for a lot of improvements and up-gradations in this application. Some of them
are listed below:
• An alarm can be set for maintenance so that each and every ambulance can be sent for
servicing at regular intervals.
• Report generation once a patient or accident victim is successfully transported to the
hospital. • Alarm in case of diversion from route.

PAGE 7
• Maintaining doctors at standby along with ambulances.
• Keeping a record of aged patients and keeping a tab on their health periodically

24
Post Practical Questions:
1. Select the developer-specific requirement?
a) Portability
b) Maintainability
c) Availability
d) Both Portability and Maintainability
2. Which of the following statements explains portability in non-functional requirements?
a) It is a degree to which software running on one platform can easily be converted
to run on another platform
b) It cannot be enhanced by using languages, OS’ and tools that are universally available
and standardized
c) The ability of the system to behave consistently in a user-acceptable manner when
operating within the environment for which the system was intended
d) None of the mentioned
3. “Consider a system where, a heat sensor detects an intrusion and alerts the security
company.” What kind of a requirement the system is providing?
a) Functional
b) Non-Functional
c) Known Requirement
d) None of the mentioned
4. The SRS document is also known as _____________ specification.
a) black-box
b) white-box
c) grey-box
d) none of the mentioned
5. The goal of reading SRS document by the software developer is to :
a) Ensure requirements are understandable from a functionality point of view
b) Understand the features of the product
c) Ensure that the software is developed as per customer needs
d) None of these

6. Choose the incorrect statement with respect to Non-Functional Requirement (NFR).

a) Product-oriented Approach – Focus on system (or software) quality
b) Process-oriented Approach – Focus on how NFRs can be used in the design process
c) Quantitative Approach – Find measurable scales for the functionality attributes
d) Qualitative Approach – Study various relationships between quality goals

7. Which is one of the most important stakeholders from the following?

a) Entry level personnel
25
 b) Middle level stakeholder
c) Managers
d) Users of the software
8. The SRS is said to be consistent if and only if
a) its structure and style are such that any changes to the requirements can be made
easily while retaining the style and structure
b) every requirement stated therein is one that the software shall meet
c) every requirement stated therein is verifiable
d) no subset of individual requirements described in it conflict with each other
9. Which of the following property of SRS is depicted by the statement: “Conformity to a
standard is maintained”?
a) Correct
b) Complete
c) Consistent
d) Modifiable
10. SRS document is called black box specification of a system because
a) It does not contain the contradictory materials
b) It does not contain the user documentation
c) SRS document should specify only the external behavior of the system
d) None of these above

Conclusion:

In this practical we learnt about Data Flow Diagram for software.

26
 PRACTICAL SET – 3
STUDY OBJECT ORIENTED DESIGN USING UML.

What is UML?
The Unified Modeling Language (UML) is a standard language for specifying, visualizing,
constructing, and documenting the artifacts of software systems, as well as for business modeling
and other non-software systems. The UML represents a collection of best engineering practices
that have proven successful in the modeling of large and complex systems. The UML is a very
important part of developing object-oriented software and the software development process.
The UML uses mostly graphical notations to express the design of software projects. Using the
UML helps project teams communicate, explore potential designs, and validate the architectural
design of the software.
Why UML?
As the strategic value of software increases for many companies, the industry looks for
techniques to automate the production of software and to improve quality and reduce cost and
time-to-market. These techniques include component technology, visual programming, patterns
and frameworks. Businesses also seek techniques to manage the complexity of systems as they
increase in scope and scale. In particular, they recognize the need to solve recurring architectural
problems, such as physical distribution, concurrency, replication, security, load balancing and
fault tolerance. Additionally, the development for the World Wide Web, while making some
things simpler, has exacerbated these architectural problems. The Unified Modeling Language
(UML) was designed to respond to these needs.
Types of UML Diagrams:
There are two broad categories of diagrams and they are again divided into subcategories
 Structural Diagrams
 Behavioural Diagrams
Structural Diagrams
The structural diagrams represent the static aspect of the system. These static aspects represent
those parts of a diagram, which forms the main structure and are therefore stable.
These static parts are represented by classes, interfaces, objects, components, and nodes. The
four structural diagrams are
 Class diagram
 Object diagram
 Component diagram
 Deployment diagram

27
Class Diagram
Class diagrams basically represent the object-oriented view of a system, which is static in nature.
It consists of classes, interfaces, associations, and collaboration. Active class is used in a class
diagram to represent the concurrency of the system.
Class diagram represents the object orientation of a system. Hence, it is generally used for
development purpose. This is the most widely used diagram at the time of system construction.
Elements in class diagram
Class diagram contains the system classes with its data members, operations and relationships
between classes.

Class
A set of objects containing similar data members and member functions is described by a class.
In UML syntax, class is identified by solid outline rectangle with three compartments which
contain
 Class name
A class is uniquely identified in a system by its name. A textual string is taken as class
name. It lies in the first compartment in class rectangle.

28
  Attributes
Property shared by all instances of a class. It lies in the second compartment in class
rectangle.
 Operations
An execution of an action can be performed for any object of a class. It lies in the last
compartment in class rectangle.
 Generalization/Specialization
It describes how one class is derived from another class. Derived class inherits the
properties of its parent class.
Relationships
Existing relationships in a system describe legitimate connections between the classes in that
system.
 Association
It is an instance level relationship that allows exchanging messages among the objects of
both ends of association. A simple straight line connecting two class boxes represent an
association. We can give a name to association and also at the both end we may indicate
role names and multiplicity of the adjacent classes. Association may be uni-directional.
 Aggregation
It is a special form of association which describes a part-whole relationship between a
pair of classes. It means, in a relationship, when a class holds some instances of related
class, then that relationship can be designed as an aggregation.
 Multiplicity
It describes how many numbers of instances of one class is related to the number of
instances of another class in an association.

29
Object Diagram
Object diagrams can be described as an instance of class diagram. Thus, these diagrams are more
close to real-life scenarios where we implement a system.
Object diagrams are a set of objects and their relationship is just like class diagrams. They also
represent the static view of the system.
The usage of object diagrams is similar to class diagrams but they are used to build prototype of
a system from a practical perspective.
Component Diagram
Component diagrams represent a set of components and their relationships. These components
consist of classes, interfaces, or collaborations. Component diagrams represent the
implementation view of a system.
During the design phase, software artifacts (classes, interfaces, etc.) of a system are arranged in
different groups depending upon their relationship. Now, these groups are known as components.
Finally, it can be said component diagrams are used to visualize the implementation.
Deployment Diagram
Deployment diagrams are a set of nodes and their relationships. These nodes are physical entities
where the components are deployed.
Deployment diagrams are used for visualizing the deployment view of a system. This is
generally used by the deployment team.

Behavioural Diagrams
Any system can have two aspects, static and dynamic. So, a model is considered as complete
when both the aspects are fully covered.
Behavioural diagrams basically capture the dynamic aspect of a system. Dynamic aspect can be
further described as the changing/moving parts of a system.
UML has the following five types of behavioural diagrams
 Use case diagram
 Sequence diagram
30
  Activity diagram
 State chart diagram
 Collaboration diagram
Use Case Diagram
Use case diagrams are a set of use cases, actors, and their relationships. They represent the use
case view of a system.
Use case diagrams aim to present a graphical overview of the functionality provided by the
system. Hence, use case diagram is used to describe the relationships among the functionalities
and their internal/external controllers. These controllers are known as actors. It also consists of a
set of actions (referred to as use cases) which can be performed by one or more actors, their
relationships and dependencies.
 Actor
An actor can be defined as an object or set of objects, external to the system, which interacts
with the system to get some meaningful work done. Actors could be human, devices, or even
other systems. Actors can be classified as below:
Primary actor: They are principal users of the system, who fulfil their goal by availing
some service from the system.
Supporting actor: They render some kind of service to the system.
In a use case diagram primary actors are usually drawn on the top left side of the diagram.
 Use Case
A use case is simply a functionality provided by a system.
 Subject
Subject is simply the system under consideration. Use cases apply to a subject.
Symbols and Notations
The notation for a use case diagram is pretty straightforward and doesn't involve as many types
of symbols as other UML diagrams.

31
  Use cases: Horizontally shaped ovals that represent the different uses that a user might
have.
 Actors: Stick figures that represent the people actually employing the use cases.
 Associations: A line between actors and use cases. In complex diagrams, it is important
to know which actors are associated with which use cases.
 System boundary boxes: A box that sets a system scope to use cases. All use cases
outside the box would be considered outside the scope of that system. For example,
Psycho Killer is outside the scope of occupations in the chainsaw example found below.
 Packages: A UML shape that allows you to put different elements into groups. Just as
with component diagrams, these groupings are represented as file folders.

Guidelines for drawing Use Case diagrams

Following general guidelines could be kept in mind while trying to draw a use case diagram:
 Determine the system boundary
 Ensure that individual actors have well-defined purpose
 Use cases identified should let some meaningful work done by the actors
 Associate the actors and use cases -- there shouldn't be any actor or use case floating
without any connection
 Use include relationship to encapsulate common behaviour among use cases

Sequence Diagram
A sequence diagram is an interaction diagram. From the name, it is clear that the diagram deals
with some sequences, which are the sequence of messages flowing from one object to another.

32
Interaction among the components of a system is very important from implementation and
execution perspective. Sequence diagram is used to visualize the sequence of calls in a system to
perform a specific functionality.
Elements in sequence diagram
Sequence diagram contains the objects of a system and their life-line bar and the messages
passing between them.
 Object
Objects appear at the top portion of sequence diagram. Object is shown in a rectangle box.
Name of object precedes a colon ‘:’ and the class name, from which the object is instantiated.
The whole string is underlined and appears in a rectangle box. Also, we may use only class
name or only instance name.
Objects which are created at the time of execution of use case and are involved in message
passing , are appear in diagram, at the point of their creation.

 Life-line bar
A down-ward vertical line from object-box is shown as the life-line of the object. A rectangle
bar on life-line indicates that it is active at that point of time.

33
  Messages
Messages are shown as an arrow from the life-line of sender object to the life-line of receiver
object and labelled with the message name. Chronological order of the messages passing
throughout the objects’ life-line show the sequence in which they occur. There may exist
some different types of messages:
o Synchronous messages: Receiver start processing the message after receiving it
and sender needs to wait until it is made. A straight arrow with close and fill
arrow-head from sender life-line bar to receiver end, represent a synchronous
message.
o Asynchronous messages: For asynchronous message sender needs not to wait for
the receiver to process the message. A function call that creates thread can be
represented as an asynchronous message in sequence diagram. A straight arrow
with open arrow-head from sender life-line bar to receiver end, represent an
asynchronous message.
o Return message: For a function call when we need to return a value to the object,
from which it was called, then we use return message. But, it is optional, and we
are using it when we are going to model our system in much detail. A dashed
arrow with open arrow-head from sender life-line bar to receiver end, represent
that message.

 Response message:
One object can send a message to self. We use this message when we need to show the
interaction between the same object.

Activity Diagram
Activity diagram describes the flow of control in a system. It consists of activities and links. The
flow can be sequential, concurrent, or branched.

34
Activities are nothing but the functions of a system. Numbers of activity diagrams are prepared
to capture the entire flow in a system.
Activity diagrams are used to visualize the flow of controls in a system. This is prepared to have
an idea of how the system will work when executed.
Components of an Activity Diagram
Below we describe the building blocks of an activity diagram.
 Activity
An activity denotes a particular action taken in the logical flow of control. This could simply
be invocation of a mathematical function, alter an object's properties and so on. An activity is
represented with a rounded rectangle. A label inside the rectangle identifies the
corresponding activity.
There are two special type of activity nodes: initial and final. They are represented with a
filled circle, and a filled in circle with a border respectively. Initial node represents the
starting point of a flow in an activity diagram. There could be multiple initial nodes, which
mean that invoking that particular activity diagram would initiate multiple flows.
A final node represents the end point of all activities. Like an initial node, there could be
multiple final nodes. Any transition reaching a final node would stop all activities.

 Flow
A flow (also termed as edge, or transition) is represented with a directed arrow. This is used
to depict transfer of control from one activity to another, or to other types of components. A
flow is often accompanied with a label, called the guard condition, indicating the necessary
condition for the transition to happen. The syntax to depict it is [guard condition].
 Decision
A decision node, represented with a diamond, is a point where a single flow enters and two
or more flows leave. The control flow can follow only one of the outgoing paths. The
35
outgoing edges often have guard conditions indicating true-false or if-then-else conditions.
However, they can be omitted in obvious cases. The input edge could also have guard
conditions. Alternately, a note can be attached to the decision node indicating the condition
to be tested.
 Merge
This is represented with a diamond shape, with two or more flows entering, and a single flow
leaving out. A merge node represents the point where at least a single control should reach
before further processing could continue.
 Fork
Fork is a point where parallel activities begin. For example, when a student has been
registered with a college, he can in parallel apply for student ID card and library card. A fork
is graphically depicted with a black bar, with a single flow entering and multiple flows
leaving out.
 Join
A join is depicted with a black bar, with multiple input flows, but a single output flow.
Physically it represents the synchronization of all concurrent activities. Unlike a merge, in
case of a join all of the incoming controls must be completed before any further progress
could be made. For example, a sales order is closed only when the customer has receive the
product, and the sales company has received it's payment.
 Note
UML allows attaching a note to different components of a diagram to present some textual
information. The information could simply be a comment or may be some constraint. A note
can be attached to a decision point, for example, to indicate the branching criteria.
 Partition
Different components of an activity diagram can be logically grouped into different areas,
called partitions or swim-lanes. They often correspond to different units of an organization or
different actors. The drawing area can be partitioned into multiple compartments using
vertical (or horizontal) parallel lines. Partitions in an activity diagram are not mandatory.

Component Graphical Notation

Activity

36
 Component Graphical Notation

Flow

Decision

Merge

Fork

Join

Note

State chart Diagram

37
Any real-time system is expected to be reacted by some kind of internal/external events. These
events are responsible for state change of the system.
State chart diagram is used to represent the event driven state change of a system. It basically
describes the state change of a class, interface, etc.
State chart diagram is used to visualize the reaction of a system by internal/external factors.
Collaboration Diagram
Collaboration diagram is another form of interaction diagram. It represents the structural
organization of a system and the messages sent/received. Structural organization consists of
objects and links.
The purpose of collaboration diagram is similar to sequence diagram. However, the specific
purpose of collaboration diagram is to visualize the organization of objects and their interaction.

References:
[1] https://nptel.ac.in/courses/pdf_link/106105182/lec30.pdf
[2] https://www.uml-diagrams.org/

38
Aim: Prepare following UML Diagrams for system selected in practical 2.
1. Use-Case Diagram
2. Entity Relationship Diagram
3. Sequence Diagram
4. Activity Diagram
5. Class Diagram

: Prepare following UML Diagrams for system selected in practical 2.

Fig: Usecase diagram for Library Book Management System

39
Fig: Sequence Diagram for User Login

Fig: Sequence Diagram for User Details

40
Fig: Sequence Diagram for Book Details

41
Fig: Sequence Diagram for Managing Member Details

Fig: Activity Diagram for Book Issue

42
Fig: Activity Diagram for Book Search

43
Post Practical Questions:
1. Which model in system modeling depicts the static nature of the system?
a) Behavioral Model
b) Context Model
c) Data Model
d) Structural Model
2. Which model in system modeling depicts the dynamic behavior of the system?
a) Context Model
b) Behavioral Model
c) Data Model
d) Object Model
3. Which perspective in system modeling shows the system or data architecture?
a) Structural perspective
b) Behavioral perspective
c) External perspective
d) All of the mentioned
4. The UML supports event-based modeling using ____________ diagrams.
a) Deployment
b) Collaboration
c) State chart
d) All of the mentioned
5. _________________ allows us to infer that different members of classes have some
common characteristics.
a) Realization
b) Aggregation
c) Generalization
d) dependency
6. ___________ Classes are used to create the interface that the user sees and interacts with
as the software is used.
a) Controller
b) Entity
c) Boundary
d) Business

44
 7. ______________ & ______________ diagrams of UML represent Interaction modeling.
a) Use Case, Sequence
b) Class, Object
c) Activity, State Chart
d) All of the mentioned
8. The Unified Modeling Language (UML) has become an effective standard for software
modeling. How many different notations does it have?
a) Three
b) Four
c) Six
d) Nine
9. Model-driven engineering is just a theoretical concept. It cannot be converted into a
working/executable code.
a) True
b) False
10. Which of the following statement is incorrect regarding the Class-responsibility-
collaborator (CRC) modeling?
a) All use-case scenarios (and corresponding use-case diagrams) are organized into
categories in CRC modeling
b) The review leader reads the use-case deliberately
c) Only developers in the review (of the CRC model) are given a subset of the CRC
model index cards
d) All of the mentioned

Conclusion:

In this practical we learnt about Data Flow Diagram for software.

45
 PRACTICAL SET – 4
STUDY SYSTEM MODELING USING DATA FLOW DIAGRAMS.

What is Data Flow Diagram (DFD)?

The DFD (also known as a bubble chart) is a hierarchical graphical model of a system that shows
the different processing activities or functions that the system performs and the data interchange
among these functions. Each function is considered as a processing station (or process) that
consumes some input data and produces some output data. The system is represented in terms of
the input data to the system, various processing carried out on these data, and the output data
generated by the system. A DFD model uses a very limited number of primitive symbols to
represent the functions performed by a system and the data flow among these functions.

Why DFD?
The main reason why the DFD technique is so popular is probably because of the fact that DFD
is a very simple formalism – it is simple to understand and use. Starting with a set of high-level
functions that a system performs, a DFD model hierarchically represents various sub-functions.
In fact, any hierarchical model is simple to understand. Human mind is such that it can easily
understand any hierarchical model of a system – because in a hierarchical model, starting with a
very simple and abstract model of a system, different details of the system are slowly introduced
through different hierarchies. The data flow diagramming technique also follows a very simple
set of intuitive concepts and rules. DFD is an elegant modeling technique that turns out to be
useful not only to represent the results of structured analysis of a software problem, but also for
several other applications such as showing the flow of documents or items in an organization.

Graphical notations for Data Flow Diagram

 Process:
Processes are represented by circle. The name of the process is written into the circle. The
name of the process is usually given in such a way that represents the functionality of the
process. More detailed functionalities can be shown in the next Level if it is required.
Usually it is better to keep the number of processes less than 7. If we see that the number of
processes becomes more than 7 then we should combine some the processes to a single one
to reduce the number of processes and further decompose it to the next level.

External entity: External entities are only appearing in context diagram. External entities are
represented by a rectangle and the name of the external entity is written into the shape. These
send data to be processed and again receive the processed data.

46
Data store: Data stares are represented by a left-right open rectangle. Name of the data store
is written in between two horizontal lines of the open rectangle. Data stores are used as
repositories from which data can be flown in or flown out to or from a process.

Data flow: Data flows are shown as a directed edge between two components of a Data Flow
Diagram. Data can flow from external entity to process, data store to process, in between two
processes and vice-versa.

Context diagram and levelling DFD

Start with a broad overview of a system represented in level 0 diagram. It is known as
context diagram of the system. The entire system is shown as single process and also the
interactions of external entities with the system are represented in context diagram.Further
we split the process in next levels into several numbers of processes to represent the detailed
functionalities performed by the system. Data stores may appear in higher level DFDs.

Numbering of processes:
If process ‘p’ in context diagram is split into 3 processes ‘p1’, ‘p2’and ‘p3’ in next level then
these are labelled as 0.1, 0.2 and 0.3 in level 1 respectively. Let the process ‘p3’ is again split
into three processes ‘p31’, ‘p32’ and ‘p33’ in level 2, so, these are labelled as 0.3.1, 0.3.2 and
0.3.3 respectively and so on.

Balancing DFD:
The data that flow into the process and the data that flow out to the process need to be match
when the process is split into in the next level. This is known as balancing a DFD.

47
Aim: Prepare Data Flow Diagrams –DFD for system selected in practical 2.

Fig: DFD (Level 0) for Library Management System

48
Fig: DFD (Level 1) for Member

49
Fig: DFD (Level 1) for Staff

50
Post Practical Questions:
1. Which of the following is a complementary approach to function-oriented approach?
a) Object oriented analysis
b) Object oriented design
c) Structured approach
d) Both Object oriented analysis and design
2. Structured Analysis is based on the principles of
a) Top-down decomposition approach
b) Divide and conquer principle
c) Graphical representation of results using DFDs
d) All of the mentioned
3. The __________ enables the software engineer to develop models of the information
domain and functional domain at the same time
a) Data flow diagram
b) State transition diagram
c)Control specification
d) Activity Diagram
4. In DFDs, user interactions with the system is denoted by
a) Circle
b) Arrow
c) Rectangle
d) Triangle
5. A DFD is always accompanied by a data dictionary.
a) True
b) False
6. The context diagram is also known as
a) Level-0 DFD
b) Level-1 DFD
c) Level-2 DFD
d) All of the mentioned
7. What DFD notation is represented by the Rectangle?
a) Transform
b) Data Store
c) Function
d) None of the mentioned

51
 8. Data Store Symbol in DFD represents a
a) Physical file
b) Data Structure
c) Logical file
d) All of the mentioned
9. State whether the following statements about the advantages of using the data dictionary
are True or False.
i) The data dictionary software can check for name uniqueness and tell requirements
analysis of name duplication.
ii) Data dictionary servers as store of organization information which can link analysis,
design, implementation and evaluation.
a) True, False
b) False, True
c) False, False
d) True, True
10. A data model contains
a) Data object
b) Attributes
c) Relationships
d) All of the mentioned

Conclusion:

In this practical we learnt about Data Flow Diagram for software.

52
 PRACTICAL SET – 5
STUDY SOFTWARE PROJECT ESTIMATION TECHNIQUES, FUNCTION POINT
ANALYSIS AND COCOMO MODEL.

What is Project Estimation?

Estimation is the process of finding an estimate, or approximation, which is a value that can be
used for some purpose even if input data may be incomplete, uncertain, or unstable. Estimation
determines how much money, effort, resources, and time it will take to build a specific system or
product.

Estimation is based on
 Past Data/Past Experience
 Available Documents/Knowledge
 Assumptions
 Identified Risks

The four basic steps in Software Project Estimation are

 Estimate the size of the development product.
 Estimate the effort in person-months or person-hours.
 Estimate the schedule in calendar months.
 Estimate the project cost in agreed currency.

Project Estimation Approach

 Decomposition Technique
o LOC based Estimation
o FP based Estimation
o Use-Case Based Estimation

 Empirical Estimation Model

o COCOMO Model

53
AIM: ESTIMATE EFFORTS AND COST USING FUNCTION POINT AND COCOMO
MODEL.
5.1 FUNCTION POINT
The purpose of FP procedure is to produce an estimate of software size from software
requirements. Function Points are an indirect measure of software size based on external and
internal application characteristics, as well as application performance. Function Points have a
significant cost estimating relationship (CER) to software costs. Once determined, Function
Points can be input into empirical statistical parametric software cost estimation equations and
models in order to estimate software costs. Function Points are widely reported to be well suited
for measuring the size of management information system (MIS), database intensive, and 4GL
based application (e.g., software) system development.
SCOPE
Function Points are indirect quantitative measures of application software functionality and size
that are based on objective counts of external application interfaces factored together with
subjective counts of internal application complexity and overall performance characteristics.
This procedure is composed of three logical divisions, determining the unadjusted function
point count, value adjustment factor, and Function Points.
Determining the unadjusted function point count consists of counting the number of external
inputs, external outputs, external inquiries, internal logical files, and external interface
files. Determining the value adjustment factor consists of rating system, input and output, and
application complexity.
Determining Function Points consists of factoring unadjusted function points and value
adjustment factor together. Function Points have two distinct purposes.
The first purpose is to act as a basis for software measurement, comparison, and analysis (e.g., a
software metrics approach).
The second, and more important purpose, is to determine software size for input into software
cost estimation models (e.g., equations) and tools that output effort (e.g., staff hours), which are
based on empirical cost estimating relationships (CERs) between Function Points and effort.
Methodology of calculating the function points
We need to under stand a system first with respect to the function points for that consider an
application model as below for measuring the function points.
The Five Major Components
Since it is common for computer systems to interact with other computer systems, a boundary
must be drawn around each system to be measured prior to classifying components. This
boundary must be drawn according to the user’s point of view. In short, the boundary indicates
the border between the project or application being measured and the external applications or

54
user domain. Once the border has been established, components can be classified, ranked and
tallied.

External Inputs (EI) - is an elementary process in which data crosses the boundary from outside
to inside. This data may come from a data input screen or another application. The data may be
used to maintain one or more internal logical files. The data can be either control information or
business information. If the data is control information it does not have to update an internal
logical file. The graphic represents a simple EI that updates 2 ILF's (FTR's).

External Outputs (EO) - An elementary process in which derived data passes across the
boundary from inside to outside. Additionally, an EO may update an ILF. The data creates
reports or output files sent to other applications. These reports and files are created from one or
more internal logical files and external interface file. The following graphic represents on EO
with 2 FTR's there is derived information (green) that has been derived from the ILF's

55
External Inquiry (EQ) - An elementary process with both input and output components will
result in data retrieval from one or more internal logical files and external interface files. The
input process does not update any Internal Logical Files, and the output side does not contain
derived data. The graphic below represents an EQ with two ILF's and no derived data.

Internal Logical Files (ILF’s) - The user identifiable group of logically related data that
resides entirely within the applications boundary and is maintained through external inputs.
External Interface Files (EIF’s) - The user identifiable group of logically related data that is
used for reference purposes only. The data resides entirely outside the application and is
maintained by another application. The external interface file is an internal logical file for
another application.
The counts for each level of complexity for each type of component can be entered into a table
such as the following one. Each count is multiplied by the numerical rating shown to determine
the rated value. The rated values on each row are summed across the table, giving a total value
for each type of component. These totals are then summed across the table, giving a total value
for each type of component. These totals are then summoned down to arrive at the Total Number
of Unadjusted Function Points.

56
The value adjustment factor (VAF) is based on 14 general system characteristics (GSC's) that
rate the general functionality of the application being counted. Each characteristic has associated
descriptions that help determine the degrees of influence of the characteristics. The degrees of
influence range on a scale of zero to five, from no influence to strong influence. The IFPUG
Counting Practices Manual provides detailed evaluation criteria for each of the GSC'S, the table
below is intended to provide an overview of each GSC.
Further the calculation of VAF (Value added Factor) which is based on the TDI (Total Degree of
Influence of the 14 General system characteristics)
a) TDI = Sum of (DI of 14 General System Characteristics) where DI stands for Degree
of Influence.
b) These 14 GSC are
1. Data Communication _________
2. Distributed Data Processing _________
3. Performance _________
4. Heavily Used Configuration _________
5. Transaction Role _________
6. Online Data Entry _________
7. End-User Efficiency _________
8. Online Update _________
9. Complex Processing _________
10. Reusability _________
11. Installation Ease _________
57
 12. Operational Ease _________
13. Multiple Sites _________
14. Facilitate Change _________
TDI = _________
c) The degree of influence range is on a scale of zero to five, from no influence to
strong influence.

Rating Degree of Influence

0 Not present, or no influence

1 Incidental influence

2 Moderate influence

3 Average influence

4 Significant influence

5 Strong influence throughout

Determine the degree of influence for each of the 14 GSCs.

The sum of the values of the 14 GSCs thus obtained is termed as Total Degree of Influence
(TDI).

TDI = ∑14 Degrees of Influence

=_________

Next, calculate Value Adjustment Factor (VAF) as

VAF = (TDI × 0.01) + 0.65
=________

58
Calculate Adjusted Function Point Count

As per the FPA approach that uses the VAF (CPM versions before V4.3.1), this is determined
by,
Adjusted FP Count = Unadjusted FP Count × VAF

5.2 Empirical Cost Estimation

Cost estimation can be defined as the approximate judgment of the costs for a project. Cost
estimation will never be an exact science because there are too many variables involved in the
calculation for a cost estimate, such as human, technical, environmental, and political.

Methods for estimation in software engineering include this principle:

COCOMO MODEL:
COCOMO (Constructive Cost Model) is a model that allows one to estimate the cost,
effort, and schedule when planning a new software development activity.
COCOMO is useful for a much wider collection of techniques and technologies.
COCOMO provides up-to-date support for business software, object – oriented software,
software created via evolutionary development models and software developed using
commercial- off-the-shelf application composition utilities.

Objective of Software Cost Estimation with COCOMO:

The most fundamental calculation in the COCOMO model is the use of the effort
equation to estimate the number of person/ months required to develop a project.
Software cost estimation is important for making good management decisions. It is also
connected to determining how much effort and time a software project requires.
Cost estimation has several uses:

• It establishes a firm, reliable budget for an –in house project.

• It facilitates competitive contract bids.
• It determines what is most effective for the organization.

59
FORMULA FOR CALCULATING EFFORT:

For Small Project:

EFFORT = a * SIZE + b

Here, the magnitude of the effort is a linear function of the size of the project (Number of Lines
of Code, usually). This model holds up until a certain point, usually for projects that can be
reasonably accomplished by small teams of two or three people. By increasing the size of the
project, the above model becomes less and less accurate and the need for a new model increases.

For Large Project:

EFFORT = a * SIZE b

Here, the size of the project is scaled exponentially, therefore as a product increases in size, the
effort to produce the product grows more than linearly (for b >= 1). It means that if we try to
develop a larger product, our productivity (SIZE / EFFORT) Decreases.
The main reasons why larger software products incur diseconomies of scale are the following:
1. Relatively more product design is required to develop the thorough unit-level
specifications required to support the parallel activity of a larger number of programmers.

2. Relatively more effort is required to verify and validate the larger requirements and
design specifications.

3. Even with a thoroughly defined specification, programmers on a large project will spend
relatively more time communicating and resolving interface issues.
4. Relatively more integration activity is required to put the units together.
Effort Equation:

Where,
Effort = 2.94 * EAF * (KSLOC) E

EAF: Is the Effort Adjustment Factor derived from the Cost Drivers.
E: Is an exponent derived from the five Scale Drivers.

60
Effort Adjustment Factor:
The Effort Adjustment Factor in the effort equation is simply the product of the effort multipliers
corresponding to each of the cost drivers for your project.
For example, if your project is rated Very High for Complexity (effort multiplier of 1.34), and
Low for Language & Tools Experience (effort multiplier of 1.09), and all of the other cost
drivers are rated to be Nominal (effort multiplier of 1.00), the EAF is the product of 1.34 and
1.09.
Effort Adjustment Factor = EAF=1.34*1.09 = 1.46
Effort = 2.94 * (1.46) * (8)1.0997= 42.3 Person-Months
Schedule Equation: Duration = 3.67 * (Effort) SE
Where,
Effort: Is the effort from the COCOMO effort equation.
SE: Is the schedule equation exponent derived from the five Scale Drivers.
Average Staffing: Average staffing=Effort/Duration

System Implementation:
Step 1: Input develops software.
Step 2: Compute the value of EAF.
Step 3: Find the value of E and SE.
Step 4: Find the size of Software (KSLOC).
Step 5: Calculate the Effort Equation by: Effort = 2.94 * EAF * (KSLOC) E
Step 6: Calculate the Duration Equation by: Duration = 3.67 * (Effort) SE
Step 7: Calculate the Average staffing by: Average staffing=Effort/Duration
Step 8: Analysis the result and draw the output is represented the volume of effort to complete
the software.
Step 9: End.

61
Analysis Result:
Eg. The Electricity Measurement project build by JAVA– Language with all normal cost drivers
and scale drivers would have an EAF of 1.00 and exponent , E of 1.0997 and consist of 10,000
source lines of code , COCOMO II estimates that 90.543 person – months of effort is required to
complete it :-
Effort=2.94*(1.0)*(10)1.0997 =36.9868 Person/ Months
Duration=3.67*(36.9868)0.3179 =11.5650 months
Average Staffing =Effort/Duration = (36.9868)/ (11.5650) =3.19816 Person.
Calculate for your system selected for the Practical 2.
Effort=
Duration=
Average Staffing =Effort/Duration =

References:
1. https://nptel.ac.in/courses/106105087/28
2. http://www.softwaremetrics.com/fpafund.htm
3. http://vlabs.iitkgp.ernet.in/se/2/

62
63
Post Practical Questions:
1. Which of the following is an important factor that can affect the accuracy and efficacy of
estimates?
a) Project size
b) Planning process
c) Project complexity
d) Degree of structural uncertainty
2. The project planner examines the statement of scope and extracts all important software
functions which is known as
a) Association
b) Decomposition
c) Planning process
d) All of the mentioned
3. Which of the following is not an option to achieve reliable cost and effort estimate?
a) Base estimates on similar projects that have already been completed
b) Use one or more empirical models for software cost and effort estimation
c) Use relatively simple decomposition techniques to generate project cost and effort
estimates
d) The ability to translate the size estimate into human effort, calendar time, and
dollars
4. What can be used to complement decomposition techniques and offer a potentially
valuable estimation approach in their own right?
a) Automated estimation tools
b) Empirical estimation models
c) Decomposition techniques
d) Both Automated estimation tools and Empirical estimation models
5. Which of the following are parameters involved in computing the total cost of a software
development project?
a) Hardware and software costs
b) Effort costs
c) Travel and training costs
d) All of the mentioned
6. Which of the following costs is not part of the total effort cost?
a) Costs of networking and communications
b) Costs of providing heating and lighting office space
c) Costs of lunch time food
d) Costs of support staff

64
 7. What is related to the overall functionality of the delivered software?
a) Function-related metrics
b) Product-related metrics
c) Size-related metrics
d) None of the mentioned
8. Which version of COCOMO states that once requirements have been stabilized, the basic
software architecture has been established?
a) Early design stage model
b) Post-architecture-stage model
c) Application composition model
d) All of the mentioned
9. Which model was used during the early stages of software engineering, when prototyping
of user interfaces, consideration of software and system interaction, assessment of
performance, and evaluation of technology maturity were paramount.
a) Early design stage model
b) Post-architecture-stage model
c) Application composition model
d) All of the mentioned
10. Which one is not a stage of COCOMO-II?
a) Early design estimation model
b) Application Composition estimation model
c) Comprehensive cost estimation model
d) Post architecture estimation model

Conclusion:

In this practical , we learnt about cost analysis software project estimation

technique, Functon Point and COCOMO model.

65
 PRACTICAL SET – 6
STUDY PROJECT SCHEDULING TECHNIQUES/TOOLS. CRITICAL PATH
METHOD (CPM), PROJECT EVALUATION AND REVIEW TECHNIQUE (PERT),
GANTT CHART AND WORK-BREAKDOWN STRUCTURE.

What is Software Project Scheduling?

Software project scheduling is an activity that distributes estimated effort across the planed
project duration by allocating the effort to specific software engineering tasks.
 During early stages of project planning, a macroscopic schedule is developed identifying
all major process framework activities and the product functions to which they apply.
 Later, each task is refined into a detailed schedule where specific software tasks are
identified and scheduled.

Basic Principles for Project Scheduling:

 Compartmentalization:
The project must be compartmentalized into a number of manageable activities, actions,
and tasks; both the product and the process are decomposed
 Interdependency:
The interdependency of each compartmentalized activity, action, or task must be
determined
Some tasks must occur in sequence while others can occur in parallel
Some actions or activities cannot commence until the work product produced by another
is available
 Time allocation:
Each task to be scheduled must be allocated some number of work units
In addition, each task must be assigned a start date and a completion date where there the
function of the interdependencies
Start and stop dates are also established based on whether work will be conducted on a
full-time or part time basis.
 Effort validation:
Every project has a defined number of people on the team
As time allocation occurs, the project manager must ensure that no more than the
allocated numbers of people have been scheduled at any given time

66
  Defined responsibilities:
Every task that is scheduled should be assigned to a specific team member
 Defined outcomes:
Every task that is scheduled should have a defined outcome for software projects such as
a work product or part of a work product – Work products are often combined in
deliverables
 Defined milestones:
Every task or group of tasks should be associated with a project milestone
A milestone is accomplished when one or more work products has been reviewed for
quality and has been approved

Factors that Influence a Project’s Schedule:

 Size of the project
 Number of potential users
 Mission criticality
 Application longevity
 Stability of requirements
 Ease of customer/developer communication
 Maturity of applicable technology
 Performance constraints
 Embedded and non-embedded characteristics
 Project staff
 Reengineering factors

Prerequisites for Project Scheduling:

Define a Task Set for Software Project:
 Concept scoping
 Preliminary concept planning
 Technology risk assessment
 Proof of concept
 Concept implementation
 Customer reaction

67
Define a Task Set Network:
 Individual tasks and subtasks have interdependencies based on their sequence
 Also called an activity network
 It is a graphic representation of the task flow for a project
 It represent task length, sequence, concurrency, and dependency
 Points out inter-task dependencies to help the manager ensure continuous progress
toward project completion

Project Scheduling Tools & Techniques:

Program Evaluation and Review Technique (PERT):
PERT is used to schedule, organize, and coordinate tasks within a project. It is basically a
method to analyze the tasks involved in completing a given project, especially the time needed to
complete each task, and to identify the minimum time needed to complete the total project. The
main objective of PERT is to facilitate decision making and to reduce both the time and cost
required to complete a project.

PERT planning involves the following steps that are described below.

1. Identify the specific activities and milestones. The activities are the tasks required to
complete a project. The milestones are the events marking the beginning and the end of
one or more activities. It is helpful to list the tasks in a table that in later steps can be
expanded to include information on sequence and duration.

68
2. Determine the proper sequence of the activities. This step may be combined with the
activity identification step since the activity sequence is evident for some tasks. Other
tasks may require more analysis to determine the exact order in which they must be
performed.
3. Construct a network diagram. Using the activity sequence information, a network
diagram can be drawn showing the sequence of the serial and parallel activities. Each
activity represents a node in the network, and the arrows represent the relation between
activities. Software packages simplify this step by automatically converting tabular
activity information into a network diagram.
4. Estimate the time required for each activity. Weeks are a commonly used unit of time
for activity completion, but any consistent unit of time can be used. A distinguishing
feature of PERT is its ability to deal with uncertainty in activity completion time. For
each activity, the model usually includes three time estimates:

69
  Optimistic time – generally the shortest time in which the activity can be completed.
It is common practice to specify optimistic time to be three standards deviations from
the mean so that there is a approximately a 1% chance that the activity will be
completed within the optimistic time.
 Most likely time – the completion time having the highest probability. Note that this
time is different from the expected time.
 Pessimistic time – the longest time that an activity might require. Three standard
deviations from the mean is commonly used for the pessimistic time.

Critical Path Method (CPM):

The critical path is determined by adding the times for the activities in each sequence and
determining the longest path in the project. The critical path determines the total calendar time
required for the project. If activities outside the critical path speed up or slow down (within
limits), the total project time does not change. The amount of time that a non – critical path
activity can be delayed without the project is referred to as a slack time.

If the critical path is not immediately obvious, it may be helpful to determine the following four
quantities for each activity:

ES – Earliest Start time

EF - Earliest Finish time
LS – Latest Start time
LF - Latest Finish time

These times are calculated using the expected time for the relevant activities. The earliest start
and finish times of each activity are determined by working forward through the network and
determining the earliest time at which an activity can start and finish considering its predecessors
activities. The latest start and finish times are the latest times that an activity can start and finish
without delaying the project. LS and LF are found by working backward through the network.
The difference in the latest and earliest finish of each activity is that activity’s slack. The critical
path then is the path through the network in which none of the activities have slack.

The variance in the project completion time can be calculated by summing the variances in the
completion times of the activities in the critical path. Given this variance, one can calculate the
probability that the project will be completed by the certain date assuming a normal probability
distribution for the critical path. The normal distribution assumption holds if the number of
activities in the path is large enough for the central limit theorem to be applied.

Since the critical path determines the completion date of the project, the project can be
accelerated by adding the resources required to decrease the time for the activities in the critical
path. Such a shortening of the project sometimes is referred to as project crashing.
70
Work Breakdown Structure:

A work breakdown structure (WBS), in project management and systems engineering, is a

deliverable oriented decomposition of a project into smaller components. It defines and groups a
project's discrete work elements in a way that helps organize and define the total work scope of
the project.

A WBS is the cornerstone of effective project planning, execution, controlling, statusing, and
reporting. All the work contained within the WBS is to be identified, estimated, scheduled, and
budgeted. The WBS is the structure and code that integrates and relates all project work (scope,
schedule, and cost). When initial project funding is received, the Project Director (PD) develops
a WBS that identifies necessary funds according to the schedule and needs of the tasks in the
WBS elements. The WBS is generally a multi-level framework that organizes and graphically
displays elements representing work to be accomplished in logical relationships. The PD is to
structure the project work into WBS elements (work packages) that are:

Definable: can be described and easily understood by project participants.

Manageable: a meaningful unit of work where specific responsibility and authority can be
assigned to a responsible individual.
Estimateable: duration can be estimated in time required to complete, and cost can be estimated
in resources required to complete.
Independent: minimum interface with or dependence on other ongoing elements (i.e.,
assignable to a single control account, and clearly distinguishable from other work packages).
Integratable: integrates with other project work elements and with higher level cost estimates
and schedules to include the entire project.
Measurable: can be used to measure progress; has start and completion dates and measurable
interim milestones.
Adaptable: sufficiently flexible so the addition/elimination of work scope can be readily
accommodated in the WBS framework.

Gantt chart

A Gantt chart is a horizontal bar chart developed as a production control tool in 1917 by Henry
L. Gantt, an American engineer and social scientist. Frequently used in project management, a
Gantt chart provides a graphical illustration of a schedule that helps to plan, coordinate, and track
specific tasks in a project.

71
A Gantt chart is constructed with a horizontal axis representing the total time span of the project,
broken down into increments (for example, days, weeks, or months) and a vertical axis
representing the tasks that make up the project (for example, if the project is outfitting your
computer with new software, the major tasks. Horizontal bars of varying lengths represent the
sequences, timing, and time span for each task.

As the project progresses, secondary bars, arrowheads, or darkened bars may be added to
indicate completed tasks, or the portions of tasks that have been completed. A vertical line is
used to represent the report date. Gantt charts give a clear illustration of project status, but one
problem with them is that they don't indicate task dependencies - you cannot tell how one task
falling behind schedule affects other tasks.

References:

[1] Roger S.Pressman, Software engineering- A practitioner’s

approach, McGraw-Hill International Editions
[2] Ian Sommerville, Software engineering, Pearson education Asia
[3] https://nptel.ac.in/courses/106105087/29

72
Aim: Prepare Gantt Chart and Work-Breakdown Structure for the system selected in practical 2.

Fig: Gantt Chart for Library Management System

73
Post Practical Questions:
1. Which of the following is the reason that software is delivered late?
a) Changing customer requirements that are not reflected in schedule changes
b) Technical difficulties that could not have been foreseen in advance
c) Human difficulties that could not have been foreseen in advance
d) All of the mentioned
2. Which of the following is an activity that distributes estimated effort across the planned
project duration by allocating the effort to specific software engineering tasks?
a) Software Macroscopic schedule
b) Software Project scheduling
c) Software Detailed schedule
d) None of the mentioned
3. Every task that is scheduled should be assigned to a specific team member is termed as
a) Compartmentalization
b) Defined milestones
c) Defined responsibilities
d) Defined outcomes
4. What is a collection of software engineering work tasks, milestones, and deliverables that
must be accomplished to complete a particular project?
a) Task set
b) Degree of milestone
c) Adaptation criteria
d) All of the mentioned
5. Ensuring that no more than the allocated number of people are allocated at any given
time in Software Scheduling is known as
a) Time Allocation
b) Effort Validation
c) Defined Milestone
d) Effort Distribution
6. What is used to determine the recommended degree of rigor with which the software
process should be applied on a project?
a) Degree of Rigor
b) Adaptation criteria
c) Task Set
d) Both degree of Rigor and adaptation criteria

74
 7. What evaluates the risk associated with the technology to be implemented as part of
project scope?
a) Concept scoping
b) Preliminary concept planning
c) Technology risk assessment
d) Customer reaction to the concept
8. Which of the following is not an adaptation criteria for software projects?
a) Size of the project
b) Customers Complaints
c) Project staff
d) Mission criticality
9. Which of the following is a project scheduling method that can be applied to software
development?
a) PERT
b) CPM
c) CMM
d) Both PERT and CPM
10. A technique for performing quantitative analysis of progress is known as
a) BCWS
b) EVA
c) BAC
d) CBSE

Conclusion:

In this practical, we learnt about project scheduling and Gantt

Chart.

75
 PRACTICAL SET – 7
STUDY SOFTWARE RISK ANALYSIS AND MANAGEMENT.

What is Software Risk?

Risk is an expectation of loss, a potential problem that may or may not occur in the future. It is
generally caused due to lack of information, control or time. A possibility of suffering from loss
in software development process is called a software risk. Loss can be anything, increase in
production cost, development of poor quality software, not being able to complete the project on
time. Software risk exists because the future is uncertain and there are many known and
unknown things that cannot be incorporated in the project plan.

A software risk can be of two types

 Internal risks that are within the control of the project manager
 External risks that are beyond the control of project manager

Categories of the risk:

 Project risk:
o If the project risk is real then it is probable that the project schedule will slip and the
cost of the project will increase.
o It identifies the potential schedule, resource, stakeholders and the requirements
problems and their impact on a software project.

 Business risk:
If the business risk is real then it harms the project or product.
There are five sub-categories of the business risk:
1. Market risk - Creating an excellent system that no one really wants.
2. Strategic risk - Creating a product which no longer fit into the overall business
strategy for companies.
3. Sales risk - The sales force does not understand how to sell a creating product.

76
 4. Management risk - Loose a support of senior management because of a change in
focus.
5. Budget risk - losing a personal commitment.

Technical risk:
o If the technical risk is real then the implementation becomes impossible.
o It identifies potential design, interface, verification and maintenance of the problem.

Principles of risk management:

 Maintain a global perspective

View software risks in the context of a system and the business problem planned to solve.
 Take a forward looking view
 Think about the risk which may occur in the future and create future plans for managing
the future events.
 Encourage open communication
Encourage all the stakeholders and users for suggesting risks at any time.
 Integrate
A consideration of risk should be integrated into the software process.
 Emphasize a continuous process
Modify the identified risk than the more information is known and add new risks as better
insight is achieved.
 Develop a shared product vision
If all the stakeholders share the same vision of the software then it is easier for better risk
identification.
 Encourage teamwork
While conducting risk management activities pool the skills and experience of all
stakeholders.

Fundamental steps of Risk Management:

77
Step 1. Risk Identification
Risk identification is the critical first step of the risk management process. Its objective is the
early and continuous identification of risks, including those within and external to the
engineering system project.

Step 2. Risk Impact or Consequence Assessment

In this step, an assessment is made of the impact each risk event could have on the engineering
system project. Typically, this includes how the event could impact cost, schedule, or technical
performance objectives. Impacts are not limited to only these criteria. Additional criteria such as
political or economic consequences may also require consideration. In addition, an assessment is
made of the probability (chance) each risk event will occur.

Step 3. Risk Prioritization

At this step, the overall set of identified risk events, their impact assessments, and their
occurrence probabilities are "processed" to derive a most critical to least critical rank-order of
identified risks. A major purpose for prioritizing risks is to form a basis for allocating critical
resources.

Step 4. Risk Mitigation, Monitoring and Management Planning RMMM

This step involves the development of mitigation plans designed to manage, eliminate, or reduce
risk to an acceptable level. Once a plan is implemented, it is continually monitored to assess its
efficacy with the intent to revise the course-of-action, if needed.

References:
[1] Roger S.Pressman, Software engineering- A practitioner’s Approach,
McGraw-Hill International Editions
[2] https://nptel.ac.in/courses/106105087/31

78
Aim: Prepare RMMM Plan for system selected in practical 2.

Risk Information Sheet

Risk ID: 01 Date: 10/4/2020 Probability: 78 % Impact:Medium
Description:
System is quite unstable.
Lack of security.
Inconsistency.
Neglectable bugs.
Refinement/Context:
System is unstable due to the unexpected developer.
It may generate error.
the critical problem is harder to find.
There is issue in map.
Mitigation/Monitoring:
Testing of each module should be done.
Must have proper database
Solutions to bugs should also be found.
Management/Contingency Plan:
We must have proper backup of database.
Expert should be hire in case of emergency or in case of issue.
Allocate this amount within the project management cost.

Current Status: Mitigation step initiated.

Originator: Assigned:
Priyal S. Dalal Priyal Dalal

79
Post Practical Questions:
1. What is the product of the probability of incurring a loss due to the risk and the potential
magnitude of that loss?
a) Risk exposure
b) Risk prioritization
c) Risk analysis
d) All of the mentioned
2. What threatens the quality and timeliness of the software to be produced?
a) Known risks
b) Business risks
c) Project risks
d) Technical risks
3. Which of the following is not a business risk?
a) building an excellent product or system that no one really wants
b) losing the support of senior management due to a change in focus or change in people
c) lack of documented requirements or software scope
d) losing budgetary or personnel commitment
4. Which of the following is a systematic attempt to specify threats to the project plan?
a) Risk identification
b) Performance risk
c) Support risk
d) Risk projection
5. Which of the following term is best defined by the statement:”the degree of uncertainty
that the product will meet its requirements and be fit for its intended use.”?
a) Performance risk
b) Cost risk
c) Support risk
d) Schedule risk
6. Which risks are associated with constraints imposed by management or the marketplace?
a) Business impact risks
b) Process definition risks
c) Product size risks
d) Development environment risks

80
 7. Which risks are associated with the overall size of the software to be built or modified?
a) Business impact risks
b) Process definition risks
c) Product size risks
d) Development environment risks
8. Which of the following is not a business risk?
a) building an excellent product or system that no one really wants
b) losing the support of senior management due to a change in focus or change in people
c) lack of documented requirements or software scope
d) losing budgetary or personnel commitment
9. Which of the following term is best defined by the statement: “Derive traceability
information to maximize information hiding in the design.”?
a) Underestimated development time
b) Organizational restructuring
c) Requirements changes
d) None of the mentioned
10. What assess the risk and your plans for risk mitigation and revise these when you learn
more about the risk?
a) Risk monitoring
b) Risk planning
c) Risk analysis
d) Risk identification

Conclusion:

In this practical,we learnt about risk information sheet which described about
risk developed after development.

81
 PRACTICAL SET – 8
STUDY SOFTWARE TESTING AND DESIGN TEST SUITES / CASES.

What is Software Testing?

Software Testing is evaluation of the software against requirements gathered from users and
system specifications. Testing is conducted at the phase level in software development life cycle
or at module level in program code. Software testing comprises of Validation and Verification.

Software Validation
Validation is process of examining whether or not the software satisfies the user requirements. It
is carried out at the end of the SDLC. If the software matches requirements for which it was
made, it is validated.

 Validation ensures the product under development is as per the user requirements.
 Validation answers the question – "Are we developing the product which attempts all that
user needs from this software?"
 Validation emphasizes on user requirements.

Software Verification
Verification is the process of confirming if the software is meeting the business requirements,
and is developed adhering to the proper specifications and methodologies.
 Verification ensures the product being developed is according to design specifications.
 Verification answers the question– "Are we developing this product by firmly following
all design specifications?"
 Verifications concentrate on the design and system specifications.

Target of the test are

 Errors - These are actual coding mistakes made by developers. In addition, there is a
difference in output of software and desired output, is considered as an error.
 Fault - When error exists fault occurs. A fault, also known as a bug, is a result of an
error which can cause system to fail.

82
  Failure - Failure is said to be the inability of the system to perform the desired task.
Failure occurs when fault exists in the system.

Testing Approaches:
Tests can be conducted based on two approaches –

 Functionality testing
 Implementation testing

When functionality is being tested without taking the actual implementation in concern it is
known as black-box testing. The other side is known as white-box testing where not only
functionality is tested but the way it is implemented is also analysed.
Exhaustive tests are the best-desired method for a perfect testing. Every single possible value in
the range of the input and output values is tested. It is not possible to test each and every value
in real world scenario if the range of values is large.

Black-box Testing:
It is carried out to test functionality of the program. It is also called ‘Behavioural’ testing. The
tester in this case, has a set of input values and respective desired results. On providing input, if
the output matches with the desired results, the program is tested ‘ok’, and problematic
otherwise.
In this testing method, the design and structure of the code are not known to the tester, and
testing engineers and end users conduct this test on the software.
Black-box testing techniques:
 Equivalence class - The input is divided into similar classes. If one element of a class
passes the test, it is assumed that all the class is passed.
 Boundary values - The input is divided into higher and lower end values. If these values
pass the test, it is assumed that all values in between may pass too.
 Cause-effect graphing - In both previous methods, only one input value at a time is
tested. Cause (input) – Effect (output) is a testing technique where combinations of input
values are tested in a systematic way.
 Pair-wise Testing - The behavior of software depends on multiple parameters. In
pairwise testing, the multiple parameters are tested pair-wise for their different values.
 State-based testing - The system changes state on provision of input. These systems are
tested based on their states and input.

83
White-box Testing
It is conducted to test program and its implementation, in order to improve code efficiency or
structure. It is also known as ‘Structural’ testing.
In this testing method, the design and structure of the code are known to the tester.
Programmers of the code conduct this test on the code.
The below are some White-box testing techniques:
 Control-flow testing - The purpose of the control-flow testing to set up test cases which
covers all statements and branch conditions. The branch conditions are tested for both
being true and false, so that all statements can be covered.
 Data-flow testing - This testing technique emphasis to cover all the data variables
included in the program. It tests where the variables were declared and defined and
where they were used or changed.

Testing Levels
Testing itself may be defined at various levels of SDLC. The testing process runs parallel to
software development. Before jumping on the next stage, a stage is tested, validated and
verified.
Testing separately is done just to make sure that there are no hidden bugs or issues left in the
software. Software is tested on various levels -

Unit Testing
While coding, the programmer performs some tests on that unit of program to know if it is error
free. Testing is performed under white-box testing approach. Unit testing helps developers
decide that individual units of the program are working as per requirement and are error free.

Integration Testing
Even if the units of software are working fine individually, there is a need to find out if the units
if integrated together would also work without errors. For example, argument passing and data
updation etc.

84
System Testing
The software is compiled as product and then it is tested as a whole. This can be accomplished
using one or more of the following tests:
 Functionality testing - Tests all functionalities of the software against the requirement.
 Performance testing - This test proves how efficient the software is. It tests the
effectiveness and average time taken by the software to do desired task. Performance
testing is done by means of load testing and stress testing where the software is put
under high user and data load under various environment conditions.
 Security & Portability - These tests are done when the software is meant to work on
various platforms and accessed by number of persons.

Acceptance Testing
When the software is ready to hand over to the customer it has to go through last phase of
testing where it is tested for user-interaction and response. This is important because even if the
software matches all user requirements and if user does not like the way it appears or works, it
may be rejected.
 Alpha testing - The team of developer themselves perform alpha testing by using the
system as if it is being used in work environment. They try to find out how user would
react to some action in software and how the system should respond to inputs.
 Beta testing - After the software is tested internally, it is handed over to the users to use
it under their production environment only for testing purpose. This is not as yet the
delivered product. Developers expect that users at this stage will bring minute problems,
which were skipped to attend.

Regression Testing
Whenever a software product is updated with new code, feature or functionality, it is tested
thoroughly to detect if there is any negative impact of the added code. This is known as
regression testing.

Testing Documentation
Testing documents are prepared at different stages -

Before Testing
Testing starts with test cases generation. Following documents are needed for reference –
 SRS document - Functional Requirements document
 Test Policy document - This describes how far testing should take place before
releasing the product.
 Test Strategy document - This mentions detail aspects of test team, responsibility
matrix and rights/responsibility of test manager and test engineer.

85
  Traceability Matrix document - This is SDLC document, which is related to
requirement gathering process. As new requirements come, they are added to this
matrix. These matrices help testers know the source of requirement. They can be traced
forward and backward.

While Being Tested

The following documents may be required while testing is started and is being done:
 Test Case document - This document contains list of tests required to be conducted. It
includes Unit test plan, Integration test plan, System test plan and Acceptance test plan.
 Test description - This document is a detailed description of all test cases and
procedures to execute them.
 Test case report - This document contains test case report as a result of the test.
 Test logs - This document contains test logs for every test case report.

After Testing
The following documents may be generated after testing:
 Test summary - This test summary is collective analysis of all test reports and logs. It
summarizes and concludes if the software is ready to be launched. The software is
released under version control system if it is ready to launch.

References:

[1] Roger S.Pressman, Software engineering- A practitioner’s Approach, McGraw-Hill International

Editions
[2] http://vlabs.iitkgp.ernet.in/se/10/

86
Standard Fields of Test Case

Several standard fields of a sample Test Case template are listed below.
 Test case ID: Unique ID is required for each test case. Follow some convention to
indicate the types of the test. E.g. ‘TC_UI_1’ indicating ‘user interface test case #1’.
 Test priority (Low/Medium/High): This is very useful while test execution. Test
priority for business rules and functional test cases can be medium or higher whereas
minor user interface cases can be of a low priority. Test priority should always be set by
the reviewer.
 Module Name: Mention the name of the main module or the sub-module.
 Test Designed By: Name of the Tester.
 Test Designed Date: Date when it was written.
 Test Executed By: Name of the Tester who executed this test. To be filled only after test
execution.
 Test Execution Date: Date when the test was executed.
 Test Title/Name: Test case title. E.g. verify login page with a valid username and
password.
 Test Summary/Description: Describe the test objective in brief.
 Pre-conditions: Any prerequisite that must be fulfilled before the execution of this test
case. List all the pre-conditions in order to execute this test case successfully.
 Dependencies: Mention any dependencies on the other test cases or test requirement.
 Test Steps: List all the test execution steps in detail. Write test steps in the order in which
they should be executed. Make sure to provide as many details as you can. Tip – In order
to manage a test case efficiently with a lesser number of fields use this field to describe
the test conditions, test data and user roles for running the test.
 Test Data: Use of test data as an input for this test case. You can provide different data
sets with exact values to be used as an input.
 Expected Result: What should be the system output after test execution? Describe the
expected result in detail including message/error that should be displayed on the screen.
 Post-condition: What should be the state of the system after executing this test case?
 Actual result: Actual test result should be filled after test execution. Describe the system
behaviour after test execution.
 Status (Pass/Fail): If actual result is not as per the expected result, then mark this test
as failed. Otherwise, update it as passed.
 Notes/Comments/Questions: If there are some special conditions to support the above
fields, which can’t be described above or if there are any questions related to expected or
actual results then mention them here.

87
Aim: Prepare any 3 Test Cases for the system selected in practical 2.
Project Name: Ambulance Dispatch System
Test case ID: 01 Test Designed By: Priyal
ANNAN Dalal
.F
Jay Darji
Test priority (Low/Medium/High): Medium Test Designed Date: 1./10./2020
21
Module Name: ADS Test Executed By: ANNAN
Priyal Dalal
Test Name: Login Validation Test Execution Date: 2-10-202021
Test Description: Login to the System and check the
validation.

Pre-conditions: User has correct credentials.

Dependencies: User should be already registered.

Sr. Test Step Test Data Expected Actual Status Notes

Result Result Pass/Fail
1 Navigation to abcxyz.com Successfully Successfully Pass -
Login page. loaded loaded
login login
page. page.
2 Login with Username User can’t User can’t Pass -
Wrong :admin , login login
credentials Password:
abc123
3 Login with right Username: User will avigation to Pass -
credentials Admin login and home page
Password : navigate to
password home page

Post-condition:
None

88
Project Name: Ambulance Dispatch System
Test case ID:02 Test Designed By: Priyal
ANNAN
Test priority (Low/Medium/High): Medium 21
Test Designed Date: 1/10/2020
Module Name: ADS Test Executed By: ANNAN
Priyal
Test Name: Check Ambulance Location Test Execution Date: 2/10/20 21
Test Description: User can see nearby ambulance

Pre-conditions: User Should enter his/her current location

Dependencies: None

Sr. Test Step Test Data Expected Actual Status Notes

Result Result Pass/Fail
01 Nearby User get User get Pass -
Admin enter Ambulance right right
right location No: timing timing
details 14578934 of of
Location:
ambulance ambulance.
@@@
to reach.

Post-condition:

None

89
Project Name: Ambulance Dispatch System
Test case ID:03 ANNAN
Test Designed By: Priyal
Test priority (Low/Medium/High): High Test Designed Date: 3/10/2021
3/10/2020
Module Name: ADS Test Executed By: ANNAN
Priyal
Test Name: Enter Incident Info Test Execution 21
Test Execution Date: 4/10/2020
Test Description: Functionality of the
Dispatcher screen.

Pre-conditions: User Should enter right phone number.

Dependencies: None

Sr. Test Step Test Data Expected Actual Status Notes

Result Result Pass/Fail
1 Valid Phone # Phone No: Address Address Pass -
8982782586 field is field is
populated populated
2 Invalid Phone Phone No: Throws Throws Pass -
# 8982782586 exception exception

Post-condition: None

Post Practical Questions:

1. Which of the following term describes testing?
a) Finding broken code
b) evaluating deliverable to find errors
c) A stage of all projects
d) None of the mentioned
2. What is Cyclomatic complexity?
a) Black box testing
b) White box testing
c) Yellow box testing
d) Green box testing

90
3. The testing in which code is checked
a) Black box testing
b) White box testing
c) Red box testing
d) Green box testing
4. Testing done without planning and Documentation is called
a) Unit testing
b) Regression testing
c) Adhoc testing
d) None of the mentioned
5. Acceptance testing is also known as
a) Grey box testing
b) White box testing
c) Alpha Testing
d) Beta testing
6. Which of the following is non-functional testing?
a) Black box testing
b) Performance testing
c) Unit testing
d) None of the mentioned
7. Unit testing is done by
a) Users
b) Developers
c) Customers
d) None of the mentioned

8. Behavioral testing is
a) White box testing
b) Black box testing
c) Grey box testing
d) None of the mentioned
9. Which of the following is black box testing
a) Basic path testing
b) Boundary value analysis
c) Code path analysis
d) None of the mentioned

91
 10. Which of the following is not regression test case?
a) A representative sample of tests that will exercise all software functions
b) Additional tests that focus on software functions that are likely to be affected by the
change
c) Tests that focus on the software components that have been changed
d) Low-level components are combined into clusters that perform a specific
software sub-function

Conclusion:

In this practical we have learned about different types of software testing.

92
 PRACTICAL SET– 9
STUDY ESTIMATION OF TEST COVERAGE METRICS AND STRUCTURAL
COMPLEXITY.
What is Test Coverage Metrics?

Test coverage is defined as a “Technique which determines whether the test cases are actually
covering the application code and how much code is exercised while running those test cases”.

When we can count upon some things in an application and also tell whether the test cases are
covering those things of application, then we can say that we measure the coverage. So basically
the coverage is the coverage items that we have been able to count and see what items have been
covered by the test. The test coverage by two test cases executed can be the same but the input
data of 1 test case can find a defect while the input data of 2nd cannot. So with this we
understand the 100% coverage does not mean 100% tested.

Why Test Coverage Metrics?

We perform Test coverage analysis for the following reasons.

 To find the areas in specified requirement which is not covered by the test scenarios and
cases.
 By determining the test coverage we can create more test cases to increase our test coverage.
 By performing the test coverage we can measure how much testing is covered. This
indirectly means the check on quality of the application.
 We can also identify some useless test cases which don’t have meaning in being executed
and thus omit them.
 Testing Life becomes smooth by managing the risk based testing approach.
 Traceability between the requirements and the test cases can be achieved by this technique.
 Impact analysis and change tracking can be determined if we have proper test coverage.

Test coverage (also referred to by some as code coverage) is one of many metrics that are
commonly used to give a statistical representation of the state of the code written for a certain
piece of software. Other typical metrics include: Cyclomatic Complexity.

How to Find Cyclomatic Complexity?

 Identify basic blocks in a program module, and draw it's control flow graph (CFG)
 Identify the linearly independent paths from a CFG
 Determine Cyclomatic complexity of a module in a program

93
Control Flow Graph

A control flow graph (CFG) is a directed graph where the nodes represent different instructions
of a program, and the edges define the sequence of execution of such instructions. Figure shows
a small snippet of code (compute the square of an integer) along with it's CFG. For simplicity,
each node in the CFG has been labelled with the line numbers of the program containing the
instructions. A directed edge from node #1 to node #2 in figure 1 implies that after execution of
the first statement, the control of execution is transferred to the second instruction.

A program, however, doesn't always consist of only sequential statements. There could be
branching and looping involved in it as well. Following figure shows how a CFG would look
like if there are sequential, selection and iteration kind of statements in order.

94
A real life application seldom could be written in a few lines. In fact, it might consist of thousand
of lines. A CFG for such a program is likely to become very large, and it would contain mostly
straight-line connections. To simplify such a graph different sequential statements could be
grouped together to form a basic block. A basic block is a maximal sequence of program
instructions I1, I2, ..., In such that for any two adjacent instructions Ik and Ik+1, the following holds
true:

 Ik is executed immediately before Ik+1

 Ik+1 is executed immediately after Ik

The size of a CFG could be reduced by representing each basic block with a node. To illustrate
this, let's consider the following example.

sum = 0;
i = 1;
while (i ≤ n) {
sum += i;
++i;
}
printf("%d", sum);
if (sum > 0) {
printf("Positive");
The CFG with basic blocks is shown for the code
}

Terminologies:
Path
A path in a CFG is a sequence of nodes and edges that starts from the initial node (or entry
block) and ends at the terminal node. The CFG of a program could have more than one terminal
nodes.
Linearly Independent Path:
A linearly independent path is any path in the CFG of a program such that it includes at least one
new edge not present in any other linearly independent path. A set of linearly independent paths
give a clear picture of all possible paths that a program can take during it's execution. Therefore,
path-coverage testing of a program would suffice by considering only the linearly independent
paths.

95
In figure of flow graph we can find four linearly independent paths:

1 - 3 - 6 - (7, 8) - 10
1 - 3 - 6 - (7, 8) - 9 - 10
1 - 3 - (4, 5) - 6 - (7, 8) - 10
1 - 3 - (4, 5) - 6 - (7, 8) - 9 – 10

Note that 1 - 3 - (4, 5) - 3 - (4, 5) - 6 - (7, 8) - 10, for instance, won't qualify as a linearly
independent path because there is no new edge not already present in any of the above four
linearly independent paths.

McCabe's Cyclomatic Complexity

McCabe had applied graph-theoretic analysis to determine the complexity of a program module.
Cyclomatic complexity metric, as proposed by McCabe, provides an upper bound for the number
of linearly independent paths that could exist through a given program module. Complexity of a
module increases as the number of such paths in the module increase. Thus, if Cyclomatic
complexity of any program module is 7, there could be up to seven linearly independent paths in
the module. For a complete testing, each of those possible paths should be tested.

Computing Cyclomatic Complexity

Let G be a a given CFG. Let E denote the number of edges, and N denote the number of nodes.
Let V(G) denote the Cyclomatic complexity for the CFG. V(G) can be obtained in either of the
following three ways:

 Method #1:V(G) = E - N + 2
 Method #2: V(G) could be directly computed by a visual inspection of the CFG:V(G) =
Total number of bounded areas + 1It may be noted here that structured programming
would always lead to a planar CFG.
 Method #3: If LN be the total number of loops and decision statements in a program,
then V(G) = LN + 1
In case of object-oriented programming, the above equations apply to methods of a class. Also,
the value of V(G) so obtained is incremented by 1 considering the entry point of the method. A
quick summary of how different types of statements affect V(G) could be found in. Once the
complexities of individual modules of a program are known, complexity of the program (or
class) could be determined by:V(G) = SUM( V(Gi) ) - COUNT( V(Gi) ) + 1where COUNT( V(Gi)
) gives the total number of procedures (methods) in the program (class).

96
References:
[1] Roger S.Pressman, Software engineering- A practitioner’s Approach, McGraw-Hill
International Editions
[2] http://vlabs.iitkgp.ernet.in/se/9/

97
Aim: Prepare CFG and calculate Cyclomatic Complexity for the following code.
{
A = 10
IF B > C THEN
A=B
ELSE
A=C
ENDIF
}
Print A
Print B
Print C

Control Flow Graph of above code

98
The cyclomatic complexity calculated for above code will be from control flow graph.
The graph shows seven shapes(nodes), seven lines(edges), hence cyclomatic
complexity is 7-7+2 = 2.

99
Post Practical Questions:
1. Architectural Design Metrics are ___________ in nature.
a) Black Box
b) White Box
c) Gray Box
d) Green Box
2. ______ is a white-box testing technique first proposed by Tom McCabe.
a) Equivalence Partitioning
b) Basis path testing
c) Boundary Value Analysis
d) None of the above.
3. Which of the following is software metric that provides a quantitative measure of the
logical complexity of a program?
a) Cyclomatic Complexity
b) LOC
c) Function Point
d) None of the above.
4. Cyclomatic complexity is computed as
a) The number of regions of the flow graph corresponds to the cyclomatic complexity.
b) Cyclomatic complexity, V(G), for a flow graph, G, is defined as V(G) = E _ N + 2
where E is the number of flow graph edges, N is the number of flow graph nodes.
c) Cyclomatic complexity, V(G), for a flow graph, G, is also defined as V(G) = P + 1
where P is the number of predicate nodes contained in the flow graph G.
d) All of the above.
5. In a flow graph, node that contains a condition and is characterized by two or more edges
emanating from it, is called as
a) Parent node
b) Two Edge node
c) Predicate node
d) None of the above.
6. Which of the following comes under the Control structure testing?
a) Condition testing
b) Loop testing
c) Data Flow Testing
d) All of the above.

100
 7. What types of errors are not done by black-box testing and can be uncovered by white-
box testing?
a) Logic errors
b) Performance errors
c) Behavioral errors
d) None of the above.
8. Equivalence Partitioning comes under which type of testing?
a) White Box testing
b) Black Box testing
c) Grey Box testing
d) None of the above.
9. A set of paths are said to be linearly independent if
a) Each of them is distinct
b) No paths have a common node
c) No two paths have a common node
d) All the paths are pair wise distinct
10. According to McCabe's Cyclomatic complexity, V(G) = E - N + 2. Here, N is
a) No. of statements in the program
b) No. of unique operators used
c) No. of nodes in the CFG
d) No. of edges in the CFG

Conclusion:

In this practical , we learnt about Cyclomatic complexity of graph.

101
 PRACTICAL SET – 10
CASE STUDY ON SOFTWARE TESTING TOOLS.

Now days we can get lots of Software Testing Tools in the market. Selection of tools is totally
based on the project requirements & commercial (Proprietary/Commercial tools) or free tools
(Open Source Tools) you are interested. Off Course, free Testing Tools may have some
limitation in the features list of the product, so it’s totally based on what are you looking for & is
that your requirement fulfil in free version or go for paid Software Testing Tools.
This is where tools become helpful. Besides tools improve reliability, reduce turnaround time
and increase ROI.

They are various types of tools that assist in diverse testing activities ranging from requirements
capturing to test management.

But just a plain mention of tools and their corresponding characteristics would be boring. So we
have designed an interactive test to help you learn key features of the various testing tools.

The tools are listed below:

 Quality Center:
Type of Tool: TEST MANAGEMENT TOOL

Key Features &Functionalities:

 Management of Tests
 Scheduling of Tests
 Management of Testing Activities
 Interfaces to other testing tools
 Traceability

 QTP:
Type of Tool: TEST EXECUTION TOOLS
Key Features & Functionalities:

 Storing an expected result in the form of a screen or GUI object and comparing it with
run-time screen or object
 Executing tests from a stored scripts, Logging test results
 Sending test summary to test management tools
102
 Access of data files for use as test data
 Load Runner:
Type of Tool: PERFORMANCE MEASUREMENT TOOLS
Key Features & Functionalities:

 Ability to simulate high user load on the application under test

 Ability to create diverse load conditions
 Support for majority of protocols
 Powerful analytical tools to interpret the performance logs generated

 Case:
Type of Tool: REQUIREMENTS MANAGEMENT TOOLS
Key Features & Functionalities:

 Storing Requirements
 Identifying undefined, missing or to be defined requirements
 Traceability of Requirements
 Interfacing with Test Management Tools
 Requirements Coverage

 Source Anywhere:
Type of Tool: CONFIGURATION MANAGEMENT TOOL
Key Features & Functionalities:

 Information About Versions and builds of Software and Test Ware

 Build and release management
 Access control (check in and check out)

 In View:
Type of Tool: REVIEW TOOL
Key Features & Functionalities:

 Sorting and Storing Review Comments

 Communicating Comments to relevant people
103
  keeping track of review comments, including defects
 Traceability between review comments & review documents
 Monitoring Review Status (Pass, pass with corrections, requires more changes)

 PMD:
Type of Tool: STATIC ANALYSIS TOOLS
Key Features & Functionalities:

 Calculate Cyclomatic Complexity

 Enforce Coding Standards
 Analyze Structure and Dependencies
 Help in understanding Code
 Identify defects in code

 Clone & Test:

Type of Tool: Test Data Preparation Tools
Key Features & Functionalities:

 Extract Selected data records from files or databases

 Data Anonymization
 Create new records populates with random data
 Create large number of similar records from a template

 Code Cover:
Type of Tool: Coverage Measurement Tool
Key Features & Functionalities:

 Identifying Coverage Items

 Reporting coverage items which are not covered yet
 Identifying test inputs to exercise
 Generating stubs and drivers

References:

[1] https://www.softwaretestingclass.com/software-testing-tools-list/
[2] https://www.softwaretestinghelp.com/5-best-automation-tools-for-
testing-android- applications/
104
Aim: Prepare Case Study on any one topic given below.
1. SCM Tools
2. SQA Tools
3. Software Project Management Tool

SCM Tools
The minimum features for SCM tools are closely related to the task of handling the different product
deliverables produced within the project software engineering process. Tool requirements and selection criteria
are based on a series of features that provide a consistent look and feel with state-of-the-art software
development environments. An SCM tool must have multiuser support, an intuitive graphical user interface,
conformity to the organization's development environment, scalability, flexibility in integrating other software
development tools, ease of setup, modifiable models, process management, extensive support for the
development phase, and management of nondevelopment objects.

105
Post Practical Questions:
1. Which of the following term describes testing?
a) Finding broken code
b) Evaluating deliverable to find errors
c) A stage of all projects
d) None of the mentioned
2. What is Cyclomatic complexity?
a) Black box testing
b) White box testing
c) Yellow box testing
d) Green box testing

3. The testing in which code is checked

a) Black box testing
b) White box testing
c) Red box testing
d) Green box testing

4. Testing done without planning and Documentation is called

a) Unit testing
b) Regression testing
c) Adhoc testing
d) None of the mentioned
5. Acceptance testing is also known as
a) Grey box testing
b) White box testing
c) Alpha Testing
d) Beta testing

6. Which of the following is non-functional testing?

a) Black box testing
b) Performance testing
c) Unit testing
d) None of the mentioned

7. Unit testing is done by

a) Users
b) Developers
c) Customers
d) None of the mentioned

106
 8. Behavioural testing is
a) White box testing
b) Black box testing
c) Grey box testing
d) None of the mentioned
9. Which of the following is black box testing
a) Basic path testing
b) Boundary value analysis
c) Code path analysis
d) None of the mentioned
10. Which of the following is not regression test case?
a) A representative sample of tests that will exercise all software functions
b) Additional tests that focus on software functions that are likely to be affected
by the change
c) Tests that focus on the software components that have been changed
d) Low-level components are combined into clusters that perform a specific
software sub- function

Conclusion:

In this practical, we learnt about types of testing in software.

107