DE19963673A1

DE19963673A1 - Verfahren, Systeme und Computerprogrammprodukte zur Dokumentenverwaltung für Software-Entwicklungssysteme

Info

Publication number: DE19963673A1
Application number: DE19963673A
Authority: DE
Inventors: Anjou James F D; Iii Lynn Cleveland Percival
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1998-12-30
Filing date: 1999-12-29
Publication date: 2000-07-06
Also published as: US6343297B1

Abstract

Es werden Verfahren, Systeme und Computerprogrammprodukte bereitgestellt, die ein Dokumentenverwaltungssystem zur Verfügung stellen, das zur Verbindung mit einer Softwareverwaltungs- und Kontrollbibliothek geeignet ist. Dies geschieht durch Kapselung einer Vielzahl von Dokumentendatenbanken mit einer Maske, um so eine Dokumentendatenbank bereitzustellen, die mit der Softwareverwaltungs- und Kontrollbibliothek wechselwirkt. Insbesondere wird die Vielzahl von Dokumentendatenbanken unter Verwendung der Maske definiert. Vorzugsweise wird die Maske benutzt, um eine Anforderungsdokumenten-Datenbank, eine Design- und Entwicklungsdokumenten-Datenbank und eine Testdokumenten-Datenbank zu definieren.

Description

Diese Anwendung bezieht sich auf die gleichzeitig angemeldete und gemeinsam übertragene US Patentanmeldung Nr. 223 253 mit dem Titel SYSTEMS, METHODS AND COMPUTER PROGRAM PRODUCTS FOR END-TO-END SOFTWARE DEVELOPMENT PROCESS AUTOMATION.

Die vorliegende Erfindung bezieht sich im allgemeinen auf Computersysteme, Verfahren und Programmprodukte und insbesondere auf Computersysteme, Verfahren und Programmprodukte für die Softwareentwicklung.

Die objektorientierte Programmierung ist eine Pro grammiertechnik, die wiederverwendbare und leicht erwei terbare Programme bereitstellt. In einem traditionellen prozeduralen Programm liegt die Betonung auf Verfahren, die an besondere Datensätze ausgeführt werden. Im Gegensatz dazu liegt in einem objektorientierten Programm die Betonung auf den Daten. Wie der Fachmann, der sich mit der objektorientierten Programmierung befaßt, verstehen wird, bestehen objektorientierte Programme aus verschiedenen Arten von "Objekten".

Ein Objekt ist eine Datenstruktur, auch "Rahmen" ("frame") genannt, und ein Satz von Operationen oder Funktionen, auch "Verfahren" genannt, um auf die Datenstruktur zuzugreifen und diese zu bearbeiten. Objekte mit identischen Datenstrukturen und gemeinsamem Verhalten können in einer "Klasse" zusammengefaßt und gemeinsam als "Klasse" identifiziert werden. Objekte sind Instanzen, die von einer bestimmten Klasse erstellt werden. Jedes Objekt vererbt die Datenstruktur und die Verfahren von der Klasse, aus der es aufgerufen wurde. Ein hierarchisches Vererbungsverhältnis besteht zwischen Mehrfachklassen. Eine Klasse kann beispielsweise als "Eltern" ("Parent") von einer anderen Klasse betrachtet werden (das "Kind" ("Child") der Parent- Klasse). Die Child-Klasse wird von der Parent-Klasse "abgeleitet" und erbt alle Attribute und Verfahren der Parent-Klasse.

Immer mehr Entwickler benutzen bei der Entwicklung von objektorientierten Programmanwendungen ein Team. Die auf Komponenten basierende Entwicklung ist rasch das Ziel von vielen neuen Entwicklungsanstrengungen geworden. Bei dieser Art von Entwicklung benutzen die Teammitglieder, die an einer Anwendung arbeiten, in Bibliotheken gespeicherte Komponenten gemeinsam, um Anwendungen zu erstellen. Die Komponenten sind im wesentlichen gekapselte (encapsulated) Softwareobjekte oder Spezifikationen, mit denen solche Objekte erstellt werden können, die eine Art von bekanntem Service bereitstellen, der in Verbindung mit anderen Komponenten zur Erstellung von Anwendungen benutzt werden kann.

TeamConnection ist ein Softwareprodukt von International Business Machines, Inc., das eine Teamentwicklungsumgebung bereitstellt, die folgendes enthält:
Konfigurationsverwaltung, Versionsverwaltung, Änderungsverwaltung und Konstruktionsunterstützung, um mehrstufige, mehrsprachige Anwendungen durch Plattformen zu entwickeln. TeamConnection stellt einen einzelnen Aufbewahrungsort für Entwicklungsdaten bereit, die mehrfach aufrufbare Teile enthalten wie JavaBeans und ActiveX, Quellcodes wie C++, COBOL und Java, Webapplets, HTML-Doku mente, Endbenutzerdokumentation, Testfälle und modellierte Objekte.

TeamConnection erleichtert die parallele Entwicklung, in die mehrere Entwickler involviert sind. Es werden verschiedene Mechanismen bereitgestellt, damit Entwickler in einer entsprechenden Bibliothek gleichzeitig auf dieselben Objekte oder Komponenten zugreifen können, ohne daß dadurch die Arbeit der anderen negativ beeinflußt wird. TeamConnection vermittelt Änderungen, die von mehreren Entwicklern an Objekten vorgenommen wurden und kontrolliert die Versionen von Objekten, die in der Bibliothek gespeichert wurden.

TeamConnection verwaltet die Entwicklung durch die Benutzung von "Teilen", die einzigartige Namen tragen und von Objekten in verschiedenen Versionen, die in TeamConnection gespeichert sind. Wie dem Fachmann, der sich mit der objektorientierten Programmierung befaßt, bekannt ist, stellt TeamConnection ein offenes Modell bereit, um Klassen zur Erstellung von verwalteten Objekten zu benutzen. Eine Teileklasse kann durch Anwendungen in Unterklassen unterteilt werden, um Objekte in verschiedenen Versionen für anwendungsspezifische Zwecke zu erstellen. TeamConnection unterstützt die Entwicklung von Client/Server und verteilten Anwendungen in Multiple Virtual Storage (MVS), OS/2, Unix und Windows Betriebssystemen und kann autonom oder in einem LAN-basierten Client-/Servermodus konfiguriert werden.

Entwicklern, die die TeamConnection Umgebung benutzen, ist es erlaubt, Teile aus dem TeamConnection Aufbewahrungsort in einem Arbeitsbereich zu übertragen. Ein Arbeitsbereich wird von Entwicklern benutzt, um Vorhandene Teile zu ändern und neue Teile für eine Anwendung zu erstellen. Um einen Teil von TeamConnection abzurufen, benutzt ein Entwickler eine Anwendung, die den Teil überträgt und die Teileinhalte in einer Form überbringt, mit der der Benutzer arbeiten kann. Bei einem Teil, der beispielsweise den C++ Quellcode speichert, würde die Anwendung die Inhalte in eine Datei abrufen, so daß der Entwickler mit einem Texteditor den C++ Quellcode ändern könnte. Dann, wenn die Änderungen vollständig durchgeführt wurden, benutzt der Entwickler dieselbe Anwendung, um die neuen Inhalte zurück in TeamConnection zu verschieben. Der Entwickler fordert TeamConnection dann auf, den C++ Code in etwas Ausführbares umzuwandeln.

TeamConnection gibt die Inhalte des Teils an einen C++ Kompilierer, um das Ausführbare zu erstellen, das dann in TeamConnection gespeichert wird. Der Entwickler kann jetzt das Ausführbare abrufen und testen.

