Team Builder

Roderick Burkhardt and Faiga Revah

California State University, Monterey Bay

CST 499 - Directed Group Capstone
Advisor: Eric Tao, Brian Robertson
October 2017
Executive Summary

As part of CSUMBs computer science curriculum, students are required to complete a

Capstone project. Roderick Burkhardt and Faiga Revah have created Team Builder, an

application that uses data to create well balanced teams. The application uses individual points

scored and other metrics to determine the skill of each player, and will thusly be able to create

fair teams. During the course of the development of Team Builder, the developers integrated

skills that they acquired during their studies at CSUMB, such as Agile software engineering,

JavaScript programming, security, and design.

The goal of Team Builder is to encourage people to play pickup games, which are crucial

to the skills of athletes. Nearly all professional athletes hone their skills not only during training

time, but also outside of official training in arenas like pickup games in the local park. Players

who are at a lower skill level are often self-conscious and do not play, which results in their skill

levels remaining stagnant. Team Builder will encourage players by tracking their progress and

ensuring that players have teammates who can help them take part in a fair game.

The application was created within an eight week time frame. The developers first began

by creating a working interface with the backend and frontend complete. Then, they completed

the algorithm by testing the application with their client, the San Francisco Gay Basketball

Association. The app was then sent to the testing phase.

The application seeks to serve all basketball players- male and female of all ages- who

want to take part in a game. Creating a fairly balanced game will have positive effects on

developing players, who need an arena to fine-tune their skills, and older players, who need an

outlet for physical activity.

Table of Contents

Executive Summary 2

Introduction

Project Name and Description 4

Problem and Solution 4

Goals and Objectives 6

Community and Stakeholders 7

Evidence 8

Feasibility Discussion 8

Design Requirements

Functional Decomposition 11

Selection of Design Criterion 11

Final Deliverables 12

Approach 12

Ethical Considerations 13

Legal Considerations 14

Timeline/Budget 15

Usability/Testing Evaluation 17

Final Implementation 18

Conclusion 23

References 25

Appendix 26
Introduction

Project Name and Description

As part of the Capstone requirement of California State University- Monterey Bays Computer

Science program, Roderick Burkhardt and Faiga Revah will be creating Team Builder, a web

application. The app creates teams for pickup basketball games based on the players abilities.

The app is primarily an algorithm that sorts the players in a game so that fair teams and balanced

games become more likely.

Our app will create a database of players and keep track of their playing abilities. This will be

based primarily on their scoring abilities, but also on other metrics that indicate the players level

of skill and ability, such as height and fitness level. When a user of the app wants to play a game,

s/he can search for neighboring players who are also looking to play, or for an existing game.

When a group of players is assembled, the app will generate teams that are as well balanced as

possible.

The client for the application is the San Francisco Gay Basketball Association. The association is

a league for basketball players, and the developers will be using the league to gather statistics

and to test the application. Most importantly, the client will help the developers with the creation

of the algorithm, by providing metrics and statistics to help determine which permutation of

players will lead to a balanced game.

Problem and solution

Pickup games in the park have many benefits to players. Firstly, it aids player development,

improves conditioning, and of course is a fun way to practice. Many major league players have

honed their skills by playing pickup games in their respective sports. Neighborhoods that have a
culture of athletics often breed more major league players, since players have more time to

practice with a wide spectrum of players, and they can learn from the skills of many different

people.

The problem with pickup games as they are is twofold. Firstly, in neighborhoods where the

culture is not intensely athletic, there will not necessarily be a pickup game available at any

given time. It is important for someone aspiring to become an athlete at any level to consistently

practice, and the availability of a pickup game is key to his/her skills. Secondly, players are

profiled before they even play. If a player looks well built, or is of a certain race, other players

will assume something about their playing abilities and will make teams based on those

assumptions. Oftentimes, assumptions are incorrect, which can lead to a game with a two teams

of completely different skill levels.

This app can tremendously benefit female players. Pickup games are nearly nonexistent for

females. Males tend to dominate the courts in the park, and most female athletes practice time is

limited to when their team actually practices. This ultimately contributes to the wide gap

between male and female sports on the professional level. By providing females with a means to

create a game in a space that is exclusively theirs, they will have more opportunities to practice

