Phase 1 (Proposal)

Our team was asked to make a proposal document and send it to our company Sponsor John Markham. In the proposal we discussed: The basic definition and benefits of the project, our research results, the requirements, specifications, and constraints of the project, the design we had so far, and our proposed schedule. Below is a design model of our project and the selected schedule we decided to use. For information on our research or a definition of or project or its benefits please click on the links above.

Phase 2 (Decision)

Description

The team is currently still in the software or programming stage of the design. Currently we are still using both Apple and Android software. First stage is playing with the code, trying to get it to perform the basics of our project. Stage two is testing, and stage 3, if necessary is hardware.

As part of this design process, the team has begun the process of becoming familiar with the development software. In doing so, we have started the design of our application’s GUI including the format and locations of different features we would like to implement in the later stages of our design. The team has also implemented single-user GPS positioning within our application allowing the location of our user on a Google provided map.

In order to assist in the design and scheduling of our project, the team elected to research and evaluate several common design schemes that are used within industry in the design of similar software development projects. Online research that was conducted was complimented with information obtained from conversation with our client in which we discussed similar design schemes used specifically within Cobham.

Stage-Gate

This design scheme is characterized by its highly structured design in which a project is divided into stages and separated by gates. At each gate, the continuation of the project is decided by a governing party. The governing party within the scope of this project would be the team itself with a majority vote deciding the action to be taken at each gate.

Scrum

The scrum design scheme is an iterative and incremental software development framework for managing product development. It is defined as a flexible and holistic product development strategy where a development team works as a unit to reach common goals throughout the process. Contact with our client has eluded to this scheme being used to breakdown large projects into smaller features that are to be completed throughout the course of the project.

V-Model

This design scheme has a structure much like that of the stage-gate design model. This structure breaks projects down into steps with each completed phase acting as the base for the steps or processes following it. Unlike the stage-gate model, the V-model works both horizontally and vertically allowing the team to revisit issues within a project rather than strict linear design.

The design strategy that our team has elected to take was chosen due to the heavily intensive programming involved with the design of this project. Our design for this project will use the scrum scheduling model which is used with many popular software development companies within the industry. This design approach will divide the design of our software application into features that we wish to address/implement within each design period.

Our team decided to choose this design method as it provides the most organized design format by splitting the work into features rather than attacking chunks of code at given times and taking whatever progress was made in those sessions as complete. By attacking it in this manner, the team can better track its progress throughout the design process and also minimize risk as delays in the design schedule are more easily identified.

Constraints

Cost

The team granted 500 dollars as a budget for the whole project so that the team cannot spend more than $500 on this project. The team has found one satellite communicator for almost 300 dollars so if the team need two satellite communicators, the team will go beyond the limited budget. This constraint has made the team rethink about what things that are not expensive and things we can buy. The team has decided to use more software than hardware parts due to the limited budget. Using software will help the team to reduce the cost because the team will be using free software applications which can be used instead of the hardware.

Manufacturability

Following hand-in-hand with our established constraint regarding cost, the manufacturability of our finished product relies heavily on the cost to produce each device used within our system. Due to our teams’ design being left with little room for manufacturing expenses, our finished product must be trivial to manufacture. Ideally, the cost to produce each of the ten devices used within our system should require zero effort resulting in near-zero cost. Because of this constraint, our team will use the smart phone devices already in our users’ possession resulting in zero cost and no extra manufacturing on our design’s end. In doing so, all that is needed to have a functioning product is the application to be installed on the users’ smart phones.

Ethical

Ethical problems come in when asked “What else can this product do?” Although we want this product to be used by rescue teams and government authorities, can our product we stolen and use for something different? Such as stalking and spying on citizens. Although we have no control over what happens to this device after it is sold, this team wants to make sure nothing such as that can happen. Solutions to this might be to put a password on each product before it is sold, so only officials can use it. Defensive measures can also be taken by whatever company the devices were sold to. They can make sure all products are accounted for and locked up at the end of the day. As stated we cannot make sure these things happen, but we will do everything in our power to make sure they do.

Safety

The team does not expect anyone to get hurt from using the device as advertised. Our safety ideas lie elsewhere though. A problem could occur if someone were to hack the signal our device was using and ether be able to follow someone using it unnoticed, or stop all users from using it. Keep in mind this wouldn’t be your everyday hacker, but perhaps a terrorist trying to stop our rescue teams from completing their mission.

Final Phase (agreement)

We sent our client John our final proposal on November 24, 2014. He read it over and signed and sent it back to our team on December 12, 2014.