Safety Critical Systems

Assignment -4
1. Please review the SWEBOK V3.0:

• Download your personal copy of SWEBOK V3.0!

• Summarize the main contents of SWEBOK V3.0!

• Since the Lab project will start with its Requirements Analysis Phase, please review the
corresponding part of SWEBOK V3.0!

Answer - The Software Engineering Body of Knowledge (SWEBOK) is an international

standard ISO/IEC TR 19759:2005[1] specifying a guide to the generally accepted Software
Engineering Body of Knowledge.
The Guide to the Software Engineering Body of Knowledge (SWEBOK Guide) has been created
through cooperation among several professional bodies and members of industry and is
published by the IEEE Computer Society (IEEE).[2] The standard can be accessed freely from
the IEEE Computer Society.[3] In late 2013, SWEBOK V3 was approved for publication and
released.In 2016, the IEEE Computer Society kicked off the SWEBOK Evolution effort to develop
future iterations of the body of knowledge.

The published version of SWEBOK V3 has the following 15 knowledge areas (KAs) within the
field of software engineering and mainly used areas are:

• Software requirements
• Software design
• Software construction
• Software testing
• Software maintenance
• Software configuration management
• Software engineering management
• Software engineering process
• Software engineering models and methods
• Software quality
• Software engineering professional practice
• Software engineering economics

Software requirements

Software requirements is a field within software engineering that deals with establishing the
needs of stakeholders that are to be solved by software. The IEEE Standard Glossary of
Software Engineering Terminology defines a requirement as:

1. A condition or capability needed by a user to solve a problem or achieve an objective.

2. A condition or capability that must be met or possessed by a system or system
component to satisfy a contract, standard, specification, or other formally imposed
document.
3. A documented representation of a condition or capability as in 1 or 2.
The activities related to working with software requirements can broadly be broken down into
elicitation, analysis, specification, and management.

Software design-

Software design is the process by which an agent creates a specification of a software artifact,
intended to accomplish goals, using a set of primitive components and subject to constraints.
Software design may refer to either "all the activity involved in conceptualizing, framing,
implementing, commissioning, and ultimately modifying complex systems" or "the activity
following requirements specification and before programming, as a stylized software engineering
process”. Software design usually involves problem solving and planning a software solution.
This includes both a low-level component and algorithm design and a high-
level, architecture design.

Software construction-

Software construction is a software engineering discipline. It is the detailed creation of working

meaningful software through a combination of coding, verification, unit testing, integration testing,
and debugging. It is linked to all the other software engineering disciplines, most strongly to
software design and software testing.

Software Testing-
Software testing involves the execution of a software component or system component to
evaluate one or more properties of interest. In general, these properties indicate the extent to
which the component or system under test:

• meets the requirements that guided its design and development,

• responds correctly to all kinds of inputs,
• performs its functions within an acceptable time,
• it is sufficiently usable,
• can be installed and run in its intended environments, and
• achieves the general result its stakeholders desire.

Software maintenance-

Software maintenance in software engineering is the modification of a software product after

delivery to correct faults, to improve performance or other attributes. A common perception of
maintenance is that it merely involves fixing defects. However, one study indicated that over 80%
of maintenance effort is used for non-corrective actions. This perception is perpetuated by users
submitting problem reports that in reality are functionality enhancements to the system. More
recent studies put the bug-fixing proportion closer to 21%.

Software configuration management-

Software configuration management (SCM or S/W CM) is the task of tracking and controlling
changes in the software, part of the larger cross-disciplinary field of configuration management.
SCM practices include revision control and the establishment of baselines. If something goes
wrong, SCM can determine what was changed and who changed it. If a configuration is working
well, SCM can determine how to replicate it across many hosts. The acronym "SCM" is also
expanded as source configuration management process and software change and configuration
management. However, "configuration" is generally understood to cover changes typically made
by a system administrator.
Software Engineering Management

Engineering management is the application of the practice of management to the practice of

engineering. Engineering management is a career that brings together the technological
problem-solving ability of engineering and the organizational, administrative, and planning
abilities of management in order to oversee the operational performance of complex engineering
driven enterprises. A Master of Engineering Management (MEM) is sometimes compared to a
Master of Business Administration (MBA) for professionals seeking a graduate degree as a
qualifying credential for a career in engineering management.

