Ipl Case Styudy

DLF INDIAN PREMIER LEAGUE
DLF IPL
for
Department of Computer
Applications, CUSAT
A
Project Report
Submitted for partial
fulfillment of the degree of
Master of Computer Applications
By
DEEPAK KUMAR SINGH
DEPARTMENT OF COMPUTER APPLICATIONS

COCHIN UNIVERSITY OF SCIENCE AND TECHNOLOGY
Kochi- 682022 ,Kerala.
1 Deepak Kumar Singh , Department of Computer Applications, CUSAT

CERTIFICATE
This is to certify that the project entitled

------------------------------------------------------ submitted to Cochin
University of Science and Technology in partial fulfillment of the
requirements for the award of the degree of Master of Computer
Applications is the bona fide record of the project work
done by ------------------------------ under our supervision and
guidance during ------------------- to -----------------.
Signature of Internal Guide Signature of External
Guide Name and Designation
Name and Designation
Head of Department
Official Address
Internal Examiner External Examiner

ACKNOWLEDGEMENT
The satisfaction and euphoria that accompany the

successful completion of any task would be incomplete
without mentioning the names of people who made it possible, whose
constant guidance and encouragement crowns
all efforts with our success.
I extend my gratitude to Dr. K.V. Pramod,

Head- Department of Computer Applications, Cochin University
of Science and Technology, Kochi, Kerala for providing
me with excellent infrastructure and awesome environment
that laid potentially strong foundation for my professional life.
I would like to express my profound thanks to

Mr. A. SreeKumar, who guided me through out the project
tenure, provided me each and every details, references, and technical helps
without which it was impossible to complete
this project. I am also thankful to Professor Dr. B. Kannan, and
Mrs. S. Malathi and Mr. Arun Sir for their help and guidance
throughout my project future.
Finally. I also wish to thank all guest faculties and non-teaching

staffs for supporting me during my whole project work.
Deepak Kumar Singh

SYNOPSIS
Title : DLF IPL
Name of Student : Deepak Kumar Singh
Venue of the Project : DCA, CUSAT
Duration : 3 months
Platform : Windows XP/Vista
Application Software
Front End : JSP
Back End : MYSQL

CONTENTS
Page No.
1. Introduction
2. System Study
2.1 Existing System
2.2 Drawbacks in the Existing System
3. System Analysis
3.1 Proposed System
3.2 Scope
3.3 Need for the Proposed System
3.4 Feasibility Study
3.4.1 Technical Feasibility
3.4.2 Financial Feasibility
3.4.3 Operational Feasibility
4. Requirement Analysis
4.1 User Class and Characteristics
4.2 Functional Requirements
4.3 Performance Requirements
4.4 Non Functional Requirements
4.5 External Interfaces Requirements
4.6 General Constraints, Assumptions, Dependencies, Guidelines

5. System Design Specification

5.1 Architectural Design
5.1.1 Data Flow Diagrams
5.1.2 Database Tables
5.1.3 User Case Diagrams
6. Testing
7. Software Quality Assurance Plan
8. Output Screen
Output of Pages
9. Conclusion
10. Scope for further development
11. Bibliography
11. Appendices
1. INTRODUCTION
DLF Indian Premier League (IPL) is a T20 cricket

league that was created and promoted by the
BCCI, with the complete backing of the ICC.
Launched as well as promoted by the Board of
Control for Cricket in India (BCCI), Indian Premier
League (IPL) made its debut in April 2008.
This web portal is designed for creating a
gateway to explore the world of INDIAN premier
league T-20 tournament .
This web portal will provide sufficient and
important informations about the whole IPL T-20
tournament.
This web portal is designed especially to create a
platform for all viewers of T-20 tournament.
So by using this web portal user can get all the

important knowledge about the IPL T-20
tournament.

2.SYSTEM STUDY
Especially users those have keen interest in cricket will be in the
center of this project. This system can be used and enjoyed by the
variety of users. Since it provides all the information and statistics that
a user would like to see in his/her website.
2.1 Existing System:

There are lots of existing systems are available on the web
with similar objectives and contents but after going through these all
following are the drawbacks I find:
1. They does not have good Interface i.e. a lots of color is used
which is not friendly at all.
2. Latest news and information are not up to date.
3. Navigation Facility is quite complex because sometimes it

navigates us to the other websites.
4. Registration requires for Navigation.

2. SYSTEM ANALYSIS
3.1 Purpose:
As we know that cricket is too much popular in our country and there are lack
of certain good web portals which can give them so much knowledge about
these type of tournaments.
So by using this web portal user can get all the important knowledge about
the IPL T-20 tournament .
Proposed web portal is designed for giving information about the Indian
premium league
T-20 Tournament, it will provide the information about teams playing in

