Chameleon Media Player

BSc in Commercial Software Development

Project Report Two

7 November 2003

Project Group

----- 10CSD -----

Gary Carney 00981435

Brian Hackett 00981516
Terry Harmer 02100277
 C HAMELEON MEDIA PLAYER

Introduction

The evolution of multimedia over the last twenty years has coincided with the large-

scale growth of computer usage by the ordinary person .In the early days of

computing only two main types of data were dealt with - words and numbers. But

with the increase in system speeds and memory size the computer became capable of

handling graphics, audio, animation and video. This has made the PC more attractive

and accessible for the ordinary user. So now that the system hardware was available a

software product was needed to manage the media file formats. This led to the

development of the media player and the large-scale growth of interest in multimedia.

Digital media players are computer programs that allow individual users to “play” (or

display) video or audio data on home computers. The origins of the media player date

back to 1991 when Microsoft introduced Windows 3.0 with multi media extensions.

This was the first media player in Windows and it allowed simple audio playback and

could play CDs and waveform files. At the same time Apple realised QuickTime

version 1.0 which could only play Apples proprietary media file format MOV. As the

products developed and new versions where released more features and functionality

were added .1n 1995 real networks entered the market with real player and several

others like Win Amp and Kazza have being developed in more recent times. Today

the media players available on the market offer a vast array of features including

DVD direct play and digital streaming media.

Motivation

The main reason we chose a media player as our project stems from our own interest

in the area. All three of us use our PCs to play music and video and we have used the

leading products on the market. We thought it would be an interesting challenge to

develop our own version of the media player, which we could customise to our own

specifications. Also the current popularity of multimedia means and there is a large

amount of information available on the web and in books about this area, which have

given us a good starting point and overview of what we have to do.

The Java Media Frame Work

Once the media player had been decided upon as our project topic we began our

research into how we would actually develop and implement the project. Our research

immediately turned up the Java Media Framework (JMF), which had being developed

by Sun Microsystems, Inc., and the IBM Corporation. It is an Application

Programming Interface (API) that means it is a set of software functions and

development tools, which comprise of an interface between a computer application

and the operating system. In this case its main purpose is to incorporate time-based

media into Java applications and applets. Time-based media is data that changes

significantly as time passes, such as audio and video clips, MIDI sequences, and

animations. The main design goals of the JMF as set down by its creators are

• Be easy to program

• Support capturing media data

• Enable the development of media streaming and conferencing applications in

Java
 • Enable developers to implement custom solutions based on the existing API

and easily integrate new features with the existing framework

• Provide access to raw media data

(Sun, jmf, programmers guide)

The applications for multimedia are vast with the latest version JMF 2.1 providing

functions to

• Play various multimedia files in a Java applet or application. The formats

supported include AU, AVI, MIDI, MPEG, QuickTime, and WAV.

• Play streaming media from the Internet.

• Capture audio and video with your microphone and video camera, and then

store the data in a supported format.

• Process time-based media and change the content-type format.

• Transmit audio and video in real-time on the Internet.

(Java world.com)
An Overview of The RAD Model

Rapid Application Development (RAD) is an incremental software development

process model that emphasises an extremely short development cycle. The RAD

Model is a “high speed” adaptation of the linear sequential model in which rapid

development is achieved by using component-based construction. If requirements are

well understood and project scope is constrained, the RAD process enables a

development team to create a “fully functional system” within a very short period of

time (e.g., 60 to 90 days). Used primarily for information systems applications, the

RAD approach encompasses the following phases:

• Business Modelling
• Data Modelling
• Process Modelling
• Application Generation
• Testing and Turnover

Business Modelling

The information flow among business functions is modelled in a way that answers the

following questions: What information drives the business process? What information

is generated? Who generates it? Where does the information go? Who processes it?

Data Modelling

The information flow defined as part of the business-modelling phase is refined into a

set of data objects that are needed to support the business. The characteristics

(attributes) of each object are identified and the relationships between those objects

are defined.
Process Modelling

The data objects defined in the data-modelling phase are transformed to achieve the

information flow necessary to implement a business function. Processing descriptions

are created for adding, modifying, deleting or retrieving a data object.

Application Generation

RAD assumes the use of fourth generation techniques. Rather than creating software

using conventional third generation programming languages the RAD process works

to reuse existing components (when possible) or create reusable components (when

necessary). In all cases, automated tools are used to facilitate construction of the

software.

Testing and Turnover