and hone their skills. Additionally, with the assurance that the games will be evenly balanced,

players will be more confident and thusly more likely to join the game. This can also boost the

culture of athletics for females, which is far behind the male athletic culture. Additionally, this

app can help lesser skilled or confident players, who feel overwhelmed by pickup games, which

are often used as a means of showing off skills. Players can see who theyll be playing against,
and by knowing that the teams will be as well balanced as possible, will perhaps be more

motivated to join a pickup game.

Goals

Build an application to support the facilitation of teams based on their players skills and

abilities.

Provide each team an opportunity have fun & vigorous play on the court.

Offer organizations a way to support their players abilities and provide them the best

possible experience on the court.

Objectives

Create an algorithm that takes a group of players and creates similar balanced teams for

open gym or league play.

Present the algorithm in an easy to use application for both players and organizations.

Application will allow players as while as organizations to update player information and

record player stats.

Make the application supported on multiple devices, such as desktops and mobile

devices, with support first on browsers, followed by android, with future support for

Apple mobile devices.

Future: Allow player or organizers that ability to check players into open gym sessions so

that the system can add them to available teams for playing.

Future: Let players sign up to join league teams from within the application.

Future: Manage league scoring keeping, and merge individual scoring statistics into

players stats.
Community and Stakeholders

The primary stakeholders for the this project will be the San Francisco Gay Basketball

Association and the community of basketball players that play with them. The SFGBA is one of

the oldest Basketball organizations in world that supports the LGBTQ community. The

organization operates basketball leagues twice a year, holds a national tournament every other

year as part of the National Gay Basketball association, and holds open gym 2 to 4 times a

month.

The organization for the most part relies on their founder during open gym sessions to

organize the available players into teams that are some what equally matched. He does this to try

and give every player on each team an opponent that is similar in skills and abilities as they are.

The teams that he creates are often matched in a way that allows each team to play a good

vigorous and challenging game against each other.

During one of the organizations open gyms is where the idea of the team builder

application was conceived with the idea that it might be possible for a computer application that

could possibly assemble teams based on the same player stats that are used to determine the

manually. With this application, the organization hopes would like to be able to create league

teams that are more eveningly matched to invite a more fair competition during the leagues

seasons.

Evidence

A number of studies have shown that as women have more access to coaching and more

opportunities to hone their athletic skills, the muscle gap between male and female athletes

closes (Fain 2016). This implies that opportunities to practice directly impacts not only skill
levels of athletes but also their physical makeup. The more an athlete, either male or female, has

access to training facilities, the more like s/he is able to accrue success in sports.

Studies have shown that one outcome of sports, in particularly team sports, is the development of

self esteem, especially when there is progressive skill development (Rosewater 2009). This app

allows for progressive skill development by tracking the progress of the athlete and always

ensuring that they are on a balanced team, where each player must contribute. Additionally,

because of the assurance of balance, players will be more motivated and feel more confident.

Feasibility Discussion

An application with the exact specification of this application has not yet been created.

There are many applications and websites that incorporate aspects of the Team Builder

application, but no app is designed uniquely for the purpose of building well-balanced sports

teams.

There are team generators that generate teams in a completely random manner, such as

randomlists.com. Most team generators online seem to be projects that were done by one

developer in his/her spare time. They have simplistic functionality, and very little logic

implemented.

There are a few apps that address the pickup game location function. Infinitehoops that

users find local pickup basketball games using their location. Another app, Hoop Maps, appears

to be the most successful pickup game app. In the week of March 22 alone, it gained 10,000 new

users. Hoop Maps is geared towards social networking. The app is connected to Facebook, and

allows for users to invite other players to their game through Facebook even if they are not Hoop
Maps users. The founders hope that the added convenience of joining a pickup game will

motivate people to move and abandon their static lifestyle (Friedman 2017). TechCrunch says

that Hoop Maps falls into the social planning and networking category of apps, making it

fundamentally different from the Team Builder App.

In order for Team Builder to properly calculate and balance the teams, the app will need

to keep track of game statistics of both teams and individual players. Capterra, a business

software referral website, lists the top sports league websites and applications. It includes

websites such as TeamSideline.com, which offers automated scheduling and scoring and team

