FEASIBILITY OF THE PRODUCT

The feasibility of the product is a question that conforms the reality to the ideas. Feasibility test is critical. The
dimensions that define the feasibility of project are:

ECONOMIC FEASIBILITY
The cost incurred in making this software product is nothing in comparison to the amount of expenses made by the
organization in managing the library activities. The cost of the software is one long time investment and its
maintainability is very easy.

The product being complemented by a user manual and documentation is reusable and open to new changes.

TECHNICAL FEASIBILITY
The software is a newly developed application so it does need any other software or hardware. The technical feasibility is
high the software can be deployed on any machine having Turbo C++ Compiler and the software requires minimum
hardware requirements.

ENVIRONMENTAL FEASIBILITY
The software is simple, and staff members and students can use it with no difficulties at all. The user needs not be trained
in using the software or have any past experience of working in the software because it is very user friendly and easy to
use.

1.
 PROGRAMMING LANGUAGE USED
The coding has been done in Turbo C++ and JAVA. C++ and JAVA ,both of them are
based on the concept of OOPS (Object Oriented Paradigm) which thereby enhances
the functionality of the program with many reusable components like functions etc.
and support various encapsulation and inheritance mechanisms which make software
easy to read and make it more maintainable in long run.

We use C++ for the game-oriented applications, such as graphical outputs, sound
outputs, movements of players, etc.

We use JAVA for the web-based applications.

2.
 HARDWARE LIMITATIONS

 PC with a Pentium 2.4 GHz processor, Pentium IV recommended.

 512 MB of RAM.
 1 GB of available hard-disk space for full installation.

SOFTWARE LIMITATIONS

 The system will run under Windows XP or later operating systems.

 Unix(Linux) Operating System is not supported.
 All functions will be developed in Turbo C++ and JAVA.
 SQL should be installed for database handling.

3.
 SOFTWARE MODEL USED

This System is based on Linear Sequential Model (Waterfall Model) because of the following reasons:

 As our system follow a systematic, sequential approach to software development that begins at the system level
and progress through analysis, design, coding, testing and support.

 As the user is required in the initial stage of the system to help the team members to know about the
requirements, nature of program, information domain for the system etc.

 All requirements for the system have been explicitly stated at the beginning. There is very little scope of user
deviation from current requirements, coding and testing after detailed analysis is much easy.

 Our system has blocking states because one team member has to wait for other member of the team to complete
the dependent tasks.

 Team members are not able to know about the changing requirements of the user as the users are present in the
initial stage and then at the testing stage of the system.

 There is no modular structure as there is only one team to develop the system and to do all the tasks related to
system such as analysis, design, coding, testing.

4.
 TEAM STRUCTURE
Our System has Democratic Decentralized (DD) team structure as there is no
permanent team leader. Problem of the system is solved by group discussion and also
decisions on problems and approach are made by group consensus. All the team
members communicate horizontally i.e. horizontal communication exist between
group members.

5.
 2.
Requirement
Analysis

6.
 REQUIREMENT ELICITATION
The real requirements actually reside in the user’s mind. Hence the most important
goal of the requirement engineering is to find out what user really needs.

The data required for this stage of our software development was gathered in the
following ways:

 The meetings were conducted with the customer team. They were questioned
about their requirements and expectations from the game.

 Numbers of questionnaires were prepared to gather the information necessary

for our product.

7.
 Initiating the process
Stage – 1 : Context Free Questions

These questions are asked to the user in the initial stages of the project and this leads
to basic understanding of the problem, the people who want the solution and the nature
of the solution that is desired.

The questions and answers related to our project are: -

Q. Who is behind the request for this work?

A. The organizer who wants to have a web-based competition.

Q. Who will use the solution?

A. The users ,who will play online and the organizer , who manages all the schedules.

Q. What will be the economic benefit of a successful solution?

A. The product will be user friendly and good at graphics which will attract lots of
people to our network and thus , we can get sponsorships also.

Stage – 2 : Better Understanding

The stage 2 questions help the analyst in gaining a better understanding of the
problem.

The questions and answers related to our projects: -

8.
Q. How would you characterize “good” product that would be generated by a
successful solution?