Software engineering process

In software engineering, a software development process is the process of dividing software

development work into distinct phases to improve design, product management, and project
management. It is also known as a software development life cycle (SDLC). The methodology
may include the pre-definition of specific deliverables and artifacts that are created and
completed by a project team to develop or maintain an application.

Most modern development processes can be vaguely described as agile. Other methodologies
include waterfall, prototyping, iterative and incremental development, spiral development, rapid
application development, and extreme programming.

Some people consider a life-cycle "model" a more general term for a category of methodologies
and a software development "process" a more specific term to refer to a specific process chosen
by a specific organization. For example, there are many specific software development
processes that fit the spiral life-cycle model. The field is often considered a subset of the systems
development life cycle.

Software engineering models and methods

"the systematic application of scientific and technological knowledge, methods, and experience
to the design, implementation, testing, and documentation of software"—The Bureau of Labor
Statistics—IEEE Systems and software engineering

Software quality

In the context of software engineering, software quality refers to two related but distinct notions:
Software functional quality reflects how well it complies with or conforms to a given design,
based on functional requirements or specifications. That attribute can also be described as the
fitness for purpose of a piece of software or how it compares to competitors in the marketplace
as a worthwhile product. It is the degree to which the correct software was produced.

Software structural quality refers to how it meets non-functional requirements that support the
delivery of the functional requirements, such as robustness or maintainability. It has a lot more to
do with the degree to which the software works as needed.

Software engineering professional practice

Software engineering professionalism is a movement to make software engineering a profession,

with aspects such as degree and certification programs, professional associations, professional
ethics, and government licensing. The field is a licensed discipline in Texas in the United
States(Texas Board of Professional Engineers, since 2013), Engineers Australia(Course
Accreditation since 2001, not Licensing), and many provinces in Canada.
Software engineering economics

Software engineering economics had the microeconomics branch of economics deals more with
the types of decisions we need to make as software engineers or managers. Clearly, we deal
with limited resources. There is never enough time or money to cover all the good features we
would like to put into our software products. And even in these days of cheap hardware and
virtual memory, our more significant software products must always operate within a world of
limited computer power and main memory.

b). Requirements Analysis Phase

The objective of this phase is to define in more detail the system inputs, processes, outputs and
interfaces. At the end of this phase the system’s processes will be defined at the functional level,
meaning the functions to be performed will be known, but not necessarily how they will be
performed. Unless specifically constrained by the Project Charter, Requirements
Analysis should not consider the computer programs, files and data streams.
Requirements Analysis will identify and consider the risks related to how the technology will be
integrated into the standard operating procedures. Requirements Analysis will collect the
functional and system requirements of the business process, the user requirements and the
operational requirements (e.g., when operational what is necessary to keep the system up and
running)
Entry Criteria
In order for Requirements Analysis to begin, there must be an approved Project Charter. The
scope of the project will be understood and stated in the Project Charter. The roles and
responsibilities for the various activities in the Development Life cycle will be known.
Roles & Responsibilities
Project Manager: The project manager is accountable for the success of this phase. The
primary responsibility of the Project Manager during Requirements Analysis is to ensure the
Business Analyst(s) has access to the proper: Subject Matter Experts, Business Process
documentation, existing technology and potential technological solutions as well as current and
desired artifacts. A major impediment to successful requirements analysis is lack of exposure to
any of the previously listed items

Business Analyst – The BA must first develop a plan for how the requirements analysis activity
will be accomplished. The BA must then document the business process descriptions and
collect the requirements of the system from the Subject Matter Experts (SME’s) in a manner
which allows traceability to documents generated in previous activities and creates a framework
for future activities. All identified requirements should fall within the constraints of the project
scope and align with the customer’s statement of needs. The BA will generate a requirements
traceability matrix which becomes the basis for the Design activity.

The BA constructs a logical model that describes the data and processes needed to support the
requested functionality. Processes are identified along with any of the associated data they use
or create. The interactions of dependent processes is also defined.

