Page 1 of 61

Mobile SMIL in the Cloud Software Requirements Specification ver. 1.0 03/18/11
For the

2.6

Project Team 5
Keith Brown, Adil Khan, Hans Hagen, Jim Neilan, Ted Landis

Page 2 of 61

Table of Contents
1.
1.1. 1.2. 1.3.

Document Information .4
Prepared by Document responsibilities Revision history

2.
2.1. 2.2. 2.3. 2.4. 2.5.

Introduction..5
Purpose Scope Definitions, acronyms, and abbreviations References Overview

3.
3.1. 3.2. 3.3. 3.4. 3.5.

Overall description7
Product perspective Product functions User characteristics General constraints Assumptions and dependencies

4.
4.1.

Specific requirements.10
External interface requirements 4.1.1. 4.1.2. 4.1.3. 4.1.4. 4.2. 4.2.1. 4.2.2. 4.2.3. 4.3. 4.4. 4.5. 4.6. User interfaces Hardware interfaces Software interfaces Communication interfaces Functional requirements Overall activity diagram Use case diagram Detailed activity diagram Performance requirements Design constraints Software system attributes Other requirements

5.
5.1. 5.2.

Project management35
Project estimation Risk assessment

6.

Future system improvements...37

Appendix: ..38
1. 2. 3. Task partition Work schedule (MS Project) Weekly meeting agenda and minutes

Page 3 of 61
4. 5. Other communication records Software configuration management

1.

Document information

Page 4 of 61

1.1.

Prepared by

This SRS document was prepared by the members of CSC 540 Team # 5: Keith Brown Adil Khan Hans Hagen Jim Neilan Ted Landis

1.2.

Document responsibilities

Document creation responsibilities are as follows: Sections: 1 - Adil Khan 2 - Ted Landis, Jim Neilan, Adil Khan, Hans Hagen 3 - Keith Brown 4 - Adil Khan, Hans Hagen, Keith Brown, Ted Landis 5 - Jim Neilan 6 - Keith Brown Appendix - Jim Neilan

1.3.

Revision history
Version 0.5 0.8 0.9 1.0 File Name Team5_SRSv0.5.doc Team5_SRSv0.8.doc Team5_SRSv0.9.doc Team5_SRSv1.0.doc Team5_SRSv1.0.pdf Date 03/05/11 03/10/11 03/13/11 03/19/11

2.
2.1.

Introduction
Purpose

Page 5 of 61 The product in this document is referred to as the Mobile SMIL Application. Its purpose is to allow an end user to build and share SMIL messages on the Android mobile platform. A subset of the SMIL specification is to be implemented. Furthermore, all resources such as audio, video and images are to be hosted in the cloud. For this project the Google App Engine cloud service is to be used. This SRS covers the SMIL Composer, SMIL Player applications, as well as the CloudDataProvider and SmilTransporter libraries. Following are descriptions of each in Version 1.0 of the application:
o o o

SMIL Composer: Application running on Android to create the SMIL message. Features user friendly UI to build the SMIL message and share with other users. SMIL Composer: Application running on Android to play a SMIL message. CloudDataProvider: Library running on android to allow the SMIL Composer to save/load resources from the Cloud. In the case of the Player, to allow to download resources from the cloud. SmilTransporter: Library to allow the SMIL Composer to send SMIL messages via XMPP to devices running the SMIL Player application.

2.2.

Scope

The Mobile SMIL Application is being developed for the Software Engineering class at Northern Kentucky University during the Spring 2011 semester. The application is being built to cement software engineering principles amongst the participating students. Furthermore, the absence of robust SMIL applications on mobile platforms has provided impetus for developing an application to fill this need. Android has been chosen as the mobile platform since it is freely available and the familiarity of the developers with the Java programming language. In addition to mobile computing, another benefit of this application is to expose students to cloud computing. The Google App Engine has been chosen as the cloud data store, mainly for the libraries available in Android that interface with the Google App Engine

2.3.

Definitions, acronyms, and abbreviations

SDK Software Development Kit - A set of development tools that enable a developer to create applications from a pre-designed software framework. SRS Software Requirements Specification. A specification document that outlines a software projects intent, deliverables, cost, project schedule, framework, and team member communications and roles.3

Page 6 of 61

Emulator A software package that mimics the hardware functionality of a given platform. Used for testing and development of solution applications. SMIL Synchronized Multimedia Integration Language. An EXML markup language for describing multimedia presentations, defining layout, timing, audio and visual information. Composer The SMIL message creation environment on the mobile hardware platform. Player The SMIL message playing environment on the mobile hardware platform. Com/Comm - Communications XML Extensible Markup Language. Rules for encoding documents in a machine-readable format. Used for internet data layout fro web forms, applications, and user environments. Simple XML A high performance XML serialization and configuration framework for Java platforms. Offers full object serialization and de-serialization, maintaining each reference encountered. Http Hypertext Transfer Protocol. A networking protocol for distributed, collaborative information system. WWW communications framework. SVN Subversion and revision control system. Recorded current and historical versions of files, source code, web pages, and other documentation. Also used for document control, merging, verification, and release stages in SDLC. SDLC Software Development Life Cycle. Imposed structure for the development of a software product. UML Unified Modeling language. An object modeling and specification language used in software engineering. Use Case Diagram Part of UML. Diagram that depicts behavioral aspects of a software packages functionality. Depicts users (actors) and main functional aspects of a products interface. Activity Diagram Part of UML. Diagram depicting software product workflows in stepwise fashion. Used to describe stepwise components of a system.

