Search

Die Energiewende stößt im Kontext des tradierten, zentral organisierten Energiemanagements an die Systemgrenzen. Erneuerbare Energien sind nicht grundlastfähig und stehen asynchron zum Bedarf zur Verfügung. Hinreichend große Pufferspeicher sind teuer. Die Lösung besteht, neben effizienteren und innovativen Energiewandlungstechnologien, insbesondere im Umstieg auf ein dezentrales Energiemanagement: Cross-Energie-Managementsysteme bringen entlang der Lieferketten die Flexibilität bei Bereitstellung von Energie optimal mit den Flexibilitätspotenzialen der Nutzung von Energie in Einklang.

An integral part of software engineering curricula at universities are practical classes or projects that enable students to apply theoretical knowledge gained in lectures on concrete practical examples. Practical projects, in particular, defined as university-industry collaborations provide the potential of being very beneficial especially in graduate education: in such realistic project settings, students can experience real-life software engineering challenges and achieve learning objectives that go beyond typical learning objectives of practical assignments during classes or even practical projects defined by faculty members. However, such collaborative projects have to be planned carefully and also come with various challenges. In this article, authors from academia and industry share their experiences gained during a history of successfully conducted collaborative projects. These experiences comprise objectives, benefits, challenges and lessons learned both from an educational viewpoint (i.e., students, supervisors), research viewpoint (supervisors), and industry viewpoint (customer). The experiences summarized in this article could serve as motivation and valuable information for other universities and industry companies intending to plan and organize collaborative projects of this kind.

Distributed software development imposes new project risks that are very different from the ones in collocated development and are overlooked easily. At the same time, they depend to a large extent on project-specific characteristics. Therefore, new methods for identifying these risks in distributed projects have to be developed. This article presents a model for identifying these risks at the beginning of a project. The model systematically captures experiences from past projects in a set of logical rules describing how project characteristics influence typical risks in distributed development. Thus, it is able to assess risks individually for each project. In addition, the model can be used for evaluating different task assignment alternatives, which makes it possible to allocate tasks systematically. An instance of the model was developed by applying qualitative content analysis to 19 interviews with practitioners. An evaluation using expert interviews showed that the risks identified by the model matched the actual experiences in 81% of the cases; of these, 40% had not been regarded at project start.

In den vielfältigen Diskursen um E-Government und Verwaltungsmodernisierung werden immer wieder die Geschäftsbeziehungen und Prozesse zwischen Wirtschaft und Verwaltung in den Blick genommen. Vor dem Hintergrund allgemein knapper Finanzressourcen wird das Interesse bei Unternehmen und Behörden immer deutlicher, nach Verbesserungsmöglichkeiten in ihren Austauschbeziehungen zu suchen, die sich auf Informationstechnologien (IT) stützen. Jedoch kostet es wiederum Mühe und Aufwand, diejenigen Prozesse und Prozessketten zu identifizieren, die das größte Optimierungspotenzial aufweisen und den höchsten Nutzen versprechen - sei es im Sinne eines verbesserten Mitteleinsatzes, eines erhöhten Steueraufkommens oder der gesteigerten Kundenzufriedenheit. Deshalb muss es das vorrangige Ziel von Unternehmen und Behörden sein, insbesondere solche Prozesse zu identifizieren, deren IT-Optimierung für beide Seiten zu einer spürbaren Verbesserung und zu einem nachweisbaren Gewinn führt. In diesem Aufsatz werden wir eine Methode vorstellen, die durch ein Priorisierungsverfahren die Anwender in Wirtschaft und Verwaltung in die Lage versetzt, genau die aussichtsreichsten Kandidaten einer Prozessverbesserung zu erkennen.

Traditional engineering disciplines such as mechanical and electrical engineering are guided by physical laws. They provide the constraints for acceptable engineering solutions by enforcing regularity and thereby limiting complexity. Violations of physical laws can be experienced instantly in the lab. Software engineering is not constrained by physical laws. Consequently, we often create software artifacts which are too complex to be understood,tested or maintained. As too complex software solutions may even work initially, we are tempted to believe that no laws apply. We only learn about the violation of some form of "cognitive laws" late during development or during maintenance, when too high complexity inflicts follow-up defects or increases maintenance costs. Initial work by Barry Boehm (e.g., CoCoMo) aimed at predicting and controlling software project costs based on estimated software size. Through innovative life cycle process models (e.g., Spiral model) Barry Boehm also provided the basis for incremental risk evaluation and adjustment of such predictions. The proposal in this paper is to work towards a scientific basis for software engineering by capturing more such time-lagging dependencies among software artifacts in the form of empirical models and thereby making developers aware of so-called "cognitive laws" that must be adhered to. This paper attempts to answer the questions why we need software engineering laws and how they could look like, how we have to organize our discipline in order to build up software engineering laws, what such laws already exist and how we could develop further laws, how such laws could contribute to the maturing of science and engineering of software in the future, and what the remaining challenges are for teaching, research, and practice in the future.