sites, and Wooter Basketball, a platform for league managers to manage registration, schedules,

players, stats and videos. Most of the apps for sports leagues are for management and data

purposes.

The primary function of the application to is to sort teams based on individual's skills

and abilities. This includes height, years of experience, age, and previous scores. Each player

will have a profile that records personal details such as age and height and data such as points per

game. The player can edit their profile and can enter their scores at the end of each game. When

a group of people or a league administrator would like to create a game, they can enter

individuals based on their profile, and the application will generate teams. Users of the

application can either be players or coaches/administrators/organizers.

A basic simulation of the application for a game is as follows: players gather together and

decide to play a game. They open the application and select the profiles of the players who will

be joining the game. The application then uses the internal algorithm to sort the players into two

teams and notifies the players which teams they are on. The players then play the game and
record their individual points scored and the team totals. The algorithm then uses that data for

future games so those games will have even more accurate data. Aside from the game

simulation, players can also search profiles, edit their own profiles, and choose their privacy

settings.

Each functional part of our application is necessary for the accuracy of the algorithm. The

profile components- such as height, years of experience and age- were carefully selected from

amongst many other attributes such as weight, conditioning, and self-rating. Those specific

components will be used by the algorithm to ascertain the skill level of the player. Additionally,

it is crucial that players enter their points scored into the application after playing so that the

algorithm can grasp the scoring abilities of the player. The team score is also important so that

the algorithm can learn from previous games and see which combinations of what prototype of

players were most effective. Finally, the profile-searching aspect of the application lends a more

social aspect to the application, which will compel users to use the app more frequently. The

more users that are on the application, the more the algorithm will be able to teach itself and

refine future teams further.

Functional Decomposition

The primary function is that the algorithm of the application works. The sole purpose of the app

is to evenly divide users into teams. While there is other functionality, such as a profile and

profile edit, and profile search, the core of the app is the sorting functionality.
While the algorithm cannot always ensure games with close scores (as professional sports is

evidence to this as well, where games are sometimes unbalanced even with a fair division of

talent) it does disperse the talent as evenly as possible.

The app will create a database of players and keep track of their playing abilities. This

will be based primarily on their scoring abilities, but also on other metrics that indicate the

players level of skill and ability. When a user of the app wants to play a game, s/he can search

for neighboring players who are also looking to play, or for an existing game. When a group of

players is assembled, the app will generate teams that are as well balanced as possible.

Selection of Design Criterion

Performance goals- performance should be fast and there should be no delays visible to the

human eye. Application should work smoothly and reliably. There is no metric for performance

that the developers are relying on due to time constraints, but they will focus on making the

application feel fluid and fast.

Reliability- Because the complexity of software is inversely related the softwares reliability, and

because this application is not extremely complex, the developers expect the application to be

fairly reliable and for users to experience no failures. The application has been developed

through test driven development, and as such, the developers have focused on reliability as a

quality of their product.

Cost- The development of this application was low budgeted. There were costs incurred in the

following areas: purchasing of instructional videos in Angular JS, sponsorship of games at

SFGBA, and a few other technologies such as a web server.

Code size- There is no goal for code size. The developers only intend that the test cases are at

least 1.5 times the code size of the remainder of the application.

Safety- The application does ask for private details from users, such as age, gender and email, but

the user can choose whether or not to share it with other users of the application.

Societal factors- The human interface is modern, intuitive and simple, with few distractions. The

application is not intended to be an addictive application in the way that many websites are,

and as such, the design is simple and reflects the goal of the application. The application has no

environmental impact, and encourages physical activity.

Final Deliverables

TProject deliverable are server application that will operate through a angular frontend that will

be used by the client and players to access the application. Players will be able to create and

update their profile information and basic stats. The organization will be responsible for keeping

up player game statistics and other information that is related to the organization. We will deliver

an application that will also include a database for securely storing all the information that is

collected.

Approach

While our application will have a functioning interface, the crux of the application is the

team building algorithm. Thus, we will begin the development cycle by creating and refining the

algorithm to build balanced teams. In order to ensure that the algorithm is as accurate as possible,

we will use our client, the San Francisco Gay Basketball Association as the test case. We will
first record statistics from a number of basketball games, including individual team points,

