| Abnahmeprotokoll | Protokoll der Systemabnahme. | |
| Abnahmetest | Systemtest, welcher von Benutzern in der produktiven Umgebung mit den migrierten, produktiven Daten durchgeführt wird und Grundlage für die Systemabnahme bildet. Die zur Anwendung kommenden Testfälle sollten prinzipiell analog jenen des Betatests sein, können aber aufgrund einer veränderten – meist zum Voraus nicht immer bekannten - konkreten Datenkonstellation – nicht vollständig identisch sein. | |
| Abstrakter Use-Case | Use-Case, welcher durch mindestens einen spezialisierten Use-Case konkretisiert wurde. Beispiel: Der abstrakte Use-Case „Bestellung erfassen“ kann durch spezialisierte Use-Cases „Bestellung via Internet erfassen“ sowie „Bestellung telefonisch erfassen“ konkretisiert bzw. spezialisiert werden. | |
| Aktivität | Eine Aktivität ist ein einzelner Schritt in einem Ablauf. Eine Aktivität ist z.B. ein Schritt in einem Geschäftsprozess (als solcher gilt also auch z.B. der Prozess „Anforderungsanalyse“ oder „Systemdesign“), aber auch ein etwas kleinerer (oft dann schon fast technischer) Schritt innerhalb eines Use-Case, wenn dieser mit Hilfe eines Aktivitätsdiagramms detailliert analysiert wird. | |
| Akzeptanztest | Siehe: Abnahmetest | |
| Alphatest | Systemtest, welcher beim und in der Regel durch den Entwickler durchgeführt wird. | |
| Analyseklasse | Fachlich motivierte Klasse, die einen Begriff aus dem Problembereich des zu entwickelnden Systems repräsentiert. Sie ist ein Ergebnis der Systemanalyse und wird nach dem CRC-Card Prinzip (Class, Responsabilities, Collaborations) detailliert beschreiben. Analyseklassen werden unterteilt in Entity, Controller und Interface (Boundary). Thematisch zusammengehörende Analyseklassen werden in einem Analyseklassen-Diagramm dargestellt. | |
| Analyseklassen-Diagramm | Klassendiagramm der Entities. | |
| Analysemodell | Das Analysemodell ist ein informatiktechnischer (aber technologieneutraler) Entwurf des Systems im Rahmen der Systemanalyse. Es besteht aus (1) Analysepaketen, (2) Analyseklassen-Diagrammen, (3) Analyseklassen, welche gemäss dem CRC-Card Prinzip (Class, Responsabilities, Collaborations) beschrieben sind sowie einer (4) Use Case Realisierungsanalyse. | |
| Analysepaket | Gruppierung von fachlich zusammengehörenden Analyseklassen. Anfänglich werden Analysepakete als „Arbeitspakete“ durch fachlich zusammengehörende Use-Cases gebildet, die letztendlich gültige Paketierung wird letztlich aufgrund eher technischer Aspekte (z.B. Vermeidung zyklischer Abhängigkeiten sowie Redundanzen) definiert. | |
| Änderung | Abweichung des beobachteten Programmverhaltens von einem bisher nicht schriftlich als Anforderung festgehaltenen Bedürfnis. Eine Änderung manifestiert meistens nur eine Änderung der schriftlich formulierten Anforderungen und nicht ein verändertes Bedürfnis, was die meisten Praktiker mit gesundem Menschenverstand wohl etwas befremden dürfte, letztlich aber immer wieder Ursache von Konflikten ist. | |
| Anforderung | Eine Anforderung beschreibt ein Merkmal oder eine Fähigkeit, welche das System aufweisen muss. Es wird unterschieden zwischen funktionalen und nicht funktionalen Anforderungen. | |
| Anforderungsanalyse | Disziplin mit dem Ziel, die Systemanforderungen zu ermitteln und schriftlich zu formulieren. Diese werden im Use-Case Modell, den Zusatzanforderungen sowie dem Externen Entwurf (Dialog- und Report-Design) dokumentiert. | |
| Anwendungsfall | Siehe: Use-Case | |
| Assembly | Assemblies sind wieder verwendbare, versionierte und selbstbeschreibende Baublöcke des .NET Frameworks und werden typischerweise als Exe- oder Dll-Dateien ausgeliefert. | |
| Assembly-Group | Sammlung der 4 Assemblies, welche notwendig sind, um gemäss der AdeNet-Architektur einen kompletten Layer-Stack (Web, Logic, Data und Common) zu bilden. | |
| Ausbildungskonzept | Das Ausbildungskonzept beschreibt alle Anforderungen an die Ausbildung sowie alle Massnahmen und Mittel, um die Anwender und Betreiber des Systems auszubilden. | |
| Ausbildungsunterlagen | Menge der Unterlagen zur Durchführung von Schulungen für Benutzer und Systembetreiber. | |
| Auslieferung | Disziplin mit dem Ziel, das realisierte System optimal an die Benutzer auszuliefern. In unserem Umfeld ist das Ergebnis der Auslieferung ein Patch. | |
| Auswertung | Siehe: Report | |
| Bedürfnis | Ein Bedürfnis ist die „wahre“ Anforderung eines Kunden, welches er mit einer Softwarelösung gelöst haben will und weshalb er überhaupt ein Projekt in Auftrag gegeben hat. Im Rahmen der Anforderungsanalyse wird versucht, diese Bedürfnisse in konsistente und für jedermann verständliche funktionale und nicht funktionale Anforderungen zu formulieren. Das Bedürfnis ist das, was der Kunde letztlich will, aber leider nicht immer das, was im Rahmen einer fast immer mit Unklarheiten behafteten Systemanforderung formuliert wurde. Die Diskrepanz zwischen Bedürfnis und Programm ist kein Fehler sondern eine Änderung, deren Behebung meistens mit terminlichen und finanziellen Konsequenzen verbunden ist. | |
| Benutzerhandbuch | Anleitung in Papierform oder als elektronische Hilfe für die Benutzer zur Bedienung des Systems. | |
| Betatest | Systemtest, welcher beim und in der Regel durch den Kunden durchgeführt wird. | |
| Black-Box-Test | Beim Black-Box-Test wird nur das von aussen her beobachtbare Verhalten überprüft. Die Typisierung Whitebox-/Blackbox-Test ist von mässiger praktischer Bedeutung. Siehe auch: White-Box-Test. | |
| Boundary | Analyseklasse, welche die Interaktion zwischen dem System und einem Aktor (Benutzer, anderes System, Device oder Software-Komponente) modelliert. Der Austausch von Daten zwischen dem System und den Aktoren ist auschliesslich über Boundary-Klassen möglich. Boundary-Klassen sind häufig Formulare. | |
| Business Use-Case (BUC) | Use-Case als Teilergebnis der Geschäftsprozessmodellierung bzw. der Situationsanalyse. Im Unterschied zu den letztlich zu realisierenden System Use-Cases sind Business Use-Cases oft noch abstrakt (d.h. konkrete Ausprägungen wie z.B. „Antrag telefonisch oder via Internet“ wurden noch nicht untersucht) und allenfalls noch redundant (d.h. mit redundanter bzw. wiederkehrender Funktionalität, welche durch sekundäre Use-Cases beschrieben - und später ev. auch implementiert - werden kann). Business Use-Cases sollten Ergebnisse von geschäftlichem Wert erzeugen. | |
| Business-Interface | Interface eines Business-Objects. | |
| Business-Object | Ein AdeNet-Architektur-Element, welches TableModule übergreifende Geschäftslogik implementiert. | |
| CodeGenerator | AdeNet-Tool für die Erzeugung von typisierten TableModules. Basiert auf dem DataDictionary. | |
| Controller | Analyseklasse, welche die gesamte notwendige Funktionalität umfasst, um die Use-Cases umzusetzen. Controllers verwenden Entities in logischen Abläufen und stellen Entity-übergreifende Business Logik zur Verfügung. Controller-Klassen resultieren im Systemdesign meistens in Business-Objects. | |
| DataDictionary | Metadaten-Datenbank für die Erfassung der TableModules und deren physischem Mapping. Ist die Grundlage für die Codegenerierung mittels des CodeGenerators. | |
| Datenbankmodell | Umfasst die Definition der Tabellen und Felder eines RDBMS. | |
| Desigmodell | Umfasst die Definition von Designpaketen und dafür jeweils ein Klassendiagramm, Detailbeschreibungen der Designklassen, Interfaces sowie einem Persistenzmodell (meist Datenbankmodell). | |
| Designklasse | Überbegriff für die während des Systemdesigns identifizierten Klassen. Siehe: TableModule, Business-Object, Business-Interface, Facade, Facade-Interface, Formular | |
| Designklassen-Diagramm | Klassendiagramm der Designklassen. | |
| Designpaket | Siehe: AssemblyGroup, Paket welches während des Systemdesigns erstellt wird. | |
| Diagramm | Grafische Repräsentation eines Modells bzw. Ausschnitt eines Modells. | |
| Dialogdesign | Definition des Aufbaus sowie des Ablaufs der Benutzeroberfläche (HTML-Formulare). | |
| Dokument | Auswertung, welche meistens publiziert und an eine Drittperson (Geschäftspartner) gerichtet ist. Beispiele: Brief, Verfügung, Abrechnung. | |
| Einzeltest | Siehe: Unit-Test | |
| Entity | Analyseklasse, welche alle langlebigen, häufig persistenten Daten eines Systems verwaltet. Entities beinhalten nur Funktionalität, welche die verwalteten Daten direkt betrifft. Sie dürfen keine Funktionalität enthalten, welche einer Umsetzung der Anwendungsfälle gleichkommt. Entity-Klassen resultieren im Systemdesign oft in Table-Modules. | |
| Facade | Implementiert das gleichnamige Facade-Interface und ermöglicht die Verteilung der Applikation auf einen Web- und einen Applikationsserver. | |
| Facade-Interface | Interface zwischen dem Presentation Layer und dem Business Layer. | |
| Fachklasse | Siehe: Analyseklasse | |
| Feature | Sammlung von (häufig noch zu konkretisierenden) Grobzielen bzw. Leistungsmerkmalen, welche direkt ein Bedürfnis der Stakeholders befriedigt. | |
| Fehler | Abweichung des beobachteten Programmverhaltens von der im Testfall definierten Vorgabe. | |
| Formular | Ein AdeNet-Architektur-Element, welches ein Benutzeroberflächenformular implementiert. Besteht aus einer View (grafisches Layout) und einem Document (Aktionen und Daten). | |
| FURPS+ | Q-Grundmodell, welches von RUP verwendet wird. Die Kürzel stehen für Functionality, Usabiltiy (Nutzbarkeit), Reliability (Zuverlässigkeit), Performance sowie Supportability (Wartbarkeit). Das + steht für zusätzliche Kriterien wie z.B. Implementierungsrichtlinien (verwendete Standards oder Programmiersprachen), Interface-Bedingungen (Bsp: Zeitformate) u.a. | |
| Geschäftsanwendungsfall | Siehe: Business Use-Case (BUC) | |
| Geschäftsdatenmodell | Konzeptionelles und in der Regel relativ grobes Datenmodell, welches voraussichtlich zur Speicherung der Daten des Geschäftsprozessmodells benötigt wird. | |
| Geschäftsfall | Siehe: Geschäftsanwendungsfall | |
| Geschäftsklasse | Siehe: Analyseklasse vom Stereotyp „Entity“. | |
| Geschäftsmodell | Ergebnis der Geschäftsprozessanalyse. Besteht aus dem Geschäftsprozessmodell sowie dem Geschäftsdatenmodell. | |
| Geschäftsprozess | Ein Geschäftsprozess ist eine Zusammenfassung einer Menge fachlich verwandter Business Use-Cases. Dadurch bildet ein Geschäftsprozess gewöhnlich eine Zusammenfassung von organisatorisch evtl. verteilten, fachlich jedoch zusammenhängenden Aktivitäten, die notwendig sind, um einen Geschäftsvorfall (z.B. einen konkreten Antrag) ergebnisorientiert zu bearbeiten. Die Aktivitäten eines Geschäftsprozesses stehen gewöhnlich in zeitlichen und logischen Abhängigkeiten zueinander [OEP]. | |
| Geschäftsprozessanforderungen | Die Anforderungen an die Geschäftsprozesse definieren die notwendigen Änderungen, Ergänzungen oder Erweiterungen, um das neue System zu integrieren und effizient zu nutzen. | |
| Geschäftsprozessmodell | Modell der existierenden oder gewünschten Prozesse der Zielorganisation. Ist Bestandteil des Geschäftsmodells und besteht aus einer Prozessübersicht (Use-Case Diagramm), Prozessdiagrammen sowie knappen Prozessbeschreibungen. Das Geschäftsprozessmodell wird normalerweise im Rahmen der Voranalyse erstellt. | |
| Geschäftsprozessmodellierung | Diese Disziplin hat 3 unterschiedliche Zielsetzungen. (1) In der Voranalyse verfolgt sie das Ziel, das Geschäft des Kunden zu verstehen und gleichzeitig eine Grundlage für die nachfolgende Anforderungsanalyse zu schaffen. Im Rahmen dieser Disziplin wird ein Geschäftsmodell, bestehend aus einem Prozessmodell und einem Geschäftsdatenmodell definiert. (2) Während der Konzeptphase und spätestens in der Einführungsphase werden die notwendigen organisatorischen Veränderungen evaluiert und definiert. (3) Im Rahmen der Phase „Implementierung“ werden die vorhandene Komponenten (Formulare und Reports) mit Hilfe der Geschäftskontrolle zu lauffähigen Prozessen zusammengebaut. | |
| Glossar | Liste mit einer einheitlichen Definition von Begriffen. | |
| Implementierungsmodell | Entwicklungsprojekt in Visual Studio gemäss den Normen von AdeNet („AdeNet-Projekt“). Ist also eine Sammlung von Sourcecode und referenzierten Bibliotheken. Umfasst ebenfalls das Unit-Testmodell (in Form von N-Unit-Testscripts) zum Testen der elementaren Funktionalität der enthaltenen Programmkomponenten. | |
| Informationssicherheit und Datenschutz (ISDS) | Disziplin mit dem Ziel, im erzeugten System die Voraussetzungen für eine optimale Sicherheit von Daten und Services in Bezug auf ihre Vertraulichkeit, Integrität und Verfügbarkeit zu gewährleisten. | |
| Integrationstest | Der Integrationstest überprüft die Schnittstellen zwischen elementaren Systemelementen, insbesondere zwischen einzelnen Komponenten. Der Unit-Test wird im Rahmen der Disziplin „Implementierung“ durch die Entwickler durchgeführt. Der Unit-Test ist typischerweise ein Black-Box-Test. | |
| Interface | Sammlung von semantisch zusammengehörenden Methoden einer Komponente. Bildet den Vertrag für die Kommunikation mit der Komponente. | |
| ISDS | Siehe: Informationssicherheit und Datenschutz | |
| ISDS-Konzept | Definiert die nötigen Angaben zur Erhaltung und Verbesse¬rung der Informationssicherheit und des Datenschutzes. | |
| Klassifizierungspattern | Entwurfsmuster für die Abbildung von Vererbung aus dem Analysemodell auf Business-Objects und TableModules. | |
| Komponente | Weitgehend unabhängiger und damit ersetzbarer Teil eines Systems, welche eine klare Aufgabe im Rahmen einer wohl definierten Architektur ausführt. Die Nutzung von Komponenten erfolgt via Interfaces. | |
| Konfigurations- und Change Management | Disziplin mit dem Ziel, sämtliche Ergebnisse des Entwicklungsprozess (Programmkomponenten, Source-Code, Dokumente) als Versionen und übergreifenden Konfigurationen konsistent zu verwalten. | |
| Liste | Auswertung, welche in den meisten Fällen für interne Zwecke verwendet wird. Im Gegensatz zur Statistik hat die Liste einen relativ einfachen Aufbau. | |
| Marketingkonzept | Definiert den Namen, das Logo des Projekts, legt fest, welche Interessengruppen allenfalls mit Marketingaktivitäten zu „Befürwortern“ gemacht werden müssen und definiert eine Planung für diese Marketingaktivitäten. | |
| Materialsammlung | Geordnete Sammlung (wenn möglich als PDF) aller Materialien, welche insbesondere aus der Situationsanalyse anfallen. Darunter fallen insbesondere Dokumentationen bestehender Lösungen sowie Beispiele für erzeugte Output-Dokumente. | |
| Migrationsdesign | Verfeinerung des Migrationskonzepts. | |
| Migrationskonzept | Definiert die technischen und organisatorischen An¬forderungen an die Migrationsverfahren, um den Übergang vom Ist- zum Soll-System durchzuführen. | |
| Modell | Abbild einer konkreten Sache in vereinfachter Form, mit dem Ziel, etwas zu veranschaulichen und zu einem besseren Verständnis beizutragen. Innerhalb eines Modellierungswerkzeuges (z.B. für UML) wird als Modell die Summe aller gespeicherten Informationen angesehen. Einzelne Diagramme repräsentieren grafisch einen bestimmten Ausschnitt dieses Modells. Nicht jede Modellinformation muss dabei in einem Diagramm enthalten sein. Eine Modellinformation kann jedoch in verschiedenen Diagrammen enthalten sein. | |
| Object Management Group (OMG) | Industriekonsortium mit dem Ziel, Informatik-Standards zu formulieren. Mitglieder von OMG sind u.a. IBM, HP, SUN, Oracle, Daimler-Chrysler etc. | |
| OMG | Siehe: Object Management Group (OMG) | |
| Organisationsanforderungen | Definition der für die Inbetriebnahme und Nutzung notwendigen Ergänzungen oder Erweiterungen der Organisation, in welcher das System eingeführt werden soll. | |
| Organisationsbeschreibung | Die Beschreibung der Organisation dokumentiert die Änderungen, Ergänzungen oder Erweiterungen, welche aufgrund des neuen Systems notwendig sind. Die Organisationsschreibungen werden im «top-down» Verfahren dokumentiert. Ausgehend von der Organisationsübersicht werden die verschiedenen Organisationseinheiten/-bereiche detaillierter beschrieben, mit ihren vom neuen System betroffenen Aufgabenbereichen und den tangierten Schnittstellen zu anderen Bereichen. | |
| Organisationshandbuch | Das Organisationshandbuch beschreibt die Integration des Informatiksystems (als technisches Produkt) in die Organisation des Anwenders sowie die organisatorischen Schnittstellen zur Umgebung. Es regelt die personellen, sachlichen und zeitlichen Aspekte der Organisation für die Nutzung des Systems. | |
| Paket | Ansammlung von Modellelementen beliebigen Typs, mit denen das Gesamtmodell in kleinere überschaubare Einheiten gegliedert wird. Je nach Disziplin spricht man von Analyse- oder Designpaketen. Letztere werden in AdeNet als AssemblyGroups bezeichnet. | |
| Patch | Neue, korrigierte oder erweiterte Programmversion inkl. Installations- bzw. Migrationsverfahren (Migrationsprogramm sowie Installations- bzw. Anpassungsanleitung) sowie allen für die Nutzung und den Betrieb notwendigen Handbücher. | |
| Persistenzmodell | Umfasst die Definition des persistenten Datenmodells. Besteht bei Datenbankanwendungen primär aus dem Datenbankmodell, kann aber auch eine Speicherung im Dateisystem beschreiben. | |
| Programmversion | Operationelle (lauffähige) Version des Systems oder eines nutzbaren Teils davon. | |
| Projekt | Ein Projekt ist ein einmaliges und einzigartiges Vorhaben mit einem bestimmten Anfang und einem bestimmten Ende, welches ein definiertes Ziel mit begrenzten Mitteln an Ressourcen in einer definierten Qualität erreichen soll. | |
| Projekt Erfahrungsbericht | Die Erfahrungen, welche in einem Projekt gemacht werden, sowohl Gute wie Problematische, liefern wertvolle Informationen, die von nachfolgenden Projekten genutzt werden können, um positive Aspekte zu übernehmen und um negative Vorfälle nach Möglichkeit zu verhindern. | |
| Projektantrag | Der Projektantrag schafft für jedes Projekt eine definierte Ausgangslage, um über das weitere Vorgehen zu entscheiden. Die für die Beurteilung notwendigen Angaben werden zusammenfassend dargestellt. Ein unterschriebener Projektantrag wird zu einem Projektauftrag. | |
| Projektcontrolling | Projektcontrolling ist das Nachprüfen des erbrachten Aufwands, der Vergleich mit dem Fertigstellungsgrad und die daraus abgeleitete Prognose für den weiteren Verlauf des Projekts. Es liefert damit sozusagen die Positionsbestimmung des Projektleiters. | |
| Projekthandbuch | Das Projekthandbuch definiert den allgemeingültigen technischen und organisatorischen Rahmen eines Projekts. Es enthält all jene Regelungen, welche weder im Vorgehensmodell AdeNet/VM noch im Projekthandbuch definiert sind. | |
| Projektmanagement | Disziplin, welche alle willensbildenden und willensdurchsetzenden Aktivitäten und Ergebnisse zur Führung und Abwicklung von Projekten umfasst. Die Schwerpunkte des Projektmanagements sind die Bildung einer funktionsfähigen Projektorganisation; Planung, Umsetzung, Kontrolle und Steuerung der Projektabwicklung; Betrieb des Informationszentrums des Projekts; sowie die Sicherstellung einer geeigneten Projektinfrastruktur. Die Aktivitäten des Projektmanagements lassen sich in zwei Gruppen unterteilen: (A) Initialisieren und Abschliessen des Projekts, (B) Führen eines Projekt während seiner Laufzeit. | |
| Projektmarketing | Disziplin mit dem Ziel, die Kommunikation mit allen Beteiligten inner- und ausserhalb des Projektes sicherzustellen. Im Rahmen des Projektmarketings sollen Bedürfnisse für das Projektresultat und ein Verständnis für das Projekt an sich geschaffen bzw. gefördert werden. | |
| Projektplan | Der Projektplan enthält die Planung und Organisation des gesamten Projekts und ergänzt das Projekthandbuch als Handlungsgrundlage. Der Projektplan wird fortlaufend (typischerweise nach jeder Phase) nachgeführt und enthält dann immer einen überarbeiteten Gesamtplan sowie eine Detailplanung für die nachfolgende Phase. | |
| Projektvision | Für alle Projektbeteiligten verständliches, allein stehendes Papier (z.B. in Prospektform) mit folgendem Inhalt: (1) wichtigste zu lösenden Bedürfnisse, (2) Zielsetzungen, (3) Features (grobe Leistungsmerkmale), welche im Rahmen der Anforderungsanalyse noch präzisiert werden müssen, (4) Abgrenzungen (was gehört nicht zum Auftrag), (5) Wichtigste Rahmenbedingungen (sofern relevant). Die Projektvision kann nach Bedarf auch in der Projektphase noch einmal aktualisiert werden. | |
| Prototyp | Der Prototyp dient zur Untersuchung kritischer Teilsysteme und zur Absicherung ausgewählter Aspekte des Konzepts und der Systemspezifikation. | |
| Q-Grundmodell | Standardisierter Katalog von Qualitätsmerkmalen. Beispiel: FURPS+ oder ISO 9126. | |
| QM | Siehe: Qualitätsmanagement. | |
| Q-Modell | Siehe: Qualitätsmodell | |
| Qualität | Qualität ist die Menge der Merkmale eines Produkts, einer Dienstleistung oder einer Tätigkeit, welche die Erfüllung festgelegter Merkmale betrifft. Merkmale sind zum Beispiel: Funktionalität, Benutzbarkeit, Zuverlässigkeit, Performance oder die Wartbarkeit. Die für ein Projekt bzw. ein Produkt relevanten Merkmale sind in einem Qualitätsmodell festgehalten. | |
| Qualitätsmanagement | Konzeption und Durchführung von Massnahmen, die der Verbesserung von Arbeitsabläufen in Organisationen dienen (9000:2005). Teil des funktionalen Managements, mit dem Ziel, die Effizienz einer Arbeit oder von Geschäftsprozessen zu erhöhen. Dabei sind materielle und zeitliche Kontingente zu berücksichtigen sowie die Qualität von Produkt oder Dienstleistung zu erhalten oder weiterzuentwickeln. Hierbei von Belang sind etwa die Optimierung von Kommunikationsstrukturen, professionelle Lösungsstrategien, die Erhaltung oder Steigerung der Zufriedenheit von Kunden oder Klienten sowie der Motivation der Belegschaft, die Standardisierungen bestimmter Handlungs- und Arbeitsprozesse, Normen für Produkte oder Leistungen, Dokumentationen, Berufliche Weiterbildung, Ausstattung und Gestaltung von Arbeitsräumen. | |
| Qualitätsmodell | Ein Qualitätsmodell ist eine Menge von gewichteten Qualitätsmerkmale und -kenngrössen, die für das Projekt bzw. Produkt relevant sind. Es ermöglicht eine objektive Messung von Qualität, ist eine wichtige Basis sowohl für die Definition von Anforderungen als auch für den Test bzw. die Abnahme des Produkts. | |
| Rational Unified Process (RUP) | Kommerzielle Implementierung bzw. Weiterführung der Vorgehensmethode "Unified Process (UP)" der Firma Rational (heute zu IBM gehörend). Obwohl es sich bei RUP um ein kommerzielles Produkt handelt, so hat es eine grosse Verbreitung, weil das Modell einerseits kontinuierlich weiterentwickelt wird und anderseits diverse massgeschneiderte Werkzeuge (Bsp: Rose, Requisite Pro) existieren, welche den Prozess optimal unterstützen. | |
| Referenzhandbuch | Letzte und vom Benutzer formal noch einmal explizit abgenommene Version der Systemanforderungen, welche meistens erst dann vorliegt, wenn erste sichtbare und bedienbare Teile des Systems vorliegen. Das Referenzhandbuch bildet die Grundlage für den Test und die Wartung. Use-Case Diagramme müssen hier nicht mehr vorhanden sein. Geschäftsregeln müssen direkt da beschrieben sein, wo sie an der Oberfläche initialisiert werden. | |
| Regressionstest | Der Regressionstest ist eine Menge von Testfällen, welche bei jeder Auslieferung durchgeführt wird. Diese sind wo möglich automatisiert. | |
| Report | Sammelbegriff für Auswertungen jeglicher Art. Reports können Dokumente, Liste oder Statistiken sein. | |
| Reportdesign | Detailspezifikation sämtlicher vom System zu erzeugenden Dokumente in allen geforderten Landessprachen. | |
| Risikomanagement | Disziplin mit dem Ziel, die Risiken, welche den Projekterfolg bedrohen, systematisch zu erkennen und zu bearbeiten. Als Projekterfolg wird die Situation bezeichnet, in der die Erfolgsdimensionen Lösungsumfang, Termin, Kosten und Qualität im vereinbarten Rahmen liegen. Die Disziplin Risikomanagement hat folgende Aufgaben: Risiken erkennen, analysieren, bewerten, reduzieren bzw. eliminieren, Eventualplänen und/oder Reserven für das verbleibende Risiko bereitzustellen. | |
| RUP | Siehe: Rational Unified Process | |
| Sekundärer Use-Case | Use-Case, welcher eine Detailfunktionalität von mindestens einem anderen Use-Case beschreibt. | |
| Siehe auch: www.omg.org. | null | |
| Situationsanalyse | Dokumentation der gegenwärtigen Situation (Organisation, Anwendungen, Prozesse, Daten, etc) sowie der zukünftigen Entwicklungen im Untersuchungsbereich. Enthält auch Ergebnisse des Geschäfts¬modells. | |
| Spezialisierter Use-Case | Konkrete Ausprägung eines abstrakten Use-Case, also z.B. „Bestellung telefonisch erfassen“ für den abstrakten Use-Case „Bestellung erfassen“. | |
| Statistik | Auswertung, welche meistens aggregierte Zahlen in tabellarischer oder grafischer Art darstellt. | |
| Stub | Softwarekomponente („Rumpfkomponente“), welche eine oder mehrere funktionierende Schnittstellen zur Verfügung steht und im Rahmen einer frühen Softwareversion dazu verwendet werden, die Integration mit einer noch nicht vorhandenen Komponente zu simulieren. Der Stub liefert typischerweise wenige vordefinierte Rückgabewerte. Stubs können auch im Rahmen von Tests verwendet werden. | |
| Subsystem | Paket bzw. Sammlung von Komponenten (inkl. zugehörigen Datenbankobjekten) höherer Ordnung. Ein Subsystem besteht aus einem oder mehreren Assembly-Groups. | |
| Systemanalyse | Disziplin mit dem Ziel, die im Use-Case-Modell enthaltene Funktionalität als Aufgabe einzelnen Analyseklassen (Entity-, Controller- und Boundary-Klassen) zuzuordnen. Die Systemanalyse ist somit das Bindeglied zwischen der funktionalen Sicht des Use-Case Modells und dem Systemdesign. Das resultierende Analysemodell ist ein informatiktechnischer (aber technologieneutraler) Entwurf des Systems und besteht aus einem in Analysepakete gruppierten Analyseklassen-Diagramm und einer Use-Case Realisierungsanalyse. Die Systemanalyse ist eine Folgeaktivität der Anforderungsanalyse, üblicherweise am Ende der Konzeptphase. | |
| Systemanforderungen | Menge der Systemanforderungen als Ergebnis der Disziplin Anforderungsanalyse. | |
| Systemarchitektur | Komprimierter Masterbauplan ( „Koordinationsplan“) des Gesamtsystems, welcher das System aus unterschiedlichen Sichten (Use-Cases, Daten, Verhalten) beschreibt. Dieses Dokument beschreibt auch die wesentlichen Schlüsselmechanismen, die wichtigsten Risiken sowie Abgrenzungen zu vorhandenen Systemen. Alle Projektbeteiligten sollten in der Systemarchitektur sehen, wie und wo ihr Beitrag oder ihre Sicht (z.B. Installation bei einem Internetprovider oder Integration in eine bestehende Umgebung) hereinpasst. Die Systemarchitektur beleuchtet also alle technisch/konzeptionellen Aspekte, welche regulative Wirkung haben und auf die Kosten, die Dauer oder die Anforderungen einen Einfluss haben können bzw. welche zur Klärung potentieller Missverständnisse dienen können. Das Dokument Systemarchitektur wird im Rahmen der Systemanalyse erstellt und bis zum Abschluss des Systemdesigns fortlaufend nachgeführt. | |
| Systemdesign | Disziplin mit dem Ziel, die in der Analyse beschriebenen Anforderungen logisch und physisch zu strukturieren und zu planen. Das resultierende Designmodell besteht aus Design-Paketen (in AdeNet. Assembly-Groups), Designkassen (Business Objects sowie Table Modules), dem Persistenzmodell (i.d.R. Datenbankmodell) sowie Interfaces. | |
| Systemtest | Mit einem Systemtest wird ein mehr oder weniger grosser Teil eines Systems hinsichtlich extern beobachtbaren und messbaren Verhaltensmerkmalen überprüft. Im Rahmen von Systemtests werden typischerweise Funktions-, Zeitreihen oder Performancetests gemacht. Abhängig vom Durchführungsstandort und dem Projektfortschritt werden Systemtests unterschieden nach Alpha-, Beta- und Abnahmetest. | |
| Szenario | Spezifischer Ablauf innerhalb eines Use-Case. Beispiel: Der Use-Case „Geld beziehen“ führt zu einem anderen Ergebnis, wenn der Kontostand negativ ist. Szenarien eines Use-Case sind oft die Basis für die Bildung von Testfällen. | |
| TableModule | Ein AdeNet-Architektur-Element, welches die Geschäftslogik einer typisierten Tabelle und deren Mapping auf das Persistenzmodell implementiert. Die dazu notwendigen .NET-Klassen (TableModule, DataTable, TableGateway, …) werden mittels des CodeGenerators erzeugt. | |
| Test | Disziplin mit dem Ziel, Abweichungen einer vorliegenden Programmversion bezüglich der funktionalen und nichtfunktionalen Systemanforderungen festzustellen, um letztlich die Qualität des Endprodukts zu optimieren. Tests sind (in der Regel) also kein Vergleich eines Produkts mit momentanen Vorstellungen, sondern mit vorgängig abgenommen Dokumenten, primär mit dem Referenzhandbuch. Test ist gleichzeitig eine Disziplin von AdeNet/VM. | |
| Testdatenbank | Datenbank mit Testdaten, welche Grundlage für die Abwicklung der definierten Testfälle sind. | |
| Testfall | Ein Testfall definiert, welche Tests durchzuführen sind. Bei funktionalen Tests werden Testfälle ab dem Use-Case-Modell, den Zusatzanforderungen sowie dem eingesetzten Qualitätsmodell abgeleitet. Da viele Use-Cases meistens unterschiedliche Szenarien haben können (Bsp: Geld abheben mit positiven oder negativen Saldo), resultieren aus einem Use-Case oft mehrere Testfälle. Bevor ein Testfall im Rahmen eines Testlaufs operativ durchgeführt werden kann, muss er mit Hilfe einer Testprozedur konkretisiert (wie und mit welchen Daten) werden. | |
| Testkomponente | Eine Testkomponente ist ein Stück Software mit dem Zweck, eine oder mehrere Testsfälle zu automatisieren oder überhaupt zu ermöglichen, z.B. mit Hilfe sog. Stubs. Synonyme: Test-Script, Test-Driver. | |
| Testkonzept | Das Testkonzept definiert die (weitgehend applikationsneutralen) Rahmenbedingungen für die Abwicklung der Tests für ein oder mehrere Projekte (das heisst also z.B. für gleichartige Projekte mit einem Kunden oder einer organisierten Kundengruppe). Es definiert das zu verwendende Qualitätsmodell, die Testverfahren, den Testablauf (Unit/Integrationstest, Systemtest, Abnahmetest) sowie die Aufgabenteilung (wer überprüft welche Aspekte in welcher Phase). | |
| Testmodell | Das Testmodell umfasst eine Menge von Testfällen für ein klar definiertes System | |
| Testplan | Der Testplan definiert das konkrete Testvorgehen sowie die Testfälle, insbesondere auch jene für die nichtfunktionalen Aspekte. Die Testfälle sind gruppiert und priorisiert. Wiederholt durchzuführende Testfälle (Regressive Testfälle) sind markiert. Zusätzlich können gewisse Rahmenbedingungen aus dem Testkonzept präzisiert bzw. konkretisiert werden, so z.B. Regelungen betreffend Testinfrastruktur, Testdatenbank und v.a. die grundsätzliche Aufgabenteilung zwischen Lieferant und Benutzer. Die konkret zum Einsatz kommenden Personen sowie Zeitpläne müssen im Projektplan enthalten sein. | |
| Testprotokoll | Protokoll eines Testlaufs. | |
| Testprozedur | Eine Testprozedur definiert für einen Testfall (a) die notwendigen Vorbedingungen (oft konkrete Testdaten), Inputs sowie das erwartete Ergebnis und (b) in welchen Detailschritten der Test durchgeführt, allenfalls rückgängig gemacht und wiederholt werden kann. Testprozeduren können mit Hilfe von Testkomponenten zumindest „teilautomatisiert“ werden. | |
| Teststrategie | Operative Zielsetzungen für die Abwicklung der Tests mit dem Ziel, Prioritäten und Erwartungen der Entwickler mit jenen der Tester zu synchronisieren und um in Problemsituationen die „richtigen“ Entscheidungen zu treffen. Beispiel: In erster Priorität wird die Funktionalität für „Gutfälle“ der Use-Cases mit Priorität 1 getestet, in zweiter Priorität deren Benutzbarkeit (inkl. Help etc) und erst anschliessend die übrigen Testfälle. Oder: Es wird jeweils nur ein Aspekt getestet und nicht alles gleichzeitig. | |
| Testumgebung | Infrastruktur für die Durchführung von (System-)Tests. Eine solche muss sowohl bei den Entwicklern (Alphatests) als auch beim Kunden (Betatests) zur Verfügung stehen. Die Testdatenbank ist ein wichtiger Bestandteil der Testumgebung. | |
| Testverfahren | Ein Testverfahren definiert applikationsneutral die Ziele, den Ablauf, allfällige Tools sowie Erfolgskriterien, um ein oder mehrere Qualitätsmerkmale zu überprüfen. Beispiel: Das Qualitätsmerkmal „Zuverlässigkeit“ kann unter anderem mit einem Datenbanktest überprüft werden. Dabei wird z.B. direkt in der Datenbank überprüft, ob die korrekten Constraints und Primary-Keys definiert worden sind. Typische Testsverfahren sind: Datenbanktest, Funktionstest, Zeitreihentest, User-Interface-Test, Performancetest, Stresstest, Security-Test, Konfigurationstest, Installationstest, Code-Review. | |
| UML | Siehe: Unified Modelling Language | |
| Unified Modelling Language (UML) | Von der Object Management Group (OMG) standardisierte Notation und Semantik zur Visualisierung, Konstruktion und Dokumentation von Modellen für die objektorientierte Softwareentwicklung. | |
| Unified Process (UP) | Objektorientierte Software-Vorgehensmethode von Ivar Jacobson, Grady Booch und James Rumbaugh. Bevor sich diese 3 Autoren („amigos“) bei der Firma Rational zusammenfanden, um den Unified Process zu formulieren, hatte jeder dieser drei Autoren eigene objektorientierte Methoden formuliert, welche teilweise bereits eine grosse Verbreitung hatten und wesentliche Beiträge zu UML lieferten. UP wurde im Anschluss an die Publikation von UML als Erweiterung zu UML definiert. | |
| Unit-Test | Individueller Test der kleinsten Einheiten (Klassen und Komponenten). Der Unit-Test wird im Rahmen der Disziplin „Implementierung“ durch die Entwickler durchgeführt. Der Unit-Test ist typischerweise ein „White-Box-Text“. | |
| UP | Siehe: Unified Process | |
| Use-Case | Ein Use-Case beschreibt einen zusammenhängenden Arbeitsablauf aus der Sicht seiner Akteure. Er wird stets durch einen Akteur bzw. Ereignis initiiert und führt zu einem für die Akteure wahrnehmbaren Ergebnis. Ein Use-Case beschreibt das gewünschte externe Systemverhalten aus der Sicht und in der Sprache der Anwender (d.h. in natürlicher Sprache) und somit Anforderungen, die das System zu erfüllen hat. Beschrieben wird, was es leisten muss, aber nicht wie es dies leisten soll. Je nach Projektphase kann zwischen Business Use-Case oder System Use-Case unterschieden werden. Letztere werden im Rahmen von AdeNet/VM oft nur als Use Case bezeichnet. | |
| Use-Case Diagramm | Diagramm mit den Akteuren, Use-Cases und die Beziehungen zwischen diesen Elementen. | |
| Use-Case Modell | Strukturierte Beschreibung der funktionalen Anforderungen an das zukünftige System mit Hilfe von Use-Cases (Anwendungsfällen). Die hier resultierenden Use-Cases bilden die Grundlage für alle nachfolgenden Disziplinen. Besteht aus (1) Definition von Akteuren, (2) Use-Case Diagramme (bei grossen System allenfalls unterteilt in Themen oder nach Prozessen), (3) Use-Case Beschreibungen, (4) Use-Case Detailbeschreibungen, z.B. in Form von Aktivitätsdiagrammen. | |
| Use-Case Paket | Menge fachlich zusammengehörendere Use-Cases. Mögliche Gliederungskriterien sind z.B. Zugehörigkeit zu denselben Prozessgruppen oder Umgang mit ähnlichen Datenbeständen. Use-Case Pakete können auch verschachtelt werden. Use-Case Pakete werden später zu Analysepaketen. | |
| Use-Case Realisierungsanalyse | Plan im Rahmen der Systemanalyse, welcher aufzeigt, mit welchen Analyseklassen ein spezifischer Use-Case umgesetzt werden kann. Die Use Case Realisierungsanalyse stellt also unter anderem sicher, dass alle Analyseklassen identifiziert wurden, welche benötigt werden, um alle Use Cases realisieren zu können. | |
| White-Box-Test | Beim White-Box-Test werden die „Innereien“ eines Systems (Klassen und Komponenten) getestet. Die Typisierung Whitebox-/Blackbox-Test ist von mässiger praktischer Bedeutung. Siehe auch: White-Box-Test. | |
| Wirtschaftlichkeit | Gegenüberstellung von Kos¬ten sowie einer quantitativen und qualitativen Bewertung des Nutzens als Basis für die Entscheidungsfindung. Der Detaillierungsgrad ist vom Projekttyp und vom Zeitpunkt der Erstellung (Projektphase) abhängig. Die Wirtschaftlichkeit wird auf Grund neuer Ergebnisse immer wieder überprüft und bis zur zuverlässigen Schätzung präzisiert. | |
| Zusatzanforderungen | Definiert die nicht funktionalen Anforderungen, welche nicht einem Use-Case zugeordnet werden können. Sie definieren die Aufgabe des Systems und seine Kritikali¬tät und legen Qualitätsanforderungen, Anforderungen an Bedienung und Nutzung sowie an die Realisierung der internen Schnittstellen fest. | |