Software Engeering

Die Hardware – wörtlich übersetzt „Eisenwaren“ – umfasst sämtliche Geräte der elektronischen Datenverarbeitung.

Ein Lastenheft in der Softwareentwicklung ist ein Dokument, das die Anforderungen an eine Softwarelösung aus Sicht des Auftraggebers beschreibt. Es dient als Grundlage für die Angebotserstellung durch potenzielle Auftragnehmer und stellt sicher, dass alle Beteiligten eine klare Vorstellung von den zu entwickelnden Funktionen und Rahmenbedingungen haben.

1. Einleitung

   • Ziel des Projekts

   • Hintergrund und Motivation

   • Projektbeteiligte und Stakeholder

2. Ist-Zustand

   • Beschreibung der aktuellen Situation

   • Bestehende Probleme oder Herausforderungen

3. Soll-Zustand

   • Ziele der Software

   • Erwünschte Verbesserungen

4. Funktionale Anforderungen

   • Detaillierte Beschreibung der Softwarefunktionen

   • Use Cases oder User Stories

5. Nicht-funktionale Anforderungen

   • Performance-Anforderungen

   • Sicherheitsanforderungen

   • Usability und Barrierefreiheit

6. Rahmenbedingungen

   • Technologische Vorgaben (z. B. Programmiersprachen, Frameworks)

   • Betriebssysteme und Hardware

   • Schnittstellen zu anderen Systemen

7. Abnahmekriterien

   • Kriterien zur Beurteilung, ob die Software den Anforderungen entspricht

8. Anhänge

   • Diagramme, Mockups, Glossar

• Was soll die Software grundsätzlich leisten?

• Sind alle Anforderungen weitgehend vollständig erfasst?

• Widersprechen sich die Anforderungen nicht? • Wie lange dauert die Entwicklung wahrscheinlich?

• Können wir die Entwicklung mit dem vorhandenen Personal durchführen? Haben wir ausreichend Mitarbeiter? Sind die Mitarbeiter genügend qualifiziert? • Was kostet die Entwicklung?

• Lohnt sich die Erstellung überhaupt? Gibt es vielleicht kostengünstigere Alternativen?

• Welche Risiken können möglicherweise auftreten? Wie soll mit diesen Risiken umgegangen werden?

Das hierarchische Prinzip wird bei der Software-Entwicklung zum Beispiel durch das „Chief Programmer“-Team8 umgesetzt. Der „Chefprogrammierer“ erledigt alle wichtigen Arbeiten selbst und weist den anderen Entwicklern vor allem unkritische Detailaufgaben zu.

In der Regel arbeiten bei der Entwicklung mehrere Personen in einem Team zusammen. Über die Rollenzuweisung werden die Aufgaben, Verantwortlichkeiten und Kompetenzen jedes Beteiligten festgelegt.

Die Zuweisung dieser beiden Rollen ist nur dann sinnvoll, wenn die Programmierer nicht ihre eigene Arbeit überprüfen. Wenn das nicht sichergestellt werden kann, sollte auf die mehrfache Zuweisung der Rollen in jedem Fall verzichtet werden.

Der „Ersatzprogrammierer“ ersetzt im Notfall den „Chefprogrammierer“. Er benötigt daher dieselben Qualifikationen wie der „Chefprogrammierer“.

• Im Team arbeiten mehrere Personen mit derselben Rolle zusammen – zum Beispiel nur Tester oder nur Programmierer. Damit jede nötige Rolle abgedeckt wird, sind mehrere Teams erforderlich, die zusammenarbeiten.

• Im Team arbeiten mehrere Personen mit unterschiedlichen Rollen zusammen. Solch ein Team könnte sich um einen ganz bestimmten Bereich der Software kümmern – beispielsweise um die grafische Benutzeroberfläche oder um die Programmierung einer bestimmten Schnittstelle zu einem anderen System.