Obgleich TeamConnection die effiziente Verwaltung von Soft warebibliotheken erlaubt, stellt TeamConnection keine Verfolgungsdokumentation (tracking documentation) bereit, die dem gesamten Software-Entwicklungsprozeß zugrunde liegen können. Diese Dokumentation wird normalerweise in einem separaten System verfolgt (tracking) und verwaltet, das von der Softwarebibliothek und dem Konfigurationskontrolltool, wie TeamConnection, getrennt ist. Während viele Software- Entwicklungsteams die Notwendigkeit einer Softwarebibliothek und eines Konfigurationskontrolltools erkennen, da sie komplexere Anwendungen entwickeln, sind möglicherweise andere intellektuelle Werte, wie technische Dokumentationen, in einer großen Vielzahl von Medien gestreut, die normalerweise mit der aktuellen Implementierung des Softwareprodukts nicht richtig synchronisiert sind. Beispielsweise kennen Benutzer möglicherweise nicht den Entwicklungsstatus, da dieser während des Entwicklungsprozesses zu den Designspezifikationen oder anderen technischen Informationen gehört. Ohne diese Information kann es schwierig, wenn nicht gar unmöglich sein, den Status von besonderen Anforderungen oder Designs während des Entwicklungsprozesses zu verfolgen und die Softwareversionen mit den spezifischen Anforderungen in Verbindung zu bringen, die zu der entwickelnden Software geführt haben. Diese Unfähigkeit, den Status zu verfolgen, kann ein Nachteil sein, wenn das Entwicklungsteam erweitert werden muß, um mehr als die Softwareentwickler aufzunehmen, wie zum Beispiel Marketing, technische Autoren und Systemarchitekten. Ohne einen verfolgbaren Auditprozeß, beispielsweise ISO9000 oder andere Zertifizierungsnormen, kann es schwierig sein, die Zertifizierung zu erreichen.

In Anbetracht der vorstehenden Erörterung ist es ein Ziel der vorliegenden Erfindung, die verbesserte Verfolgung der Softwareentwicklung bereitzustellen.

Ein weiteres Ziel der vorliegenden Erfindung ist es, ein System bereitzustellen, das die Koordination über die tradi tionellen Softwareentwickler hinaus ermöglicht.

Es ist noch ein weiteres Ziel der vorliegenden Erfindung, ein einzelnes System bereitzustellen, das benutzt werden kann, um Aspekte des Entwicklungsprozesses zu unterscheiden, ohne das Entwicklungssystem neu zu entwerfen.

Es ist noch ein weiteres Ziel der vorliegenden Erfindung, ein Systementwicklungssystem bereitzustellen, das flexibel ist und es ermöglicht, Entwicklungsstrategien zu unter scheiden.

Diese und weitere Ziele der vorliegenden Erfindung werden von Verfahren, Systemen und Computerprogrammprodukten erreicht, die ein Dokumentenverwaltungssystem bereitstellen, das zur Integration in eine Softwareverwaltungs- und Softwarekontrollbibliothek geeignet ist, indem eine Vielzahl von Dokumentendatenbanken mit einer Maske (template) gekapselt werden, um eine Dokumentendatenbank bereitzustellen, die mit der Softwareverwaltungs- und Kontrollbibliothek (software management and control library) wechselwirkt. Insbesondere wird die Vielzahl von Dokumentendatenbanken unter Verwendung der Maske definiert. Vorzugsweise wird die Maske benutzt, um eine Anforderungsdokumenten-Datenbank (requirements document database), eine Design- und Entwicklungsdokumenten-Datenbank (design and development database) und eine Testdokumenten- Datenbank (test document database) zu definieren.

Durch Integration von Datenbankdefinitionen in einer einzelnen Maske sorgt die vorliegende Erfindung für Flexibilität bei der Unterscheidung von Software- Entwicklungsumgebungen, die dem Benutzer oder Systemverwalter noch eine einzelne Dokumentationsentität präsentieren, die durch die verschiedenen Datenbanken hindurch Gemeinsamkeiten hat. Somit können das Aussehen und die Handhabbarkeit einer einzelnen Datenbank erhalten werden, während die Flexibilität der multiplen Datenbanken mit zugeschnittenen Definitionen bereitgestellt werden kann.

In einem besonderen Ausführungsbeispiel der vorliegenden Er findung umfaßt das Definieren der Anforderungsdokumenten- Datenbank das Definieren eines Anforderungsdokuments zur Speicherung von Anforderungsinformationen in der Anforderungsdokumenten-Datenbank, und das Definieren eines Merkmalsdokuments zur Speicherung von Informationen, die zu Anforderungsdokumenten gehören, die in der Anforderungsdoku menten-Datenbank gespeichert sind, in der Anforde rungsdokumenten-Datenbank. In der vorliegenden Erfindung bezeichnet ein "Merkmal" eine Verbesserung oder eine ver besserungsorientierte Arbeitseinheit für die Softwareentwicklung. Die Definition der Design- und Entwicklungsdokumenten-Datenbank kann außerdem enthalten: das Definieren eines Designdokuments zur Speicherung von Designinformationen in der Design- und Entwicklungsdokumenten-Datenbank, das Definieren eines detaillierten Designdokuments (low level design document) zur Speicherung von zusätzlichen Designinformationen, die zu Designdokumenten in der Design- und Entwicklungsdatenbank gehören, das Definieren eines Änderungsdokuments zur Speicherung von Designänderungsinformationen, die wenigstens zu einem Designdokument und einem detaillierten Designdokument gehören, die in der Design- und Entwicklungsdatenbank gespeichert sind und das Definieren eines Merkmalsdokuments zur Speicherung von Merkmalsinformationen, die zu den Designdokumenten, den detaillierten Designdokumenten oder Änderungsdokumenten gehören, die in der Design- und Entwicklungsdatenbank gespeichert sind, in der Design- und Entwicklungsdatenbank. Das Definieren der Testdokumenten-Datenbank kann außerdem umfassen: das Definieren eines Testfalldokuments zur Speicherung von Testfallinformationen in der Testfalldokumenten-Datenbank, das Definieren eines Ausführungsaufzeichnungsdokuments zur Speicherung von Ausführungsinformationen, die zu einem in der Testdokumenten-Datenbank gespeicherten Testfalldokuments gehören, in der Testdokumenten-Datenbank, und das Definieren eines Defektdokuments zur Speicherung von Defektinformationen, die zu den in der Testdokumenten- Datenbank gespeicherten Aufzeichnungsprotokollen gehören, in der Testdokumenten-Datenbank. In der vorliegenden Erfindung bezeichnet ein "Defekt" eine problemorientierte Ar beitseinheit für die Softwareentwicklung.

In einem weiteren Ausführungsbeispiel der vorliegenden Erfindung enthält jedes der definierten Dokumente ein Verknüpfungsfeld, um Dokumente, die per Definition erstellt wurden, mit einem anderen Dokument zu verknüpfen. Eine Vielzahl von Benutzerberechtigungsebenen, die zu der Vielzahl der Dokumentendatenbanken gehören, kann unter Verwendung der Maske definiert werden. Die Vielzahl von Benutzerberechtigungsebenen definieren Zugangs- und Kontrollrechte, die zu den in der Vielzahl von Datenbanken gespeicherten Dokumenten gehören. Ebenso kann mit der Maske eine Vielzahl von zulässigen Statuszuständen für wenigstens eine Dokumentendefinition für die Anforderungsdokumenten- Datenbank, die Design- und Entwicklungsdokumenten-Datenbank oder die Testdatenbank definiert werden. Die Aktionen, die für Dokumente zulässig sind, die mittels der Dokumentendefinitionen erstellt wurden, können dann auch unter Verwendung der Maske definiert werden, um die zulässigen Aktionen zu kontrollieren, die auf einer Kombination des Statuszustands des erstellten Dokuments und einer Benutzerberechtigungsebene basieren, die zu einem Benutzer gehört, der auf das erstellte Dokument zugreift.

Die Maske kann auch ein Formular-Format definieren, das benutzt wird, um von jeder der Vielzahl von Datenbanken auf die Dokumente zuzugreifen. Das Formular-Format enthält vorzugsweise wenigstens ein vordefiniertes Subformular und wenigstens ein benutzerdefiniertes Subformular.

In einem bevorzugten Ausführungsbeispiel ist die Maske eine Lotus Notes Maske.

Dem Fachmann ist es verständlich, daß die vorliegende Erfindung verallgemeinert werden kann, um ein allgemeines Datenbankschema bereitzustellen, das an andere Datenbankanwendungen als an Softwaremanagement- und Dokumentendatenbanken angepaßt werden kann. Benutzer können daher Datenbanken definieren, die mit einer Maske gekapselt werden, um so die Verhältnisse der Datenbanken untereinander zu definieren. Wie der Fachmann sofort sieht, kann die vorliegende Erfindung in Form von Verfahren, Systeme und Computerprogrammprodukte vorliegen.

Fig. 1 zeigt eine schematische Darstellung einer Hardwareumgebung, in der die vorliegende Erfindung eingesetzt werden kann;

