team5 srsv1.0 ms

of 59

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

of 59

Table of Contents

1. Document Information …………………………………………………………….4

1.1. Prepared by

1.2. Document responsibilities

1.3. Revision history

2. Introduction…………………………………………………………………………..5

2.1. Purpose

2.2. Scope

2.3. Definitions, acronyms, and abbreviations

2.4. References

2.5. Overview

3. Overall description…………………………………………………………………7

3.1. Product perspective

3.2. Product functions

3.3. User characteristics

3.4. General constraints

3.5. Assumptions and dependencies

4. Specific requirements…………………………………………………………….10

4.1. External interface requirements

4.1.1. User interfaces

4.1.2. Hardware interfaces

4.1.3. Software interfaces

4.1.4. Communication interfaces

4.2. Functional requirements

4.2.1. Overall activity diagram

4.2.2. Use case diagram

4.2.3. Detailed activity diagram

4.3. Performance requirements

4.4. Design constraints

4.5. Software system attributes

4.6. Other requirements

5. Project management…………………………………………………………………35

5.1. Project estimation

5.2. Risk assessment

6. Future system improvements……………………………………………………...37

Appendix: …………………………………………………………………………………………..381. Task partition

2. Work schedule (MS Project)

of 59

3. Weekly meeting agenda and minutes

4. Other communication records

5. Software configuration management

of 59

1. Document information

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 File Name Date

0.5 Team5_SRSv0.5.doc 03/05/11

0.8 Team5_SRSv0.8.doc 03/10/11

0.9 Team5_SRSv0.9.doc 03/13/11

1.0 Team5_SRSv1.0.doc

Team5_SRSv1.0.pdf

03/19/11

of 59

2. Introduction

2.1. Purpose

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 au-dio, 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 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.

o SMIL Composer : Application running on Android to play a SMIL message.

o 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 down-load resources from the cloud.

o 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.

of 59

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

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.

of 59

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.

( 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++ API’s. 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.

of 59

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, 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. Overall description

3.1. 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

of 59

streams to the players when requested. It will upload multimedia files from the composer when they don’t 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 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. User characteristics

3.3.1 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.

of 59

3.3.2 Message Receiver

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. Specific requirements

4.1. External interface requirements

4.1.1 User Interfaces

There are two main components that will operate on the mobile device. The Composer and the Player. The Player’s 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.

of 59

Figure 4.1: Application Entry Screen

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

of 59

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.

of 59

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.

of 59

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.

of 59

4.1.2 Hardware Interfaces

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 user’s SMIL message has the resource URL’s 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 requiredo 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)

of 59

4.1.3 Software Interfaces

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.

of 59

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

Figure 4.2.1

SMIL Composer

Cloud Interaction

Data Communication

SMIL Player

of 59

4.2.2. Use case diagram

4.2.2.1 SMIL Composer use case diagram

Use case Name: Create MessageDiagram:

Participating actors: User

Entry condition: In SMIL Composer App.

Exit condition: Save message or Close.

Flow of Events:

1. 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.

CreateMessage

of 59

7. User saves or closes message.

Special Requirements: Access to media.

Use case Name: Save MessageDiagram:

Participating actors: User

Entry condition: Message has been created.

Exit condition: Message saved.

Flow of Events:

1. User has created message.

2. Data Com replies save success or failure.

3. User clicks OK.

Special Requirements: Access to media.

Use case Name: Open MessageDiagram:

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.

Open Message

MessageNotFound

SelectFile

SaveMessage

of 59

Flow of Events:

1. Data Com has a clean message.

2. User Selects message from list.

3. User Presses Open button.

4. User Presses plays or closes message.

Special Requirements: Data Communication has a message and message is not corrupt.

Use case Name: Preview MessageDiagram:



Exit condition: Moved on to play, edit, or close message.

Flow of Events:

1. Data Com has a clean message.


3. User Presses preview button.

4. User Presses play, edit or close message.


Preview Message

MessageNotFound

SelectFile

of 59

Use case Name: Edit MessageDiagram:


Entry condition: User has message open or previewed.

Exit condition: Moved on to saved or closed message.

Flow of Events:

1. User has message opened or previewed.

2. User Selects edit message.

3. User edits message in composer mode.

4. User Presses save or close message.


Use case Name: Send MessageDiagram:



Exit condition: Message sent no error.

Flow of Events:

1. User selects message from message list.

2. User selects send message button.

Edit Message

MessageNotFound

SelectFile

Send Message

MessageNotSentError

SelectFile

of 59

3. Data Com sends conformation that message is sent.

4. User returns to message list screen.

Special Requirements: Data Communication has sent a message and message is not corrupt.

4.2.2.1 Data Communication use case diagram

Use case Name: Save FileDiagram:

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.

(Data Com)

of 59

Use case Name: Get FileDiagram:

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 ListDiagram:

Participating actors: SMIL Composer, Cloud

Entry condition: Composing message browse files on cloud.

Exit condition: File list received no exceptions thrown.

Flow of Events:

1. SMIL Composer requests to get media file list.

