Stage 1 Design Document 2011

From Derek
Jump to navigation Jump to search

Executive Summary

The case of the Somerton Man and the code he left behind has baffled police, the public and cryptanalysts for six decades. This project aims to take advantage of relatively recent advances in technology, including computers and the World Wide Web, to approach the as yet un-deciphered code from a new angle. With the help of modern technology, the project hopes to shed light on what the code could mean.

Introduction

Case Background

The unidentified man found dead on Somerton Beach on December 1 1948.

At 6:30am on December 1 1948, a man was found dead on Somerton Beach, resting against a rock wall. The man carried no identification, just some chewing gum, cigarettes, a comb and an unused train ticket and a used bus ticket to a Glenelg bus stop just 250m from the body’s location. The pathologist conducting the autopsy found that while the man’s heart size was normal, the stomach and kidneys were deeply congested and the liver contained excess blood. He concluded that the death was not natural and suggested a poison, which he could not identify, was the likely cause of death. A review of the case in 1994 concluded that there was little doubt the man died from digitalis poisoning.[1]

The identity of the man was, and still is, a cause of great mystery. He was described as of eastern European appearance, in his mid-40s and in in top physical condition with his hands showing no signs of manual labour. He was clean shaven, dressed in a fashionable European suit and polished boots. All clothing nametags were found to be removed. Neither his fingerprints nor dental records were found to be on any international registries, and by early February 1949 there had been eight different "positive" identifications of the body by members of the public.[1]

The brown suitcase.

A brown suitcase believed to be the Somerton Man’s was found at the Adelaide Railway Station; adding to the mystery. Its contents included shaving items and other tools such as scissors and stencilling equipment. It also contained additional clothes, some with the label removed and some with a nametag that was never successfully linked to anyone. It is thought that after coming into the city via train overnight, on the morning of November 30th, the man checked his suitcase into the railway station cloak room before catching a bus to Glenelg and walking to Somerton Beach.[1]

Due to the mysterious circumstances surrounding the case, many theories have been developed about who the Somerton Man was and the meaning of the code. The most popular theory is that the man was a Soviet spy, perhaps his presence in Adelaide relating to the top-secret missile-launching site at Woomera. Proponents of this theory point out the nature of the mysterious poisoning death and the fact no one could identify him as key reasons for their belief.[1]

Further intriguing details of the case can be read at the Taman Shud Case Wikipedia site - corresponding to Reference [1], or at the sites suggested in the See Also section of this report.

The Code

The mysterious code found marked in the back of the Rubaiyat.

A tiny piece of paper was found deep in the pockets of the Somerton Man’s clothing. On it were printed the words “Tamam Shud”. The meaning of these words is “ended” or “finished”. The slip of paper was identified as being from the last page of a book of a collection of Persian poems called “The Rubaiyat of Omar Khayyam”. An Australia-wide search was launched to find a copy of the book with the “Tamam Shud” section ripped out of the last page. A man came forward to reveal he had found a copy of the Rubaiyat tossed into the back seat of his car, parked in Glenelg, on the night of the 30th of November 1948. Tests later confirmed the scrap of paper came from this book.

What was more fascinating was a 5 line marking of a code found in the back of the book. One interpretation of the code is as follows:

WRGOABABD
WTBIMPANETP
MLIABOAIAQC
ITTMTSAMSTCAB

No one has yet determined what this code means and that is the basis for our project.

Motivation

One subject of inspiration for this project comes from the challenge of looking at a cold case. The code we are examining is part of a 62 year-old unsolved murder investigation and the results we might obtain have the potential to lead to the resolution of this case. Similarly, this is our chance to achieve something that has never been done before in solving this code that remains un-deciphered despite 62 years of attempts.

Another area of motivation comes from a product we plan to create during the project. This product, which we will describe in more detail further on, is to be an integrated web-crawler and pattern-matcher whose function and purpose is not just to help search for an answer regarding the code, but to provide a mechanism to generally search the web for patterns in a way that traditional search engines, such as Google, do not cater for. We are not aware of any software currently available that has this function, so the development of this unique application is a big motivating factor.