Fig. 2 zeigt ein Blockdiagramm von einem End-to-End Softwareentwicklungssystem gemäß der vorliegenden Erfindung;

Fig. 3 zeigt ein Blockdiagramm eines bevorzugten Ausführungsbeispiels vom System von Fig. 2;

Fig. 4 zeigt ein Blockdiagramm, das Abläufe eines exemplarischen Entwicklungszyklus darstellt, der die vorliegende Erfindung benutzt;

Fig. 5 zeigt ein Flußdiagramm, das die Abläufe von einem Ausführungsbeispiel der vorliegenden Erfindung zeigt;

Fig. 6 zeigt ein Flußdiagramm, das die Anforderungsdokumentenerstellung und die Softwarebibliothekswechselwirkung für ein Anforderungsdokument zeigt, das die vorliegende Erfindung benutzt;

Fig. 7 zeigt ein Flußdiagramm der Design- und Verbesserungsdokumentenerstellung und der Softwarebibliothekswechselwirkung für ein Design- und Verbesserungsdokument, das die vorliegende Erfindung benutzt;

Fig. 8 zeigt ein Flußdiagramm der Testdokumentenerstellung der Softwarebibliothekswechselwirkung für Testdokumente, die die vorliegende Erfindung benutzen; und

Fig. 9 zeigt ein Diagramm von einem allgemeinen Formular, das gemäß der Erfindung in einer Maske integriert werden kann.

Die vorliegende Erfindung wird nun nachstehend ausführlicher mit Bezug auf die beiliegenden Zeichnungen beschrieben, in denen die bevorzugten Ausführungsbeispiele der Erfindung abgebildet sind. Diese Erfindung kann jedoch in vielen verschiedenen Formen ausgeführt werden und sollte nicht so betrachtet werden, daß sie auf die hier ausgeführten Ausführungsbeispiele begrenzt ist. Statt dessen werden diese Ausführungsbeispiele bereitgestellt, so daß diese Beschreibung umfassend und vollständig sein wird und das Ziel der Erfindung für den Fachmann vollkommen transparent machen wird. Dieselben Elemente haben dieselben Nummern.

Wie es der Fachmann schätzen wird, kann die vorliegende Erfindung als ein Verfahren, ein Datenverarbeitungssystem oder Computerprogrammprodukt ausgeführt werden. Die vorliegende Erfindung kann dementsprechend die Form eines vollständig in Hardware ausgeführten Ausführungsbeispiels, eines vollständig in Software ausgeführten Ausführungs beispiels oder eines Ausführungsbeispiels annehmen, bei dem Software- und Hardwareaspekte miteinander kombiniert werden. Die vorliegende Erfindung kann außerdem die Form eines Computerprogrammprodukts in einem computerlesbaren Speichermedium annehmen, das computerlesbare Programmcodemittel hat, die in dem Medium enthalten sind. Jedes passende computerlesbare Medium, einschließlich Magnetplatten, CD-ROMs, optische Speicher- oder magnetische Speichereinheiten, kann dabei benutzt werden.

Die vorliegende Erfindung stellt eine End-to-End Software- Entwicklungsprozeßautomation durch Integrierung von techni scher Dokumentations- und Softwarebibliotheksverwaltung in einem einzelnen System bereit. Diese End-to-End Entwicklungskontrolle kann in einem bevorzugten Ausführungsbeispiel bereitgestellt werden, das Lotus® Notes® (IBM) in Verbindung mit VisualAge™ Team Connection™ benutzt, um die integrierte Dokumentenverwaltung und die Softwareentwicklungsbibliotheksverwaltung bereitzustellen. Fig. 1 zeigt eine Betriebsumgebung, in der der End-to-End Softwareentwicklungsprozeß gemäß der vorliegenden Erfindung benutzt werden kann.

Wie Fig. 1 zeigt, können Benutzer auf ein Netzwerk mit das gemeinsam benutzten Betriebsmitteln zugreifen, oder autonom arbeiten. Ein Benutzer kann in jedem Fall eine Betriebsumgebung ausführen, die geeignet ist, um den End-to- End Softwareentwicklungsautomationsprozeß gemäß der vorliegenden Erfindung zu nutzen, der in einem Computer 20 ausgeführt wird. Der Computer 20 kann Apple®, IBM® oder IBM- kompatible Personalcomputer oder andere Datenverarbeitungssysteme umfassen, die dem Fachmann bekannt sind, ist jedoch nicht auf diese begrenzt. Der Computer 20 enthält vorzugsweise eine Zentraleinheit 21, einen Bildschirm 22, eine Zeigegerät 23, eine Tastatur 24, eine Kommunikationseinheit 25 (beispielsweise ein Modem oder eine Netzwerkschnittstelle) und einen Anschluß 26 zum Anschluß an ein Netzwerk 27. Die Tastatur 24, die eine Vielzahl von Tasten enthält, kommuniziert mit der Zentraleinheit 21. Ein Zeigegerät 23, beispielsweise eine Maus, ist ebenfalls mit der Zentraleinheit 21 verbunden. Der Netzwerkanschluß 26 kann über traditionelle Telefonleitungen, eine ISDN-Leitung, eine T1-Leitung, eine T3-Leitung, über Fernsehkabel, über eine Netzwerkadapterkarte (NIC), beispielsweise einen Ethernet Adapter, einen Token Ring™ (IBM) Adapter o. ä. erfolgen.

Die Zentraleinheit 21 enthält einen oder mehrere Mikroprozessoren (ohne Abbildung) oder andere Rechenvorrichtungen und einen Speicher mit wahlfreiem Zugriff (ohne Abbildung) oder sein Funktionsäquivalent einschließlich RAM, FLASHRAM und VRAM - ist jedoch nicht darauf begrenzt - um darin Programme zu speichern, die von dem/den Mikroprozessor(en) oder anderen Rechenvorrichtungen verarbeitet werden. Ein Teil des Speichers mit wahlfreiem Zugriff und/oder des persistenten Datenspeichers, "Cache" genannt, wird oft während der Ausführung von Verarbeitungsumgebungen, beispielsweise objektorientierten Umgebungen im Computer 20, benutzt, um die verschiedenen Daten- und Programmbefehle zu speichern.

Der Computer 20 enthält vorzugsweise einen Intel® Pentium® Prozessor (oder ein Äquivalent) mit wenigstens zweiunddreißig Megabytes (32 MB) RAM und wenigstens fünf Megabytes (5 MB) persistenten Computerspeicher als Cachespeicher. Noch bevorzugter ist ein Intel® Pentium II® Prozessor (oder ein Äquivalent). Es sollte jedoch klar sein, daß verschiedene Prozessoren benutzt werden können, um die vorliegende Erfindung auszuführen, ohne daß diese auf diejenigen beschränkt sind, die hier aufgeführt sind. Wenn es sich bei dem Computer 20 um einen IBM® oder IBM-kompa tiblen Personalcomputer handelt, so benutzt dieser vorzugs weise entweder ein Windows® 3.1, Windows 95®, Windows 98®, Windows NT®, Unix® oder OS/2® Betriebssystem.

Es sollte außerdem klar sein, daß eine Einheit, die keine Rechenfähigkeit oder nur begrenzte Rechenfähigkeit hat, gemäß der vorliegenden Erfindung benutzt werden kann, um Inhalte über ein Netzwerk aufzurufen, wo die Ausführung der Programmbefehle von der Betriebsumgebung fern vom Arbeitsplatz des Benutzers erfolgt. Die vorliegende Erfindung kann somit auch in "Mainframe" Systemen verwendet werden, wo eine Vielzahl von Terminals ein Rechensystem gemeinsam benutzen. Diese Systeme sind dem Fachmann sehr wohl bekannt und werden deshalb hier nicht weiter beschrieben.

In einer Netzwerkumgebung kann die vorliegende Erfindung in Client-/Server- oder anderen derartigen Netzwerkumgebungen, einschließlich Intranet, Extranet und Internetumgebungen benutzt werden, die Transport Control Protocol/Internet Protocol (TCP/IP) Kommunikationen, Asynchronous Transfer Mode (ATM) oder andere Verbindungs- und Kommunikationsprotokolle verwenden, die die Kommunikation zwischen Computern, zum Beispiel zwischen einem Computer 20 und einem Computer 30, ermöglichen.

