Scribd
Upload
24 views4 pages

Solution Exercise 1

The document identifies five examples of safety-critical software and ranks their levels of integrity from high to low: 1) aerospace control systems, 2) medical devices, 3) nuclear power plant control systems, 4) automotive, and 5) industrial control systems. It notes that the actual integrity level depends on specific system factors and software development processes.

Uploaded by

Tooba Akhter
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
24 views4 pages

Solution Exercise 1

The document identifies five examples of safety-critical software and ranks their levels of integrity from high to low: 1) aerospace control systems, 2) medical devices, 3) nuclear power plant control systems, 4) automotive, and 5) industrial control systems. It notes that the actual integrity level depends on specific system factors and software development processes.

Uploaded by

Tooba Akhter
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 4

Identify five examples of safety critical software and try and rank them in terms of

their levels of integrity.


Sure! Here are five examples of safety-critical software and a rough estimate of their levels of
integrity:

1. Aerospace control systems software: High level of integrity - these systems are responsible
for controlling and navigating aircraft, and any failure could result in catastrophic
consequences.
2. Medical devices software: High level of integrity - medical devices such as pacemakers,
insulin pumps, and ventilators must be reliable and accurate, as any malfunction could harm
or even kill a patient.
3. Nuclear power plant control systems software: High level of integrity - software in nuclear
power plants is responsible for controlling and monitoring critical safety systems, and any
failure could result in a nuclear accident.
4. Automotive software: Medium level of integrity - software in vehicles controls a range of
systems, including powertrain, braking, and stability control. Failures in these systems could
result in accidents, but they are generally not as catastrophic as failures in aerospace or
medical software.
5.
Industrial control systems software: Low to medium level of integrity - industrial
control systems software is used in a variety of industrial settings to control
processes and equipment. While failures in these systems can result in damage or
downtime, they typically do not pose a direct threat to human life.

Note that these are rough estimates and that the actual level of integrity for any given
system will depend on a variety of factors, including the specific requirements and
constraints of the system, the design and implementation of the software, and the
processes and tools used to validate and verify its correctness.

Give an example of software that is both mission and safety critical.


One example of software that is both mission and safety critical is the software used in military
drones. These drones are used for a variety of missions, including reconnaissance, surveillance, and
attack, and they must operate with a high degree of reliability and accuracy. At the same time, they
must also be designed and built to meet stringent safety requirements, as any failure in the software
could result in the loss of the drone and its valuable payload, as well as potentially endangering
human lives.

The software used in military drones must be carefully validated and verified, with multiple layers of
redundancy built in to ensure that it can perform its functions even in the face of failures or adverse
conditions. This requires a high degree of expertise and attention to detail in software design and
implementation, as well as robust processes for software development, testing, and maintenance.
Why testing cannot guarantee that a program is correct.
Testing is an important part of software development and helps to uncover defects and ensure that a
program meets its functional requirements. However, testing cannot guarantee that a program is
correct for several reasons:

1. Completeness of test cases: It is not possible to test every possible combination of inputs,
scenarios, and edge cases, so there may be defects that remain undiscovered even after
extensive testing.
2. Unintended behavior: The program may exhibit unexpected behavior that is not covered by
the test cases, even if the program is functioning as intended.
3. Hidden dependencies: A program may have hidden dependencies on other components or
systems that are not fully understood or accounted for, leading to defects that only appear in
certain scenarios.
4. Dynamic behavior: Testing can only verify the behavior of a program at a given moment in
time, but the behavior may change dynamically over time as inputs, conditions, and
environments change.
5. Undetectable defects: There may be defects in the program that are not
detectable through testing, such as security vulnerabilities or subtle performance
issues.

Therefore, while testing is a crucial part of the software development process, it cannot
provide a guarantee that a program is correct. To achieve a high level of confidence in
the correctness of a program, it is necessary to use a combination of techniques,
including formal verification, code review, and other methods for ensuring software
quality.

Why is natural language a poor choice for expressing specifications?


Natural language is a poor choice for expressing specifications for several reasons:

1. Ambiguity: Natural language is often ambiguous, making it difficult to determine the


intended meaning of a specification. This can lead to misunderstandings and
miscommunications between stakeholders, as well as to defects in the resulting software.
2. Imprecision: Natural language is imprecise, making it difficult to specify precise requirements
and constraints. For example, it can be difficult to specify exact values, ranges, or
relationships between variables.
3. Inconsistency: Different stakeholders may interpret the same natural language specification
in different ways, leading to inconsistencies in the software that is developed.
4. Verifiability: Natural language specifications are often difficult to verify, as it can be difficult
to determine if a software implementation meets the intended requirements.
5. Maintenance: Natural language specifications are often difficult to maintain, as they may
need to be updated as the software evolves and new requirements are added.
For these reasons, it is often more effective to use formal methods, such as mathematical
notation or computer-readable languages, for expressing specifications. These methods provide
a more precise, unambiguous, and verifiable way of expressing requirements and constraints,
and can help to ensure that the resulting software meets the intended specifications.

Identify any weaknesses in the following requirements definition: ‘Software is


required to monitor a collection of documents kept in a library. There may be
multiple copies of each document. Some of the documents are deemed to be of
high importance. Documents can be borrowed from the library by certain
members of staff. There must always be at least one copy of any document
deemed to be of high importance left in the library. All other documents may be
removed. The software needs to record each document’s identity code (consisting
of letters and numbers), and whether or not it is of high importance, as well as the
number of copies. Documents can be removed from the library only by providing
the correct document code.’

The following are some weaknesses in the requirements definition:

1. Lack of clarity: The definition is somewhat unclear about the exact criteria for
determining which documents are deemed to be of high importance, and how
this information is stored and used by the software.
2. Insufficient detail: The definition does not specify how the software should
handle situations where multiple copies of a high-importance document are
present and one is borrowed, or how the software should enforce the
requirement that there must always be at least one copy of a high-importance
document left in the library.
3. Unaddressed security: The definition does not address how the software will
ensure that only authorized members of staff are able to borrow documents, or
how it will prevent unauthorized access to the library's collection.
4. Inadequate error handling: The definition does not specify how the software
should handle errors or exceptional conditions, such as incorrect document
codes, or cases where the library runs out of copies of a document.
5. Lack of scalability: The definition does not consider the scalability of the software,
for example, if the number of documents in the library grows significantly over
time.
These weaknesses in the requirements definition could lead to misunderstandings and
misinterpretations of the requirements, and could result in the development of software that
does not meet the intended needs of the library. To address these weaknesses, it is important to
clarify the requirements and provide more detailed and specific definitions of the functionality
and behavior of the software.

You might also like