7.4 Using Classic Methods of Reliable …
681
top-to-bottom design method, where each phase (stage) is performed strictly after
the previous ones.
In other words, IC design phases are somewhat similar to software development
only during separate stages. In other words, methods from the field of development
of reliable programming can most possibly be adapted only for the first stages of
microcircuit design.
7.4.5 Lifecycle of Safe Software Development
In software a secure development process is often referred to as trustworthy, since
secure is also associated with a quality control so that the end product does not contain
design- or implementation-specific security vulnerabilities, such as buffer overflows
or command injections. In [72], the authors focus on the first interpretation, even
though they often correlate.
The Requirement Traceability method was examined in detail by Gotel and Finkelstein [75]. In brief, it describes the ability to track all people, decisions, and artifacts
that lead to a certain requirement, as well as all artifacts (e.g., code and tests) involved
in fulfilling the requirement in the final product. The latter part is called post requirements specification and can be as detailed as for each single code block or code
line.
There are many different variants and specific implementations for all popular
platforms of software development. They usually overlap or unite other requirements,
specifications, testing methods, and software source-code versions. Their integration
into a specific development environment (IDE) forces the developers to stick to a
specific work algorithm. In such regulated process, the developers can turn out to
be unable to change the means of controlling the source code without registration
in specification, test scenario, or change request. Together with debug symbols for
the binary, this method creates an uninterrupted traceability from the requirement,
through the specification, the test cases, and the implementation down to the binary
code and vice versa. Each compiler-generated CPU instruction can be traced to
a specific source-code line or module and then to all the authors, specifications,
requirements, change requests, and test cases associated with it.
Another term, (Continuous Integration, describes the infrastructure of development of such software, where the code is automatically built and tested over extremely
short time intervals—as a rule, several times per day or at least every evening (i.e.,
nightly build). This leads to a usable product very fast, but without the full feature set
that grows additively, which allows for early testing. This method is often combined
with test driven development. Tests for a specific product here are written directly
before actual implementation of the device and automatically tested.
681
top-to-bottom design method, where each phase (stage) is performed strictly after
the previous ones.
In other words, IC design phases are somewhat similar to software development
only during separate stages. In other words, methods from the field of development
of reliable programming can most possibly be adapted only for the first stages of
microcircuit design.
7.4.5 Lifecycle of Safe Software Development
In software a secure development process is often referred to as trustworthy, since
secure is also associated with a quality control so that the end product does not contain
design- or implementation-specific security vulnerabilities, such as buffer overflows
or command injections. In [72], the authors focus on the first interpretation, even
though they often correlate.
The Requirement Traceability method was examined in detail by Gotel and Finkelstein [75]. In brief, it describes the ability to track all people, decisions, and artifacts
that lead to a certain requirement, as well as all artifacts (e.g., code and tests) involved
in fulfilling the requirement in the final product. The latter part is called post requirements specification and can be as detailed as for each single code block or code
line.
There are many different variants and specific implementations for all popular
platforms of software development. They usually overlap or unite other requirements,
specifications, testing methods, and software source-code versions. Their integration
into a specific development environment (IDE) forces the developers to stick to a
specific work algorithm. In such regulated process, the developers can turn out to
be unable to change the means of controlling the source code without registration
in specification, test scenario, or change request. Together with debug symbols for
the binary, this method creates an uninterrupted traceability from the requirement,
through the specification, the test cases, and the implementation down to the binary
code and vice versa. Each compiler-generated CPU instruction can be traced to
a specific source-code line or module and then to all the authors, specifications,
requirements, change requests, and test cases associated with it.
Another term, (Continuous Integration, describes the infrastructure of development of such software, where the code is automatically built and tested over extremely
short time intervals—as a rule, several times per day or at least every evening (i.e.,
nightly build). This leads to a usable product very fast, but without the full feature set
that grows additively, which allows for early testing. This method is often combined
with test driven development. Tests for a specific product here are written directly
before actual implementation of the device and automatically tested.