Der Computer 30 kann eine Konfiguration ähnlich der von Computer 20 haben und eine Zentraleinheit 31, einen Bildschirm 32, ein Zeigegerät 33, eine Tastatur 34, eine Kommunikationseinheit 35 und einen Netzwerkanschluß 36 zum Anschluß ans Netzwerk 27 enthalten. Der Computer 30 kann jedoch auf die gleiche Weise oder auf andere Weise als der Computer 20 konfiguriert werden. Die vorliegende Erfindung kann dementsprechend in einem homogenen oder heterogenen Netzwerk benutzt werden. Der Computer 30 kann beispielsweise unter Verwendung von anderen Prozessoren und mit anderen Recheneinrichtungen, einschließlich Mainframe- Computersystemen und Minicomputer, implementiert werden, ist jedoch nicht darauf begrenzt.

Fig. 2 zeigt eine Architektur gemäß der vorliegenden Erfin dung, wobei die technische Dokumentation mit einer Software bibliothek verknüpft ist, um Verfolgung und Status des Soft wareentwicklungsprozesses bereitzustellen, wie diese zu der technischen Dokumentation gehören, die zur Erstellung von Code, Teilen, Objekten, Treibern, Versionen oder anderen Softwareentwicklungsschritten, die in der Softwareentwicklungsbibliothek reflektiert wird, führt. Wie aus Fig. 2 ersichtlich ist, kann eine technische Dokumentendatenbank (technical documents database) 100 eine Vielzahl von Datenbanken umfassen, beispielsweise die Anforderungsdokumenten-Datenbank 102, die Designdokumenten- Datenbank 104 und die Testdokumenten-Datenbank 106. Die technische Dokumentendatenbank 100 organisiert und verknüpft die Anforderungsdokumente in der Anforderungsdokumenten- Datenbank 102, die Designdokumente in der Designdokumenten- Datenbank 104 und die Testdokumente in der Testdokumenten- Datenbank 106 mit der Softwarebibliotheksverwaltung- und Kontrollsoftware 200 über einen Änderungsmechanismus, beispielsweise ein Merkmals- und Defektverfolgungsmechanismus. Änderungen in der Software bibliothek 200 sind somit mit den technischen Dokumenten verbunden, die in der Datenbank 102, 104 und 106 gespeichert sind die und diese Änderungen erzeugen. Der Status der Änderungen wird außerdem, entsprechend ihrer Bewegung innerhalb des Entwicklungsprozesses in der Softwarebibliothek, der jeweiligen Datenbank von der technischen Dokumentationsdatenbank 100 zurückgemeldet, so daß der Status einer Änderung mit Bezug auf dasjenige technische Dokument oder die technischen Dokumente verfolgt werden kann, die die Änderung erzeugten.

Fig. 3 zeigt ein bevorzugtes Ausführungsbeispiel von Fig. 2, wobei eine einzelne Lotus Notes Maske 112 benutzt wird, um die multiplen Datenbanken in eine einzelne Datenbank 100 zu kapseln. Die Maske sorgt auch für die Verknüpfung und Verfolgung zu einer TeamConnection Softwarebibliothek 200, die die TeamConnection Bibliotheksverwaltungsmerkmale 202 sowie die TeamConnection Merkmals- und Defektänderungsverwaltungsfunktion 204 umfaßt.

Die technische Dokumentenverwaltung durch den Notes Support ist in einer einzelnen Notes Datenbankmaske 112 gekapselt, die viele Funktionen im Anwendungsentwicklungsprozeß übernehmen kann. Eine Notes Maske ist ein Gerüst, das Designelemente aber keine Dokumente enthält. Eine Notes Maske kann zur Erstellung einer Datenbank benutzt werden, wobei die Datenbank die Designelemente der Maske empfängt, die dann mittels der bekannten Lotus Notes Programmiertechniken individuell angepaßt werden können. Somit kann ein Benutzer durch einen einfachen Datenbank- Setup-Prozeß entscheiden, wie die Notes Datenbank in einer bestimmten Organisation angewendet werden kann und eine Notes Basismaske individuell anpassen. Die Notes Basismaske enthält vorzugsweise integrierte Layouts, um die Anforderungs-, Designdokumentations- und Testfalldefinitionen zu handhaben. Durch die individuelle Anpassung können Layout und Organisation von Dokumenten so ausgelegt werden, daß sie zu einer bestimmten Organisation passen. Diese Änderungen können jedoch von Organisation zu Organisation unterschiedlich sein und werden für den Fachmann aus der vorliegenden Beschreibung ersichtlich. Deshalb ist hier nur die Notes Basismaske beschrieben.

Wie oben kurz beschrieben wurde, erfolgt die Verbindung mit TeamConnection 200 über seine Merkmals- und Defektobjekte 204. Neue Defekte und Merkmale können von der Notes Datenbank 100 geöffnet werden, so daß sie logischerweise mit Notes Dokumenten verbunden werden können. Die Notes Datenbank 100 wird mit der TeamConnection Datenbank 200 über einen Abstimmungsprozeß (reconciliation process) aktualisiert, der entweder automatisch oder auf Anforderung ausgeführt werden kann. Mit dem TeamConnection Internet Browser Support können Notes Benutzer außerdem auf alle TeamConnection Informationen von innerhalb Notes zugreifen. Die Notes Datenbanken 100 können zum Browsen in einem Intranet veröffentlicht werden, das Merkmale benutzt, die von Lotus Domino, der HTTP Serverkomponente von Lotus Notes, bereitgestellt werden. Somit können auch Benutzer ohne Zugriff auf Notes Informationen in der Dokumentendatenbank 100 bereitstellen. Der Zugriff kann außerdem durch die Merkmale von Lotus Domino streng kontrolliert werden.

Bei Verwendung eines etablierten Dokumentendatenbank-Verwal tungssystems wie Notes können durch integrierte Notes Funktionen der Fortschritt der Entwicklungs- und Testanstrengungen angezeigt und überwacht werden. Wie oben kurz beschrieben wurde, kann beispielsweise eine Liste mit Merkmalen in TeamConnection, welche die Implementierung eines spezifischen Designs darstellen, unterhalten werden.

Diese Merkmale können mit technischen Dokumenten in der technischen Dokumentendatenbank 100 verknüpft werden, um den Implementierungsprozeß in bezug auf die Designdokumente zu überwachen. Ebenso können Defekte, die in TeamConnection geöffnet wurden, mit den Testfällen in der Testdatenbank 106 verknüpft werden, um den Testfortschritt zu überwachen. Außerdem können die zugehörigen Dokumente in der technischen Dokumentendatenbank 100 verknüpft werden, und eine Liste mit Dokumentenänderungen kann unterhalten werden.

Mit einem Überprüfungszyklusmerkmal (review cycle feature) von Notes können Dokumente unter Kollegen und Endbenutzern umlaufen, die diese mit Kommentaren versehen und überprüfen können. Die Prüfer werden per Email aufgefordert, sich zu beteiligen. Eine Kopie des Dokuments mit ihren Kommentaren kann gespeichert und in der technischen Datenbank 100 referenziert werden.

Die Nutzung von Notes bietet außerdem auch Sicherheits- und Berechtigungsprivilegien, die auf einer Kundenbasis definiert werden können oder die Standards der Basismaske 112 verwenden. So können beispielsweise nur Projektleiter befugt sein, Dokumente zu genehmigen und nur genehmigte Dokumente können in TeamConnection offene Merkmale haben. Diese Berechtigungsstufen können benutzt werden, um sicherzustellen, daß die Implementierung nicht weitergeführt wird, bis ein Design zur Implementierung fertig ist. Da der Fachmann, der mit der Arbeitsablaufverwaltung vertraut ist, diese Berechtigungsstufen kennt, werden diese hier nicht weiter beschrieben.

Wie oben erwähnt und wie nachstehend ausführlicher beschrieben werden wird, enthält eine einzelne Datenbankmaske 112 alle Informationen, um eine Lotus Notes Datenbank 100, die für Anforderungen, zur Entwicklung oder Prüfung benutzt werden soll, zu definieren. Mit der Maske können eine oder alle von einer Anforderungsdatenbank 102, einer Design- und Entwicklungsdatenbank 104 und einer Testdatenbank 106 erstellt werden. Die Datenbankmaske 112 kann auch benutzt werden, um kundenspezifische Datenbanken wie die beliebige (generic) Datenbank 108 und die be nutzerdefinierte Datenbank 116 zu erstellen, die in der technischen Dokumentationsdatenbank 100 enthalten sind. Diese Datenbanken sind optional und können von Implementierung zu Implementierung variieren. Die Einzelheiten dieser Datenbanken sind von dem Entwicklungsprozeß eines bestimmten Benutzers abhängig. Somit werden diese Datenbanken hier nicht weiter be schrieben.

