MECHENG401:ProjectProposal

Home

Due date: Thursday 10 April, by 5.00 pm.

Your project proposal will need to be understood by both your client partner and your mentor.
It therefore needs to be fully explanatory, but be understood by someone who may have no technical expertise in your area.

Your proposal should clearly explain the following:
1. The objectives of your proposed work.
2. How you are proposing to tackle it.
3. The time frame for each stage.
4. Facilities, resources, equipment and technical help needed.

Your report should therefore do the following:

• Emphasise the potential advantages of your activities to the organisation.
  
• Use a Glossary of Terms to clearly explain terminology that may not be familiar to the client organisation.
  
• Be written in language that does not need expert knowledge to be understood. But it shouldn't be oversimplified.
  
• Be very concise, well presented and clearly worded, without elaborate justifications or full descriptions of technical techniques.
  

Overview of Proposal Format

1. Cover Page - 1 page
2. Executive Summary
3. Table of Contents
4. Introduction, including motivation and problem identification
5. Project Description
6. Team Organization
7. Project Planning Schedule
8. Resources and Needs
9. Team Background
10. Appendices (if needed)

BEWARE: What follows is a rough brain dump. Requires hard hat and soft expectations when inspecting.

---

Cover Page

Software development for seismic assessment of Auckland buildings

for Auckland City Council

Department of Electrical and Computer Engineering

Mark Gardiner Nick Irvine Shaun Seo

{mgar059, nirv002, sseo004}@ec.auckland.ac.nz

due 10 April 2008

---

Executive Summary

The Building Act 2004 introduces a requirement for territorial authorities such as local councils to create guidelines (???) on dealing with earthquake prone buildings in their region. Many buildings in the Auckland region are in such a state that they are in large danger from seismic activity. The Auckland City Council wants to assess these buildings to find which ones would be at risk in an earthquake. The process of assessing and analysing these buildings is well suited to, and could be made easier by, an electronic process.

We plan to produce a system which makes it easy for the council to input, store and process this information. This will involve creating a database to hold all the related information, such as physical attributes of each building and supporting photographs, and an application to support the data entry and display. We need to create a system which can then evaluate this information and present the relevant information as a pdf report to assessors, council workers and policy makers. The system should be scalable nationally and compatible with future/other council systems.

The benefits of such a system will be reduced cost and effort in assessing buildings for their earthquake-proneness, and thus faster and better guidelines for dealing with such buildings in the case of an earthquake. This has benefits for the Auckland city Council and the safety of the people of Auckland.

The tasks involved are research, design and implementation. During the design and implementation phases user input will be gathered from team members who are using the system to assess buildings.

The project has unique requirements, such as the need for synchronising the contents of two databases, that make it a challenge. some more....

Introduction

Section 1: Introduction (1 page max)

The introduction should provide the following information:
* Motivation for what you are doing: concise statement of your client’s needs, constraints, and resources
* Problem identification: concise statement of the specific problem(s) you will be addressing

Motivation:
With the introduction of the The Building Act 2004, territorial authorities such as city councils were obligated to comply by certain building regulations. One such regulation is that the council must have in place a plan for dealing with earthquake prone buildings. The Auckland City Council needs a system for identifying which buildings are earthquake prone. Territorial authorities can issue notices requiring owners to deal with issues with earthquake-prone buildings. If there are immediate dangers or issues, territorial authorities can take action themselves and owners will be liable for the costs. Also, councils must adopt policies on dangerous, earthquake-prone and insanitary buildings before 31 May 2006.Council workers will have to survey each building in the Auckland region and assess and classify it according to criteria set out in the Building Act 2004. Currently the recording, analysing and reporting processes are done manually and they are both time consuming and costly. This project aims to automate these processes through researching, designing and implementing a computer based system for the data input, data analysis and report generation for the Initial Evaluation Procedure (IEP). The aim is that council officers can install the application on their laptop, and take with them a portion of the existing data when they go on site to assess buildings. This will be useful as otherwise the data entry must be done twice, once by hand and again into a computer. This can be error prone and time consuming. They can use the application in the field to immediately enter the data, and then load that data back into the central data store later. They can also edit information about a building and have that information be updated in the central store. The reports generated must be in pdf format and stored safely so that they can be accessed and referred to in developing strategies on earthquake prone buildings. For this reason it is also essential that the data on buildings is stored in such a way that it can be queried to answer such questions as 'How many earthquake prone buildings are there in this area?'.
It is important that this system be implemented quickly, and is easily usable so that benefit from it can be seen immediately. The benefits will be to the ACC, and also to the people of Auckland and eventually all of New Zealand as this system aids territorial authorities in developing quality strategies to deal with earthquake prone buildings.
It is desirable to use open-source or public domain software to keep the costs as low as possible.

