Craig Mattson (Personal Website)
Home - Blog, News, About MePrograms - C#.Net, Java, VB6MusicWebsites

Monash Industry Experience Project

Client: Access Education
Team Name: MoMo Solutions

Project Manager and Team Leader: Craig Mattsonpsandg_400
Software Architect: James Charters (Also Assistant Project Manager)
Business Analyst(s): Yousef Al Jaberi, Pranesh Medilall and Anand Rajagopal
Year: 2008
Technologies Deployed: Microsoft ASP.Net 2.0, Windows Server 2003, MySQL 5.1, NAB Transact (through XML API) 

As part of the Bachelor of Information Technology and Systems degree at Monash University, students undertake a project with a real world client to complete a real world solution. The unit(s) FIT3047 and FIT3048 make up a year long project requiring regular documentation as well as an expo upon completion of the project.

Please note that the documents themselves are NOT downloadable. This is to prevent people plagiarising as well as keeping each team members contact details anonymous. This also protects the client from exposure to underlying code.

Project Standards and Governance:

 MoMo Solutions was formed originally with a team of five people with Anand Rajagopal completing his contributions during first semester. During the Project Standards and Governance phase, the team agreed that standards would be formed on the basis of popular conventions supplied by TechNotes, ANSI and W3C XHTML (Strict DTD) format.

As part of Governance, the team determined the best approach to disciplinary action was not to involve monetary fines, but rather agree that we operate in a professional capacity - or face a group meeting where we determine the appropriate action. With (combined) some 200km distance between us, it was not appropriate to expect each member to continuously show up on time or apply rules to missing meetings. With these rules in place, the team had minor issues.

Standards for documentation handling were also established including the various fonts that we would use, sizes and colours as well as spacing, table and version standards. The document layout is clean and easy flowing. The document achieved an impressive 10 / 10 (HD) which was awarded to our team and only one other.

Business Case and Risk Analysis:

The second major submission requirement included analysing the basic requirements for the business. In this phase, five systems were determined appropriate: Bookings, Events, Content, Reporting, Ticket Printing. These five business areas will be centralised in one database accessed by three different applications.

Risk Analysis coverd the determination of Damage versus Probability. That is; risks such as the client changes the scope for an entire sub-system has a reasonably high probability but a low-medium impact if applied BEFORE development commences. After applying a calculation, these risks were categorised as "Low, Medium, High and Extreme" and were to be updated on a weekly basis.

Functional Specification:

The Functional Specification confirmed 15 functional areas across the five sub-systems (Orders, Calendar Event, Mailing List, Menu, News Article, News Letters, Web Pages, Coupons, Events, Programs, Supplementary Content, Venues, Reports, Members and Ticketing). Each function within a functional area were documented using "CRUD" complete with Use Case Diagram, Use Case Description and Input-Processing-Output diagrams. Additional methods where appropriate were also documented.

Design Specification:

The Design Specification determined the .NET Framework appropriate for the development platform due to the integration of classes between the website and the application. The Design Specification covered the creation of UML Class Diagrams using NetBeans UML Plugin, an Entity-Relationship Diagram for the Database and Storyboarding for screen layouts.

Development:

During the second semester, development commenced early on with the database written including 180 Stored Procedures and the Master pages written for ASP.Net. Through consultation and some Agile Programming, the Website was largely complete within 6 weeks (consider 3 other units worth of work as well as part-time employment). The Website was built around the principal of a Presentation Layer (ASP.Net Website - What you see), Business Logic Layer (Objects and Processing Rules), Data Access Layer (Connection to the Data Source), Data Abstraction Layer (Translate Data Source to the DBMS - in our case, MySQL - although it would be relatively easy to change the DBMS to Oracle or MSSQL) and a Base Layer where the fundamental Object Details and Enumerations are stored.

The initial version of the ticket printer used a rather-lengthy PDF control (iTextSharp) which was later considered too slow to process beyond 5 bookings at a time (it was estimated a peak of 100 orders would be necessary for End of Year Revision Programs) and was thus re-written to use the PrintDocument control. The Ticket Printer generates an Invoice Page including details of all bookings, payments and outstanding amounts (if any) - followed by Tickets which pull data straight from the database and lays out the tickets as appropriate - followed by Venue Maps as appropriate. The time saving in packing tickets as well as the accuracy of the invoicing and ticketing procedure is of particular value and critical importance for the continued success of Access Education.

Finally, Crystal Reports were integrated initially to produce different representations of data. Unfortunately due to time constraints, the Crystal Reporting functionality had been removed from the system and replaced with Excel Spreadsheets to pull data down straight from the website so that Access Education can create Mail Merge documents, check profit margins and print lists of students attending the various events.

Payment Gateway

The website uses an XML-based Payment Gateway within Australia. As part of the payment process, the website automatically records the Order Number to the bank, the payment amount and the status of the transaction. As part of Staff entering data, processing is now done as a booking is entered rather than going directly to the Merchant's website.

Testing

During the final weeks of the semester, a considerable amount of time was spent testing particular aspects of the system. With over 1,000 tests, some critical decisions were made such as if a test is successful on Round 1, no further testing is required unless the function itself has been changed. The testing strategy was written over three documents; Test Plan (strategies in approaching testing with respect to our schedule), Test Cases (a summary of the testing areas and what is to be tested) and Test Results (a comprehensive document containing Test Data, Expected Results, Actual Results and whether the test was a Pass (P), Conditional Pass (CP) or Failure.

All stored procedures were tested manually outside of the system prior to testing through the system. All classes were unit tested to instantiate objects, load and dispose lists and performance measured based on 10,000 random students loaded into the database.

Once we were satisfied with our testing, three User Acceptance Tests were completed onsite where real data was trialed. Most issues reported were layouts of fields, required and not-required fields and the occasional crash generally due to Ajax synchronisation.

Conditional Signoff:

At the end of the semester, the client agreed to sign off conditionally pending successful integration with the NAB and proper installation of the website.

Ongoing Maintenance (2009):

After completing the project and in agreeance with the client, I have continued to maintain the system and introduce changes between February 2009 and June 2009. These have included optimising slow to render pages (usually resolvable by binding the results of a stored procedure directly to a Data Grid), Making changes and improvements to the client checkout process, providing additional abstractions of data (through the use of Excel and Access), altering the ticketing application and fixing bugs as they appear.

Access to Source Code and Documentation will be considered on a case-by-case basis only. This is to protect Monash University, Access Education and Myself from unnecessary security risks pertaining to internal knowledge.

[Comment]

[Print View]