In einem demokratischen Team gibt es keinerlei Hierarchie. Alle Mitglieder sind gleichberechtigt. Entscheidungen werden vom Team gemeinsam getroffen. Das demokratische Team funktioniert allerdings nur dann, wenn kein Mitglied versucht, eine Führungsposition anzustreben.

n der Software-Entwicklung findet sich das demokratische Team zum Beispiel beim „Pair Programmer“-Team7 wieder. Hier arbeiten immer zwei Entwickler gemeinsam und gleichberechtigt an einer Lösung. Der eine Entwickler übernimmt so quasi automatisch die Qualitätssicherung für den anderen Entwickler.

Ein hierarchisches Team arbeitet mit einem Team-Leiter, der den anderen Team-Mitgliedern Arbeiten zuweist und diese Arbeiten prüft. Häufig findet sich neben dem eigentlichen Team-Leiter auch noch ein Team-Manager, der vor allem für die Organisation des Teams zuständig ist.

Der Designer ist vor allem für die Analyse und den Entwurf zuständig

der Programmierer erstellt die ausführbare Anwendung

Der Tester prüft die Software

Eine Rolle in der Software-Entwicklung definiert die Aufgaben, Verantwortlichkeiten und Kompetenzen einer Person.

Eine mögliche Rolle ist zum Beispiel Kunde. Neben der Definition der Anforderungen an die Software liefert er alle nötigen Fachinformationen, die für die Umsetzung benötigt werden, prüft die Software – zum Beispiel über Prototypen – und nimmt das fertige Produkt schließlich ab.

Auch die Anwender lassen sich über eine eigene Rolle abbilden. Ihre Aufgabe besteht im Wesentlichen in der Arbeit mit dem System.

Eine andere Rolle wäre Manager. Er ist für die Organisation der Arbeit verantwortlich.

• Entwickler

• Designer

• Tester

Als Nachteil des kooperativen Führungsstils können die zeitlichen Verzögerungen bei der Entscheidungsfindung (z.B. infolge von Beratungsgesprächen mit den Mitarbeitern) angesehen werden. Dieser Nachteil wird aber sicher dadurch ausgeglichen, dass die Entscheidungen durch die Einbindung der Mitarbeiter i.d.R. besser werden und die Mitarbeiterzufriedenheit größer ist.

Die Mitarbeiter sind anonyme Faktoren. Sie erhalten zumeist nur schriftliche Anweisungen. Berichte und schriftliche Überprüfungen kontrollieren die Arbeit.

Die Mitarbeiter werden „als Kinder“ behandelt. Sie stehen in einem Abhängigkeitsverhältnis. Informationen kommen als „Geschenk von oben“. Aufsicht und Kontrolle erfolgen nach Gutdünken.

Die Mitarbeiter sind Individuen, denen große Freiheiten eingeräumt werden. Informationen kommen zufällig. Eine Kontrolle erfolgt lediglich durch den Mitarbeiter selbst.

• mangelnde Motivation der Mitarbeiter,

• keine Selbstentfaltung des Mitarbeiters,

• möglicherweise ein überforderter Vorgesetzter (qualitativ, quantitativ), was Fehlentscheidungen verursachen kann.

• Der Vorgesetzte beteiligt seine Mitarbeiter am Entscheidungsprozess. Er erwartet von seinen Mitarbeitern eine sachliche Unterstützung.

• Der Vorgesetzte berücksichtigt die Einwände/Anregungen der Mitarbeiter bei seinen Entscheidungen.

• Er delegiert so viel wie möglich und gibt nur die nötigsten Anweisungen. Er berücksichtigt dabei die Fähigkeiten seiner Mitarbeiter und die Tatsache, dass er nicht alles weiß.

• Der Vorgesetzte führt Erfolgskontrollen durch.

• Der Vorgesetzte benötigt keine Statussymbole.

• hohe Motivation

• Entlastung des Vorgesetzten

• Förderung der Mitarbeiter

• sachgerechte Entscheidungen

Der Rational Unified Process berücksichtigt besonders die objektorientierte Entwicklung.