Motivation: An Engineering Perspective

While the project is fascinating in that it concerns a specific unsolved murder case, there is also a heavy engineering side that motivates us in regards to career relevance and developing technical skills. During the project lifespan, we will be utilizing engineering techniques including information theory, probability and statistics, encryption and decryption as well as data-mining. The project will also use and enhance our software development skills in the design and implementation of the web-crawler and pattern-matcher, as well as providing experience in the mechanisms of search engines.

These skills we will gain and develop are relevant in many engineering industries, including the e-finance, e-security and IT industries, as well as the internet search industry, which includes employers such as Google. The skills we gain will also be relevant to the covert defence industry, which includes organisations such as ASIO, ASIS and the Defence Signals Directorate.

Previous Studies

As mentioned, the code we are examining is involved in a 62 year-old cold case murder, and as such, there have been many attempts to shed light on the code’s meaning over the years. Of most interest is the report given by Government cryptanalysts in Canberra and the two previous projects done by students at the University of Adelaide.

When the code was examined by Government cryptanalysts in the Department of Defence in 1978. They made three points:

  • There are insufficient symbols to provide a pattern
  • The symbols may be a complex substitute code or could be the ramblings of a disturbed mind
  • It is not possible to provide a satisfactory answer.[2]

While these results are somewhat discouraging, this study was done in 1978 and there have been vast improvements in technology since then that we plan to take advantage of, namely the internet and the data processing power of computers. We expect the University of Adelaide student projects done in the past two years to be more useful in providing a starting point for our own investigations.

In 2009, the students, made several conclusions regarding the code. These were:

  • The letters are not random – they mean something; they contain information.
  • The code is not a transposition cipher – the letters are not simply shifted in position.
  • The results are consistent with an English initialism – the letter distribution is consistent with the letter distribution of the first letter of English words.[3]

The honours students examining the code in 2010 took a slightly different approach. They attempted to match the code’s letter distribution to a specific type of English text, for example a novel, poem, scientific article or Shakespeare play. While this did not return any significant results, they also performed a search across many of these document types, identifying patterns contained in the code. Interestingly, their results were mostly consistent except for their analysis of the Rubaiyat of Omar Khayyam, the book of poems linked to the case. In the Rubaiyat they found few, if any, matches.

The 2010 analysis also proposed to take advantage of the vast quantities of information available on the internet to search for patterns occurring in the code. To do this, they created a simple web application and pattern matcher that could download a website’s contents and screen it for patterns. This is something we plan to extend this year, into a web-crawling application that can autonomously browse the web, searching for patterns.[4]

Something else both previous Adelaide University studies worked on was a Cipher Cross-Off list. This is a list of ciphers that were identified as potentially being used in encrypting the code. The purpose of this list is to test individual ciphers identified on it and attempt to rule them out as being used in creating the code (cross them off the list). The Cross-Off list is something we plan to continue in 2011.

Objectives

There are several goals that we plan to achieve in order to make our project successful and these are listed and explained below.

  1. Verify previous results.
  2. Continue the Cipher Cross-Off list.
  3. Create generally applicable Web-Crawling Pattern-Matcher.
  4. Crack the Code and Solve the Case???

As listed, firstly, we’d like to verify certain results gathered by previous years’ students including showing that the code is in fact consistent with an English initialism, as well as statistically analysing the pattern matches data obtained last year. Secondly, we plan to continue the Cipher Cross-Off list started in previous years, testing and ruling out as many ciphers as we can.

Also, extending on last year’s web pattern-matching application, an objective is to provide an ability to analyse vast amounts of data from numerous internet data sources autonomously. This will be achieved by building and integrating a web-crawler and pattern-matcher. The purpose of this is not only to try to shed light on the Somerton Man’s code, but to also provide a generally useful application that can accept a pattern or word stub and crawl the web for matches.

Finally, we could set ourselves the objective of cracking the code and solving the case. However, the code has not been solved in over 6 decades of attempts, so while we do hope to shed some light on what the code could be or mean, we are also realistic in our goals and the success of our project will not hinge on the code being cracked or the case being solved.