Elderly people living alone lead dangerous lives: If they fall, they often spend hours lying on the floor before their situation comes to anyone's attention and a doctor can be sent for. But falls are not the sole reason for critical situations. Physical frailty or sudden disorientation can also lead to precarious situations, which is why a fall detection system alone is not sufficient. A new system automatically detects elderly people stuck in difficult situations and informs a trusted person. This makes it possible for elderly people to live an independent life in their own home for a longer period of time.

Humans are getting permanently older. Age-related disabilities and diseases increase dramatically with growing age, and often force the respective persons to continue their life in nursing homes. Can ambient-intelligent technology help to extend a self-conducted life of elderly people in their own homes? This article attempts to provide answers to this question. We present the concept of an AmI-based assistance system which detects actual emergencies and tries to avoid their occurrence.

Intellectual control over software development projects requires the existence of an integrated set of explicit models of the products to be developed, the processes used to develop them, the resources needed, and the productivity and quality aspects involved. In recent years the development of languages, methods and tools for modeling software processes, analyzing and enacting them has become a major emphasis of software engineering research. The majority of current process research concentrates on prescriptive modeling of small, completely formalizable processes and their execution entirely on computers. This research direction has produced process modeling languages suitable for machine rather than human consumption. The MVP project, launched at the University of Maryland and continued at Universität Kaiserslautern, emphasizes building descriptive models of large, real-world processes and their use by humans and computers for the purpose of understanding, analyzing, guiding and improving software development projects. The language MVP-L has been developed with these purposes in mind. In this paper, we motivate the need for MVP-L, introduce the prototype language, and demonstrate its uses. We assume that further improvements to our language will be triggered by lessons learned from applications and experiments.

The rapid development of any field of knowledge brings with it unavoidable fragmentation and proliferation of new disciplines. The development of computer science is no exception. Software engineering (SE) and human-computer interaction (HCI) are both relatively new disciplines of computer science. Furthermore, as both names suggest, they each have strong connections with other subjects. SE is concerned with methods and tools for general software development based on engineering principles. This discipline has its roots not only in computer science but also in a number of traditional engineering disciplines. HCI is concerned with methods and tools for the development of human-computer interfaces, assessing the usability of computer systems and with broader issues about how people interact with computers. It is based on theories about how humans process information and interact with computers, other objects and other people in the organizational and social contexts in which computers are used. HCI draws on knowledge and skills from psychology, anthropology and sociology in addition to computer science. Both disciplines need ways of measuring how well their products and development processes fulfil their intended requirements. Traditionally SE has been concerned with 'how software is constructed' and HCI with 'how people use software'. Given the different histories of the disciplines and their different objectives, it is not surprising that they take different approaches to measurement. Thus, each has its own distinct 'measurement culture.' In this paper we analyse the differences and the commonalties of the two cultures by examining the measurement approaches used by each. We then argue the need for a common measurement taxonomy and framework, which is derived from our analyses of the two disciplines. Next we demonstrate the usefulness of the taxonomy and framework via specific example studies drawn from our own work and that of others and show that, in fact, the two disciplines have many important similarities as well as differences and that there is some evidence to suggest that they are growing closer. Finally, we discuss the role of the taxonomy as a framework to support: reuse, planning future studies, guiding practice and facilitating communication between the two disciplines.

Software-Projekte bestehen aus einer Vielzahl von Teilaufgaben, die durch komplexe Wechselbeziehungen miteinander verknüpft sind. Systematische Unterstützung bei der Durchführung von Software-Projekten erfordert deshalb nicht nur die isolierte Unterstützung einzelner Teilaufgaben, sondern insbesondere der Wechselbeziehungen. Außerdem müssen Aktivitäten des Messens und Bewertens durchgeführt werden, um quantitative Aussagen über Produkte und Prozesse ableiten zu können. Ziel des MVP-Projekts (Multi-View Process modeling) ist es, derartige integrierte Unterstützung auf der Basis meßbarer Projektpläne zur Verfügung zu stellen. Projektpläne setzen sich dabei unter anderem aus Prozeß-, Produkt-, Ressourcen- und Qualitätsmodellen zusammen. Meßansätze werden nicht nur zur systematischen Unterstützung von Projekten, sondern auch zur Verbesserung existierender Prozeß-, Produkt-, Ressource- und Qualitätsmodelle aufgrund 'gemessener' Erfahrungswerte verwendet. Die Benutzer des MVP-Entwicklungssystems (MVP-S) werden durch ihre Rollen im Rahmen eines Projekts charakterisiert werden können. Es wird beschrieben, wie Rollen das MVP-System nutzen können. Dies geschieht entweder durch direkte Repräsentation ihrer Aufgaben als Prozesse oder indem die im Projektplan repräsentierte Information ausgewertet und präsentiert wird; entsprechend bezeichnen wir eine Rolle als "zustandsverändernd" oder als "zustandserfragend". Um diese Rollen zu unterstützen, existieren unterschiedliche Möglichkeiten abhängig vom Grad der Automatisierung. Es werden beispielhaft drei Stufen aufgezeigt. Anschließend wird die Realisierung einer prototypischen, qualitätsorientierten, prozeßsensitiven Software-Entwicklungsumgebung diskutiert. Zum Abschluß wird auf gegenwärtige und zukünftige Forschungsfragen im Rahmen des MVP-Projekts eingegangen.