Page 7 of 61

(Google) App Engine Cloud computing environment that always developers and uses to run web applications on the Google infrastructure. Supports apps written in several programming languages. Google Corporation that begin in 1996 as a graduate project search engine software package. Supplies web searching, cloud computing, software development, and computing research. Cloud, Cloud Computing Computation, software, data access, and storage services, not requiring end user knowledge of location nor configuration for mass distribution and usage. Typically described as an IT service model for enabling convenient, on-demand network access to a shared pool of computing resources. MS Project Microsoft Project. Software packaged supplied by Microsoft corporation for scheduling, task assignment, and resource tracking for project planning and tracking. (Google) Android A Google supplied operating system designed for mobile computing devices. Architecture built on top of a slim Linux kernel and using Java and C++ APIs. An open source Operating System for Mobile application development Mobile Device A handheld embedded computer, having a display screen with touch input and/or miniature keyboard/pen device for mobile computing and telecommunications.

2.4.

References

[1] Wikipedia Reference Website http://en.wikipedia.org

[2] Simple XML Website http://simple.sourceforge.net/ [3] Google Corporate/Android Development/App Engine http://code.google.com/appengine/ [4] Project Descriptions and Definitions Notes via Black Board for CSC 540, taught by Dr. Wei Hao.

2.5.

Overview

The remainder of this document is four sections, the first, section 3, provides a full description of the product for the customers. It lists all the functions, user characteristics,

Page 8 of 61 assumption, and general characteristic of the SMIL in the Cloud product. The next section is section 4. It concerns details of each of the system requirements for the software developers. After section 4, section 5 deals with information for the Project Manager. It documents the project schedule and the risk involved with the project. Finally, section 6 lists all improvements that will be added in the future. These four sections are cross-referenced by topic; to increase understanding by all groups involved.

3.
3.1.

Overall description
Product perspective

This project is to be developed to bring SMIL (Synchronized Multimedia Integration Language) to the mobile world. There are several players available for desktop environments, but there is a general lack of support for mobile environments. The initial target for this product is going to be the Android operating system. To reduce data transfer and storage requirements for messages multimedia files [i.e. images, music, and video] will be stored on a cloud server. The Goggle App Engine is the target platform for the cloud services. App Engine was chosen, because of its scalability and compatibility with Android. Integration with Google accounts can be implemented easily, as well as ad based revenue for future.

There are two major components to the application, the mobile application and the cloud server. The cloud server is a JAVA web application running on Google App Engine. The mobile application is an Android app that needs to run on two or more Android devices. The cloud server will store the multimedia files used in the messages. It will provide a list of content stored in the cloud when requested. It will serve up image files and audio and video streams to the players when requested. It will upload multimedia files from the composer when they dont already exist in the cloud. All communication will be HTTP. The mobile app consists of two major parts, the composer, which creates and sends the message, and the player that interprets the message and plays the appropriate media. The composer gets a list of files from the cloud and a list of multimedia files local to the machine. These files can then be used to construct a message. When the message is saved if any of the

Page 9 of 61 files used are not in the cloud they will be uploaded to the cloud. The message can then be sent to another Android device to be played. The message will be sent via XMPP to the other Android device. The player, the other portion of the mobile app will be invoked anytime a message is to be played. If a message is received the player will interpret it, and the necessary resources will be requested from the cloud. The message will be displayed / played on the main device display, and any sound will play from the current active audio output.

3.2

Product Functions

Through the composer the user will create multimedia presentations using a combination of local A/V files and text, and A/V files stored in the cloud. These messages will contain some combination of audio, video, images and text. The audio, video, and image files will be stored in the cloud. The path to these files, the layout, as well as the scheduling of their playing / displaying and any text will be encoded into SMIL and sent to another device running a SMIL player via XMPP. The cloud will provide an XML encoded list of the files and their type to the composer. The cloud will upload new files from the composer. The cloud will serve image files to the player. The cloud will provide streams for audio and video files to the player. The composer will provide a simple and intuitive GUI interface for designing the message layout as well as a built in player to demo the message before sending it. The player will provide functions to play, stop, and pause the playback. There will be a progress slider to show progress of the message.

3.3. 3.3.1

User characteristics Message Author / Sender

Using the composer on an Android device the author will combine various components to create a multimedia message. Eventually this user class will be required to have a Google account to access the composer functionality. This user class is expected to have minimal technical expertise, with moderate familiarity with the platform the composer is running on. This is the favored user class. This will be the prime mover for usage of the application as well as the driver of ad-based revenue. If no one creates a message, no one will view a message. The ease of use of the composer UI is paramount to the success of this application.

3.3.2

Message Receiver

Page 10 of 61 The Message Receiver is expected to have a basic skill level. Playing a message should be trouble free and intuitive.

3.3.3

Administrator

The Administrator is a power user and a member of the team. The lowest priority is given to this class. Technical skill is expected to be high, and any consideration is to streamline the process of administering the server for efficiency.

3.4.

General Constraints

The use of the App Engine vs. a private server limits us to http protocol for submitting requests for files, streams, and uploading files. The use of the blob store service is required for large multimedia files. Security is a concern to minimize risk to liability any one who uploads files will be required to have an account and will only be able to access their own files.

3.5.

Assumptions and dependencies

The Google App Engine, the Simple XML library, and Android 2.3 operating systems will be required for this project.