Background Theory

The three disciplines the project will be focusing on are cryptanalysis, web crawling and pattern matching. Cryptanalysis involves the conversion of encrypted messages into plain text without having initial knowledge of the key used in the encryption process. There are almost infinitely many possible ways the Somerton Man's code could have been encrypted, for example, through the use of transposition ciphers or substitution ciphers. Transposition ciphers involve swapping letter positions, for example ABC becomes CAB, or hello becomes lohel. Substitution ciphers encompass substituting letters for others based on a rule, for example shifting each letter along one, causing ABC to become BCD or hello to become ifmmp.

Web crawlers are programs that browse the web in an automated and orderly fashion, looking for data. Search Engines such as Google and Yahoo use web crawlers as a means of gathering data for their search results. Web crawler design is a complex process due to the sheer scale of the World Wide Web and the limited resources of a single computer program – a crawler can only process a tiny fraction of the web at any time. This creates a need to prioritise downloads and crawl the web in an efficient manner, so as to avoid spending resources downloading duplicate data (data that has already been downloaded).[5]

The other discipline the project focuses on, pattern matching, will be linked closely to the web crawler. Pattern matching involves detecting whether a specific pattern of letters or tokens is present in a section of data. Pattern matching can be used to detect both exact string matches as well as patterns of letters. For example, an exact string match may be used when searching for a segment of the code such as MLIABO, while a letter pattern search may be used in checking if the code is a substitution cipher by searching for patterns such as %%&%. In the Somerton Man's code, this pattern could correspond to TTMT, however, pattern matches could return results such as SSES.

Proposed Approach

Overview

The approach we propose to take in order to achieve our stated objectives is described diagrammatically in the figure below.

Proposed project approach for 2011
Proposed project approach for 2011

As the diagram shows, the project will be split into two main sections, Cryptanalysis and Mass Data Analysis. The cryptanalyst section will involve reviewing and verifying some previous results as well as performing some statistical analysis on data gathered in prior years. It will also include continuing work on the Cipher Cross-Off list and finally will provide direction for investigating the links between the Rubaiyat and the code. The other branch of our project involves creating an application that has the ability to crawl the web autonomously and search for patterns and word stubs. As the diagram suggests, this will be implemented in two stages, a web crawler and a pattern matching text parser. The technical details regarding this proposed approach are explained in the following sections.

Technical Details

Review and Verification

As identified, the first section to be completed is the review and verification of previous results. This will start with a review of the efforts made by students in previous years, including identifying and evaluating their conclusions. After the review is complete, select tests will be identified to verify these previous years’ results to ensure the results can be used as a basis for new work to be conducted in this project.

We expect the verification stage will include verifying that the code is in fact consistent with an English initialism and also statistical analysis of some of the pattern matching data gathered by the 2010 students.

Cryptanalysis

In the cryptanalysis section, a task that will be continued this year is the Cipher Cross-Off list. In continuing with the Cipher Cross-Off list, we will need to methodically test ciphers on the list to see if we can rule them out in being used in the creation of the Somerton Man’s code. In addition to this, the project includes room for identifying further ciphers that could potentially have been used in encrypting the code and adding these to the list for later testing.

The cryptanalysis section of the project also includes the specific study of the book linked closely to the code, the Rubaiyat of Omar Khayyam. This book will be subject to both close cryptanalytic and statistical examination in order to determine if it could provide the key to unlocking the code. In terms of the cryptanalytic examination, techniques such as the One-Time Pad will be investigated, while the statistical analysis will be aimed at identifying any structural coincidences between the code and the poems contained in the book. Specifically, given the code is four lines and each of the poems in the book contains four lines, statistical analysis will be used to examine the spread word numbers in each poem line to detect any relation to the number of letters in the code.

Web Crawler and Pattern Matcher Software

The web crawler and pattern matcher are to be implemented and tested separately before being integrated. A high level architecture of the integrated system is shown in the figure below.

