Team music within



Download 120.96 Kb.
Date29.01.2017
Size120.96 Kb.

FUNCTIONAL SPECIFICATIONS REV. 0.95 PAGE

TEAM MUSIC WITHIN





University of Portland

School of Engineering Phone 503 943 7314

5000 N. Willamette Blvd. Fax 503 943 7316

Portland, OR 97203-5798





Requirements and Functional Specifications

Project Hands-Free Sheet Music



Team Members:

Chelsea Colvin (Fall Team Lead)

Andrew Tanasse (Spring Team Lead)

Cori Goya



Industry Representatives:

TBD


Faculty Advisor:

Tanya Crenshaw



Other Contributors:

Rick Broussard (Consultant)


Revision History

Rev.

Date

Author

Reason for Changes

0.1.0

19 Sep 2011

C. Colvin

Requirements and Milestones

0.1.1

19 Sep 2011

A. Tanasse

Use Cases and Development Process

0.1.2

19 Sep 2011

C. Goya

Ethical Considerations, Environmental Specifications, and Preliminary Budget

0.9.1

21 Sep 2011

C. Colvin

Compiled assigned sections into first draft and added Introduction

0.9.2

21 Sep 2011

C. Colvin

C. Goya


Revised Introduction; added block diagram; reformatted tables

0.9.3

21 Sep 2011

C. Colvin

Added Conclusion

0.9.3.1

22 Sep 2011

C. Colvin

C. Goya


Added Table of Contents, List of Figures, and List of Tables

0.9.3.2

23 Sep 2011

C. Colvin

C. Goya


A. Tanasse

Added Revision History and Development Process flow chart; made revisions based on feedback from faculty advisor

0.9.3

23 Sep 2011

A. Tanasse

Revised General Approach

0.9.4

24 Sep 2011

C. Goya

Revised Ethical Considerations

0.9.4.1

24 Sep 2011

C. Colvin

Added System Architecture and Component Details

0.9.5

24 Sep 2011

C. Colvin

C. Goya


A. Tanasse

Edited System Architecture and Component Details; added more Milestones

0.95.0

26 Sep 2011

C. Colvin

Fixed typos; edited sentences on cover page, pages 7, 11, and 13

0.95.1

26 Sep 2011

C. Colvin

C. Goya


A. Tanasse

Updated Development Process Diagram and Preliminary Budget; edited Milestones and Ethical Considerations

0.95.2

30 Sep 2011

A. Tanasse

Updated Development Process text

0.95.3

01 Oct 2011

C. Colvin

C. Goya


Replaced figures; updated glossary; edited Use Cases

0.95.4

01 Oct 2011

C. Colvin

C. Goya


A. Tanasse

Updated Budget; edited figures captions; minor editing for grammar and verbosity



Table of Contents

Introduction 6

Requirements 7

Overview 7

A – Application 8

B – Platform 8

C – Pedal Device 8

Environmental Specifications 9

General 9

Temperature 9

Liquid Exposure 9

High-Level Design 10

Component Details 10

Application Shortcut 10

Main Menu 11

Import New Sheet Music 12

Read Sheet Music 13

Organize Music Sets 14

Application Directory 14

Use Cases 15

Use Case 1 - Turn on the Tablet 15

Use Case 2 - Downloading the Application Online 15

Use Case 3 - Launch the Sheet Music Application 16

Use Case 4 - Importing .pdf files 16

Use Case 5 - Flipping Pages left/right with foot pedal device 17

Use Case 6 - Flipping pages left/right with touch screen 18

Use Case 7 - Creating Organized Sets of music 18

Use Case 8 - Discover Bluetooth pedal device 19

Use Case 9 - Turn off the Tablet 19

Development Process 21

General Approach 21

Assumptions 22

Ethical Considerations 22

Milestones 22

1 – Foot Pedal Device Decision 23

2 – Android Tablet Decision 23