• der Knappheit des Angebots qualifizierter Mitarbeiter; trotz hoher Arbeitslosigkeit fehlt es häufig an qualifizierten Kräften

• der Steigerung von Anforderungen, die durch den technologischen Fortschritt bedingt sind (im DV-Bereich ist es schon seit längerer Zeit äußerst schwierig, Mitarbeiter zu finden, die in der Lage sind, die immer komplexer werdenden Aufgabenstellungen zu lösen)

• Planung des Mitarbeiterbedarfs und Beschaffung der Mitarbeiter,

• Auswahl und Einsatz der Mitarbeiter,

• Förderung der Mitarbeiter im Sinne der Aus- und Weiterbildung,

• Schaffung einer angemessenen Lohn- und Gehaltsgerechtigkeit,

• Schaffung eines angenehmen Betriebsklimas,

• angemessene Berücksichtigung der sozialen Belange der Mitarbeiter.

• kurzfristige Personalplanung

• langfristige Personalplanung

• Altersstruktur

• Krankenstand

• Fluktuation (Wechsel der Mitarbeiter)

• Sollen die Produktionskapazitäten erweitert werden? • Ist mit einschneidenden Rationalisierungsmaßnahmen zu rechnen?

• Wie sehen die Produktionsmethoden in der Zukunft aus? • Welchen Verlauf nimmt die Bevölkerungsentwicklung?

• Wie entwickeln sich die Ausbildungszeiten?

• Wie wirken sich mögliche Arbeitszeitverkürzungen aus?

Die Hauptaufgabe der Personalauswahl ist festzustellen, ob ein Bewerber für eine vorgesehene Position geeignet ist.

Ziel der Personalauswahl muss es i.d.R. sein, gute, leistungfähige Mitarbeiter langfristig zu gewinnen.

• Festlegung der Stellenanforderungen

• Erfassung der Bewerber

• Eignungsprüfung/Eignungstest

• Entscheidung über die Einstellung

Unter Motivation verstehen wir die Identifikation des Mitarbeiters mit den Unternehmenszielen. Diese Motivation kann mit bestimmten Führungsinstrumenten und Führungsprinzipien verstärkt werden. Deshalb dient eine gute, qualifizierte Mitarbeiterführung immer dem ganzen Unternehmen und trägt zur Verwirklichung der Unternehmensziele bei.

• Der Vorgesetzte trifft seine Entscheidungen ohne den Mitarbeiter und begründet Entscheidungen nicht.

• Den Anordnungen des Vorgesetzten ist widerspruchslos Folge zu leisten, andernfalls drohen Sanktionen.

• Das Verhältnis Vorgesetzter – Mitarbeiter ist distanziert. Der Vorgesetzte gibt nur die Informationen weiter, die der Mitarbeiter zur Arbeitserfüllung benötigt.

• Der Vorgesetzte kontrolliert die Befolgung seiner Anweisungen durch detaillierte Ausführungskontrollen.

• Der Vorgesetzte hat Statussymbole.

Eine Version im inkrementellen Modell wird Build genannt.

Das Spiralmodell ermöglicht durch die Risikoanalyse ein schnelles Erkennen möglicher Risiken und eine schnelle Reaktion.

• Planung,

• Analyse,

• Entwurf,

• Implementierung

• Test.

Zusätzlicher Aufwand entsteht vor allem beim Erstellen von „Wegwerf“-Prototypen. Diese Prototypen werden nach dem Einsatz nicht mehr verwendet.

Prototypen eignen sich sehr gut für die Validierung.

Vollständige Prototypen werden auch Pilotsystem genannt.

Der unvollständige Prototyp setzt nur bestimmte Teile des Systems um – zum Beispiel lediglich einen bestimmten Prozess oder die grafische Benutzeroberfläche. Unvollständige Prototypen lassen sich noch weiter unterteilen in vertikale Prototypen und horizontale Prototypen.

Ein vertikaler Prototyp bildet dabei einen bestimmten Prozess durch sämtliche Schichten des Systems ab – zum Beispiel die Ausleihe eines Buchs in unserer Leihbücherei. E