number of wins per person and team, height of players and position played. The algorithm will

be based on those statistics, and will attempt to create new teams with those players that are well

balanced. We will then continually test and refine our algorithm using statistics from games

generated by the algorithm and from other games.

After achieving a 65 percent success rate, we will begin the design and implementation of

our application. We will first design the application on the front-end using Angular 4 and test

that. We will then incorporate our logic together with the front-end and implement the back-end.

The entire process of development will be test-driven, from the creation of the algorithm, to the

design implementation, to the back-end functionality. Once the application is completed, it will

be run through a series of tests on the computer and on our client.

The application will be a web based application written in Angular 4 with Bootstrap UI

integration. The algorithm will be written in Java backend, and accessed via RestAPI calls and

will be paired with a MySQL or a MySQL type database. In the mobile application, the

algorithm will have an accessible component within the phone app to circumvent the possibility

that the phone might be offline during its use.

Ethical Considerations

Like most other applications, privacy is one of the ethical considerations that we have to

take into consideration. It is important that we ensure that the user data is protected and that as

developers, we take all security precautions necessary. Users will likely have to submit some

form of identification, such as an email or phone number, so that we can create authentic
accounts with primary keys such as an email. Developers have an ethical obligation to ensure

first and foremost that the users private information is protected. Another ethical obligation that

we have is to ensure data integrity. We must make sure that hackers cannot access our data and

manipulate it, because that would jeopardize the integrity of the entire games algorithm. We

would therefore be marketing a product that does not do what it advertises.

In the design process of our application, we were debating whether or not to ask users to

enter their gender, as it would allow for us to create female-only games that are a safe space for

female players who may have less confidence. However, this would perhaps be sensitive for

gender nonconforming individuals, who would not like games to be gendered. This concern can

be mitigated by offering multiple choices for genders, allowing people to pick their games no

matter the gender, or perhaps eliminating the gender consideration altogether.

Handicap players or players of lesser physical ability may also feel the fallout of their

weaker skills. Since they usually have a low impact on the scoring, the record of their data and

its publicity can become embarrassing for them. Therefore, it is important that we give players

options as to whether or not they would like to make their data public.

Our application has no environmental impact, and encourages physical activity.

Legal Considerations

There are a few potential legal considerations that we must consider as we work through

this project. The application collects player information, a few of these bits of information can be

considered sensitive information that will need to be properly protected otherwise it could lead to

possible legal and privacy issues especially being that the application will be primarily a cloud
based application. It will be important that we select services for hosting the application that will

help us with securing and protecting the data used in the application.

In the currently planned version, there are not really any other legal considerations that

care clearly present at this time, but in the future should feature such as league registration

include the ability to accept payments, there will be additional legal considerations to take with

the handling of payments.

Timeline/Budget

Timeline at start of project:

Faiga Roderick

Week 1 Project Documentation Setup project resources and

management

Week 2 Begin frontend coding Finish base backend application and

start algorithm coding

Week 3 Work on frontend design Continue work on algorithm

Week 4 Begin mock data creation and testing

Week 5 QA testing and debugging

Week 6 Enter / acquire real player and so real time testing at an open gym session and do
debugging as needed.
Week 7

Week 8 Finish up documentation and prepare for presentation.

Timeline at conclusion of project:

Faiga Roderick

Week 1 Project Documentation Setup project resources and

management

Week 2 Begin frontend coding Finish base backend application and

start algorithm coding

Week 3 Work on frontend design Continue work on algorithm

Week 4 Set up API, integrate frontend with API

Week 5 Continue working on API

Week 6 Integrate algorithm with API

Week 7

Week 8 Enter / acquire real player and so real time testing at an open gym session and do
debugging as needed, finish documentation and video

The timeline for this project left the developers seven weeks to complete the project. Due

to unforeseen circumstances, the timeline had to be extended and as of now, the project will

remain in development for the remainder of the semester. There will be a working prototype for

the Capstone festival, but it will not be thoroughly tested. In the first four weeks, the developers

worked on the interface, creating both the frontend and backend. There were some server issues

that further delayed development as well. Interface development was only projected to last the

first two to three weeks, but it went beyond the allotted time. The algorithm itself took less time

to develop than projected, which helped even out the timeline.