Indian premium league.
This webportal will provide information about stastistics & records of

players(batsman & bowling) of all teams playing in Indian premium league.
3.2 Scope:
1. It provides information as per the requirements of the user .

2. Nave user and Administrator have well defined boundary and
criteria. They have their predefined section and modules such that a
user can not enter into the administrator section.
3. This system works well within the boundary and boundary for this
system is Only cricket, nothing else you will find in this project apart
from cricket.

3.3 Need for the proposed system:

As we know that cricket is too much popular in our country and there are lack
of certain good web portals which can give them so much knowledge about
these type of tournaments.
So by using this web portal user can get all the important knowledge about
the IPL T-20 tournament .
Proposed web portal is designed for giving information about the Indian
premium league
T-20 Tournament, it will provide the information about teams playing in

Indian premium league.
This webportal will provide information about stastistics & records of

players(batsman & bowling) of all teams playing in Indian premium league.
3.4 Feasibility study:
Many feasibility studies are disillusioning for both users and analysts. First,
the study often presupposes that when the feasibility document is being prepared,
the analyst is in a position to evaluate solutions. Second, most studies tend to
overlook the confusion inherent in system development- the constraints and the
assumed attitudes. If the feasibility study is to serve as a decision document, it
must answer three key questions :
1. Is there a new and better way to do the job that will benefit the user ?
2. What are the costs and savings of the alternative(s)?
3. What is recommended?

The most successful system projects are not necessarily the biggest or most
visible in a business but rather those that truly meet user expectations. More
projects fail because of inflated expectations than for any other reason.
2.1 Feasibility considerations:
Three key considerations are involved in the Feasibility analysis: economic,

technical, behavioral. Let's Briefly review each consideration and how it relates to
the System efforts. Depending on the results of the initial investigations, The
survey is expanded to a more detailed feasibility study. A feasibility study is a test
of a system proposal According to its workability, impact on the organization,
Ability to meet user needs, and effective use of resources. If focuses on three
major questions:
1. What are the user's demonstrable needs and how does a candidate system meet
them?
2. What resources are available for given candidate systems? Is the problem worth
solving?
3. What are the likely impacts of the candidate system on the organization? How
well does it fit within the organization's master MIS plan?
Each of these questions must be answered carefully. They revolve around
investigation and evaluation of the problem, identification and description of
candidate systems, specification of performance and the cost of each system, and
final selection of the best system. The objective of a feasibility study is not to solve
the problem but to acquire a sense of its scope. During the study, the problem
definition is crystallized and aspects of the problem to be included in the system
are determined. Consequently, costs and benefits are estimated with greater
accuracy at this stage. The result of the feasibility study is a formal proposal. This
is simply a report-a formal document detailing the nature and scope of the
proposed solution. The proposal summarizes what is known and what is going to
be done.

It consists of the following:

1. Statement of the problem - a carefully worded statement of the problem that led
to analysis.
2. Summary of findings and recommendations a list of the major findings and
recommendations of the study. It is ideal for the user who requires quick access to
the results of the analysis of the system under study. Conclusions are stated,
followed by a list of the recommendations and a justification for them.
3. Details of findings - an outline of the methods and procedures under taken by
the existing system, followed by coverage of the objectives and procedures of the
candidate system. Included are also discussions of output reports, file structures,
and costs and benefits of the candidate system.
4. Recommendations and conclusions - specific recommendations regarding the
candidate system, including personnel assignments, costs, project schedules and
target dates.
2.2 Steps in feasibility analysis:

Eight steps are involved in the feasibility analysis. They are :
1.Form a project team and appoint a project leader.
1. Prepare system ER-Diagram,DFD

2. Enumerate potential proposed systems.
3. Define and identify characteristics of proposed system.
4. Determine and evaluate performance and cost effectiveness of each
proposed system.
5. Weight system performance and cost data.
6. Select the best proposed system.
7. Prepare and report final project directive to management

2.3 Type of feasibilities:-

1. Economic Feasibility
Economic analysis is the most frequently used technique for evaluating the
effectiveness of a proposed system. More commonly known as cost benefit
analysis; in this procedure we determine the benefits and savings that are expected
from a proposed system and compare them with costs. We found the benefits
outweigh the costs; we take a decision to design and implement the new proposed
system.
2. Technical Feasibility
This is concerned with specifying equipment and software that will successfully
satisfy the user requirement. The technical needs of the system may vary
considerably, but might include:
The facility to produce outputs in a given time.
Response time under certain conditions.
Ability to process a certain volume of transaction at a particular speed.
Facility to communicate data to distant location.
After examining technical feasibility, we give more importance to the

