Project 2
Student id: v26
To select another student or project, return to the Project Page.
<?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="../schema_3302.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?>
<!--the second line in the document associates the schema, so be sure not to change it-->
<DOC>
<docHead>
<!--required header includes metadata about the assignment (title, author, version)-->
<title>Writing Project 2 - Phase 2</title>
<author xml:id="v26">Michael Van Wickle</author>
<version n="2" date="2016-08-09"/>
</docHead>
<fsb_rpt>
<!-- container element for writing project 2. Contains any number of pages. -->
<page type="ttl">
<title>Distributed Weather Data Collection System: Feasibility Report</title>
<date>August 1st, 2016</date>
<contributors>Michael Van Wickle</contributors>
</page>
<!-- Todo: Report -->
<page type="tbl_contents">
<sect n="1" lvl="1">Executive Summary</sect>
<sect n="2" lvl="1">Preliminary Requirements Analysis</sect>
<sect n="1" lvl="2">Application Overview</sect>
<sect n="1" lvl="3">Objectives</sect>
<sect n="3" lvl="1">Technical Feasibility</sect>
<sect n="1" lvl="2">Overview</sect>
<sect n="4" lvl="1">Success Criteria</sect>
<sect n="5" lvl="1">Design</sect>
<sect n="6" lvl="1">Cost</sect>
<sect n="7" lvl="1">Report</sect>
<sect n="8" lvl="1">Risk Analysis</sect>
<sect n="9" lvl="1">Conclusion</sect>
<sect n="1" lvl="2">Feasibility</sect>
<sect n="2" lvl="2">Feasibility Conditions</sect>
<sect n="3" lvl="2">Summary</sect>
</page>
<page type="exec_sum"> The system outlined in this study is a distributed method for the
collection of weather-related data. The system consists of a network of
micro-controllers with attached sensors to measure temperature and pressure. Associated
with this system is a web application for the viewing and acquisition of collected data.
The distributed nature of the system allows for a more granular view of weather data,
allowing for better reporting and prediction of weather patterns. In addition, this
system will attempt to be as open as possible as to effect the best possible analysis.
<pb/> Based on preliminary research, this project is feasible. </page>
<page type="pre_req_ana">
<app_ovr type="obj"> The primary functionality provided is a system that collects
weather data, specifically temperature and pressure, in a highly distributed manner.
Micro-controllers will host the sensors that directly collect data; they will also
contain networking functionality in order to send data to a centralized database.
The data will be exposed to the public via a web application. Features provided by
the web application include direct download of the data and visualizations based on
the data. </app_ovr>
</page>
<page type="fsb">
<fsb_hlgt type="tcnl" n="1"> This project has two broad components<note
type="instructor" resp="#kgs">I'm a bit surprised that these aren't separated
into two fsb_hlght elements, but I could see the argument that they are so
integrated as to be inseparable</note>, the sensor and the web applications. The
sensor portion is composed of a micro-controller and multiple sensors. The
micro-controller will also have some form of network connection and possibly some
form of rudimentary data filtering mechanism. Network connectivity will be in the
form of an ad-hoc network between all of the devices, with certain devices used as
"exit nodes" which connect to the internet at large in order to upload to a central
database and, by extension, the web application. Sensors to be included are for
temperature (thermometer) and pressure (barometer). Data sent to the central
database will be a timestamp, location data, and the data collected by the sensors.
The web application is build<note type="instructor" resp="#kgs">built</note> on top
of a database containing the data sent from the sensors. The two main features for
the web application are data download and visualization creation. </fsb_hlgt>
</page>
<page type="sccs_crt">
<req_sect><note type="instructor" resp="#kgs">this page really turned out nicely; it
follows very well from the previous page and really outlines the components of
the project</note> Sensors <req n="1" title="Micro-Controller">The base
platform, essentially a small computer which provides power to all of the other
components. It also may contain some basic data filtering software in order to
prune noise from the collected data. </req>
<req n="2" title="Network Connectivity">The sensors will be connected via an ad-hoc
network model. In this model, most units will only be connected to other units.
Pre-programed into each unit, will be the routing data which provides a path to
a unit that has connection to the actual internet (an "exit node"). Thus, each
unit will push its data towards the unit that is "closer" to an "exit node"
until the data is pushed to the database. </req>
<req n="3" title="Temperature Sensor">A basic thermometer, this will collect the
temperature at an appropriate precision. </req>
<req n="4" title="Pressure Sensor">A barometer, this will collect pressure data at
an appropriate precision. </req>
<req n="5" title="Location Data">In order for the system to work, each sensor must
have its own location. This will be programmed in upon installation, likely in
the form of a latitude, longitude pair. </req>
</req_sect>
<req_sect> Web Application <req n="1" title="User Interface">The user interface should
provide easy and intuitive access to all of the functionality provided. The
interface should be optimized for use on desktop computers of all screen sizes.
It also should have at least the basic ability to be used on mobile devices. </req>
<req n="2" title="Data Download">Data download is the ability to pull ranges of data
and possibly all data from the database. Also provided is the ability to
download data in many different formats. </req>
<req n="3" title="Visualizations">This feature will create various forms of visual
representations of the data. This includes map overlays of the data, animations
of the data, and various charts that show changes in the data over time. </req>
</req_sect>
</page>
<page type="dsn">
<img url="https://cdn-shop.adafruit.com/1200x900/50-07.jpg"> Potential Micro-Controller
(Arduino Uno) </img>
</page>
<page type="cost">
<est type="fnc"> This<note type="instructor" resp="#kgs">these</note> sensors could use
many commercial off the shelf products. For the micro-controller, an Arduino based
chip could be used. These kinds of controllers are widely available and have the
additional advantage of being open-source. The cheapest appropriate model would be
rather expensive at fifteen to twenty dollars, but that price could go down as the
boards are bought in bulk. Sensors provided by the Arduino project could also be
used. A temperature sensor costs around one dollar and fifty cents and a pressure
sensor costs around five dollars. Both of these prices, as with the chip, could go
down with bulk purchases. The most expensive piece of equipment to buy would be
network connectivity module, which would likely cost more than twenty dollars.
Assuming a cost of twenty dollars for both the chip and the network module, this
adds up to an overall cost of about forty seven dollars per unit. This price seems
quite restrictive on the surface, but the price could decrease with bulk pricing
and/or the possible development of specialized micro-controllers. </est>
<est type="fnc"> The costs for the web application consist of payment to developers and
hosting fees. </est>
</page>
<page type="rpt">
<tmln n="1" date="2017-01-01"> Complete research into technical feasibility. Begin
research into implementation details, i.e., actual components, financial details. </tmln>
<tmln n="2" date="2017-02-01"> Complete implementation details. Begin creation of proof
of concept. </tmln>
<tmln n="3" date="2017-03-01"> Show proof of concept to potential investors and/or
public officials. </tmln>
<tmln n="4" date="2016-04-01"> Obtain funding. Begin actual implementation. </tmln>
</page>
<page type="rsk_ana"> Potential risks to this system include, but are not limited to, loss
of funding and public disinterest in the project<note type="instructor" resp="#kgs"
>because the funding model is based on people paying for the app?</note>. These two
risks are intertwined as each can lead to the other. Mitigating the risk of public
disinterest could be achieved by hiring a public relations firm to create and/or
maintain enthusiasm for a distributed weather system. <pb/> Causes of funding loss for
the project depend on the actual source of said funding.<note type="instructor"
resp="#kgs">glad you're addressing this</note> If most of the financing for the
project is public, disinterest in the project is a likely cause, which was discussed in
the previous paragraph. If funding is generally private, the causes are numerous and
mitigation strategies more nebulous and possibly less effective. Again, a downturn in
public opinion could reduce funding. The most general and likely cause of private
funding loss is the fiscal state of the company providing funding. Once a downturn of
the funding company has started, it is out of the hands of the executors of this
project. The only real way to reduce this risk is to choose a funding company that
stable for the foreseeable future. </page>
<page type="conc">
<fsb> Based on preliminary research, this project seems to be technologically feasible.
From a practical perspective, these systems should be designed to be deployed in
small segments, e.g., a neighborhood, as deploying in a entire city at one time
would be fiscally and technically challenging.<note type="instructor" resp="#kgs"
>excellent point</note>
</fsb>
<cond> The main hurdle to any actual implementation of this project is funding. A
significant amount of the funding to this project would likely need to be public.
The need for public funding necessitates a campaign in order to drum up general
support for this project. </cond>
<sum> This is a project that would provide more granular and open granular weather data.
The described implementation is made of commercially available, common parts. This
system is quite feasible in the current environment. </sum>
</page>
</fsb_rpt>
<docReview>
<reviewer type="peer" xml:id="m19"/>
<report type="peer" resp="#m19">
<p>For Project 2, Michael wrote a feasibility report for a distributed weather data
collection system which he believes is feasible. This system consists of a network
to measure temperature and pressure and a web application to collect and view the
data. ere.</p>
<p>A feasibility report would be written in response to the question of a project or
idea being feasible, and these reports include logical, factual data to support
their claims. Michael’s writing for Project 2 follows this genre, as shown by his
explanation of his project, his supporting evidence, and his position that it is
feasible. As an expert in this genre, Michael’s sentences are appropriate. They
communicate facts of his weather data collection system in a direct manner, and they
do not include emotional pleas to support his belief that his project is feasible.
His word choices are appropriate as they deal with many technical aspects of his
project. For example, he details system components like micro-controllers, data
visualization, and exit nodes. One major missing piece is a section for risk
analysis. This is important to a feasibility report so that any major concerns over
the project can be addressed. This helps answer if a project is feasible despite
possible complications. Another element that could be included is a design. Some
type of diagram could show how the sensor network could communicate with a central
database and eventually a web application. Also a report section could be added to
detail how progress would be reported on the project. </p>
<p>Overall, the structure of Michael’s feasibility report conforms to the schema that
our group created. He mentioned in his peer review memo that he was concerned that
he used too many idioms. However, I did not see this, and I believe that his
language and sentences were appropriate. Michael also had questions about the
distinction between the preliminary requirements and success criteria section. I
think that his success criteria section was effective in showing the different
components of his project. However, I think that to differentiate the preliminary
requirements from it, he could add information for types rls (rules and regulations
encountered) and synergy (how his project interacts with any existing systems).
Lastly I think that he could add the missing elements referenced earlier in order to
make his feasibility report more complete. </p>
</report>
<reviewer type="instructor" xml:id="kgs"/>
<report type="instructor" resp="#kgs">
<p>This is a great example of a feasibility report--it is well thought out and well
researched. I am fascinated by the potential for this project, as well. Your success
criteria section, in particular, stands out as especially thorough and well done.
Throughout you maintain an appropriate tone for the genre. Pay attention to the
minor questions and corrections I added in the in-text comments. On the whole, very
well done!</p>
</report>
</docReview>
</DOC>