Table of Contents Executive Summary 2

Budget and Administration 5.1 Pricing Breakdown, Sponsorship and Time allocation

Download 471.88 Kb.

Page	17/17
Date	31.07.2017
Size	471.88 Kb.
	#25812

1 ... 9 10 11 12 13 14 15 16 17

5.0 Budget and Administration

5.1 Pricing Breakdown, Sponsorship and Time allocation

The system will incur several costs in the course of its development. Since the umpire indicator is being built from scratch, all of the individual parts must be purchased separately, in addition to any services utilized that will fabricate a PCB board for the assembly of all its parts. On the software side of the system, a much larger price will be incurred since all development and testing requires individual computers and testing devices. Development computers and testing devices (both the tablet for the coaching application and the handset for the fan application) must be purchased in order to do any sort of testing to ensure that the system is functional. It is also assumed that the group members do not have a professional level of knowledge needed to produce such a system entirely without reference, so reference materials for coding, database, and hardware design must also be acquired. Additionally, because the system must continue to function beyond its initial development by the design team, a monthly cost to keep the server space that will be needed to maintain the server communication throughout the system. A pricing breakdown of all possible costs that will be incurred can be found on the following page in 5.1 Figure 1.
This project is sponsored and funded by Dr. Peter McAlindon, on behalf of Orlando-area Little League baseball coaches. Dr. McAlindon has agreed to cover costs for software, resource manuals, and hardware devices required in the implementation of this baseball scoring system, as well as providing a means for contacting and interacting with little league coaches in the area, and outlining all basic requirements and improvements within the device design shown in this document in exchange for the intellectual rights of all software and hardware produced for this system. Any additional funding needed for other unforeseen costs may be additionally supplied by local coaches who have been introduced to the system by Dr. McAlindon.

The research and development of this system is to take course over two semesters of the Senior Design course (EEL 4914 and EEL 4915). A majority of the Fall semester was spent defining and researching the needed parts for the proposed system, and eventually developing an initial design. Although design changes will most likely continue until the final product is delivered in May, the second, Spring, semester consists mainly of development, prototyping, and testing. A breakdown of each semester of work is shown on the following pages in 5.1 Figures 2 and 3.

6.0 Conclusion

6.1 Summary

The ultimate goal of this design is to streamline the ease and accessibility of baseball statistical record-keeping, for the coaches and umpires. Additionally, adding a new level of interactivity for the fans via the fan device application would allow spectators of little league games immediate access to new data in ways that have never been done before. This implementation allows coaches more time to focus on their team management, gives umpires the capabilities to make faster and more accurate rulings, and promotes more fan involvedness with new features.

Migrating data and team management from traditional pencil and paper mechanics to a new, faster, efficient electronic system greatly improves not only user friendliness, but consequently also improves reliability and quality of the work being done. Improving this system allows clients access to new abilities that previously were unavailable to them, due to over-complicated requirements, or simply inaccessible formulas which would require too much focus being spent on statistical recording, rather than the game being currently played. This enhanced system gives everyone involved the best of both worlds: Increased statistical capabilities, combined with ease of use, form a system designed around the requirements and needs of little league baseball teams and spectators.

Employing a design focusing on these key elements establishes a new and unique way for clients to interact with the sport, which means all aspects must be easily adaptable by anyone who uses them. The increased accessibility and complexity of mobile devices presented a perfect opportunity to utilize their capabilities for the advantage of little league scorekeeping. Basing the design using these mobile devices, as well as behind-the-scenes data and scoring analysis, provides a seamless upgrade for the clients, which not only simplified the statistical process, but also greatly improved on its potential.

Compressing all of the statistical requirements into a single source of data, the mobile application, reduced the amount of overhead required by the umpires and coaches in applying statistics to their records. Typical scoring sheets previously used by coaches are overly complex and unorganized, requiring much more time and effort to implement.

6.2 Reflection

The specific requirements set forth by the coaches and umpires, as well as the expectations of accessibility by the fans, presents unique design challenges for the application interfaces as well as data management within the system. The rules of the game, specifically the unique rules employed by little league teams, enforce strict requirements from the system, including certain statistical values which must be stored and retrieved accurately, and as timely as possible.

These types of data storage have typically been done manually, via a paper spreadsheet or standard scoreboard. Adapting these record-keeping strategies to electronic technologies, specifically the umpire/coach interface interaction and database optimization, will require new adaptation for anyone involved with the game. The true challenge is creating a system that is easy enough for the coaches, umpires, and fans to adapt to, both in ease of use and adjusting to the new methods of interacting with the game. Naturally, meeting these demands will present a unique challenge, as the system’s design must meet their criteria in all aspects.