3 - Functional Specifications Version 0.95 24

4 – Obtaining the Android Tablet 24

5 - Functional Specification Approved 24

6 – Complete Initial Prototyping with Wired Peripheral 24

7 – Purchase/Obtain Wireless Foot Pedal Device 24

8 – Simple Pedal Device Prototype 24

9 - Final Budget Set 24

10 - Design Document Version 0.95 24

11 - Design Document Approved 24

12 – Software Prototype I Complete 25

13 – Software Prototype II Complete 25

14 – Android Application Complete 25

15 – Application and Device Interfacing Complete 25

16 – Application and Device Testing Complete 25

17 - Final Report Version 0.95 25

18 - Final Report Approved 25

19 - Project Presentation 25

20 - Final Report Approved 26

Risks 26


Trouble with getting the tablet app to talk to the device 26

The pedal device breaking 26

Learning curve for developing an Android app 27

Scheduling to meet as a team 27

Team member absences 27

Team member commute status, especially for freezing weather 27

Android Emulator is not compatible with our machines 27

Resources 28

Personnel 28

Preliminary Budget 28

Equipment 28

Facilities 28

Conclusions 30

Glossary and References 31




List of Figures


List of Tables


Introduction


The purpose of this functional specification document is to define the Hands-Free Sheet Music project for the stakeholders listed on the front cover. The document details the project’s requirements, components, use cases, development process and milestones, ethical considerations, business assessment, risks, and resources.

Many musicians require the use of both hands for playing their instruments, thus making it difficult to flip through sheet music while performing. Also, there is the danger of losing sheet music while flipping between pages.

Hands-Free Sheet Music is an Android application, which will display .pdf sheet music on a tablet screen. A wireless pedal device will interface with the application, and be controlled by the musician’s feet. The application will feature the option of organizing pieces of music into sets of music for playing sequentially from piece to piece.

The project will enable musicians to flip through sheet music without the use of their hands while playing their instruments. The pedal will be wireless to prevent problems with tangling on stage, or accidently pulling the tablet off the stand by tripping over a cord. The organized music sets will enable a performance to be played from beginning to end without switching out books or sheet music.



Requirements

Overview


Figure 1 is a mockup of how the project will appear to the user when in use during a performance.mockup_official.jpg


Figure - Mockup of the finished project. Image adapted from www.manhasset-specialty.com, www.pageflip.com, www.acer.com, and www.classical-sheet-music.eu

D

Team Music Within plans to create a tablet application that will interface with a wireless foot pedal device to enable musicians to flip through sheet music on a tablet without using their hands. This application will display music, enable the user to create organized sets of music for sequential use, and flip pages forwards and backwards based on commands from the pedal device. Figure 2 below is a block diagram of the project components.




    1. Application

    2. Platform

    3. Pedal device



The application interfaces with the platform

.


The platform interfaces with the pedal device

B. A



Figure - Block Diagram of the Project
C.

The user will interact with the application by interfacing with the tablet screen to organize music sets and choose music for display. The user can then tap the pedal to flip between music pages, leaving both hands free for playing the musical instrument. If the pedal is absent or malfunctions, the music pages can still be flipped by tapping the tablet screen.


A – Application


  • The app must be able to handle .pdf files only, to display pages of sheet music, and to interface with the pedal device to turn pages (back and forth).

  • The response time between pressing the physical pedal and the music actually flipping must be less than 1.0 second.

  • The app must be able to organize sets of music to enable sequential performance of different pieces of music without hand interactions. The user can then flip through these sets.

  • The .pdf files used must not be of poor quality or unreadable in order for the app to be useful.

B – Platform


  • The platform chosen for the app to run on is Android, which the user operates on an emulator or a physical device.

  • The device must have good visibility, a large screen (10.1 or larger), good battery life (5 hours or more), and low weight (less than 2 lb.).

  • The device must have a USB port for wired prototyping, and Bluetooth built-in for wireless interface.

  • The user must be able to pick up the device with one hand.