A. The graphics should be high, it should be user-friendly, databases should be well-

maintainable. All the interfaces should be well connected. User accounts should be
well-protected and should stop any of the errant users.

Q. Can you describe the environment in which the solution will be used?
A. We need a web-based, multiuser environment,, so that people can connect through
the world-wide-web to each other ,as we want a product through which we can
have a web-based competition.

Q. Will special performance issues or constraints affect the way the solution is
approached?
A. Yes, our solution needs high graphics and web-based applications. So, these
graphics and web-based applications will make the project to be approached for
designing differently.

9.
Stage – 3 Meta Questions

Meta Questions focuses on the effectiveness of the meeting.

In respect to our project, the questions can be like:

Q. Whether these questions are relevant to our project?

Q. Can anyone else provide additional information?

It can be conveyed from the user side or any one else can provide any other
information.

10 .
 FACILITATED APPLICATION
SPECIFICATION TECHNIQUE (FAST)

FAST approach encourages the creation of a joint team of customers and

developers who work together to identify the problem, propose elements of the
solution, negotiate different approaches and specify a preliminary set of solution
requirements.

While reviewing the request the following lists were prepared:

List of Objects:
Users
Databases
Sponsorers
Organizer
Players

List of Services:
Create username and password.
Create a team.
Select players/uniforms/formation settings.
Adding the username, its password, its team, players, and all other information
in the database.
Game playing interface.
Developing a game playing interface.
Database for storing the temporary results of match, when the match is being
played.
Edit the team before and after match.
Changing the username and password whenever user wants.
11 .
 As soon as the match is over, the result, standings, previous result databases
should be updated automatically.

List of Constraints:
Need of good graphics.
Managing databases dynamically.
Help for user’s friendliness.
System works only on DOS and Windows 98/XP Platforms.
Cost of developing the system should be manageable.
Only authenticated users can login the system due to security reasons.

Performance Criteria:

Nice graphics, to give a touch of originality to game.

Software works within operable and acceptable speed and can work efficiently
even if the database grows rapidly.
Use modern OOPS concepts and heavily relies on Databases.
System is secure and uses strong and modern encryption techniques for storing
passwords of the authenticated users.

For any kind of queries (like, timetable, standings, etc.) only respective
database should be printed on monitor.

Support for GUI (Graphical User Interface).

12 .
USE CASE

A use-case is a scenario that describes how software is to be used in a

given situation. These are defined from actor’s point of view(an actor is a
role that people(users) or devices play as they interact with the system).

USE CASE FOR CREATION OF U/P AND TEAM

Whenever a new user visits the online game and wants to create a new team of
its own, then he will click on the option “creation of team”.
As soon as he clicks on the option “creation of team”, he will be asked to enter
username and password to register himself. If this username already exists
then a message will be displayed on the screen, and he will again be asked to
enter different username.
After the creation of U/P, the user will be asked to create its team. It includes a
team name(which would be unique) . If the name he selects has already been
selected by another user, then a message will be displayed on the screen and
he will be asked to enter a different team name.
Now the user will selects the uniform for its team ( home, away, alternate kits
) , selection of 16 players ( 11 mains, 5 subs ) for the team according to their
skills, and will be positioned accordingly, that is, the formation settings of the
players.
Then, the user will save its team by clicking on the button “SAVE”.

13 .
 QUALITY FUNCTION DEPLOYMENT
It is a quality management technique that helps to incorporate the voice of the
customer. The voice is then translated into technical requirements. These requirements
are translated into design requirements. Here, customer satisfaction is of prime
concern and thus QFD emphasizes an understanding of what is valuable to the
customer and then deploys these values throughout the software engineering process.
Three types of requirements are as follows:

NORMAL REQUIREMENTS
The objectives and goals of the proposed are discussed with the customer. If this
category of requirements are present, the customer is satisfied.
Normal requirements of our project are: -
Ease of verification and creation of team
Help feature to explain what they are looking for.
Standings databases should be automatically updated.
Efficiency

EXPECTED REQUIREMENTS
These requirements are implicit to the system and may be so obvious that the customer
does not explicitly state them. If such requirements are not present, customer will be
dissatisfied with the software.
Expected requirements of our project are:-

