Studio Project Environment

The projects conducted in Studio course are all quasi-safety critical -- meaning that if used in a more realistic setting, product failure could cause loss of life or physical harm. The studio process therefore integrates safety-critical development processes. The project environment includes various tools and guidelines to be followed.

Software Artifacts and Traceability

All Safety critical domains are governed by certifying and approval bodies which prescribe specific development processes. Such processes include guidelines for process, artifact creation, and trace links which are to be established and then used to demonstrate safety of a product. Click here to view a larger image of the TIM. Many of the artifacts and their associated trace links will be created as a natural byproduct of the Software Development process using the processes and tools described below. (Check back here later for an Interactive TIM).

Software Processes

We follow a "basically-agile" approach, augmented to provide additional rigor suited to the safety-critical nature of the projects. Our process includes the following:

1. SCRUM is an effective framework that can be used to develop and maintain complex products. It defines roles, events, and artifacts, as well as the rules that bind them together. The Scrum user guide provides more details. Click here to view a SCRUM process model. Our use of SCRUM is supported by an academic license of Atlassian Jira. Our goal is to incrementally deliver functioning software across a series of releases.

2. EARS -- the Easy Approach to Requirements Specification, was created by Alistair Maven at Rolls Royce and now adopted by numerous organizations. EARS provides a relatively simple way to add rigor to the requirements specification by defining simple-to-use templates for specifying requirements for normal and unwanted behavior. Alistair's Tutorial slides on EARS are available online. In this studio course we will use EARS requirements in place of standard user stories.

3. Safety Analysis involves several different activities. First, performing a hazard analysis to identify hazards that may occur. The hazards, their associated faults, and mitigating requirements are modeled in a FMECA, which stands for a Fault Mode, Effects, and Criticality Analysis. Traceability links are established across the life-cycle artifacts and then used to argue a safety-case for the system.

Tools and Environments

Almost nobody enjoys a "heavy-weight" process. The goal is therefore to put enough process in place -- supported be effective tools, so that the team can focus on building a product. We will utilize several tools and environments in Studio course in order to facilitate the development effort

1. Atlassian Jira provides an environment for managing the agile process -- including creating, managing, and tracking epics, user stories, and bugs.

2. GitHub provides a collaborative environment for managing source code and versions of source code. Each team has a private GitHub repository which will made public at the conclusion of this project. Furthermore, each GitHub repository is integrated into the Jira projects, so that source code commits can be tracked against specific user stories.

3. We will use a variety of IDEs and SDKs (Android, Arduino etc) as needed for each project.

4. IBM BlueMix has provided free academic accounts for use by all students in the course. These accounts provide hosting options and are available for team use.

5. The ASCE Tool for creating and managing assurance- and safety- cases will be used to build safety cases for each of the releases. (Status: Currently awaiting confirmation of academic license.)