C – Pedal Device


  • The pedal device must be wireless for safety reasons.

  • The pedal device must be Bluetooth enabled in order to interface wirelessly with the application.

  • The pedal device must have at least two pedals, one to advance the sheet music forward and the other to advance the sheet music backward.



Environmental Specifications


Table 1 contains a list of the environmental specifications and their required values.

Table - Environmental Specifications



Requirement

Value




Acer tablet

Pedal

General

Conventional

Conventional

Temperature

32-104°F

32-140°F

Liquid Exposure

None

None

Each of the sections below describes the individual specifications in more detail.

General


Both devices are designed to operate under normal conditions. The user should be careful because mishandling them could result in significant physical damage.

Temperature


Acer Tablet: The battery cannot charge in temperatures that are below 32°F and exceed 104°F. In order to preserve the lifetime of the battery, it is recommended that the battery remain at a temperature between 59-77°F and not exceed that of 140°F.

Pedal: The foot pedal can operate in temperatures within the range of 32-140°F and should be stored within -4-140°F.



Liquid Exposure


Neither device should be cleaned with or exposed to any liquid as it might leak into the devices internal hardware and cause severe damage.


High-Level Design


This section describes the design of Hands-Free Sheet Music at the component level.

The menus are designed for interaction through the touch screen, with the hands-free option available only when actually reading the sheet music.


Component Details

Application Shortcut


Figure 3 below shows a mockup of how the application shortcut will appear to the user within the tablet app menu.


Figure - Application Shortcut Within App Directory. Image adapted from www.computershopper.com
acer-iconia-tab-a500-apps-from-computershopper.com_with_sheetmusicapp.jpg


Hands-Free Sheet Music Shortcut

The user will open the application by going to the tablet’s app menu, and tapping on the shortcut button.



Main Menu


Figure 4 below shows a mockup of how the main screen will appear to the user and the options available on this menu.main_menu.jpg

btsiglogo.gif


Figure - Main Menu Screen, with options to Import New Sheet Music, Organize Music Sets, Read Sheet Music, or Quit the application. Image adapted from www.acer.com, www.bluetooth.org, background designs by Charyn Colvin

The Main Menu will be displayed every time the user opens the application by choosing the app shortcut from the tablet. The user will make a selection from the main menu by tapping the appropriate button on the touch screen. The Quit button will allow the user to leave the application, and go back to the Android app menu screen.



Import New Sheet Music


Figures 5 and 6 below shows a mockup of how the Import New Sheet Music screens will appear to the user if chosen off the main menu.main_menu.jpgmain_menu.jpg

Senior Design


Church Orchestra
MYS
Band Concert
Classical

Classical

William Tell Overture

Toccata & Fugue in Dm

Barber of Seville

Serenade in D major



Are you sure you want to import this file?

YES NO




Figure - Import New Sheet Music Screen, Android OS File Browser, folders in tablet memory. Image adapted from www.acer.com, background design by Charyn Colvin



Figure - Import New Sheet Music Screen, Android OS File Browser, files within folders in tablet memory. Image adapted from www.acer.com, background design by Charyn Colvin

The .pdf sheet music files must already be loaded into the tablet memory. The user will select the sheet music to be imported using the Android OS file browser. Once the file is selected, and the selection is confirmed by the user, a copy of the file will be saved in the application directory. The user can then choose to go back to the main menu, or import another file.



Read Sheet Music


Figures 7 and 8 below shows mockups of how the Read Sheet Music screens will appear to the user if chosen off the main menu.read_sheet_music_page.jpgos_file_browser.jpg


Figure - Android File Browser will appear, allowing the user to choose the music to view. Image adapted from www.acer.com, background design by Charyn Colvin

Figure - Read Sheet Music screen, the user can now view the music. Image adapted from www.acer.com and www.classical-sheet-music.eu