of 59

2. File list received no exceptions thrown.

Special Requirements: Network connection.

Use case Name Upload FileDiagram:

Participating actors: Cloud

Entry condition: Request for file upload.

Exit condition: Upload is successful, no exception thrown.

Flow of Events:

1. Cloud Uploads a file.

2. File uploaded no exceptions thrown.

Special Requirements: Network connection and no duplicate files.

Use case Name Download FileDiagram:

Participating actors: Cloud

Entry condition: Request for file download.

Exit condition: Download is successful, no exception thrown.

Flow of Events:

1. Cloud downloads a file.

of 59

2. File downloaded no exceptions thrown.

Special Requirements: Network connection and file found.

4.2.2.3 Cloud Interaction use case diagram

Use case Name: Upload FileDiagram:

Participating actors: Data Com

Entry condition: Mobile phone has data connection.

Exit condition: Upload complete or exception thrown.

Flow of Events:

4. Data Com sends HTTP request.

5. Data Com Request upload URL

6. Data Com receives upload URL.

7. File is uploaded.

Special Requirements: None.

Upload File

of 59

Use case Name: Get Files InstalledDiagram:



Exit condition: XML received or exception thrown.

Flow of Events:


4. Data Com Request Requests Map

5. Map Processed to XML.

6. Data Com receives XML response via HTTP.


Use case Name: Play/Download FileDiagram:



Exit condition: File is streamed, downloaded, or exception thrown.

Flow of Events:


2. Data Com Request stream to video/audio and download to image.

3. Data Com receives download URL.

4. File is downloaded.


4.2.2.4 SMIL Player use case diagram

Get Files Installed

Play/Download File

of 59

Figure 4.2.2.4.1

Use case Name: Receive MessageDiagram:


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:

1. 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.

Receive Message

of 59

Use case Name: Open MessageDiagram:



Exit condition: Moved on to play message or close message and return to message list.

Flow of Events:

5. Data Com received a clean message.


7. User Presses Open button.

8. User Presses plays or closes message.


Use case Name: Play MessageDiagram:

Open Message

of 59


Entry condition: User has opened message.

Exit condition: User stops, pause, or closes message.

Flow of Events:

1. User selects play button.

2. User selects stop, pause, or close button.


Use case Name: Pause MessageDiagram:


Entry condition: User is playing message.

Exit condition: User stops, resumes, or closes message.

Flow of Events:

1. User selects pause button.

2. User selects stop, resume, or close button.


Play Message

Pause Message

of 59

Use case Name: Resume MessageDiagram:


Entry condition: User is pausing message.

Exit condition: User stops, pauses, or closes message or end of message.

Flow of Events:

1. User selects resume button.

2. User selects stop, pause, or close button or end of message.


Use case Name: Stop MessageDiagram:


Entry condition: User is playing or pausing message.

Exit condition: User plays or closes message.

Resume Message

Stop Message

of 59

Flow of Events:

1. User selects stop button.

2. User selects play or close button.


4.2.2.5 Message Sending Mobile to Mobile Use Case

Use case Name: Send MessageDiagram:

Participating actors: SMIL Composer

Entry condition: Saved and selected a message, send button pressed.

Exit condition: Confirmation of message sent.

Flow of Events:

(Data Com)

of 59

1. 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.


Use case Name: Receive MessageDiagram:

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:

1. SMIL Player receives message.

2. SMIL Player saves message to message log.

Special Requirements: Mobile phone has network connection.

4.2.3.5 SMIL Transporter (Data Com) activity diagram

of 59

4.2.3. Detailed activity diagram

of 59

4.2.3.1 SMIL Composer activity diagram

of 59

4.2.3.1 Data Communication activity diagram

of 59

4.2.3.3 Cloud Interaction activity diagram

of 59

4.2.3.4 SMIL Player activity diagram

of 59

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

of 59

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. Project management

5.1. 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.

5.2. Risk assessment

of 59

Risk Risk Type Risk Likelihood Impact Mitigation Strategy

Cloud Connectivity Medium Low High Ensure testing and validation prior to demonstration

Emulator Failure Medium High Medium Back up dev phones for demo.

Prototype delay in integration of components

Medium Medium Medium Continue to update project schedule and ensure targets are met

SMIL Parser fails High Low High Ensure testing and validation by 04/04

Simple XML integration problems

Low Low High Team review 04/04

Composer touch creation failure

Medium Low Low Ensure proper error recovery and restart for demo.

Playback from cloud failure

Medium Low High Ensure proper error recovery and restart for demo.

Message send/receive failure

Medium Low Medium Ensure proper error recovery and restart for demo.

Composer video / emulator failure

Medium Medium High Have PC and/or dev phone back ups ready for demo

Team member lack of work

Medium Low High Monitor input during weekly team meetings and adjust engagement appropriately.

of 59

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:

1. Task partition

of 59

Who Role Skills and Assessments Languages GAPS Email

Keith Brown

ArchitectCloud Connectivity

Documentation

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

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

iPhone

[email protected]

Hans Hagen