Plan for Web Crawler and Pattern Matcher.
Plan for Web Crawler and Pattern Matcher.
Web Crawler

The key requirements of the web crawler and its proposed implementation process are defined below.

Key Requirements

  • Accept a URL or list of URLs in a text file as starting points from which to crawl.
  • Pass contents of web pages to Pattern Matcher.
  • Must be able to add all URL links contained in a visited page to its queue of URLs to visit.
  • Appropriately handle errors such as Web Page does not exist.
  • Must be able to read attached documents, including MS Word documents and .txt documents.
  • Must not revisit the same site multiple times unless new content has been uploaded.
  • Avoid infinite cycles such as when a page references itself.
  • Crawl as efficiently as possible and avoid downloading duplicate data.
  • Neat, commented and logical code designed in a modular style.


Implementation Process

  1. Evaluation of previous efforts
  2. Research and evaluation of Web Crawler implementation options
  3. Implementation of identified Web Crawler solution
  4. Test and Verification of Web Crawler

The implementation process will start with an evaluation of the 2010 effort. The purpose of this is to use their findings as a basis for this project's efforts. However, research will not be limited to examining the previous year's efforts. Wider research will be conducted to determine what implementation possibilities are best suited to the project's needs. This will include research into off-the-shelf, open source and self-designed options. Once the optimal option has been identified, it will be implemented and tested.

Pattern Matcher

The key requirements and proposed implementation process for the pattern matcher are specified below.

Key Requirements

  • Must be able to parse HTTP coded web page content
  • Detect encoded URL links and supply these back to the web crawler.
  • Must provide a flexible pattern matching service, disregarding punctuation, upper/lower case etc.
  • Must have an option to pattern-match data as whole words or as initials of words.
  • Detect both exact string matches and pattern matches.
  • Results must be stored in a results text file, with details including: Continuous or Initials match; Exact or Pattern match; website found on; line found in.
  • Neat, commented, logical and modular code.


Implementation Process

  1. Evaluation of previous efforts at pattern matcher code
  2. Design pattern matching algorithms
  3. Implement pattern matching algorithms
  4. Test and Verification of Pattern Matcher
  5. (Extension) GUI Interface development for pattern matcher


The implementation process for the Pattern Matcher will be similar to that of the web crawler. It will start with an evaluation of last year's work, before continuing onto the design of pattern matching code and algorithms. After implementation and test, the project allows room for the possible development of a Graphical User Interface (GUI) to make the application more user friendly.

System Integration

The completed web crawler and pattern matcher will be integrated with requirements and process as follows.

Key Requirements

  • Web Crawler passes web page contents to Pattern Matcher
  • Pattern Matcher returns any contained URLs to Web Crawler
  • Neat, commented, logical and modular code.


Implementation Process

  1. Design of Interface between Web Crawler and Pattern Matcher
  2. Implementation of interface between Web Crawler and Pattern Matcher
  3. Test and Verification of Integrated System


The key to the system integration implementation is the design of an interface between the web crawler and pattern matcher that enables smooth and issue-free process transition. Once this has been completed, implementation, test and verification can be performed on the integrated system.

Work Completed to Date

Project Management and Procedural setup

Substantial work was required on the project management component of the project to satisfy the deadlines that have already passed. As a result, derivation and implementation of all project management strategies and procedures have been completed. Each strategy utilises the work breakdown structure formed during the planning phase. The work breakdown structure, as outlined in the proposal seminar, was formed collectively by both project team members and distribution of tasks between each individual was included. The associated deliverables expected from all tasks has also been specified. After the work breakdown structure was determined, appropriate management mechanisms could be derived and implemented. The following project management tools have already been completed and are currently being used. A more detailed description of each one can be found in the relevant section below.

  • A comprehensive project schedule corresponding to the established work breakdown structure.
  • A project budget.
  • A management strategy to ensure progress is closely monitored and the project schedule is maintained. A Gantt chart detailing the work breakdown structure will be used in this process.
  • Risk Minimisation procedures in both a project and occupational health and safety capacity in accordance with the results of the respective assessments.

