Software Engineering BFH

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

tbd

+ Designfehler frühzeitig erkennen (Risiko minimieren)

+ flexibel bei neuen Anforderungen

+ früher Gewinn durch Beta-Releases

+ Kundenfeedback fliesst bereits in Implementierung rein

- Kein Ende in Sicht

- Erfordert fähiges Entwicklerteam und vollen Einsatz von jedem

- schwieriger zu planen

• show that a system conforms to its specification and
• meets the requirements of the system customer.

• Development or component testing

  • Individual components are tested independently;

  • Components may be functions or objects or coherent groupings of these entities.

• System testing

  • Testing of the system as a whole. Testing of emergent properties is particularly important. 

• Acceptance testing

  • Testing with customer data to check that the system meets the customer’s need

  • Includes usability testing

• User Requirements
  • Aussagen in der natürlichen Sprache plus Diagramme der Dienstleistungen, die das System bietet und seine operativen Einschränkungen.
  • Geschrieben für Kunden
  • Wird gelesen von: Kundenbetreuer, Endnutzer, Client-Engineers, Vertrags-Manager, System-Architekten
• System Requirements
  • Ein strukturiertes Dokument, in dem detaillierte Beschreibungen der Funktionen, System-Architekten Dienste und Betriebsbedingungen des Systems beschrieben werden.
  • Definiert, was umgesetzt werden soll, kann ein Teil eines Vertrages zwischen Auftraggeber und Auftragnehmer sein.
  • Die Systemanforderungen können in funktionale und nicht funktionale und Domänenanforderungen gruppiert werden, obwohl diese Gruppen manchmal nicht eindeutig getrennt oder sogar überlappen können.
  • Wird gelesen von: Endnutzer, Client-Engineers, System-Architekten, Software Entwickler

1. Solve System and Software development problems methodically
2. reduction of the system complexity
3. evaluation before implementation
4. Decomposition into independet modules (easier to implement)
5. Reduction of design errors > reduction of dev. Costs

• The process of developing abstract models of a system, with each model presenting a different view or perspective of that system 
• A graphical notation of a System
• A formal, mathematical description (z.B. ER for DB),
• A universal tool for different stakehoders
• It focuses on main aspects > incomplete

• External: Context or environment of the System
• Structural: Organization of a System or Structure of the processed data
• Interaction: System - -Environment or Component -- Component
• Behavioral: Dynamic behavior of the System, Responds to events

• Structural (class, object, use case, ..)
• Annotational (note)
• Grouping (package, modul, ..)
• Behavioral (activity, state, ..)

In any UML diagram

• Class D.
• Object D.
• Package D.
• Component D.
• Deployment D.

• Use Case D.
• Activity D.
• State D.
• Sequence D.

• Classes, Interfaces and other UML elementw which together realize a higher level task or abstraction.-
• Only conceptual not physikal

• Illustrate the operational context
  • what is outside the System boundaries 
  • definition of "out of Scope" on system level
  • is based on user and system requirements

- Show the system and ist relationship with oder systems