In addition to gaining a vast knowledge about the sport of baseball and all facets of baseball statistical data, this design also introduces new conditions regarding interface implementation, data management, and user interactivity. In today’s world, dominated by electronic communications, adapting a complex and dynamic record-keeping service from traditional methods into an electronic realm presents uniquely modern challenges, ranging from data efficiency to interfacing requirements, all layered with expectations of the teams and fans.

The vast spectrum of requirements for this design; mobile development, software development, database management, and hardware design, require a diverse and enveloping knowledge of all aspects of electronic design, all aimed at meeting the demands of the baseball scoring system, while improving on the original design. Improving on these kinds of systems is challenging, and with all the aspects implemented in this design, all of the pieces will need to work together to be capable of handling the scoring requirements of the sport.

6.2.1 Features Left Out

With many optional features being discarded for the initial scoring design, this allows the database structure to be cut down to size as well, as many of these optional features would have also required database entries for storage. Fan input applications, such as average pitch speed calculations and rule debate resolutions, would require many database queries to store and access the multiple data sources for fan input.
Even though the database design currently being implemented meets all of the requirements for scoring functionality, integrating more of the database into online storage or backup would increase stability and data redundancy. This feature has been discarded for time reasons, as it doesn’t directly impact the function of the database or mobile device applications. For long-term use, implementing some extra backups and web integration into the database would boost reliability. Unfortunately this would also increase additional costs to the design, as online services for database have increase costs depending on storage size, accesses, and bandwidth usage. In a more official implementation, these costs could be accounted for by the team, in order to enhance convenience and avoid having to directly control a physical database.
Enhancing the database for future performance is definitely possible, as the structure used to handle and organize data types in this design is less than matured. Extra speed optimizations could be used to control the flow of data in a more precise manner to enhance response times. Additionally, the database in its current state is required to store all data types, even if those types are unused. For smaller-sized little league teams and basic usage, this works fine and provides upgradability for each individual player. Although, ideally, a player could be specifically defined within their roles, which would allow the database to completely eliminate unused fields altogether, until such a time when they are required, on a per player basis. Fortunately, database software such as MySQL and FileMaker Pro already handles these kinds of unused data optimizations, so the impact for this design is less than noticeable under most circumstances.
With respect to the coach application, the bottleneck of features that could be implemented is more or less limited to what the database can handle. Any statistic, picture, feed, etc that could be pulled or added to the database would be relatively simple to just display from the user’s tablet device. That said, it was originally intended that the system would also be able to include live videos of the plays in action. Given that many of the new tablet device that run the android operating system typically have a camera in the device, it was not in the framework or scope of the project to develop a media delivery system or database that could handle such bandwidth or media-intensive activities. The addition of said video would give coaches an addition metric by which to better prepare their own team in addition to studying to play against another. The addition of video upload from the coach application would also increase interest in the fan app. Being able to visually see their children/grandchildren/etc perform in their little league games in almost real time would most certainly increase public interest in the fan application, and most likely increase the marketability likeliness of a user to purchase the fan application.
It was also initially intended to include several features to increase parent involvement during the game. Often times, a parent who attends their child’s games has little indication of what is going on on-field with the lack of an announcer or in depth scoreboard. Although it’s current features will give those fans in depth, easily read coverage of all on-field events, it does not encourage the amount of participation originally intended. For example, one proposed feature was a button that the fans would press upon the ball leaving the pitcher’s hand and release upon it being caught by the catcher. This would be used to give a ballpark figure of pitching speed which although would likely be inaccurate on the individual scale, when averaged with all other fans who are participating with this feature can likely provide a pretty accurate figure. Another feature that was left out was the initial design of player lookup section of the fan application. Originally, it was intended to show information returned on an individual player in the form of a baseball card that would be populated with an uploaded image of the player in addition to all of their basic information on the front of the card. If a user were to click on the front of the card it would flip over and the user would be able to see the more in-depth statistics similar to what is already on the back of many MLB player cards. This was let out due to a lack of graphic resources.
6.2.2 Future Improvements
6.2.2.1 Umpire Indicator

The current umpire device fully realizes the existing umpire indicator. This does not mean though that the umpire indicator designed in this project cannot be improved upon. The Bluetooth module used in this design of the handset is essentially operating in a one-way design. For the Bluetooth device to be able to pair with more than one device at a time the device has to be placed into command mode. This mode only allows data to flow in one direction to the coach tablets. The reason this method was chosen was to allow no dongles or extra equipment to have to be installed in a secondary computer not needed for the design or to have the dongle hanging out of one or both of the tablets. Having a dongle plugged into the coaching tablets is unsafe because it could be broken and does not look as professional as if nothing was there. In a later design the Bluetooth module could be replaced by a better module that did properly pair with more than one device in a two-way data transfer method. Another option to implement this is to make the umpire device have cellular data transferring abilities installed that allow it to transmit data to and from the device over a 3G network.