The screen in Figure 6 displays a list of files in the application directory that can be opened. Once a file is selected, the screen in Figure 7 appears, displaying the sheet music to be played.



Organize Music Sets


Figures 9, 10, and 11 below shows mockups of how the Organize Music Sets screens will appear to the user if chosen off the main menu.os_file_browser_over_workspace.jpgworkspace.jpgorganize_music_sets_menu.jpg


Figure - Android File Browser will appear when the user taps the Add Another File button in Figure 10. Image adapted from www.acer.com, background design by Charyn Colvin

Figure - Organize Music Sets Menu. Image adapted from www.acer.com, background design by Charyn Colvin

Figure - Workspace for Creating Music Sets. Image adapted from www.acer.com, background design by Charyn Colvin

The Organize Music Sets Menu in Figure 9 will give the user the option to either edit a file, or to create a new set made from copied files from the application directory. The copied files will be reorganized, given new page numbers, and be combined into one single .pdf file that will contain a set of music pieces. Figure 10 shows the OS file browser for the user to download files into the workspace seen in Figure 11. The workspace will allow the user to move pages around into the desired order before saving the set.


Application Directory


The application directory will be created within the tablet memory when the application is first downloaded. This will be the only directory from which the user can choose sheet music to display. Both imported .pdf files of sheet music and the organized sets of music will be stored here.

Use Cases

Use Case 1 - Turn on the Tablet


Primary Actor: User

Goal in Context: Access Application Functionality

Preconditions: Working power source (battery, power adapter); functional tablet

Trigger: User wishes to use the Sheet music app

Scenario:

  1. The user presses the power button.

  2. Tablet successfully loads the OS and boots to home screen

  3. Tablet is in a secure and safe position


Exceptions:

  1. The tablet hardware is defective

  2. OS fails to post/load

  3. User cannot locate the power button


Priority: High

Frequency of use: Every use of the tablet

Channel to Primary Actor: Direct physical manipulation to tablet

Use Case 2 - Downloading the Application Online


Primary Actor: User

Goal in Context: Download the application for use

Preconditions: Connection to internet; the app has not been previously downloaded

Trigger: User does not have Hands-Free Sheet Music app on their tablet

Scenario:

  1. User visits Music Within homepage

  2. Application is downloaded from site

  3. Application is available for use


Exceptions:

  1. User does not have a connection to the internet


Priority: High

Frequency of use: Once

Channel to Primary Actor: Tablet internet browser

Use Case 3 - Launch the Sheet Music Application


Primary Actor: User

Goal in Context: Open the Hands-Free Sheet Music app

Preconditions: Android tablet is already on; Hands-Free Sheet Music app is already downloaded; user wishes to use app

Trigger: User wishes to use Hands-Free Sheet Music app

Scenario:

  1. User navigates to application shortcut (see Figure 3)

  2. User clicks the icon to launch application

  3. Application home screen/menu appears


Exceptions:

  1. Application is not downloaded

  2. OS fails to launch app


Priority: High

Frequency of use: Once every application use

Channel to Primary Actor: Android OS

Use Case 4 - Importing .pdf files


Primary Actor: User

Goal in Context: Import .pdf file of sheet music into application directory

Preconditions: Hands-Free Sheet Music application is active; sheet music is a .pdf format; .pdf file already located within Android device memory; application directory is already downloaded specifically for application

Trigger: User wishes to import new sheet music

Scenario:

  1. User goes to main menu (see Figure 4)

  2. User clicks button to select option to import sheet music

  3. OS file browser comes onto display (see Figures 5 and 6)

  4. User navigates to desired sheet music file within Android device directories

  5. User selects file and saves a local copy of it into application directory


Exceptions:

  1. Selected file is not in .pdf format

  2. File is corrupt

  3. File is moved out of application directory; application is not responsible for tracking a file if it is moved out of the specific directory