Because of the variability in scope of the projects intended to fall within the confines of this life
cycle, it is expected that the BA will need a flexible set of tools to properly elicit and document the
business requirements. The BA will work closely with the SME’s to ensure a logical model
showing processes, data structures and business activities in an accurate, consistent and
complete manner.
The BA must also consider the current technical architecture, application software and data that
is used to support the business function to guarantee that no necessary functionality has been
overlooked. The BA will also be aware of considerations surrounding persons with disabilities
and any other legal considerations. Some consideration must also be paid to capacity and
growth associated with the project.

Subject Matter Expert – The Subject Matter Expert understands the current business processes
and any new requirements that are to be satisfied by the project. They must work closely with
the BA to transfer both stated and tacit knowledge for inclusion in the Functional Requirements
Documents

Designer – The Designer receives the Artifacts produced in the Requirements Analysis phase.
Because of the variability in scope of the projects intended to fall within the confines of this life
cycle, it is expected that the Designers will coordinate with the BA early on to ensure there is an
agreed upon set of artifacts delivered.

Testing Lead – The Testing Lead is involved during this activity to ensure that the requirements
identified by the BA and accepted by the customer are measurable and that IT has the resources
to complete adequate testing. Having the Testing Lead involved at this step allows for proper
scheduling and preparation for the various stages of testing that occur during the SDLC.

Artifacts
Functional Requirements Document.dotx (FRD): This is a document that defines in more detail
the system inputs, processes, outputs and interfaces. Such detail can be provided in various
formats. Usually no individual technique or model is sufficient to express the requirements of a
nontrivial system. Different types of projects and different varieties of customers will find success
using different techniques for collecting and representing the functional requirements. Some of
the optional techniques for the expression of functional requirements which could define the
contents of the FRD are shown in the italicized list below. Note that all of the techniques should
be briefly considered at the beginning of the Requirements Analysis and appropriate ones should
be determined based on type of project and customer. The FRD should ultimately contain a
Requirements Traceability Matrix which will be uniformly adopted as the main component of all
FRDs. Note that none of the optional techniques listed are technology dependent nor do they
dictate specifics to the Designers of HOW process work and accomplish the goals of the system.

Entity-relationship diagrams (optional)

process hierarchy diagrams (optional)
process dependency diagrams (optional)
logical model (optional)
activity diagrams (optional)
business algorithms (optional)
entity life cycle diagrams (optional)
entity state change matrices (optional)
Mockups (optional)
Data Flow Diagrams: Intended to represent the flow of information around a system (optional)
Requirements Traceability Matrix (included at end of FRD)
Review (Revision)
The completion of Requirements Analysis is signified by a presentation of the FRD to the
Customer and the Designers. At this point the Project Manager should also review the FRD for
the time line for the remaining life cycle phases, review of resource availability and a risk
assessment organized to align with the remaining steps of the life cycle.
Approval
When the customer signs off on the Business Requirements the solution designers can begin
their system design work. Depending on the technique of development there might be more than
one visit to the Requirements Analysis activity. It is important that the Business Analyst,
Designers and Customer agree and understand the expected iterations of Requirements
analysis.
Exit Criteria
Requirements Analysis is complete when the customer signs off on the Functional Requirements
Document.

2.) Generic Safety Standard IEC61508:

• Browse for alternative literature! (The original standard is quite expensive!)

• Summarize the main aspects of the standard!
• Which process model is proposed?

Answer - In safety circles, the draft standard IEC 1508, published in 1995 by the International
Electrotechnical Commission, received wide publicity and has been hugely influential. The recent
publication of its successor, IEC 61508 [IEC 1998], has raised considerable interest, for the principles
embodied in it are recognised as fundamental to modern safety management.
The standard gives guidance on good practice. It offers recommendations but does not absolve its
users of responsibility for safety. Recognising that safety cannot be based on retrospective proof but
must be demonstrated in advance, and that there can never be perfect safety (zero risk), the
recommendations are not restricted to technical affairs but include the planning, documentation
and assessment of all activities. Thus, IEC 61508 is not a system development standard but a
standard for the management of safety throughout the entire life of a system, from conception to
decommissioning. It brings safety management to system management and, in respect of the
development of safety-related systems, it brings safety engineering to software engineering. It is a
'generic' standard, intended to be used as the basis for writing more specific (e.g. sector-specific and
application-specific) standards. Where these do not exist, it is also intended to be used directly. In
this author's view, it is preferable to use the standard in the former mode, with a few experts
producing a shorter document specifically interpreted to a given industry sector or application. To
use it directly will require considerable understanding, planning, directing and monitoring by
management, because of the current lack of understanding of the standard and of safety
engineering

