ACBLscore+ Evaluation ACBL conducted a thorough review of ACBLscore+ in April of 2014. The project team came together for a three-day kick-off event, the stated purpose of which was to perform a gap analysis of the March 2014 ACBLscore+ deliverable. More specifically, the stated objectives were:

1. Define where the development of ACBLscore+ stood in relation to the *Functional Requirements*. (Attached) 2. Define the usability of ACBLscore+. 3. Define the viability of the ACBLscore+ architecture within the constraints of the functional requirements.

To tackle the first objective, a more detailed list of functional requirements had to be created. In particular the first functional requirement was not sufficient to conduct an analysis of what was complete or incomplete in ACBLscore+.

The first version of the new version shall have essentially the same functionality as the current version unless explicitly stated otherwise in this document. It is not expected that the functionality shall be implemented in the same way. It is not feasible to document the entire functionality and business logic embedded in the existing version of ACBLscore therefore the source code (~200,000 lines of code) is considered to be the definitive set of requirements. Prior to the kickoff meeting a small team of ACBL Employees set out to clearly define the first item on the list of *Functional Requirements*. It was known that ACBLscore+ would handle many of the tasks performed by ACBLscore differently, but the group still needed a basis of comparison between ACBLscore and ACBLscore+ functionality. The team defined ACBLscore functionality by documenting ACBLscore commands. The goal was not to hold ACBLscore+ to this command list, but instead to verify that core ACBLscore functionality was replicated. Unfortunately, the group found that much of the anticipated functionality was lacking from ACBLscore+.

The group was left with the following challenge: How can we best critique the usability and viability of a program that is so largely incomplete? Our solution was to create an installer for ACBLscore+ and to develop a prototype based on the configuration and toolset of ACBLscore+.

The ACBLscore+ Installer ≈ $32,000 A big part of determining the usability and viability is ensuring the program can be packaged into an installation file. In March 2014 ACBL brought on a web developer with expertise in Stack configuration and deployment, Ruby on Rails and LAMP to better understand the configuration and server-install process of ACBLscore+. Using the instructions provided by Hammond Software on the ACBLscore+ Wiki, he was able to get a version running locally on his PC, and on a server. ACBL then turned over the development of the install package to a second developer with more experience creating installation packages in April 2014. The developed install package runs on Windows XP/7/8. It has an installed footprint of 1800 MB, and once packaged and compressed is 658 MB. The total cost of the development for the install package was approximately $32,000.

The Prototype ≈ $79,000 At the end of the gap analysis meeting, the team concluded that the ACBLscore+ did not have a proper workflow function to allow us to walk through a basic sequence of game function. We built the prototype to evaluate ACBLscore+ and answer questions such as what would it look like if it worked? How would it perform in the intended personal web server? How would it perform on hosted server environment? The Prototype was developed because it was a necessary conclusion of a thoughtful and well-reasoned assessment of ACBLscore+.

The work done for the prototype has been broken out into four different areas. The TourneyTRAX & ACBLscore Classic Integration piece has been used for other projects that are currently in use, and was therefore not written off. The total cost of the Prototype was approximately $79,000

Development ‐ Web App, DB & Server ≈ $13,000 The prototype uses a personal web server configuration and was written using Ruby-on-Rails to demonstrate the functional behavior proposed at the end of gap analysis. This was not meant to be an ACBLscore+ replacement.

The Prototype steps through a sectional tournament from start to finish. A big part of any ACBLscore replacement is tight integration with existing systems at ACBL HQ, and in our opinion this integration had to be proven. The prototype does the following:

• Retrieves data from HQ helpful and/or necessary for tournament and event setup • Allows the user to set-up any number of events, sessions and sections that include a standard, skip or bye-relay Mitchell as the movement • Scores the section, session and event • Calculates and assigns for a stratified event

Prototype Installer Creation ≈ $9,000 An installer was created for the prototype which contains the full sequence of installation proposed by Ruby-on-Rails (ACBLscore+). The purpose of the installer is to demonstrate how a user can install a full package of a Ruby-on-Rail program on a personal computer.

Planning ≈ $24,000 Plan, design, and manage the process of this prototype period.

