Identifying cognitive aspects to improve business process reengineering

Knowledge-intensive processes are widely used to recover from errors, handle exceptional cases and complaints, and to improve or adapt a process itself. In this context, evolved Business-Process Reengineering (BPR) techniques are changing to give some answers to this reality. In this paper, we identify some cognitive aspects used by traditional and recent reengineering models. We provide a framework highlighting how cognitive aspects might improve reengineering through knowledge and perception modelling.Eje: I - Workshop de Ingeniería de Software y Base de DatosRed de Universidades con Carreras en Informática (RedUNCI

Identifying cognitive aspects to improve business process reengineering

Knowledge-intensive processes are widely used to recover from errors, handle exceptional cases and complaints, and to improve or adapt a process itself. In this context, evolved Business-Process Reengineering (BPR) techniques are changing to give some answers to this reality. In this paper, we identify some cognitive aspects used by traditional and recent reengineering models. We provide a framework highlighting how cognitive aspects might improve reengineering through knowledge and perception modelling.Eje: I - Workshop de Ingeniería de Software y Base de DatosRed de Universidades con Carreras en Informática (RedUNCI

Feature-based methodology for supporting architecture refactoring and maintenance of long-life software systems

Zusammenfassung Langlebige Software-Systeme durchlaufen viele bedeutende Veraenderungen im Laufe ihres Lebenszyklus, um der Weiterentwicklung der Problemdomaenen zu folgen. Normalerweise ist es schwierig eine Software-Systemarchitektur den schnellen Weiterentwicklungen einer Problemdomaene anzupassen und mit der Zeit wird der Unterschied zwischen der Problemdomaene und der Software-Systemarchitektur zu groß, um weitere Softwareentwicklung sinnvoll fortzufuehren. Fristgerechte Refactorings der Systemarchitektur sind notwendig, um dieses Problem zu vermeiden. Aufgrund des verhaeltnismaeßig hohen Gefahrenpotenzials und des zeitlich stark verzoegerten Nutzens von Refactorings, werden diese Maßnahmen normalerweise bis zum letztmoeglichen Zeitpunkt hinausgeschoben. In der Regel ist das Management abgeneigt Architektur-Refactorings zu akzeptieren, außer diese sind absolut notwendig. Die bevorzugte Vorgehensweise ist, neue Systemmerkmale ad hoc hinzuzufuegen und nach dem Motto ”Aendere nie etwas an einem funktionierenden System!” vorzugehen. Letztlich ist das Ergebnis ein Architekturzerfall (Architekturdrift). Die Notwendigkeit kleiner Refactoring-Schritte fuehrt zur Notwendigkeit des Architektur-Reengineerings. Im Gegensatz zum Refactoring, das eine normale Entwicklungstaetigkeit darstellt, ist Reengineering eine Form der Software- ”Revolution”. Reengineeringprojekte sind sehr riskant und kostspielig. Der Nutzen des Reengineerings ist normalerweise nicht so hoch wie erwartet. Wenn nach dem Reengineering schließlich die erforderlichen Architekturaenderungen statt.nden, kann dies zu spaet sein. Trotz der enormen in das Projekt gesteckten Bemuehungen erfuellen die Resultate des Reengineerings normalerweise nicht die Erwartungen. Es kann passieren, dass sehr bald ein neues, kostspieliges Reengineering erforderlich wird. In dieser Arbeit werden das Problem der Softwareevolution und der Zerfall von Softwarearchitekturen behandelt. Eine Methode wird vorgestellt, welche die Softwareentwicklung in ihrer entscheidenden Phase, dem Architekturrefactoring, unterstuetzt. Die Softwareentwicklung wird sowohl in technischer als auch organisatorischer Hinsicht unterstuetzt. Diese Arbeit hat neue Techniken entwickelt, welche die Reverse-Engineering-, Architecture-Recovery- und Architecture-Redesign-Taetigkeiten unterst uetzen. Sie schlaegt auch Aenderungen des Softwareentwicklungsprozesses vor, die fristgerechte Architekturrefactorings erzwingen koennen und damit die Notwendigkeit der Durchfuehrung eines Architektur- Reengineerings vermeiden. In dieser Arbeit wird die Merkmalmodellierung als Hauptinstrument verwendet. Merkmale werden genutzt, um die Abstraktionsluecke zwischen den Anforderungen der Problemdomaene und der Systemarchitektur zu fuellen. Merkmalmodelle werden auch als erster Grundriss fr die Wiederherstellung der verlorenen Systemarchitektur genutzt. Merkmalbasierte Analysen fuehren zu diversen, nuetzlichen Hinweisen fuer den erneuten Entwurf (das Re-Design) einer Architektur. Schließlich wird die Merkmalmodellierung als Kommunikationsmittel zwischen unterschiedlichen Projektbeteiligten (Stakeholdern) im Verlauf des Softwareengineering-Prozesses verwendet und auf dieser Grundlage wird ein neuer Anforderungsde.nitionsprozess vorgeschlagen, der die erforderlichen Architekturrefactorings erzwingt.The long-life software systems withstand many significant changes throughout their life-cycle in order to follow the evolution of the problem domains. Usually, the software system architecture can not follow the rapid evolution of a problem domain and with time, the diversion of the architecture in respect to the domain features becomes prohibiting for software evolution. For avoiding this problem, periodical refactorings of the system architecture are required. Usually, architecture refactorings are postponed until the very last moment, because of the relatively high risk involved and the lack of short-term profit. As a rule, the management is unwilling to accept architecture refactorings unless they become absolutely necessary. The preferred way of working is to add new system features in an ad-hoc manner and to keep the rule ”Never touch a running system!”. The final result is an architecture decay. The need of performing small refactoring activities turns into need for architecture reengineering. In contrast to refactoring, which is a normal evolutionary activity, reengineering is a kind of software ”revolution”. Reengineering projects are risky and expensive. The effectiveness of reengineering is also usually not as high as expected. When finally after reengineering the required architecture changes take place, it can be too late. Despite the enormous invested efforts, the results of the reengineering usually do not satisfy the expectations. It might happen that very soon a new expensive reengineering is required. This thesis deals with the problem of software evolution and the decay of software architectures. It presents a method, which assists software evolution in its crucial part, the architecture refactoring. The assistance is performed for both technical and organizational aspects of the software evolution. The thesis provides new techniques for supporting reverse engineering, architecture recovery and redesigning activities. It also proposes changes to the software engineering process, which can force timely architecture refactorings and thus avoid the need of performing architecture reengineering. For the work in this thesis feature modeling is utilized as a main asset. Features are used to fill the abstraction gap between domain requirements and system architecture. Feature models are also used as an outline for recovering of lost system architectures. Through feature-based analyses a number of useful hints and clues for architecture redesign are produced. Finally, feature modeling is used as a communication between different stakeholders of the software engineering process and on this basis a new requirements engineering process is proposed, which forces the needed architecture refactorings

Proceedings /5th International Symposium on Industrial Engineering – SIE2012, June 14-15, 2012., Belgrade

editors Dragan D. Milanović, Vesna Spasojević-Brkić, Mirjana Misit

Proceedings /5th International Symposium on Industrial Engineering – SIE2012, June 14-15, 2012., Belgrade

editors Dragan D. Milanović, Vesna Spasojević-Brkić, Mirjana Misit

Proceedings der 11. Internationalen Tagung Wirtschaftsinformatik (WI2013) - Band 1

The two volumes represent the proceedings of the 11th International Conference on Wirtschaftsinformatik WI2013 (Business Information Systems). They include 118 papers from ten research tracks, a general track and the Student Consortium. The selection of all submissions was subject to a double blind procedure with three reviews for each paper and an overall acceptance rate of 25 percent. The WI2013 was organized at the University of Leipzig between February 27th and March 1st, 2013 and followed the main themes Innovation, Integration and Individualization.:Track 1: Individualization and Consumerization Track 2: Integrated Systems in Manufacturing Industries Track 3: Integrated Systems in Service Industries Track 4: Innovations and Business Models Track 5: Information and Knowledge ManagementDie zweibändigen Tagungsbände zur 11. Internationalen Tagung Wirtschaftsinformatik (WI2013) enthalten 118 Forschungsbeiträge aus zehn thematischen Tracks der Wirtschaftsinformatik, einem General Track sowie einem Student Consortium. Die Selektion der Artikel erfolgte nach einem Double-Blind-Verfahren mit jeweils drei Gutachten und führte zu einer Annahmequote von 25%. Die WI2013 hat vom 27.02. - 01.03.2013 unter den Leitthemen Innovation, Integration und Individualisierung an der Universität Leipzig stattgefunden.:Track 1: Individualization and Consumerization Track 2: Integrated Systems in Manufacturing Industries Track 3: Integrated Systems in Service Industries Track 4: Innovations and Business Models Track 5: Information and Knowledge Managemen

Prozessoptimierung in der Krankenhaussprechstunde: Erfahrungen und Ergebnisse unter Berücksichtigung der Möglichkeiten von Informationstechnologie

Einleitung: Prozessorientiertes Denken nimmt in der Medizin bei knapper werdenden Ressourcen einen immer größeren Stellenwert ein. Diese Arbeit untersucht Möglichkeiten der Prozessoptimierung im Bereich der ambulanten Versorgung am Krankenhaus. Fragestellung: Mit einer Interventionsstudie wird untersucht, ob ein aus der Softewareentwicklung abgeleitetes Vorgehensmodell erfolgreich für ein Prozessoptimierungsprojekt in der ambulanten Sprechstunde eines Krankenhauses angewandt werden kann. Es wird die EDVUnterstützung klinischer Abläufe der Sprechstunde eingeführt. Das Gesamtzielkriterium ist die Steigerung der Patientenzufriedenheit. Als Teilaspekt werden die Erstellung und die Anpassung eines in einem KIS abgebildeten Terminkalenders mittels Generatortools untersucht. Können durch eine erfolgreiche Umsetzung verkürzte Wartezeiten der Patienten sowie eine verbesserte Dokumentenbereitstellung erreicht werden? Ein weiterer Teilaspekt ist die Einführung von „Computerized Physician Order Entry“ für radiologische Untersuchungen in der ambulanten Sprechstunde. Ist dies technisch und organisatorisch möglich und können dadurch eine höhere Prozessqualität und kürzere Prozesszeiten erreicht werden? Material und Methoden: Untersucht wird die unfallchirurgische Sprechstunde für ambulante und ehemals stationäre Patienten an einem Krankenhaus der Maximalversorgung. Die Datenerhebungen fanden im Herbst 2002 und Frühjahr 2004 statt. Sie bestehen aus einer Patientenbefragung inklusive eines Zufriedenheitsfragebogens, Messungen der Warte- und Prozesszeiten sowie Mitarbeiterbefragungen. Die zwischenzeitliche Prozessoptimierung erfolgt nach einem Vorgehensmodell, welches sich von dem Modell zur Softwareentwicklung im Krankenhaus nach (Kuhn KA, Lenz R et al. 2003) ableitet. Es besteht aus einer Erkundungs- und einer Analysephase zur Erfassung von Problembereichen und zur Datenerhebung. Es folgt eine Phase des Redesigns, in der Prozessänderungen und IT-Anwendungen entworfen werden. Diese werden in der Implementierungsphase organisatorisch und technisch umgesetzt. Nach einer Phase der Schulung für die Mitarbeiter folgt der Routinebetrieb. In der zweiten Analysephase wird abschließend der der Erfolg des Projektes gemessen. Ergebnisse: Die Prozessoptimierung nach dem genannten Vorgehensmodell konnte erfolgreich durchgeführt werden. Ein Terminkalender für die Sprechstunden und ambulante Operationen wurde erfolgreich im KIS eingeführt, dieser beinhaltet die Terminvergabe bei der Arztbriefschreibung. Die Anmeldung von radiologischen Untersuchungen wurde auf ein CPOE-Verfahren umgestellt und ein Vorgehen zur direkten Einbestellung von Patienten zur Röntgenuntersuchung eingerichtet. Die Mitarbeiter der Sprechstunde akzeptieren diese Prozessänderungen, die eingeführten IT-Anwendungen werden überwiegend als positiv betrachtet. Die Anzahl der vorhandenen Termineinträge der Patienten steigt signifikant auf 67,5% der Fälle (p=0,000), die Verfügbarkeit von Akten bei der Anmeldung des Patienten steigt auf 47,8% (p=0,000). Die Ankunft der Patienten in der Sprechstunde erfolgt durchschnittlich zu einem späteren Zeitpunkt (p=0,000) und verteilt sich gleichmäßiger über die Sprechstundenzeit. Die Wartezeit der Patienten auf den ersten Aufruf in die Sprechstunde sinkt signifikant von 69min. (n=344) auf 43min. (n=317) (p=0,000). Ebenso sinkt die Gesamtdauer des Sprechstundenbesuches signifikant von 128min. auf 100min (p=0,000). Die Wartezeit auf die Röntgenuntersuchung verlängert sich jedoch signifikant um 5min (p=0,045). Die Dauer der Röntgenuntersuchung verlängert sich signifikant um durchschnittlich eine Minute (p=0,039). Weder steigt der Patientenanteil, der direkt zu einer Röntgenuntersuchung einbestellt wird, noch verringert sich die Wartezeit hierfür signifikant. Die Patientenzufriedenheit steigt zwischen den Messzeitpunkten signifikant an (p=0,001). Diskussion: Mit dem Vorgehensmodell kann mit vertretbarem Aufwand erfolgreich eine Prozessoptimierung in einer ambulanten Sprechstunde am Krankenhaus unter Einführung von IT-Anwendungen durchgeführt werden. Kurze Iterationen, ein offener Kommunikationsstil, die frühe Einbindung der Endnutzer und ein abteilungsübergreifendes Vorgehen sind wichtige Erfolgsfaktoren. Die Aufteilung des Gesamtprojektes in Unterschritte ist vorteilhaft. Bei ITgestützten Interventionen ist ein hochpartizipatorischer, iterativer Softewareentwicklungsprozess in Verbindung mit einem holistischen KIS der Schlüssel zum Erfolg. Ein „Generator Tool“ des KIS ermöglicht die schnelle Entwicklung klinischer Anwendungen. Durch die gewählte Form der Prozessoptimierung kann die Patientenzufriedenheit signifikant steigen. Es gibt starke Hinweise, dass Terminkalender im KIS die Wartezeit auf den ersten Aufruf in das Behandlungszimmer und die Gesamtaufenthaltsdauer der Patienten reduzieren sowie die Aktenverfügbarkeit bei der Anmeldung erhöhen. Die Übernahme eines bestehenden CPOE für radiologische Untersuchungen in eine ambulante Sprechstunde am Krankenhaus ist technisch und organisatorisch möglich. Sie führt zu einer höheren Prozessqualität, jedoch entstehen dadurch eine zeitliche Mehrbelastung der anwendenden Ärzte und längere Wartezeiten der Patienten auf die Untersuchung. Die Einbestellung von Patienten direkt zu einer Röntgenuntersuchung unter Verwendung von CPOE ist umsetzbar, führt aber zu keiner Einsparung von Wartezeit für den Patienten. In den neuen Feldern von Prozessdenken und Informationstechnologie in der Patientenversorgung zeigt diese Arbeit ein erfolgreiches Modell zur Optimierung der ambulanten Versorgung am Krankenhaus

Objektorientierter Softwareentwurf in der Sekundarstufe II

Der objektorientierte Softwareentwurf spielt in der Bildung eine immer wichtigere Rolle. Mit ihm kann die Modellbildungskompetenz und die Problemlösefähigkeit, wie sie u.a. in der Pisa-Studie gefordert werden, gut gefördert werden. In dieser Arbeit wird ein Konzept hierfür entwickelt, umgesetzt und evaluiert. Als Leitgedanken bei der Entwicklung dient die Förderung der Modellbildungskompetenz und der Problemlösefähigkeit, wobei der objektorientierte Softwareentwurf in seiner ganzen Breite von der Anforderungsanalyse über das Design bis zur Implementierung bearbeitet wird. Dazu werden zuerst die fachlichen Inhalte strukturiert und diese anschließend zusammen mit einer Lernzieltaxonomie in einer Lehrzielmatrix verknüpft, um so die Lernziele festzulegen. Als didaktisches Konzept wird ein dem üblichen Entwicklungsverlauf beim Softwareentwurf entgegengesetztes Vorgehen gewählt und begründet. Die entwickelten Lernprozesse werden dann mit Hilfe von Aktivitätsdiagrammen dargestellt und feiner ausgearbeitet. Zur Evaluation des Konzepts wurden die ausgearbeiteten Einheiten an 3 Schulen umgesetzt und mit einer Kontrollgruppe an 3 weiteren Schulen verglichen. Dazu wurde ein Test entwickelt und zusammen mit einem IQ-Test und Fragebögen zu den Randbedingungen von den Schülern und Eltern ausgefüllt. Das Ergebnis der Evaluation zeigt, dass die Verwendung dieses Konzepts aber auch der Einfluss des Lehrers und die Beschäftigung der Schüler mit dem Programmieren in der Freizeit wichtige Faktoren sind. Das entwickelte Konzept ist gut geeignet in den objektorientierten Softwareentwurf einzuführen und die Problemlösefähigkeit und die Modellbildungskompetenz im Vergleich zur Kontrollgruppe zu fördern