4.
4.1.

Specific requirements
External interface requirements User Interfaces 4.1.1

There are two main components that will operate on the mobile device. The Composer and the Player. The Players purpose is to receive and play SMIL messages, whereas, the composer is designed to create SMIL messages that include, audio, video and text. Below are Screen shots that describe these modules.

Page 11 of 61

Figure 4.1: Application Entry Screen

Page 12 of 61

Figure 4.2: Send a Message via sms or xmpp and Open an existing message

Page 13 of 61

Page 14 of 61

Figure 4.3 : Edit message and preview message screens. The canvas area of the screen allows users to drag around the elements to position/re size them according to the users needs.

Page 15 of 61

Figure 4.4: Stages to compose a SMIL message, includes adding the Video, Audio, Image and Text components. The canvas area of the screen allows users to drag around the elements to position/re size them according to the users needs.

Page 16 of 61

Figure 4.5: Player UI screens, the main screen for the Player and the Play Message Screen. The canvas area of the screen displays the SMIL message.

4.1.2 Hardware Interfaces

Page 17 of 61 The hardware in the production product will be an Android powered device such as an Android phone or Tablet. The cloud functionality is provided by the Google App Engine (GAE).

Figure 4.5: Overview of the SMIL message passing application.

A user with the composer application on her tablet/phone will create a SMIL message using a variety of images, audio, video and text. Once composed the message is sent to another user for viewing the message. All resources are saved to the cloud using the Google App Engine. The receiving users SMIL message has the resource URLs embedded within the SMIL to download the resources from the Google App Engine. Following are the list of hardware requirements:
o Client Device should be capable of internet connectivity, such as WIFI, 3G,

Wired connection. o For 3G Connections Cellular service provider account required o Device should be able to run Android 2.3 or higher. o Device should have Sound, and Video Capability. o Touch Screen interface required (Capacitive touch screen with multi touch gestures supported)

4.1.3 Software Interfaces

Page 18 of 61

Figure 4.6: Component diagram describing the software interfaces.

Figure 4.6 describes the required software interfaces. The Composer and the Player are separate applications that communicate with the cloud using the CloudDataProvider library. Messages composed by the composer are sent to other devices using the SmilTransporter library that interfaces with the underlying Android XMPP library.

4.1.4 Communications Interfaces

Figure 4.7: Component diagram describing the communication interfaces.

Page 19 of 61 Communication Protocols used:

o Http for uploading and downloading resource files (images, video, audio) o XMPP for sending SMIL messages from composer devices to player devices

4.2.

Functional requirements

This section outlines the overall activity diagram, use cases diagrams, and detailed activity diagrams for each of the separate sections of the SMIL in the Cloud project. The separate sections are as follows; SMIL Composer, Data Communication, Cloud Interaction, and SMIL Player.

4.2.1.

Overall activity diagram

Cloud Interaction

SMIL Composer

SMIL Player Data Communication Figure 4.2.1

4.2.2.

Use case diagram SMIL Composer use case diagram

4.2.2.1

Page 20 of 61

Use case Name: Create Message Diagram:

CreateMessage

Participating actors: User Entry condition: In SMIL Composer App. Exit condition: Save message or Close. Flow of Events: User opens composer. 2. User selects to add text, image, audio, or video. 3. User selects where to get resources. 4. User sets position of selection. 5. User sets timing of selection. 6. User repeats selection process until message is composed. 7. User saves or closes message. Special Requirements: Access to media.
1.

Page 21 of 61

Use case Name: Save Message Diagram:

SaveMessage

Participating actors: User Entry condition: Message has been created. Exit condition: Message saved. Flow of Events: User has created message. 2. Data Com replies save success or failure. 3. User clicks OK. Special Requirements: Access to media.
1.

Use case Name: Open Message Diagram:

MessageNotFound Open Message SelectFile

Participating actors: User and Data Com Entry condition: User has entered message list screen. Exit condition: Moved on to play message or close message and return to message list. Flow of Events: Data Com has a clean message. 2. User Selects message from list.
1.

Page 22 of 61 User Presses Open button. 4. User Presses plays or closes message. Special Requirements: Data Communication has a message and message is not corrupt.
3.

Use case Name: Preview Message Diagram:

MessageNotFound Preview Message SelectFile

Participating actors: User and Data Com Entry condition: User has entered message list screen. Exit condition: Moved on to play, edit, or close message. Flow of Events: Data Com has a clean message. 2. User Selects message from list. 3. User Presses preview button. 4. User Presses play, edit or close message. Special Requirements: Data Communication has a message and message is not corrupt.
1.

Use case Name: Edit Message Diagram:

Page 23 of 61

MessageNotFound Edit Message SelectFile

Participating actors: User and Data Com Entry condition: User has message open or previewed. Exit condition: Moved on to saved or closed message. Flow of Events: User has message opened or previewed. User Selects edit message. 3. User edits message in composer mode. 4. User Presses save or close message. Special Requirements: Data Communication has a message and message is not corrupt.
1. 2.

Use case Name: Send Message Diagram:

MessageNotSentError Send Message SelectFile

Participating actors: User and Data Com Entry condition: User has entered message list screen. Exit condition: Message sent no error. Flow of Events:
1.

User selects message from message list. 2. User selects send message button. 3. Data Com sends conformation that message is sent. 4. User returns to message list screen.

Page 24 of 61 Special Requirements: Data Communication has sent a message and message is not corrupt.

