A, B, C, E, F, I, M, O, P, Q, R, S, T, V, W
Siehe Analyse in der Entwicklung
Bei der Analyse ist aus Kundensicht festzustellen, was entwickelt werden sollte. Dies kann in Form eines Lastenhefts erfolgen. Es wird aber nicht festgelegt, was später tatsächlich entwickelt werden soll. Dies erfolgt erst in der Spezifikationsphase. Während der Analyse ist sowohl der Ist- als auch der Soll-Zustand zu dokumentieren. Denn der Ist-Zustand beschreibt die Funktionsweise des aktuellen Systems und der Soll-Zustand beschreibt die Änderungswünsche am aktuellen System. Erst die Kombination aus Ist- und Soll-Zustand beschreibt das vom Kunden gewünschte System.
Siehe Softwarearchitektur
Die Geschäftsobjekte (englisch: Business Object) bilden das Geschäftsmodell für ein Informationssystem und sind eine Realisierung aller benötigten realen oder gedachten Objekte für das Informationssystem.
Computer-Aided Software Engineering
Lower CASE-Werkzeuge werden zur Codierung, zur Eingabe, zum Übersetzen und zum Modultest eingesetzt.
Upper CASE-Werkzeuge werden zur Analyse, zur Spezifikation, zum Entwurf, zum Managen, zum Integrationstest, zur Installation und zum Betrieb eingesetzt.
Siehe Management
Ein komplexer Ablauf, wie der der Entwicklung oder eines Projekts, sollte immer unterteilt werden. In der Entwicklung lassen sich mehrere Phasen feststellen, die auch auf Projekte anwendbar sind: Analyse, Spezifikation, Entwurf, Implementierung, Test und Wartung. Diese Phasen können in unterschiedlicher Form und Reihenfolge entsprechend eines Vorgehens- oder Prozessmodells abgearbeitet werden. Tätigkeiten, die mehreren Phasen oder keiner direkten Phase zugesprochen werden können, lassen sich beispielsweise im Projektmanagement inklusive Qualitäts-, Risikomanagement und Management of Exceptions zusammenfassen.
Siehe Entwurf in der Entwicklung
Der Entwurf soll die Entwicklung eines Systems überschaubar machen. Dazu muss es in mehreren Schritten zerlegt und gegliedert werden, wobei in jedem Schritt nur so viele Komponenten und Einzelteile erzeugt werden, dass die Struktur der Komponenten und Einzelteile untereinander übersichtlich ist. Wenn jede Komponente und jedes Einzelteil ein überschaubares Problem für die Implementierung darstellt, ist der Entwurf fertig gestellt. Beim Entwurf von Software sind Architektur- und Entwurfsmuster sowie vorhandene Module innerhalb verschiedener Klassenbibliotheken von zentraler Bedeutung.
Da die Datenbank meist Bestandteil eines mehrschichtigen Softwaremodells ist, ist der Datenbankentwurf prinzipiell schon im Softwareentwurf enthalten. Der Datenbankentwurf kann aber auch separat durchgeführt werden. Er sollte sich dann weniger an den Spezifikationen eines bestimmten Softwareprojektes orientieren, sondern eher an einem allgemein gültigen Datenmodell, welches für mehrere Softwareprojekte verwendet werden kann. Der Datenbankentwurf sollte sich dann in folgende Phasen gliedern:
Die Sonderrolle des Datenbankentwurfs wird auch durch die besonderen Anforderungen an diesen verdeutlicht, wobei die Anforderungen Geschwindigkeit, Speichereffizienz, Kosten und Sicherheit miteinander konkurrieren. Beispielsweise erhöht eine normalisierte Datenbank die Datenintegrität und kann sich somit positiv auf die Speichereffizienz, Wartungskosten und Sicherheit aber negativ auf die Geschwindigkeit auswirken. So wird man bei einer transaktionsorientierten Datenbank, die immer das selbe Abfrageschema zu bearbeiten hat, von der Normalisierung abweichen, um Anfragen schneller beantworten zu können. Da bei anspruchsvollen Datenbankprojekten die Leistungsfähigkeit im Vordergrund steht, wird beim Datenbankentwurf der Verteilung und dem physischen Entwurf eine zentrale Rolle zugesprochen.
Die Informationsbedarfsanalyse dient der Abgrenzung zur realen Welt, welche man nicht versuchen sollte exakt abzubilden, da sie zu komplex und meist stetig im Wandel ist. Zur Sammlung abzubildender Datensätze können die Anwender gefragt, existierende Informationssysteme betrachtet, Geschäftsprozesse analysiert, vergleichbare existierende Lösungen hinzugezogen oder Experten befragt werden.
Beim konzeptionellen Entwurf werden die gesammelten Datensätze strukturiert und innerhalb eines ER-Modells abgebildet.
Im logischen Entwurf werden alle gesammelten Daten und deren Beziehungen zueinander auf ein logisches meist relationales Modell verteilt. Es findet eine Normalisierung der Daten statt, wobei der Grad der Normalisierung bezüglich der Aufgaben des Systems festgelegt wird.
Der physische Entwurf ist DBMS spezifisch. Hier muss ein Datenbanksystem gewählt werden, welches die Leistungsanforderungen an die Datenbank erfüllt. Es werden zum Beispiel Indexstrukturen konzipiert und Partitionen festgelegt.
Siehe Softwarearchitektur
Elektromagnetische Verträglichkeit
Siehe EMV
Failure Mode, Effects and Criticality Analysis
Beim Implementieren wird der Entwurf umgesetzt, es entsteht das spezifizierte System. Die Fachkenntnisse und die Routine des Entwicklers bestimmen beim Implementieren, wie effizient, sicher und robust der Entwurf umgesetzt wird. In der Softwareentwicklung spricht man auch vom Codieren, wobei den Programmierern durch Programmierkonventionen weitere Vorgaben zum Codieren gegeben werden können.
Datenkapselung (englisch: encapsulation, nach Parnas auch information hiding) beschreibt in der Programmierung Methoden zum Verbergen von Daten und eine Zugriffsbeschränkung auf definierte Gültigkeitsbereiche.
Dem Management wird durch alle Branchen ein einheitliches Muster von Aufgaben zugesprochen: Es entscheidet, was zu tun ist. Dabei muss es sich an Zielen, verfügbaren Mitteln und der geltenden Rechtslage orientieren. Im Bereich der Entwicklung heißt das, das Management muss eine funktionierende Entwicklung mittels eines bestimmten Budgets bereitstellen. Dazu werden Entwickler benötigt, die entsprechend ihren Stärken und Schwächen eingesetzt und motiviert werden müssen. Weiter werden Räume, Geräte, Werkzeuge und Materialien benötigt, die eingeplant, verteilt und erneuert werden müssen. Das Projektmanagement organisiert und kontrolliert die Umsetzung der Entwicklungsphasen. Es kommuniziert zwischen den Beteiligten, reagiert auf Ausnahmesituationen, ermittelt und überprüft Risiken und Qualität und übernimmt die Verantwortung für die Durchführung des Projekts.
Mess-, Steuerungs- und Regelungstechnik
Optik bezieht sich hier auf die Lasermesstechnik. Bestehend aus Laser, fokussierender Optik, Empfangsoptik und optischen Empfänger.
Siehe Management
Siehe Entwicklungsphase
Siehe Vorgehensmodell und Prozessmodell
Das Qualitätsmanagement definiert eine ganze Reihe von Qualitätszielen und Maßnahmen zum Erreichen dieser. Zur Qualitätssicherung muss das Qualitätsmanagement auf alle Bereiche einer Firma angewandt werden. Für jedes Produkt oder Projekt können zusätzliche Qualitätsmerkmale definiert werden. Qualitätsmerkmale betreffen sowohl das Produkt oder System, wie auch den Prozess oder das Projekt. Für die Qualitätssicherung sind Prozessmodelle, Standards, Tests, Reviews und modellierende Techniken, wie beispielsweise die FMECA, von zentraler Bedeutung.
Siehe Qualitätsmanagement
Beim Reengineering soll die Qualität des Systems dahingehend verbessert werden, dass Änderungen am System rentabel durchgeführt werden können. So zielt das Reengineering aus Herstellersicht auf eine Verbesserung des Systems. Eine Verbesserung aus Sicht des Kunden soll nicht stattfinden, da die Funktionen des Systems unverändert erhalten bleiben sollen. In der Praxis wird das Reengineering jedoch meistens mit funktionalen Änderungen am System verbunden sein, da Änderungswünsche des Kunden meistens der Auslöser für ein Reengineering sind. Das Reengineering kann als ein Prozess aus Reverse Engineering (Beschreibung des Ist-Systems), Restrukturierung (Feststellung des Soll-Zustands) und Forward Engineering (Erstellung des Systems) verstanden werden.
In einem Sicherheitskonzept für Datenbanken sollten folgende Punkte bedacht werden:
Am sichersten sind die Daten, wenn sie vor Diebstahl geschützt weggeschlossen sind und niemand Zugriff auf sie hat. Da die Daten in der Praxis allerdings meistens zugänglich sein müssen, ist es möglich diese zu verschlüsseln,
so dass bei einem Datenklau diese nur schwer zu analysieren sind. Werden Daten über das Netz verschickt, können die Transaktionen verschlüsselt werden, um die übermittelten Informationen zu schützen.
Eine Zugriffseinschränkung für alle Datenbanknutzer ist sinnvoll, da in der Regel nicht jeder Benutzer Administratorenrechte bekommen soll. Werden die Benutzer in Gruppen aufgeteilt, die eine Rolle zugesprochen bekommen und für jede Rolle wird jeder erlaubte Befehl explizit festgelegt, wird die Datenbank vor Manipulation durch andere Benutzer geschützt.
Passwörter schützen die Daten eines Benutzers vor unautorisiertem Zugriff durch Andere. Passwörter müssen sicher programmiert werden, so dass das Ausspähen dieser erschwert wird. Da Passwörter meist nur einen minimalen Schutz bieten können, sollte bedacht werden, ob bereits die Hardware eingeschränkt werden kann, die Zugriff auf die Datenbank erhält.
Daten können verloren gehen, wenn die Datenträger durch Umwelteinflüsse, wie Feuer oder Wasser, beschädigt werden, ein technischer Defekt durch Alterung oder Produktionsfehler auftritt oder diese durch Bedienungsfehler gelöscht beziehungsweise verändert werden. Um dem entgegezuwirken, ist eine regelmäßige Datensicherung auf Backup-Medien unabdingbar. Bedienungsfehler können durch Zugriffseinschränkungen, Transaktionssperren und Schulungen minimiert werden. Zentraler Bestandteil der Sicherung der Daten vor Verlust und Beschädigung ist aber die Reparatur und Wiederherstellung der beschädigten Daten mittels Sicherung und Rücksicherung auf beziehungsweise von Backup-Medien.
Der Software-Entwurf liefert die Softwarearchitektur. Sie zeigt die Struktur der Software und aus welchen Subsystemen sie zusammengesetzt ist. Bewährte Architekturen kann man dokumentieren und wiederverwenden. Diese werden Architekturmuster genannt und beschreiben das System als Ganzes. Entwurfsmuster befassen sich mit der Struktur von Subsystemen und bieten eine Lösung für wiederkehrende Entwurfsprobleme im Einzelnen.
Siehe Spezifikation in der Entwicklung
In der Spezifikationsphase werden die Anforderungen formuliert und dokumentiert. Die Spezifikation muss vollständig sein und ihre Anforderungen müssen überprüfbar verfasst werden, da gegenüber der Spezifikation der Entwurf des zu entwickelnden Systems und später die System-Abnahme erfolgt. Wichtig ist die Neutralität der Spezifikation. Es wird spezifiziert, was gemacht werden soll und nicht wie. Die Festlegung, wie es gemacht werden soll erfolgt im Entwurf, es sei denn der Kunde nimmt mit seinen Anforderungen einen Teil des Entwurfs vorweg. Die Spezifikation kann in Form eines Pflichtenheftes erfolgen, welches in der Softwareentwicklung auch Software Requirement Specification (SRS) genannt wird. Für die Erstellung solcher Dokumente sollten veröffentlichte Regeln und Normen eingehalten werden.
Siehe Spezifikation in der Entwicklung
Software Requirement Specification; siehe auch Spezifikation in der Entwicklung
Alle an der Software Beteiligten oder von dieser Betroffenen: Kunde, Eigentümer, Benutzer, Verkäufer, Manager, Architekt, Entwickler, Tester, Qualitätssicherung, Support, Wartung usw.
Siehe Test in der Entwicklung
Der Test ist die Überprüfung, ob etwas gemäß der Spezifikation realisiert worden ist. Tests können im Umfang und Beschaffenheit sehr unterschiedliche ausgeprägt sein und werden in verschiedenen Entwicklungsphasen immer wieder zur Qualitätssicherung eingesetzt. In der Softwaretechnik werden zahlreiche Testtechniken beschrieben:
Funktionsorientierter TestKontrollflussorientierter TestDatenflussorientierter TestSpezielle TestsDie zahlreichen Testtechniken existieren, da es keinen Test gibt, der alle Fehler aufspüren kann. Es können nur bestimmte Aspekte getestet werden und selbst die Summe aller Tests garantiert keine fehlerfreie Software. So können Tests nur die Anwesenheit von Fehlern zeigen, nicht deren Abwesenheit.
Beim funktionsorientierten Test werden die Funktionen einer Software gemäß ihrer Spezifikation ermittelt. Diese Funktionen werden anhand der Software getestet. Unter den funktionsorientierten Testtechniken werden die Funktionale Äquivalenzklassenbildung und der zustandsbasierte Test am meisten eingesetzt.
Beim Kontrollflussorientierten Test wird die Struktur des Codes betrachtet, wobei zwischen Anweisungen, Zweigen, Bedingungen, Schleifen und Pfaden unterschieden wird. Um einen kontrollflussorientierten Test auszuführen, müssen die Testfälle das entsprechende Strukturkriterium vollständig abdecken. So wird beispielsweise der Zweigüberdeckungstest vollständig ausgeführt, wenn alle Zweige durchlaufen werden beziehungsweise jede Bedingung einmal falsch und einmal wahr liefert. Der Zweigüberdeckungstest gilt als minimale Anforderung an einen kontrollflussorientierten Software-Test.
Neben den funktionsorientierten und strukturorientierten Testtechniken existieren noch diverse weitere, die sich schwer kategorisieren lassen, wie zum Beispiel das Error guessing und der Zufallstest. Beiden Tests kommt eine gesonderte Bedeutung zu, weil einmal die Erfahrung eines Testers direkt ausgenutzt wird und das andere Mal der Tester zur Erzeugung der Testfälle ausgeschlossen wird. Beim Testen von Servern oder zeitkritischen Anforderungen sollte auf einen Last-, Stress- oder Überlasttest nicht verzichtet werden.
Da Tests keine Fehlerfreiheit garantieren können und nicht alle möglichen Tests durchgeführt werden sollen, ist es wichtig in einem Testkonzept zu definieren, welche Tests wie und in welchem Umfang durchgeführt werden sollen. So stellt das Testkonzept ein wichtiges Qualitätsmerkmal dar.
Jeder Entwicklung oder jedem Projekt liegt ein gewisser Ablauf zu Grunde, ob er nun explizit beschrieben oder intuitiv gewählt ist, ist dabei unerheblich. Auch wenn der Ablauf beziehungsweise der Prozess nicht benannt oder beschrieben wird, folgt er meistens einem bereits veröffentlichten Vorgehens- beziehungsweise Prozessmodell. Während Vorgehensmodelle einen Ablauf beschreiben, beschreiben Prozessmodelle den Ablauf genauer, indem sie Personen und deren Rollen sowie Dokumente und deren Funktion mit einbeziehen. Als Beispiele für ein Vorgehensmodell können das Code and Fix-Modell, Wasserfallmodell, die Prototypingmodelle und das Spiralmodell aufgeführt werden. Als Beispiele für ein Prozessmodell können das V-Modell, das Phasenmodell und das Extreme Programming aufgeführt werden.
An sich kann die Wartung kein Teil der Entwicklung sein, da nach Abschluss der Entwicklung, die Wartung beginnt. Da aber generell die Entwickler von der Wartung des Systems nicht vollständig ausgeschlossen werden können, sollte diese auch in der Entwicklung einkalkuliert werden. Verglichen mit den Entwicklungsphasen ist der Aufwand für die Wartung eines guten Systems besonders hoch, denn ein gutes System ist lange im Einsatz und weckt neue Begehrlichkeiten. Hinzu kommen turnusmäßige Änderungen (z. B. Abnutzung, Aktualisierungen) und sporadische (z. B. Zwischenfälle, Umrüstung).
