Ongoing Reports for Semester 1:

The first semester is difficult as far as managing documentation is concerned because you are involved in many activities trying hard to understand your project. To make life easier and more controlled it is a good idea to break down the initial documentation into three separate reports as outlined by Shelly Cashman and Rosenblatt in their book Systems Analysis and Design (web site). They also provide a very good grounding for the development phase, whether you are using the prototype methodology or following the traditional SDLC. These reports provide the basis of your final Systems Manual and below is a suggested structure for each of these reports.

1. Schedule:

Include your Schedule documentation in your final semester 1 report.

1.1 Preliminary Investigation Report (not required):

This report, as specified in Shelley, Cashman and Rosenblatt, is not required because it is contained within your Schedule or within your System Requirements Specification. I have listed the headings here simply to provide you with more ideas.

The main purpose of this document is for you to explain your project. (see chapter 2 of Systems Analysis and Design)

1. Introduction
   • Who the project is for
   • Why the project is required
2. Project Description
   • General description
   • Problem identification
3. Any obvious constraints
   • Financial
   • Technical - OS, software, hardware
4. Time and cost estimates
5. Feasibilty
   • can it be completed on time?
   • do you have the technical expertise?
   • financial
6. Even a context DFD? (to show scope and external entities)

2. System Requirements Specification:

(see Chapter 5 or visit their web page)
The aim of this document is to show your understanding of the current system and what is required for the new system.
This document should be well underway for the mid-semester review and should be used to impress your supervisor and second assessor.

1. Management Summary
2. Information System Background
   • Description of current system
   • DFD of current system - usually not required for Projects
   • Data Dictionary of current system - usually not required for Projects
3. Functional Requirements (or Software Specifications)
   • Description of alterations/proposed new system
   • DFD of new system
   • top-level Data Dictionary entries and process descriptions
     (For DD expand each data flow of your DFD into its basic data elements. Specify name, type, constraints and a description. Process descriptions should correspond to your DFD processes.)
4. Environmental Requirements
   • specify any constraints for the new system.
     eg. hardware, Operating System, Control and Security.
     Also any outside requirements such as those required by government bodies.
5. Alternatives
   • Try to specify at least three alternatives:
     eg. Off-the-shelf package 1, package 2 etc;
     modification of a package;
     or write from scratch.;
   • Specify feasibility of each.
   • Time and Cost Estimates
     • This can be incorporated into each alternative above
   • Recommended Alternative (if any)
   • Why?
6. Appendices (as needed)
   • Interview reports
   • Questionnaires
   • Examples of forms and reports of the current system

3. System Design Specification:

This report specifies all programming requirements. Ideally, it should be finished just before the end of semester one.

1. Management Summary
2. Entity-Relationship diagrams and/or Normalisation listing (if appropriate)
   (Entities and their attributes can be recognised from your DD.)
3. File and Database Design
4. Environmental Requirements (if appropriate)
   • More specific elaboration on the requirements specified in the System Requirements Specification document.
5. Menu Structure (Navigation Structure)
   • first as a user sees it,
   • then as a structure for the programmer that specifies module/file names for each menu screen
   • If using Prototype Methodology, these screens will be developed in your prototype.
6. Output Design
   • examples of reports.
   • specify how the data will be extracted from the DB using  pseudocode, SQL etc
   • If using Prototype Methodology, these report outlines can be developed in your prototype. Further detail can be added during the Development Phase of your project.
7. Input Design
   • specify in detail any template for your system (html code, graphics etc.)
   • examples of screens (start with pen and paper)
   • If using Prototype Methodology, these screens will be developed in your prototype. Functionality behind events, eg. Save Button, can be developed during the Development Phase of your project.
   •  list events (onLoad, save, other button actions etc.) associated with the screen
   • pseudocode, SQL etc. associated with each event
8. Other modules, etc., if required.
9. Implementation Requirements
10. Time and Cost Estimates
11. Appendices (as needed)

If you manage to get all this done before the end of first semester you are well on the way to producing a sound product.

4. Other activities you can be involved in during semester 1:

1. Learning your software development environment, particularly if you are using a language or development environment new to you.
   • Play around by creating some very simple screens, reports etc. that use the same features your project will need.
   • eg. for a web project write a cgi script to store simple values in a database - just so you know how to do it.
   • or, document a screen/report from an example application that has similar functionality to your project.
   • Include documentation for this in your Individual Project Report as it is an integral part of your learning, but it is not part of your final system.
2. Presentation of your reports probably requires some knowledge of a graphics program. So obtain one, such as gimp on our Unix system (download it for free, eg. from http://gimp-win.sourceforge.net/stable.html), and learn how to use it - which you can describe in your Individual Report.

A really good project group may also have some of the first prototype underway by the end of first semester.
Second semester now concentrates on the development phase, testing, then producing the User's Manual etc.

5. Minor Project students working in S.I.T.S.

Objectives of the position:

To render assistance to Students and Staff during operating hours in a variety of narrowly defined IT services. Assistance will be given via telephone, e-mail and face to face contact. IT systems supported include: WebCT, Student Online, OASIS, Microsoft Office, Student e-mail, Turnitin, student wireless.

Duties and responsibilities:

1. Provide assistance to Students and Staff in use of the local lab facilities.

2. Assist in maintenance and upkeep of facilities and System administration.

3. record client interactions and work performed in central logging system.

4. Monitor and report any service failures to appropriate areas for rectification.

5. Assist students with problems relating to La Trobe software.

6. Other duties as directed.

Staffing 2009

Notices

Welcome to the subject for 2009!