Logo des Repositoriums

Auflistung nach Autor:in "Sneed, Harry"

1 - 10 von 12
  • Zeitschriftenartikel
    Agiles Testmanagement
    (Rundbrief des Fachausschusses Management der Anwendungsentwicklung und -wartung (WI-MAW): Vol. 19, No. 2, 2013) Sneed, Harry
  • Konferenzbeitrag
    Checking Consistency and Completeness of Software Systems
    (Software Engineering and Software Management 2019, 2019) Sneed, Harry
    The following paper presents the current state of the author’s research on the subject of static software tracing, a research which dates back to the year 2000 when the author was requested to predict the costs of software maintenance projects. The goal of static tracing is to link the software artifacts produced in software development with the original requirements. These artifacts are linked by comparing the data names they use, i.e. their operands, with the nouns in the requirement text. Artifacts that have data names similar to those used in the requirement texts are considered to be implementations of those requirements.
  • Zeitschriftenartikel
    Ein Modell für natursprachliche Anforderungsdokumente
    (Informatik-Spektrum: Vol. 39, No. 5, 2016) Demuth, Birgit; Sneed, Harry
    Trotz oder vielleicht wegen ihrer Ungenauigkeit und Mehrdeutigkeit ist die natürliche Sprache weiterhin das Hauptinstrument der Anforderungsdokumentation. Das Anforderungsdokument dient mehreren Zwecken, als Vorgabe für die technische Implementierung, als Vereinbarung mit den Benutzern, was sie an Funktionalität und Qualität zu erwarten haben, als verbindliche Vertragsunterlage zwischen Auftraggeber und Auftragnehmer und nicht zuletzt als Basis für den Systemtest. Demzufolge muss das Dokument mehrere Sichten anbieten – eine Sicht für die Entwickler, eine Sicht für die Anwender und eine Sicht für die Tester. In diesem Beitrag wird die Rolle der Anforderungsdokumentation als Basis für den Systemtest betont. Die Hauptaussage ist, die Grundlage für den Systemtest bereits bei der Spezifikation der Anforderungen mit dem Ziel zu legen, die Effektivität des Tests bei gleichzeitiger Reduzierung der Testkosten zu steigern. Die beschriebene Methode, die eine maschinelle Textanalyse einschließt, wurde von Harry Sneed in einem Dutzend von industriellen Testprojekten seit 2005 erprobt und verfeinert.
  • Zeitschriftenartikel
    Evolution Service-Orientierter Systeme
    (Rundbrief des Fachausschusses Management der Anwendungsentwicklung und -wartung (WI-MAW): Vol. 19, No. 1, 2013) Sneed, Harry
    In diesem Beitrag geht es um die Evolution, Wartung und Weiterentwicklung Serviceorientierter Systeme (SoS). Zunächst werden die besonderen Eigenschaften solcher Systeme auf dem Hintergrund einer Service-orientierter Architektur(SoA) erläutert. Danach werden drei Probleme vorgestellt, die im Zusammenhang mit der Evolution Service-orientierter Systeme stehen ­ die Mehrsprachigkeit, die gestiegene Komplexität und die vermehrte Abhängigkeit von externen Lieferanten. Der Beitrag geht darauf ein, welchen Einfluss diese Probleme auf die Evolution der Software haben werden. Anschließend werden alternative Möglichkeiten aufgezeichnet mit diesen Problemen fertig zu werden. Schlüsselbegriffe Software-Evolution, Web-Services, Service-orientierter Architekturen, Wartung, Weiterentwicklung, Reverse-Engineering, Regressionstest.
  • Zeitschriftenartikel
    Evolutionsschätzung
    (Rundbrief des Fachausschusses Management der Anwendungsentwicklung und -wartung (WI-MAW): Vol. 19, No. 1, 2013) Sneed, Harry
    Der folgende Betrag ist ein Ausschnitt aus dem neuen Buch von Harry M. Sneed zum Thema Software-Evolution, das demnächst im dpunkt Verlag erscheint. Er schreibt ein Verfahren vor um die Kosten der nächsten Release-Periode zu ermitteln. Das Verfahren nutzt neue Ansätze zur Voraussage der Fehleranzahl und zur Projektierung der Fehlerbehebungskosten sowie zur Kalkulation des Deltas zwischen dem alten und dem neuen Release aufgrund einer Impaktanalyse und zur Schätzung des Aufwandes um dieses Delta bereitzustellen. Software-Evolution beinhaltet die parallelen Aktivitäten Fehlerbehebung, Änderung, Sanierung und Weiterentwicklung eines bestehenden Softwareproduktes. In regermäßigen Intervallen von drei bis sechs Monaten werden neue Releases des Produktes herausgegeben, in denen neue Funktionen und Daten erscheinen. Gleichseitig wird im letzten Release Fehler beseitigt und Notänderungen durchgeführt. Der Produktleiter muss deshalb bei der Planung der nächsten Release-Periode beides berücksichtigen ­ die Pflege des zuletzt ausgelieferten Release und die Bereitstellung des nächsten Release, denn beide Aktivitäten laufen neben einander her.
  • Zeitschriftenartikel
    Meinung/Dialog
    (Wirtschaftsinformatik: Vol. 46, No. 6, 2004) Buhl, Hans Ulrich; Lehner, Franz; Sneed, Harry; Kurbel, Karl
  • Konferenzbeitrag
    Migrating to a service-oriented architecture
    (Software-engineering and management 2015, 2015) Sneed, Harry
  • Zeitschriftenartikel
    Migration einer veralteten Power-Builder Applikation in eine moderne Java Applikation
    (Softwaretechnik-Trends Band 31, Heft 2, 2011) Sneed, Harry
    Hier wird die automatische Transformation einer Power-Builder Applikation aus den 90er Jahren mit einer Zwei-Schichten-Client/Server-Architektur in ein modernes Java-Anwendungssystem mit drei Architekturschichten geschildert. Neben der Umsetzung der Power-Builder GUI-Oberflächen in Java-SWT Oberflächen wird die Verarbeitungslogik aus den PowerBuilder Thick-Client Modulen entfernt und in Java Transformationsklassen versetzt. Auf der Datenbankseite werden die PL-SQL Stored-Procedures aus der Datenbank entfernt und in Java Zugriffsklassen versetzt. Dadurch entsteht eine neue Architekturschicht zwischen den jetzt verdünnten Client-Oberflächen und der abgemagerten Datenbankstruktur, die frei von der Zugriffslogik ist. Zur Zeit ist die Umsetzung nur teils automatisiert; die vollautomatische Transformation ist aber noch für dieses Jahr geplant.
  • Konferenzbeitrag
    Model-based Software Cost Estimation: Calculating Time and Effort for Software Evolution Projects
    (Modellierung 2020, 2020) Sneed, Harry; Prentner, Wolfgang
    Estimating the costs of an evolution project differs from development project estimation and must follow its own rules. When estimating development project costs the whole system is taken into consideration. When estimating evolution costs only those parts of the system are considered that have to be changed or added. The rest is left as it is, but must be included in the test. The mixing of changed components with new components and old components presents several challenges to software product management. The main challenge is how to recognize those features that have to be added or changed – feature analysis. Together they make up the change domain. The extent of this change domain is the key factor in estimating the costs of change in each new release. It is measured by means of one or more size metrics such as function-points, data-points and object-points in order to convert size into effort. The approach used here was to model the change requirements and then compare the change model with the original requirements model to ascertain the scope of the change. To this end, both the original and the current requirements had to be extracted from the requirement text and then modelled. This approach was applied here to calculate the costs of expanding a national health record system. The preliminary results are presented in this short paper.
  • Zeitschriftenartikel
    Reengineering for Testability
    (Softwaretechnik-Trends Band 26, Heft 2, 2006) Sneed, Harry