Suchergebnisse

Directory of software products developed in Singapore, with details of the products (package name, name, address and telephone number of the company selling the package, package function, hardware on which package runs, operating system, minimum memory requirement, source language, pricing structure, training, number of users, product description, etc). Index of computer packages. Index of companies. (Econom. Voorl.dienst)

Im Bereich der organisationsbezogenen Software-Entwicklung zeichnet sich eine paradoxe Situation ab: die herrschende Vorstellung von der sequentiellen Abarbeitung von Entwicklungsschritten einer formal spezifizierten Problemstellung als Idealfall einer "ingenieursmäßig sauberen" Vorgehensweise und andererseits die Praxis einer inkrementellen Anpassung von Zielen sowie ein Mangel an Reflexion. Ausgehend von dieser Beobachtung fragt der Autor nach der Bedeutung konstruktionsleitender Orientierungsmuster in der Software-Entwicklung. Er geht aus von einem theoretischen 3-Stufen-Modell der Technikentwicklung und unterscheidet zwischen Leitbildern, Konstruktionstraditionen und -stilen. Darauf aufbauend wird die konstitutive Bedeutung einer ingenieurwissenschaftlichen Perspektive bei der Entwicklung der Softwaretechnik zu einem eigenständigen Technikfeld sowie die Entstehung einer designwissenschaftlichen Perspektive angesichts der besonderen Probleme organisationsbezogener Software-Entwicklung untersucht. Eine Erklärung für die scheinbar paradoxe Ausgangssituation ergibt sich durch die Berücksichtigung des Inhalts von Widersprüchen zwischen gültigen Orientierungsmustern. So müsse der Begriff des Leitbildes im Hinblick auf die Machbarkeit weiter ausdifferenziert werden. Der Diskurs zwischen ingenieur- und designwissenschaftlicher Perspektive wird in absehbarer Zeit nicht mit "Sieg oder Niederlage einer der beiden Sichtweisen" enden, lautet ein Resümee. (rk)

Die folgenden Ausführungen nehmen das 50. Jubiläum der berühmten NATO-Konferenzen von Garmisch und Rom zum Anlass zu einem kritischen Blick auf das meist vereinfachte Geschichtsbild der Software Community. Dem vorherrschenden linearen Erfolgsmodell wird eine erweiterte historische Perspektive gegenübergestellt und die These entwickelt, dass die lange vor 1968/69 beginnende softwaretechnische Methodenentwicklung sehr wesentlich ein diskontinuierlicher Lernprozess war, in dem frühere Erkenntnisse über die Grenzen der Engineering-Metapher und erste Ansätze zu iterativen und evolutionären Designmethodenaus dem Blick gerieten und Jahrzehnte später erst wieder neu entdeckt werden mussten. Es wird daher die bisher nur sehr verkürzt wahrgenommene Traktat-Literatur der 'Vorläufer' des Software Engineering analysiert und gezeigt, dass von Beginn mit diesem die Leitbilder der Software Manufaktur und Software Architecture konkurrierten. Das 1. Kapitel skizziert zunächst den Entstehungskontext der Garmisch-Konferenz und legt dabei Friedrich L. Bauers Intentionen und Programmatik sowie deren Folgen für die disziplinäre Verortung der Disziplin Software Engineering dar. Dann wird anhand eines Vergleiches von Rückblicken von Pionieren und Repräsentanten der Software Engineering-Community bei den 10-Jahres-Jubiläen der NATO-Konferenzen die Zunahme von Problemwahrnehmungen und die allmähliche Entzauberung des Garmisch-Mythos herausgearbeitet. Gleichwohl hielt man beharrlich an einem vagen Ingenieur-und Industrialisierungs-Leitbild fest, das, wie der Wissenschaftshistoriker Michael Mahoney mehrfach dargelegt hat, nie gründlicher wissenschaftlich fundiert wurde. Die Engineering-Metapher hatte so letztlich zwar eine wichtige Anstoßfunktion für die Institutionalisierung der Disziplin, siereichte aber offenbar nicht aus, um die Entwicklung der Softwaretechnik als einen durchgängigen Verwissenschaftlichungs- und Industrialisierungsprozess zu begründen. Im 2. Kapitel werden Software-Manufakturen im militärischen und staatlichen Contractor-Sektor betrachtet, die unter dem Einfluß von Operations Research und Systems Engineering standen und den Schwerpunkt auf eine Team-orientierte Teilung der Arbeit legten. In diesen gab es bereits vor den NATO-Konferenzen von deren Teilnehmern nicht zur Kenntnis genommene Engineering-Konzepte und Prozess-und Lifecycle-Modelle für die Softwareherstellung. Doch es werden hier bereits die Grenzen von wasserfallartigen Entwicklungsprozessen erkannt und erste Modelle für ein iteratives und evolutionales Vorgehen erörtert. Das 3. Kapitel behandelt das Software-Architektur-Konzept im Corporate Software-Sektor, das hierarchische Organisationsprinzipien mit einem nicht-analytischen erfahrungs- und qualitätsorientierten Designkonzept verknüpfte. Dabei wird gezeigt, dass schon parallel zur Propagierung des Software-Engineering-Begriffs seit den 60iger Jahren Software Architecture als Methodenleitbild in der Community kursierte, mit dem neben der Produkt-und Prozess-Strukturierung vor allem der Synthese-Charakter der Software-Entwicklung betont wurde. Das 4. Kapitel legt skizzenhaft dar, dass als Folge der Krise des Software-Engineerings das Software-Architektur-Leitbild seit den späten 80er Jahren eine Renaissance erlebte mit dem Ziel einer Vollendung bzw. einer Ablösung des Software-Engineering-Konzeptes.

This paper is to appear in IANewsletter, June 2002. ; Some information systems are critical to defend against malicious attack. Yet they often rely on just the same countermeasures as any system ? firewalls, authentication, intrusion-detection systems, and encryp!tion ? although politically motivated attackers may be far more determined than hackers to bring them down. Future information security will increasingly use ideas from military defensive tactics [3] to effectively defend critical information sys!tems. This will include automatic "counterintelligence" with deliberately deceptive behavior, what we call "software decoys". Decoys can deceive attackers into thinking their attacks have succeeded while protecting key assets at least temporarily.