As will be discussed in the Project Management sections below it is the opinion of both project team members that the current project management strategies and procedures are performing to an acceptable standard thus review or modification of their structure or implementation is not required. Furthermore as a result of this success there is currently no intention to extend or expand the strategies in the next phase of project development.

Technical

In this early stage of the project limited technical work has been completed. As per the Gantt Chart schedule, however, the Review and Verification of the previous years’ efforts has commenced and internal reports summarising the results of this previous work have been produced. Along with this, early design has been started on the text parsing Pattern-Matching software and research into web crawler implementation possibilities has also commenced.

Project Management

Project Schedule

The project schedule can be seen diagrammatically in the Gantt chart below. Progress and planned dates indicated in the Gantt chart are up to date as of April 7 2011. The dates included as milestones correspond to the required project deliverables; including the Proposal Seminar (18 March), Stage 1 Progress Report (1 April), Stage 2 Progress Report (3 June), Final Seminar (30 September), Final Report including a video (21 October) and Project Exhibition including demonstration (28 October).

Gantt Chart

Current Gantt chart of project schedule.

Project development to date has required no timeline modification. Current progress is ahead of the planned schedule which in reflection can be attributed to the progress management strategy.

As was discussed in the proposal seminar, the progress management strategy is formed from several different mechanisms. Weekly team meetings and fortnightly supervisor meetings together with a Gmail Digital Calendar and Gantt chart will be used to regularly assess the status and progress of the project; as well as providing timely opportunities for redistributing individuals’ tasks and resources to ensure no milestones are jeopardised. Other contributing components are the progress reporting documents and the publicly accessible wiki page provided by the project supervisor. Both forums enable more extensive elaboration of the work completed and provide an opportunity for summarising discussions from team and supervisor meetings.

At this stage the weekly team meetings have been identified as particularly useful with fortnightly supervisor meetings and revision of the Gantt chart and digital calendar also important. Analysing the usefulness of the publicly accessible wiki page will be reserved for the Stage Two Progress Report as access for both team members was only recently granted.

Responsibility Breakdown

The following figure shows the breakdown of tasks between team members. It should be noted that this breakdown is neither exclusive nor final; it just gives an indication of the division of responsibilities. Flexibility has been included to enable this breakdown to be modified should progress reviews indicate the need.

Task assignment between Steven and Patrick.

Budget

Continuing on from the projected budget presented in the proposal seminar, the available budget balance remains at $500 (financed by the University of Adelaide). The early decision to use open source software (software freely available at no cost) in the proposed approach has ensured there is no variation from the initial planned budget at the current stage of development. The entire budget therefore remains provisioned for use as incidental expenditure, summarised in the table below. In addition to providing a contingency for addressing any unanticipated costs, it will also allow the flexibility to pursue additional services. One such service currently being contemplated is the use of professional handwriting analysis on the code obtained from the Rubaiyat of Omar Khayyam. Other potential uses will become more apparent as further project progress is made.

Summary of Budget Allocation

Items for purchase Cost
Incidental Expenditure $500
Total: $500

Risk Management

To formulate the project risk management plan presented in the proposal seminar, separate assessments of the both the Occupational Health and Safety (OHS) and Project risks were conducted. The presentation time available for the proposal seminar did not allow for a detailed review of these assessments and thus a summary of their derivation and findings has been included here. In addition, there is a review of all corresponding risk management strategies as outlined in the proposal seminar; accompanied by a discussion of their effectiveness from induction to the current stage of development.

Project Risk Assessment and Management

The identified project risks and planned risk reduction strategies for the 2011 Code Cracking Honours Project have been listed below. Each risk has a corresponding risk estimation detailing the potential impact the risk poses to the overall project. The risk level estimator used can be seen below the risks. It uses an estimate of the probability that the risk occurs and an estimate of the consequences on the project if the risk was to eventuate. The risk level estimator was derived from the one presented to all Honours students in the Risk Analysis lecture.