Ein horizontaler Prototyp dagegen bildet eine Schicht des Systems möglichst vollständig nach – zum Beispiel die grafische Oberfläche. Hier wird dann nur demonstriert, wie die Oberfläche aussehen könnte. Die Funktionalität – also zum Beispiel die Reaktion auf einen Mausklick auf eine Schaltfläche – dagegen fehlt.

1. der Präsentation,

2. der Applikation – die Anwendung

3. der Datenhaltung

Zur Präsentation gehört alles, was direkt am Bildschirm passiert – also zum Beispiel die Datenein- und -ausgabe, aber auch die Benutzeroberfläche. Hier erfolgt – wenn Sie so wollen – die Kommunikation zwischen Mensch und Maschine.

Zur Applikation gehört die gesamte Logik der Anwendung – also, wenn Sie so wollen, das eigentliche Programm. In der Applikationsschicht erfolgt zum Beispiel die Verarbeitung von Daten durch Berechnungen.

In der Datenhaltung schließlich erfolgen das Speichern und auch das Abrufen der Daten – meistens über Datenbanken.

Ein „Wegwerf“-Prototyp wird nur zur Demonstration eingesetzt – zum Beispiel, um dem Anwender einen ersten kurzen Eindruck zur vermitteln oder um einem möglichen Kunden eine Vorstellung von der Software zu geben. Nach der Demonstration wird der Prototyp nicht mehr verwendet – er wird „weggeworfen“. Beim „Wegwerf“-Prototyp zählt vor allem di

Wegwerf“-Prototypen werden auch Throw-away-Prototypena) genannt. Häufig findet sich auch die Bezeichnung Rapid Prototypingb).

Ein wiederverwendbarer Prototyp schließlich dient zur schrittweisen Entwicklung des vollständigen Systems. Dazu wird in der Regel zunächst ein erster Prototyp erstellt, der einige wenige eindeutig geklärte Basisfunktionen enthält. Dieser Prototyp wird dann von den Anwendern geprüft und beurteilt. Anhand der Beurteilung wird der erste Prototyp verbessert und weiter ausgebaut. Der so entstandene neue Prototyp wird wieder durch die Anwender beurteilt und weiter ausgebaut. So entsteht ein evolutionäres Modell.

Eine Evolution ist eine ständig fortschreitende Entwicklung.

Inkrement bedeutet so viel wie Zuwachs.

Hier werden verschiedene aufeinander aufbauende Versionen des Produkts – Build genannt5 – hintereinander entwickelt und ausgeliefert. Den Ausgangspunkt bilden dabei wie beim evolutionären Prototyping eindeutig geklärte Basisfunktionen. Diese Basisfunktionen werden dann in jeder folgenden Ausbaustufe weiter verfeinert beziehungsweise angepasst.

Die Spirale wird von innen nach außen im Uhrzeigersinn durchlaufen. Der Startpunkt befindet sich links oben im Inneren der Spirale.

Im ersten Schritt (in der Abbildung links oben) werden jeweils die Ziele und Anforderungen definiert, verschiedene Lösungsvarianten ermittelt sowie die Nebenbedingungen und Einschränkungen ermittelt. Zu den Nebenbedingungen und Einschränkungen gehören zum Beispiel die Kosten und Termine.

Im zweiten Schritt (in der Abbildung rechts oben) werden die verschiedenen Lösungsvarianten im Rahmen einer Risikoanalyse kritisch bewertet. Hier sollen mögliche Risiken bei der Entwicklung möglichst schnell sichtbar gemacht werden und geeignete Maßnahmen zur Beseitigung der Risiken getroffen werden. Ein wichtigstes Hilfsmittel bei der Risikoanalyse sind Prototypen.

Im dritten Schritt (in der Abbildung rechts unten) erfolgen die konkrete Umsetzung und die Prüfung der Umsetzung. Was genau in diesem dritten Schritt geschieht, hängt vom Fortschritt des Projekts ab. Zu Beginn wird zum Beispiel ein Vorgehensmodell ausgewählt (in der Abbildung innen im rechten unteren Bereich), später erfolgen hier zum Beispiel die Systemspezifikation oder der Komponententest.

