Mid term Project Meeting: Summary of Work Completed

The following is a summary of the work completed to date for the ECE 651 project. The document addresses topics from each chapter of the course sequentially.

Life Cycle Model

The main life cycle model adopted for the project is the evolutionary process model, which facilitates agile development. However, prototyping is also used throughout for higher risk tasks, or to validate specifications. This particular model and development process is the most well-suited for our project, as it possesses the following key qualities:

• facilitation of parallel development
• changing requirements (and incomplete requirements at beginning of project)

Example instances of prototyping: code formatting, pre-commit, hooks rollout; Travis CI rollout

Prior to the project, the developers were using a build-and-fix model. Each developer worked off their individual repository. There were no measures in place for issue tracking, team communication, formalization of requirements into specifications, or documentation. Since adopting the evolutionary model, the development team has taken the following measures to improve upon the development workflow:

• Setup basecamp for issue tracking and for turning requirements into specifications via user stories
• Amalgamated existing repositories into a single unified repository using a Github organization
• Created extensive documentation for existing code via:
  • Design and implementation of a Github wiki, containing detailed descriptions of code packages, as well as supplemental material to help prospective developers and users better understand functionality
  • Readme files for each code package, with basic instructions for installation and operation, and clear reference to the corresponding wiki page where the user can find comprehensive information

Requirements Engineering

Stakeholders

The current stakeholders for the project are the BEAM developers, and research partners and clients who are interested in implementing the software.

Functional requirements (high level)

The following are the main high level functional requirements for BEAM robotics:

• Operation requirement: software needs to be used with unmanned vehicles
• Performance requirements for preliminary results:
  • be able to perform inspections in a timely manner (1 hr for 70 to 140 m²
  • be able to perform inspections in a computationally efficient manner (produce the map for the inspector to visualize within 10 minutes of completing the inspection such that the inspector can validate the results before leaving the site.
  • be able to generate the complete inspection report within 24 hours of receiving the field results and data
• Usability requirement: end goal is for an undergraduate level civil engineer to be able to take the robot to an inspection site and perform an automated inspection, given two days of training.
• Modifiability requirement: software will be continuously updated with new functionality and features; existing and new software must be conducive to modification.

Requirements Solicitation and Issue Tracking

In the basecamp, we have developed categorized spaces for stakeholders to create user stories. These user stories can then be formally developed into specifications and tasks. The progress of these tasks is also tracked on basecamp. In addition, a naming convention was developed to streamline and organize the user stories and tasks. The convention is as follows:

• [US-01][OP] : Open
• [US-01-01][AS] : Assigned
• [US-01-02][ID] : In Dev.
• [US-01][RE] : Ready for Eval
• [US-01][CP] : Complete
• [US-01][BL] : Backlog
• [US-01][AB] : Abandoned

where "US" denotes a user story, and each number denotes which family of tasks/requirements a particular user story belongs to. Each subsequent number denotes a subtask within a family.

Testing

Unit testing

Unit tests were written for selected modules which are either critical, or have proven difficult to troubleshoot during development. One example is the unit test written for the GraphSLAM module, which is a black box test that performs input parameter validation via analysis of the the outputted field data.

Code Quality

Several measures have been taken to improve the overall code quality:

• formatting requirements have been specified
• continuous integration (Travis CI)
• protected master branch

Integration Testing

For integration testing, we have implemented Travis CI across the repository.

System Testing

Currently, we utilize black box testing to validate the performance of Inspector Gadget. i.e. Given a set of inputs and an expected output: compare with the actual output of the system and determine if they are coherent.

Acceptance Testing

Ultimately, acceptance testing is performed by providing an automated report to a particular client and receiving an approval or disapproval. Given these circumstances, the acceptance criteria for these tests is client dependent. i.e. a specific client may specify that they want a certain location mapped to a certain degree of accuracy. Additionally, clients can be shown intermediate results or early release versions in order to provide feedback to the developers.

Modularity and Cohesion and Coupling

We are looking at ways to restructure the existing repositories to facilitate cleaner development. As mentioned previously, the first step was to amalgamate the separate repositories into a single repository. Versioning and sub-moduling was implemented in order to facilitate parallel development.

In reviewing old code, we are looking to identify instances where semantic cohesion is present or not present within a module, and take the appropriate steps to restructure the code to improve cohesion wherever possible. One example of this is within the GraphSLAM code, which was originally a very long and self contained code that is currently undergoing this review process. To minimize coupling, the developers communicate back and forth to determine which packages are common to their work. When install scripts are written for each developers' package, attention is paid to ensure that there are no redundant installs occurring.

Review of old code

Old code was revisited to determine which portions of the code could be modularized.

Code Library

A code library called "libbeam" was created to house common code or frequently used functions.