Analysis complete

Task ID: 32 (I think – don’t have MS Project on my computer)

The analysis of the reward game has been completed! It would have been done by now but I had a week and two days off during Easter for a Catholic youth retreat called “Light to the Nations” and to do a workshop that will prepare myself for the World Youth Day event happening in Coffs Harbour in August. I couldn’t pass Light to the Nations up this year given I might not get time off work for it (provided I even have a job). It’s important that I do other things than uni and in particular maintain a healthy relationship with God.

So I got back home and produced a 47 page report. The report aims to explore the logic of the reward game (and the sound utility that will come with it). I also revised (again) the Gantt chart to pretty impressive detail, if I may say so myself. So hopefully I won’t lose 1.5 marks on it again.

The analysis was pretty useless for me – I felt a lot of the information I could discover in the design – but I guess this project isn’t the most typical IT project – it contains elements of a Multimedia project, too. While there are still inputs being transformed into outputs and all that jazz, but this isn’t as heavy as it would be for a student writing an eCommerce system. However, completing data flow diagrams, data dictionaries, an object-oriented analysis, entity relationship diagrams and all the other goodies packed in this monster of a report, my theory of the structure and design of the game was further refined. I have such a clear image for the implementation now I’m actually itching to start doing it, especially now that I know and have practiced how scripting in Macromedia Director works. It’s going to be lots of fun! But before I do that I have the design phase to complete (which is basically lots of UML).

Here’s what’s gotta happen between now and the completion of the Design phase (the last phase before implementation):

• Arrange with EdAlive our next meeting regarding the analysis report – review any comments or feedback they may have.
• Start the design phase: specifically, develop the storyboards. EdAlive will be wanting to see these so I can get feedback from them straight away.
• Act on any feedback from the Analysis phase.
• Arrange two more formal meetings with Bruce.
• Arrange a final formal meeting with EdAlive.
• Complete the design phase (write Pseudocode and UML into a report basically).

Feasibility Study finally complete

Task ID: None – still perfecting Gantt chart in Microsoft Project.

I have finally completed a 33 page requirements report and feasibility study that adheres closely to the IEEE830 standard for a requirement report. I will submit this to EdAlive once it has been marked by the project supervisor.

The overall report took longer than expected for a few reasons – mainly I felt that the marks rested more in the feasibility study and I had not provided enough detail to get those marks. Other reasons include other university assignments and personal commitments.

The benefit of doing the report to the IEEE830 standard was it gave me a much clearer picture of the needs and requirements of the reward game. It focused some of my attention to issues such design constraints and performance requirements. This document is probably (almost certainly) overkill for a reward game and lots of it is just saying the same thing in different ways… but it does help.

So now the requirements and feasibility report are completed to a standard I am happy with, I will continue with the following tasks over the next few weeks:

1. List the very fundamental tasks of the project. I lost 1.5 marks in my Preliminary Description for being too general. This has to be corrected before the next deliverable is due.
2. Update the Gantt chart in Microsoft Project. Being a strange Microsoft product that I’ve hardly used before, this will take some time.
3. Meet with EdAlive regarding documenting previous meetings, providing a Memorandum of Understanding, discussing analysis techniques (for example, how does the EdAlive development team usually design reward games?) and discuss/draw conceptual storyboards. This meeting date is yet to be set.
4. Commence the Analysis phase. This will include lots of documentation about the data and the user interface logic of the game.

Feel free to make any comments.

Preliminary Project Description

Task ID: None

Tonight I typed up the Preliminary Project Description. This does not include the Gantt chart.

I also spent time looking for web sites that offer free, copyleft, unrestricted for commercial use instrument samples. I found one good site, the Freesound Project but it uses some variant of the Creative Commons which doesn’t allow for commercial use. Bummer!

I’m asking other people if they know of a site that offers samples that will suit my needs. I’d rather not record instruments if other people have done it and are making them freely available.

You might be wondering why I’m doing this research now – it’s because I have a feasibility study to complete and a Gantt chart to make. If I can get free instrument samples then that will free up some time on my Gantt chart.

Starting the Project

Task ID: Not Applicable

Last night I sat down and dedicated time to identifying the tasks required to complete the first half of this project. Now, provided I have all the bases covered, I can develop a Gantt chart by estimating (from my personal experience) how much time the tasks will take to complete. This project is going to be huge.

Tonight I sent an email to Leone, the project supervisor, asking her if she feels I’m on the right track. I really want to get great marks for this project and I’d love to see and hear about creative little critters using BRAINtastic and making wonderful music.

The current list of tasks I have identified are (quoted from the email I sent to Leone):

I have developed a list of activities or tasks that can be done during the analysis stage – can you please let me know if these are not acceptable or not meeting the purpose of the analysis stage?

• Conceptual Storyboards (preferably developed by EdAlive: communicate essential UI needs).
• Data Flow Diagrams (how data flows between and is processed by the BRAINtastic API and the plug in musical composition game as well as instrument or composition data being read, loaded and presented on the screen).
• Data Dictionary (document elements identified in DFD including data exchanged by the BRAINtastic API and the game).
• Process Narrative (to accompany the storyboards, describing the transition between storyboards as well as how a composition is arranged).
• ERD (describe how the composition is structured in memory and in a file to be used at a later date).

I feel that these forms of documentation adequately describe the needs of EdAlive and the data used, the logic needed to structure the data and the processes to manipulate that data. If you (EdAlive or Leone) feel their are any things I might be missing out on or thoughts that might guide me to producing a good analysis, please let me know. It would be much appreciated.

I have also developed a list of activities or tasks that can be done during the design stage – can you please let me know if these are not acceptable or not meeting the purpose of the design stage?

• Interface Designs/Storyboards
• Report Detailing:
  • Targeted software platform and intended system requirements (is this necessary?).
  • Design paradigms used to develop the software (I’d like to use an Object Oriented, Model-View-Controller approach using the Publish/Subscribe [or similar] pattern, don’t know yet if Lingo will let me).
  • File arrangement (stating something like instruments must be stored in a folder like “./instruments/”).
  • File Structure documentation (I’m thinking a UML class diagram might be made redundant here).
• Class Responsibility Collaboration (CRC) Cards (to help determine how objects are related)
• UML
  • Use Cases
  • Class Diagrams
  • Sequence Diagrams
  • State Transition Diagrams
  • Activity Diagrams
• Pseudocode to detail logic behind:
  • Composition saving and restoring
  • Playback of compositions (namely the relationship between the arrangement of instruments on the screen and the timing of an instrument’s playback)
  • Definitions of the callback functions I need to implement for the BRAINtastic API

  Again, I feel these forms of documentation together cover the logic behind an event driven program. Please let me know if you feel I might have gone off track or missing out on some critical thoughts or concerns of the project.