Im vierten Schritt (in der Abbildung links unten) werden die nächsten Phasen vorbereitet und geplant.

Der Rational Unified Process6 – kurz RUP – ist ein Vorgehensmodell für die objektorientierte Software-Entwicklung.

• die Vorbereitung, in der vor allem die Anforderungen an das System erarbeitet werden,

• die Ausarbeitung, in der ein Entwurf für die Umsetzung der Anforderungen erstellt wird,

• die eigentliche Umsetzung – die Konstruktion

• die Einführung des fertig gestellten Systems.

• der vollständige Prototyp,

• der unvollständige Prototyp,

• der „Wegwerf“-Prototyp

• der wiederverwendbare Prototyp

Der vollständige Prototyp bildet alle wesentlichen Funktionen des Systems vollständig ab. Er wird damit quasi zur Grundlage für die Systemspezifikation. Da der Aufwand und damit die Kosten für die Erstellung allerdings sehr hoch sind, werden vollständige Prototypen nur sehr selten eingesetzt.

Sie dienen zur Prüfung der entsprechenden Phasen auf der linken Seite des Modells.

Prototypen sind – allgemein betrachtet – erste Ausprägungen eines Produktes, die wesentliche Eigenschaften des späteren Endprodukts darstellen. So werden zum Beispiel in der Automobilbranche Prototypen gebaut, um das Fahrverhalten eines Autos unter realen Bedingungen zu testen oder einfach nur, um das Auto auf einer Messe präsentieren zu können.

Das Erstellen eines Prototyps wird Prototyping genannt

Die Analysephase liefert die Vorgabe für alle weiteren Phasen. Werden hier Fehler gemacht, sind in der Regel aufwendige Korrekturen erforderlich.

Es ist keine Rückkoppelung zwischen den Phasen vorgesehen. Bei Fehlern in einer Phase muss im Extremfall ein neuer Zyklus begonnen werden

Es darf nur die Phase wiederholt werden, die unmittelbar vor der aktuellen Phase durchlaufen wurde. Eine Rückkoppelung über mehrere Phasen ist nicht vorgesehen.

Die Problemstellung gibt den Anstoß für die Entwicklung. Hier wird beschlossen, dass ein Prozess durch Software unterstützt beziehungsweise abgelöst werden soll.

In der letzten Phase – Betrieb und Wartung – wird die Software schließlich eingesetzt. Falls dabei noch Fehler auftreten, werden sie durch die Wartung behoben.

Das Wasserfallmodell geht ebenfalls von mehreren Phasen aus, die nacheinander durchlaufen werden. Es handelt sich also – wie beim Software Life Cycle-Modell – ebenfalls um ein sequenzielles Vorgehen.

Eine Wiederholung wird im Fachjargon auch Iteration genannt.

Bei diesem Beta-Test erfolgen die Prüfungen nicht mehr durch die Entwickler, sondern durch eine ausgewählte Gruppe von Anwendern. Wenn Sie so wollen, wird hier die Praxistauglichkeit der Software getestet.

• Problemanalyse

• Systemspezifikation

• Grobentwurf

• Feinentwurf

• Implementierung

• Integration

• Installation

• Betrieb und Wartung

• Anforderungsdefinition

• Grobentwurf

• Feinentwurf

• Modulimplementation

• Abnahmetest

• Systemtest

• Integrationstest

• Modultest

Bei der Validierung wird geprüft, ob ein Ergebnis auch mit einem Sachverhalt übereinstimmt.

Bei der Verifikation wird die Richtigkeit eines Ergebnisses geprüft.

In der Phase Implementierung und Komponententest werden die einzelnen Komponenten technisch umgesetzt und dann zunächst getrennt getestet. Hier erfolgt also die eigentliche Programmierung