User account should be well encrypted.

Information should be well protected.
Ease of interaction i.e. user friendly

14 .
 Maintainable databases.
Adequate size of databases
Installation ease
Operational correctness

EXCITING REQUIREMENTS
Some features go beyond the customer’s expectations and prove to be very satisfying
when present.
Exciting requirements of our project are:-

Good graphical presentations

Commentary features.
Sounds of kicks, whistles, tackles, etc.
Showing the timer.

15 .
 QUESTIONAIRE TO BE GIVEN TO STUDENTS

Ques1) Do you visit library or not?

Ans.--------------------------------------
Ques2) How often do you visit library?
Ans. ----------------------------------------
Ques3) Do you use the catalogue to reserve the books and to find the books?
Ans.----------------------------------------------------------------------------------------
Ques4) Do you find any problem in the system? If any please specify.
Ans.--------------------------------------------------------------
Ques5) In case of problems whom do you consult?
Ans.--------------------------------------------------------
Ques6) Did the advices of library staff helped you?
Ans.-----------------------------------------------------------
Ques7) Is the procedure to get the information of the book is easy?
Ans.-----------------------------------
Ques8) Is there any other source for the solution that you need?
Ans.----------------------------------------------------------------
Ques9) How would you characterize the “good” system?
Ans.---------------------------------------------------------------------
Ques10) What special performances do you expect in the system?
Ans. ---------------------------------------------------------------------------
Ques11) What other improvements do you expect in the system?
Ans. ---------------------------------------------------------------------------

16 .
 3.
Data Modeling
And
Design

17 .
 ANALYIS MODELING

The analysis model achieves three primary objectives:-

 To describe what the customer requires.

 To establish a basis for the creation of software design.
 To define set of requirements that can be validated.

18 .
It uses a combination of text and diagrammatic form to depict requirements for data,
function and behavior in a way that is relatively easy to understand and review.

The following tools have been used to model the system.

Entity Relationship Diagram (ERD) specifies the relationships between data objects
and attribute of each data object can be described using a data object description.

Data Flow Diagram (DFD) provides an indication of how data are transformed as
they move through the system. Also depicts the function that transforms the data
flow.

PSPEC specifies the work of each process i.e. the description of each function
presented in DFD.

Data dictionary has been used as a repository that contains description of all
data objects consumed or produced by the software.

19 .
 PSPEC of result processing module(2.3)

i is the name of any team..

for all i’s

If result[i] is “w”

Then standing[i][1] + =3;

Else if result[i] is “l”

Then standing[i][1]+=0;

Else

standing[i][1]==1;

standing[i][2]+=int[i][1];

standing[i][3]+=int[i][2];

standing[i][4]+=int[i][2] – standing[i][3];

sort the standing array using a suitable sorting technique, according to points, i.e. ,
standing[i][1];

winner of league will be standing[1][1];

first runner-up will be standing[2][1];

second runner-up will be standing[3][1];

20 .
21 .
 DATA DICTIONARY
The data dictionaries are simply repositories to store information about all data items
in DFDs. At the requirements stage, the data dictionary should at least define customer
data items, to ensure that the customer and developers use the same definitions and
terminologies.

The data dictionary for the Player’s info is as follows:-

1. Name : Player’s info

Alias : None
Where used/How Used : By user for creation of team.
Description:
Player’s info = Name + physique + skills + position + m/s

Name = ronaldo |
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………………………
………………………………………………………………………………………..
Physique = skinny | fatty | athletic | average
Skills = 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99
Position = forward | middle | defender
m/s = main | sub

22 .
 DESIGN CONCEPTS

Design is the meaningful representation of the something that is to be built.It can be

traced to a customer’s requirements and at the same time can be accessed for the
quality of the product to be built.
A good design basically focuses upon : data, architecture, interfaces, and components.
Our design of system should be modular in nature, which reduces complexity,
facilitates changes, and results in easier implementation by encouraging parallel
development of different parts of the system.

The modules should be functionally independent. Software with effective modularity,

that is, independent module, is easier to develop and easier to maintain because
secondary effects caused by design or code modification are limited.
Independence is measured using two quality criteria: COHESION and COUPLING.