4.2.2.1 Data Communication use case diagram (Data Com)

Use case Name: Save File Diagram:

Participating actors: SMIL Composer Entry condition: Saving Composed Message. Exit condition: No Duplicate File Exception thrown. Flow of Events:
1.

SMIL Composer requests to save media files.

2. Save confirmed no Duplication File Exception thrown. Special Requirements: No Duplicate Files. Use case Name: Get File Diagram:

Page 25 of 61

Participating actors: SMIL Composer, SMIL Player Entry condition: Composing or playing a message. Exit condition: Files received no exceptions thrown. Flow of Events:
1.

SMIL Composer or SMIL Player requests to get media files.

2. Files received, no exceptions thrown. Special Requirements: Network connection and existing files.

Use case Name: Get File List Diagram:

Participating actors: SMIL Composer, Cloud Entry condition: Composing message browse files on cloud. Exit condition: File list received no exceptions thrown. Flow of Events: SMIL Composer requests to get media file list. 2. File list received no exceptions thrown. Special Requirements: Network connection.
1.

Page 26 of 61

Use case Name Upload File Diagram:

Participating actors: Cloud Entry condition: Request for file upload. Exit condition: Upload is successful, no exception thrown. Flow of Events: Cloud Uploads a file. 2. File uploaded no exceptions thrown. Special Requirements: Network connection and no duplicate files.
1.

Use case Name Download File Diagram:

Participating actors: Cloud Entry condition: Request for file download. Exit condition: Download is successful, no exception thrown. Flow of Events: Cloud downloads a file. 2. File downloaded no exceptions thrown. Special Requirements: Network connection and file found.
1.

Page 27 of 61

4.2.2.3

Cloud Interaction use case diagram

Use case Name: Upload File Diagram:

Upload File

Participating actors: Data Com Entry condition: Mobile phone has data connection. Exit condition: Upload complete or exception thrown. Flow of Events: Data Com sends HTTP request. 5. Data Com Request upload URL 6. Data Com receives upload URL. 7. File is uploaded. Special Requirements: None.
4.

Use case Name: Get Files Installed Diagram:

Page 28 of 61

Get Files Installed

Participating actors: Data Com Entry condition: Mobile phone has data connection. Exit condition: XML received or exception thrown. Flow of Events: Data Com sends HTTP request. 4. Data Com Request Requests Map 5. Map Processed to XML. 6. Data Com receives XML response via HTTP. Special Requirements: None.
3.

Use case Name: Play/Download File Diagram:

Play/Download File

Participating actors: Data Com Entry condition: Mobile phone has data connection. Exit condition: File is streamed, downloaded, or exception thrown. Flow of Events: Data Com sends HTTP request. 2. Data Com Request stream to video/audio and download to image. 3. Data Com receives download URL. 4. File is downloaded. Special Requirements: None.
1.

4.2.2.4

SMIL Player use case diagram

Page 29 of 61

Figure 4.2.2.4.1

Use case Name: Receive Message Diagram:

Receive Message

Participating actors: User and Data Com Entry condition: Mobile phone is turned on and has found a clean message. Exit condition: Moved on to Message list screen or close message notification. Flow of Events: User has phone on. 2. Data Com received a clean message. 3. Data com posts a notification of new message. 4. User closes notification or move to message list screen. Special Requirements: Data Communication has found a message and message is not corrupt.
1.

Page 30 of 61

Use case Name: Open Message Diagram:

Open Message

Participating actors: User and Data Com Entry condition: User has entered message list screen. Exit condition: Moved on to play message or close message and return to message list. Flow of Events: Data Com received a clean message. 6. User Selects message from list. 7. User Presses Open button. 8. User Presses plays or closes message. Special Requirements: Data Communication has found a message and message is not corrupt.
5.

Use case Name: Play Message Diagram:

Page 31 of 61

Play Message

Participating actors: User and Data Com Entry condition: User has opened message. Exit condition: User stops, pause, or closes message. Flow of Events: User selects play button. 2. User selects stop, pause, or close button. Special Requirements: Data Communication has found a message and message is not corrupt.
1.

Use case Name: Pause Message Diagram:

Pause Message

Participating actors: User and Data Com Entry condition: User is playing message. Exit condition: User stops, resumes, or closes message. Flow of Events: User selects pause button. 2. User selects stop, resume, or close button. Special Requirements: Data Communication has found a message and message is not corrupt.
1.

Page 32 of 61

Use case Name: Resume Message Diagram:

Resume Message

Participating actors: User and Data Com Entry condition: User is pausing message. Exit condition: User stops, pauses, or closes message or end of message. Flow of Events: User selects resume button. 2. User selects stop, pause, or close button or end of message. Special Requirements: Data Communication has found a message and message is not corrupt.
1.

Use case Name: Stop Message Diagram:

Stop Message

Participating actors: User and Data Com Entry condition: User is playing or pausing message. Exit condition: User plays or closes message.

Page 33 of 61 Flow of Events: User selects stop button. 2. User selects play or close button. Special Requirements: Data Communication has found a message and message is not corrupt.
1.

4.2.2.5

Message Sending Mobile to Mobile Use Case

(Data Com)

Use case Name: Send Message Diagram:

Participating actors: SMIL Composer Entry condition: Saved and selected a message, send button pressed. Exit condition: Confirmation of message sent. Flow of Events:

Page 34 of 61 SMIL Composer has a saved created message. 2. SMIL Composer has a selected message to send. 3. SMIL Composer sends message. 4. SMIL Composer receives sent message confirmation. Special Requirements: None.
1.

