Software Standards

The laser instrument and its connected mobile application must acknowledge and follow multiple software standards set by the community and recognized organizations. This is to prevent errors, bugs, or potentially hazardous events from occurring while the user is interacting with the software. Any situations such as these will hinder the operation of the entire laser instrument device or possibly damage components. These standards apply to the source code as well as the connections managed by this code. The ones specific to this project are listed in the following sections to give their description and how they apply to the laser instrument designed.

4.2.4.1 Android Developers Core App Quality

The Core App Quality guidelines set by Android Developers were created to establish high-quality applications. The guidelines set good user experience expectations and prevent common issues. The guidelines cover a variety of app areas, including standard design, navigation and notifications. Furthermore, the guidelines are set in place to prevent issues with permissions, privacy, and performance on the device.

4.2.4.2 Barr Group’s Embedded C Coding Standards

This standard was set in place for coding with C to prevent errors and ‘bugs’ within code as groups work on sections together. Without set standards for using something as seemingly simple as brackets correctly can create large issues in the code as it is passed from person to person. This set of standards shows examples for all the code standards the group sets. The group will be using C in the embedded systems software, and in order to prevent errors in the project, will be implementing these coding standards.

4.2.4.3 IEEE 830.1998

The IEEE 830.1998 standard outlines the recommended practices and requirements for software. It provides the content and qualities of good software that is to be developed and presented both in-house and commercially. They can also assist in the selection of other products to use during the development process. This standard directly influences the development environment used for the source code of the mobile application used in this project. It also directly influences the design of the application and the communication it has with the instrument. The final product is expected to be presented as a device to be sold commercially, so it is important to follow these guidelines to increase commercial applications and streamline the development process through the duration of this project. Included in IEEE 830 is a definition and description of a recognized “good”

Software Requirement Specification (SRS). The following sections define and apply SRS to this project.

4.2.4.4 Software Requirement Specification (SRS)

The role of an SRS is to define what the software being developed is expected to do. This affects the development process, including planning, design, assessment, testing, and expected final functionality and operation. In larger projects, it also includes the interaction between multiple interfaces. For the purpose of this project, there is only the single interface for the user to interact with. The communication is expected to be a single bidirectional path between the mobile application and the instrument, which makes the list of SRS’s simpler but still just as important.

Each SRS is meant to be referred to during every step of the development process to confirm that the software is on track and continues to serve the purpose that it is included in the project for.

There are several characteristics of a good SRS, as defined by IEEE 830. The first is that a good SRS must be correct. This means that every requirement listed is one that the final software will meet, and that every market requirement has been met. With this practice, the design of the software in this project will satisfy each applicable requirement defined by the customer and the final software will meet the design specifications. The next characteristic is that an SRS should be unambiguous, which means that it is clear enough that everyone who references it can understand it. This helps to confirm that there won’t be multiple interpretations of the same SRS, which regulates the development process between the customer and the developer. The next characteristic is that a good SRS is complete. This means it must include all the significant requirements for the entire project, how the final product will react to expected input, and all the supporting material is completely defined. An SRS must also be consistent, meaning that it does not contradict another SRS or other referencing documents that the project builds from. This includes listed schedules within the project, descriptions of a single part or components, or referenced values used in research or testing. Also, a good SRS must be verifiable, or able to be tested to prove that a specific requirement has been met. It must be modifiable so that when a requirement changes, the software can change in reaction to that. This influences all the other good characteristics of an SRS as well.

An SRS is very similar to an engineering requirement but is strictly limited to the software of a project. In that sense, a list if good SRS’s place the software of a project into an environment in which it can be approached as if it is its own project.

This is an ideal way to break down delegations of tasks and identify the relation the final software has on the design of the project. Since an SRS presents a solution to a specific problem, it can be used to address specific requirements presented for the entire project and have a lasting impact on the design for the final product. It makes these solutions simpler to track when good documentation is kept, and all ideas presented are agreed upon by a combination of the consumer and the engineering team developing the software.

4.2.4.5 IEEE 829

The standard IEEE 829 defines and explains the proper software testing stages and the documentation required for the process. It is meant to improve readability and reusability when analyzing and citing tests throughout a given project or in future projects by other groups. This is an important standard to apply to this project because the mobile application will require significant testing to be fully integrated with the laser instrument by the end of this project. Each of those tests will need to be repeated several times throughout the development process and must be replicated for demonstrative purposes with the final product. This does not have a direct influence on the design of instrument, or the software used for the application, but is important for the testing stages of the project. The practices described by this standard can be applied to both software and to the physical device designed. Standardizing the testing processes will improve team efficiency and the trust factor of the tests themselves knowing that they have been properly documented and cited for future references.

4.2.4.6 Agile Development Method

The Agile development method is a growing standard practice used in many development environments today. It is the cycle of communicating with the customer, developing in stages, and being responsive to changes in design or requirements. It increases understanding of needs between the consumer and the development team by setting expectations of regular communication that includes reporting and feedback between the two groups. It also allows for a development team to work in shorter bursts of energy to complete smaller stages of the project, in this case it is the software, before reassessing the design to meet the market requirements. This can be applied to this project easily because the project builds from several similar ideas that have been presented by multiple sources. The solutions signed to solve the problems presented may change as the design of the instrument grows over the course of the project. The design of the mobile application is highly responsive to the design of the physical instrument and is therefore susceptible to higher rates of change than other aspects of the project.

The software present in the final product is expected to be significantly different than the first expectation, which is why the team has decided to develop within an agile environment. By utilizing this standardized process, the software will improve its adaptability and the team will lose less time to designing and implementing new ideas. This directly satisfies multiple requirements highlighted in the House of Qualities presented in Figure 4.

4.2.4.7 IEEE 1540

The IEEE 1540 standard relates to risk management in the life cycle of software.

By standardizing the way potential problems are identified and the documentation of the consequences of such problems, the process for solving the problems found is made easier. Each member is held to the same standards and problems can be

tracked in a simpler way when they are all organized the same as each other. This is important for this project since the mobile application is expected to change frequently throughout the design process for the laser instrument, making it susceptible to many types of errors. These errors can be more readily dealt with the use of this standard.