Summary of Project Risks
Risk Probability Consequence Risk Estimation
Availability of personnel Multiple occurrences Serious problem High
Insufficient financial resources Unlikely Catastrophic problem Medium
Access to software development tools Multiple occurrences Serious problem High
Unable to maintain software development schedule Unlikely Serious problem Medium
The Somerton Man case is solved Unlikely Moderate problem Low
Project Risks

Availability of personnel (Risk estimation: High)

The time available for the project will depend on the schedules of both team members. The risk is made more prominent by both team members undertaking full time university study in different disciplines and this is reflected in the high probability. In addition to having deadlines relating to external courses that may interfere with the project there is also the possibility a team member becomes ill. In either case, work on the project would be severely impacted by limited team member availability and hence a high consequence was also deemed to be required. (Probability: Multiple occurrences, Consequence: Serious problem)

The risk reduction strategy for minimising the influence of external deadlines and schedule conflicts is to use the weekly team meetings to regularly update each team member of the other’s impending schedule and reallocate resources and tasks accordingly. The project schedule was designed specifically to include float for use in this case. The schedule float will also be used in the event a team member is unavailable due to ill health.

Presently no float has been required to accommodate external deadlines or illness for either team member thus comments cannot be made on the effectiveness of the risk reduction strategy.


Insufficient financial resources (Risk estimation: Medium)

Corresponding with the discussion in the Budget section above, restrictions on development due to financial constraints is unlikely to occur with this project; hence a low probability was used. In the instance financial resources are insufficient project work would be impacted severely, possibly even halting development whilst a resolution is sought, yielding a high value for consequence. (Probability: Unlikely, Consequence: Catastrophic problem)

To reduce the risk of financial resources being used up prematurely, a project budget was established. Included in this budget was the decision to utilise open source software for development thus nullifying the cost of software for the project. As a result, the likelihood financial restrictions are imposed on project development is significantly reduced.

The effectiveness of the implemented project budget has been apparent even at this early stage; as no financial resources have been required even with progress ahead of schedule. Thus the current decision coincides with the one made during the project planning phase and the original projected budget needs no update.


Access to software development tools (Risk estimation: High)

The ability to access appropriate software for project development whilst on the university campus is critical for ensuring adequate progress. The consequence selected reflects this significance. Despite the opening of additional computer resources in Innova21, the specialised software required by both team members further limits the potential resources available and thus the probability of this risk occurring was also deemed to be significant. (Probability: Multiple occurrences, Consequence: Serious problem)

The risk reduction strategy employed in this case is to utilise the personal laptop computers of each team member to enable access even in the worst case scenario of no university resources being available.

One team member has already benefited from the use of their personal computer whilst at the university campus in accordance with the risk management strategy. This was seen as validation of a successful risk mitigation scheme and it has been decided by both team members that no modifications to the current planned strategy are required at this stage of development.


Unable to maintain software development schedule (Risk estimation: Medium)

Timely completion of the project is strongly dependent on the development team being able to abide by the project schedule, described in detail in the Gantt chart above. A high consequence to reflect this significance was deemed necessary. Protocols already established in the progress management strategy have reduced the likelihood of this risk occurring and hence a low probability was chosen. The progress management strategy also serves as the reduction mechanism for this risk. Details of the progress management strategy can be found in the corresponding section below. (Probability: Unlikely, Consequence: Serious problem)

Up to this stage of development all required project deliverables have been submitted prior to their respective deadline as planned in the project schedule. Therefore it is the decision of both team members that the planned schedule does not need to be modified for the next phase of project development. As described below in the progress management strategy this decision may be revised following review of the progress in weekly team meetings or fortnightly supervisor meetings.


The Somerton Man case is resolved (Risk estimation: Low)

The Somerton Man murder case has remained unsolved for 62 years and as a consequence, like with the project team, extensive interest has developed. The possibility of the case being solved outside the project is remote and is reflected in a low estimation for probability; however a large potential impact is still evident. Although an external resolution to the case would reduce the public importance of the research findings, the scope of the project has been specified to ensure the project deliverables are generic allowing them to be used in several other implementations. As a result the consequence is low. (Probability: Unlikely, Consequence: Moderate problem)