configuration of the system than the actual make of hardware. The configuration
gives the complete picture about the system's requirements: Ten to twelve
workstations are required, these units should be interconnected through LAN so
that they could operate and communicate smoothly.
3. Operational Feasibility
It is mainly related to human organizational and political aspects. The points to be
considered are:
what changes will be brought with the system?
what organizational structures are disturbed?

what new skills will be required? Do the existing staff members have these skills?
If not, can they be trained in due course of time?
Generally project will not be rejected simply because of operational infeasibility

but such considerations are likely to critically affect the nature and scope of the
eventual recommendations.
For operational feasibility study we appointed a small group of people who are
familiar with information system techniques, who understand the parts of the
business that are relevant to the project and are skilled in system analysis and
design process.
4. Social feasibility
Social feasibility is a determination of whether a proposed project will be

acceptable to the people or not. This determination typically examines the
probability of the project being accepted by the group directly affected by the
proposed system change.
5. Management feasibility
It is a determination of whether a proposed project will be acceptable to
management. If management does not accept a project or gives a negligible support
to it, the analyst will tend to view the project as a non-feasible one.
6.Legal feasibility
Legal feasibility is a determination of whether a proposed project infringes on

known Acts, Statutes, as well as any pending legislation. Although in some
instances the project might appear sound, on closer investigation it may be found
to infringe on several legal areas.

4. SYSTEM REQUIREMENTS SPECIFICATIONS

System requirements are expressed in a software
requirement document. The Software requirement specification (SRS)
is the official statement of what is required of the system developers.
This requirement document includes the requirements definition and
the requirement specification. The software requirement document is
not a design document. It should set out what the system should do
without specifying how it should be done. The requirement set out in
this document is complete and consistent.
The software specification document satisfies the following:-
1 It specifies the external system behaviors.

2 It specifies constraints on the implementation.
3 It is easy to change.
4 It serves as reference tool for system maintainers.
5 It record forethought about the life cycle of the system.
6 It characterizes acceptable response to undesired events.

4.1 User Class and Characteristics:
There are 2 types of user of this software-
A. General Public.
B. Administrator.
1. General public can book online tickets for various

matches,see match schedules & view previous match
results.
2. GP can also view image galleries of each team.
3. Administrators update match schedule at regular

intervals, update ticket availability status & account
information .

4.2 Functional Requirements:
The System must provide following functionalities
i GP can see ticket availability for different matches.
ii. Registered GP can book a ticket for a match in IPL.
iv. Any GP can view match schedules and updates.
v. Administrators can update seat availability ,update match schedule

at regular intervals, update ticket availability status & account information .
.
4.3 Performance Requirements:
In order to maintain an acceptable speed at maximum

number of uploads allowed from a particular user will be any
number of users can access the system at any time. Also
connections to the servers will be based on the criteria of attributes
of the user like his location, and server will be working whole 24X 7
times.

4.4 Non Functional Requirements:
Following Non-functional requirements will be there in the

Insurance on internet:
i). Secure access of confidential data (users details).

ii). 24 X 7 availability.
iii). Better component design to get better performance at

peak time.
iv). Flexible service based architecture will be highly

desirable for future extension Non functional
requirements define system properties and constraints
It arise through user needs, because of budget
constraints or organizational policies, or due to the
external factors such as safety regulations, privacy
registration and so on.
Various other Non-functional requirements are:
1. Security
2. Reliability
3. Maintainability
4. Portability
5. Extensibility
6. Reusability
7. Application Affinity/Compatibility
8. Resource Utilization

4.5 External Interface Requirements:
4.5.1 User Interface:

User of the system will be provided with the Graphical user
interface, there is no command line interface for any functions of the
product. The user will get page
1. Login page followed by Password
SOFTWARE REQUIREMENTS:-
OPERATING SYSTEM:- MS WINDOWS 2000, Window-XP..
FRONTEND PLATFORM :- HTML, Java-Script, CSS.
WEB BROWSER:- Internet explorer , Google chrome.
HARDWARE REQUIREMENTS:-
MICROPROCESSOR :- Pentium IV (1.4 GHZ)
RAM :- 256 MB
MOTHERBOARD :- INTEL 810E
HARD DISK :- 40 GB HDD Ultra Wide SCSI DISK
POINTING DEVICE :- 3 Button mouse with wheel

MONITOR :- 15 inch color monitor
(VGA/SVGA/UVGA)

STANDARD INPUT DEVICE :- Multimedia keyoard