Mit der Maske 112 kann eine Notes Anforderungsdatenbank 102 erstellt werden, mit der die Benutzer Anwendungsanforderungen definieren können. Die technischen Auswertungen der Anforderung können ebenfalls eingegeben werden. Wie nachstehend ausführlicher erörtert werden wird, können den Anforderungen ein Vorrang gegeben werden, und Anforderungen können verschiedene Zustände (states) zugeordnet sein (wie z. B. angenommen, abgelehnt, aufgeschoben). Für Anforderungen, die zur Implementierung ausgewählt werden, kann ein TeamConnection Merkmal definiert werden, um die Implementierung aufzurufen und eine Verknüpfung zurück zur Originalanforderung zu unterhalten, auf die sich derjenige, der die Implementierung ausgeführt hat, beziehen kann.

Die Maske 112 kann auch benutzt werden, um eine Notes Design- und Entwicklungsdatenbank 104 zu erstellen, die eine Vielzahl von technischen Dokumenten wie Designspezifikationen und Designänderungen unterstützt. Diese Design- und Entwicklungsdokumente können in einer Hierarchie angeordnet werden, die Dokumente der höheren und unteren Ebenen (high level and low level documents) zuläßt. Die TeamConnection Merkmale und Defekte können geöffnet und diesen Dokumenten zugeordnet werden, um die Implementierung zu verfolgen.

Die Maske 112 kann auch benutzt werden, um eine Notes Testdatenbank 106 zu erstellen, die die Definition von Testfällen und die Aufzeichnung von spezifischen Ausführungen dieser Testfälle ermöglicht. Die TeamConnection Defekte können bei fehlgeschlagenen Ausführungsversuchen geöffnet werden, und eine Verknüpfung mit dem Testfall kann unterhalten werden. Der Testfortschritt kann über eine Vielzahl von Ansichten, die zur Verfügung stehen, überwacht werden.

Wie ausführlicher in Fig. 4 dargestellt ist, kann eine oder alle Notes Datenbanken 102, 104, 106, 108 und 110 in der technischen Dokumentationsdatenbank 100 benutzt werden und mit TeamConnection 200 synchronisiert werden.

Fig. 4 zeigt einen Teil eines exemplarischen Entwicklungsprozesses, der die vorliegende Erfindung benutzt. Fig. 4 zeigt außerdem, wie die in Notes integrierten Fähigkeiten zur Verknüpfung von Dokumenten über verschiedene Datenbanken hinweg benutzt werden können, um ein Anforderungsdokument in einer Datenbank mit dem Designdokument in einer anderen Datenbank zu verknüpfen. Die Testfälle können mit dem Designdokument verknüpft werden, welches sie beabsichtigen zu testen. Die Designdokumentation kann auch mit der Implementierung in TeamConnection verknüpft werden. Das Testen kann auch mit Defekten verknüpft werden, die in TeamConnection aufgezeichnet sind. Obgleich die vorliegende Erfindung mit Bezug auf die be stimmten exemplarischen Dokumententypen beschrieben wird, können weiterhin - da Lotus Notes eine Vielzahl von Dokumenten unterstützen kann - andere Informationen wie Zeichnungen (plans), Aufstellungen (schedules) und Prozesse ebenso in die Notes Datenbanken aufgenommen werden.

Wie aus Fig. 4 ersichtlich ist, kann ein Anforderungsdokument 300 von einem Benutzer erstellt werden. Wenn das Anforderungsdokument dazu führt, daß ein Merkmal in der Software zu entwickeln ist, dann wird ein Öffnen (open) 302 von einem TeamConnection Merkmalobjekt 304 durchgeführt, um ein Merkmal in TeamConnection zu erstellen, das zu dem Anforderungsdokument 300 gehört. Der Status 306 des Merkmals 304 kann von TeamConnection erhalten und mit dem Anforderungsdokument 300, das das Merkmalsobjekt 304 erstellte, verknüpft werden.

Das Anforderungsdokument 300 kann auch zur Erstellung von Design- und Entwicklungsdokumenten führen, wie beispiels weise des Designdokuments 308. Das Verhältnis zwischen Anforderungsdokument 300 und Designdokument 308 wird von der Verknüpfung 310 in Fig. 4 reflektiert. Wenn sich das Designdokument 308 auf das Merkmalsobjekt 304 bezieht, das als Ergebnis des Anforderungsdokuments 300 erstellt wurde, dann kann des weiteren auch eine Verknüpfung oder Verbindung 312 zwischen Designdokument 308 und Merkmalsobjekt 304 erstellt werden, und der Status des Merkmals 304 kann ebenfalls in bezug auf das Designdokument 308 verfolgt werden.

Wenn für das Designdokument 308 außerdem zusätzliche Merkmale oder Änderungen in der Software entwickelt werden müssen, dann kann das Designdokument 308 auch ein Merkmalsobjekt in TeamConnection durch ein Öffnen 314 des Merkmalsobjekts 316 erstellen, welches das Merkmalsobjekt 316 öffnet und das Merkmalsobjekt 316 mit dem Designdokument 308 verknüpft, welches das Merkmalsobjekt erstellt hat. Der Status 318 des Merkmalsobjekts 316 kann dann an das Designdokument 308 zurückgeschickt werden, um den Status des Merkmalsobjekts 316 zu verfolgen, so wie sich dieser auf das Designdokument 308 bezieht.

Mit einem eingerichteten Design können Testfälle als Testfalldokumente geschrieben und gespeichert werden. Wenn das Designdokument 308 Testfälle erzeugt hat, können die Testfalldokumente 320 erstellt und über die Verknüpfung 322 mit dem Designdokument 308 verbunden werden. Dadurch kann das Verhältnis zwischen einem Testfall und dem Design, das den Testfall erzeugt hat, unterhalten werden. Wird ein Defekt erkannt, dann kann ein Defektobjekt 326 von dem Testfalldokument 320 geöffnet 324 werden. Das Defektobjekt 326 kann mit dem Testfalldokument 320, von dem es geöffnet wurde, verknüpft werden, so daß der Status 328 zurückgesendet und mit dem Testfalldokument 320 verbunden werden kann.

Der Prozeß, technische Dokumente zu erstellen, technische Dokumente mit dem Merkmals- oder Defektobjekt in TeamConnection zu verknüpfen und technische Dokumente unter einander zu verknüpfen, kann für jedes technische Dokument wiederholt werden, das zum Softwareentwicklungsprozeß gehört. Somit kann die technische Dokumentation untereinander und mit der Softwarebibliothek verbunden werden, die die Notes Datenbank 100, die von der Maske 112 verwaltet wird, benutzt und kann über die Merkmals- und Defektobjekte 204 von TeamConnection integriert werden.

Dieser allgemeine Entwicklungsprozeß ist in Fig. 5 darge stellt. Obgleich die Blöcke in Fig. 5 als nacheinander ablaufende Vorgänge dargestellt sind, ist es für den Fachmann klar, daß die Operationen von Fig. 5 parallel und in verschiedenen Kombinationen von parallelen und seriellen Modi ausgeführt werden können. Nachdem ein Merkmalsobjekt erstellt wurde, kann beispielsweise der Status des Merkmalsobjekts geprüft oder regelmäßig an das erstellende Dokument zurückgemeldet werden. Ebenso kann die multiple Erstellung von Dokumenten gleichzeitig erfolgen. Somit können beispielsweise Designdokumente gleichzeitig mit Anforderungsdokumenten, anderen Designdokumenten oder Testfalldokumenten erstellt werden. Daher sollte die vorliegende Erfindung nicht so betrachtet werden, als wäre sie auf den bestimmten Ablauf in Fig. 5 begrenzt.