COHESION

Cohesion is a measure of the degree to which the elements of a module are

functionally related. A strongly cohesive module implements functionality that is
related to one feature of the solution and requires little or no interaction with other
modules.
It can be of many types, like, Coincidental, logical, temporal, procedural,
communicational , sequential, functional cohesion etc., where functional cohesion
has high degree of cohesion, and coincidental has lowest cohesion. We search for high
cohesion between the modules.

COUPLING

Coupling is the measure of degree of interdependence between modules.

It is the measure of interconnection between modules. Two modules with high
coupling are strongly interconnected and thus, depend on each other. Two modules
with low coupling are not dependent on one another.

23 .
Different types of coupling are content, common, external, control, stamp, and data,
where data coupling is the best coupling and content coupling is the worst amongst the
list. We search for low coupling between the modules.

An efficient system must have High cohesion and Low coupling.

24 .
 4.
Project Metrics

25 .
 PROJECT METRICS

Project metrics describes the project characteristics and execution. These are used
for strategic purposes. Project metric and indicator derived from them are used to
adjust task flow, track potential risks etc.

The intent of project metrics is two fold:

1)used to minimize development schedule by making necessary adjustments.
2)can assess product quality on ongoing basis and when necessary modify technical
approach to improve quality.

FUNCTION ORIENTED METRICES

Function oriented metrics use a measure of the functionality delivered by the

application as a normalization value. Functionality is measured by function points.
Function points are derived using an empirical relationship based on direct
measures of software’s information domain and assessments of softeare
complexity.

Calculation of complexity adjustment values:

Grade
Value
Does the system require reliable backup and recovery? 5
Are data communications required? 4
Are there distributed processing functions? 2

26 .
Is performance critical? 5
Will the system run in an existing, heavily utilized 3
operational environment?
Does the system require online data entry? 5
Does the on-line data entry require the input transaction 5
to be built over multiple screens or operations?
Are the master files updated online? 5
Are the inputs, outputs, inquiries complex? 2
Is the internal processing complex? 3.5
Is the code designed to be reusable? 1
Are conversion and installation included in the design? 5
Is the system designed for multiple installations in 5
different organizations?
Is the application designed to facilitate change and ease 3.5
of use by the user?
∑Fi= 55

Calculation of Function point for the Football league software::

Measurement parameter
Count Weighting
factor(average) Weighting
count

Number of user inputs 4 4 16

Number of user outputs 11 5 55
Number of user inquiries 2 4 8
Number of files 9 10 90
Number of external interfaces 7 7 49

Count total 218

27 .
Function point = Total count x (0.65 + 0.01 x (∑Fi))
= 218 x (0.65 + 0.01 x 55)
= 218 x (0.65 + 0.55)
= 218 x 1.2 = 261.6  262
Once function point has been calculated it can be used to normalize measures for
software quality, productivity and other attributes such as:
Errors per FP
Defects per FP
$ per FP
Pages of documentation per FP

28 .
 RISK ANALYSIS AND MANAGEMENT

Risk Projection or Risk Estimation attempts to estimate risk by performing four major risk estimation
activities
Scale is established which reflects the likelihood of the risk.
Consequences of the risk are delineate.
Impact of the risk is estimated on the system.
Accuracy of risk estimation is noted to avoid misunderstanding.

For performing risk estimation RISK TABLE is developed which help to estimate risk and provide us
with the CUTOFF LINE (which indicates which risks will be handled first and will be given priority).

For our project the risk table is as follows:

Category Probability Impact RMMM

Risks
Insufficient no. of BU 40% 1  Keep the cost
users may apply for of installation
the game ROM low.

 Publicize the
product
efficiently.

User exits without DE 30% 3  Saving options should

saving the details.
Size estimate may be
significantly low
be highlighted whenever
necessary.
PS 50% 2  Choose appropriate
sizing technique to
determine the software
size
 Ensure all the customer
requirement are clearly
understood

Customer will PS 20% 1  Update the employers

change requirements regularly about the
status and working
assumptions.
 System must be
modular so that changes
can be easily

29 .
 accommodated.
 Get Customers’