Currently there is no risk reduction strategy in place for this risk due to the uncontrollable nature of its origins. Since there is no risk reduction strategy there is no comment to be made regarding its effectiveness during the previous five weeks.

Project Risk Level Estimator
Probability
Consequence Practically Impossible Unlikely Rare to occur Multiple occurrences Regularly occurs
Minor inconvenience (no impact on project) Negligible Very Low Low Medium Medium
Moderate problem (minimum impact to project) Very Low Low Medium Medium High
Serious problem (singificant impact to project) Low Medium Medium High Urgent
Catastrophic problem (project unlikely to be completed) Medium Medium High Urgent Critical

Occupational Health and Safety Risk Assessment

The purpose of the OHS risk assessment was to identify the potential health hazards that may be encountered whilst completing the project. Accompanying each risk is a corresponding risk reduction strategy and risk estimation. The risk estimations were derived using the same Risk Level Estimator as provided to all honours students in the Risk Analysis lecture, with identical probability and consequence scales. The Risk Level Estimator is shown below the risks.

Summary of Occupational Health and Safety Risks
Risk Probability Consequence Risk Estimation
Physical Hazards
External construction noise Known to occur Minor illness or injury Medium
Falls within laboratory Not likely to occur Serious illness or injury Medium
Injuries due to electrical shock Not likely to occur Serious illness or injury Medium
Chemical Hazards
None - - -
Biological Hazards
None - - -
Ergonomic Hazards
Work place layout Not likely to occur Moderate illness or injury Low
Radiation Hazards
None - - -
Psychological Hazards
Work related stress Known to occur Moderate illness or injury Medium
Repetitive tasks Known to be a common or repeating occurrence Minor illness or injury Medium


Both project team members believe the Occupational Health and Safety policy implemented by the University of Adelaide has and will continue to be sufficient in minimising the risk of physical hazards. Relocation of the honours practical laboratory to an adequate distance from the current construction site has reduced any potential hazard relating to the generated noise. Also the stringent guidelines for using the practical laboratory ensure the risk of electrical shock or falling in the laboratory is mitigated in accordance with the Occupational Health and Safety policy requirements.

The next most serious hazard concern highlighted by the risk assessment was psychological hazards, specifically relating to stress and the repetition of tasks. During planning it was decided that each team member would be responsible for their own psychological health to ensure there was minimal likelihood of problems in this area influencing overall project development. During the first phase of project development there have been no instances to suggest the policy needs revising and therefore the current arrangement will continue to be used.

To reduce the risk of work place layout becoming a significant ergonomic hazard it was decided by both team members that all workstations used will be arranged according to the University of Adelaide Workstation Ergonomics guidelines.[6] Both team members agree this has and will continue to be sufficient; subsequently ergonomic hazards have been given a low classification in the risk assessment.

Occupational Health and Safety Risk Level Estimator
Probability
Consequence Practically Impossible Not likely to occur Could occur (i.e. heard of it happening ) Known to occur (i.e. has happened in the past) Known to be a common or repeating occurence
Minor illness or injury Negligible Very Low Low Medium Medium
Moderate illness or injury Very Low Low Medium Medium High
Serious illness or injury Low Medium Medium High Urgent
Fatality or permanent disability Medium Medium High Urgent Critical

Conclusion

This project is structured around providing insight into an as yet un-deciphered code from an historic South Australian murder cold case. However, the scope of the project is such that its success does not depend on the code being cracked or the case being solved. While cryptanalytic examination of the code comprises of a large part of the project, another major component is the development of a generally applicable pattern matching web crawler. The progress on the project to date includes the completion of initial reviews of work done in previous years as well as research into the implementation possibilities of web crawlers and pattern matching algorithms.

From the perspective of Project Management, the project is currently slightly ahead of schedule and progress management strategies have been implemented to ensure it has the best opportunity to stay ahead. Potential sources of both Project risks and Occupational Health and Safety risks have been identified and corresponding risk management strategies have been put in place to limit their possible effects.

At this early stage, we are confident the project is on course for a successful outcome.

References

See also