Use case Name: Receive Message Diagram:

Participating actors: SMIL Player Entry condition: Mobile phone has network connection and message was sent. Exit condition: Message is received and saved. Flow of Events: SMIL Player receives message. 2. SMIL Player saves message to message log. Special Requirements: Mobile phone has network connection.
1.

4.2.3.5

SMIL Transporter (Data Com) activity diagram

Page 35 of 61

4.2.3.

Detailed activity diagram

Page 36 of 61

4.2.3.1

SMIL Composer activity diagram

Page 37 of 61

4.2.3.1

Data Communication activity diagram

Page 38 of 61

4.2.3.3

Cloud Interaction activity diagram

Page 39 of 61

4.2.3.4

SMIL Player activity diagram

Page 40 of 61

4.3.

Performance requirements 4.3.1 SMIL Composer

Responsive to user user requests should be preemptive maintaining fluid response for user. Resource loading should be done on background threads to minimize impact to user. Any process that does make the user wait should have a progress indicator. Gracefully handle unavailable resources (notify user) o XMPP o Cloud

4.3.3 Cloud Media Store

Scalable from 1 to 1,000 concurrent users with a 2 sec response time. Storage available for up to 100,000 users at an average of 5 GB per user. 99.5% Uptime for Application.

4.4.

Design Constraints 4.4.1 Software Design Constraints 4.4.1.1 Composer / Player

Android operating system 2.3 simpleXML package for XML creation / reading CSC-440/540 coding standards JAVA DOCS coding standard Timing of player and player synchronization 250 ms

4.4.1.2 Cloud Media Store

Google App Store CSC-440/540 coding standards JAVA DOCS coding standard Blob Store Interface

4.4.2 Hardware Design Constraints

Page 41 of 61

Android application should be compatible with any Android system with a sufficient API level [10] that has Internet connectivity and XMPP capability. Cloud hardware is independent of the system and is outside the scope of this document.

4.5.

Software system attributes

Cloud should have a 99.5% availability Software should be compartmentalized for maintainability Android app should be reliable and stable with 99.99% availability.

4.6.

Other requirements
Security other users should not be able to access a given users media files. Unless it is to view them as a recipient of a message. [This is for a later release see Section 6]

5.
5.1.

Project management
Project estimation

The Mobile SMIL in the Cloud team project has been broken into 5 distinct sections covering the entire project from conception to termination. The schedule breakdown was estimated by determining the major tasks of each step. The steps are as follows: Conception Definition Start Steady-State Termination

Component assignments were then determined via the skills assessment sheet found in section 1 of the appendix. The Each task or task set was estimated given the due dates of the software specifications document and the expectation that 3 prototypes would be needed in order to test functionality and help learn and identify gaps in the multiple modalities used for the project.

Page 42 of 61

5.2.
Risk
Cloud Connectivity

Risk assessment
Risk Type
Medium

Risk Likelihood
Low High

Impact

Mitigation Strategy
Ensure testing and validation prior to demonstration Back up dev phones for demo. Continue to update project schedule and ensure targets are met Ensure testing and validation by 04/04 Team review 04/04 Ensure proper error recovery and restart for demo. Ensure proper error recovery and restart for demo. Ensure proper error recovery and restart for demo. Have PC and/or dev phone back ups ready for demo Monitor input during weekly team meetings and adjust engagement appropriately.

Emulator Failure Prototype delay in integration of components SMIL Parser fails Simple XML integration problems Composer touch creation failure Playback from cloud failure Message send/receive failure Composer video / emulator failure Team member lack of work

Medium Medium

High Medium

Medium Medium

High Low Medium

Low Low Low

High High Low

Medium

Low

High

Medium

Low

Medium

Medium

Medium

High

Medium

Low

High

Page 43 of 61

6.

Future system improvements

E-Mail Support to send SMIL messages - Support to send messages via E-Mail SMS Support to send SMIL messages - Support to send messages via text messaging. Fast Forward and Rewind of playback - Add Fast Forward and Rewind to player functionality. Google account support / requirement for composer functionality - This will be needed to better control content uploading, and to only allow the user who uploaded the content to link to it. Ad revenue / Composer purchase - To support the project and repay investors. Port to iPhone windows mobile - New clients developed using the same cloud service. Additional SMIL support - Incremental increase in the amount of SMIL tags that are supported until SMIL is fully supported. Administrative cloud console for usage tracking, banning, and deletion of inappropriate content.

Appendix:

Page 44 of 61

1.
Who Role

Task partition
Skills and Assessments XML: Advanced J2ME: Basic iPhone Prg: None MS Mobile Prg: Basic Android: Advanced OOP: Intermediate Multithreading: Intermediate Networking: Intermediate GUI: Intermediate XML: Basic J2ME: None iPhone Prg: None MS Mobile Prg: None Android: None OOP: Intermediate Multithreading: None Networking: Basic GUI: Intermediate Languages Java: Advanced C++: Advanced VB: Advanced C#: Advanced IDE: Eclipse GAPS Email

Keith Brown

Architect Cloud Connectivity Documentation

ferret70@gmail. com

iPhone Java: Intermediate C++: Intermediate VB: Advanced IDE: MSVS

Hans Hagen

SMIL Player XML Parsing Documentation

iPHone Android Multithreadin g J2ME MS Mobile Phone Prg

hans.p.hagen@ gmail.com

