Testing software design decisions

It is recommended that wherever possible the structure of the URS be used as the basis for the presentation format of the FDS and hardware and software design specifications this helps ensure design decisions are auditable back to the source requirement. Traceability should also be carried forward to the qualification test procedures, where it can link each test and qualification acceptance criterion directly to a specific requirement. 

The products identified may be technical ones, such as software components and their supporting documentation, management products, such as plans and reports of various types, or items that are the by-products of processes to ensure software quality, such as testing scripts. The products may be ones that will be delivered to the customer (deliverables) or intermediate products created at various stages of the project for internal purposes, for example, to clarify and communicate design decisions between members of the development team. The concept of a product is a broad one, so that a person could be a product (e.g., a trained user ) or the product could be a revised version of a previously existing product (e.g., a tested program ). 

Consistent and proper operation of any software system is dependent upon the decision and action formulae or algorithms included in the code. With a poorly designed algorithm, interim problems may not be obvious in testing, but may cause significant difficulties over time. Similarly, improper formulae may work properly with some data sets, but may malfunction with unusual or outlier data points. Examination and confirmation of appropriate formulae is a critical part of any source code review. 

Once defined, the business process transactions can be configured within the development environment of the MRP II system. There are normally instances when it is easier to amend the business process to fit the standard functionahty of the MRP II product software than to make a customized bespoke modification. Any bespoke modiflcations, like the interfaces, must be fuhy documented in design specifications, test speciflcations, and test records. One important aspect to avoid during configuration is to set up the system to accept default user entries. There have been several recalls within the pharmaceutical industry because users failed to recognize that a default entry on their MRP II systems was incorrect. It is always a good idea to have positive user confirmation of key data entry or decision points. If defaults are stih required then make them... 

The models, data files, and supporting documentation should be maintained, and each version of a model or data file that impacts requiremmts, designs, or decisions should be saved in the integrated database. Models may be digital, partial, or complete and may be hardware, software, or a combination of both, or may include human models or human-in-the-loop simulations or mock-ups for usability testing and workload measurement. 

Aerospace has continued to provide many engineering, design, and safety services to the Air Force for more than 40 years. One of its chief functions is to perform launch verification and readiness assessments for all Air Force space launches. Aerospace s launch verification procedure is veiy broad, beginning with analysis of launch system design. Aerospace independently tests physical components and software, checks manufacturing processes, and verifies correct assembly of the launch vehicle. Finally, Aerospace delivers a formal launch verification letter to the Air Force s Space and Missile Systems Center, monitors the launch, and analyzes launch and post-launch data (Tomei, 2003). All of the functions are redundant in the sense that Air Force and contractor personnel also perform most of the same functions. Aerospace s launch verification serves as an independent, objective assessment of launch safety that the Air Force uses in conjunction with its own analyses in making launch decisions. 

---