Project Proposal

A Block of Code

Senior Capstone Project Proposal V2.2

Needs Statement

Today’s world is one of interconnected technologies, at the heart of which are devices like computers and micro-controllers. As the technological complexity of our world increases we will find our society increasingly reliant on the men and women who know how to operate and control these devices.

However as of today no universally accessible curriculum includes a focus on the knowledge and skills needed to program these machines. We have need of any system that can help children learn and understand these concepts. Additionally, the long term effectiveness of any system will depend on both it’s ease of use and it’s accessibility across a large range communities, especially those under financial duress.

Objective

The primary goal of this project is to create a low cost tactile teaching aide capable of helping a wide range K-12 students learn the basics of computer programming. Our proposed teaching aide is a set of blocks that will allow students to perform basic programming operations and assignments through the arrangement of the blocks. Verification of valid code structures will provide feedback for learning, and control of simple outputs connected to the system can give students a goal for their projects.

Background

Currently there are limited methods of teaching younger groups of students about computer programming, and those that do exist often rely heavily on access to computers. This project is meant to produce a learning aid that will function in a classroom setting, doing away with the need have computers present for learning about programming. The use of a visual-tactile system to teach new skills to children has a long and well established history dating at least as far back as Froebel, who believed that freedom to play and experiment was essential to real learning.

In terms of this project the system can be thought of as a, Froebel Spielgaben, or a subject specific learning module. The purpose of which is to allow students of any age to be introduced to coding using a familiar process that promotes creativity. Allowing the module to be untethered, separate from a computer, will also allow the teaching of programming without the other distractions available on a PC, and give students that have trouble with abstraction a set of objects to focus on.

Marketing Requirements

The final package will be a set of between twenty to thirty blocks typically two or less inches across a side. The set will function as it’s own interface device, where the topographical arrangement of elements (blocks) will determine the program. The individual blocks must be identifiable as belonging to a specific programming construct-group. At a minimum these groups must include; numbers, variables, operators, and controls.

Additionally , if possible, a block should be capable of indicating what value or function has been assigned to it. Blocks should be easy to assemble, allowing users to experiment with layouts, but provide area specific error feedback and thereby increasing understanding and limiting confusion.

Finally, the set should open source and be sufficiently accessible, both by cost and teaching use, as to promote universal access and encourage development and expansion by others.

Risk Management

Identifying potential risks at the beginning of a project can help by allowing a certain amount of mitigating action to be built in to the design process.

Defining Risks

Risk types:

1. Scope; risks of scope are those that cause the project to be delayed, too complex, or trivial. Frequently these are cause by poorly defined project specifications, attempting to do much, or becoming unnecessarily focused on specific details.

2. Conceptual; risks belonging here are the products of some failure in understanding a problem or it’s intended solution. One example could be attempting to predict position by triangulation but forgetting to consider velocity.

3. Physical; risks of this type include problems that manifest physically, most commonly refereed to as bugs(software bugs are included here. )

4. Incalculable; risks of this nature include random and unforeseeable events. Shipping delays, inclement weather, and distributor component substitution are all examples of such risks.

Mitigating Risk

Action by type:

1. Scope;

   1. Over reaching and scope creep;

      Controlling the scope size can usually be implemented by instituting system of interdepartmental checks, and by setting project goals by stages. The later, infers making the scope such that it satisfies only the minimum project specifications, while the former, in this case infer double checks are done between team and advisor, or other available expert resources.

      In both cases the scope can be added to, but by building a semi-bureaucratic requirement into the process, the chances of adding unrealizable goals to the project have been reduced.

   2. Built in obsolescence;

      In contrast to point (a) is the risk defining the project so precisely as to reduce the final product’s usability. Incorporating mandatory reviews of tasks/ goals at milestones , and use of a check list or pre-scripted questionnaire can help ensure essential functionality has not been overlooked.

      As in the above (5.2 1a) process, by conceiving each stage of the project between milestones as a singular smaller projects, we improve the chances of including new and relevant additions to scope.

2. Conceptual;

   1. Improperly defined problems;

      The methods of limiting these types of risk are very closely related to those of controlling scope. By ensuring clarity of scope, it then becomes easier to dissect the problem as it pertains to project.

      After dissection, it is up to each team member to voice any concerns or confusions. To which as a group, providing an open, non-judgmental forum is imperative.

   2. Fallacious solution sets;

      This type of risk usually, but not always, stems from having improperly defined problems, which we have addressed already. For the cases not covered, a solid system of review and collaboration, combined with weekly meetings will reduce the likelihood of implementing improperly framed or proposed-solutions.

3. Physical;

   1. Mechanical;

      Mechanical failure can be difficult to foresee, however by rigorously checking each proposed design for possible simplifications can help mitigate potential pitfalls. General mechanical design considerations should always consider; least number of [connections, moving parts, seams, joints]

   2. Electrical:

      As with mechanical, where checks should also include maximum dissipated power, potential bounces, and bit drift.

   3. Code based;

      Some of the electrical/ mechanical risks can be mitigated with software, however constant review and sections-testing is necessary to ensure that new bugs are not introduced with coded solutions. Before considering a section done, all attempts should be made to break it.

4. Incalculable;

   1. Components;

      While the very nature of this section precludes prediction, there are certain actions that can limit damage done in event of component based problems. Problems may include, random device failure, shipping delays, distributor substitutions, and more.

      1. avoid dependence on non generic components

      2. avoid, where possible, proprietary technologies.

      3. always check licensing

      4. never order minimums

      5. always build in parallel

   2. Events;

      The most effective way to mitigate damages done by events like unforeseen weather or closure of services needed, is to have a flexible, organic schedule (see next).

   3. Scheduling;

      Designing a system of scheduling, that allows for the most efficient use of available resources can greatly reduce strain on project time-lines. For this project we have implemented a generic, by ticket system, which allows team members to bid on project tasks as dictated by their own constraints. This combined with ensuring that no individual task is longer than the time between meetings (1-week) will help ensure work flow.