The project remained within the budget and no extra or unexpected costs occurred.
Usability Testing/Evaluation

There were a number of components of the application that required testing. Since the

application was created in NodeJS, and JavaScript is a dynamically typed language, testing cases

are crucial to the development of the application. The backend of the website was created in

NodeJS, and the developers performed unit tests using available AngularJS testing tools.

The unit tests were done in Jasmine, a JavaScript framework for testing code that

executes tests in a browser. Some examples of unit tests were: ensuring that only valid email

addresses are used, ensuring that upon creation of a new user profile, the username is unique, and

ensuring that only valid values for height, age, and experience are entered. There were also tests

to ensure that each element (such as a button, dropdown menu, or header) works correctly, and

when clicked, the functions work as well. Some of the tests were written prior to development,

while most were written after development.

For integration testing, we used Karma. Integration testing was done near the completion

of the project to test the workflow of the website. For example, we tested whether a new user can

create an account and profile, and then see the profile details. We also tested whether a user

could look up games based on location and whether an administrator can create teams. All pages

of the website were involved in at least one integration test, and the entire flow of the website

was tested. The integration tests were based on user stories (such as As a user, when I select a

game, I am able to join the game as a player.)

To test the server, the developers created mock HTTP requests and a mockup server.

$httpBackend is a mock HTTP backend implementation. Instead of running tests on the real
server, $httpBackend allowed for the developers to check whether requests were being sent or

received with a mockup implementation.

After completing the unit, integration and API tests, the application interface was ready

to be used by the client, who would test the algorithm at the crux of the application. The

algorithm attempts to sort the players into two teams. The algorithm works based on a point

system, where players are assigned a number of points based on their skill level, age, experience,

and average points scored per game. The players also receive a ranking. The algorithm then

creates teams of equal or nearly equal point values for players.

To test the efficacy and accuracy of the algorithm, the developers first gathered stats from

previous games at the San Francisco Gay Basketball Association. They logged onto our app and

we collected feedback initially only about the design and ease of navigation. We then had them

use the app to play a game, and over a series of five games, we collected data and continually

refined our algorithm. In the section below, there is a diagram that illustrates our testing

iterations successes and failures.

Final Implementation

The major functions of the project are as follows:

Homepage: The homepage, which the user sees immediately upon entering the site, includes a

header with the app name and logo, a menu bar that allows users to navigate to the
organization/league menu, to login and to sign up. It also includes a description of the

application so that users know what the function of the application is.

Create and login to an account: New users can create an account using their email address as a

username and a password. Once users have an account, they can login using their username and

password combination.

Create a profile: Under their accounts, users can create a player profile. The profile collects

information including age, years of experience, height, injuries and health restrictions (such as a

heart condition, asthma, bone and muscle injuries, etc.), point per game average (which is

compiled based on the stats from each game the player plays using the app), organization or

league, and a description. Once the player creates the profile, s/he is able to view the profile.
When players view the profile, the player also receives a ranking based on their stats. (The

ranking is used in the calculation of dividing the teams.)

Enter a game: The app allows for users to enter a game, and after the game to enter their scores.

The frontend of the application did not have any difficulties during development. Faiga worked

on the frontend initially because she was unfamiliar with Angular prior to beginning the project

and needed to adjust to the framework.

The API development did have some issues. While the coding itself went smoothly for the most

part, there were some issues getting the API to deploy. The API would run, but it was not

accessible from the outside. After working for the issue for several days, prodding the security

measures and settings, and looking at StackOverflow and Angular forums for similar bugs, we
reached out to a team that works in Angular. They helped us figure out that there was an extra

layer of security on the port that was blocked. Once we changed the settings of that port, the API

deployed successfully. Unfortunately, this issue set us back a few days, but ultimately the API

was completed.

Below is a code sample from the connection to the database:

MongoClient.connect(mongodbURL, function ( e rr, dbConnection ) {

assert.equal(null, err);
console.log("connected successfully to m ongodb server: " + m ongodbURL);
db = dbConnection;
app.set("dbConnection", dbConnection);

/ / create location index in players for latLong to 2d location

v ar playersCollection = dbConnection.collection("players");
p layersCollection.createIndex({"latLong":"2d"});

// Modules that interact with the controllers

// require('./routes/authenticate')(app);
require('./routes/organization')(app);
require('./routes/player')(app);
require('./routes/user')(app);
require('./routes/zipcode')(app);

// Handle 404 issues

app.use(function(req, res, next) {
res.status(404);
res.sendFile(path.join(__dirname, './public', '404.html'));
});

The database of the project is MongoDB. Below is a picture of a working Postman response.
The algorithm works based on a point system. Each category is worth a given amount of points,

with the weightiest category being the points per game scored.

Algorithm calculations:

Age 1-5, with 1 being below 12, 5 being between

20-33, 3 being above 50, 4 being 15-20 and
33-43, and 2 being 12-15

Experience 1-5, with 1 being 0-1 years of experience and

5 being 8+

Height 1-5 based on height curve

Injuries Points detracted if knee or any other leg

injuries are relevant

Points scored 1-15, 15 points given to those who score an

average of 25%+ of team points per game
Below is a chart that details the implementation of the app. Each iteration, we played a game,

and based on the results of the game, we tweaked the algorithm. During the first game, there was

a 23% difference between the two team scores. During the second, there was a 25% difference, a

19% during the third, a 4% during the fourth and a 8% difference during the last.

Conclusion

Roderick Burkhardt and Faiga Revah have created Team Builder, an application that uses

data to create well balanced teams. The application uses individual points scored and other

metrics to determine the skill of each player, and will thusly be able to create fair teams. The

goal of Team Builder is to encourage people to play pickup games, which are crucial to the skills

of athletes. Players who are at a lower skill level are often self-conscious and do not play, which

results in their skill levels remaining stagnant. Team Builder will encourage players by tracking
their progress and ensuring that players have teammates who can help them take part in a fair

game.

The development of the application took place over an eight week period. During the first

five weeks, the developers worked on the interface, designing both the frontend and backend.

The application was created in AngularJS. The frontend used HTML, CSS and JavaScript, while

the backend used NodeJS. The database was MongoDB. The interface went through unit,

integration and backend tests. After the interface was completed, the developers then created a

preliminary algorithm. The application was then given to the clients, who played a game based

on the teams that the application created. After a few iterations of tweaking the algorithm and

testing it on the client, the algorithm was fairly efficient and development was completed.

The project was an excellent cumulative experience for the CSIT degree program. While

collaboration was emphasized throughout the program, the project required an extra focus in that

area. Roderick and Faiga were in constant contact throughout the development. It was helpful to

have a collaborator that complemented each others strengths- Roderick had experience in

AngularJS while Faiga had experience with frontend web development and documentation. We

learned the importance of tracking tools to mark our progress and keep up on task and following

the timeline. We also just how important project management was, and that we cannot just rush

into development without having goals, deadlines and objectives.

In the future, we hope this application is used by leagues worldwide to create teams, and

hopefully helps players build up their confidence in their abilities.

 References

Fain, E., Weatherford, C. (2016). Comparative Study of Millenials (Age 20-34 years) Grip and

Lateral Pinch with the Norms. Journal of Hand Therapy, 29(4). doi:http://dx.doi.org

/10.1016/j.jht.2015.12.006

Rosewater, A. (2009). Organized Sports and the Health of Children and Youth. The Team-Up for

Youth Monograph Series. http://www.teamupforyouth.org. (Accessed August 20, 2017.)

Appendix

Usability Testing/Evaluation Test Plan

Testing will be done locally using mock data for QA testing in the beginning. Once bugs

are minimized we will move to real data collection of players from our client organization. Once

we have enough players in the system we will than start real life testing of the application in an

open gym scope.

Team Member Roles and Division of Work

Roderick Burkhardt and Faiga Revah have teamed up for the development of Team Builder.

Both Roderick and Faiga worked on the application development itself. The majority of Faigas

focus was the frontend development in HTML, CSS and AngularJS, with a smaller focus on the

backend. Roderick focused primarily on the backend development of the application. Both team

members together created and refined the algorithm, and Roderick met with the client

face-to-face and acquired the data. Faiga worked on the majority of the documentation, and both

Roderick and Faiga worked on the video presentation.

Pertinent Websites

San Francisco Gay Basketball Association (client) website: http://www.sfgba.com/home/