Problem Identification:
There are several key problems with developing this system. These lie in the areas of:

• Data storage
  • What is the best technology to use to store the necessary data? What form should it be stored in?
• Data entry
  • How can we make the user interface easy to use for non technical personnel, while still offering advanced features to other users.
• Data analysis
  • The analysis of the data according to the IEP should be done automatically and accurately
• Report generation
  • Reports must be generated in pdf format and stored in the database.
• Synchronisation support for merging data entered in a local database with data held on a central database
  • This is a non-trivial problem that may require a novel solution to be developed by us

Project Description

Section 2: Project Description (2 pages max)

How you propose to solve the problem(s): describe the approaches you will consider in attacking the problem; identify the relevant
issues you will need to consider; and summarise the expected outcomes.

If your project consists of several tasks, the Project Description should start with a single paragraph that introduces all of your
team's tasks. The remainder of this section should then consist of one subsection for each task.

The tasks of this team are to research, design, and develop an application that can support the Auckland City Council(ACC) in meeting some of its obligations under the Building Act 2004. These obligations are to do with a strategy to deal with Earthquake prone buildings. Firstly, the application must provide a locally accessible database to store all the necessary data. It must also allow a council officer to take part of the database with them as they enter data on site, and merge changes or additions to that data back into the central database when they are done. A second aspect to the project is the report generation application. From the data in the database, our application must be able to generate reports in Adobe pdf format, and analyse a building to determine if it must be surveyed further.<br/>
The challenge that the ACC faces is being faced by all territorial authorities in New Zealand. The system which we develop should be suitable to present to all territorial authorities as a solution to their needs. This means that the database developed should be able to be scalable to the whole of New Zealand.


Remove this section as it is already covered in the introduction/motivation????

The problem to be solved is a difficult one. There are several requirements of this project that make it both unique and challenging.

Research

The synchronisation at the database level of photos, text and numbers is not a problem that has been solved by any technology that we know of. Therefore in the research task we must spend significant time in researching technologies that may allow us to do this. Some areas that we have considered for further research are the Adobe Integrated Runtime (AIR) framework, Groupware like Lotus notes, and Google Gears. An alternative solution, if an existing one cannot be found, is to create our own. If designed and implemented in a reusable way, this could be a very positive contribution to the developer community.
The outcome of our research task will be a decision on which technology solution to use in our implementation

Design

The development of an architecture and design for our solution will be guided by current best practice and the constraints provided by the requirements. The preliminary suggestion is for a three tier architecture, with hardware provided by the ACC to host application and database servers, and a web based user interface. The benefit of creating our solution in this fashion is that by installing database and application servers on a laptop, a council officer may use the program in the field exactly as if they were using it in their office. This solution needs to be researched and analysed for suitability, to ensure it meets the security and scalability requirements of the client.
The outcome of the design task will be a robust, secure and above all scalable architecture and design for our final solution.

Develop

The development of the system will take a large portion of our time.
The outcome of the development task will be a prototype system that meets all the clients key functional requirements. That is, it will support the entering and storing of all the necessary data, the generation of reports from this data, and the ability to use the system on a laptop on site and have the data entered be synchronised with the central database.

Further development

The outcome of the further development task will be improvements to the prototype system....

Team Organization

Section 3: Team Organisation (½ page)

Summarize your team's organization (i.e., who is doing what) with respect to both the overall team and the major tasks of your
project.

The team is organised into 2 parts. There are 3 part 4 Software Engineering students and 2 Computer Science academic staff working on the software aspects of the project.

Alongside this are 2 part 4 Civil Engineering students doing a 4th year project with CE academic staff. They will be associated with the project, and their tasks will be to take part in data collection and analysis, providing feedback on usability and features of the software. They will also provide the in-the-field testing of the mobile component of the software system.