Priority: High

Frequency of use: When new music needs to be imported

Channel to Primary Actor: Hands-Free Sheet Music app

Use Case 5 - Flipping Pages left/right with foot pedal device


Primary Actor: User

Goal in Context: Flip a page with the wireless foot pedal device

Preconditions: Pedal device is visible to tablet/app; pedal has source of power

Trigger: User wishes to flip page hands free

Scenario:

  1. User goes to main menu

  2. User selects the option to read a sheet music file

  3. User selects sheet music file from list of files to display (see Figure 7)

  4. 1st page of selected sheet music is displayed (see Figure 8)

  5. Appropriate pedal is depressed

  6. Page is turned to the corresponding direction once


Exceptions:

  1. Pedal device is not powered

  2. Pedal device is not discoverable by tablet

  3. User does not have a pedal device


Priority: High

Frequency of use: Every time a page needs to be turned (high)

Channel to Primary Actor: Wireless foot pedal device

Use Case 6 - Flipping pages left/right with touch screen


Primary Actor: User

Goal in Context: Flip the page with touch screen gestures

Preconditions: Tablet touch-screen is functional; recommended pedal device is not available

Trigger: User wishes to flip the page

Scenario:

  1. User goes to main menu (see Figure 4)

  2. User selects the option to view a sheet music file

  3. User selects sheet music file from list of files to display (see Figure 7)

  4. 1st page of selected sheet music is displayed (see Figure 8)

  5. User extends hand to touch the screen

  6. User taps left side of screen to turn page backwards

  7. User taps right side of screen to turn page forwards

  8. Page will turn once in appropriate direction


Exceptions:

  1. Tablet touch screen is non-functional


Priority: High

Frequency of use: Occasionally

Channel to Primary Actor: Tablet touch screen interface

Use Case 7 - Creating Organized Sets of music


Primary Actor: User

Goal in Context: Create an organized set of music for sequential viewing

Preconditions: Music has been imported into application

Trigger: User wishes to automatically flip through multiple pieces of music

Scenario:

  1. User selects option to create new set of music (see Figure 9)

  2. Workspace appears on the screen, initially blank (see Figure 10)

  3. User selects the option to add a file to the workspace (see Figure 10)

  4. User selects the desired files to be edited/combined (see Figure 11)

  5. User drags-and-drops the files into desired order (see Figure 10)

  6. User approves selection, and selects the Save button (see Figure 10)

  7. Set is saved as a new single .pdf file


Exceptions:

  1. User has selected invalid files

  2. User has selected files that have been moved from the application directory


Priority: High

Frequency of use: Occasionally

Channel to Primary Actor: Hands-Free Sheet Music app

Use Case 8 - Discover Bluetooth pedal device


Primary Actor: User

Goal in Context: Manually discover Bluetooth pedal device for use with application

Preconditions: Powered foot pedal device; tablet is powered on; Bluetooth is manually enabled

Trigger: User wishes to discover foot pedal device for use with application

Scenario:

  1. User goes to Main Menu (see Figure 4)

  2. User chooses the option to open Bluetooth menu (upper right corner)

  3. User finds foot pedal device

  4. Foot pedal device is recognized as a valid input device


Exceptions:

  1. Tablet Bluetooth hardware is faulty

  2. Pedal device’s Bluetooth hardware is off

  3. Tablet fails to locate pedal device


Priority: High

Frequency of use: When pedal device is not readily visible to tablet

Channel to Primary Actor: Android OS

Use Case 9 - Turn off the Tablet


Primary Actor: User

Goal in Context: Turn off the tablet

Preconditions: Tablet is on; use of tablet is no longer required

Trigger: User desires to turn off tablet

Scenario:

  1. User locates the power button

  2. The power button is depressed for the appropriate amount of time

  3. Tablet successfully powers off


Exceptions:

  1. User is unaware of how to turn off tablet