Wie aus Fig. 5 ersichtlich ist, gibt ein Benutzer oder Ver walter zuerst wie oben beschrieben die Datenbanken für die technische Dokumentation an, die die Maske 112 (Block 400) benutzt. Zu diesem Zeitpunkt wird vorzugsweise auch das TeamConnection Bibliothekssystem 200 eingerichtet. Ein Benutzer kann dann ein Anforderungsdokument (Block 402) erstellen. Das Anforderungsdokument kann dann ein Merkmal oder Merkmale erstellen (Block 404), die in TeamConnection Merkmalsobjekten resultieren würden, die in TeamConnection (Block 406) geöffnet und mit dem Anforderungsdokument, das das Merkmal erstellt hat, verknüpft werden.

Der Benutzer kann auch ein Designdokument (Block 408) erstellen, das auch ein Merkmal oder Merkmale (Block 410) erstellen kann. Das Designdokument kann auch mit zugehörigen Anforderungsdokumenten (Block 412) verknüpft werden. Das Designdokument kann außerdem mit vorhandenen Merkmalsobjekten verknüpft werden, die von anderen Designdokumenten oder Anforderungsdokumenten (Block 414) geöffnet werden. Die Merkmale, die von dem Designdokument erstellt werden, können auch mit TeamConnection verknüpft werden, indem die Merkmalsobjekte geöffnet werden, die den Merkmalen entsprechen (Block 416).

Der Benutzer kann auch Testdokumente erstellen, die Testfälle o. ä. enthalten können (Block 418). Wenn die Testfälle einen Defekt erkennen, dann kann ein Defektobjekt mit TeamConnection (Block 420) geöffnet werden, um den Defekt zu verfolgen und ihn wieder mit dem Testfalldokument zu verbinden, das den Defekt erkannt hat.

Wie bei jedem der verschiedenen Dokumententypen und Merkmals- oder Defektobjekten kann der Status entweder von Dokumenten innerhalb der technischen Dokumentendatenbank 100 oder von der TeamConnection Bibliotheksverwaltung 200 erhalten werden und mit den Dokumenten verbunden werden, die mit dem Status verknüpft sind (Block 422).

Mit der Maske 112 können Benutzertypen mit unterschiedlichen Berechtigungsebenen definiert werden. Diese Berechtigungsebenen können die "Verwalterberechtigung" ("administrator authority") enthalten, die beim Setup der Datenbank und für weitere administrative Funktionen benutzt werden kann, wie beispielsweise das Anpassen der Datenbank an TeamConnection. Die Verwalterberechtigungsebene sollte eine Zugangsberechtigung zu Notes haben, welche die Berechtigung zum Löschen von Dokumenten umfaßt. Eine zweite "Projektleiter" Berechtigungsebene wird ebenfalls bereitge stellt. Mit der Projektleiterberechtigung kann der Benutzer Dokumente auf einen eingeschränkten Status setzen, beispielsweise auf den "genehmigt" - Status. Die Projektleiterberechtigung sollte Notes Berechtigungen mit "Editor" und "Autor" Funktionen enthalten. Die "Autor" Berechtigungsebene erlaubt es einem Benutzer, Dokumente zu erstellen und kann notwendig sein, damit das Dokumentennumerierungssystem von Notes korrekt funktioniert. Bei der Autor-Berechtigungsebene ist die "Autorfunktion" vorzugsweise zusätzlich zur Notes Autorzugriffsbe rechtigungsebene eingestellt. Es können auch andere Berechtigungsebenen definiert werden. Die Maske 112 enthält jedoch vorzugsweise zumindest diese drei Berechtigungsebenen.

Die Dokumente, die von der Maske 112 geliefert werden, enthalten vorzugsweise allgemeine Eigenschaften und sorgen so für ein konsistentes Aussehen und Handhabbarkeit von Dokumenten, wobei es keine Rolle spielt, ob es sich um Anforderungsdokumente, Designdokumente oder Testfalldokumente handelt. Insbesondere enthält der Dokumentensatz vorzugsweise zwei Hauptdokumente und sechs verschiedene Antwortdokumenttypen, obwohl auch andere Kombinationen benutzt werden können.

Jede der Datenbanken kann diese Dokumententypen für ihre jeweilige Verwendung organisieren. Ein "Basisdokument" sowie ein "Antwortdokument" und ein "Antwort auf Antwort"- ("response to response") Dokument kann auch für den allgemeinen Gebrauch aller Datenbanken bereitgestellt werden. Dokumententypen können aktiviert und deaktiviert werden, und die Dokumentenverhältnisse können für die unterschiedlichen Dokumententypen definiert werden. Es können ebenfalls benutzerdefinierte Datenpunkte (data points) bereitgestellt werden.

Die Dokumente enthalten vorzugsweise einen gemeinsamen "oberen" Teil, der den Namen des Autors, die Dokumentenkategorisierung, einen expliziten Satz mit Dokumentenstatus (document states) und eine Dokumentenkon trollnummer enthält. Für jede Datenbank kann ein "Mittelteil" bereitgestellt werden. Es kann auch ein gemeinsamer "unterer" Dokumententeil bereitgestellt werden, der die Dokumentenge schichte, Verknüpfungen mit untergeordneten (subordinate) Dokumenten und Verknüpfungen mit TeamConnection Merkmalen und/oder Defekten enthält. Des weiteren kann das Dokument die Aufschrift öffentlich oder privat tragen. Ein privates Dokument ist nur für den Autor des Dokuments zugänglich.

Die verschiedenen, von der Maske 112 bereitgestellten Doku mente, genauer gesagt ihr Dialog mit dem TeamConnection Bibliotheksmanager 200, werden nun ausführlicher beschrieben. Fig. 6 zeigt ein Flußdiagramm eines Anforderungsdokuments 500 und zeigt, wie ein Anforderungsdokument ein Merkmalsdokument 502, das ein Merkmalsobjekt in TeamConnection 506 erstellen oder öffnen kann, erstellt und mit diesem verknüpft werden kann. Das An forderungsdokument kann Status und Berechtigungen haben, wie diese in Tabelle 1 beschrieben sind.

Tabelle 1

Anforderungsdokumentenstatus

Die unterschiedlichen Status eines Anforderungsdokuments, das von der Maske 112 bereitgestellt wird, können in der Notes Umgebung weiter an kundenspezifische Belange angepaßt werden.

Fig. 7 zeigt ein Flußdiagramm eines Design- und Entwicklungsdokuments 600 und eines Verbesserungsdokuments 612 und zeigt, wie unterschiedliche Design- und Entwicklungsdokumente Verbesserungsdokumente erstellen und mit Merkmals- oder Defektdokumenten verknüpft werden können, was in einem Öffnen eines Merkmals- oder Defektobjekts in TeamConnection 506 resultieren kann. Wie Fig. 7 zeigt, kann ein Designdokument 600 ein untergeordnetes Designdokument (lower level design document) 602 erstellen, das seinerseits ein Designänderungsdokument 604 erstellen kann. Das Designänderungsdokument 604 kann ein Merkmals- oder Defektdokument 606 erstellen, welches das Merkmals- oder Defektobjekt mit TeamConnection 506 öffnen würde. Alternativ dazu kann ein Designdokument 600 direkt ein Designände rungsdokument 606 erstellen, das ein Merkmals- oder Defektdokument 608 erstellen würde, welches das Merkmals- oder Defektobjekt mit TeamConnection 506 öffnen würde. Schließlich kann ein Designdokument 600 direkt ein Merkmals- oder Defektdokument 610 erstellen, das ein Merkmals- oder Defektobjekt mit TeamConnection 506 erstellen würde. Somit kann die Designdokumentenhierarchie auf die besonderen Umstände im Entwicklungsprozeß zugeschnitten werden, um die Entwicklung von der Erstellung von Merkmals- oder Defektobjekten in TeamConnection 506 zu reflektieren.

Fig. 7 zeigt auch eine vereinfachte Verbesserungsdokumentenhierarchie, die entweder anstelle der Designdokumentenhierarchie oder zusätzlich zu dieser benutzt werden kann. Das Verbesserungsdokument 612 kann ein Designänderungsdokument oder Designänderungsdokumente 614 erstellen, das bzw. die ein Merkmals- oder Defektdokument 616 erstellt/erstellen, das bzw. die ein Merkmals- oder Defektobjekt in TeamConnection 506 öffnet/öffnen. Alternativ kann das Verbesserungsdokument 612 direkt das Merkmals- oder Defektdokument 616 erstellen, das das Merkmals- oder Defektobjekt in TeamConnection 506 öffnet.

