Software Engineering BFH

• Requirements elicitation (herauspicken)
• Requirements analysis
• Requirements validation
• Requirements management

• Preface
• Introduction
• Glossary
• User requirements definition
• System architecture
• System requirements specification
• System models
• Testing
• Appendices
• Index

erweitert Wasserfall-Modell um Validierungsphasen

1. Musskriterien
2. Sollkriterien
3. Kannkriterien
4. Abgrenzungskriterien

A system that runs paralles to an other (security relevant) system to execute a task if the main system fails. It does the same as the main system does but with other sensors, techniques and technologies.

By:

• Fault avoidance:
  • Development
  • z.B. exeption handling, check inputs --> if(23:00){...
• Fault detection and removal
  • Verification and Validation before the system goes live
  • Testing
• Fault tolerance
  • runtime techniques > ensure that the system faults do not result in errors
    and that errors do not lead to system failures
  • Redundancy, protection systems

DU!

Weiterhin viel SPASS beim Lernen :-)

• Primary safety-critical systems:
  • Direct
  • Embedded sw-systems whose failure cause the hardware to fail and directy threaten people
• Secondary safety-critical systems:
  •  Indirect
  • Systems whose failure results in faults in other systems and .... 

• Hazard: Condition with the condition for causing an accident: Failure of the sensor
• Accident (mishap): Unplanned event resulting in human death or injury of anyting: Overdose of Insulin
• Damage: Result of the Accident: Overdose could cause injury or death of patient
• Hazard severity: Assessment of the worst possible damage: Possibility of death > severity = very high
• Hazard probaility: Pobability of the hazard:  Pobability of a sensor failure = low
• Risk: comparison of severity and probability: risk of an insulinoverdose is probably medium to low

• Hazard avoidance
  • Design: Classes of hazard cannot arise
• Hazard detection and removal
  • Design: Hazard are detected and removed
• Damage limitation
  • Protection features that minimize the damage

1. Risk identification
2. Risk assessment 
   • analize damage and hazard severity and probabilityof each possible accident 
     (injuries, cost etc...)
3. Risk treatment
4. Risk monitoring and incident handling

• avoidance: eliminate risks
• reduction: mitigate impact and/or probability
• sharing: outsource or insure against
• acceptance: incident plan (what if..)

1. Signal to a calling component
2. Carry out some alternative processing
3. Pass control to a runtime support system to handle the exception

• Floating-point numbers (unprecise)
• Parallelism (timing errors)
• Out of memory (attempt to process too much data)
• Recursion: stack overflows
• Aliasing

• That the sw meets its requirements
  • i.e. perfomrs correctly using a set of test cases

• The test cases are designed to expose defects.
• The inputs shall cause anaomalous behavior
• A successful test is a test that makes the system perfomr incorrectly

Unit testing (methods)

component testing (interfaces)

system testing (interaction)

The process of testing a system that is intended to use outside the development team.

examining the source with the aim of discovering anomalies and defects

does not use execution of the system

May be applied on requirements, design, configuration, data, test data, etc...