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...

- Generische Produkte (BTS Build to Stock)

Beispiele: 

• PC software such as graphics programs

• project management tools

• CAD software

• software for specific markets such as appointments systems for dentists. 

- Customized Products (BTO Build to Order)

Beispiele:

• embedded control systems

• air traffic control software

• traffic monitoring systems. 

1. Analyse und Spezifikation
2. Entwicklung
3. Validierung
4. Evolution (Weiterentwicklung)

Gute Software sollte die gewünschte Funktionalität und Leistung für den Benutzer liefern und sollte Wartbar, zuverlässig und nutzbar sein

Rund 60% der Softwarekosten sind Entwicklungskosten, 40% testen die Kosten. Für kundenspezifische Software übersteigen Evolutionskosten oftmals die Entwicklungskosten.

tbd

• Benutzeranforderungen
• Applikationstyp
• Hintergrund vom Entwicklerteam

Computer Science konzentriert sich auf Theorie und Grundlagen. Software Engineering beschäftigt sich mit den Praktiken Entwicklung und Bereitstellung von nützlicher Software.

Die Systemtechnik beschäftigt sich mit allen Aspekten der computergestützten Systementwicklung, einschließlich Hardware, Software und Verfahrenstechnik. Software Ingenieurwesen ist Teil dieses allgemeineren Prozesses.

Umgang mit zunehmender Vielfalt, Forderungen nach reduzierten Lieferzeiten und Entwicklung vertrauenswürdiger Software.

Während alle Softwareprojekte professionell verwaltet und entwickelt werden müssen, sind verschiedene Techniken für verschiedene Systemarten geeignet. Zum Beispiel sollten Spiele immer mit einer Reihe von Prototypen entwickelt werden, während sicherheitskritische Steuersysteme eine komplette und analysierbare Spezifikation erfordern. Sie können also nicht sagen, dass eine Methode besser ist als eine andere.

Das Web hat zur Verfügbarkeit von Software-Diensten geführt und die Möglichkeit, hochverteilte Service-basierte Systeme zu entwickeln. Die webbasierte Systementwicklung hat zu wichtigen Fortschritten in Programmiersprachen und Softwarewiederverwendung geführt.

Weil das Finden und Spezifizieren aller Anforderungen eines System sehr schwierig ist und weitreichende Konsequenzen in die Entwicklung hat. Das Requirements Engineering Process ist dafür da um alle Anforderungen systematisch und umfassend zu finden und zu dokumentieren.

• Analysis – investigating what the system should do;

• Specification – defining what the system should do;

• Design – defining the organization of the system;

• Implementation – implementing the system;

• Validation – checking that it does what the customer wants;

• Evolution – changing the system in response to changing customer needs. 

Die Dienste, die der Kunde von einem System benötigt und die Einschränkungen, unter denen sie arbeitet und entwickelt wird

Prozesse, bei denen alle Prozessaktivitäten geplant sind und Fortschritt wird an diesem Plan gemessen.

Die Planung ist inkrementell und es ist einfacher, den Prozess zu ändern, um den sich ändernden Kundenanforderungen gerecht zu werden.

die Beschreibungen der Systemdienste und Einschränkungen, welche während des Requirements Engineering Prozesses bestummen werden.

Thewaterfallmodel

•  Plan-driven model.
• Separate and distinct phases of specification and development.

Incrementaldevelopment

• Specification, development and validation are interleaved.

• May be plan-driven or agile.

Reuse-orientedsoftwareengineering

• The system is assembled from existing components.

• May be plan-driven or agile.