Further to this, there is a part three Engineering Science student who is voluntarily assisting both sides of the project.

The software team will follow the Agile project management approach. The Agile approach is a proven software development methodology where members of the team move around roles, so that the team is not reliant upon any one person. Each of the team members will have input in all areas of the project, and in depth understanding. All three team members are experienced in this approach and it was decided to be the most effective approach for the team.

Nick Irvine will be in charge of a mailing list to notify all members of important events or meetings.

There will be no website administrator, rather all work will be carried out collaboratively on the Software Engineering wiki (https://www.se.auckland.ac.nz/wiki2008/index.php?title=MECHENG401)

Project Planning Schedule

Section 4: Project Planning

Give a projected schedule for your project. Use a Gantt chart. This shows how the various tasks are scheduled and  integrated with
each other over the year. See also the EPICS Purdue website: Notes on project planning: (broken link given)

	Activity	Mar	Apr	May	Jun	July	Aug	Sept	Oct	Total Hours
1.	Project Setup	10								.
2.	Define Requirements	5								.
3.	Research	20								.
4.	Define/Refine Scope		10	1	1	1	1	1		.
5.	Project Proposal		10							.
6.	Implementation - GUI		10	5	5	5				.
7.	Implementation - Database		10	5	5	5	5	5		.
8.	Implementation - Client webpage		10	5	5	5	5			.
9.	Implementataion - IEP Module			10	4	4	4			.
10.	Prototype - Populate DB		5							.
11.	Test - Prototype		3							.
12.	Progress Report				10					.
13.	Implementation - Offline capability			30						.
14.	Implementaiton - Synchronisation			30						.
15.	Unit Test - Offline Capability						8			.
16.	Unit Test - Synchronisation						8			.
17.	Unit Test - Client webpage			4	4	4	4			.
18.	Unit Test - IEP Module			4	4	4	8			.
19.	Informal Usability Test - GUI					2				.
20.	Integration Test - Entire System						4	4	10	.
21.	Poster							5		.
22.	Final Presentation							5		.
23.	Final Report						5	10		.
	Total Hours									...

Resources and Needs

Section 5: Resources and Needs (1 page max)
* Equipment/software needed to get started.
* List of relevant equipment already available.
* Equipment/software you expect to need later.
* Outside resources you may draw on.
* Space required.

• Equipment/software needed to get started.
  • None
• List of relevant equipment already available.
  • Standard PC's for general use.
• Equipment/software you expect to need later.
  • Physical server to host a web server and database server (On client premises)
• Outside resources you may draw on.
  • People
  • Building regulations etc
• Space required.
  • none

This project will focus on the development of a software solution to record, store, and control information. This is exemplary of a database system and this will most certainly be the basis for our software. To build our tool we will draw upon the Java programming language, which will perform the manipulation of information, and is readily available on the university laboratory computers. To work with Java we will use the Eclipse IDE and some form of version control. To store and retrieve the information we will use a database implementation such as MySQL or Firebird.

We will be drawing a lot of information from the internet and technical documents which outline the assessment process and guidelines for surveying buildings. We will also work with 2 part four civil engineering students to better understand the system from a users point of view.

All the resources the team needs for development are largely in place and available. The main resources we need for this project are; access to computers, time, and the technical knowledge of the process.

A large part of the time spent on this project will be on computers. Access to computers and the internet is very important. We will mainly be using university laboratory computers for the research and development needed by the project. It is likely that most of the required software will be on the lab computers or freely accessible on them. There is a slim possibility that some proprietary software may be needed in the future.

Team Background

The Software Engineering members of the team have all been through the SE degree at the same time. We have completed papers on fundamentals of database systems, Java programming, Software design and architecture and many others. We also all had the opportunity to work over the period November 2007 to February 2008 with Orion Health and the CSI academy, where we could practice software development in a real situation. These experiences have given us a solid background to apply to this project.

Nick Irvine

• 4th year SE student
• Deans list 2007
• Software Engineering prize 2007

Shaun Seo

• 5th year BE(SE)/BCom student
• 2007 President of Auckland University Collaboration Group, an AUSA affiliated student club
• 2008 Group Leader of Software Engineering Discussion Initiative

Mark Gardiner

• 4th year SE student
• Events manager for SESA, the Software Engineering Students Association
• Webmaster for Azion