SMIL PlayerXML Parsing

Documentation

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

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

Android Multithreading J2ME MS Mobile Phone Prg

[email protected]

Adil Kahn

Http CommunicationsDocumentation

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

[email protected]

Ted Landis

ComposerSimple 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

iPHone J2ME MS Mobile Phone Prg

[email protected]

Jim Neilan

Project DocumentationComposer GUIMain App GUI

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

J2ME iPhone MS Mobile Prg Android Networking

[email protected] [email protected] [email protected]

mailto:[email protected]








of 59

2. Work schedule (MS Project)

of 59

3. Weekly meeting agenda and minutes

When and Where RoleDate: 1/19 Primary Facilitator: Hans HagenStart: 9:00 P.M. Timekeeper: Ted LandisEnd: 9:20 P.M. Minute Taker: Adil KhanRoom: ST 254 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:

● Keith to explore svn plugin● Adil to explore eclipse uml plugin● James to share MS Project files.

http://code.google.com/





of 59

● Members to create USE CASE Diagram for project requirements.● Adil to get meeting minutes out by Sunday.

When and Where Role

Date: 1/25 Primary Facilitator: Ted Landis

Start: 7:00 P.M. Timekeeper: James Neilan

End: 7:30 P.M. Minute Taker: Hans Hagen

Room: Student Lounge 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

3.5.3 Adil to develop prototype of interface between the cloud, the composer and player.

of 59

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): Week after:

Facilitator: Adil Facilitator: Jim

Minute Taker: Jim Minute Taker: Keith

Timekeeper: 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 RoleDate: 01/24/11 Facilitator: Ted LandisStart: 20:30 Timekeeper: James NeilanEnd: 21:00 Minute Taker: Has HagenRoom: ATLC 254 Attending: Keith Brown, Hans Hagen, Adil Khan, Ted Landis, And James Neilan

● ObjectiveThe purpose of this meeting is to formulate use case documentation of the project.

● Status[Allocated Time: 10 minutes]

of 59

Jim Neilan: gantt chart, scheduleAll: 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 items4.2 Meeting critique

When and Where Role

Date: 01/19/11 Facilitator: Hans Hagen

Start: 20:30 Timekeeper: Ted Landis

End: 21:00 Minute Taker: Adil Khan

Room: ATLC 254 Attending: Keith Brown, Hans Hagen, Adil Khan, Ted Landis, And James Neilan

● ObjectiveThe 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

http://code.google.com/intl/en/appengine - App Engine API

http://code.google.com/intl/en/appengine

http://developer.android.com/index.html

http://code.google.com/intl/en/projecthosting

http://code.google.com/p/nku

of 59

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 RoleDate: 02/1/11 Facilitator: Adil KhanStart: 7:00 Timekeeper: Keith BrownEnd: 7:30 Minute Taker: James NeilanRoom: Student Lounge Attending: Keith Brown, Hans Hagen, Adil Khan, Ted Landis, And James Neilan

● ObjectivePresent 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

● Discussion[Allocated Time: 15 minutes]

http://live.gnome.org/Dia

of 59

3.1. Team members discuss status of individual prototypes. 3.2. Update Team members on project time lines and milestones.


When and Where Roles:

Date: 02/01/11 Primary Facilitator: Adil Khan

Start: 7:00 P.M. Timekeeper: Keith Brown

End: 7:30 P.M. Minute Taker: Jim Neilan

Room: Informatics Lounge 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.

of 59

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): Week after:

Facilitator: Jim Facilitator: Adil

Minute Taker: Keith Minute Taker: Hans

Timekeeper: 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 Roles:Date: 02/08/11 Facilitator: Jim NeilanStart: 7:00 Timekeeper: Hans HagenEnd: 7:30 Minute Taker: Keith BrownRoom: Student Lounge Attending: Keith Brown, Hans Hagen, Adil Khan, Ted Landis, Jim Neilan

of 59

● ObjectivePresent 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 ScheduleHans: SMIL and PlayerAdil/Keith: Cloud connectivityAll: 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.


When and Where Role

Date: 2/15/11 Primary Facilitator: Keith Brown

Start: 7:00 P.M. Timekeeper: Ted Landis

End: 7:30 P.M. Minute Taker: Hans Hagen


1. Objective

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

2. Status

2.1 Prototype status:

of 59

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

of 59

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 Role

Date: 2/19/11 Primary Facilitator: Hans Hagen

Start: 10:00 A.M. Timekeeper: Adil Khan

End: 12:00 A.M. Minute Taker: Ted Landis


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.

of 59

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 RoleDate: 3/5/2011 Primary Facilitator: James NeilanStart: 10:00 A.M. Timekeeper: Hans HagenEnd: 12:00 P.M. Minute Taker: Adil KhanRoom: Faculty Lounge 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.○ Adil’s 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.

of 59

● 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.

of 59

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

of 59

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

of 59

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

team5 srsv1.0 ms

Documents

smil messages

smil specification

mobile smil application

smil player applications

o o o o smil composer

document information

srs document

ted landis page