Adil Kahn

Http Communications Documentation

XML: Advanced J2ME: Basic iPhone Prg: Basic MS Mobile Prg: Basic Android: Intermediate OOP: Advanced Multithreading: Basic Networking: Basic GUI: Basic

Java: Advanced C++: Basic ObjectiveC: Basic IDE: Eclipse

khana2@nku.e du

Ted Landis

Composer Simple XML Documentation

XML: Basic J2ME: Intermediate iPhone Prg: None MS Mobile Prg: None Android: Basic OOP: Intermediate Multithreading: Basic Networking: Basic GUI: Intermediate

Java: Advanced C++: Basic C#: Basic IDE: Eclipse

landis1@gmail. com
iPHone J2ME MS Mobile Phone Prg

Page 45 of 61
XML: Basic J2ME: None iPhone Prg: None MS Mobile Prg: None Android: None OOP: Intermediate Multithreading: Basic Networking: None GUI: Intermediate Java: Intermediate C,C++: Advanced VB: Intermediate Ruiby: Basic Python: Basic IDE: MSVS, Eclipse, Netbeans

Jim Neilan

Project Documentation Composer GUI Main App GUI

J2ME iPhone MS Mobile Prg Android Networking

jimbolysses@gmail .com neilanj1@nku.edu james.neilan@tem a.toyota.com

Page 46 of 61

2.

Work schedule (MS Project)

Page 47 of 61

3.
When and Where Date: 1/19 Start: 9:00 P.M. End: 9:20 P.M. Room: ST 254

Weekly meeting agenda and minutes

Role Primary Facilitator: Hans Hagen Timekeeper: Ted Landis Minute Taker: Adil Khan Attending: Hans Hagen, Keith Brown, Ted Landis, Adil Khan, James Neilan.

1. Objective Objective was to finalize the software tools, platforms and versions to use for the completion of the Mobile SMIL in the Cloud project. The roles and responsibilities of the team members was also discussed. 2. Status Role for Project Tracking tool maintainer was finalized to be James. Team members discussed knowledge and progress for the tools/platforms to be used in the project. API /versions finalized.

3. Discussion James agreed to be the caretaker of the Project Management tool, MS Project. Keith to setup the SVN repository and documentation on the google code project site. Hans to familiarize with the site and eclipse tools. Keith has set up the code.google.com site. The app engine account and also shared information about the app engine plugin for eclipse. Ted mentioned some issues he had installing android on his development system. Hans expressed need for reading/training with the android development tools Keith recommended we need to start working on the requirements Adil to look for and recommend UML eclipse plugin. Hans wants to decide if Team leader /liaison should be the same person Keith recommended we use the code site to share documentation The team agreed to do the final demonstration using the Emulator with the latest version of the android sdk: 2.3 (Gingerbread) New meeting time of Tuesdays at 7pm was agreed to. 4. Wrap up Action Items:

Page 48 of 61 When and Where Date: 1/25 Start: 7:00 P.M. End: 7:30 P.M. Room: Student Lounge Keith to explore svn plugin Adil to explore eclipse uml plugin James to share MS Project files. Members to create USE CASE Diagram for project requirements. Adil to get meeting minutes out by Sunday. Role Primary Facilitator: Ted Landis Timekeeper: James Neilan Minute Taker: Hans Hagen Attending: Hans Hagen, Keith Brown, Ted Landis, Adil Khan, James Neilan.

1. Objective The Purpose of this meeting was to formulate Use Case documentation of the project.

2. Status 2.1 Jim: Created first draft of Gantt chart for meeting discussion. 2.2 Keith/Adil: Continued work on SVN Repository. More testing is needed. 2.3 Hans: Created formal version of Use Case diagram for meeting discussion.

3. Discussion 3.1 Ted: SVN link up issues. More testing is needed. 3.2 Keith: Lead discussion on using Use Case diagram to divide up project into parts to be prototyped by team members. 3.3 Jim: Used Gantt chart to help the division of project for prototyping. 3.4 Adil: wanted to work on process flow of the project. Keith thinks is better to prototype portions of the project before we discus process flow. Team agrees. 3.5 First draft of project breakdown as discussed by team is as follows: 3.5.1 Jim and Ted to develop prototype of Android GUI for composer 3.5.2 Keith to set up Cloud space

Page 49 of 61 3.5.3 Adil to develop prototype of interface between the cloud, the composer and player. 3.5.4 Hans to develop prototype of Android GUI for player 3.6 Jim supplied new resource for programming in Android: The Android Developers Cook Book 3.7 Hans: Set meeting roll rotation as follows: Hans, Ted, Adil, Jim, and Keith

Move up in rotation (Next Week): Facilitator: Adil Minute Taker: Jim Timekeeper: Keith

Week after: Facilitator: Jim Minute Taker: Keith Timekeeper: Hans

3.8 Next week meeting time: Tuesday 7:00 Student Lounge

4. Wrap up Action Items: 4.1 Jim: Update Gantt chart from suggestions during meeting. 4.2 Hans: Update Use Case diagram. 4.3 Hans: Act as temporary liaison and send in all paperwork on 1/26/11. 4.4 Keith: Continue work on SVN Repository 4.5 All members: Start work on Prototypes

When and Where Date: 01/24/11 Start: 20:30 End: 21:00 Room: ATLC 254 Landis,

Role Facilitator: Ted Landis Timekeeper: James Neilan Minute Taker: Has Hagen Attending: Keith Brown, Hans Hagen, Adil Khan, Ted And James Neilan