The current method of powering the device is with standard alkaline batteries. For the first version of this device it is helpful to have batteries that are widely available. But this design could be improved upon by implementing a battery source that lasted longer and was rechargeable for the convenience of the umpires that have to use this device and the cost savings of no longer having to buy costly 9V batteries. One available option is to switch to NimH batteries that both have more mAh and are rechargeable. This would allow a charging port to be installed in the device and the battery compartment would no longer have to be opened.
Version one of the digitized umpire indicator does succeed in being within the size requirements of our design for this project. This device is still bigger than the current umpire indicator however. Shrinking version two of the umpire indicator would aid in usability and promote umpires to switch to the new digital indicator type if the new device was more closely dimensioned to the device they currently use. Version two of the umpire device can change the circuitry internally to a smaller non-designer soldered type of component and have the components all surface mounted. This would greatly reduce the size of the needed PCB area and could shrink the dimensions of the device considerably. To make the device more ergonomic and not a rectangular box like version one of the design a curved PCB design could be custom fabricated for a more ergonomically designed case.

6.2.2.2 Coach application

Future improvements would include everything pertaining to this portion of the system mentioned in section 6.2.1 Features left out. The addition of video to the entire system would provide much more interest in prospective users and investors as the capabilities to use such technology is rapidly improving, especially with many cell phone networks introducing high-speed cellular networks that rival residential cable modems. Additionally, there are several smaller additions that were simply outside the scope and resources of this project. The User Interface screens could have used the work of a professional graphic artist to give a sleeker look in addition to a cohesive style throughout both the coach an fan applications. The addition of sound effects and animations while navigating through the many user interface screens would also.
Another feature that this version of the system lacks is the ability to input all of a particular game’s information in the event that the coach on the other team is not using the system. The that is implementing the system will not suffer much in the form of data loss since nearly all of the information for a team is input while they are at bat, it is still a discrepancy that partially limits the completeness of all the information that could be recorded during a particular game.

6.2.2.3Fan Application

There are a few features that if implemented in the future may improve usability and interest in the fan application portion of this system, the first of which being a layout overhaul by a graphic artist. Since none of the group members had explicit experience with creating graphic assets for a computer application, the interfaces used are rudimentary and not as sleek as potentially possible had the group utilized someone with graphic arts capabilities. Similarly adding something as simple as sound effects for the changing of interface screens or in the event that a run is scored would really increase the production quality of the application, however the group did not have the skills or facilities to implement such features.
There are a few extra additional improvements that could be made on the information side of the application as well. In its current form, the fan application does not have the ability to show some of the in depth team information that will be available to the coaching application simply because of the difficulty to display large groups of information on a device with such a small screen, but the addition of this information would afford fans an even larger breadth of information about their favorites players and teams. The fan application could take fan participation even further by including a fantasy league feature in which users could create their own fantasy team and follow the season similar to what is currently offered to fans of other major sports leagues.

6.2.2.4 Database

The database must be self-sufficient, however it’s unreasonable to expect that none of the clients would ever want to manually access or control the database directly. To that end, the database was implemented with some directly viewable user interface designs. These designs work for viewing and managing some data, but do not provide an overall customizable database experience for the clients. As with the structural optimizations, these limitations are acceptable for little league usage, as the clients require less expansive statistics and summaries, so all data they require can be pre-programmed into the database from its original state. In more complex scenarios, the clients may want to add or modify these statistics and how they are stored, to better meet their teams’ needs. This is inherently possible with any database structure, unfortunately the user interface design to promote these changes isn’t currently implemented. Having more control over these data types and statistics could be a crucial factor for more involved teams, and designing an interface to facilitate that customization would be necessary for their desires.

Little league teams may only require a small sample of baseball statistics to be recorded, as their needs are less complex than other types of baseball teams. As such, some of the more complex baseball statistics have been excluded from the database, if only for the sole purpose of enhancing response times and structural organization. These intricate statistics are more calculation-heavy and require more basic statistic types which are difficult for coaches and umpires to manage during games. The device applications already require the clients to manage their inputs effectively, so the data values will constantly be up to date and accurate. The more complex data, such as fielding statistics, require multiple players’ data to be simultaneously monitored, which in little league settings is virtually impossible due to client limitations. To that end, these impossible statistics have not been implemented into the database at all. Putting these new variables into the design would require new database fields, as well as average calculations (depending on the statistics themselves), and new interfacing updates for the mobile applications.

For data control within the database, including data backups and game data control, the database can be designed such that it automatically creates and manages game backups at the beginning and ending of each individual game. This refers to actual database control, since each game is its own independent database. Coaches may choose to manage these scheduled events more directly, as they may have personal requirements for how the data needs to be moved, stored, and backed up. For a functional design, these kinds of personal controls are not required for the database to do its job.