Priority: High

Frequency of use: Once per session

Channel to Primary Actor: Physical manipulation of device

Development Process

General Approach


Process of design and implementation of this Android Application and interfacing with a wireless peripheral will proceed in a step by step process. Our first goal will be to have a wired peripheral device talk to the Android tablet. Next, this same test program will be tested again but with the wireless foot pedal device. From here basic features of the application will be implemented such as a Main Menu, page flipping for one file and a functional GUI as part of a first software prototype. A second prototype will allow for the creation of music sets with the Organize Sheet Music and Import New Sheet Music menus completed. A completed Android application will be built on these two prototypes and will subsequently be tested for interface compatibility. Concurrently throughout the development process there will be testing of not only code but wireless communication and the feasibility of implementing our secondary requirements as seen in Figure 12. Before Founder’s Day there will be a cut-off for testing and modifications to the project.


Figure - Development Process Diagram

The Fall Team Lead is Chelsea Colvin. The Spring Team Lead is Andrew Tanasse. The overall scope of implementation will be dependent on the completion of primary functional requirements. Secondary and tertiary goals will only be considered for implementation after the primary requirements have been satisfied.


Assumptions


Assumptions that are required for project Hand-Free Sheet Music to be successful:

  • Computer Science department has budgeted funds to purchase a Tablet PC for this project’s development.

  • Musical stands will be able to support a tablet PC during application use without concern for stand failure or user clumsiness.

  • Wireless communication will be a feasible feature to the pedal implementation. Getting the tablet to talk to a Bluetooth foot pedal will be a manageable task.

  • Application deployment will be early enough to allow for testing with musicians.

  • The pedal will be durable enough to withstand program/device testing. This assumption is more critical depending on whether the pedal is off-the-shelf or custom built.

Ethical Considerations


Issues to consider with this project include the potential misuse of the devices and facilitation of illegal file downloading. If the user fails to properly handle the device it could harm the user or others.  The application created for this project will use PDF sheet music files that can be uploaded from a computer. The major ethical concern is the source of these files because they can be illegally obtained from Internet websites. If that is the case, this project has the potential to condone the illegal act of downloading these files.

Milestones


Table 2 below lists the milestones in the order that they will occur, and are followed by a detailed description of what each milestone is and the completion criteria for each milestone.

Table - Milestones



Number

Description

Completion Date

1

Foot Pedal Device Decision

September 23, 2011

2

Android Tablet Decision

September 23, 2011

3

Functional Specifications Version 0.9

September 30, 2011

4

Obtaining the Android tablet

September 30, 2011

5

Functional Specification Approved

October 7, 2011

6

Complete Initial Prototyping with Wired Peripheral

October 28, 2011

7

Purchase/Obtain Wireless Foot Pedal Device

November 4, 2011

8

Simple Pedal Device Prototype

November 12, 2011

9

Final Budget Set

November 12, 2011

10

Design Document Version 0.95

November 19, 2011

11

Design Document Approved

December 3, 2011

12

Software Prototype I Complete

January 27, 2012

13

Software Prototype II Complete

February 17, 2012

14

Android Application Complete

March 9, 2012

15

Application and Device Interfacing Complete

March 23, 2012

16

Application and Device Testing Complete

April 6, 2012

17

Final Report Version 0.95

April 6, 2012

18

Final Report Approved

April 13, 2012

19

Project Presentation

April 17, 2012

20

Final Report Approved

April 20, 2012



1 – Foot Pedal Device Decision


The team is expected to make a decision on a foot pedal. Team Music Within decided to purchase the PageFlip Cicada, a Bluetooth foot pedal device.

2 – Android Tablet Decision


Team Music Within makes a decision about which Android tablet to purchase. The team decided on the Acer Iconia TAB A500.

3 - Functional Specifications Version 0.95