feedback periodically

Delivery deadline BU 80% 2  Schedule made should

may be tightened be realistic and
achievable
 There should be no
blocking states.
 All the tasks must be
divided properly among
group members with time
constraints.

Don’t get the BU 50% 2  Publicize the

expected and every user
sponsorships. who wants
product
efficiently.
 Charging a
specific
amount for
each to play in
the league.


IMPACT VALUES:

1. Catastrophic
2. Critical
3. Marginal
4. Negligible

Now once the risks are estimated, their probability, their impact on the system and category to which they
belong then RMMM is followed to deal with the risk.
RMMM is the effective strategy that must consider three issues

Risk avoidance.
Risk monitoring.
Risk management and contingency planning.

30 .
 6.
Project
Scheduling

31 .
 PROJECT SCHEDULING

Before the starting of a new project, it must be scheduled properly (i.e. all the tasks
involved in the project, duration of each task must be planned properly).this project
schedule is monitored on continuous basis.

Every process model is populated by a set of tasks that enables a software team to
define, develop, and ultimately support software. There are different kinds of task sets
available for a project. Depending on the type of project and TSS value ( which gives
degree of rigor), a task set is selected.

New
Adaptation criteria Grade Weight development Product

Size of project 5 1.2 1 6.0

Number of users 5 1.1 1 5.5

Business criticality 3 1.1 1 3.3

Longevity 3 0.9 1 2.7

Stability of requirements 2 1.2 1 2.4

Ease of communication 4 0.9 1 3.6

Maturity of technology 1 0.9 1 0.9

Performance constraints 5 0.8 1 4.0

Project staffing $$$3 1 1 3.0

Interoperability $$$4 1.1 1 4.4

Task set selector 3.58

Interpreting the TSS value and selecting the task set:

32 .
TSS = 3.58
It lies in the category of 3.58 > 2.4
Therefore the task set selector value recommends a strict degree of rigor to be
followed in scheduling the processes.

33 .
 Timeline Chart

A timeline chart enables to determine what tasks will be conducted at a given point in
time. When creating a software project schedule, the planner begins with a set of tasks
(the work breakdown structure). Effort, duration, and start date are then input for each
task. As a consequence of this input, a timeline chart or Gantt chart is generated.

In a timeline chart, horizontal bars indicate the duration of each task. When multiple
bars occur at the same time on the calendar, task concurrency is implied. Diamond
indicates a milestone.

The timeline chart for our software project is as follows:

34 .
35 .
 7.
SQA
Software Quality
Assurance

36 .
 SQA (Software Quality Assurance)

Quality is addressed by applying solid technical methods and measures, conducting

Formal Technical Reviews (FTR) and performing well planned software testing.
SQA Activities
The Formal Technical Review is one of the SQA activities that is used to find the
error during the process so that they do not become defects after the release of the
software.
Defect Amplification Model is a method to illustrate the generation and detection of
error during the preliminary design, detailed design and coding step of the system
engineering process.

Development Step
Defect Detection

Error Passed Through

Errors from
previous step
Percent Errors passed
efficiency for
Amplified Errors 1 : x error to next
detection step

Newly Generated Errors

The defect amplification for our system is:

Preliminary Design
Detail Design
0
9
9
0 0%
6 6 x 1.5 40
10% Coding Stage
=9
15
25

37 .
 8.
Software
Testing

38 .
 SOFTWARE TESTING
Testing is a process of executing a program with the intent of finding an error. A good
test case is one that has a high probability of finding an as-yet-undiscovered error. A
successful test is one that uncovers an as-yet-undiscovered error.
Testing can be done by many ways-:

White-Box Testing or Glass-Box Testing.

Basis path Testing.
Integration Testing.
Validation Testing.
Black box Testing.
System Testing.
Recovery Testing.

These are the various testing methods which are applied on the systems that have code
segments. But since there is no coding in our system so no testing is required in our
system.

39 .
 BIBLIOGRAPHY

1. Roger S. Pressman, Software Engineering, A Practitioner’s Approach 5th

Edition.
2. K.K.Aggarwal & Yogesh Singh , Software Engineering, 2nd edition.

40 .