CD-ROM/DVD DRIVE :- Samsung/LG 52X MAX S
4.5.4 Communication Interfaces
The two parties should be connected through either by

LAN or WAN for the communication.
Communication channels Receiver

Sender
4.6 General Constraints, Assumptions,

Dependencies, Guidelines:
4.6.1 General Constraints
1 The interface will be in English only.

2 The system is working for single server.
3 There is no maintainability or backup so availability will get
affected.
4 The system is a single user system.
5 GUI features available.
4.6.2 Assumptions and Dependencies
The product does require back-end database server

MySQL for storing the username and password for different
types of user of the system as well as various databases
regarding various insurance information.
Assumptions:
1 User must be trained for basic computer functionalities.
2 User must have the basic knowledge of English
3 The system must be able to respond to database software
within reasonable time.
Front-end (user interaction):
The product will require a computer with an application program

or with any other application program and an communication
channel.
The speed of the communication channel (if any) must be, at a

minimum 28.8 kbps in order to support message transfer in
reasonable time.

5 . SYSTEM DESIGN SPECIFICATION
5.1 ARCHITECTURAL DESIGN
5.1.1 DATA FLOW DIAGRAMS:
Data flow diagrams (DFD) was first developed by LARRY

CONSTANTINE as way representing system requirements in a
graphical form; this lead to modular design. A DFD describes what
data flow (logical) rather than how they are processed, so it does
not depend on hardware, software, data structure or file
organization. It is also known as bubble chart.
A Data Flow Diagrams is a structured analysis and design tool that

can be used for flowcharting in place of, or in association with,
information-oriented and process-oriented systems flowcharts. A
DFD is a network that describes the flow of data and the processes
that change, or transform, data throughout a system. This network
is constructed by using a set of symbols that do not imply a
physical implementation. It has the purpose of clarifying system
requirements and identifying major transformations that will
become programs in system design. So it is the starting point of
the design phase that functionality decomposes the requirement
specifications down to the lowest level of detail.

The symbols used to prepare DFD do not imply a physical

implementation, a DFD can be considered to an abstract of the
logic of an information-oriented or a process-oriented system
flow-chart. For these reasons DFDs are often referred to as logical
data flow diagrams. The four basic symbols used to construct data
flow diagrams are shown below:
A rectangle represents a data source or

destination.
A directed line represents the flow of data that

is data stream.
An enclosed figure, usually a circle or an oval

bubble, represent a process that transforms
data streams.
An open-ended rectangle represents data

storage.

These are symbols that represent data flows, data sources, data
transformations and data storage. The points at which data are
transformed are represented by enclosed figures, usually circles,
which are called nodes. The principle processes that take place at
nodes are:
1. combining data streams
2. splitting data streams
3. modifying data streams.
REQUEST
GEN PUB.
REQUEST
DATA
BASE
ADM.
SERVER



5.1. 2. DATABASE DESIGN:
A database design is a collection of stored data organized in such a

way that the data requirements are satisfied by the database. The general
objective is to make information access easy, quick, inexpensive and flexible
for the user. There are also some specific objectives like controlled
redundancy from failure, privacy, security and performance.
A collection of relative records make up a table. To design and store

data to the needed forms database tables are prepared. Two essential
settings for a database are:
Primary key: - The field that is unique for all

the record occurrences.
Foreign key: - The field used to set relation

between tables. Normalization is a technique to avoid
redundancy in the tables.

Data base TABLE DESIGN:
Table Name: Login--
This table stores the login details of a Adminstrator .
Field Type Null Key Default Extra
User_id varchar(35) NO PRI
password varchar(15) NO NULL
Table Name:person --
This table stores the details of a person which are Booked ticket for IPL.
Person_id varchar(35) NO PRI
Card_id varchar(40) NO NULL
Fname varchar(100) NO NULL
Lname varchar(100) NO NULL
Sex varchar(20) NO NULL
Dob Date NO NULL
Email_id varchar(100) NO NULL

Phone_no varchar(100) NO NULL
Table Name: Match
This table stores the details of the match.
Match_id varchar(30) NO Pri
Team_1 varchar(30) No NULL
Team_2 varchar(125) NO NULL
Current_sheat int(10) NO NULL
Date date NO NULL
City varchar(14) NO NULL
R_sheat int(10) NO NULL
Table Name: Reservation
This table stores the details of the Reservation.
Match_id varchar(30) NO Pri

Person_id varchar(30) No Pri
Amt Int(10) NO NULL
Table Name: Match result--
This table stores the result details of a match .
Match_id varchar(35) NO PRI
status varchar(100) NO NULL

5.1.3 USER CASE DIAGRAM:
User case diagrams are used to model the functional