Objective The purpose of this meeting is to formulate use case documentation of the project.

Page 50 of 61

Status[Allocated Time: 10 minutes] Jim Neilan: gantt chart, schedule All: SVN repository

Discussion[Allocated Time: 15 minutes] 3.1 Use case discussion

Wrap up[Allocated Time: 5 minutes] 4.1 Review and assign new actions items 4.2 Meeting critique
When and Where Date: 01/19/11 Start: 20:30 End: 21:00 Room: ATLC 254 Ted Landis, Role Facilitator: Hans Hagen Timekeeper: Ted Landis Minute Taker: Adil Khan Attending: Keith Brown, Hans Hagen, Adil Khan, And James Neilan

Objective The object for this meeting is to finalize software tools that will be used to accomplish the Mobile SMIL in the Cloud project and to discuss project responsibilities.

Status[Allocated Time: 10 minutes] Keith Brown: State of e-mail distribution, SVN repository, and software links All Team members: State progress and knowledge of following software tools: http://code.google.com/p/nku..... Our site http://code.google.com/intl/en/projecthosting - Info on Project hosting http://developer.android.com/index.html - Android API

Page 51 of 61 http://code.google.com/intl/en/appengine - App Engine API Jim Neilan: State of Skills Documentation. Adil Khan: State of UML program choice: http://live.gnome.org/Dia - Open Source UML diagram Program or other

Discussion[Allocated Time: 15 minutes] 3.1 Finalize IDE, language, and other software to be used 3.2 Set primary and secondary roles (Especially Liaison) 3.3 Discuss the use of project scheduling software 3.4 Discuss preliminary ways to layout and break up the project 3.5 Discuss demo layout: Emulators or Phones

Wrap up[Allocated Time: 5 minutes] 4.1 Review and assign new actions items 4.2 Meeting critique

When and Where Date: 02/1/11 Start: 7:00 End: 7:30 Room: Student Lounge Landis,

Role Facilitator: Adil Khan Timekeeper: Keith Brown Minute Taker: James Neilan Attending: Keith Brown, Hans Hagen, Adil Khan, Ted And James Neilan

Objective Present the use case diagrams for the different parts of the project. Finalize remaining tool issues such as SVN. Status[Allocated Time: 10 minutes] Jim Neilan: Use case diagrams for the player and composer. All: SVN repository

Page 52 of 61

Discussion[Allocated Time: 15 minutes] 3.1. Team members discuss status of individual prototypes. 3.2. Update Team members on project time lines and milestones.

Wrap up[Allocated Time: 5 minutes] 4.1 Review and assign new actions items 4.2 Meeting critique

When and Where Date: 02/01/11 Start: 7:00 P.M. End: 7:30 P.M. Room: Informatics Lounge

Roles: Primary Facilitator: Adil Khan Timekeeper: Keith Brown Minute Taker: Jim Neilan Attending: Hans Hagen, Keith Brown, Ted Landis, Adil Khan, Jim Neilan.

1. Objective Present the use case diagrams for the different parts of the project. Finalize remaining tool issues.

2. Status 2.1 Jim: Use case diagram review for the player and composer project components. 2.1.1 Discussion of Composer Use case. Decomposition of Send Message action to cloud and to mobile, breaking components into xml and multimedia formats. A new composer use case with activity and sequence diagrams to be presented on 02/08. 2.2 All: SVN repository 2.2.1 Keith: SVN set up in Eclipse OK. Description of SVN in Eclipse. Everyone should be set up by 02/08. Each person should keep own folder in SVN until mid-term when we begin to combine code. Hans, Ted to set up SVN by 02/08.

3. Discussion 3.1 Ted: Discussion of resources staying on phone.

Page 53 of 61 3.2 Keith: Editing in composer -> layout and table save for export into SMIL xml. Additions of timeline, sidebar, and add button with pull down menu. 3.3 Jim: Used Gantt chart to help the division of project for prototyping. 3.4 3.5 Next Steps 3.5.4 Hans to develop prototype of Android GUI for player and DMIL table 3.5.5 Adil and Keith to continue working on cloud connectivity. 3.6 Jim: Set meeting roll rotation as follows: Hans, Ted, Adil, Jim, and Keith

Move up in rotation (Next Week): Facilitator: Jim Minute Taker: Keith Timekeeper: Hans

Week after: Facilitator: Adil Minute Taker: Hans Timekeeper: Ted

3.8 Next week meeting time: Tuesday 7:00 Student Lounge

4. Wrap up Action Items: 4.1 Jim: Update Gantt chart and schedule. And new use case and sequence diagrams for composer. 4.2 Hans: Start on cloud/player connectivity and SMIL table. 4.3 4.4 Keith: Cloud connectivity research 4.5 All members: Continue work on Prototypes and have use cases ready for 02/08

When and Where Date: 02/08/11 Start: 7:00 End: 7:30 Room: Student Lounge Landis,

Roles: Facilitator: Jim Neilan Timekeeper: Hans Hagen Minute Taker: Keith Brown Attending: Keith Brown, Hans Hagen, Adil Khan, Ted Jim Neilan

Page 54 of 61