Wie bei dem Anforderungsdokument können Designdokumente, einschließlich des Verbesserungsdokuments, die Status und Berechtigungen haben, die ihnen zugeordnet sind. Diese Status und Berechtigungen, die von Maske 112 bereitgestellt werden, sind nachstehend in Tabelle 2 beschrieben.

Tabelle 2

Designdokumentenstatus

Die unterschiedlichen Status eines Designdokuments, die von der Maske 112 bereitgestellt werden, können innerhalb der Notes Umgebung weiter an kundenspezifische Belange angepaßt werden.

Fig. 8 zeigt ein Flußdiagramm von einem Testdokument 700 und zeigt, wie ein Testdokument eine Ausführungsaufzeichnung oder Ausführungsaufzeichnungen 702 erstellen und mit dieser/diesen verknüpft werden kann, die ein Defektdokument 704 erstellen kann/können und ein Defektobjekt mit TeamConnection 506 öffnen kann/können. Das Testdokument und die Ausführungsaufzeichnungen können Status und Berechtigungen haben, wie diese nachstehend in Tabelle 3 und 4 beschrieben sind.

Tabelle 3 Testfallstatus

Testfallstatus
Erstellt von
Nicht definiert	Autor
In Erstellung	Autor
In Prüfung	Autor
Überprüfung beendet	Autor
Genehmigt	Projektleiter
Fertig	Autor
Vollständig	Autor
Veraltet	Autor

Tabelle 4

Ausführungsaufzeichnungsstatus

Der Fachmann, der mit der Technik der Arbeitsablaufverwaltung vertraut ist, weiß, daß der Testfallstatus benutzt werden kann, um die Erstellung von Ausführungsaufzeichnungen 702 zu kontrollieren, so daß eine Ausführungsaufzeichnung beispielsweise nicht erstellt werden kann, bis ein Testfall in einem besonderen Status ist, zum Beispiel in einem "Überprüfung beendet"- oder "Genehmigt"- Status. Außerdem können, wie bei den vorherigen Dokumenten, die verschiedenen Status eines Testdokuments, einschließlich einer Ausführungsaufzeichnung, die von der Maske 112 bereitgestellt werden, in der Notes Umgebung weiter an kundenspezifische Belange angepaßt werden.

Zusätzlich zu den Dokumentendefinitionen, die von der Maske 112 bereitgestellt werden, kann die Maske 112 auch spezifische TeamConnection Daten liefern, wie Familien- und Portadreßinformationen, Komponentennamen, die während Merkmals- und Defektöffnungen benutzt wurden, benutzerkonfigurierbare Felder für Merkmals- und Defektöffnungen und Defekt- und Merkmalsattribute wie Name, Kurzbeschreibung, Status, Besitzer, Schweregrad (severity) und sonstige, vom Benutzer angegebene Attribute.

Abstimmungs-Operationen werden auch bereitgestellt, damit die Notes Datenbanken mit TeamConnection synchronisiert bleiben. Diese Abstimmungen können manuell oder automatisch ausgeführt werden. Die Abstimmungen frischen jeden Defekt und jedes Merkmal mit den neuesten Daten in TeamConnection auf, und erstellen ein Protokoll mit Einzelheiten und Ausnahmen bei der Abstimmung erstellt.

Schließlich kann die Maske 112 Formulare zur Verwendung in den Datenbanken bereitstellen. Ein solches beliebiges (generic) Formular 800 ist in Fig. 9 dargestellt. Wie Fig. 9 zeigt, kann das Formular 800 einen Standard- Unterformularbereich 802 und benutzerdefinierte Unterformularbereiche 804, 806 und 808 enthalten. Unter Verwendung der Notes-Anpassung können diese Unterformulare an die kundenspezifische Belange angepaßt werden. Die Unterformulare können neu angeordnet werden, die Inhalte können in andere Unterformulare kopiert werden, oder die Inhalte können geändert werden, um Teile des Standard- Unterformulars in benutzerdefinierte Unterformulare aufzunehmen. Diese Änderungstechniken sind dem Fachmann, der mit der Arbeitsablaufverwaltung vertraut ist, bekannt und werden hier nicht weiter beschrieben.

Es sollte klar sein, daß jeder Block des Flußdiagramms und der Flußdiagrammabbildungen und Kombinationen von Blöcken im Flußdiagramm und in Flußdiagrammabbildungen mit Computerprogrammbefehlen implementiert werden können. Diese Programmbefehle können an einen Prozessor geliefert werden, um eine Maschine zu erstellen, so daß die Befehle, die im Prozessor ausgeführt werden, Mittel zum Implementieren der im Flußdiagramm oder im Flußdiagrammblock oder in den Flußdiagrammblöcken angegebenen Funktionen erzeugen. Die Computerprogrammbefehle können von einem Prozessor ausgeführt werden, um zu veranlassen, daß eine Reihe von Operationsschritten von dem Prozessor ausgeführt werden, um einen computerimplementierten Prozeß zu erstellen, so daß die Befehle, die im Prozessor ausgeführt werden, Schritte bereitstellen, um die Funktionen, die im Flußdiagramm oder im Flußdiagrammblock oder in den Flußdiagrammblöcken angegeben sind, zu implementieren.

Demgemäß unterstützen die Blöcke des Flußdiagramms oder der Flußdiagrammabbildungen Kombinationen von Mitteln zur Durch führung der angegebenen Funktionen, Kombinationen von Schritten zur Durchführung der angegebenen Funktionen und Programmbefehlsmittel zur Durchführung der angegebenen Funktionen. Jeder Block des Flußdiagramms oder Flußdiagrammabbildungen, und Kombinationen von Blöcken in einem Flußdiagramm oder in den Flußdiagrammabbildungen, kann durch spezielle hardwarebasierende Systeme (special prpose hardware-based systems) implementiert werden, die die angegebenen Funktionen oder Schritte oder Kombinationen von speziellen Hardware- und Computerbefehlen ausführen.

Das Vorstehende dient dazu, die vorliegende Erfindung zu illustrieren und ist nicht als Beschränkung auf die Ausführungen anzusehen. Obwohl einige exemplarische Ausführungsbeispiele von dieser Erfindung beschrieben wurden, wird der Fachmann sofort sehen, daß einige Änderungen bei den exemplarischen Ausführungsbeispielen möglich sind, ohne materiell von den neuen Lehren und Vorteilen dieser Erfindung abzuweichen. Dementsprechend sind alle Änderungen in der durch die Ansprüche definierten Schutzbereich aufzunehmen. In den Ansprüchen sind die "Means-plus-Function" Klauseln dazu gedacht, die hier beschriebenen Strukturen abzudecken, da sie die angegebene Funktion und nicht nur strukturelle Äquivalente sondern auch äquivalente Strukturen ausführen. Es sollte daher klar sein, daß das Vorstehende dazu dient, die vorliegende Erfindung zu illustrieren und nicht auf die spezifischen, hier be schriebenen Ausführungsbeispiele beschränkt ist, und daß Änderungen von den beschriebenen Ausführungsbeispielen sowie von anderen Ausführungsbeispielen im Bereich der anhängenden Ansprüche liegen. Die Erfindung wird von den folgenden Ansprüchen mit den Äquivalenten der Ansprüche, die darin enthalten sind, definiert.

Claims

1. Ein Verfahren zur Bereitstellung eines Dokumentenverwaltungssystems, das zur Integration mit einer Softwareverwaltungs- und Kontrollbibliothek geeignet ist, wobei das Verfahren umfaßt:
Kapseln einer Vielzahl von Dokumentendatenbanken mit einer Maske, um eine Dokumentendatenbank bereitzustel len, die mit der Softwareverwaltungs- und Kontrollbibliothek wechselwirkt.

2. Ein Verfahren gemäß Anspruch 1, wobei der Kapselungsschritt umfaßt:
Definieren der Vielzahl von Dokumentendatenbanken unter Verwendung der Maske.

3. Ein Verfahren gemäß Anspruch 2, wobei der Definitionsschritt umfaßt:
Definieren einer Anforderungsdokumenten-Datenbank;
Definieren einer Design- und Entwicklungsdokumenten- Datenbank; und
Definieren einer Testdokumenten-Datenbank.