interaction between users and system.
Login Validat
e
User1 Request to the system
Perform
next task
Informatio
n
Logout

User2
(User Case Diagram)
6. TESTING
Software Testing is an empirical investigation conducted
to provide stakeholders with information about the quality of the
product or service under test, with respect to the context in which
it is intended to operate. Software Testing also provides an
objective, independent view of the software to allow the business
to appreciate and understand the risks at implementation of the
software. Test techniques include, but are not limited to, the process
of executing a program or application with the intent of finding
software bugs. It can also be stated as the process of validating
and verifying that a software program/application/product meets
the business and technical requirements that guided its design
and development, so that it works as expected and can be implemented
with the same characteristics.
Software Testing, depending on the testing method employed,

can be implemented at any time in the development process, however
the most test effort is employed after the requirements have been defined
and coding process has been completed.

6.1 Unit Testing:
The primary goal of unit testing is to take the

smallest piece of testable software in the application, isolate
it from the remainder of the code, and determine whether it
behaves exactly as you expect. Each unit is tested separately before
integrating them into modules to test the interfaces between modules. Unit
testing has proven its value in that a large percentage of defects
are identified during its use.
Unit testing is a software verification and validation

method where the programmer gains confidence that individual
units of source code are fit for use. A unit is the smallest testable part of an
application. In procedural programming a unit may be an individual
program, function, procedure, etc., while in object-oriented programming,
the smallest unit is a class, which may belong to a base/super class,
abstract class or derived/child class.
Ideally, each test case is independent from the others:

substitutes like method stubs, mock objects, fakes and test harnesses can
be used to assist testing a module in isolation. Unit tests are typically

written and run by software developers to ensure that code meets its
design and behaves as intended. Its implementation can vary from being
very manual (pencil and paper) to being formalized as part of build
automation.
6.2 Integration Testing
Integration testing, also known as integration and testing

(I&T), is a software development process which program units are
combined and tested as groups in multiple ways. In this context, a unit is
defined as the smallest testable part of an application. Integration
testing can expose problems with the interfaces among program
components before trouble occurs in real-world program execution.
Integration testing is a component of Extreme Programming (XP), a
pragmatic method of software development that takes a meticulous
approach to building a product by means of continual testing and revision.
There are two major ways of carrying out an

integration test, called the bottom-up method and the top-down
method. Bottom-up integration testing begins with unit testing,
followed by tests of progressively higher-level combinations of
units called modules or builds. In top-down integration testing,
the highest-level modules are tested first and progressively
lower-level modules are tested after that. In a comprehensive

software development environment, bottom-up testing is usually

done first, followed by top-down testing.
6.3 Validation testing
At the validation level, testing focuses

on user visible actions and user recognizable output from the
system. Validations testing is said to be successful when software functions
in a manner that can be reasonably expected by the customer.
Two types of validation testing:
Alpha testing is simulated or actual operational

testing by potential users/customers or an
independent test team at the developers' site.
Alpha testing is often employed for off-the-shelf
software as a form of internal acceptance testing,
before the software goes to beta testing.
Beta testing comes after alpha testing.

Versions of the software, known as beta version,
are released to a limited audience outside of the
programming team. The software is released to
groups of people so that further testing can

ensure the product has few faults or bugs.

Sometimes, beta versions are made available to the
open public to increase the feedback field to a
maximal number of future users.
Software Quality Assurance Plan

Each development and maintenance project should have a Software
Quality Assurance Plan that specifies its goals, the SQA tasks to be performed, the
standards against which the development work is to be measured, and the
procedures and organizational structure.
The IEEE Standards for the Software Quality Assurance Plans states that the plan
should contain the following sections:
1. Purpose
2. Reference documents
3. Management
4. Documentation
5. Standards, practices and conventions
6. Reviews and Audits
7. Configuration Management
8. Problem reporting and corrective action
9. Tools, techniques and methodologies
10.Code Control
11.Media Control
12.Supplier Control
13.Records collection, maintenance and retention.
1. Purpose, Scope and Overview:
The purpose of this Software Quality Assurance (SQA)

Plan is to establish the goals, processes, and responsibilities required to implement
effective quality assurance functions for the DLF IPL project.
The DLF IPL Software Quality Assurance plan provides the

framework necessary to ensure a consistent approach to software quality assurance
throughout the project life cycle.
This plan establishes the SQA activities performed

throughout the life cycle of the DLF IPL. Specifically, this SQA Plan will show
that the SQA function is in place for this project. It will show that the SQA group
has a reporting channel to senior management that is independent of the project
manager, the projects software engineering group, and software related groups
that include Software Configuration Management (SCM), System and Software
Test, and Logistics.
The goal of the SQA program is to verify that all software and documentation to be
delivered meet all technical requirements.
2. Reference documents:

a. Software Quality Assurance, Principles and Practice: Nina S

Godbole.
3. Management:
An IEEE standard lays down three aspects that should be covered in the
Software Quality Assurance Plan:
a) Organization: The organization section includes the roles of

the team members, their hierarchy etc. It is important that the
head of the Software Quality Assurance (SQA) function in the
organization has the adequate authority to be able to perform
independent verification that the processes are adhered to.

Figure below shows the SQA organization with relation to the project
organization:
Program
Management/
Line Management
(Sponsor)
IV &V SEPO
SQA
Project
Management
SCM
Systems Software Software System Logistics

Engineering Development Test Test
(Figure: DLF IPL Organization)
The following describes the functional groups that influence and control
software quality.
a). Program Management/Line Management (Sponsor) is responsible for the

following items:
1. Identifying an individual or group independent from the project

to audit and report on the projects SQA function.
2. Identifying the quality factors to be implemented in the system
and software.

b). Project Management is responsible for:

1. Resolving and following-up on any quality issues raised by
SQA.
2. Identifying, developing and maintaining planning documents such
as the Program Management Plan.
c). System Engineering is responsible for:
Implementing the engineering practices, processes, and procedures as
defined in program/project planning documents.
d). Software Design/Development is responsible for::
Identifying, implementing, and evaluating the quality factors to be
implemented in the software.
e). Software Test is responsible for:
Verifying, Implementing the software test practices, processes, and
procedures as defined in program/project planning documents.
f). System Test is responsible for:

Verifying the quality factors are implemented in the system (software
and hardware).
g). Logistics is responsible for:
1. Reviewing and commenting on the SQA Plan.
2. Implementing the quality program in accord DLF IPL
assurance with this SQA Plan.
h). Software Configuration Management (SCM) is responsible for:

Implementing the SCM practices, processes, and procedures as

defined in reference and other program/project planning documents.
i). Independent Verification and Validation (IV& V) is responsible for:
Implementing the practices, processes, and procedures as defined for
IV&V in program/project planning documents.
j). Systems Engineering Process Office (SEPO) is responsible for:
1. Maintaining the SQA Process.
2. Ensuring SQA training availability.
3. Providing assistance in software process engineering and
software process improvement.
b) Tasks: An SQA task is performed in relationship to what

software development activities are taking place. One or more
SQA tasks can be performed concurrently until a task is
completed.
The following are the tasks of SQA plan:

Evaluate System Requirements Analysis Process
Evaluate System Design Process
Evaluate Software Requirements Analysis Process
Evaluate Software Design Process
Evaluate Software Tools
Evaluate Software Implementation and Unit Testing Process

Evaluate End-item delivery Process
Evaluate Configuration Management Process
c) Responsiblities: The project manager and

design/development teams have primary responsibility for the
quality controls applied during the development of the software
project.
The quality manager will:
Define the responsibilities of quality personnel in the form of quality

assurance procedures applicable to the project.
Agree to the quality plan with the project manager.
Approve the plan of the audits for the project which are to be carried out by
quality personnel.
Resolve any disagreement between the project manager and quality
personnel on matters relating to quality.

Review the activities performed by project personnel to ensure that the

requirements of the quality plan and quality procedures are being satisfied.
Quality personnel will:
Carry out planned internal audits of the project to assess compliance with
quality objectives.
Agree on corrective action with the project manager for any discrepancies,
non-conformities found and ensure that corrective action is taken.
Evaluate defect trends and take appropriate action.
4. Documentation:
The basic purpose of the documentation section of the Software Quality Assurance
Plan is to describe the documentation to be produced and how it is to be reviewed.
The documentation section normally includes the following:
Software Requirements Specification (SRS)

Software Design Description
Software Verification Plan
Software Verification report
Reference to Software Standards (ISO, CMM, IEEE etc) and procedures
mentioned and defined as in the Quality Manual and Quality Management
System
User guides, operators and programmers manual
Configuration Management Plan
Software Quality Objectives.

5. Standards, practices and conventions:
To verify the delivery of a fully conforming, high-quality product,

every individual assigned to the project will participate in quality assurance. This
section describes the procedures used by SQA to verify that the quality assurance
provisions of this SQA Plan and applicable standards, practices, conventions, and
metrics are met.
The following measurements will be made and used to determine the

cost and schedule status of the SQA activities: SQA milestone dates (planned)
a. SQA milestone dates (completed)