Im Systemtest wird dann das System unter möglichst realistischen Bedingungen insgesamt getestet. Hier wird also geprüft, ob die einzelnen Komponenten korrekt zusammenarbeiten.

Bei der Problemanalyse wird festgehalten, welche Aufgaben die Software grundsätzlich erledigen soll. Ausgangspunkt sind dabei die Wünsche der Anwender. Außerdem erfolgt hier eine erste grobe Prüfung der Wirtschaftlichkeit – also „Lohnt sich die Entwicklung überhaupt?“

In der Systemspezifikation werden die noch groben Angaben zu den Aufgaben der Software konkretisiert. Hier wird also detailliert der genaue Leistungsumfang festgelegt.

Beim System- und Komponentenentwurf geht es dann darum: „Wie soll die Funktionalität erreicht werden?“ Dazu wird zunächst das System insgesamt betrachtet und dann in kleinere Teile – die Komponenten – untergliedert. Das System wird also strukturiert, hierarchisiert und modularisiert.

Das Software Life Cycle-Modell war eines der ersten Vorgehensmodelle für die Software-Entwicklung überhaupt. Es unterteilt die Erstellung in insgesamt sechs Phasen, die strikt hintereinander durchlaufen werden. Die nächste Phase darf erst dann begonnen werden, wenn die vorlaufende Phase abgeschlossen ist.

• Problemstellung

• Problemanalyse

• Systemspezifikation

• System- und Komponentenentwurf

• Implementierung und Komponententest

• Systemtest

• Betrieb und Wartung

Alle Phasen zusammen in ihrer zeitlichen Abfolge werden auch als Software-Lebenszyklus oder Software Life Cyclea) bezeichnet. Der Software-Lebenszyklus ist also die Zeitspanne, in der ein Softwareprodukt entwickelt und eingesetzt wird – bis zum Ende seiner Benutzung.

1. Der Programmierer erstellt die Anweisungen und lässt sie übersetzen.

2. Er testet, ob die Anweisungen das gewünschte Ergebnis liefern.

Build-and-Fix-Zyklus

• die Analyse („Was soll die Software machen?“),

• der Entwurf („Wie soll die Software die Aufgaben lösen?“),

• die Implementierung1 – die eigentliche Programmierung,

• der Test des Systems sowie

• Betrieb und Wartung

Zu den Prinzipien gehören • die Voraussicht,

• die Abstraktion – das Konzentrieren auf das Wesentliche,

• die Strukturierung,

• die Modularisierung – die Zerlegung in kleinere Funktionseinheiten – und

• die Hierarchisierung. Hier werden die einzelnen Elemente über mehrere Ebenen in eine Beziehung gesetzt.

Der Begriff Methode im Software Engineering umfasst neben dem Vorgehen auch Konzepte und Notationen

Der wesentliche Unterschied liegt in der Richtung. Top-Down arbeitet von oben nach unten – also vom Abstrakten zum Konkreten. Bottom-Up dagegen arbeitet von unten nach oben – also vom Konkreten zum Abstrakten.

CASE steht für Computer Aided Software Engineering – die computergestützte Software-Technik.

• die Voraussicht,

• die Abstraktion

• die Strukturierung,

• die Modularisierung

• die Hierarchisierung.

• Was ist überhaupt das Wesentliche?

• Worauf muss besonders geachtet werden?

• Was kann vernachlässigt werden?

Mit dem Prinzip der Strukturierung wird ein Problem in mehrere kleinere Teilprobleme aufgelöst. Dazu werden die Modularisierung und die Hierarchisierung verwendet.

Bei der Modularisierung wird ein System in einzelne strikt voneinander getrennte Funktionseinheiten zerlegt – die Module. Jedes Modul kann weitgehend für sich allein seine spezielle Teilaufgabe bearbeiten. Die Kommunikation der Module erfolgt dabei über fest definierte Schnittstellen.

Bei der Hierarchisierung schließlich werden die einzelnen Elemente eines Systems – zum Beispiel die Module – über mehrere Ebenen in eine Beziehung gebracht. Dabei entsteht häufig eine baumartige Struktur.