4. Ein Verfahren gemäß Anspruch 3, wobei das Definieren der Anforderungsdokumenten-Datenbank außerdem umfaßt:
Definieren eines Anforderungsdokument zur Speicherung von Anforderungsinformationen in der Anforderungsdokumenten-Datenbank;
Definieren eines Merkmalsdokuments zur Speicherung von Merkmalsinformationen, die zu den in der Anforderungsdokumenten-Datenbank gespeicherten Anforderungsdokumenten gehören, in der Anforderungs dokumenten-Datenbank.

5. Ein Verfahren gemäß Anspruch 4, wobei das Definieren der Design- und Entwicklungsdokumenten-Datenbank umfaßt:
Definieren eines Designdokuments zur Speicherung von Designinformationen in der Design- und Entwicklungsdokumenten-Datenbank;
Definieren eines detaillierten Designdokuments zur Speicherung von zusätzliche Designinformationen, die zu den Designdokumenten in der Design- und Entwicklungsdatenbank gehören;
Definieren eines Änderungsdokuments zur Speicherung von Designänderungsinformationen, die zu wenigstens einem der Designdokumente und der detaillierten Designdokumente gehören, die in der Design- und Entwicklungsdatenbank gespeichert sind; und
Definieren eines Merkmalsdokuments zur Speicherung von Merkmalsinformationen, die zu wenigstens einem der Designdokumente, der detaillierten Designdokumente und der Änderungsdokumente gehören, die in der Design- und Entwicklungsdatenbank gespeichert sind, in der Design- und Entwicklungsdokumenten-Datenbank.

6. Ein Verfahren gemäß Anspruch 5, wobei das Definieren der Testdokumenten-Datenbank außerdem umfaßt:
Definieren eines Testfalldokument zur Speicherung von Testfallinformationen in der Testfalldokumenten- Datenbank;
Definieren eines Ausführungsaufzeichnungsdokuments zur Speicherung von Ausführungsinformationen, die zu einem Testfalldokument gehören, das in der Testdokumenten- Datenbank gespeichert ist, in der Testdokumenten- Datenbank; und
Definieren eines Defektdokuments zur Speicherung von Defektinformationen, die zu den Ausführungsaufzeichnungen gehören, die in der Testdokumenten-Datenbank gespeichert sind, in der Testdokumenten-Datenbank.

7. Ein Verfahren gemäß Anspruch 6, wobei jedes der definierten Dokumente eine Dokumentendefinition mit einem Verknüpfungsfeld enthält, um Dokumente, die per Definition erstellt wurden, mit einem anderen Dokument zu verknüpfen.

8. Ein Verfahren gemäß Anspruch 6, wobei der Kapselungs schritt außerdem umfaßt:
Definieren einer Vielzahl von Benutzerberechtigungsebenen, die zur Vielzahl der Dokumentendatenbanken gehören, wobei die Vielzahl der Benutzerberechtigungsebenen die Zugangs- und Kontroll rechte definieren, die zu Dokumenten gehören, die in der Vielzahl von Datenbanken gespeichert sind.

9. Ein Verfahren gemäß Anspruch 8, das außerdem die Schritte umfaßt:
Definieren einer Vielzahl von zulässigen Statuszuständen für wenigstens eine Dokumentendefinition für wenigstens eine der Anforderungsdokumenten-Datenbanken, der Design- und Entwicklungsdokumenten-Datenbanken und der Testdatenbanken; und
Definieren von Aktionen, die für Dokumente zulässig sind, die mit wenigstens einer Dokumentendefinition erstellt wurden, um so die zulässigen Aktionen zu kontrollieren, die auf einer Kombination des Statuszustands des erstellten Dokuments und einer Benutzerberechtigungsebene basieren, die zu einem Benutzer gehört, der auf das erstellte Dokument zugreift.

10. Ein Verfahren gemäß Anspruch 6, mit dem weiteren Schritt:
Definieren eines Formularformats zur Verwendung bei einem Zugriff auf Dokumente in jeder der Vielzahl der Datenbanken.

11. Ein Verfahren gemäß Anspruch 10, wobei das Formularformat wenigstens ein vordefiniertes Unterformular und wenigstens ein benutzerdefiniertes Unterformular enthält.

12. Ein Verfahren gemäß Anspruch 1, wobei die Maske eine Lotus Notes Maske ist.

13. Ein Datenbankverwaltungs- und Kontrollsystem mit
einer Vielzahl von Datenbanken; und
Mitteln zum Kapseln einer aus der Vielzahl von Datenbanken ausgewählte Datenbank mit einer Maske, um eine Datenbank bereitzustellen, die mit der Softwareverwaltungs- und Kontrollsystem wechselwirkt.

14. Ein System gemäß Anspruch 13, wobei die Kapselungsmittel Mittel zum Definieren der Vielzahl von Datenbanken unter Verwendung der Maske umfassen.

15. Ein System gemäß Anspruch 14, wobei die Vielzahl von Datenbanken zu einer Softwareverwaltungs- und Kontrollbibliothek gehören und die Mittel zum Definieren umfassen:
Mittel zum Definieren einer Anforderungsdokumenten- Datenbank;
Mittel zum Definieren einer Design- und Entwicklungsdokumenten-Datenbank; und
Mittel zum Definieren einer Testdokumenten-Datenbank.

16. Ein System gemäß Anspruch 15, wobei die Mittel zur Definition einer Anforderungsdokumenten-Datenbank außerdem umfassen:
Mittel zum Definieren eines Anforderungsdokument zur Speicherung von Anforderungsinformationen in der Anforderungsdokumenten-Datenbank; und
Mittel zum Definieren, um ein Merkmalsdokument zu definieren, um in der Anforderungsdokumenten-Datenbank Merkmalsinformationen zu speichern, die zu den in der Anforderungsdokumenten-Datenbank gespeicherten Anforderungsdokumenten gehören.

17. Ein System gemäß Anspruch 14, wobei die Mittel zur Definition einer Design- und Entwicklungsdokumenten- Datenbank außerdem umfassen:
Mittel zum Definieren eines Designdokuments zur Speicherung von Designinformationen in der Design- und Entwicklungsdokumenten-Datenbank;
Mittel zum Definieren eines detaillierten Designdokuments zur Speicherung von zusätzlichen Designinformationen, die zu den Designdokumenten in der Design- und Entwicklungsdatenbank gehören;
Mittel zum Definieren eines Änderungsdokuments zur Speicherung von Designänderungsinformationen, die zu wenigstens einem der Designdokumente und der detaillierten Designdokumente gehören, die in der Design- und Entwicklungsdatenbank gespeichert sind; und
Mittel zum Definieren eines Merkmalsdokuments zur Speicherung von Merkmalsinformationen, die zu wenigstens einem der Designdokumente, der detaillierten Designdokumente und der Änderungsdokumente gehören, die in der Design- und Entwicklungsdatenbank gespeichert sind, in der Design- und Entwicklungsdokumenten- Datenbank.

18. Ein System gemäß Anspruch 17, wobei die Mittel zur Definition einer Testdokumenten-Datenbank außerdem umfassen:
Mittel zum Definieren eines Testfalldokuments zur Speicherung von Testfallinformationen in der Testfalldokumenten-Datenbank zu definieren;
Mittel zum Definieren eines Ausführungsaufzeichnungsdokuments zur Speicherung von Ausführungsinformationen, die zu einem Testfalldokument gehören, das in der Testdokumenten-Datenbank ge speichert ist, in der Testdokumenten-Datenbank; und
Mittel zum Definieren eines Defektdokuments zur Speicherung von Defektinformationen, die zu den Ausführungsaufzeichnungen gehören, die in der Testdokumentendatenbank gespeichert sind, in der Test dokumenten-Datenbank.

19. Ein Computerprogrammprodukt, gespeichert auf einem computerlesbaren Medium, wobei das Computerprogrammprodukt computerlesbaren Programmcode enthält, und der Programmcode einen Computer veranlaßt, ein Verfahren nach Anspruch 1 auszuführen, wenn das Computerprogrammprodukt in einem Computer ausgeführt wird.

20. Ein Computerprogrammprodukt, gespeichert auf einem computerlesbaren Medium, wobei das Computerprogrammprodukt computerlesbaren Programmcode enthält, und der Programmcode einen Computer veranlaßt, ein Datenbankverwaltungs- und Kontrollsystem entsprechend Anspruch 13 zu implementieren, wenn das Computerprogrammprodukt in einem Computer ausgeführt wird.