b. SQA work scheduled (planned)
c. SQA work completed (actual)
d. SQA effort expended (planned)
e. SQA effort expended (actual)
f. SQA funds expended (planned)

6. Reviews and Audits:
The review and audits sections of Software Quality Assurance Plan will state
which technical and managerial reviews will be undertaken and how they will be
carried out. The ANSI standard suggests that the following would be a minimum
set of reviews:
Software Requirements Specification Review: This review is held to

approve the document defining the software requirements specifications and
it aims to check the adequacy of the requirements.
Primary Design Review: The purpose of this review is to approve formally,
the software top-level design document.
Critical Design Review: The purpose of this review is to approve the
software detailed design document as a basis for further development work.
Software Verification Review: The purpose of this review is to approve the
test plan. It is the evaluation of the adequacy and completeness of the
methods described.
Functional Audit: This is held to verify that all the requirements in the
software requirements specification have been met.
Physical Audit: This is held to verify that the software and its documentation
are internally consistent prior to delivery to the user.
In-Process Audit: In-Process audits of a sample design are held to verify the
consistency of the design.

7. Configuration Management:
This Configuration Management section of the Software Quality

Assurance Plan covers configuration identification, configuration control,
configuration status accounting, and configuration auditing.
8. Problem reporting and corrective action:
This section of the Software Quality Assurance plan describes the

system, which ensures that software problems are documented and resolved. It
should be a closed-loop system. All the problems should be promptly reported at
appropriate level, acted upon and resolved. Each problem should be analyzed to
determine its significance and causes and classified by category and each problem
must have severity level and a priority number.
For each problem, some corrective action and a target completion

date should be identified. The appropriate level of management should be made
aware of the problems and adverse trends. The corrective action taken will be
evaluated to ensure that it solved the problem without introducing any new
problems. Management should monitor the status of all unresolved problems.

9. Tools, techniques and methodologies:
Tools - SQA software tools include, but are not limited to, operating
system utilities, debugging aids, documentation aids, checklists, structuring
preprocessors, file comparators, structure analyzers, code analyzers, standards
auditors, simulators, execution analyzers, performance monitors, statistical analysis
packages, software development folder/files, software traceability matrices, test
drivers, test case generators, static or dynamic test tools, and information
engineering CASE tools.
Techniques - techniques include review of the use of standards,
software inspections, requirements tracing, requirements and design verification,
reliability measurements and assessments, and rigorous or formal logic analysis.
Methodologies - methodologies are an integrated set of the above
tools and techniques. The methodologies should be well documented for
accomplishing the task or activity and provide a description of the process to be
used.

10. Code Control:
Code control includes the items listed below:

Identifying, labeling, and cataloging the software to be controlled
Identifying the physical location of the software under control
Identifying the location, maintenance, and use of backup copies
Distributing copies of the code
Identifying the documentation that is affected by a change
Establishing a new version
Regulating user access to the code.
11. Media Control:
The Media Control section of the Software Quality Assurance Plan

will describe how the media are to be protected from unauthorized access or
damage. Security threats to a software project come from the following
environmental factors:
Fire Damage
Water Damage
Energy Variations
Structural Damage
Pollution
Unauthorized Intrusion
Viruses and Worms
Misuse of Software, Data and Services.

12.Supplier Control:
Prior to any purchase of software to support the development

effort, SQA and project members will define and provide complete requirements to
the supplier/vendor. The Software Tool Evaluation Process will be followed. Part
of the evaluation process will require the supplier or vendor to describe their
technical support, handling of user questions and problems, and software product
upgrades.
13.Records collection, maintenance and retention:
SQA activities are documented by records and reports that

provide a history of product quality throughout the software life cycle.
Measurement data collected will be reviewed for trends and process
improvement. All SQA records will be collected and maintained in the SDL
or archival storage for the life cycle of the product.
Appendices used in the Software Quality Assurance Plan:

AI Action Item
CMM Capability Maturity Model
CRLCMP Computer Resource Life Cycle Management Plan
CI Configuration Item
DBDD Database Design Description
DCR Document Change Request

DID Data Item Description

FCA Functional Configuration Audit
FQR Formal Qualification Review
IDD Interface Design Description
IEEE Institute of Electrical and Electronics Engineers
IRS Interface Requirements Specification
IV&V Independent Verification and Validation
KPA Key Process Area
OJT On-the-Job
PCA Physical Configuration Audit
P/CR Problem/Change Report
PDR Preliminary Design Review
PP&O Project Planning and Oversight
PRR Product Readiness Review
SCM Software Configuration Management
SDD Software Design Document
SDF Software Development File
SDP Software Development Plan
SDR System Design Review
SEI Software Engineering Institute
SEPO Systems Engineering Process Office
SME Software Management for Everyone
SPI Software Process Improvement
SQA Software Quality Assurance
SRR System Requirements Review
8. SCREEN SHOTS
(Main page screen)