Bei der Auflösung komplexer Systeme kann man grundsätzlich auf zwei verschiedene Arten vorgehen:

• vom Abstrakten zum Konkreten oder

• vom Konkreten zum Abstrakten. Nimmt man das höchste abstrakte Niveau als Spitze – als Top – und das konkreteste Niveau als Boden – als Bottom, kann man die Wege von oben nach unten (Top-Downa)) und von unten nach oben (Bottom-Upb)) einschlagen.

Bei der Top-Down-Methode erfolgt durch schrittweise Zerlegung in einzelne Teilaufgaben über mehrere Ebenen eine immer feinere Aufgliederung, bis eine weitere Zerlegung nicht mehr sinnvoll ist. In jeder Ebene erfolgt dabei eine weitere Abstraktion der vorhergehenden Ebene. Die Zerlegung wird auch Dekomposition genannt.

Die Bottom-Up-Methode schlägt genau den entgegengesetzten Weg ein. Von einer möglichst konkreten Darstellung wird nach oben gegangen. Dabei werden die Teile einer Ebene zu einem Teil der nächsthöheren Ebene zusammengefügt. Dieses Zusammenfügen einzelner Teile zu einem Ganzen wird auch Synthese genannt.

Eine Notation ist ein System zur Darstellung von Informationen über Symbole und/ oder Texte.

Die Werkzeuge – im Fachjargon auch Tools10 genannt – sollen die Software-Entwicklung unterstützen – zum Beispiel, indem sie den Entwickler von Routinearbeiten entlasten oder ihm die Arbeit erleichtern. Bei sehr vielen dieser Werkzeuge handelt es sich selbst ebenfalls um Software.

Allgemeine Werkzeuge

CASE WErkzeuge

n. Die allgemeinen Werkzeugesind Hilfsmittel, die nicht nur für die Software-Entwicklung eingesetzt werden. Dazu gehören beispielsweise eine Textverarbeitung zum Erfassen und Bearbeiten von Dokumenten und ein Präsentationsprogramm zur Darstellung von Sachverhalten.

Die CASE-Werkzeuge(Computer Aided Software Engineering11) dagegen unterstützen direkt die Software-Entwicklung – zum Beispiel durch die Erstellung und Bearbeitung von Diagrammen oder durch Hilfestellungen bei der Modellierung. Dabei unterstützt ein Werkzeug in der Regel auch nur eine bestimmte Methode beziehungsweise Teilbereiche der Methode.

Monolithisch bedeutet eigentlich „aus einem Stein bestehend“. In der Informationstechnik ist damit aber eine Struktur aus mehreren Komponenten gemeint, die nicht zu trennen ist.

• Es gibt kaum Grenzen für die Einsatzmöglichkeiten von Software.

• Es gibt keine brauchbaren Modelle für die Entwicklung.

• Es fehlen verbindliche Standards für die Entwicklung

• Software lässt sich scheinbar sehr leicht ändern.

• Software muss in vielen verschiedenen Umgebungen arbeiten.

Software muss sich an Änderungen der Umgebung anpassen können.

• Bei der Entwicklung müssen Kreativität und feste Vorgaben kombiniert werden.

• Software lässt sich nicht am Fließband entwickeln

• Es gibt keine Ersatzteile für Software.

Software muss häufig gegen Widerstände der Anwender kämpfen.

• Die Kommunikation zwischen Anwendern und Entwicklern muss eindeutig und ohne Missverständnisse erfolgen.

• Die Anforderungen an das System müssen so exakt wie eben möglich definiert und dokumentiert werden.

• Ein komplexes System muss in ein handhabbares Modell abgebildet werden.

• Ein komplexes System muss in mehrere Teilsysteme zerlegt werden.

• Die Zusammenarbeit dieser Teilsysteme muss exakt definiert werden.

• Es sollte von vornherein darauf geachtet werden, dass möglichst viele kleine Teile des Systems in anderen Software-Produkten wiederverwendet werden können.

