Design Review

0

The Software life cycle processes are:

    • PLANNING Process
    • DEVELOPMENT Process
    • INTEGRAL Process

The software planning process that defines and coordinates the activities of the software development and integral processes for a project.

Software Development Life Cycle Overview (SDLC):

The software development processes that produce the software product.

    • Software Requirements Process
    • Software Design Process
    • Software Coding Process
    • Integration process.

The Integral processes ensure the correctness, control and confidence of the software life cycle processes and their outputs.

    • Software Verification Process
    • Software Configuration Management Process
    • Software Quality Assurance Process
    • Certification Liaison Process

Requirement and Design Reviews forms a part of Verification process.

What is Software Design Process: The software high level requirements are refined through one or more iterations in the software design process to develop the software architecture and the low level requirements that could be used to implement the source code.

 

ETVX is the criteria followed for the Design Review.

Entry Criteria:

  • The project is started when the Correct and Complete inputs are received
  • The inputs for the Design Reviews include the following each of which should be under configuration control
    • Hardware Software Interface document
    • High Level Requirements document
    • Software Design Standards document
    • Low level Design document(including both low level requirements and software architecture)
    • Traceability matrix from High Level Requirements to Low Level Requirements
    • Software Verification Plan document

Task Criteria:

  • The Tasks includes
    • Understanding the Low Level Requirements, Software architecture and High Level Requirements.
    • Understanding the standards described in the Software Design Standards document.
    • Review is done as per the standards described in DO-178B and Software Design Standards document generally with the aid of a checklist.
    • All the findings and comments should be recorded in a checklist or review record which should be under Configuration Control.

Verification Criteria:

  • Verification is done by means of
    • Technical review
    • Quality review
  • Technical review is done to remove any documentation, functional and other technical defects in the Design Review Checklist
  • Quality review is done to identify and remove the process related defects associated with the work product.
  • Reviewer raises the comment for each defect found which will be corrected by the author

Exit Criteria:

  • Design Review process is complete when all the comments closed by the author and it is accepted by both technical as well as quality reviewer, which ensures that the final output is defect free.
  • The final output of this process is a completely filled Design Review Check list and Review record which are under configuration control.

Design Review Checklist as per DO-178B

Pic 1

Checkpoint Interpolation

Comply with the High Level Requirement:

  • Objective:
    • Requirements Review: To ensure that the system functions to be performed by the software are defined, that the functional, performance, and safety-related requirements of the system are satisfied by the software high-level requirements, and that derived requirements and the reason for their existence are correctly defined.
    • Low-Level Requirements Review: To ensure that the software low-level requirements satisfy the software high-level requirements and that derived requirements and the design basis for their existence are correctly defined.
    • Software Architecture Review: To ensure that the software architecture does not conflict with the high-level requirements, especially functions that ensure system integrity, for example, partitioning schemes.

Example:

  • Given below is a High Level Requirement and the corresponding System requirement to which it is traced. This is one of the requirement used to indicate the Quantity of Oil in the oil tank of an Auxiliary Power Unit of a System.
  • High level requirement : The AI_14_OIL_LEVEL shall represent the oil quality of the APS5000 oil sump to a system accuracy of ± 0.25 quarts for the nominal aircraft installed attitude (APU 7.5 degrees forward facing downward) OIL LEVEL SENSOR over the OIL_HEIGHT range of 4.00 to 7.824 inches.
  • System requirement : The oil indication system shall have an accuracy of 0.25 quart to be used for calculation of oil consumption, corrective action and pre-dispatch servicing decisions.
  • When we review the above High level Requirement, we find the following discrepancy
    • System Requirement       describes to “calculate of oil consumption, corrective action and pre-dispatch servicing decisions.” i.e to calculate the quantity of oil consumed by the system, corrective actions to be decided based on this reading and dispatch the service decisions.
    • But the High level requirement describes “AI_14_OIL_LEVEL shall represent the oil quality of the APS5000 oil sump”
    • As per the System requirement this requirement should measure the quantity of the oil not the quality
    • Hence the Check point “Does the requirement comply with the higher level document? “ fails
  • The Check point “Does the requirement comply with the higher level document? “ would pass if at all the High Level Requirement is given as below.
  • High level requirement : The AI_14_OIL_LEVEL shall represent the oil quantity of the APS5000 oil sump to a system accuracy of ± 0.25 quarts for the nominal aircraft installed attitude (APU 7.5 degrees forward facing downward) OIL LEVEL SENSOR over the OIL_HEIGHT range of 4.00 to 7.824 inches.

Accuracy and Consistency:

  • Objective:
    • Requirements Review: To ensure that each high-level requirement is accurate, unambiguous and sufficiently detailed and that the requirements do not conflict with each other.
    • Low-Level Requirements Review: To ensure that each low-level requirement is accurate and unambiguous and that the low-level requirements do not conflict with each other.
    • Software Architecture Review: To ensure that a correct relationship exists between the components of the software architecture. This relationship exists via data flow and control flow.