Since the RAD process emphasises reuse, many of the program components have

already been tested. This reduces overall testing time. However, new components

must be tested and all interfaces must be fully exercised.

The time constraints imposed on a RAD project demand “scalable scope”. If an

application can be modularised in a way that enables each major function to be

completed in less than three months, it is a candidate for RAD. Each major function

can be addressed by a separate RAD team and integrated to form a whole.

Like all process models, the RAD approach has certain realities:

• For large, but scalable projects, RAD requires sufficient human resources to create
the right number of RAD teams.
• RAD requires developers and customers who are committed to the rapid-fire
activities necessary to get a system complete in a much shorter time frame. If
commitment is lacking from either constituency, RAD projects will not be
successful.
• Not all types of application are appropriate for RAD. If a system cannot be
properly modularised, building the components necessary for RAD will be
problematic. If high performance is an issue, and performance is to be achieved
through tuning the interfaces to system components, the RAD approach my not
work.
• RAD is not appropriate when technical risks are high. This occurs when a new
application makes heavy use of new technology or when the new software
requires a high degree of interoperability with existing computer programs.

Why RAD is the Best Design Methodology for Chameleon

Rapid Application Development using iterative prototyping is ideal for the

development of our software application due to the nature of the project and the

knowledge base of the team members.

The initial prototype that has been developed consists of the most basic element of the

application, that is the ability to play an audio file. While it is true that this is a long

way from what the end product is envisioned to be capable of. It is an essential part of

the development cycle, as this first iteration is the base on which all other components

and features will be built.

The nature of this iterative development process also allows for the addition of new

features or functionalities should they arise, for example in the event of a new media

format being released, this new standard can be integrated into the next iteration of

the prototype, resulting in an up-to-the minute application being released when

completed.

As the team becomes more proficient with the various attributes and facilities of the

Java Media Framework we will be able to add new features to each subsequent

iteration until such a time that all the required functionality has been successfully

added to the software.

The “Real World” benefits of RAD can also quite clearly been seen when contrasted

with the more traditional linear methodologies which generally involve a system

being requested by the client and then developed by the programmers with little or no

contact between the initial meeting and the final release of the package, at which time

the requirements of the client may have completely changed, these methods are

generally very costly especially in the event of the client requesting a new function

being added during the development phase, as it is not iterative and there are no

working models created until the final build. RAD allows the client to see their

application being developed through each development cycle and to customise it to

meet their specific needs if it appears to be moving in the wrong direction or their

business needs have changed.

Once the project has completed its final iteration it will enter its testing phase to

ensure that all possible errors can be trapped and prevented before it is finally

released. This testing phase will involve using elements of the Personal Software

Process (PSP). The following table outlines the various phases of the PSP post-

mortem.

PSP0 POST-MORTEM SCRIPT

Phase Purpose To guide the PSP post-mortem process

Number
Entry Criteria • Problem description and requirements statement
• Project Plan Summary form with planned
development time
• Completed Time Recording Log
• Completed Defect Recording Log
• A tested and running program
1 Defects Injected • Determine from the Defect Recording Log the
number of defects injected in each PSP0 phase.
• Enter this number under Defects Injected –
Actual on the Project Plan Summary form.
2 Defects • Determine from the Defect Recording Log the
Removed number of defects removed in each PSP0 phase.
• Enter this number under Defects Removed –
Actual on the Project Plan Summary form.
3 Time • Review the completed Time Recording Log.
• Enter the total time spent in each PSP0 phase
under Actual on the Project Plan Summary
form.
Exit Criteria • A fully tested program
• Completed Project Plan Summary form
• Completed Defect and Time Recording Logs
Division of Work

Due to the nature of our project and its development, we are adopting a somewhat

unconventional approach to the division of work. As a whole this project presents the

team with many unknowns. And with no notable prior exposure to the core

technologies involved in the project we have decided to tackle the various challenges
that arise through group discussion and research, which will be followed by

delegating specific tasks to the team member who feels most confident about each

particular element as its specific requirements become more apparent.

We envision regular project meetings as well as liasing with our project tutor and

concise documentation expanding from each software build which maps out the

results of our individual work as the key to successfully expanding each iteration of

our media player.

References

Rapid Application Development in Action, J.Butler, Applied Computer Research

pp.6-8, (May 1994).

Inside RAD, J.Kerr, R.Hunter, McGraw-Hill (1994).

Software Engineering, R.Pressman, McGraw-Hill (2000).