Research Methodology

1. Research Methodology SDLC MDLC Waterfall Model RAD

2. Introduction • A framework that describes the activities performed at each stage of a software development project. • MM System has various aspects of the methodology (genre, character, interface, location, plotting, scripting and testing) compared to conventional systems development processes (SDLC).

3. Introduction • Technical side of multimedia: • knowledge of new devices • interfaces is required • skills of animation, film and audio need to be integrated • Design and production for multimedia system must be approached differently. Development in multimedia design are readily adapted to these new media – Multimedia Development Life Cycle (MDLC).

4. Unique character of multimedia • two aspects (Trueblood et. al., 1995) : • the technological richness of the media • the broadness and diversity of the audience or users

5. Comparison of SDLC and MDLC

6. Problem definition • the first stage of any design cycle. • successful systems design and implementation is only possible when developers have a clear idea of the problem to be solved (understands the target users, the technology, and the problem domain). • four basic issues: • identifying the client / sponsors / target audience, • eliciting their needs / wants, • identifying the scope of the project, and • understanding the resource limits.

7. Two approach: • Reactive projects • information is given by the client, but there is still a need to understand power relationships and decision making structures so as to avoid satisfying only the less important, but not the most influential, members of the client organisation. • Proactive projects • the developers that initiate the process, there is greater freedom to determine the nature of the system, but poor hoices at this stage will lead to trouble in subsequent marketing.

8. Recognise your strengths and weaknesses, and to seek help from people with greater knowledge in the areas you have least experience in.

9. Genre • Feasibility study - the analyst uses a mental model of a proposed system, aided by rough sketches and calculations, and tries to imagine the idea working. • Examine feasibility from three perspectives: • Technical • ask the question as to whether you think the system can be built. • Economic • estimate the likely cost of production • organisational feasibility • ask whether the idea would work given the intended user • organisations and people.

10. Genre • A genre comprises a class of communicative events, the members of which share some common set of communicative purposes. • Genre exhibit various patterns of similarity in terms of structure, style, content and intended audience. Example: • Romantic setting - the hero requiring to get supplies of partridges, turtle doves, French hens, geese and swans in ever increasing number to satisfy the object of their affections

11. Characterisation • extension of genre choice where we choose the primary character, secondary (support, foil, catalyst) characters and work with archetypes and stereotypes within our genre. • Characters: • physical attributes, • specific knowledge and role, • language style and vocabulary, and • attitude

12. Characterisation • Defining the characters are important, which we are attempting to cover the bases of our project objectives while still remaining true to our genre. Example: Produce a check list of character traits (helpful, competitive, obstructive, friendly, aloof, rigid, deceitful, vague), and we would like our user to experience and attempt to attach these traits to our characters. We have in effect started to build a data dictionary / repository as used in Database Management or CASE tools.

13. Location • The creation of locations and sub-locations is a manifestation of top-down design, and as in program design, for reasons of economy we will often reuse locations or sub-locations. • Concerned with sketching each location and placing movable objects and fixed property within the location, and adding these things into our dictionary or repository

14. Location

15. Location • Purpose to sketch the location • to have accurate depiction, • describing the essence of some activity, and • where humour and characterisations can be employed to focus attention and to stimulate discussion.

16. Interface • Part and parcel of location design is the specification of the interaction interface and its commands - talk, examine, use, take, give and so on. • Techniques in interface design: • pop-up windows and icons, • widgets like menus, buttons, scroll bars, text type-in fields, alpha sliders, range sliders and • the like can be readily adapted as part of the interactive multimedia user interface.

17. Interface • These techniques need to be integrated into a project framework so that the user can express their thoughts, feelings and desires, and is not just a passive object to be manipulated

18. Plotting • Having decided upon the locations, it is now time to connect them up with actions and events to indicate the various story paths, rewards and obstacles of the interactivity. • Dataflow diagrams and flowcharts are readily adapted for this stage of multimedia design. • In linking locations and sub-locations, the lessons of programming modularity need to be borne in mind, particularly the emphasis of data coupling.

19. Scripting • Scripting is the process of defining all the dialogue, actions and reactions, location by location, scene by scene, for the whole interaction. • Scripting is like coding a program, only in a new language and perhaps with different layout rules. It is a process that mixes art and science. • In order for dialogue to flow conversation trees, similar to decision trees, are a useful visualisation.

20. Scripting A conversation tree

21. Production • production is simply a process of letting each skill group - film makers, graphic artists, animators and programmers, go about their tasks in their own way. • In any computer project, poor design will be magnified during production, and major problems will necessitate returning to previous design stages to overcome them.

22. Testing • Make an experienced in the process of prototyping • Integrate all sections of the prototype progressively before the whole process is passed over to media production. • Types of Testing • Alpha • Beta

23. Rapid Application Design/Development (RAD) • RapidApplication Development (RAD) is a development lifecycle designed to give much faster development and higher quality results than those achieved with the traditional lifecycle. • It is designed to take the maximum advantage of powerful development software that has evolved recently

24. Rapid Application Design/Development (RAD) • Professor Clifford Kettemborough of Whitehead College, University of Redlands: “RAD as an approach to building computer systems which combines Computer-Assisted Software Engineering (CASE) tools and techniques, user-driven prototyping, and stringent project delivery time limits into a potent, tested, reliable formula for top-notch quality and productivity. RAD drastically raises the quality of finished systems while reducing the time it takes to build them.”

25. Rapid Application Design/Development (RAD) • RAD approach involves compromises in: • usability, features, and/or execution speed. • functionality and performance in exchange for enabling faster development and facilitating application maintenance. • The RAD methodology uses computerized tools and human techniques in a tightly interwoven fashion to achieve the goals of high-speed and high-quality. • Unique and highly complex programs cannot be created using RAD method - programs for tasks such as game playing.

26. Rapid Application Design/Development (RAD) • RAD Requirements • Thorough involvement of the end-user in the design of the system. • Prototyping to help the end-user visualize adjustments to the system. • Use of an integrated CASE toolset, which enforces technical integrity in system modeling and design. • A CASE repository which facilitates the reuse of well-proven templates, components, or systems. • A CASE toolset that generates bug-free code from validated design. • User involvement in the Construction Phase, allowing the details of the prototype to be adjusted if necessary.

27. Rapid Application Design/Development (RAD) • Pros: • Increased speed of development through methods including rapid prototyping, virtualization of system related routines, and other techniques. • Decreased end-user functionality (arising from narrower design focus), hence reduced complexity • Larger emphasis on simplicity and usability of GUI design • Promotes strong collaborative atmosphere and dynamic gathering of requirements.

28. Rapid Application Design/Development (RAD) • Cons: • Reduced Scalability, and reduced features when a RAD developed application starts as a prototype and evolves into a finished application • Reduced features occur due to time boxing when features are pushed to later versions in order to finish a release in a short amount of time • The data needs to already exist • Dependency on strong cohesive teams and individual commitment to the project. Success depends on disciplined developers and their exceptional technical skills and ability. Decision making relies on the feature functionality team and a communedecision making process with lesser degree of centralized PM and engineering authority.

30. Overall Project Development • A critical feature in multimedia development is the sizing of the finished product to fit say a CDROM - so much video, so much audio, so much program, just as PC software must control and balance ROM, RAM and disk storage and meet desired response times.