Example:

  • Given below is a High Level Requirement and the corresponding System requirement to which it is traced. This is one of the requirements used to indicate the Quantity of Oil in the oil tank of an Auxiliary Power Unit of a System.
  • High level requirement : The AI_14_OIL_LEVEL shall represent the oil quantity of the APS5000 oil sump to a system accuracy of ± 0.5 quarts for the nominal aircraft installed attitude (APU 7.5 degrees forward facing downward) OIL LEVEL SENSOR over the OIL_HEIGHT range of 4.00 to 7.824 inches.
  • System requirement: The oil indication system shall have an accuracy of 0.25 quart to be used for calculation of oil consumption, corrective action and pre-dispatch servicing decisions.
  • When we review the above High level Requirement, we find the following discrepancy
    • System Requirement mentions the accuracy to be 0.25%
    • But the High level requirement describes mentions the accuracy to be 0.5%
    • Hence there is a mismatch in the values given in the System requirement 0.25% and High Level Requirement 0.5%
    • Hence the Check point “Is the requirement accurate and consistent? “ fails
  • The check point “Is the requirement accurate and consistent? “would PASS if at all the High Level Requirement is given as below.
  • High level requirement : The AI_14_OIL_LEVEL shall represent the oil quantity of the APS5000 oil sump to a system accuracy of ± 0.25 quarts for the nominal aircraft installed attitude (APU 7.5 degrees forward facing downward) OIL LEVEL SENSOR over the OIL_HEIGHT range of 4.00 to 7.824 inches.

Compatibility with the Target Environment:

  • Objective:
    • Requirements Review: It is necessary to verify that the Requirements developed is in compliance and supported by the Hardware and       Hardware/Software integration features.
    • Low-Level Requirements Review: To ensure that no conflicts exist between the software requirements and the hardware/software features of the target computer, especially, the use of resources (such as bus loading), system response times, and input/output hardware.
    • Software Architecture Review: To ensure that no conflicts exist, especially initialization, asynchronous operation, synchronization and interrupts, between the software architecture and the hardware/software features of the target

Example:

  • Given below is a High Level Requirement. This requirement describes about the memory locations where the data can be written.
  • High level requirement : The address ranges for write requests for SFTY shall be checked if the requested address for data to be written to is in an accessible memory area with the following ranges:

0x00000000 to 0x200FFFFF – Data Memory

0x21000000 to 0x2103FFFF – Nonvolatile Data Memory

0x40000000 to 0x4000FFFF – Data Memory

  • But in the Hardware Specification document it is given that “Addresses ranging from 0x00000000 to 0x0000FFFF would be reserved for ROM” and “the addresses ranging from 0x00010000 to 0xFFFF0000 would be write accessible location”
  • In the above case the given requirement which states       “0x00000000 to 0x200FFFFF – Data Memory” to be write accessible location does not comply with the Target computer
  • The check point “Is the SWRD requirement compatible with the target computer?” would FAIL for the above example
  • The check point “Is the SWRD requirement compatible with the target computer?” would PASS if the High Level Requirement had been the following
  • High level requirement : The address ranges for write requests for SFTY shall be checked if the requested address for data to be written to is in an accessible memory area with the following ranges:

0x20000000 to 0x200FFFFF- Data Memory

0x21000000 to 0x2103FFFF – Nonvolatile Data Memory

0x40000000 to 0x4000FFFF – Data Memory

Verifiability:

  • Objective:
    • Requirements Review: To ensure that each high-level requirement can be verified.
    • Low-Level Requirements Review: To ensure that each low-level requirement can be verified.
    • Software Architecture Review: To ensure that the software architecture can be verified, for example, there are no unbounded recursive algorithms.

Example:

  • Given below is a High Level Requirement. This requirement describes one of the way to determine the value of the absolute position of an outflow valve of a system
  • High level requirement: If the validity of OFV_POS_ABS_V obtained by calling the getter functions is INVALID, then the received value of OFV_POS_ABS shall be unknown.
  • The above requirement describes if the validity of the Outflow valve is INVALID, then the value of its position received will be unknown, but while testing we cannot test a variable against an unknown equivalence class.
  • Hence the check point “Is the requirement verifiable?” will FAIL
  • The check point “Is the requirement verifiable?” would PASS is the requirement had been the following
  • High level requirement : If the validity of OFV_POS_ABS_V obtained by calling the getter functions is INVALID, then the received value of OFV_POS_ABS shall be set to Zero.

Conformance to standards:

  • Objective:
    • Requirements Review: To ensure that the Software Requirements Standards were followed during the software requirements process and that deviation from the standards are justified.
    • Low-Level Requirements Review: To ensure that the Software Design Standards were followed during the software requirements process and that deviation from the standards are justified.
    • Software Architecture Review: To ensure that the Software Design Standards were followed during the software design process and that deviations to the standards are justified, especially complexity restrictions and design constructs that would not comply with the system safety objectives.