The Functional Specification is expected to be at Version 0.95 on September 30, 2011. This means that it has been approved by Team Music Within’s faculty advisor, and been sent to the team’s industry representative.

4 – Obtaining the Android Tablet


Team Music Within physically obtains the purchased Android tablet.

5 - Functional Specification Approved


The Functional Specification is expected to be approved by both the faculty advisor and the industry representative by October 7, 2011. The document is now considered complete.

6 – Complete Initial Prototyping with Wired Peripheral


The team will complete testing to insure that the application responds to the wired peripheral.

7 – Purchase/Obtain Wireless Foot Pedal Device


The team orders a wireless foot pedal device and receive it by November 4, 2011.

8 – Simple Pedal Device Prototype


The team will complete testing to insure that the application responds to the wireless foot pedal device.

9 - Final Budget Set


The Final Budget is expected to be set by November 12, 2011. This accounts for all costs associated with developing the application and the pedal device. The development tools are free, and a tablet will be purchased outside of the team, but the testing pedal device and parts for a new pedal device will be purchased within the team’s budget.

10 - Design Document Version 0.95


The Design Document is expected to be at Version 0.95 on November 19, 2011. This means that it has been approved by Team Music Within’s faculty advisor, and been sent to the team’s industry representative.

11 - Design Document Approved


The Functional Specification is expected to be approved by Team Music Within’s faculty advisor and industry representative by October 7, 2011. No further changes or revisions will be made.

12 – Software Prototype I Complete


  • The application shortcut is operational, and can be used to access the Main Menu Screen

  • The Main Menu screen (Figure 4) has one functional button.

  • A piece of music can be displayed through the Read Music Option button and the flipping functionality is implemented. (Figure 8)

13 – Software Prototype II Complete


  • The application can access more than one file in its file directory

  • Sets of music can be created

  • Import New Sheet Music and Organize Music Sets buttons are functional (Figures 5, 6, 9, 10, and 11)

14 – Android Application Complete


The whole software package is complete for the Android application.

15 – Application and Device Interfacing Complete


The wireless foot pedal device successfully talks to the completed Android application.

16 – Application and Device Testing Complete


This is the cut-off date for testing the device.

17 - Final Report Version 0.95


The Final Report draft of Hands-Free Sheet Music is expected to be ready to be submitted for approval by Team Music Within’s faculty advisor by April 6, 2012.

18 - Final Report Approved


The Final Report is expected to be approved by Team Music Within’s faculty advisor and industry representative by April 13, 2012.

19 - Project Presentation


Team Music Within is expected to give its final presentation on Founders Day, April 17, 2012, at the University of Portland, demonstrating Hands-Free Sheet Music in front of other senior design teams and industry representatives.

20 - Final Report Approved


The Final Report of Hands-Free Sheet Music is expected to be approved by both Team Music Within’s faculty advisor and industry representatives by April 20, 2012.

Risks


The risks that Team Music Within could come across are listed in Table 3.

Table - Project Risks and Contingencies



Risk

Severity

Likelihood

Trouble with getting the tablet app to talk to the device

High

Moderate

The pedal device breaking

High

Low

Learning curve for developing an Android app

High

Moderate

Scheduling to meet as a team

High

Moderate

Team member absences

Moderate

Low

Team member commute status, especially for freezing weather

Moderate

High

Android Emulator not compatible with our machines

High

Low


Trouble with getting the tablet app to talk to the device


A major concern is the problems that may occur when trying to get the tablet application to talk to the pedal device. If clear communication does not occur between the app and the pedal, the project will not be fully hands-free, thus defeating the purpose of the project. Our plan to prevent these problems includes (a) making sure the tablet recognizes external devices, and (b) extensive Bluetooth testing with a purchased pedal while coding the app.

The pedal device breaking


Another concern is that the pedal, purchased or customized, might break after extensive testing. Our plan is to (a) make sure that the purchased pedal is saved as a back-up in case the customized one breaks right before Founder’s Day presentation, and (b) that the application works with touch screen inputs as well in case both pedals are broken.

