0% found this document useful (0 votes)
43 views16 pages

Implement Maintenance Procedures LO3

This document discusses maintaining IT systems by identifying components, reviewing documentation, and analyzing system architecture. It describes determining warranty status, reviewing system architecture and configuration documentation including physical and logical components, software and network capabilities, and risk analysis outputs. The document outlines identifying hardware and software resources, interfaces, functions, and how third party software is integrated and used within the system.

Uploaded by

abebaw
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
43 views16 pages

Implement Maintenance Procedures LO3

This document discusses maintaining IT systems by identifying components, reviewing documentation, and analyzing system architecture. It describes determining warranty status, reviewing system architecture and configuration documentation including physical and logical components, software and network capabilities, and risk analysis outputs. The document outlines identifying hardware and software resources, interfaces, functions, and how third party software is integrated and used within the system.

Uploaded by

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

LO 3:

Identify and analyze IT system


components to be maintained
Determining and documenting Warranty Status
Documenting Warranty Status
• A warranty describes the conditions under, and period during, which the
producer or vendor will repair, replace, or other compensate for, the
defective item without cost to the buyer or user.
• Often it also delineates the rights and obligations of both parties in case of a
claim or dispute.
• ICT equipment companies guarantees that all the products undergo
backbreaking quality control testing before delivery and installation.
• In the event that any product of these manufacturers is found to be
defective, the company will provide service for product repair and/or
component replacement as may be necessary within the warranty period as
per the terms mentioned here under.
Reviewing system architecture and
configuration documentation
Architecture overview
• Give general description of the system, from the point of the user:
 In what environment it works ( home, near patient bed, operating rooms….)
 Who the users are
 What it is for
 The main functions
 The main interfaces, input and outputs
 If your soft ware is integrated in a large system, you may reference a
document that describes this system.
Physical architecture overview

• Describe the hardware components on which software runs and their


interactions/relationships
• Use components diagrams, deployment diagrams, network diagrams,
interface diagrams…
Hardware Component description

• Describe the content of each hardware component in the architecture


 Its identification
 The purpose of the component
 The software component it receives
 Its technical characteristics: type of machine, CPU, RAM, disk and so
on.
 Its network hardware interfaces
Logical architecture overview

• Describe the top level software components and their


interactions/relationships.
• Use UML package diagrams and/or layer diagrams and/or interface
diagrams.
• Describe also the operating systems on which the software runs.
Software Component description

• Describe the content of each top-level software component in the


architecture
• The description should contain:
 Its identification
 the purpose of the component,
 Its interfaces with other components,
 Its network interfaces
Software SOUP
If you use SOUP (Software Of Unknown Provenance /source/), list
them here. For each SOUP, describe:
• Its identification and version
• Its purpose
• Where it comes from: manufacturer, vendor, university …
• Whether it is maintained by a third party or not
• If this is an executable,
Cont.…
• What are the hardware / software resources it uses
• Whether it is insulated in the architecture and why
• Its interfaces and data flows
• Which SOUP functions the software uses
• How the SOUP is integrated in the software
• What hardware/software resources it requires for proper use
Dynamic behavior of architecture
• The architecture was designed to answer to functional requirements.
• For each main function of the system, add a description of the sequences / data
flow that occur.
• Use sequence diagrams, collaboration diagrams

Workflow / Sequence 1
• Describe here the workflow / sequence of a main function
• For example, the user queries data, what happens, from his terminal to the
database.

Workflow / Sequence 2
• Repeat the pattern for each main function of the system
System architecture capabilities

Describe here the rationale of the hardware / software architecture in


terms of capabilities:
• Performances (for example response time, user mobility, data storage,
or any functional performance which has an impact on architecture)
• User / patient safety
• Protection against misuse
• Maintenance (cold maintenance or hot maintenance),
• Adaptability, flexibility
Cont.…
• Scalability, availability
• Backup and restore
• Hardware and Software security : fault tolerance, redundancy,
emergency stop, recovery after crash …
• Administration,
• Monitoring, audit
• Internationalization
Network architecture capabilities
If the medical device uses/has a network, describe here the rationale of
the hardware / network architecture:
• Bandwidth
• Network failures
• Loss of data
• Inconsistent data
• Inconsistent timing of data
• Cyber security (see FDA Guidance on Cyber Security of networked
medical devices)
Risk analysis outputs
• If the results of risk analysis have an impact on the architecture,
describe here for each risk analysis output what has been done to
mitigate the risk in the architecture.
• Use diagrams if necessary, like architecture before risk mitigation and
architecture after risk mitigation, to explain the choices.
Human factors engineering outputs

• If the results of human factors analysis have an impact on the


architecture, describe here for each risk human factors output what has
been done to mitigate the risk in the architecture.
THANK YOU!

You might also like