(Admin /Editor Login page screen)




9. CONCLUSION
This is to conclude that the project that I
undertook was worked upon with a sincere effort. Most of the
requirements have been fulfilled up to the mark and
the requirements which have been remaining, can be completed with a
short extension.
Since Cricket Makes the Indian Crazy, The DLF-IPL site provides
a Single Platform to get All Information about Cricket & Fulfill Your Desire
to Entertained Completely.

10. FUTURE SCOPE OF PROJECT

The project made here is just to ensure
that this product could be valid in today real challenging
world. Here all the facilities are made and tested.
Currently the system works for Cricket League Played
In India Only. In near future it will be extended
for Cricket League that Played in Other Countries those are
Associated With ICC, so that efficiency can be improved.

12. BIBLIOGRAPHY
Books which I referred for the reference

Core Java 2 Volume I and II, by Cay S. Horstmann and
Gary Cornell
The Complete Reference JSP 2.0 by Hanna
Beginning JavaScript 2nd Edition, by Wilton
JavaScript for Dummies 3rd Edition, by Emily A. Vander Veer
The Complete Reference MYSQL
The Complete Referance HTML.
Websites referred:-
http://www.edition.cnn.com/
and some more news website for representing the way of news

THANKS

Ipl Case Styudy

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Ipl Case Styudy

Diunggah oleh

Hak Cipta:

Format Tersedia

DLF INDIAN PREMIER LEAGUE

DEEPAK KUMAR SINGH

DEPARTMENT OF COMPUTER APPLICATIONS

1 Deepak Kumar Singh , Department of Computer Applications, CUSAT

This is to certify that the project entitled

Signature of Internal Guide Signature of External

Guide Name and Designation

Name and Designation

Internal Examiner External Examiner

2 Deepak Kumar Singh , Department of Computer Applications, CUSAT

The satisfaction and euphoria that accompany the

I extend my gratitude to Dr. K.V. Pramod,

I would like to express my profound thanks to

Finally. I also wish to thank all guest faculties and non-teaching

Deepak Kumar Singh

3 Deepak Kumar Singh , Department of Computer Applications, CUSAT

Name of Student : Deepak Kumar Singh

Venue of the Project : DCA, CUSAT

Platform : Windows XP/Vista

Front End : JSP

Back End : MYSQL

4 Deepak Kumar Singh , Department of Computer Applications, CUSAT

5 Deepak Kumar Singh , Department of Computer Applications, CUSAT

5. System Design Specification

DLF Indian Premier League (IPL) is a T20 cricket

So by using this web portal user can get all the

7 Deepak Kumar Singh , Department of Computer Applications, CUSAT

2.1 Existing System:

2. Latest news and information are not up to date.

3. Navigation Facility is quite complex because sometimes it

4. Registration requires for Navigation.

8 Deepak Kumar Singh , Department of Computer Applications, CUSAT

T-20 Tournament, it will provide the information about teams playing in

This webportal will provide information about stastistics & records of

1. It provides information as per the requirements of the user .

9 Deepak Kumar Singh , Department of Computer Applications, CUSAT

3.3 Need for the proposed system:

T-20 Tournament, it will provide the information about teams playing in

This webportal will provide information about stastistics & records of

3.4 Feasibility study:

10 Deepak Kumar Singh , Department of Computer Applications, CUSAT

2.1 Feasibility considerations:

Three key considerations are involved in the Feasibility analysis: economic,

11 Deepak Kumar Singh , Department of Computer Applications, CUSAT

It consists of the following:

2.2 Steps in feasibility analysis:

1. Prepare system ER-Diagram,DFD

12 Deepak Kumar Singh , Department of Computer Applications, CUSAT

2.3 Type of feasibilities:-

The facility to produce outputs in a given time.

Response time under certain conditions.

Ability to process a certain volume of transaction at a particular speed.

Facility to communicate data to distant location.

After examining technical feasibility, we give more importance to the

what changes will be brought with the system?

what organizational structures are disturbed?

If not, can they be trained in due course of time?

Generally project will not be rejected simply because of operational infeasibility

Social feasibility is a determination of whether a proposed project will be

Legal feasibility is a determination of whether a proposed project infringes on

14 Deepak Kumar Singh , Department of Computer Applications, CUSAT

4. SYSTEM REQUIREMENTS SPECIFICATIONS

The software specification document satisfies the following:-

1 It specifies the external system behaviors.