Learning curve for developing an Android app


A moderate risk is that the team, including the main developer (Chelsea Colvin), has not had previous experience in coding for Android applications. Our plan for overcoming this is (a) begin coding early, (b) read documentation about Android, and (c) getting other resources for help.

Scheduling to meet as a team


Because of different class schedules, the team has difficulties meeting all together during the school week. Our methods of preventing this becoming a major problem are (a) meeting regularly at least once or twice a week at the same time, (b) dividing up the work so that the team members can work independently on parts, and as a whole team in other parts, and (c) communication and file sharing on the team’s Basecamp account.

Team member absences


Since we are a three member team, meetings with the entire team present are important for preventing workload imbalances. We plan to account for team member absences by (a) clear communication between all members, and (b) making sure that each member has an understanding of each part of the entire project to make sure no one person becomes indispensable as resource should an absence occur.

Team member commute status, especially for freezing weather


One of our team members has an hour-long commute to campus. As the weather becomes cooler, there is a higher chance that the team member might be stuck at home due to freezing weather and road hazards. We have compensated for this by (a) making sure wireless communication can continue between team members despite bad weather, (b) giving that team member a heavy portion of coding which can be done from the team member’s home computer, and (c) having the team member have other housing options should freezing weather be forecasted in time.

Android Emulator is not compatible with our machines


A software concern is whether the Android Emulator is compatible with our machines, including our home computers and school computers. We will try to mitigate this concern by testing the emulator early and often.

Resources

Personnel


Team Music Within consists of three personnel with the following responsibilities:

  • Chelsea Colvin – Coding the App, Fall Team Lead

  • Andrew Tanasse - Communication between devices, Making the devices talk to each other, Spring Team Lead

  • Cori Goya – Hardware, Pedal Development


Preliminary Budget


The main component Table 4 contains a list of the materials and software that need to be purchased.

Table - Preliminary Budget



Line

Category

Description

Number

Rate

Amount



















1

Materials




# of parts




Subtotal

1.1




PageFlip Cicada

1

$80

$80

1.2




Arduino Mega ADK

1

$80

$80

1.3




Bluetooth Shield

1

$20

$20

1.4




Miscellaneous Parts

TBD

$20

$20

2

Software













2.1




Android Development Tools








2.2




Eclipse














TOTAL







$200


Equipment


Team Music Within will be using Android Development tools and Eclipse to code the application. We will also be purchasing a wireless pedal device for testing. The equipment we will need for building an actual pedal has not yet been determined.

Facilities


Team Music Within will need the engineering workshop room and the computer science room offered to seniors for their team projects.

Conclusions


The goal of Hands-Free Sheet Music is to enable musicians to perform without the hassle of physically flipping pages of sheet music. End users will be able to perform without worrying about sheet music flying off the stand, and will be able to continue playing from piece to piece in sets of music.

With a pedal device, a tablet running Android OS, and the Hands-Free Sheet Music application, musicians will be able to perform their instruments with fewer sheet music problems, and more efficiently.



Glossary and References


.pdf (Portable Document Format) – file format created by Adobe Systems to display files to be viewed outside of software programs, hardware, or operating systems
OS (Operating System) – a set of programs that manages computer hardware resources, and provides common services for application software
Android Emulator – a virtual mobile device that runs on your computer, and lets you develop and test Android applications without using a physical device
Eclipse – a multi-language software development environment that comprises an integrated development environment (IDE) and an extensible plug-in system


GUI (Graphical User Interface) – user interface that allows users to interact with electronic devices with images rather than text commands


UNIVERSITY OF PORTLAND SCHOOL OF ENGINEERING CONTACT: CHELSEA COLVIN



Download 120.96 Kb.

Share with your friends:




The database is protected by copyright ©ininet.org 2020
send message

    Main page