• Das System muss möglichst einfach zu pflegen sein. Das setzt wiederum eine möglichst genaue und vor allem verständliche Dokumentation voraus.

• Das System sollte sich möglichst einfach ändern und erweitern lassen.

• Das System muss in möglichst vielen Umgebungen arbeiten können.

• Die Entwicklung und auch die Wartung müssen durch feste Vorgehensweisen und klar definierte Zuständigkeiten koordiniert werden. Das erfordert eine detaillierte Projektorganisation und ein umfangreiches Projektmanagement.

• ausgeprägte kommunikative Kompetenzen,

• analytische Denkweise,

• sehr gute Abstraktionsfähigkeiten,

• hohe Flexibilität, • Kreativität,

• Kenntnisse einschlägiger Methoden zur Dokumentation komplexer Vorgänge, •

Voraussicht

• ausgeprägte Fähigkeiten zur Teamarbeit.

• Die vollständige Beschreibung der Anforderungen ist schwierig.

• Es gibt kaum Grenzen für die Einsatzmöglichkeiten von Software.

• Es gibt keine brauchbaren Modelle.

• Es fehlen verbindliche Standards.

• Software lässt sich scheinbar sehr leicht ändern.

• Software muss in vielen unterschiedlichen Umgebungen arbeiten. • Software muss sich an Änderungen der Umgebung anpassen können.

• Bei der Entwicklung müssen Kreativität und feste Vorgaben kombiniert werden.

• Es gibt keine Ersatzteile für Software.

1. Ermittlung und Formulierung des Problems,

2. Analyse des Problems

3. Suche nach Lösungen

4. Bewertung der Lösungen und Auswahl einer geeigneten Lösung

5. Umsetzung der Lösung

„Software Engineering ist die Entwicklung, die Pflege und der Einsatz qualitativ hochwertiger Software unter Einsatz von wissenschaftlichen Methoden, wirtschaftlichen Prinzipien, geplanten Vorgehensmodellen, Werkzeugen und quantifizierbaren Zielen.“ (Kahlbrandt)

„Software Engineering: das ingenieurmäßige Entwerfen, Herstellen und Implementieren von Software sowie die ingenieurwissenschaftliche Disziplin, die sich mit Methoden und Verfahren zur Lösung der damit verbundenen Problemstellungen befasst.“ (Brockhaus Enzyklopädie)

„Softwaretechnik: Fachgebiet der Informatik, das sich mit der Bereitstellung und systematischen Verwendung von Methoden und Werkzeugen für die Herstellung und Anwendung von Software beschäftigt.“ (Hesse und andere)

„Software-Technik: Zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden und Werkzeugen für die arbeitsteilige, ingenieurmäßige Entwicklung und Anwendung von umfangreichen Software-Systemen. Zielorientiert bedeutet die Berücksichtigung z. B. von Kosten, Zeit und Qualität.“ (Balzert, Lehrbuch der Software-Technik, Band 1).

Der Quellcode sind die Anweisungen einer Programmiersprache für die Ausführung eines Programms.

Es wurden bekannte Lösungswege in eine Form umgesetzt, die für den Computer zu verarbeiten war. Komplett neue Lösungen wurden kaum erstellt.

Die Anforderungen waren aus heutiger Sicht nicht sonderlich komplex.

Der Programmierer war häufig identisch mit dem Anwender. Damit waren Bedienfehler weitgehend ausgeschlossen.

Die Programme wurden vergleichsweise selten eingesetzt.

Der Begriff „Softwarekrise“ beschreibt die Probleme, die entstanden, als Computerprogramme immer komplexer wurden und die Anzahl der Fehler dramatisch zunahm.

In den letzten Jahren hat der Computereinsatz bei Unternehmen und auch bei Privatpersonen immer weiter zugenommen. Software hat damit eine immer größere Bedeutung bekommen.

die Systemsoftware

die Anwendungssoftware

• Betriebssystem

• Dienstprogramme

• Entwicklungssoftware

• Standardprogramme

• Branchenprogramme

•