TourneyTRAX & ACBLscore Classic Integration ≈ $33,000 This area of integration work includes several key components that were already in development. The prototyping work included developing capabilities in TourneyTRAX that was intended to be part of ACBLscore+. We also built some extended features to use TourneyTRAX data to populate ACBLscore automatically. The developed work for TourneyTRAX and data population has been used for ACBL Live in production today.

Functional Requirements

Prepared by Nicolas Hammond

1. The first version of the new version shall have essentially the same functionality as the current version unless explicitly stated otherwise in this document. It is not expected that the functionality shall be implemented in the same way. It is not feasible to document the entire functionality and business logic embedded in the existing version of ACBLscore therefore the source code (~200,000 lines of code) is considered to be the definitive set of requirements. 2. The new version is not required to support the macro capability in the DOS version of ACBLscore. The new version is not required to support Duplicate Spades. 3. The new version is required to support the external scoring devices (e.g. Bridgemate/Bridgepad) that are currently supported in the Windows version of ACBLscore. Initial implementation must match current functionality however future releases would be expected to use more information from the wireless scoring systems 4. It may be acceptable to delay certain functionality (e.g. individual tournaments, tournament financial reports) if this will significantly speed up delivery of the first release of the new version. The new version must eventually support these features 5. The new version will run on a minimum of Windows and MAC OS. It is NOT required to run under DOS. 6. The new version will run on Microsoft Windows 7. This includes both the 32 bit and 64 bit versions. 7. Although not required, it is highly desired that the new version will also run on Windows XP with SP2 and Windows Vista. There should be a very good reason for introducing a feature that only runs on Windows 7 and not XP/Vista. There is no requirement to support older versions of Microsoft Windows though there are a large number of users that current run ACBLscore on these versions 8. The new version will run on Mac OS 10.6.8 and later versions. There is no requirement to support older versions of Mac OS. This requirement may change to only requiring support for Lion (Mac OS 10.7) and later 9. The new version shall be designed so that it is relatively easy to port to other operating systems, for example, Linux or to run on tablets, e.g. iPad. There is no requirement for initial support for anything other than Windows or Mac OS 10. As much as possible, configuration files shall be shared between different operating systems. This means use of ‘standardized’ configuration files rather than registry settings (Windows) or plist files (Mac OS). A preferred solution is XML configuration files (or similar), or something that can be easily copied between different operating systems 11. Lots of clubs run ACBLscore on old laptops that have limited memory and limited size. Within reason the new version should still run on those systems, albeit slower than systems that meet the minimum configuration. 12. The minimum hardware configuration for the new version will be 512Mb RAM. However, if during development it is found that more memory is required this number may be increased but to no more than 1GB. 13. The minimum screen size is 800x600 however the new version should be designed for a typical minimum screen size of 1024x768 14. The minimum configuration for a Mac to run Snow Leopard (10.6) is 1Gb of memory, 1.6Ghz processor. The requirements for the new version should be the same as the minimum for the supported operating system on a Mac. 15. The new version should support the vast majority of printers that are in use today, including all the printers in use at ACBL tournaments, providing that those printers are supported by the native operating systems 16. Within reason, all printers that are supported by the native operating systems shall be supported to the extent that the native operating system 17. The new version shall support the same wireless scoring systems as ACBLscore. At a minimum the scoring function shall be supported. Some of the wireless scoring system ACBL implementation was based on how ACBLscore worked. This functionality is changing, therefore it cannot be expected that the same functionality would be supported in the new version (example: player data ). 18. Subsequent versions (but not the first) of the new version shall support the ability for future wireless systems to be relatively easily supported. Thus all design for support for wireless scoring systems shall be abstracted with the intention that an API can ultimately be provided. This is outside the scope of the first version. 19. The new version must run in a standalone mode, i.e. not connected to the Internet. 20. The new version should be designed in a modular fashion 21. The new version is expected to last 15+ years. Although it is impossible to predict computer systems in the future, decisions should always be made to ensure future support. This includes the choice of programming language, development environment etc. 22. A SQL database shall be used for storing the majority of the data. Any specific SQL product used shall be abstracted as much as is reasonable so that it can be changed for a different SQL database at a later date. For example, all calls to an SQL/Relational database shall be put into a library as much as possible. It should be easy to replace a key component (a specific database) as much as possible. 23. To minimize costs, the new version should not contain any software that requires a license fee