Auflistung nach Autor:in "Spitta, Thorsten"
1 - 10 von 175
Treffer pro Seite
Sortieroptionen
- Konferenzbeitrag14 Jahre Intranet der Bertelsmann AG – Resümee und Erfolgsfaktoren(Nachhaltiges Software Management, 2012) Weber, Christian; Brandt-Pook, Hans; Krieg, AntoniaDieser Beitrag beleuchtet die Erfolgsfaktoren für den nachhaltigen erfolgreichen Betrieb eines Intranets. Dazu werden zunächst aktuelle Anforderungen an Intranets dargelegt. Es wird vorgeschlagen, diese in die Dimensionen Kern- Intranet, Portal, Suche, Collaboration und Social Intranet zu gliedern. Anschließend werden das Intranet der Bertelsmann AG vorgestellt und seine Entwicklung sowie Erfolgsfaktoren für den nachhaltigen Betrieb beschrieben.
- Konferenzbeitrag2nd collaborative workshop on evolution and maintenance of long-living Systems(EML)(Software-engineering and management 2015, 2015) Heinrich, Robert; Jung, Reiner; Konersmann, Marco; Schmieders, Eric
- Konferenzbeitrag8. Arbeitstagung programmiersprachen (ATPS 2015)(Software-engineering and management 2015, 2015) Grelck, Clemens; Widemann, Baltasar Trancón
- KonferenzbeitragAdvances in quantitative software product line analysis(Software-engineering and management 2015, 2015) Dubslaff, ClemensThe quantitative analysis of software is important, e.g., for energy-aware systems having constraints on energy consumption while guaranteeing a certain degree of utility. Analyzing software product lines is challenging due to the possibly exponential number of feature combinations. This paper sketches new approaches using probabilistic model checking for a quantitative analysis of software product lines and the integration of such into the software development process.
- KonferenzbeitragAktives Portfolio-Management als Wertbeitrag in einem IT-Service Unternehmen(Nachhaltiges Software Management, 2012) Lienau, KarstenDie unterschiedlichsten IT Unternehmen werden am Markt häufig als einheitliche Klasse „IT Unternehmen“ gesehen. Bei genauerer Betrachtung kann eine Unterscheidung in Anbieter von (1) IT-Geräten/Standardsoftware, (2) IT-Projekten und (3) IT-Services getroffen werden. Obwohl es auch Unternehmen gibt, die zwei oder drei dieser Klassen unter einem Firmennamen vereinen, sind diese Unternehmen typischerweise pro Klasse in eigenständige Business Units gegliedert. Diese agieren betriebswirtschaftlich und operativ wie eigenständige Firmen. Betrachtet man die Bedeutung eines aktiven Portfolio- Managements in einem IT Unternehmen, können somit auch Mischunternehmen jeweils nach den o. g. Klassen getrennt betrachtet werden. Im Folgenden sollen IT Unternehmen des Typs (3) betrachtet werden, deren Geschäftsmodell darin besteht, ihren Kunden einen ständig laufenden IT Service zu gewährleisten, der typischerweise über vertraglich geregelte Service Level Agreements (SLA) qualitativ beschrieben ist. Bei IT Unternehmen des Typs (1), die entweder IT- Geräte (wie bspw. Drucker, PCs und Notebooks, Server, Netzwerkrouter) oder Standardsoftware (wie bspw. PC-Betriebssysteme, Office-Anwendungen, ERP-Anwendungen) herstellen, wird der Begriff „Produkt“ unmittelbar intuitiv richtig interpretiert: Das „Produkt“ sind eben solche Geräte oder Software. Im Gegensatz dazu fällt die Begriffsbestimmung des „Produkts“ bei IT-Services nicht so einfach aus. Was ist ein Service, und was ist ein Produkt? Worin bestehen die Unterschiede? Der Schlüssel zur Beantwortung dieser Frage liegt in der Herkunft des Wortes „Produkt“. Jedes Wirtschaftsunternehmen verbindet Material und Arbeitskraft zu einem neuem Wert, dem „Produkt“ seiner Arbeit. Der Wert bei ITService Unternehmen ist aber genau der IT-Service; somit ist in diesem Umfeld der Begriff Produkt synonym zum Begriff Service zu sehen. Gleichzeitig verbindet man mit dem Begriff Produkt eine Reproduzierbarkeit, d.h. eine wiederholte Nutzbarkeit einer gleichen Sache. Gerade im IT Service Geschäft waren die Anfänge der Branche meist durch Projekte geprägt. Diese zeichnen sich durch eine konkrete Anforderung eines Unternehmens an die IT aus, die dann durch eine speziell auf diese Situation zugeschnittene IT Lösung abgedeckt wird. Die Realisierung der IT Lösung erfolgt in einem dedizierten Projekt. Die Wiederverwendbarkeit im Sinne eines standardisierten Produkts ist häufig nicht gegeben. Für ein IT Unternehmen des Typs (3) ergibt sich somit ein Widerspruch, denn das Geschäftsmodell sollten keine Projekte sondern Produkte sein. Der Weg aus dem Projektgeschäft hin zu standardisierten IT Services, also Produkten, beginnt bei den Anforderungen. Werden individuelle Anforderungen an einen IT Service Provider heran getragen, mündet dies regelmäßig in einem individuellen Projekt. Dreht man dies um, also stellt der IT Service Provider die Anforderungen auf und trägt diese zu den Kunden, kann dies standardisiert geschehen und es können in der Tat Produkte etabliert werden, die vielfach produziert und an Kunden verkauft werden. Auf den ersten Blick kommen wir somit aber zu einem naiven Geschäftsmodell: der Dienstleister diktiert die Anforderungen und der Kunde kauft diese. Prinzipiell ist dies richtig, allerdings noch nicht vollständig. Es kommt ein weiterer Aspekt hinzu, der das Produkt- respektive Portfolio-Management bei einem IT Service Provider erst sinnvoll macht: der Vertriebsprozess. Der IT Markt sowie die funktionale Machbarkeit in der IT werden zunehmend komplex und für die Verantwortlichen in einem beliebigen Wirtschaftsunternehmen immer weniger durchschaubar. Mit welchem IT Angebot am Markt werden die Bedarfe des Unternehmens gedeckt? Hier steckt der Ansatzpunkt für den Vertrieb von IT Produkten. Hat der Provider die Kompetenz aufgebaut, den Business Bedarf seiner Kunden zu kennen und zu verstehen, lässt sich ein potentieller Kunde bei seinem individuellen Bedarf adressieren und daraus systematisch eine Lösung ableiten, aufbauend auf vordefinierten und standardisierten Produkten. An dieser Stelle findet die eigentliche Leistung statt: Beim Ableiten der Lösung müssen stets die Produkte im Fokus stehen, ansonsten droht erneut ein individuelles Projekt. Argumentativ muss besonders Wert auf die Zukunftsfähigkeit der Lösung gelegt werden, die umso höher ist, je mehr Marktstandards und -trends berücksichtigt werden. Diese Kompetenz innerhalb des Vertriebs wird häufig als Sales Consulting oder Solution Architecture bezeichnet und stellt die eigentliche Brücke zwischen Serviceerbringung (Herstellung) und Kunde (Nutzung) dar. Zusammenfassend lässt sich feststellen, dass eine strategische und langfristige ServiceEntwicklung im Sinne eines Produkt Managements in einem IT Service Unternehmen nur dann sinnvoll ist, wenn alle Bereiche des Unternehmens, insbesondere die Vertriebsbereiche, Teil dieser Struktur sind. Fehlt diese Integration, bleibt nur noch das Angebot von selbsterklärenden Services, wie man sie meist bei Anbietern von Cloud Services findet, die ihre Produkte über sogenanntes Self Provisioning an die Kunden vertreiben. Hierbei ist das Aufdecken des Kundenbedarfs in Form einer Beratung (Sales Consulting) nicht ausschlaggebend. Anders formuliert stellt sich der Wertbeitrag eines aktiven Produkt oder Portfolio Managements für das IT-Service Unternehmen primär durch das operative Einhalten des strategischen Wegs des Unternehmens dar. Ein nicht intendiertes Abgleiten sowohl zum Projektgeschäft als auch zum Cloud Anbieter wird effektiv verhindert. Aspekte wie Kosten/Nutzen oder Qualität können vielmehr als sekundär betrachtet werden.
- KonferenzbeitragAnalyse der sozialen teamstruktur in softwareprojekten(Software-engineering and management 2015, 2015) Meißner, Johannes; Schulz, Frederik; Rossak, WilhelmUm den organisatorischen Kontext von Softwareentwicklungsprojekten abzubilden, haben wir das Goal-orientierte OrCA-Framework entworfen. Damit lassen sich die Abhängigkeiten zwischen Projektbeteiligten, ihren Beiträgen zur Umsetzung sowie den Ergebnissen ihrer Arbeit modellieren. Durch die Integration von OrCA mit dem Teamrollenkonzept von Belbin reichern wir diese Modelle mit Informationen zu persönlichen und sozialen Charakteristika der Projektbeteiligten an. Diese Arbeit zeigt, wie wir diese Modelle formalisieren, um eine Grundlage für eine automatische Analyse der Qualität der Teamzusammenstellung unter sozialen Aspekten zu schaffen.
- KonferenzbeitragAnalysis strategies for software product lines: A classification and survey(Software-engineering and management 2015, 2015) Thüm, Thomas; Apel, Sven; Kästner, Christian; Schaefer, Ina; Saake, GunterSoftware-product-line engineering enables the efficient development of similar software products. Instead of developing each product from scratch, products are generated from common artifacts. However, the product generation is a challenge for the analysis of correctness properties. Applying traditional analysis techniques, such as type checking and model checking, to each product involves redundant effort and is often not feasible due to the combinatorial explosion of products. Approaches to scale analysis techniques to product lines have been presented in unrelated research
- ZeitschriftenartikelApproaches to the Ex-ante Evaluation of Investments into Information Systems(Wirtschaftsinformatik: Vol. 46, No. 3, 2004) Walter, Sascha G.; Spitta, ThorstenThis paper critically reviews approaches for the evaluation of investments in information systems prior to their implementation. First, the ground for the review is prepared by examining characteristics of evaluation, information systems and value. A classification of the numerous evaluation approaches identified in English and German literature is then presented. Examples of each class are reviewed and their advantages and drawbacks are discussed. Their use in evaluation practice is analyzed through the examination of empirical studies and directions for future research are given.
- KonferenzbeitragArchitecture challenges for internal software ecosystems: A large-scale industry case study(Software-engineering and management 2015, 2015) Schultis, Klaus-Benedikt; Elsner, Christoph; Lohmann, DanielThe idea of software ecosystems encourages organizations to open software projects for external businesses, governing the cross-organizational development by architectural and other measures. Even within a single organization, this paradigm can be of high value for large-scale decentralized software projects that involve various internal, yet self-contained organizational units. However, this intra-organizational decentralization causes architecture challenges that must be understood to reason about suitable architectural measures. In our FSE paper, we present an in-depth case study on collaboration and architecture challenges in two of these large-scale software projects at Siemens. We performed a total of 46 hours of semi-structured interviews with 17 leading software architects from all involved organizational units. Our major findings are: (1) three collaboration models on a continuum that ranges from high to low coupling, (2) a classification of architecture challenges, together with (3) a qualitative and quantitative exposure of recurring issues along each collaboration model. We identified compliant software development as the core challenge. It targets cross-cutting regulations and architecture governance to assist and check for compliance. In addition to our study results, we outline a framework along with tool support that allows to manage these regulations and their violations throughout the life cycle. Internal Software Ecosystems We have investigated two large-scale software projects (about 500 and 950 developers) within Siemens [SEL14]. These projects involve a set of internal organizational units that are self-contained profit centers with own business objectives, organizational independent with own product management, and have to a wide extent autonomous processes and software-engineering life cycles. Thus, the view on the organizational structure moves from strict hierarchies towards more decentralized topologies. We define those systems as internal software ecosystems (ISECOs) [SEL14]. ISECOs comprise a keystone organizational unit that provides a platform and multiple client organizational units that build applications upon it. The keystone acts in a creative role but does not have power to direct. Our talk is laid out as follows: First, we outline our study results. Second, we present our current work, a framework that addresses the compliant software development challenge. 114 Case Study Results:
- KonferenzbeitragArchitekturerkennung aus Quellcode? - Möglichkeiten und Grenzen anhand einer Fallstudie(Software management 2004, Outsourcing and integration, 2004) Teßmer, Meik; Spitta, ThorstenThe source code is the only really true structure in a software system's life cycle, let it be excellent or poor. Its structure-in-the-large, the architecture, is its most important technical artefact. Programming languages have no syntactical elements to express architectural structures like components or connections. Therefore architectural recovery is one of the most interesting topics in the reengineering area. The source code is parsed to find different views of the architecture in order to judge its maintainability. That's why architectural recovery is a very important topic also for software management purposes. We investigated a large component of a 1 million lines C++ system, which is in operation since 1,5 years. We show what can be detected in the code and how it can be done under real life conditions.