Example:

  • During Planning process of the Software Development Life Cycle, Software Requirement Standards and Software Design Standards are defined in a document.
  • The purpose of Software Requirements Standards is to define the methods, rules and tools to be used to develop the high-level requirements
  • These standards should include
  • The methods to be used for developing software requirements, such as structured methods.
  • Notations to be used to express requirements, such as data flow diagrams and formal specification languages.
  • Constraints on the use of the requirement development tools.
  • The method to be used to provide derived requirements to the system process.
  • The purpose of Software Design Standards is to define the methods, rules and tools to be used to develop the software architecture and low-level requirements
  • The standards should include
    • Design description method(s) to be used.
    • Naming conventions to be used.
    • Conditions imposed on permitted design methods, for example, scheduling, and the use of interrupts and event-driven architectures, dynamic tasking, re-entry, global data, and exception handling, and rationale for their use.
  • Constraints on the use of the design tools.
  • Constraints on design, for example, exclusion of recursion, dynamic objects, data aliases, and compacted expressions.
  • Complexity restrictions, for example, maximum level of nested calls or conditional structures, use of unconditional branches, and number of entry/exit points of code components.
  • Given below is a High Level Requirement, and in the Software Requirement Standards document, It is mentioned that the requirements are categorized into three types
  • Title
  • Requirement
  • Derived Requirement

pic2

  • In the Requirement document, the above Requirement is categorized as “Title”, but the requirement actually describes a functionality, hence the above requirement should have been categorized into either “Requirement” or “Derived Requirement”

Trceability :

  • Objective:
    • Requirements Review: To ensure that the functional, performance, and safety related requirements of the system that are allocated to software were developed into the software high-level requirements.
    • Low-Level Requirements Review: To ensure that the high-level requirements and the derived requirements were developed into the low-level requirements.

EXAMPLE :

  •    Objective:
    • Requirements Review: To ensure that the functional, performance, and safety related requirements of the system that are allocated to software were developed into the software high-level requirements.
    • Low-Level Requirements Review: To ensure that the high-level requirements and the derived requirements were developed into the low-level requirements.

pic3

In the Requirement document, the above Requirement is categorized as “Requirement”, but no trace to any Higher Level Requirement was provided in the Traceability Matrix

  • Hence the check point “Does the requirement trace to a Parent document?” would FAIL.
  • The check point “Does the requirement trace to a Parent document?” would PASS if at all the requirement was categorized into “Derived Requirement” or a suitable trace to System Requirement was provided as shown below

pic4

Algorithm aspects:

  • Objective:
    • Requirements Review: To ensure the accuracy and behavior of the proposed algorithms, especially in the area of discontinuities.
    • Low-Level Requirements Review: To ensure the accuracy and behavior of the proposed algorithms, especially in the area of discontinuities

Example :

  • Given below is a High Level Requirement, which is used to calculate the static pressure inside a system using the values read from the sensor and a reference pressure( which is a constant)
  • High Level Requirement : P_STATIC shall be calculated as follows:

P_STATIC = SENSOR_PRESSURE/(SENSOR_PRESSURE – REF_PRESSURE)

  • Above algorithm works well for all cases except for the case         “SENSOR_PRESSURE = REF_PRESSURE”. The value for this case becomes unpredictable.
  • Hence the check point “Is the requirement algorithm accurate and consistent?” FAILS
  • The check point “Is the requirement algorithm accurate and consistent?” would PASS if the Requirement stated the following
  • High Level Requirement : P_STATIC shall be calculated as follows:

P_STATIC = SENSOR_PRESSURE/(SENSOR_PRESSURE – REF_PRESSURE)

If SENSOR_PRESSURE != REF_PRESSURE

Partitioning Integrity

  • Objective:
    • Software Architecture Review: To ensure that partitioning breaches are prevented or isolated.
  • This Standard is applicable only for Software Architecture Review.

Example :

  • The Software for system described below is divided in to two partitions “Control” and “Safety” .
  • It is already described in the Requirement document as well as the Hardware Software Integration Document(HSID) that communication regarding the “Faults” associated with the system is communicated to On Board Health Monitoring System(OBHM) only through “Control” partition
  • High Level Requirement : The “Safety” partition shall communicate all the faults detected by the system to OBHM
  • Since the above requirement is in conflict with the other requirements of the system which clearly defines, the communication between the System and the OBHM happens only through “Control”, the Partition Integrity is lost
  • Hence the Check point “Is the Partitioning Integrity maintained?” Fails
  • The Check point “Is the Partitioning Integrity maintained?”       would Pass, if the requirement was as given below.
  • High Level Requirement : The “Control” partition shall communicate all the faults detected by the system to OBHM

 

Leave a Reply

Your email address will not be published. Required fields are marked *