Objective Present the use case diagrams/Sequence and Activity for the different parts of the project. Finalize remaining tool issues such as SVN. Status[Allocated Time: 10 minutes] Jim Neilan: Use case diagrams for the player and composer and Schedule Hans: SMIL and Player Adil/Keith: Cloud connectivity All: SVN layout and Protype updates Discussion[Allocated Time: 15 minutes] 3.1. Team members discuss status of individual prototypes. 3.2. Update Team members on project time lines and milestones. Wrap up[Allocated Time: 5 minutes] 4.1 Review and assign new actions items 4.2 Meeting critique

When and Where Date: 2/15/11 Start: 7:00 P.M. End: 7:30 P.M. Room: Student Lounge

Role Primary Facilitator: Keith Brown Timekeeper: Ted Landis Minute Taker: Hans Hagen Attending: Hans Hagen, Keith Brown, Ted Landis, Adil Khan, James Neilan.

1. Objective Present prototype results and update UML diagrams. Determine roles. Discuss extended design meeting.

2. Status 2.1 Prototype status:

Page 55 of 61 2.1.1 Jim: Out of town last week. 2.1.2 Ted: Learned and used Simple XML and investigated Android classes to be used with the mapping of the SMIL files. 2.1.3 Hans: Learned and used Android classes for creating and positioning different views and view groups. 2.1.4 Keith: Learned and tested cloud components. Passed information successfully. 2.1.5 Adil: Successfully tested local message passing. Had issues with passing information to the server. 2.2 Requirements analysis: 2.2.1 Jim: Out of town last week. Updated Schedule. 2.2.2 Ted: Worked on second draft of documentation. 2.2.3 Hans: Worked on second draft of documentation. 2.2.4 Keith: Presented second draft of documentation. 2.2.5 Adil: Worked on second draft of documentation. 3. Discussion 3.1 Keith: Presented Use case diagram for composer to cloud interaction. Also, presented activity diagram for each use case. 3.2 Adil: Communication issue in Android version 2.2 ok in 2.1. 3.3 Ted: We need to serialize what SMIL tags we need to support. Hans has started on this and will bring copies to next meeting. 3.4 Keith: XSD definition should work with Simple XML. Adil thinks this will be too heavy for a mobile device. 3.5 Ted: Prototyped with the canvas function and touch components on android. Hans thinks canvas may not be the way we want to go. Ted agrees. Need to look into this more. 3.6 Jim and Adil: We need to nail down a time for design meeting. This was decided. 3.8 Next week meeting time: Saturday 10:00 am Parking Structure side entry Lounge.

4. Wrap up

Page 56 of 61 Action Items: 4.1 All: Bring Documentation to design meeting, this also includes all packages, imports, and extended classes needed to support designed classes. When and Where Date: 2/19/11 Start: 10:00 A.M. End: 12:00 A.M. Room: Student Lounge Role Primary Facilitator: Hans Hagen Timekeeper: Adil Khan Minute Taker: Ted Landis Attending: Hans Hagen, Keith Brown, Ted Landis, Adil Khan, James Neilan.

1. Objective Design review after first stage of prototyping has been started. Review design documentation: Use Case, activity, and sequence diagrams will be used to start Class diagram conversations. After project is laid out, team members responsibilities will be more concretely defined and more evenly distributed.

2. Status [Allocated Time: 50 minutes]

2.1 Individual component design ideas: 2.1.1 Jim: Composer layout. 2.1.2 Ted: Mapping to SMIL. 2.1.3 Adil: Mobile to mobile messaging. 2.1.4 Keith: Cloud interaction. 2.1.5 Hans: Player layout.

3. Discussion [Allocated Time: 60 minutes]

3.1 Big picture project design layout. 3.2 Class design and layout.

Page 57 of 61 3.3 Assign responsibilities. 3.4 Assign rolls.

4. Wrap up [Allocated Time: 10 minutes] 4.1 Review and assign new actions items 4.2 Meeting critique When and Where Date: 3/5/2011 Start: 10:00 A.M. End: 12:00 P.M. Room: Faculty Lounge Role Primary Facilitator: James Neilan Timekeeper: Hans Hagen Minute Taker: Adil Khan Attending: Hans Hagen, Keith Brown, Adil Khan, James Neilan.

1. Objective Objective was to go over the first draft of the Software Requirements Specification (SRS) document. 2. Status All sections of the SRS document were covered. James was the error logger and the members all took turns to review the documentation and the diagrams. An action list was formulated and a subsequent meeting for 3/9 was set.

3. Discussion Hans shared his use case and activity diagrams for section 4.2 Rest of team members critiqued errors/enhancements, while James recorded in the Log. Keiths section 3 and 6 was reviewed. Rest of team members critiqued errors/enhancements , while James recorded the Log. Adils Use case and Activity Diagrams were reviewed. Rest of team members critiqued errors/enhancements , while James recorded the Log.

4. Wrap up Action Items: Adil to set up Google Docs for sharing the SRS document Adil to work on activity/use case diagrams for SMIL SENDER/RECEIVER James to email Dr. Hao on video issues regards emulator.

Page 58 of 61 James to email Dr. Hao on requirement of use case diagrams, and whether they require accompanying descriptions. Team to implement changes in SRS documentation based on feedback from team members during this meeting.

Page 59 of 61

4.

Other communication records (such as emails, Wiki, Google Wave, Instant messaging, and so on)

Page 60 of 61

We also use NKU and gmail email services for communication.

5.

Software configuration management

We use Tortiouse and Eclipse SVN packages for software tracking and change monitoring. Current, we have separate folders for each team members development

Page 61 of 61 component. We intend to integrate the full package and track integration changes starting on April 1st, 2011.