OBJECTIVES OF THE STANDARD IEC 61508 is a basic safety publication of the International
Electrotechnical Commission (IEC). As such, it is an “umbrella” document covering multiple
industries and applications. A primary objective of the standard is to help individual industries
develop supplemental standards, tailored specifically to those industries based on the original 61508
standard. A secondary goal of the standard is to enable the development of E/E/PE safety-related
systems where specific application sector standards do not already exist. Several such industry
specific standards have now been developed with more on the way. IEC 61511 has been written for
the process industries. IEC 62061 has been written to address machinery safety. IEC 61513 has been
written for the nuclear industry. All of these standards build directly on IEC 61508 and reference it
accordingly.

The development of software for safety-critical systems is guided by standards. For software where
it is not possible to quantify the associated risks, current standards in the aerospace, rail and
defence sectors identify design and safety processes for different Safety Integrity levels (SILs) or
Development Assurance Levels (DALs). From the SIL/DAL assigned to a software function, guidance
on the development process, use of tools and techniques can be found accordingly from standards.
Software is shown to be fit for use primarily by appeal to conforming to the standards, supported
with appropriate evidence. The assumption is that software developed against the process
requirements of higher SILs/DALs will be less prone to critical failures and thus have a lower impact
on the overall system safety. UK Defence Standard 00-56 defines the SIL as “an indicator of the
required level of protection against systematic failure” [26]. A number of standards (e.g., UK Defence
Standard 00-56 Issue 2, IEC 61508 [25], Australian Defence Standard 5679 [24], US Military Standard
MIL-STD-882C [55], UK Automotive Standard MISRA [56]) use the SIL concept to provide guidance on
the design and development of safety-critical systems, 37 although each standard interprets the
concept differently. The SIL approaches defined in Defence Standard 00-56 and IEC 61508 are
discussed in more detail in this section. In IEC 61508, safety integrity requirements for safety
functions are set directly from target failure rates. The target failure rates are determined from the
necessary risk reduction which is calculated from the actual risk of the Equipment Under Control
(EUC), assuming that no safety measures are taken, and the tolerable level of risk. The target failure
rates are measured in two different ways: as dangerous failures per year, for continuous control
systems; and as probability of failure to perform design function on demand, for protection systems
SILs are allocated to the safety functions in the designated computer system, taking into account
other technological systems, external risk reduction facilities and the independence of these
systems. The resultant SILs are used to determine appropriate processes to be applied in software
development. Part 3 of the standard refers specifically to the software requirements for electrical /
electronic / programmable electronic safety-related systems. Based upon the SIL of the software
component, various techniques and measures are highly recommended (HR), recommended (R),
have no recommendation (-) or are not recommended (NR). For example, formal proof is a highly
recommended technique for SIL4 software verification, and there is no recommendation for its use
on SIL1 software verification. As the guidelines for SILs are defined in terms of the amount of risk
reduction achieved by adding protection mechanisms, they fail to take account of the possibility that
such additions may result in new failure modes and new risks
b.)The process model for IEC 61508

The name comes from the basic shape of the model. The development phases start on the left
side going down, from gathering and refining the requirements to implementation of the design.
The test effort goes along the right side from the bottom up, starting with unit testing and
continuing until validation testing is correct. The V-model twists the traditional waterfall model a
bit by linking the test plans with the respective development phase. For example, after the
requirements are created, reviewed, and approved, a validation test plan can be developed. This
can also be a great tool to help refine the requirements so they are clear, understandable, and
testable. The Integration test plan is linked closely with the Architecture Design phase, where all
the interfaces are defined. The integration test plan focuses on ‘big block’ functions and
collections of functionality. The lowest test level, unit testing, is linked to the implementation
phase. Unit testing looks at the smallest functional levels of implementation to make sure they
work correctly.