ITP Merged

Management of
Machine Learning Products
Dr. Adrian Engelbrecht

27.06.2023
500+
Employees
1000+
Customers
20+ 81
Million
Years of
Experience Revenue
14
Offices
22
Agenda
› Goals of B2B Software Vendors

› Essentials of Product Management
› Management of Machine Learning Products
Vorschlag Alex
3
Goals of B2B Software Vendors
4
Typical Goals of Software Vendors in B2B Markets
1 3
› Create profits and enable growth by building great products many customers use.
5
Create Profits and Enable Growth …
Create profits and enable growth by building great products many customers use.
› Scalability
› How expensive is it to grow your customer base from X to Y?
› Software mostly comes with fix and only few variable costs
› Customer acquisition & implementation often do not scale that well
› Standards
› Are at the heart of scalability; especially for SaaS offerings
› Do not only concern the product, but also sales, consulting etc.
› Are regularly challenged by individual customer demands
› Lock-In & Expansion
› It’s crucial to keep customers, especially given high acquisition costs
› Lock-in refers to high switching costs for a customer
› It’s often a lot easier to expand business with an existing customer
than acquiring a new one (i.e., up - & and cross-selling)
6
… Building Great Products …
› Products over Projects

› A product is never done. A project has an end and limited budget.
› Products are a lot about the what, projects about the how.
› Products focus on solving problems, projects on delivering in time &
budget.
› Winner takes it all
› The best solution gets most customers, generates most revenues,
invests the most in further development, and improves fastest.
› Demands of different markets can be different.
› Disruptive innovations may break existing circles.
› Open & Connected
› No product stands-alone, there is always an ecosystem around it.
› It’s crucial to understand a product’s role in the ecosystem.
› Options for fast integrations are often required.
7
… Products many Customers use.
› Targets Markets
› Can be defined looking at business problems, personas, business
domains, industries, regions, and org. sizes
› Goal is to achieve a series of product-market-fits
› Targeting too many markets in parallel can be a huge challenge
› Customizing
› Goal is to adjust a product for company-specific use
› Requires coding or some form of implementation
› Comes with many challenges if not done well (e.g., updates)
› Configuration
› Goal is adjust a product for company-specific use
› Requires no coding; only involves out-of-the-box functionality
› Range of options often can be changed by provider
8
Typical Goals of Software Vendors in B2B Markets
Scalability Target Markets

Standards Customizing
Lock-In & Expansion Configuration
› Create profits and enable growth by building great products many customers use.
Products over Projects

Winner takes it all
Open & Connected
9
The Essentials of
Product Management
10
Expectations & Reality
https://twitter.com/onek2go/status/714059284049428480
11
Project Management vs. Product Management
While product and project management share many activities, there are also major differences:
Product Management Project Management

› A product is never done › A project has an estimated end and budget
› Work on a problem space › Work on a (more or less) clear goal
› Define what has to be done › Define & oversee how things get done
› Focus on solving business problems › Focus on delivering in time, budget and quality
12
Basics on Product Management
› In product management, there are two

inconvenient truths:
› Half of our ideas are not going to work.
„Teams fall in love with
› For the other half, it takes several iterations to the solution too early.
get the implementation of an idea to the point We need to fall in love
where it delivers the necessary business value.
with the problem, not
› The critical question is how an organization deals
with these truths. the solution.“
› However, customer validation often happens way
too late.
Based on Inspired by Marty Cagan (2018)
13
Risks should be tackled up-front
„The most important thing is

› Value Risk: Will the customer buy it? to establish compelling
› Usability Risk: Can users figure out how to use it? value. We can survive for a
› Feasibility Risks: Can our engineers build what we while with usability or
need with the time, skills, technology we have? performance issues, but
› Business viability risk: Does the solution also work without the core value we
for sales, marketing, legal, …? have nothing.“
Based on Inspired by Marty Cagan (2018)
14
Product Discovery & Delivery are Intertwined
Risks are mostly tackled in product discovery, which

is meant to quickly separate the good from the bad
ideas. Product discovery heavily uses mock-ups, click
dummies, and prototypes instead of an actual
product.
In contrast, product delivery is about making a
product so mature that it can be sold and form the
foundation of a business. This involves getting the
right scale, performance, reliability, fault tolerance,
security, privacy, internationalization, localization.
Based on Inspired by Marty Cagan (2018) https://www.gv.com/sprint/
15
Management of ML Products
16
A Short History of AI at Serviceware
Use-Case
› Central vs. Decentral teams Definition
› Developing new vs. Extending existing Products

› OnPrem vs. Cloud Integration Development
› NLP vs. Predictive Planning Organization
& Management
› Use Case specific vs. Generic Products
Marketing &
› Customer-specific Training vs. Out-of-the Box Sales
Integration &
Operation
17
Basics of Machine Learning Products
› Machine learning products are more than just

machine learning models
› Machine learning is 80% software engineering
› “All models are wrong, but some are useful”(1)
› Breaking down model requirements is essential
and helps defining priorities
› In the end, it’s still about solving customer
problems. Be careful: “If your only tool is a
hammer, all your problems start looking like
nails.”
(1) George Box (1987); Empirical Model-Building and Response Surfaces
18
Generative AI revolutionizes our
customer‘s industry
"One big category that I think could be massively affected

[by AI] is customer service. I would say there could be a lot
fewer jobs there relatively soon."
Sam Altman, CEO OpenAI
Source: https://podcasts.apple.com/de/podcast/lex-fridman-podcast/id1434243584
19
Guiding Principles
› Serviceware enables customers to use state-of-the-art models with minimal efforts

› Serviceware is investing into flexible infrastructures to adjust to new model releases quickly and seamlessly integrate
customer data
› Serviceware is not building foundational language models, but making it easy to apply them effectively (incl. data pre- &
postprocessing, prompt engineering, and feedback integration)
› Serviceware limits the risks of misinformation created by generative AI through strong context control mechanisms
› Models are prompted to work solely with data provided by Serviceware Knowledge, instead of using “general knowledge”
obtained from the internet
› Customer-specific model training and finetuning become less important, while providing context and setting boundaries
gets more relevance
› Serviceware handles customer data with care, reduces third-party dependencies and looks for optimizing operational costs
› Wherever possible, models are hosted and operated in Serviceware-controlled infrastructures
› When there are no alternatives for accessing state-of-the-art-models, trustworthy third-party vendors with data storage in
EU / Germany are chosen (while data can be anonymized before sending it to third-party-services)
20
Trade-Offs
› General Purpose Models vs. Specific Models

› Self-hosted Models vs. Models via API
› Prompting vs. Fine-Tuning
› Performance vs. Costs vs. Accuracy
› Value-based vs. Cost-based Pricing
https://openai.com/pricing
21
Considerations for Embeddings LLMs into Your Product
How to deal with large amounts of external information?
› Preparation of Semantic Search:
› Combining Data to Feed Your LLM:
https://blog.langchain.dev/tutorial-chatgpt-over-your-data/
22
Contact Deflection Widget
Business value: Reduces volume of incoming service requests and

improves customers satisfaction given less waiting times.
Characteristics:
› Works without customer-specific training
› Incorporates implicit & explicit feedback
› Suggestions can be visualized in different
ways
23
Response Generator (I)
24
Response Generator (III)
25
Allowing Customers to Use LLMs in Workflows
AI Service-Tasks – Example: Sentiment Analysis
› The prompt template can be configured in the background, allowing customers to use LLMs in various ways.
› Through integration in a workflow, LLMs can be used multiple times and combined with other BPMN elements.
26
It’s not just the Products that change…
› Coding becomes more efficient „AI will probably most likely

› Team Sizes & Structures adjust lead to the end of the world,
› Thinking & Judgement change but in the meantime, there'll
› … be great companies.“
(Sam Altman,
CEO at OpenAI)
Based on https://www.svpg.com/preparing-for-the-future/
27
Thank you!
www.serviceware.de
“Moderne Software-Entwicklung ...
Wird Projektmanagement
überflüssig?”
Danilo Suntal
Senior Director IT
Agile & DevOps Solution and PMO
WE ARE P&G
A COMPANY OF
LEADING BRANDS
65 80.2 MM 5B
CONSUMERS
LEADING NET USE OUR
BRANDS SALES BRANDS
180
COUNTRIES
>145
NATIONALITIES
40%
WOMEN
SELL OUR MAKE UP OUR AND
BRANDS WORKFORCE GROWING
Who are you?
4
8
9
Project Management constraints
11
What is project success?
12
But what about
13
14
15
20
The (Digital) Product
22
The Product?
23
The Product?!
24
“A product is a vehicle to deliver value. It has a
clear boundary, known stakeholders, well-
defined users or customers. A product could be
a service, a physical product, or something
more abstract.” – scrum.org
25
Scope
28
29
Agile Product Management
better than
(Waterfall) Project Management?
Agile Project Management?!
Traditional Agile
(Waterfall) (Scrum)
Cost Time
Scope
Quality
Quality
Cost Time
Scope
One more thing ...
33
DEVOPS – 3 WAYS
Phase 1: Phase 2: Phase 3:

THE FIRST WAY THE SECOND WAY THE THIRD WAY
Flow Feedback Continuous Experimentation and
Learning
DEV OPS DEV OPS DEV OPS

37
Outcome
Deliver Value Faster, Safer, Happier
38
Input Output Outcome
Product Agile CI/CD DORA metrics Deliver Value
Faster,
Management Incremental Value Software Safer,
Delivery Development Happier
Product Definition Automation
& Team
39
40
41
Today: Project – Product
Tomorrow: Project - Product

Questions?
44
45
AGILE VS. TRADITIONAL
IT-PROJEKTMANAGEMENT | WILLKOMMEN
MANAGEMENT VON SOFTWARE-

UND DIGITALPROJEKTEN
11.04.2023 FB01 | Software & Digital Business | Dr. rer. pol. Timo Koppe 1
ORGANISATORISCHES
VORLESUNG UND PRÜFUNG
Vorlesung Sprechstunde
Dienstag, 13:30 bis 15:00 Uhr Vereinbarung per E-Mail:
koppe@is.tu-darmstadt.de
Freitag,
11:40 bis 13
:20
S 103 / 123 Ankündigungen

Moodle-Forum
Dozent Prüfung
Dr. rer. pol. Timo Koppe voraussichtlich 26. Juli 2023
Inhalte aus VL, Übung und Gastvorträgen
ORGANISATORISCHES
VORLESUNG UND PRÜFUNG

Veranstaltungsmanagement TUCaN
https://www.tucan.tu-darmstadt.de
Anmeldung zur Vorlesung und Klausur

Bzgl. IT-Praktikum WS23/24: Anmeldung für das Modul zum Sommersemester notwendig
Freitag,
11:40 bis 13:
Lernplattform Moodle 20
https://moodle.tu-darmstadt.de/
Folien zur Vorlesung & Übungsaufgaben, Ergänzende Literatur, Informationen und Forum zur
Veranstaltung
Linkedin
https://www.linkedin.com/in/dr-timo-koppe-759a0a124/
ORGANISATORISCHES
ZIELSETZUNG DER
LEHRVERANSTALTUNG
Wir sind in der Lage…
• Grundlagen der Wirtschaftsinformatik in den Bereichen

Anforderungsmanagement, Software-Entwicklungswerkzeuge und
Software-Qualität zu erklären und anzuwenden,
• Aufgaben und Prozesse des Managements von Software- und
Digitalprojekten zu erklären und praktizieren,
• ausgewählter Technologien zur Web- und Cloud-Entwicklung zu
implementieren,
• Besonderheiten von Software- und Digitalprojekten in der Praxis zu
erkennen und erklären.
ORGANISATORISCHES
AUFBAU DER VERANSTALTUNG
1 Einführung in das Management von Software-

und Digitalprojekten
6 Agile Methoden im IT Praktikum
2 Grundlagen Informationssysteme und 7 Software Development - Praktiken, Tools,
3 8
Anwendungssystemen Testing
IT Organisationen und Betriebswirtschaftliche Software Development - Build, Operate und
4 9
Anwendungssysteme Cloud Platformen
Projektmanagement von Software- und Management von Software- und

Digitalprojekten Digitalprojekten in der Praxis
5 Agiles Projektmanagement 10 Software Development - Datenhaltung und

Datenmanagement
IT-PROJEKTMANAGEMENT | MANAGEMENT VON SOFTWARE- UND DIGITALPROJEKTEN
EINFÜHRUNG IN DAS
MANAGEMENT VON SOFTWARE-
UND DIGITALPROJEKTEN
EINFÜHRUNG
ZIELSETZUNG DER HEUTIGEN

LEHRVERANSTALTUNG
• eine Einordnung und Erläuterung des Begriffs "Projekt" geben zu können,

• Aufgaben und Funktion des (IT-)Projektmanagements benennen,
• einen Überblick über verschiedene Vorgehensmodelle im
Projektmanagement geben.
EINFÜHRUNG
SOFTWARE- UND
DIGITALPROJEKTE
Software durchdringt seit Jahrzehnten immer mehr
Produkte und Prozesse in Unternehmen.
Software birgt aufgrund ihrer Immaterialität,

Komplexität und hohen Anforderungsdynamik
projektspezifische Herausforderungen.
EINFÜHRUNG
SCALING AGILE @
SPOTIFY
Source: Kniberg, H., & Ivarsson, A. (2012). Scaling agile@ spotify. online], UCVOF, ucvox. files.
EINFÜHRUNG
PROJEKT - DEFINITION
Ein Projekt ist eine zeitlich begrenzte Zusammenstellung von Ressourcen zur Lösung eines
einmaligen Problems. Projekte gibt es in verschiedenen Größen und Arten.
• Projekte haben spezifische Ziele.
• Projekte müssen innerhalb eines bestimmten Zeitraums abgeschlossen werden.
• Projekte sind an ein bestimmtes Budget gebunden.
• Eigene Organisation (temporär) - Die Zuweisung von Mitarbeitern zu einem Projektteam kann je
nach den spezifischen Anforderungen des Projekts in Vollzeit und/oder Teilzeit erfolgen.
• Projekte sind einmalig. Auch wenn der Grad der Einzigartigkeit von Projekt zu Projekt variieren
kann, sind alle Projekte im Wesentlichen einmalige, nicht wiederkehrende Unternehmungen.
Definition IT-Projekt: Gegenstand ist die Entwicklung, Einführung oder Änderung eines IT-Systems.
EINFÜHRUNG
PROJEKT - BEISPIELE
Welche der folgenden Beispiele sind Projekte?

(Welche nicht und weshalb?)
Betreuung der Kunden eines Marktsegments

Erstellen einer Bachelorarbeit
IT-Integration bei Mergers & Acquisitions-Projekten
Bereitstellung und Betrieb von Office 365 durch MS
Umzug von einer Wohnung in einer andere
Instandhaltung Flugzeug-Flotte
Erstellung einer Massenemail-Versandt-Software
Verwaltung einer Immobilie

Einführung einer betrieblichen Standardsoftware, wie etwa SAP S/4HANA
Verwaltung einer Menge von Aktien
EINFÜHRUNG
PROJEKT - BEISPIELE
Welche der folgenden Beispiele sind Projekte?

(Welche nicht und weshalb?)
Projekt Portfolio-Management Service
IT-Integration bei Mergers & Acquisitions- Betreuung der Kunden eines Verwaltung einer Immobilie
Projekten Marktsegments
Umzug von einer Wohnung in eine andere Verwaltung einer Menge von Aktien Bereitstellung und Betrieb von Office 365
durch MS
Erstellung einer Massenemail-Versandt- Instandhaltung einer Flugzeugflotte
Software
Einführung einer betrieblichen

Standardsoftware, wie etwa SAP S/4HANA
Erstellen einer Bachelorarbeit
EINFÜHRUNG
PROJEKTKONTEXT - DEFINITION
Programm
Ein Programm ist eine Menge von miteinander in Beziehung stehenden

Projekten und / oder Programmen,
die in abgestimmter Weise gemanagt werden,
um Ergebnisse oder Leistungen zu erbringen, die so ohne ein koordiniertes
Management nicht erbracht werden könnten.
Portfolio
Ein Portfolio ist eine Menge von Projekten und / oder Programmen und
sonstiger Arbeit,
die in abgestimmter Weise gemanagt werden,
um Vorteile und Steuerung im Sinne der strategischen Geschäftsziele zu
erreichen.
EINFÜHRUNG
PROJEKTKONTEXT - DEFINITION
Produkt
k te,
r odu en?
Ergebnis der Produktion und Sachziel einer Unternehmung oder
h P nz
auch Mittel der Bedürfnisbefriedigung. s i bgre
c
n
s se kte a
a
i e l Proje
W
n g: und
u s
Service Üb rvice
Se
Eine Möglichkeit, einen Mehrwert für Kunden zu erbringen, indem
das Erreichen der von den Kunden angestrebten Ergebnisse
erleichtert oder gefördert wird. Dabei müssen die Kunden selbst
keine Verantwortung für bestimmte Kosten und Risiken tragen
EINFÜHRUNG
PRODUCT-SERVICE SYSTEM AM
BEISPIEL VON MASCHINEN
Servitisierung Rolle des
Stufen Dienstleistungen Eigentum
Herstellers
Produkt Anbieter
1) Reine Maschine mit obligatorischen Dienstleistungen
Servitisierung
Integration
2) ausgerichtetes Vertikale Integration z.B.: Transport, Schulung und Inbetriebnahme
PSS
Beim Kunden
Produkt Services mit direkten Bezug 3.1) Ersatzteile und
Lösungs Anbieter
3) ausgerichtetes zum Produkt Reparatur
PSS z.B. Beratung und Wartung
3.2) Finanzierung, Sales und
Leaseback „Jet-Engine-as-a-service"
Service
Zusätzliche Mehrwertdienste werden als integraler Bestandteil des
4) ausgerichtetes
Angebots angeboten z.B.: Health Usage Monitoring Services
PSS
Performance Provider
Nutzungs
Fokus auf Services, inkl. SLAs (z.B.
Beim Provider
5) ausgerichtetes
Verfügbarkeitsgarantien) und nutzungsabhängige
PSS Berechnung
Ergebnis
Berechnung des Ergebnisses des PSS inkl. z.B. dem Betrieb, Hilfs- und
6) ausgerichtetes
Betriebsstoffe und Fokus auf dem Nutzungswert
PSS
eigene Darstellung nach Vgl. Gebauer; Fleisch; Friedli (2005); Sachnow et al. (2018); Ziegler;Rossmann (2018)
EINFÜHRUNG
WOFÜR
PROJEKTMANAGEMENT?
EINFÜHRUNG
WAS VERSTEHT MAN UNTER

PROJEKTMANAGEMENT?
Das Projektmanagement ist dafür verantwortlich, dass die Projektziele im Rahmen der
vorgegebenen Funktionalität, Termine und Kosten sowie in der geforderten Qualität erreicht
werden.
Projektmanagement Funktionen
• Projektführung im Sinne von Planung, • Projektführung

Steuerung und Kontrolle eines Projekts • Aufstellen der Projektorganisation
• Institution, welche diese Aufgaben • Vorbereitung eines Projektes
übernimmt • Qualitätssicherung
EINFÜHRUNG
PROJEKTMANAGEMENT
Projektausschuss Aufgaben
• Planung
Führungs- • Steuerung
kreislauf I
• Kontrolle
Projektleiter
Ziele
Führungs-
kreislauf II • Zeit
• Kosten
• Qualität
• Funktionalität
Projektteam
EINFÜHRUNG
STAKEHOLDER
Stakeholder sind Individuen und Organisationen, die entweder aktiv in

einem Projekt beteiligt sind oder deren Interessen durch die
Projektdurchführung und/oder das Projektergebnis tangiert werden.
• Sie haben Einfluss auf die Projektziele und -ergebnisse
• Das Projektmanagementteam sollte die Anforderungen und Erwartungen der

Stakeholder identifizieren und berücksichtigen und möglichst ihren Einfluss
steuern.
EINFÜHRUNG
STAKEHOLDER
Stakeholder in Projekten
Projekt- Beteiligte Projekt-

manager Kunde Organisation mitarbeiter
Projekt- Project
management- Beeinflusser Management Sponsor
team Office (PMO)
Öffentlichkeit Politik Betriebsrat ...
EINFÜHRUNG
ROLLEN IM IT-PROJEKTTEAM
PROJEKTLEITER SOFTWAREARCHITEKT
• Projektplanung und -kontrolle • Analyse und Design
• Aufgabenverteilung, Koordination des • Gestaltung der Softwarearchitektur
Projektteams • DV-Konzept
• Verantwortlich für Projektdokumentation
ENTWICKLER
QM-BEAUFTRAGTER
• Versionsmanagement TESTER
• Änderungsmanagement
• Programmierrichtlinien, Quellcode- UI-DESIGNER
Dokumentation
SYSTEMANALYTIKER
• Ermittlung der Kundenanforderungen
• Fachkonzept
EINFÜHRUNG
PROBLEME BEI IT-PROJEKTEN
Viele IT-Projekte werden nicht erfolgreich abgeschlossen
Nach einer Studie in 2011 wurde bei…
… 56% der IT-Projekte der erhoffte End-Nutzen nicht erzielt.
… 75% der IT-Projekte der Kostenplan überstiegen.
… 55% der IT-Projekte der geplante Zeitrahmen nicht eingehalten
(Universität Oxford und McKinsey 2011)
EINFÜHRUNG
SPANNUNGSFELD BEI IT-

PROJEKTEN
“Teufelsquadrat des Projektmanagements”
Leistung/ Funktionalität
+ Gute
Kundenbeziehung
Zeit (Termine)
+ + Projektressourcen
(Kosten)
+
Qualität
EINFÜHRUNG
VORGEHENSMODELLE
EINFÜHRUNG
ABLAUF VON PROJEKTEN
Projekte werden häufig in Phasen gegliedert, um die Komplexität des

Projektmanagements zu reduzieren
Ausführung & Projektabnahme

Projekt Konzeption Planung
Steuerung
und -abschluss
EINFÜHRUNG
Ausführung
Projekte werden häufig in Phasen gegliedert, um die Komplexität des & Projektabnahme
Projekt Konzeption
Projektmanagements zu reduzieren Planung
Steuerung
und -abschluss
• Bedürfnisse ermitteln • Pläne vorbereiten • Arbeit durchführen • Verantwortung übertragen

• Festlegen von Zielen • Budget erstellen • Material beschaffen • Ressourcen freigeben
• Machbarkeit bestimmen • Zeitplan erstellen • Build and test • Teammitglieder übertragen
• Vorschlag vorbereiten • Projektteam • Verify performance • Mitarbeiter auszeichnen
• Schätzung von Zeit und zusammenstellen • Modify as required • Bewertung durchführen
Ressourcen (grob) • Prototypen bauen und
• Identifizierung von testen
Schlüsselpersonen • Genehmigung für die
• Genehmigung einholen nächste Phase einholen
EINFÜHRUNG
VORGEHENSMODELLE
Ein Vorgehensmodell ist eine planvolle, systematische Beschreibung der

einzelnen Schritte des Entwicklungsprozesses. Die einzelnen Prozessschritte
sind dabei in einer Folge angeordnet, aufeinander aufbauend und fest definiert.
Vgl. Ruf/Wittkau (2008), S. 25.
§ Fragestellung: „Was ist wann zu tun?“
§ Ziele:
§ Entwicklungsstufen systematisieren und strukturieren, um das Projekt
transparent, plan- und überprüfbar zu gestalten
§ Komplexitätsreduktion, das Entwicklungsprojekt wird überschaubarer
EINFÜHRUNG
ÜBERBLICK VORGEHENSMODELLE
• Kein standardisiertes Vorgehensmodell für alle IT-Projekte

• Innerhalb eines Unternehmens kann ein einheitliches Modell verwendet
werden, welches jedoch an Projektspezifika angepasst werden muss
Grundmodelle:
Agile
Sequentielle Vorgehensmodelle
Vorgehensmodelle
(u.a. Scrum)
EINFÜHRUNG
SEQUENTIELLES
VORGEHENSMODELL
Phase
Spezifikation
Entwurf
Implementierung
Integration
Einführung
Zeit Quelle: Eigene Darstellung, in Anlehnung an

Ruf/Fittkau (2008), S. 30.
EINFÜHRUNG
SEQUENTIELLES
VORGEHENSMODELL
Merkmale sequentieller Vorgehensmodelle
§ Die Phasen enden mit einem Phasenprodukt, welches überprüft werden kann
§ Erst wenn eine Phase abgeschlossen wurde, kann die folgende Phase
gestartet werden (Meilensteine)
§ Das Projektergebnis kann gegen die anfangs bei der Spezifikation erstellten
Anforderungen geprüft werden
Voraussetzungen für die Anwendbarkeit sequentieller Vorgehensmodelle

§ Das Projektergebnis lässt sich durch relativ fixe Anforderungen beschreiben
§ Änderungen der Anforderungen während des Projekts sind nicht zu erwarten
EINFÜHRUNG
DAS WASSERFALLMODELL
System
Requirements
Das ursprüngliche Wasserfallmodell von Royce
Software
Requirements
(1970): Prüfung der Phasenergebnisse und
Rückkopplungen zu vorherigen Phasen
Analysis
Program
Design
Coding
Testing
Operations
Quelle: Royce, W. (1970): Managing the Development of Large Software Systems.
EINFÜHRUNG
PHASENERGEBNISSE IM
WASSERFALLMODELL
1. System 2. Software 3. Analysis: 4. Program 5. Coding: 6. Testing: 7. Operations:

Requirements: Requirements: Entwurf der Design: Implementierter Verifikation des Installiertes System
Lastenheft Pflichtenheft Software- Spezifikation Code Programms und Abnahme-
architektur benötigter und bestätigung
Module Testprotokolle
EINFÜHRUNG
PROJEKTPHASEN NACH PRINCE2
Prince2 sieht mehrere Lieferphasen vor. Das Modell ist branchenunabhängig.
Source: https://www.prince2.com/
EINFÜHRUNG
AGILE VORGEHENSMODELLE
§ Entstanden aus Kritik an linear ablaufenden

Vorgehensweisen
§ Agile Vorgehensmodelle setzen vor allem
auf Flexibilität und Anpassung. Statt
ausführlicher und umfangreicher Planung
zu Beginn eines Projekts werden das
adaptive Planen sowie die schnelle
Abstimmung im Team unterstützt.
§ Verschiedene Ausprägungen: Bspw.
Extreme Programming (XP) und Scrum
Abbildung: Beispiel von Scrum
EINFÜHRUNG
BEISPIEL: VORGEHENSMODELLE IN
DATA SCIENCE PROJEKTE
§ CRISP-DM Modell: Cross-Industry Standard Process for Data
Mining
§ Sechs Phasen als iterativer, zyklischer Prozess: Flexibilität
und kontinuierliche Verbesserung
§ Branchenübergreifende Anwendbarkeit: Anpassungsfähig an
verschiedene Projekte und Organisationen
§ Fördert Zusammenarbeit: Integration von Fach- und Data-
Science-Teams für optimale Ergebnisse
Quelle: https://commons.wikimedia.org/wiki/- File:CRISP-DM_Process_Diagram.png
EINFÜHRUNG
SOFTWARE DEVELOPMENT METHODOLOGIES

PRACTICED WORLDWIDE IN 2022
50% 47%
45%
40% 37%
Share of respondents
34%
35%
28% 29%
30% 26%
25%
20%
15%
10%
5%
0%
ps
an
l
um
l
an
al
al
/F
f
cO
Le
nb
er
cr
um
Se
Ka
at
/S
W
ile
cr
ev
/S
Ag
/D
er
ps
at
O
W
ev
D
Description: In 2022, almost 47 percent of respondents state using a DevOps or DevSecOps method for software development. DevOps is a practice that combines IT operations with software development. Its aim is to provide continuous
delivery by shortening the systems development cycle while ensuring high software quality. Read more
Note(s): Worldwide; February to March, 2021; 4,294 respondents; developers, operations, and security professionals*; *Approximately 50% of respondents are GitLab customers. Respondents hold various job roles, represent several
different [...] Read more
Source(s): GitLab, Statista
EINFÜHRUNG
FRAGEN?
Koppe, Timo
+49 6151 16-25754
timo.koppe@tu-darmstadt.de
S102 245, Hochschulstrasse 1, 64289 Darmstadt
GRUNDLAGEN ZU
INFORMATIONS- UND
ANWENDUNGSSYSTEMEN
RÜCKBLICK
ÜBERBLICK ZUR LETZTEN

VERANSTALTUNG
Stakeholder Programm Produkte
Organisation
Projekt Konzeption Planung Ausführung & Projektabnahme und -
Steuerung abschluss
Projektmanage-
Projekt ment
Projektteam Portfolio Services
GRUNDLAGEN ZU INFORMATIONSSYSTEMEN
Chris Wanstrath
GitHub CEO (2008 – 2018)
Source: https://www.idgconnect.com/article/3578431/github-ceo-the-future-of-coding-is-no-coding-at-all.html

LEHRVERANSTALTUNG
• die Begriffe Anwendungs- und Informationssystem kennen und

voneinander abgrenzen können,
• Typische Aufgaben und Berufsfelder von Wirtschaftsinformatiker_innen
kennen (Exkurs)
• Verschiedene Typen von Software kennen und klassifizieren
können
INFORMATIONSSYSTEME VS.
ANWENDUNGSSYSTEME
Definition: „IKS [Informations- und Kommunikationssysteme] sind soziotechnische Systeme, die menschliche
und maschinelle Komponenten (Teilsysteme) als Aufgabenträger umfassen, die voneinander abhängig sind,
ineinandergreifen und / oder zusammenwirken.“ (König 1994, S.80)
Mensch
Anwendungssoftware
Software-
system
Basissoftware Informations-
system
Anwendungs-
system
Rechner
Hardware-
system
Sonstige technische Einrichtungen
18.04.23 Quelle: Teubner, R. Organisations-und Informationssystemgestaltung, Dt. Univ.-Verl.,FB01

1999. |König, W. Profil
Software der Wirtschaftsinformatik.
& Digital Business | Dr. rer.Ausführungen der Wissenschaftlichen Kommission der Wirtschaftsinformatik, Wirtschaftsinformatik (36:1) 1994.
pol. Timo Koppe 6
Ex
ku
sr
TYPISCHE AUFGABEN VON
WIRTSCHAFTSINFORMATIKER_INNEN
IM UNTERNEHMEN
„Wirtschaftsinformatiker beschäftigen sich mit der Gestaltung, dem

Betrieb und der Nutzung von Systemen der computergestützten
Informationsverarbeitung (IV) in Wirtschaft und Verwaltung und
zunehmend auch im unmittelbaren privaten Lebensumfeld.“
(Mertens et al. 2012)
Ex
ku
r s
AUFGABENGEBIETE VON
WIRTSCHAFTSINFORMATIKER_INNEN
Effizientes
Informations- und Gestaltung von
Anwendungs- Informations- Informations- und
Kommunikations- Anwendungs-
systeme management Kommunikations-
technologien systemen
system
Aufgabengebiete von Wirtschaftsinformatiker_innen
§ Typische Prozesse: Gestaltung von Anwendungssystemen sowie das

Informationsmanagement
§ Befasst sich nur mit Teilaspekten der technologischen Grundlagen
§ Kann das komplette Informations- und Kommunikationssystem des
Unternehmens nicht alleine gestalten Quelle: Mertens et al. (2012), S. 3
G R U N D L A G E N Z U I N F O R M AT I O N S S YS T E M E N
Ex
ku
r s
AUFGABENSPEKTRUM IM BERUF –
BEISPIELE
• Entwicklung, Anpassung und Einführung von Anwendungs- und Kommunikationssystemen
(besonders für betriebswirtschaftliche Problemstellungen)
• Fortentwicklung und Einführung von Organisationskonzepten
• Durchführung theoretischer und angewandter Forschung zur Anwendung der
Informationstechnologie (IT)
• Vertrieb von Hard- und Softwareprodukten und Anwenderunterstützung bei der
Produktplanung
• Gestaltung und Durchführung von Schulungen für die Benutzung betrieblicher
Informationssysteme.
• Wahrnehmen von Führungsaufgaben für IT-Abteilungen, Fachabteilungen, Projekte oder für
IT-Unternehmen und Beratungsfirmen.
• Umstellung auf Cloud-Systeme
Quelle: Mertens et al. (2012), S. 3
BEISPIEL: DER BERUF DES CIO
• CIO (Chief Information Officer) benötigt nicht nur technisches Wissen, sondern auch allgemeine
Management-Fähigkeiten
• Nutzung der IT zur Stärkung der Erfolgspotenziale des Unternehmens sicherstellen
• Bewirtschaftung der Ressource Information
• Verantwortung für unternehmensweite IT-Strategie, IT-Standards, Technologie- und
Architekturentscheidungen, Koordination der IT mit den Fachbereichen sowie Personalführung im IT-
Bereich
• Beratung der Fachbereiche bei Gestaltung von Geschäftsprozessen
• Im Gegensatz zum klassischen IT-Leiter, dessen Aufgaben eher in Richtung Softwareentwicklung

und Rechenzentrumsbetrieb gehen, hat der CIO als Leiter des Information Managements
weitergehende, mehr strategisch geprägte Aufgaben
• Zum Teil auf Vorstandsebene angesiedelt
ZIEL: IT SOLL DIE PRODUKTIVITÄT

STEIGERN
"You can see computers everywhere but

in the productivity statistics" (R. Solow, 1987)
Das Produktivitätsparadoxon der IT: Trotz hoher Investitionen in IT durch

Unternehmen ist keine Steigerung der Produktivität eindeutig messbar
• Zahlreiche Untersuchungen seit 1980er Jahren

• Auf Einzelfirmenebene, Branchen, Ländern
• Erklärungsansätze: Mess- und Methodikschwächen, Zeitversatz zwischen
Investition und Wirkung, langsame Anpassung an Möglichkeiten der Technologie,
u. v. m.
Ex
ku
sr
/B
ei
sp
IT à UNTERNEHMENS-ERFOLG
ie
l
Beispiel zeigt Modell von Potthoff (1998),
wie die Wirkungszusammenhänge des
Einsatzes von IT und dem
Unternehmenserfolg gemessen werden
könnten.
18.04.23 I. Potthoff. 1998. Empirische Studien zumFB01

wirtschaftlichen Erfolg
| Software & Digital der Informationsverarbeitung.
Business | Dr. rer. pol. Timo Koppe Wirtschaftsinformatik. 40(1) 54-65. 12
KLASSIFIZIERUNG VON
SOFTWARE
KLASSIFIZIERUNG VON SOFTWARE
Software
i.d.R. Standardsoftware
Anwendungs-
Systemsoftware software
Betriebssysteme
Standardsoftware Individualsoftware
Übersetzungs-
programme
Basissoftware
Dienstprogramme
Standardbürosoftware
Protokolle und Treiber
Funktions- und prozessorientierte

Software
BETRIEBSSYSTEM
(OPERATING SYSTEM, OS)
Aufgaben
Bereitstellung eines Systems zur Dateiverwaltung
Verwaltung der Hardwarebetriebsmittel (Prozessor, Hauptspeicher, Peripheriegeräte)
Administration der Benutzeraufträge und Überwachung der Programmabläufe
Bereitstellung einer Mensch-Maschine-Schnittstelle (Kommunikation mit dem System)
Eigenschaften moderner Betriebssysteme

Grafische Benutzerschnittstelle (Graphical User Interface – GUI)
Multitasking und Multiusing
Hierarchische Dateiverwaltung
ÜBERSETZUNGSPROGRAMME
1 Lege fest, wie viele Tassen Kaffee gekocht werden
sollen und weise diesen Wert der Variablen
AnzahlTassen zu.
2 Fülle eine AnzahlTassen entsprechende Menge

Wasser in den dafür vorgesehenen Behälter.
3 Stecke einen Kaffeefilter in den dafür vorgesehenen

Behälter.
4 Wenn der Kaffeetrinker ein Informatiker ist, dann

setze die Variable TeelöffelProTasse auf 2, sonst auf
Quellcode / Quelltext
1.
5 Setze die Variable Zähler auf 0.
6 Solange die Variable Zähler kleiner ist als der Wert

AnzahlTassen x TeelöffelProTasse ist, führe folgende
Schritte aus:
• Schritt 6.1: Fülle einen Teelöffel Kaffeepulver in den
Filter
• Schritt 6.2: Erhöhe den Wert von Zähler um 1
7 Schiebe den Kaffeefilter ein.
Compiler / Interpreter 8 Stelle die Kaffemaschine an.
§ Compiler übersetzen das gesamte Quellprogramm „in einem Stück“

§ Interpreter arbeiten jeden Befehl einzeln ab Zeichen ASCII-Code
+ 0010 1011
Programm mit offenen Adressen
0 0011 0000
(noch nicht lauffähig)
1 0011 0001
Linker (Binder): A 0100 0001
§ Zur Einbindung von Hilfsprogrammen (z.B. Bibliotheken für die
a 0110 0001
Ein- und Ausgabesteuerung)
§ Umwandlung der symbolischen Adressen der Funktionen und
Variablen in konkrete Speicheradressen
10110001 10101010 11110010 00101100

Fertiger Objektcode 00101101 11010110 10100101 01011110
10110001 10101010 11110010 00101100
DIENSTPROGRAMME UND TREIBER
Dienstprogramme
• Ermöglichen die Abwicklung systemorientierter, anwendungsneutraler Aufgaben
• Beispiele: Sortierprogramme, Suchprogramme (Hilfsprogramme), Kopieren von Dateien,
Datensicherung, Optimierung der Speicherorganisation
Treiber
• Programme, die als Übersetzer zwischen Protokollen verschiedener Funktionseinheiten
bzw. zwischen Programmen und Funktionseinheiten agieren
• Beispiele: Druckertreiber, Grafikkartentreiber, Webcamtreiber
KLASSIFIZIERUNG VON SOFTWARE
Software
i.d.R. Standardsoftware
Anwendungs-
Systemsoftware software
Betriebssysteme
Standardsoftware Individualsoftware
Übersetzungs-
programme
Basissoftware
Dienstprogramme
Standardbürosoftware
Protokolle und Treiber
Funktions- und prozessorientierte

Software
STANDARDSOFTWARE
Standardsoftware umfasst Produkte, die für den Massenmarkt konzipiert wurden.
Basissoftware
• Stellt Funktionalitäten zur Verfügung, die unabhängig von spezifischen Arbeitsgebieten genutzt
werden
• Beispiele: E-Mail, Termin- und Adressverwaltung, Browser, Virenscanner,
Komprimierungsprogramme (ersetzen Sequenzen von Nullen)
Bürosoftware
• „Die Grundlage des Erfolgs der PCs“
• Beispiele: Textverarbeitung (Schreiben und Formatieren von Texten), Bildbearbeitungssoftware,
Tabellenkalkulationsprogramme, Editoren für Webseiten, …
Funktions- und prozessorientierte Software
• Unterstützung eines Anwendungsbereichs und seiner Prozesse
• Anwendungsbereichsübergreifende Unterstützung der Prozesse (horizontal oder vertikal)
INDIVIDUALSOFTWARE
Für eine spezielle Betriebliche Anforderung

• Sowohl die Hard- als auch die Softwareumgebung kann individuell angefertigt sein
• Individualsoftware wird entweder eigenentwickelt oder fremdbezogen.
• Eigenentwicklung kann sowohl von der IT-Abteilung als auch von den
entsprechenden Fachabteilungen durchgeführt werden. Entwicklung muss technisch
und finanziell zu beherrschen sein.
• Individualsoftware wird häufig eingesetzt, um Prozesse zu steuern, mit welchen ein
unternehmen Wettbewerbsvorteile erzielt.
BEWERTUNG DES EINSATZES VON

STANDARDSOFTWARE
Vorteile Standardsoftware Nachteile Standardsoftware
Diskrepanz zwischen Programmabläufen
Lizenz- und Einführungskosten meist
und betrieblichen Anforderungen /
geringer als Kosten einer Individuallösung
Prozessen
Customizing nur begrenzt möglich und
Verfügbarkeit / kurze Einführungsdauer
oftmals kostenintensiv
Reifegrad Kein Wettbewerbsvorteil
Erwerb von externem
betriebswirtschaftlichem und Abhängigkeit vom Hersteller
organisatorischem Know-how
In manchen Branchen/Situationen erfüllen
Schonung eigener SW-Entwicklungs- Standardsoftware und Erweiterungen
Ressourcen besondere Sicherheits- oder Compliance-
Anforderungen nicht
KOMPONENTENARCHITEKTUREN
Die zunehmende Modularisierung von Anwendungsprogramm lässt die Grenzen

zwischen Individual- und Standardsoftware schwinden:
• Komponentenbasierte Anwendungsprogramme werden aus einzelnen
Bausteinen individuell zusammengestellt
• Eine Softwarekomponente ist ein Codebaustein mit Softwareschnittstellen,
Attributen (Eigenschaften) und Verhalten (Funktionalitäten)
• Die einzelnen Komponenten sind Standardsoftware, jedoch das resultierende
Anwendungsprogramme nicht mehr
• Integration der Komponenten zu Anwendungsprogrammen erfolgt in
Komponentenarchitekturen. Diese bieten in der Regel
• Plattform als Laufzeitumgebung,
• Weitere Bestandteile: Sicherheitsmechanismen, Datenbankverbindungen,
Benutzungsschnittstellen und die Speicherverwaltung
INDIVIDUALISIERUNG MITTELS
ADD-ONS UND APIS
• Große Standardsoftwareanbieter bieten inzwischen häufig integrierte
Marktplätze mit Add-ons und Plugins an, um ihre Software einfach zu
erweitern und anzupassen
• Softwareplattformen (wie Betriebssysteme und Webbrowser) sind
erweiterbare Codebasen von Softwaresystemen, die Kernfunktionen für die
darauf laufenden Anwendungen bereitstellen
OPEN SOURCE SOFTWARE
Frei verfügbare Software gibt es schon lange:

• Freeware im privaten Bereich
• Austausch von Quelltexten und Programmen zwischen Programmierer_innen
Unter Open-Source-Software werden Programme verstanden, die insbesondere

die freie Nutzung, Weitergabe und Modifikation der Software bzw. des
Quellcodes erlauben.
Open Source ist sowohl eine Entwicklungsmethode als auch eine

Lizenzierungsform für Software.
Beispiele: Linux, OpenOffice und viele andere
“VIEL SOFTWARE FÜR WENIG

CODE”
NO-CODE ALS BRÜCKE?
• Laut einer Studie des IT-Analysten Techconsult im

Auftrag von Dr. Eckhardt + Partner setzen 2021
mehr als die Hälfte der deutschen Unternehmen
auf Individualsoftware.
Standardsoftware bedeutet in vielen Fällen
IN
RD „Verzicht auf Funktionalität und Flexibilität“.
SO DIV D A
RE
FT ID N
A W A
W UA ST FT
AR L • „No Code“-Plattformen könnten helfen,
E SO Individualsoftware einfach zu entwickeln, aber auch
bestehende Systeme zu erweitern, zu
individualisieren und leichter in die Infrastruktur zu
integrieren.
• Bis 2025 werden 70 % der neu entwickelten Apps
mit Low-Code- oder No-Code-Technologien
entwickelt (Gartner)
NO-CODE / LOW-CODE
• Beschreiben Softwareentwicklungsumgebungen und Platformen um

die Erstellung von Anwendungen und Softwarelösungen zu
vereinfachen und beschleunigen.
• Mit vorgefertigten Elementen per Drag-and-drop zu individuellen

Applikationen
Microsoft Power Apps
• Im Backend aus getesteten Codeschnipsel sauberer

Anwendungscode
• No-Code erfordert i.d.R. keine Programmierkenntnisse
Appian
NO-CODE PLATTFORMEN
• Schnelle & kostengünstige Entwicklung § Auf Funktionen und Möglichkeiten

von Minimum Viable Products der Plattform beschränkt
• Höhere Individualität und Anpassbarkeit § Nicht geeignet für komplexe
gegenüber Standardsoftware Anwendungsgebiete
• Geringere Abhängigkeit von externen § Abhängigkeit zum No-Code
Dienstleistern Plattformbetreiber
• Bessere Einbindung von Fachexperten & § …
IT-fremden Angestellten durch leichten
Einstieg
• Höhere Innovationsfähigkeit und
Wettbewerbsfähigkeit
• …
FRAGEN?
Koppe, Timo
+49 6151 16-25754
IT-ORGANISATION
RÜCKBLICK

VERANSTALTUNG
Organisation
Steuerung abschluss
Projektmanage-
Projekt ment
IT-ORGANISATION

LEHRVERANSTALTUNG
Wir sind in der Lage… Programm
1. die Grundbegriffe, Aufgaben und Organisation des

Informationsmanagements kennen und erläutern zu können.
2. die Grundbegriffe und Organisationsformen der IT-Organisation kennen
und erklären zu können.
3. die Zentralisierung bzw. Dezentralisierung der IT zu verstehen.
Portfolio
IT-ORGANISATION
ZUKUNFTSFÄHIGE IT-ORGANISATION
Aufgaben d. Klassischen Unternehmens-IT (IT-Abteilung/Corporate IT): Optimale Unterstützung der

Geschäftsprozesse des Unternehmens mit der dafür geeigneten Infrastruktur und passenden
Applikationen
Bedeutung der IT im Wandel

• IT wird zum Kernbestandteil der Produkte und Leistungen (z.B., Kundeninteraktionen und der internen
Prozesse) à strategische Relevanz
• IT-Management muss permanent technologische Veränderungen verfolgen und systematisch bewerten
• Steigende Erwartungen und Anforderungen an die Leistungen der Corporate IT
• Möglichkeiten des Cloud Computing verändern die Betriebsmodelle für die IT
• Zunehmende Vernetzung mit Geschäftspartnern führen zu häufigen und kurzfristigen Veränderungen
in den IT-gestützten Geschäftsprozessen
• Thema IT-Sicherheit erhält eine zentrale Bedeutung
IT-ORGANISATION
IT-ORGANISATION UND
INFORAMTION MANAGEMENT
IT-ORGANISATION
DEFINITIONEN DES BEGRIFFS

„INFORMATION MANAGEMENT“
Definition: Information Management ist das Leitungshandeln (Management) in einer
Organisation in Bezug auf Beschaffung und Bereitstellung von Informationen.
Das generelle Ziel des Information Managements ist es, „im Hinblick auf die Unternehmensziele
den bestmöglichen Einsatz der Ressource Information zu gewährleisten.“ Krcmar (2010), S. 52
Besondere Eigenschaften der Ressource Information:

• Informationen sind immaterielle Güter (kein Verbrauch im materiellen Sinne, günstig
speicherbar und transportierbar)
• Dimensionen d. Informationsqualität: Genauigkeit, Vollständigkeit, Aktualität, Format
Hinweis: Es existieren zahlreiche andere Definitionen des Begriffs „Information Management“
IT-ORGANISATION
AUFGABEN DES INFORMATION

MANAGEMENT (ÜBERBLICK)
Strategische Aufgaben Administrative Aufgaben Operative Aufgaben
Gesamtheit der Informationssysteme sowie deren Nutzung der Informationssysteme
Bezug
Informationssysteme im Komponenten (beinhaltet u. a. und

Unternehmen und das deren Planung und Realisierung) Sicherstellung ihres Betriebs
Unternehmen als Ganzes
• Strategische IT-Zielplanung • Management von IT-Projekten • Betrieb der
Beispiele für Aufgaben
• IT-Strategieentwicklung • Pflege und Weiterentwicklung Informationssysteme

• Strategisches IT- des Bestands von insb. Rechenzentrumsbetrieb
Projektportfolio Informationssystemen • Problemmanagement
• … • Personalmanagement • Benutzer-Service
• Sicherheits- und • …
Katastrophenmanagement
• Vertragsmanagement
• …
24.04.23 In Anlehnung an Heinrich L. Informationsmanagement, (7.

FB01 | Software Aufl.)Business
& Digital Oldenburg,
| Dr. rer.München, 2002. (Seite 22-23 und 34-38)
pol. Timo Koppe 9
IT-ORGANISATION
Ex
ku
sr
BEISPIEL FÜR DIE ORGANISATION
DES IM
Informations-
management
Strategische
IT-Controlling
Planung
Consulting Anwendungen Betrieb
Standardsoftware /
Software- Betriebswirtschaft-
Geschäftsprozesse Rechenzentrum
entwicklung liche
Anwendungen
Customizing und
Organisation Analyse Netzbetrieb
Parametrisierung
Realisierung Dezentrale Server

E-Business Technische Pflege
und Wartung und Endgeräte
Hotline / Hotline /
… Qualitätssicherung
Benutzerservice Benutzerservice
24.04.23 …Business | Dr. rer. pol.

FB01 | Software & Digital … Timo Koppe … 10
IT-ORGANISATION
ALTERNATIVEN: IT-ABTEILUNG IN
DER ORGANISATION
IT-Abteilung
FB: Fachbereich
TB: Teilbereich
Unternehmensleitung
Zentralisation
Finanz- und
FB 1 FB 2 FB 3 Rechnungswesen 2
Dezentralisation
TB 1 3
24.04.23 In Anlehnung an Mertens, P. FB01

u. a. |(2005),
SoftwareS.
& Digital
192 undBusiness | Dr. rer. pol.
Stahlknecht Timo Koppe (2005), S. 448.
/ Hasenkamp 11
IT-ORGANISATION
VOR- UND NACHTEILE VON

ZENTRALEN / DEZENTRALEN
ENTSCHEIDUNGEN
Führungs-
informations-
systeme
Controlling Vertrieb
Finanz- Material-
buchhaltung wirtschaft
Anlagen- Produktions- Informationsflüsse

buchhaltung planung
IT-ORGANISATION
ÜBERBLICK ZU IT-SYSTEMEN IN
INDUSTRIEUNTERNEHMEN CAD Computer Aided Design
Computer Aided Engineering

CAE
ERP
Computer Aided Manufacturing
CAM
FIN Distribution
DIS
DIS PPS Document Management System
DMS
MES Enterprise Resource Planning
ERP
Zulieferer SCM PRODUCTION CRM Kunden Finance
(Kunden) FIN
CAM / NC Manufacturing Execution System
MES
CAM CAD /CAE Numerical Control
NC
PDM Product Data Management
PDM
Product Lifecycle Management
PLM PLM
Production Planning and Scheduling
24.04.23 FB01 | Software & Digital Business | Dr. rer. pol. Timo Koppe
PSS 13
IT-ORGANISATION
ZENTRALISIERUNG ODER
DEZENTRALISIERUNG
Zentrale Lösungen Dezentrale Lösungen
Vorteile: Vorteile:
• Interdependenzen zwischen verschiedenen Bereichen • Größere Flexibilität
können besser berücksichtigt werden • Klare Zuordnung der Verantwortlichkeiten und auch der
• Bessere Möglichkeiten zur systematischen Planung, IT-Kosten
Überwachung und Steuerung • Fachspezifisches Know-How in den einzelnen
• Einfachere Einhaltung von Standards in Bezug auf Abteilungen
Anschaffung, Hardware und Technologieeinführung;
Entwicklung von Anwendungssystemen; Kauf von Ausgestaltung:
Standardsoftware; Schulung; Prozesse • Das Entscheidungsproblem wird in Teilprobleme zerlegt;
die Lösung der Teilprobleme wird an unterschiedlichen
Ausgestaltung: Instanzen übertragen.
• Einzelne Teilaktionen und -aufgaben werden unmittelbar
von einer einzelnen Instanz aufeinander abgestimmt
• Instanz entscheidet simultan über alle Teilprobleme
• Koordination als Totalkalkül
IT-ORGANISATION
IT-KEY ACCOUNT MANAGEMENT
• Key Account Managers als Bindeglied

zwischen den IT-Fachabteilungen und den
internen Unternehmensbereichen bzw.
Gesellschaften
• Ziel: Bedarfe der Unternehmensbereiche nach
IT-Services und IT-Projekten mit interenen
Möglichkeiten und Kapazitäten in Einklang
bringen: IT Demand <> IT Supply
• Für jeden Unternehmenskunden muss ein
verantwortlicher Key Account Manager definiert
sein (Linking Pin-Ansatz)
• Berücksichtigung kundenindividueller Bedarfs-
und Anforderungsstrukturen
24.04.23 Helmke, S. (2013). Managementorientiertes

FB01IT-Controlling
| Software &und
Digital
IT-Governance.
Business | Dr.
M.rer.
Uebel
pol. (Ed.).
Timo Koppe
Springer Fachmedien Wiesbaden. 15
IT-ORGANISATION
IT-KEY ACCOUNT MANAGEMENT
Aufgabenprofil:
• Vertriebsfunktion:
Kunden- und Vertriebsorientierung, Kommunikativ,…
• Betreuungsfunktion:
Kenntnisse über IT-Organisation, Org-Strukturen,…
• Projektbegleitungsfunktion:
IT-PM, Kostenbewusstsein, BWL-/IT-Know How,..
• Trouble Shooting Funktion:
Überzeugungskraft, Konfliktmanagement, …
IT-Ltg.
FB 1 FB 2 FB ... KAM
25.04.23 Helmke, S. (2013). Managementorientiertes

FB01IT-Controlling
| Software &und
Digital
IT-Governance.
Business | Dr.
M.rer.
Uebel
pol. (Ed.).
Timo Koppe
Springer Fachmedien Wiesbaden. 16
IT-ORGANISATION
BIMODAL IT IN UNTERNEHMEN
• IT-Einheit im Unternehmen Weg vom internen

Dienstleister hin zum Wegbereiter für die
Leistungsfähigkeit des Unternehmens
• Neue zentrale Rolle der IT führt dazu, dass sie
schneller und flexibler agieren können muss, während
gleichzeitig kritische IT-Systeme weiterbetrieben
werden müssen
• IT der zwei Geschwindigkeiten bzw. eine bimodale IT
• Traditionelle IT: sichere, zuverlässige und
skalierbare System-Bereitstellung Bild: Haffke, I., Kalgovas, B., Benlian, A.: The Transformative Role of Bimodal IT in an Era of
Digital Business. Hawaii International Conference on System Sciences, 5460–5469 (2017)
• Agile IT: Experimentieren mit neuen Technologien
und digitalen Produkten
IT-ORGANISATION
Ex
ku
sr
HOW TO IMPLEMENT BIG DATA
ANALYTICS – EXAMPLE AUDI
Werkzeuge zur Integration von Daten und Prozessen (Chen et al., 2012)
• Business Intelligence
• Geschäftsanalytik
• Big Data-Analytik
How to implement Big Data analytics – Example AUDI (Dremel et al., 2017)
IT-ORGANISATION
Ex
ku
sr
HOW TO IMPLEMENT BIG DATA
ANALYTICS – EXAMPLE AUDI
Step 1: „Advancing“ Step 2: „Enabling“ Step 3: „Leveraging“
• Einbindung von externen • IT-Abteilung baut intern • Die IT-Abteilung bietet nun
Analysekompetenzen technologische Kompetenzen auf zentral Datenanalyselösungen an
• Intuitive und erfahrungsbasierte • "Datengesteuerte" • Evidenzbasierte und prädiktive
Berichte und beschreibende fortgeschrittene beschreibende Entscheidungsfindung
Analysen Analytik
Quelle: Dremel et al., 2017
IT-ORGANISATION
Ex
ku
sr
VOLVO CARS’ CONNECTED CAR
INITIATIVE
• Um 2010 skizzierte Volvo Cars eine Vision, die Autos über die
Produktionszeit hinaus "Leben" verleihen sollte
• Dies erforderte, dass sich der Automobilhersteller von seinen
konventionellen Praktiken - der strikten Arbeitsteilung und Spezialisierung -
löste, um inkrementelle, komponentenbasierte Innovationen zu fördern.
• Um die digitale Transformation zu bewältigen, müssen Unternehmen neue
Fähigkeiten entwickeln, um neue Ideen in bestehenden institutionellen
Kontexten zu identifizieren (Henfridsson und Yoo, 2014).
Quelle: Svahn, F., Mathiassen, L., & Lindgren, R. (2017). Embracing Digital Innovation in Incumbent Firms. MIS quarterly, 41(1), 239-254.
IT-ORGANISATION
Ex
ku
sr
VOLVO CARS’ CONNECTED CAR
INITIATIVE
1 2
Einrichtung des Innovation Aufbau eines
Hub Plattformportfolios
à Interdisziplinäre Impulse und à Fähigkeit, viele
Innovation Entwickler/Crowd einzubeziehen
3 4
Implementierung der Volvo Partnerschaftsmodell
Cloud
à Fähigkeit, Designräume offen à Fähigkeit, externe Akteure zu
zu halten motivieren
Quelle: Svahn, F., Mathiassen, L., & Lindgren, R. (2017). Embracing Digital Innovation in Incumbent Firms. MIS quarterly, 41(1), 239-254.
FRAGEN?
Koppe, Timo
+49 6151 16-25754
PROJEKTMANAGEMENT VON
SOFTWARE- UND DIGITALPROJEKTEN
PROJEKTMANAGEMENT

LEHRVERANSTALTUNG
• den Ablauf von IT-Projekten und deren Phasen zu kennen und zu verstehen.
Stakeholder
• die Bestandteile eines Projektplans zu verstehen und anzuwenden.
• einen Überblick über Projektdurchführung, -kontrolle und -abschluss geben
zu können.
• das Wasserfallmodell zu erklären.

Steuerung abschluss
Projekt Projektmanage-
ment
Projektteam
PROJEKTMANAGEMENT
PROJEKTMANAGEMENT
W
ie
de
rh
ol
un
g
Projekte werden häufig in Phasen gegliedert, um die Komplexität des
Projektmanagements zu reduzieren

Projekt Konzeption Planung
Steuerung
und -abschluss
PROJEKTMANAGEMENT
PROJEKT KONZEPTION
Projektdefinition aus Ausgangspunkt jedes IT-Projekts

Ziele dieser Phase
• Definition der Aufgaben und Ziele des beabsichtigten IT-Projekts

• Abschätzung der Chancen und Risiken des Projektes
• Abschätzung der möglichen Kosten, Ressourcen (Zeit, Personen, Sachmittel)
• Vorschlag zur Projektorganisation und zum Projektablauf
Die Phase Projektdefinition beinhaltet die Erarbeitung
• eines Projektantrags und

• eines Projektauftrags.
Bei Outsourcing: häufig Ausschreibungen

PROJEKTMANAGEMENT
PROJEKTAUFTRAG - BEISPIEL
Auftraggeber / Sponsor: <Name> / (<Rolle>) Projekt Manager: <Name>

Projektziel Erfolgskriterien
Im Scope Nicht im Scope
Liefergegenstände Vorgehensweise
Budget / Kosten / Aufwand Ressourcen / Organigramm
Risiken Zeitplan
PROJEKTMANAGEMENT
PROJEKTPLANUNG
Projektauftrag als Grundlage für die Projektplanung
Planungsmethoden
• Projektstrukturplan
• Vorgangsliste
• GANTT-Diagramm
• Netzplantechnik
Vorgehens- und Phasenmodelle
• Sequentielle Vorgehensmodelle
• Agile Vorgehensmodelle
PROJEKTMANAGEMENT
PROJEKTPLANUNG - VORGEHEN
Strukturplanung
• Strukturierung in Teilaufgaben und Arbeitspakete
• Detaillierteste Gliederungsebene: Arbeitspakete
Zeitplanung
• Ermittlung frühester und spätester Anfangs- und Endzeitpunkte der einzelnen Arbeitspakete (bzw. früheste
und späteste Eintrittszeitpunkte der Vorgänge) und Bestimmung der Pufferzeiten und kritischen Pfade.
Ressourcen- / Kapazitätsplanung
• Zuordnen von Ressourcen zu den einzelnen Arbeitspaketen
• Planung der Kapazitätsauslastung unter Berücksichtigung vorhandener Kapazitäten und Pufferzeiten
Kostenplanung
• Zuordnen der Einzelkosten zu den Arbeitspaketen
• Ermitteln der Gesamtkosten
PROJEKTMANAGEMENT
PROJEKTSTRUKTURPLAN
Definition nach DIN 69901:
• Ein Projektstrukturplan (PSP) ist die Darstellung der Projektstruktur, d.h. der Gesamtheit der wesentlichen
Beziehungen zwischen den Elementen eines Projekts.
• Diese Darstellung kann nach dem Aufbau (Aufbaustruktur), nach dem Ablauf (Ablaufstruktur), nach den
Grundbedingungen (Grundstruktur) oder nach sonstigen Gesichtspunkten (z.B. Mischformen) erfolgen.
• hiernach würden auch Netzpläne und GANTT-Diagramme als Projektstrukturplan angesehen werden.
Übliche Definition in der Praxis:

• Ein PSP ist die vollständige hierarchische Anordnung aller Elemente eines Projekts.
Darstellungsformen:
• Organigramm (am häufigsten verwendet)
• Listendarstellung
• Mind Map
PROJEKTMANAGEMENT
BEISPIEL FÜR EINEN

PROJEKTSTRUKTURPLAN (PSP)
SAP-Einführung
Business Blueprint Produktions- Go-Live und

Projektvorbereitung Realisierung
(Sollkonzept) vorbereitung Support
Definition der Schulung des

Customizing Qualitätsprüfung Abnahmetest
Systemlandschaft Projektteams
Definition der Einrichten der Dokumentation Produktiv-

Systemtest setzung
Schnittstellen Testumgebung der Einstellungen
Ermittlung der Festlegen der Einrichtung des Optimierung

Unternehmens- Berechtigungen Produktivsystems
anforderungen
Erstellen der
Abbilden der Benutzer- Benutzerschulung Support
Unternehmens- dokumentation
struktur
Planung der
Implementierung
PROJEKTMANAGEMENT
VORGEHENSPLANUNG
Projektstrukturplan 1) Vorgangsliste
2) Netzplan
AP AP Zeit-, Ressourcen-
und Kostenplan
AP AP
Arbeitspaket (AP)
Name Verantwortlichkeiten
3) GANTT-Diagram
Beschreibung Ziele
Beginn Ende
Risiken Ressourcen
Aufwand (PT) Kosten (€)
…
PROJEKTMANAGEMENT
VORGEHENSPLANUNG
2) Netzplan
und Kostenplan
AP AP
Arbeitspaket (AP)
3) GANTT-Diagram
Beschreibung Ziele
Beginn Ende
Risiken Ressourcen
…
PROJEKTMANAGEMENT
VORGANGSLISTE
Eine Vorgangsliste ist eine tabellarische Aufzählung von Vorgängen in einem Projekt und deren
Anordnungsbeziehungen.
Neben Vorgängen, Meilensteinen und Anordnungsbeziehungen können weitere wichtige Informationen

aufgenommen werden, beispielsweise
• Dauer des Vorgangs
• Angaben über Kosten
• Benötigte Arbeitskräfte
• …
Wichtige Angaben über das Projekt enthält der Listenkopf
• Projektbeschreibung
• Auftraggeber
• Verantwortlicher Projektleiter
PROJEKTMANAGEMENT
VORGANGSLISTE – BEISPIEL
Tabellenkopf einer Vorgangsliste
Vorgangsliste
Projekt: Nr.: Auftraggeber:

Teilprojekt: TP 4 Arbeitspaket: AP 2 Erstellungsdatum: 11.04.2023
Arbeitskräftebedarf
Vorgangs- Kosten- Kosten der Abteilungen:
Nr. Dauer
beschreibung stelle in Euro
I II III IV
0101 Requirements 132 2 2800 1
0102 Studie 125/147 1 4200 1 2
0200 Systementwurf 147 4 5600 2
... ... ... ... ... ... ... ... ...
PROJEKTMANAGEMENT
VORGANGSLISTE – BEISPIEL
Nr. Tätigkeit Dauer in Tagen Vorgänger

1 Projektformulierung 3 --
2 Konzept erstellen 10 1
3 Daten sammeln 12 1
4 Programmieren 14 2
5 Test 4 3, 4
6 Schulung 10 2
7 Systemeinführung 5 5, 6
PROJEKTMANAGEMENT
DETAILLIERUNGSGRAD DER
VORGANGSLISTE
Wie „groß“ sollte ein Vorgang gewählt werden?
• Eine zu detaillierte Planung kann zu einer aufwändigen und schwerfälligen Planung, Steuerung und Kontrolle
führen (Widerstände bei Mitarbeitern aufgrund von unzumutbaren Kontrollen; wenig Flexibilität)
• Ein zu grober Plan kann zu Problemen bei der Projektdurchführung, -koordination und Abstimmung führen
Faustregeln zur Bestimmung des Detaillierungsgrades der Vorgänge

• Die Anzahl der eingesetzten Mitarbeiter je Vorgang sollte sich während der Durchführung nicht ändern
• Die Zeiteinheit pro Vorgang sollte eine Zeiteinheit nicht unterschreiten
• Die Ausführung eines Vorgangs sollte nur einem Verantwortungsbereich unterliegen
PROJEKTMANAGEMENT
VORGEHENSPLANUNG
2) Netzplan
und Kostenplan
AP AP
Arbeitspaket (AP)
3) GANTT-Diagram
Beschreibung Ziele
Beginn Ende
Risiken Ressourcen
…
PROJEKTMANAGEMENT
NETZPLANTECHNIK
Die Netzplantechnik ermöglicht die Darstellung der Grundstruktur eines Projektes bestehend aus Vorgängen
bzw. Ereignissen sowie den Anordnungsbeziehungen mittels eines zusammenhängenden Graphen.
Ziel: Planung, Steuerung und Kontrolle von (Groß-) Aufträgen und Projekten
Anwendungsbereiche:
z.B. Einzelfertigung im Anlagenbau (z.B. Bau eines Kraftwerkes), Forschung & Entwicklung (z.B. Konstruktion
eines neuen Großraumflugzeugs), Organisation von Großprojekten (z.B. Fußball-WM) oder IT-Projekte (z. B.
Einführung einer Unternehmenssoftware)
Zentrale Begriffe:
• Vorgang: Zeiterforderndes Geschehen (z. B. Entwicklung eines bestimmten Softwaremoduls)
• Ereignis: Zeitpunkt, der das Eintreten eines bestimmten Projektzustandes markiert
• Vorrangbeziehungen bzw. Rangfolgebeziehungen: Aufgrund technologischer oder wirtschaftlicher Restriktionen können
bestimmte Vorgänge erst nach Abschluss anderer Vorgänge ausgeführt werden
PROJEKTMANAGEMENT
NETZPLANTECHNIK - METHODEN
Vorgangspfeilnetzplan:
Critical Path Method (CPM): Vorgänge werden als Pfeile dargestellt; Knoten
repräsentieren Ereignisse
Vorgangsknotennetzplan:
Metra Potential Method (MPM): Vorgänge werden als Knoten des Graphen abgebildet,
Vorgangsdauern dienen als Knotenbewertungen
Stochastische Methode:
Programm Evaluation and Review Technique (PERT): Wenn Vorgänge nicht
vollständig vorherbestimmbar sind
PROJEKTMANAGEMENT
NETZPLANTECHNIK - ZEITPLANUNG
V i = Menge der (direkten) Vorgänger von Vorgang (Knoten) i = 1,…,n

Ni = Menge der (direkten) Nachfolger von Vorgang i
T = kürzeste Projektdauer
FA i , FE i = frühestmöglicher Anfangs- bzw. Endzeitpunkt von Vorgang i
SA i , SE i = spätestmöglicher Anfangs- bzw. Endzeitpunkt von Vorgang i
ti = Dauer von Vorgang i
Vorwärtsrechnung: Ermittlung früheste Anfangs- und Endzeitpunkte für jeden Vorgang:

FAi := max {FEh | hÎVi}, FEi := FAi + ti
Rückwärtsrechnung: Ermittlung der spätesten Anfangs- und Endzeitpunkte aller Vorgänge:

SEi := min {SAj | jÎNi}, SAi := SEi - ti
PROJEKTMANAGEMENT
NETZPLANTECHNIK - ERGEBNISSE
Ergebnisse ermöglichen Informationen über:
Gesamte Pufferzeit (GP) eines Vorgangs i

ð Maximale Zeitspanne, um die ein Vorgang i verschoben und/oder verlängert
werden kann, ohne dass sich die Projektdauer erhöht
ð „Kritische Vorgänge“ = Vorgänge mit GPi = 0
Kritischer Weg:
Folge von kritischen Vorgängen im Netzplan, die mit Startknoten beginnt und im Endknoten endet
PROJEKTMANAGEMENT
BEISPIEL EINES VORGANGS-

KNOTEN-NETZES FAi := max {FEh | hÎVi}, FEi := FAi + ti
SEi := min {SAj | jÎNi}, SAi := SEi - ti
Vorgangsnummer
0304 0407 0509
Bezeichnung
Prototypen-
Frühester Dauer Frühestes
HW-Entwurf entwicklung HW-Test
Anfang Ende
Spätester Gesamt- Spätestes 6 3 9 9 5 14 14 4 18
Anfang puffer Ende
8 2 11 11 2 16 16 2 20
0101 0200 0305 0611 0712
Systementwurf Funktions-muster
Requirements Integration Systemtest
0 2 2 2 4 6 6 2 8 20 2 22 22 3 25
0 0 2 2 0 6 7 1 9 20 0 22 22 0 25
0102 0306 0408 0510
Program-mierung
Studie SW-Entwurf SW-Test
0 1 1 6 3 9 9 6 15 15 5 20
1 1 2 6 0 9 9 0 15 15 0 20
PROJEKTMANAGEMENT
BEISPIEL EINES VORGANGS-

KNOTEN-NETZES
Vorgangsnummer
0304 0407 0509
GPi = 0
Bezeichnung
Prototypen-
Frühester Dauer Frühestes
Anfang Ende HW-Entwurf entwicklung HW-Test Kritischer
Spätester
Anfang
Gesamt-
puffer
Spätestes
Ende
6 3 9 9 5 14 14 4 18 Pfad
8 2 11 11 2 16 16 2 20
0101 0200 0305 0611 0712
Systementwurf Funktions-muster
Requirements Integration Systemtest
0 2 2 2 4 6 6 2 8 20 2 22 22 3 25
0 0 2 2 0 6 7 1 9 20 0 22 22 0 25
0102 0306 0408 0510
Program-mierung
Studie SW-Entwurf SW-Test
0 1 1 6 3 9 9 6 15 15 5 20
1 1 2 6 0 9 9 0 15 15 0 20
PROJEKTMANAGEMENT
VORGEHENSPLANUNG
2) Netzplan
und Kostenplan
AP AP
Arbeitspaket (AP)
3) GANTT-Diagram
Beschreibung Ziele
Beginn Ende
Risiken Ressourcen
…
PROJEKTMANAGEMENT
GANTT-DIAGRAMM
Ein GANTT-Diagramm ist eine grafische Darstellung von Arbeitsabläufen in

Form eines Balkendiagramms.
• Zwei Dimensionen: Zeit und Aktivitäten

• Jeder Balken stellt eine Aktivität dar
• Die Länge des Balkens entspricht der geschätzten Dauer der Aktivität
• Nachteil: Es werden keine Abhängigkeiten dargestellt (bis auf wenige, die
vermutet werden können)
PROJEKTMANAGEMENT
BEISPIEL EINES GANTT - DIAGRAMMS
Umsetzung der Website für ein

Softwareunternehmen:
FB01 | Software & Digital Business | Dr. rer. pol. Timo Koppe 29
PROJEKTMANAGEMENT
PROJEKTPLAN (OUTLINE)
1. Introduction 4. Technical Process
1. Project Overview 1. Methods, Tools, and Techniques
2. Project Deliverables 2. Software Documentation
3. Evolution of the Software Project Management Plan 3. Project Support Functions
4. Reference Materials 5. Work Packages, Schedule, and Budget
5. Definitions and Acronyms 1. Work Packages
2. Project Organization 2. Dependencies
1. Process Model 3. Resource Requirements
2. Organizational Structure 4. Budget and Resource Allocation
3. Organizational Boundaries and Interfaces 5. Schedule
4. Project Responsibilities 6. Additional Components
3. Managerial Process 7. Index
1. Management Objectives and Priorities 8. Appendices
2. Assumptions, Dependencies, and Constraints
3. Risk Management
4. Monitoring and Controlling Mechanisms
5. Staffing Plan
* Based on IEEE Std 1058.1-1987.
PROJEKTMANAGEMENT
AUSFÜHRUNG & STEUERUNG

Projektdurchführung
• Die Projektdurchführung umfasst die eigentliche Projektarbeit / das Erstellen der Liefergegenstände. Sie basiert auf
dem Projektplan.
• Aufgaben des PM sind u.a. Stakeholder Management, Motivation, Konfliktlösung,
Moderation, Ressourcenbereitstellung, Klärung von Fragen, Fällen von Entscheidungen zur Projektdurchführung
Projektmonitoring und -steuerung
• Regelmäßige Statusberichte der Arbeitspakete über den Projektfortschritt

• Durch Formulare unterstützen (Schätzwerte, Ampelmethode, …)
• In kleinen Projekten kann eine formale, schriftliche Rückmeldung z.B. durch Teambesprechungen ersetzt werden
Projektqualität
• Reviews
• Walk-Throughs
• Individuelle Tests
PROJEKTMANAGEMENT
PROJEKTSTEUERUNG
Ziel
• das Projekt auf Kurs zu halten und so nah wie möglich am Plan
zu bleiben,
• Probleme zu erkennen, bevor sie auftreten, und
• Pläne zur Korrektur umzusetzen
Überwachung
• Projektstatus ermitteln – „Plan-Ist-Vergleiche“
• Fortschritt und Prognose ableiten und Risiken identifizieren
• Informationsbasis pflegen
Steuerung
• Korrektur- oder Präventivmaßnahmen vorschlagen
• Planung / Change Management
Abb. von Jurison, J. (1999). Software project management: the manager's view.
Communications of the association for information Systems, 2(1), 17.
PROJEKTMANAGEMENT
CHANGE (REQUEST) MANAGEMENT

Raise Change
Changes: Änderungen, die das Vorgehen im Projekt oder von
Projektergebnissen betreffen
Register
Change Request (CR): Anfrage / Aufforderung / ... (z. B. aus Change
Statusberichten, Audits, etc.) à Korrekturmaßnahme,
Präventivmaßnahme, Fehlerbeseitigung
Assess
Change
Change (Request) Management → Sicherstellen, dass CR
dokumentiert und gemanagt werden
Approve /
Reject Change
Manage
Change
PROJEKTMANAGEMENT
QUALITÄTSSICHERUNG
Die Qualitätssicherung (QA) stellt sicher, dass das Produkt den Anforderungen
der Benutzer Anforderungen entspricht und die gewünschte Funktionalität und
Qualität bietet.
• Qualität, sollte, wie die technischen Leistungsanforderungen, in spezifischen,

quantifizierbaren Begriffen definiert werden, die vom Kunden und dem
Projektteam gut verstanden werden.
• Die frühzeitige Erkennung und Korrektur von Fehlern kann zu erheblichen
Kosten- und Terminvorteile führen.
à Die Kosten für die Korrektur von Fehlern in der Entwurfsphase betragen etwa
ein Zehntel der Kosten für die Behebung von Fehlern in der Testphase.
PROJEKTMANAGEMENT
PROJEKTABNAHME UND -ABSCHLUSS

Am Ende des Projekts erfolgt i.d.R. die Abnahme durch den Auftraggeber
Möglicher Gegenstand einer Abnahme

• Software
• Hardware
• Dokumentation
• Lösungsverfahren
• Datenbestand
Abnahme aus juristischen Gründen von großer Bedeutung

• Bis zur Abnahme muss der Auftragnehmer die Vollständigkeit der Leistung nachweisen; nach der Abnahme kommt es zu
einer Beweislastumkehr
• Verjährungsfrist läuft ab der Abnahme
Bei externen Partner: Vereinbarung, wie Abnahme erfolgen soll (daran ist häufig auch die Abschlusszahlung gekoppelt)
Vertragliche Regelungen können bestimmte Tests vorsehen (z.B. Lasttests, Funktionstests)
FRAGEN?
Koppe, Timo
+49 6151 16-25754
PROJEKTMANAGEMENT VON
SOFTWARE- UND DIGITALPROJEKTEN
RÜCKBLICK

VERANSTALTUNG
Projekt Konzeption Planung Steuerung
und -abschluss
Organisation
Steuerung abschluss
Projektmanage-
Projekt ment
IT-PROJEKTMANAGEMENT

LEHRVERANSTALTUNG
• das Wasserfallmodell, dessen Phasen und -ergebnisse zu erklären.
Stakeholder
• Vor- und Nachteile sequenzieller und agiler Vorgehensmodelle zu diskutieren.
• Scrum und dessen Artefakte, Rollen und Ablauf zu verstehen und
anzuwenden.

Steuerung abschluss
ment
Projektteam
VORGEHENSMODELLE
W
ie
de
rh
ol
VORGEHENSMODELLE
un
g
Ein Vorgehensmodell ist eine planvolle, systematische Beschreibung der
einzelnen Schritte des Entwicklungsprozesses. Die einzelnen Prozessschritte
sind dabei in einer Folge angeordnet, aufeinander aufbauend und fest definiert.
Vgl. Ruf/Wittkau (2008), S. 25.
§ Fragestellung: „Was ist wann zu tun?“
§ Ziele:
§ Entwicklungsstufen systematisieren und strukturieren, um das Projekt
transparent, plan- und überprüfbar zu gestalten
§ Komplexitätsreduktion, das Entwicklungsprojekt wird überschaubarer
W
ie
de
rh
ol
ÜBERBLICK VORGEHENSMODELLE
un
g
• Kein standardisiertes Vorgehensmodell für alle IT-Projekte
• Innerhalb eines Unternehmens kann ein einheitliches Modell verwendet
werden, welches jedoch an Projektspezifika angepasst werden muss
Grundmodelle:
Agile
Sequentielle Vorgehensmodelle
Vorgehensmodelle
(u.a. Scrum)
W
ie
de
rh
ol
SEQUENTIELLES
un
g
VORGEHENSMODELL
Phase
Spezifikation
Entwurf
Implementierung
Integration
Einführung
Zeit Quelle: Eigene Darstellung, in Anlehnung an

Ruf/Fittkau (2008), S. 30.
DAS WASSERFALLMODELL
System
Requirements
Das ursprüngliche Wasserfallmodell von Royce
Software
Requirements
(1970): Prüfung der Phasenergebnisse und
Rückkopplungen zu vorherigen Phasen
Analysis
Program
Design
Coding
Testing
Operations
Quelle: Royce, W. (1970): Managing the Development of Large Software Systems.
PHASENERGEBNISSE IM
WASSERFALLMODELL
1. System 2. Software 3. Analysis: 4. Program 5. Coding: 6. Testing: 7. Operations:

Requirements: Requirements: Entwurf der Design: Implementierter Verifikation des Installiertes System
Lastenheft Pflichtenheft Software- Spezifikation Code Programms und Abnahme-
architektur benötigter und bestätigung
Module Testprotokolle
LASTEN-/PFLICHTENHEFT
Lastenheft ü Lastenheft als „Wunschkatalog“
des Auftraggebers (z.B. von
„Vom Auftraggeber festgelegte Gesamtheit der Fachabteilung erstellt)
Forderungen an die Lieferungen und Leistungen eines ü Nach dem Lastenheft wird ein
Auftragnehmers innerhalb eines Auftrages.“ (DIN 69905) Pflichtenheft angefertigt
ü Pflichtenheft zeigt auf, wie die

Pflichtenheft Vorgaben erfüllt werden sollen
„Vom Auftragnehmer erarbeitete Realisierungsvorhaben ü Abschließend erfolgt eine
aufgrund der Umsetzung des vom Auftraggeber Genehmigung durch den Auftraggeber
vorgegebenen Lastenheftes.“ (DIN 69905) („Abnahme“ / “Freigabe“)
ü Die Vereinbarung des Pflichtenhefts gilt
für Auftraggeber und -nehmer als
verbindlich
W
ie
de
rh
ol
SEQUENTIELLES
un
g
VORGEHENSMODELL
Merkmale sequentieller Vorgehensmodelle
§ Erst wenn eine Phase abgeschlossen wurde, kann die folgende Phase
gestartet werden (Meilensteine)
§ Das Projektergebnis kann gegen die anfangs bei der Spezifikation erstellten
Anforderungen geprüft werden
Voraussetzungen für die Anwendbarkeit sequentieller Vorgehensmodelle

§ Das Projektergebnis lässt sich durch relativ fixe Anforderungen beschreiben
§ Änderungen der Anforderungen während des Projekts sind nicht zu erwarten
AGILE VORGEHENSMODELLE
Vision Continue
Iteration 1 Iteration 2 Iteration 3 Iteration 4
Beispiel Iteration: Frühzeitig liefern.

Prüfen und anpassen.
Retro Planung
Review Implementierung
WANN WASSERFALL, WANN AGILE?
Stacey Complexity Matrix

• “There is no silver bullet” (Brooks, 1986, p. 2)
unknown
• Die Komplexität eines Projekts kann den Projektleitern
Chaos bei der Auswahl der geeignetsten Methodik helfen
Requirements
Wasserfall SCRUM
Complex
Co
Wasserfall erfordert vollständige SCRUM akzeptiert

m
Anforderungen und Detailanalyse Anforderungsänderungen und

pl i
ca
vor Entwicklung. bezieht alle Entwicklungsaktivitäten

te
d
Simple in jede Iteration

known Ideal für einfache, vorhersehbare SCRUM passt zu komplexen
known Technology unknown Szenarien zur Minimierung von Szenarien mit unsicheren
Neuplanungskosten. Anforderungen und Technologien.
… …
AGILES MANIFEST UND

SCRUM
ETWAS WERTVOLLES UND

BRAUCHBARES SCHAFFEN....
...auch wenn es anfangs nicht voll ausgestattet ist.
Beginne zum Beispiel mit einem einfachen, aber gut gefertigten Taschenmesser, das
wirklich benutzt werden kann
Danach können einige weitere Funktionen hinzugefügt werden
Es kann später immer noch zu einem Schweizer Taschenmesser machen, indem

zusätzliche Funktionen iterativ entworfen werden.
In Agile ist dies bekannt als die Entwicklung von MINIMUM VIABLE PRODUCT (MVP)
... NICHT VERSUCHEN, IM VORAUS

AN ALLES ZU DENKEN UND ES OHNE
STÄNDIGES FEEDBACK ZU LIEFERN
AGILITÄT KONZENTRIERT SICH AUF

FRÜHE UND KONTINUIERLICHE
WERTLIEFERUNG.
Wasserfall
Früher ROI
Gewinn
Agil
Höhere
Ergebnisqualität
Monate Reduzierter
Abstimmungs- und
Übergabeaufwand
Risikovermeidung
Kosten
WAS PASSIERT, WENN DU Höhere Effizienz &

HIER AUFHÖRST? Flexibilität
Implementation
4 AGILEN WERTEN - 12 PRINZIPIEN
Agil ist ein Mindset,

eine Einstellung, eine
Haltung
basierend auf
4 Agilen Werten und
12 Agilen Prinzipien
MANIFEST – 4 WERTE
Obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.
www.agilemanifesto.org
12 PRINZIPEN ZUR AGILEN ARBEIT
AGILE METHODEN – WURZELN UND

ENTWICKLUNG
Kanban & Toyota '01 Agile Manifesto - '07
Production Systems '86 - New New Product Kanban (SD) -
/ Lean Development Game '09 Lean Startup
1940s 1950s 1960s 1970s 1980s 1990s 2000s
'95 Scrum –
'99 XP, User Stories
“SCRUM” – ENTWICKELT IN DEN 90ER
(Kleine) Auswahl von Unternehmen die Scrum

verwenden
Rugby – Scrum(mage) (Gedränge) eine Methode, um

das Spiel nach einem Stillstand wieder zu starten.
Teammitglieder arbeiten als eine starke gemeinsame
Einheit mit dem Ziel Ballbesitz zurückzugewinnen & sich
in Richtung ihres Zieles zu bewegen.
DER SCRUM GUIDE
Download
https://www.scrumguides.org/download.html
Letztes Update: November 2017
DER AGILE “FLOW” IN SCRUM
DER AGILE FLUSS IN SCRUM

Product Backlog
Sprint Review Refinement (PBR)
Präsentation der Sprint Kontinuierliche gemeinsame
Ergebnisse und Feedback Product
Überarbeitung des Backlogs
von Programmbeteiligten Backlog
Refine-
ment
Kunde
Stakeholder
Sprint
Review Sprint 1,5h
Scrum
Master
1,5h 2 - 4 Wochen
Vision
Sprint Retro
Sprint
Retro- Betrachtung der Daily Daily
spective Teamleistung und Scrum Besprechung der
Erarbeitung von
Product Sprint Tagesaufgaben,
1,5h Verbesserungen. 15m Koordination und
Backlog Backlog
Blocker Management
Details, Priorität
Product Owner Team

Sprint
Sprint Backlog Potenziell
Planning
Product Enthält User auslieferbares
Backlog Stories denen PO Produkt-
& Entwickler für
2h Sprint Planung inkrement
Enthält die den aktuellen
priorisierten Das Team plant, was es
Sprint zugestimmt im bevorstehenden
User Stories. haben
08.05.23 Sprint erreichen kann. 25
3 ROLLEN
Product Backlog
Refine- Scrum Master
ment
Kunde Der Scrum Master ist
Stakeholder
Sprint
Review Sprint 1,5h
Scrum
Master
verantwortlich für das
Führen, Coachen, Trainieren
und Unterstützen des Scrum
1,5h 2 - 4 Wochen Teams bei der richtigen
Anwendung von Scrum
Vision
Sprint Retro
Sprint
Product Owner Erarbeitung von Team Tagesaufgaben,
Product Sprint 1,5h Verbesserungen. 15m
Der Product
BacklogOwner definiert Backlog Das Team ist für die Koordination und
Backlog Items, ist Umsetzung der Blocker Management
verantwortlich für das Product Sprint Items
Details, Priorität
Product Owner Backlog und entscheidet was

„done“ ist
Team verantwortlich
Sprint
Planning
& Entwickler für
User Stories. haben
3 ROLLEN
Product Owner Scrum Master Scrum Team
Anforderungen Effiziente Teamarbeit User Stories

Aufgaben bündeln & definieren fördern umsetzten
Spielt den Kunden Hindernisse Selbst-

für Teamfragen beseitigen organisation
Hauptansprech- Meetings
Sprintplanung
partner des Kunden moderieren
Priorisiert User Einhaltung agiler Sprint-

Stories Arbeitsweisen steuerung
ÜBERBLICK: 5 EREIGNISSE
Product Backlog
Präsentation der
Präsentation der Sprint
Sprint Kontinuierliche gemeinsame
gemeinsame
Kontinuierliche
Ergebnisse und
Ergebnisse und Feedback
Feedback Product
Product Überarbeitung des
Backlogs
von
vonProgrammbeteiligten
Projektbeteiligten Backlog
Backlog
Refine-
Refine-
ment
ment
Kunde
Stakeholder
Sprint
Sprint
Review
Review Sprint 1,5h
1,5h Scrum
Master
1,5h
2 - 4 Wochen
Vision
Sprint Retro
Sprint
Sprint
Retro-
Retro- Betrachtung der
Betrachtung der Daily
Daily Daily
spective
spective Teamleistung und
Teamleistung und Scrum
Scrum Besprechung der
Besprechung der
Erarbeitung von
Erarbeitung von
Tagesaufgaben,
1,5h Verbesserungen.
Verbesserungen. 15m Koordination und
und
Backlog Backlog Koordination
Blocker Management
Blocker Management
Details, Priorität
Product Owner Team

Sprint
Sprint
Planning
Planning
& Entwickler für
2h Sprint Planung
Planung
Sprint inkrement
priorisierten Das Team
Das Team plant,
plant, was
was es
es
im bevorstehenden
User Stories. haben
08.05.23 Sprint erreichen
Sprint erreichen kann.
kann. 29
BEISPIEL: 2 WÖCHIGER SPRINT

ZYKLUS
Sprint Zyklus
Woche 1 Woche 2
Mi Do Fr Mo Di Mi Do Fr Mo Di
Sprint
1h+1h
Planning
Bi-Daily 15m 15m 15m 15m 15m 15m 15m 15m
Backlog
Refinement 1,5h
Sprint Review 1,5h
Retrospektive 1,5h
BACKLOG UND USER STORIES
3 ARTEFAKTE
Product Backlog
Refine-
ment
Kunde
Stakeholder
Sprint
Review Sprint 1,5h
Scrum
Master
1,5h 2 - 4 Wochen
Vision
Sprint Retro
Sprint
Erarbeitung von
Backlog Backlog
Blocker Management
Details, Priorität
Product Owner Team

Sprint
Planning
2h Sprint Planung
& Entwickler für inkrement
User Stories. haben
BACKLOG
Product Backlog
Refine-
ment
Kunde
Stakeholder
Sprint
Review Sprint 1,5h
Scrum
Master
1,5h 2 - 4 Wochen
Vision
Sprint Retro
Sprint
Erarbeitung von
Backlog Backlog
Blocker Management
Details, Priorität
Product Owner Team

Sprint
Planning
& Entwickler für
User Stories. haben
BACKLOG - AGILES KERNARTEFAKT
Das Backlog reflektiert die Top-

Prioritäten der Kunden und wird Die obersten Einträge werden
kontinuierlich gepflegt. USER STORY als Nächstes bearbeitet.
USER STORY Deshalb sind die Einträge
Die Priorität der Backlog Einträge
DETAILLEVEL
detailliert und in Sprintlänge
PRIORIÄT
bestimmt, in welcher Reihenfolge ENABLER geschnitten
die Teams die Einträge abarbeiten.
SPIKE Untere Einträge werden erst
Damit bestimmt die Priorisierung später abgearbeitet.
USER STORY
den Plan und den Umfang der Sie sind bewusst grob-granular
Umsetzung. Kann mehr BACKLOG und groß und werden zeitgerecht
umfassen, als im Projekt detailliert und geschnitten.
umgesetzt werden kann
BEISPIEL: ZUSAMMENSPIEL DER

VERSCHIEDENEN BACKLOG ITEMS
SPIKE
Vision / Produkt / Zielbild
• LIEFERT WISSEN (z. B. Termine, Entscheidungen, …)
• verlinkt mit User Story und zeitlimitiert
detailliert
Features / Epics ENABLER
blockiert • ERMÖGLICHT USER STORIES
(z.B. Data, Auth.,
Basis, Arch, …)
blockiert durch
LÖSUNGSRAUM
liefert
USER STORY
• LIEFERT BUSINESS WERT
• geliefert in 2 Wochen Zyklen
WARUM IST DAS ARBEITEN MIT

USER STORIES HILFREICH?
Der erste große Unterschied von User Stories zu Anforderungen
liegt darin, was sie beschreiben
ANFORDERUNGEN USER STORIES
Beschreiben, was der Kunde mit

Beschreiben, was das System tun der Umsetzung der Story erreichen
soll. will. Das Produkt.
USER STORY UM “PRODUCT BACKLOG

EINTRÄGE“ ZU BESCHREIBEN
Die User Story
• Anforderungen werden nicht nur erfasst
sondern auch diskutiert
Als < Nutzer> • „Stimme des Nutzer/Kundens“
möchte ich < etwas tun > • Initiiert vom Product Owner unter
sodass < ich einen Nutzen Berücksichtigung des Inputs von
generiere> Spezialisten, Entwicklern, Testern, Scrum
Master und/oder anderen Stakeholdern
• Jede User Story hat Akzeptanzkriterien,
welche durch den Product Owner identifiziert
und abgenommen werden
INVESTIERE IN “GUTE“ USER STORIES
I
Eine User Story sollte, wenn möglich unabhängig von den anderen Stories im Product
ndipendent (unabhängig) Backlog sein. Eine Story sollte nicht davon abhängig sein, dass zuerst eine andere Story
umgesetzt werden muss.
N
Eine User Story ist kein starres Konstrukt. Es sollte solange gemeinsam zwischen Product
egotiable (verhandelbar) Owner und Entwicklerteam über eine User Story gesprochen werden, bis diese durch das
Entwicklerteam in einem Sprint umsetzbar ist.
V
Eine im Product Backlog befindliche User Story weist einen erkennbaren Nutzen für das
aluable (werthaltig) Produkt aus und zahlt auf die Produkt Vision ein. Aus diesem Grund ist es sinnvoll, dass der
Product Owner User Stories mit Stakeholdern/Nutzern bespricht.
E
Eine User Story ist so detailliert, dass das Entwicklerteam die Umsetzung in einem Sprint
stimatable (schätzbar) schätzen kann. Jeder User Story im Product Backlog muss vor der Umsetzung in einen Sprint
vom Entwicklerteam geschätzt sein.
S
Für die Größe eines User Story gilt folgende Faustregel:
mall (klein) Eine User Story sollte maximal so groß sein, dass diese in einem Sprint, aber mindestens an
einem halben Tag umgesetzt werden kann.
08.05.23
T estable (testbar)
Der erfolgreiche Abschluss einer User Story stellt die Testdurchführung anhand von
Akzeptanzkriterien dar. Die Festlegung von Akzeptanzkriterien erfolgt zwischen Product
Owner
FB01und Entwicklerteams
| Software & Digital Businessund
| Dr. sind vor
rer. pol. Umsetzung
Timo Koppe in einem Sprint festzulegen. 38
KOMPONENTEN EINER USER

STORY
TITEL/ZUSAMMENFASSUNG
BESCHREIBUNG/ WERT HYPOTHESE
AKZEPTANZKRITERIEN
SCHÄTZUNG IN USER STORY GGF. UNTERTYP (SPIKE,

POINTS ENABLER)
ABHÄNGIGKEITEN LÖSUNGSVERSION
EPIC ZUORDNUNG
AKZEPTANZKRITERIEN
Akzeptanzkriterien sind vergleichbar mit einem sehr

konzentrierten, grobgranularen Tests.
Sie sind nicht so feinkörnig wie ein Testskript, sondern dienen als
Grundlage, zur Erzeugung eines Skripts (z. B. im Sprint)
Richtig formuliert beschreiben sie, was der primäre Interessent der

Story nach der Lieferung tun kann, nicht die Lösung.
Sie beginnen oft als knappes, „absolutes Muss“ und werden
dann nach und nach im Backlog Management verfeinert.
BEISPIEL: BACKLOGHIERARCHIE
MIT EPICS UND USER STORIES
Team Scope
EPIC EPIC … • EPICs dienen der

Organisation/Gruppierung
von Stories
Sprint 1
• Ein EPIC ist fertig, sobald

alle dem EPIC zugehörigen
Stories fertig gestellt sind
Zeit
Sprint 2
User Story
Enabler
Sprint …
Spike
CHALLENGE 1: ZU WENIG WISSEN

§ manchmal existiert noch nicht das Wissen, um eine USER STORY final zu detaillieren, um sie zu planen, bzw. zu implementieren
(z. B. die Entscheidung für eine Technologie muss erst getroffen werden)
§ in diesen und ähnlichen Fällen helfen SPIKES
SPRINT 1 SPRINT N SPRINT X SPRINT Y SPRINT Z
SPIKE User Story Option A

blockiert
durch
User Story Option B
… … …
DAUMENREGELN
§ SPIKES sind immer an USER STORIES, oder Story-Platzhalter gebunden (USER STORY blockiert durch SPIKE)
§ falls es mehrere Optionen gibt, muss der Platzhalter, der dem SPIKE folgt, groß genug sein, um alle Optionen abzudecken
§ Platzhalter müssen rechtzeitig in sprintgerechte USER STORIES zerbrochen werden (z. B. im Backlog Management)
§ die vorhandene Kapazität muss ausreichen, um SPIKE & USER STORIES zeitgerecht zu liefern
CHALLENGE 2: DIE STORY IST ZU GROSS

teile und herrsche
(durch mehr Wissen)
ideal Spike
Pfade/Schritte durch den (System-) Grenzen,

Prozess / das System Pfade Interfaces Proxies, …
SPIDR
z. B. Geschäftsregeln,
z. B. CRUD, etc. Akzeptanzkriterien,
Daten Regeln NFAs, …
CRUD: Create, Read, Update, Delete NFA: Nichtfunktionale Anforderungen
CHALLENGE 3: DIE STORY WIRD NICHT

ERZÄHLT
Was haben User Stories

und Diashows
gemeinsam?
WIE EINFACH IST ES, ANWEISUNGEN ZU

SCHREIBEN/ZU BEFOLGEN? EIN TEASER....
https://youtu.be/cDA3_5982h8
AGILES SCHÄTZEN
RELATIVES SCHÄTZEN
§ misst relativen Aufwand und
Größe, hat keine Einheit
§ ist relativ:
8~3x3
§ nutze Schritte
1, 2, 3, 5, 8, 13, 20, 40, 80, 100, …
(Fibonacci-Sequenz)
1 3 5 8
Charakteristika von Story Points Beim Vergeben von Story Points zu

• Empirisch beachten:
• Relativ • Story Komplexität
• Einzigartig für das Team • Benötigte Fähigkeiten
• Risiken & Unklarheiten
Story Points werden als Erleichterung bei der Schäzung verwendet und helfen dem Scrum Team zu verstehen, wie viel
08.05.23
Einsatz notwendig ist um eine Story abzuschließen.
FB01 | Software & Digital Business | Dr. rer. pol. Timo Koppe 48
PLANNING POKER
Schritte
Die größten
Jeder Schätzer Schätzer wählen Alle zeigen Schätzung
Der Moderator Ausreißer
macht sich geheim eine gleichzeitig ihr wiederholen,
liest die Story werden
bereit Größe Ergebnis falls notwendig
diskutiert
Mike Cohn, Agile Estimating and Planning, 2005
PLANNING POKER - ÜBUNG
Der Moderator Schätzer wählen Alle zeigen Die größten Schätzung

Jeder Schätzer gleichzeitig ihr Ausreißer werden
stellt die Story geheim eine wiederholen,
macht sich bereit Größe Ergebnis diskutiert falls notwendig
vor
1 2 3 5
8 13 20
DIE 5 EREIGNISSE
SPRINT PLANUNG
Product Backlog
Refine-
ment
Kunde
Stakeholder
Sprint
Review Sprint 1,5h
Scrum
Master
1,5h 2 - 4 Wochen
Vision
Sprint Retro
Sprint
Erarbeitung von
Backlog Backlog
Blocker Management
Details, Priorität
Product Owner Team

Sprint
Planning
& Entwickler für
User Stories. haben
SPRINT PLANUNG
Ziel: "Aufgaben und Verantwortlichkeiten für Sprint sind klar, realistische

Planung“
• max. 1h+1h Meeting zu Beginn des Sprints
• Backlog wird als Unterstützung zur Besprechung verwendet
Team
• Der Product Owner präsentiert die vorgeschlagenen User Stories und
Prioritäten
Product Sprint
• Das Team schätzt und bespricht die User Stories, Prioritäten und erstellt Backlog Backlog
Sub-Tasks die Teammitgliedern zugeordnet werden
Details, Priorität
• Team stimmt den User Stories für den Sprint zu à Sprint Commitment
Sprint Backlog
Product Enthält User
Backlog Stories denen PO
& Entwickler für
priorisierten Sprint zugestimmt
User Stories. haben
Product Owner
DAILY
Product Backlog
Refine-
ment
Kunde
Stakeholder
Sprint
Review Sprint 1,5h
Scrum
Master
1,5h 2 - 4 Wochen
Vision
Sprint Retro
Sprint
Retro- Betrachtung der Daily
Daily Daily
Daily
spective Teamleistung und Scrum
Scrum Besprechung
Besprechung der
der
Erarbeitung von
Tagesaufgaben,
1,5h Verbesserungen. 15m
15m Koordination
Koordination und
und
Backlog Backlog
Blocker
Blocker Management
Management
Details, Priorität
Product Owner Team

Sprint
Planning
2h Sprint Planung
& Entwickler für inkrement
User Stories. haben
DAILY
Ziel: "Koordination und Transparenz zu aktuellen User Stories schaffen & Daily Daily
Scrum
Blocker Management“ Besprechung der
Tagesaufgaben,
15m
• max. 15min Meeting jeden Tag Koordination und
Blocker Management
• Backlog wird als Unterstützung zur Besprechung verwendet

• Jedes Teammitglied informiert über den aktuellen Stand
• Blocker und Risiken werden besprochen und gemanagt
• Potenzielle Nachbesprechungen vereinbart
WERTFLUSS AUF STORY-EBENE

XXX Team
Aktiver Sprint:
OPEN ANALYSE BUILD TEST Review DONE
User Story User Story
Story-Treiber bestimmt User Story Bearbeitung …. Sprint Test Prüfung: Definition of Done und
Sprint-Planung wird aufgenommen Akzeptanzkriterien Akzeptanz-Kriterien
durchgeführt Erfüllung abgenommen
Prüfung: Dokumentation Alle Sub-Task sind
abgeschlossen
Spike User Story Spike User Story
Reduzierter Workflow für

z.B.: Spikes
DEFINITION OF DONE
Die „Definition of Done“ (DoD) legt ein gemeinsames Verständnis dessen DONE
fest, was "Erledigt" bedeutet
• Das Team und der Kunde definieren, was “Done" bedeutet (z.B. “high quality
shippable“, nicht funktionale Anforderungen [externe + innere Qualität],
Tests)
• Nicht “Done” Backlogitems werden bei der Sprint-Review nicht präsentiert
• Mit zunehmender Erfahrung des Teams wird die Definition von “Done" Definition of Done und
Akzeptanz-Kriterien
erweitert und verschärft. abgenommen
Alle Sub-Task sind
• Def. of Done umfasst alle Akzeptanzkriterien abgeschlossen
PRODUCT BACKLOG REFINEMENT

Product Backlog
Refine-
ment
Kunde
Stakeholder
Sprint
Review Sprint 1,5h
Scrum
Master
1,5h 2 - 4 Wochen
Vision
Sprint Retro
Sprint
Erarbeitung von
Backlog Backlog
Blocker Management
Details, Priorität
Product Owner Team

Sprint
Planning
& Entwickler für
User Stories. haben
PRODUCT BACKLOG REFINEMENT
Übergeordnetes Ziel: Mittel- und Nahfrist-Planung des Backlogs (bspw., nächste 3 Sprints)
Backlog Pflege (Refinement)

• Erstellung neuer User Storys und Epics
• Detaillierung existierender Stories und Epics, gegebenenfalls Splitting
• Diskussion der Akzeptanzkriterien
• (Neu-)Schätzung, u.a. aufgrund neuer Erkenntnisse
USER STORY
• Veränderung der Priorisierung
USER STORY
DETAILLEVEL
PRIORIÄT
ENABLER
Überlegungen: SPIKE
• Scope mit aktuellem Fortschritt / geplanter Kapazität noch machbar? USER STORY
• Was brauchen wir um unsere Ziele zu erreichen? BACKLOG
SPRINT REVIEW
Product Backlog
Refine-
ment
Kunde
Stakeholder
Sprint
Review Sprint 1,5h
Scrum
Master
1,5h 2 - 4 Wochen
Vision
Sprint Retro
Sprint
Erarbeitung von
Backlog Backlog
Blocker Management
Details, Priorität
Product Owner Team

Sprint
Planning
& Entwickler für
User Stories. haben
SPRINT REVIEW
Ziel: "Transparenter Projektfortschritt. Informierte Stakeholder. Wichtiger

Realitäts- Check!“
• max. 1,5h am Ende des Sprints
• Teilnehmer: Stream Mitglieder und Stakeholder
• „Was ist jetzt neu, was vor 2-4 Wochen noch nicht da war…“
• Vorzugsweise mit minimalen bis gar keinen PowerPoint Präsentationen –
Gelegenheit Fortschritt zu feiern
• Sprint Review ist keine Demonstration von Dingen, die nicht umgesetzt
werden konnten.
Sprint
Backlog Potenziell
auslieferbares
Produkt-
inkrement
SPRINT RETROSPEKTIVE
Product Backlog
Refine-
ment
Kunde
Stakeholder
Sprint
Review Sprint 1,5h
Scrum
Master
1,5h 2 - 4 Wochen
Vision
Sprint Retro
Sprint
Erarbeitung von Tagesaufgaben,
Product Sprint Verbesserungen. 15m
1,5h Koordination und
Backlog Backlog
Blocker Management
Details, Priorität
Product Owner Team

Sprint
Planning
& Entwickler für
User Stories. haben
SPRINT RETROSPEKTIVE
Ziele:
Blick auf die Ergebnisse: Haben wir unser Ziel erreicht?
Blick auf den Sprintverlauf: Müssen wir uns anpassen?
Anpassen der Arbeitsweise: Konkrete Maßnahmen
BURN-UPS VISUALISIEREN VELOCITY
GEPLANTER SCOPE in Story Points

(“Wie viele Story Points sind insgesamt im Sprint/Wave geplant?”)
IDEAL-LINIE
(“Wie viele Story Points sollte ich tendenziell schon erreicht haben?”)
BURN-UP
(“Wie viele Story Points habe ich schon erreicht/abgenommen?”)
ENTWICKLUNG, VELOCITY PRO SPRINT

SPRINT-PLAN
(“Wie viele Story Points habe ich mir im Sprint vorgenommen?“)
ERREICHTE VELOCITY
(“Wie viele Story Points habe ich im Sprint erreicht/abgenommen?”)
VELOCITY FORECAST
(“Wie entwickelt sich meine Velocity?”)
LEITENDE PRINZIPIEN EINER

RETROSPEKTIVE
Retrospektiven erfordern Mut, sich Herausforderungen &

1. Retrospektiven sind harte Arbeit Diskussionen frühzeitig zu stellen.
…und niemals auf Personen. Das Meeting dient nicht

2. Fokus liegt auf dem Prozess dazu Schuldige zu finden, sondern Lösungsansätze.
“Wir müssen aufhören…” liefert selten Ergebnisse.

3. Lösungsorientierung Aufbauen/Starten von Dingen ist effektiver. Fokus auf
kleine, sofort umsetzbare Handlungen & Übernahme ins
Backlog.
BRAINSTORMING RETRO:
START – STOP - CONTINUE
Was soll künftig gemacht Was soll künftig Was soll künftig fortgesetzt
werden? unterlassen werden? werden?
Für andere Retro Ideen: https://www.funretrospectives.com/category/retrospective/

FRAGEN?
Koppe, Timo
+49 6151 16-25754
AUSGEWÄHLTE TECHNOLOGIEN FÜR

DIE SOFTWAREENTWICKLUNG IN
IT-PROJEKTEN
RÜCKBLICK

VERANSTALTUNG
Organisation
Steuerung abschluss
Projektmanage-
Projekt ment
AUSGEWÄHLTE TECHNOLOGIEN FÜR DIE SOFTWAREENTWICKLUNG IN IT-PROJEKTEN

LEHRVERANSTALTUNG
• einen groben Überblick über "alle" Bereiche der Softwareentwicklung zur
Stakeholder
Vorbereitung auf das IT-Praktikum zu geben.
• wichtige Meta-Skills für die Einarbeitung und Bearbeitung von
Programmierprojekten im Rahmen des IT-Praktikums zu kennen
• erste praktische Erfahrungen zu sammeln und den Umgang mit
grundlegenden Softwareentwicklungswerkzeugen zu erlernen
Steuerung abschluss
ment
Projektteam
ÜBERBLICK ZUM IT PRAKTIKUM

(WS23/24)
~ 15
Jahre FT
~40% Personal
>1000
Analytics User
& AI Stories
IT-Praktikum
22/23
90 13
Studierende
Projekte
4,5
Monate
BEISPIELE: IT PRAKTIKUM -
PROJEKTE UND INHALTE WS2021/22
Themen WS 2022/23
Using Market Data to Enhance Trading Decisions
Verkaufs- und Potentialanalyse als Consulting-Projekt bei echtem Kunden
Direktes Feedback in der hybriden Arbeitswelt. (MS Teams)
Cyber Security Legislation Monitoring
Smart Energy
AI-Visual Inspection Studio
AI Generated Product Media
SkillT – A gamified approach to individual development
...
IT PRAKTIKUM - HERAUSFORDERUNGEN
Projektabnahme
Projektdurch
Projektdefinition Projektplanung und
führung
Projektabschluss
⟩ Unklare technische ⟩ Undefinierte ⟩ Entwicklungs- ⟩ System- und

Anforderungen des Qualitätsstandards erwartungen und - Anwendungsintegration
Praxispartners ⟩ Berücksichtigung der ergebnisse ⟩ Debugging
⟩ Unbekannte IT- neuesten ⟩ Veränderte ⟩ “Delivery Challenge”
Landschaft und Technologietrends Kundenanforderungen ⟩ Projektabnahme
Technology Stack des ⟩ Einrichtung der ⟩ Probleme mit Legacy ⟩ ...
Praxispartners Entwicklungsumgebung Systems
⟩ ... ⟩ Schätzung des ⟩ Qualitätssicherung
Umfangs ⟩ Daten- und
⟩ Fachjargon Infrastruktur-
⟩ ... verfügbarkeit
⟩ ...
ÜBERBLICK ZUR BEWERTUNG DES

IT PRAKTIKUMS
Kategorie Bestandteile
Initiales Backlog - Issues vorhanden, Beschreibung, Struktur & Format
Jira - Struktur (bspw. Epics, User Stories, Value Propositions, Schätzungen,...), Entwicklung
Schriftliche Abgabe
& Doku Sprint Reports - Kontinuierlich abgegeben, Vollständigkeit, Struktur & Inhalt
Benutzerhandbuch - Verständlich & angemessen, Inhalt, originelle Aufbereitung
Abschlussbericht (Agil) - Formale Vorgaben, Inhalt
Präsentation 8 Min Pitch – Storyline (Roter Faden), Folien, Vortragsweise/Stil, Diskussion, Gesamteindruck (u.a. Originalität)
Bewertung Praxispartner Kooperation und Projektergebnis
Teamdynamik & -Entwicklung - wie Gleichverteilung, Lernkurve, Performance

Teamentwicklung
Stakeholdermanagement - Umgang Stakeholder, Erwartungsmanagement etc.
IT-PRAKTIKUM 101
ÜBERBLICK ZU BEKANNTEN...
● Software Engineering Tools: Integrated Development Environment (IDE), Software
Development Kit (SDK), Libraries Diese VL
● Praktiken: DevOps, Version Control System (VCS), Continuous Integration (CI) /
Continuous Delivery (CD), Testing
● Architektur- und Design Muster: Serviceorientierte Architektur (SOA),
Microservices, Model View Controller (MVC) Nächste VL
● Unterstützende Aktivitäten - Documentation, Software quality assurance (SQA),
(Project Management), User Experience
Weiterführende Inhalte:
❏ Git Dokumentation: https://git-scm.com/doc
❏ Git workflows: https://nvie.com/posts/a-successful-git-branching-model/ oder https://guides.github.com/introduction/flow/
❏ “Design Patterns”, Gamma, Helm, Johnson & Vlissides, Addison-Wesley 1995
❏ “Building Microservices”, Sam Newman, O’Reilly Press 2015
❏ “Beautiful Architecture”, Spinellis & Gousios, O’Reilly Press 2009
BUZZWORDS & HYPES
SOFTWARE DEVELOPMENT - PRAKTIKEN,

TOOLS, ARCHITEKTUREN ETC.
Software development Process Template
● Die IEEE-Definition von 2010 definiert Software Engineering als: (Quelle: Wikipedia)
Core activities
The application of a systematic, disciplined, quantifiable approach to the development,
Processes , Requirements, Design , Engineering, Construction,
operation and maintenance of software; that is, the application of engineering to software.
[IEEE 2010]
Testing, Debugging, Deployment , Maintenance
Paradigms and models
Agile, Cleanroom, Incremental, Prototyping, Spiral, V model,
● Prozessmodelle (z.B. Agil, Wasserfall) können Aktivitäten (z.B. Waterfall
Methodologies and frameworks
Testing) und die Rollen beteiligter Personen umfassen ASD, DevOps, DAD, DSDM, FDD, IID, Kanban, Lean SD, LeSS,
MDD, MSF, PSP, RAD , RUP, SAFe, Scrum, SEMAT, TSP,

● Größere Projekte können mehrere unterschiedliche OpenUP, UP, XP
Supporting disciplines
Prozessmodelle verwenden, um verschiedene Teile der Software Configuration management , Documentation , Software quality
zu entwickeln. assurance (SQA), Project management, User experience

Practices
● Frameworks, Tools, Praktiken und Architekturen wurden entwickelt, ATDD , BDD, CCO, Continuous integration (CI), Continuous
delivery (CD), DDD, PP, SBE, Stand-up, TDD
um den (Entwicklungs-) Prozess zu erleichtern Tools

Compiler, Debugger, Profiler, GUI designer, Modeling, IDE, Build
automation, Release automation, Infrastructure as code, Testing
...
ÜBERBLICK ZUM
ENTWICKLUNGSPROZESS
Code Build Package Deploy Run Operate
SOFTWARE ENGINEERING TOOLS: IDE
• Eine integrierte Entwicklungsumgebung (IDE) ist eine

Softwareanwendung, die Programmierern umfassende
Funktionen für die Softwareentwicklung bietet.
• Eine IDE besteht in der Regel aus einem Quellcode-
Editor, Compiler, Linker, Interpreter, Debugger und GUI-
Builder, die als Komponenten bezeichnet werden.
• Einige der IDEs sind Eclipse IDE, Microsoft Visual
Studio (Code), Dev-Cpp Turbo C / C++ Builder usw.
SOFTWARE ENGINEERING TOOLS:

SDKS & LIBRARIES
• Libraries (dt. Bibliotheken) sind eine Sammlung • Software Development Kits (SDKs) umfassen
von häufig genutzten Funktionen für einen mehrere Bibliotheken und andere Werkzeuge
bestimmten Zweck (z.B. IDEs, Runtime)
• Beispiele: • Ziel: Entwicklung einer Anwendung für eine
• Interaktion mit dem Dateisystem bestimmte Plattform
(z.B. os in Python) • Beispiele:
• Mathematische Funktionen • iOS SDK zur Entwicklung von mobilen
(z.B. Math in JavaScript) Anwendungen für iPhone/iPad
• Maschinelles Lernen • Microsoft Windows SDK zur Entwicklung von
(z.B. scikit-learn in Python) Windows-Anwendungen
PRAKTIKEN - VERSION CONTROL

SYSTEM (VCS)
Warum wird ein Version Control System (VCS) benötigt?
• Dokumente und Dateien wachsen über die Zeit
• Mehrere Programmierer arbeiten parallel am Code
• Verschiedene Versionen wachsen “nebeneinander” (z.B. für
die Entwicklung neuer Features)
Zwei Ansätze:
• Zentralisierte VCS: z.B. Subversion SVN
• Verteiltes VCS: z.B. GIT
• Jeder hat seinen eigenen “Clone” des Repositories und
Änderungen am Server Repository durch Push/Pull

SYSTEM
Remote
Begriffe: clone
• Repository (kurz “Repo”): Datenbank mit einer Versionshistorie für alle fetch
gespeicherten Dateien
• Head: Die letzte Revision in dem Repository push pull
Repository
Grundlegende Aktionen:
• Clone: Erstmaliges Herunterladen des Remote Repo commit
• Ignore: Erlaubt lokale Dateien, welche nicht im Repo sind
Index
• Add: Hinzufügen einer Datei in den Index
• Commit: Überführung von Änderungen aus Index in Repo (= Version) Workspace
add
• Pull: Abrufen von Commits aus Remote ins lokale Repo
• Push: Veröffentlichen von Commits vom lokalen ins Remote Repo

SYSTEM
Weiterführende Aktionen, die in der Praxis oft verwendet werden:
• Diff / Change: Spezifische Modifikationen eines Dokuments
• Branch: Duplikation des Codes zur Feature Entwicklung
• Merge: Integration von zwei Branches
• Resolve: Manuelles Beheben von Konflikten
• Locking: Verhindern von Änderungen durch andere Entwickler

SYSTEM
Best Practices:
• Kleine Commits: Nachvollziehbarkeit, einfaches Zurückrollen und weniger
Konflikte
• Häufiges Updaten und Commiten
• KEINE Commits für kaputten, halb fertigen oder ungetesteten Code
• Einheitliche Commit Nachrichten, damit “Sinn” der Änderungen
nachvollziehbar ist
• Einheitlichen Workflow (siehe weiterführende Inhalte)
Tools:
• Hosting für Remote Repositories: GitHub, GitLab, Bitbucket
• Command Line Tools (z.B. Git CLI)
• IDE Integration (z.B. Visual Studio Code )
• GUI Tool (z.B. Sourcetree) Quelle: https://www.sourcetreeapp.com/
PRAXIS 1: LOCAL DEVELOPMENT
Code for practical ITPM lectures offered by Software & Digital Business Group at
Technical University of Darmstadt: https://github.com/timo-koppe/itpm-lecture
• Setup instructions can be found in the file README.md
• Repository contains two examples:
• Example 1: Hello world
• Example 2: Grade calculator
GRUNDLAGEN DER WEBENTWICKLUNG
Client Schnittstelle (“API”) Server

(“Frontend”) (“Backend”)
• Beim Frontend handelt es sich zumeist um eine Webanwendung, die über

den Internetbrowser verwendet werden kann
• Das Backend läuft auf einem oder mehreren Servern und kann auch in
mehrere kleine Anwendungen aufgeteilt sein
• Für die Gestaltung der Schnittstelle gibt es standardisierte Protokolle, z.B.
REST, GraphQL
• Für komplexe Anwendungen bietet es sich an, Frontend und Backend
voneinander getrennt zu entwickeln
BEISPIEL: NOTENRECHNER FÜR

ITPM/IT-PRAKTIKUM
Backend {“grade”: 2}
http://localhost:3000
{“itpmGrade”: 1, “itpGrade”: 2.3}
Browser Frontend
ÜBERBLICK ZUM
ENTWICKLUNGSPROZESS
UNTERSTÜTZENDE AKTIVITÄTEN -
SOFTWARE QUALITÄT
Software Qualität
• Die internen Qualitätsfaktoren können nur von Computerfachleuten
wahrgenommen werden
• Modularity, Readability,...
• Die externen Qualitätsfaktoren sind letztlich die relevanten, wie sie vom
Benutzer wahrgenommen werden
• Correctness, Robustness, Extendibility, Reusability, Efficiency ...
• Attribute einer “guten Software”
• Maintainability, Efficiency, Usability, Dependability
SOFTWARE TESTING & UNIT TESTS
• Software inspections → Überprüfung der Korrespondenz zwischen einem Programm und

seiner Spezifikation häufig mittels Checkliste
• Code Review - finde Programmfehler, Standardverletzungen, schlechten Code
• Automatisiert - Source Code Analysis z.B. Control Flow Analysis, Path Analysis
• Formale Verifikation - kann die Vermeidung von spezifischen Bugs garantieren
• Software testing → bezieht sich auf das Ausführen einer Implementierung der Software mit
Testdaten, um Programmfehler zu entdecken
• Validation testing (Test Case für jedes Requirement) oder Defect testing (fault directed)
• Artefakte: Test Case, Test Suite, Test Run, Test Driver/Framework
• Fehlertypen: Failure (dt. Defekt), Fault (dt. Mangel), Error (dt. Fehler)
SOFTWARE TESTING & UNIT TESTS
• Unit tests (dt. Modultest) - Testet eine relativ kleine

ausführbare Einheit, z.B. ein einzelnes Objekt oder
eine Funktion
• Integration tests - Komplette (Sub-)Systeme,
Interfaces zwischen voneinander abhängige
Komponenten
• System tests - Eine vollständig integrierte
Anwendung
BUILD
Building: Prozess zur Umwandlung von Quellcode in ein lauffähiges Software-Artefakt

• Prozess umfasst typischerweise folgende Schritte (Reihenfolge kann variieren):
• Compiling, z.B. Erstellung einer ausführbaren Datei
• Packaging, z.B. Installation benötigter Softwarepakete
• Testing, z.B. Ausführung von Unit und Integration Tests
• Automatisierung dieses Prozesses => Continuous Integration/Continuous Delivery
Continuous Integration
Continuous Delivery
CI / CD
Commit Build Unit Test Package Component Test
• Continuous Integration (CI):
Prozess des fortlaufenden
Zusammenfügens von Komponenten Continuous Integration
zu einer Anwendung
Deploy INT Smoke Test Functional Test
• Continuous Delivery (CD):
Continuous Deployment
Sammlung von Techniken, Prozessen
und Werkzeugen, die das Deployment Deploy STAGE Smoke Test Manual Test - QA
verbessert
Deploy PROD Smoke Test

Continuous Delivery
Automated
ÜBERBLICK ZUM
ENTWICKLUNGSPROZESS
Beispiel Pipeline mit CI / CD Tools:
Run
Code Build Package Deploy Operate
Developers
(Agility)
Jenkins Artifactory Terraform

Operators ...
(Stability)
...
PRAXIS 2: BUILD
Code for practical ITPM lectures offered by Software & Digital Business Group at
Technical University of Darmstadt: https://github.com/timo-koppe/itpm-lecture
In order to run the automated build process, you will have to create a Github
account and fork (i.e., copy) the repository to your own account. In this second
exercise we will cover the following aspects:
• Unit testing the grade calculator
• Packaging the grade calculator app
• Automating the build process using CI tools offered by Github
FRAGEN?
Koppe, Timo
+49 6151 16-25754

IT-PROJEKTEN
LEHREVALUATIONSLINK
https://evaluation.tu-darmstadt.de/evasys/online.php?pswd=ZX4H3.
ÜBERBLICK ZUM
ENTWICKLUNGSPROZESS
Run
Developers
(Agility)
Jenkins Artifactory Terraform

Operators ...
(Stability)
...
ÜBERBLICK
VL08
Example - Source:
https://www.cnbc.com/2023/01/25/
microsoft-investigating-teams-and-
outlook-outage-as-users-report-
issues.html
IT OPERATIONS MANAGEMENT
• Das IT-Betriebsmanagement (IT Operations Management)

übernimmt das Tagesgeschäft zur Verwaltung und
Aufrechterhaltung der IT-Services und der IT-Infrastruktur -
ITIL V3 Service Operation
• Operational IT failures, or failures of operational IT systems,
“can paralyze a company’s ability to make its products, deliver
its services, and connect with its customers, not to mention
foul its reputation” - Carr N 2003
• Werkzeuge: Monitoring, Logging, Diagnostics, Alerting,...
Carr N 2003 “IT Doesn’t Matter,” Harvard Business Review (81:5), 5-12.
PRAKTIKEN – CI / CD
Run
Developers
(Agility)
Kontinuierliches Ausliefern von Code Betriebspraktiken
Jenkins Artifactory Terraform Operators ...

(Stability)
...
Develop
Operate
PRAKTIKEN - DEVOPS
• DevOps, aus dem Kontext der agilen Software-Entwicklung,

ermöglicht die kontinuierliche Bereitstellung und den Einsatz Development QA
funktionierender Software in kleinen Releases DevOps
• Erich et al. (2014); "Die Automatisierung von DevOps wird

durch verschiedene Entwurfsmuster unterstützt, die die
Operations
kontinuierliche Bereitstellung von Softwareanwendungen auf
der Cloud-Plattform verbessern".
MUSTER / PATTERN
• Patterns sind herausgelöste Gemeinsamkeiten, die man in Programmen

findet
• Ziel: Große komplexe Struktur zu dekonstruieren und mit einfachen Teilen Beispiel: singleton
pattern ist ein
aufzubauen. Es bietet eine allgemeine Lösung für eine Klasse von Problemen. Software Design
Pattern, das die
• Komplexe Software durchläuft eine Reihe von “Zerlegung / Abstraktionen” auf Instanziierung einer
verschiedenen Ebenen Klasse auf eine
"einzige" Instanz
• Auf der großen Ebene sind Architekturpattern (d.h. grundlegende strukturelle einschränkt
Organisation für Softwaresysteme), auf kleinerer Ebene sind Designpattern

(d.h. löst wiederkehrende Probleme in der Software-Konstruktion) wichtige
Arbeitsmittel
MUSTER / PATTERN
“An architectural pattern is a general, reusable solution to

a commonly occurring problem in software architecture
within a given context. Architectural patterns are similar to
software design pattern but have a broader scope. The
architectural patterns address various issues in software
engineering, such as computer hardware performance
limitations, high availability and minimization of a business
risk. Some architectural patterns have been implemented
within software frameworks.”
BEISPIEL DESIGN MUSTER:

MODEL VIEW CONTROLLER (MVC)
• MVC unterteilt eine Software in drei
Komponenten als flexibler
Programmentwurf, der eine spätere
Änderung oder Erweiterung erleichtert
und eine Wiederverwendbarkeit der
einzelnen Komponenten ermöglicht
• De-facto-Standard für den Grobentwurf
vieler komplexer Softwaresysteme
APPLICATION PROGRAMMING
INTERFACE (API)
• APIs verbinden Anwendungen miteinander, so dass
Unternehmen Software leichter zu neuen Produkten
kombinieren können
• APIs (bspw. Web API) sind zum De-facto-Standard für den
Aufbau und die Verbindung moderner Systeme und
Anwendungen in der Cloud geworden
• API-Plattformen bieten die Technologie um eine Reihe von
Anwendungsprogrammier-Schnittstellen, bspw. innerhalb einer
Geschäftsumgebung effektiv freizulegen, zu nutzen, zu
monetarisieren und anderweitig zu steuern Beispiel: Google Vision AI API
MONOLITHIC, SOA UND

MICROSERVICES
Monolithic SOA Microservices
ARCHITEKTURMUSTER:
SERVICEORIENTIERTE ARCHITEKTUR
• Service Oriented Architecture (SOA) ist ein Paradigma für die
Strukturierung und Nutzung verteilter Funktionalität, die von
unterschiedlichen Besitzern verantwortet wird.
(vgl. OASIS 2006)
• Im Fokus steht die Definitionen sind von Diensten mit
Eigenschaften wie standardisierter Service-Beschreibung, lose
Koppelung, Abstraktion, Wiederverwendbarkeit und Autonomie
• SOA ist eine Sichtweise, die auf verschiedene Arten
interpretiert werden kann bspw.: SOAP, OSGi
ARCHITEKTURMUSTER:
MICROSERVICES
- Microservice Architectural-Style ist ein Ansatz zur Entwicklung einer
einzelnen Anwendung als eine Reihe kleiner Dienste, die jeweils in
einem eigenen Prozess laufen und mit leichtgewichtigen Mechanismen
kommunizieren, häufig einer HTTP-Ressourcen-API
- Microservice Merkmale:
- Stateless/Ephemeral
- Unabhängig: "Kann ich den Dienst aktualisieren und veröffentlichen,
Microservices
ohne etwas anderes zu zerstören?”
- ...
MONOLITHIC, SOA UND

MICROSERVICES
Monolithic SOA Microservices
Nachteile: Nachteile: Nachteile:

Coupling Issues, Build-test-deploy der Aggregation Layer (SOA BUS) schwer Payloads und Latency, erhöhte
gesamten Codebase, Lange Go-Live zu handhaben, Error Handling (200 Netzwerkkommunikation, “Distribution
Dauer, “Bad” Agility und Scaling,... oder 500)... Tax”...
EINFÜHRUNG IN CLOUD-
PLATTFORMEN UND CLOUD-
SERVICES / WEB-APIS
BEREITSTELLUNGSMODELLE VON
CLOUD COMPUTING
Private Cloud Private Cloud Community Cloud
Exclusive use by a single organization comprising multiple Customer
Customer
consumers Customer Customer
May exist on or off premises Shared
Data
Data
Centre
Public Cloud Centre
Open use by the general public

Exists on the premises of the cloud provider
Community Cloud
Exclusive use by a specific community of consumers that have Public Cloud Hybrid Cloud
shared concerns
Customer
Hybrid Cloud Customer
Cloud infrastructure is a composition of two or more distinct Data

Centre
cloud infrastructures that remain unique entities
Mell, P., & Grance, T. (2011). The NIST definition of cloud computing [Recommendations of the National
Institute of Standards and Technology-Special Publication 800-145]. Washington DC: NIST.
SERVICEMODELLE VON CLOUD

COMPUTING
On Premises Infrastructure Platform Software
as a Service (Components) as a Service as a Service
Applications Applications Applications Applications

Data Data Data Data
Runtime Runtime Runtime Runtime
Managed by Provider
Middleware Middleware Middleware Middleware
Managed by Provider
O/S O/S O/S O/S
Virtualization Virtualization Virtualization Virtualization
Managed by Provider
Servers Servers Servers Servers

Storage Storage Storage Storage
Networking Networking Networking Networking
CONTAINER UND
INFRASTRUCTURE AS CODE
Container sind eine Methode zum “Packaging” einer ausführbaren
Anwendung und ihrer Abhängigkeiten (Laufzeit, Systemwerkzeuge,
Systembibliotheken, Konfiguration) und zur Ausführung des Pakets
als eine Reihe von ressourcen-isolierten Prozessen.
Infrastructure as Code stellt IT-Infrastrukturleistungen wie

Rechenleistung, Speicher und Netzwerk auf Basis von
maschinenlesbarem Code zur Verfügung. Die Infrastruktur wird
ähnlich wie Software programmiert
PRAXISBEISPIEL: CLOUD
COMPUTING BEI MERCK
Encryption & Integration Architecture
On-premise
SaaS applications
usw.
On-premise
HANA
Cloud
Platform
infrastructure
PaaS
Collaboration & In-memory
productivity Application platform application platform
HANA
Enterprise
Cloud
IaaS
Infrastructure as a Infrastructure as a ERP hosting as a
service service managed service
WICHTIGE META SKILLS
• Die Wahl der Programmiersprache und

Entwicklungsumgebung
• Code lesen und verstehen
• Einarbeitung in neue Technologien
• Aktuelle Trends in der Softwareentwicklung
❏ Pragmatic Programmer von Andy Hunt und Dave Thomas

❏ What Every Developer Should Learn Early On (https://stackoverflow.blog/2019/08/07/what-every-developer-should-learn-early-on/)
❏ 2020 Stack Overflow Developer Survey (https://insights.stackoverflow.com/survey/2020)
❏ Clean Code von Robert C. Martin
“In general, language choice is usually one of the least important issues for a project. (...) There’s only one non-
negotiable rule I have. I refuse to use languages that don’t have most of the problems I will encounter,
directly solved on StackOverflow.”
https://stackoverflow.blog/2019/08/07/what-every-developer-should-learn-early-on/
WAHL DER
PROGRAMMIERSPRACHE
• Über die Wahl der richtigen Programmiersprache werden regelrechte “Glaubenskriege” geführt
• Programmiersprachen sollten als Tools gesehen werden, wobei jedes Tool bestimmte Vor- und Nachteile hat
• In den meisten Fällen ist die Wahl der Programmiersprache nicht ausschlaggebend für den Projekterfolg
• Zu berücksichtigende Aspekte:
• Verfügbarkeit von Online-Ressourcen (z.B. StackOverflow, Dokumentation)
• Fehlertoleranz im Anwendungsfall (z.B. typisierte vs nicht typisierte Sprachen)
• Qualität und Breite bereitgestellter Pakete (z.B. Standardbibliothek)
• Erforderliche Performance
• Verfügbarkeit von Entwicklern mit erforderlichen Kenntnissen
CODE LESEN UND VERSTEHEN
“Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are
constantly reading old code as part of the effort to write new code. …[Therefore,]
making it easy to read makes it easier to write.” (Robert C. Martin)
• Jeder Programmierer entwickelt über die Zeit seinen eigenen Stil

(z.B. Benennung von Variablen, Architekturentscheidungen)
• Das macht es oftmals schwierig, den Code anderer Programmierer
nachzuvollziehen
• Den Code anderer zu lesen verbessert die eigenen Coding-Fähigkeiten
• Übung: Code interessanter Open Source-Projekte lesen und nachvollziehen
EINARBEITUNG IN NEUE
TECHNOLOGIEN
• Neue Projekte erfordern oft die Einarbeitung in neue Technologien (z.B.
Programmiersprachen, Bibliotheken oder SDKs)
• Effiziente Einarbeitung ist eine essentielle Fähigkeit, um schnell erste
Erfolge im Projekt vorweisen zu können (→ IT-Projekt)
• Vorgehen bei der Einarbeitung:
• Dokumentation finden
• Installationen durchführen
• Tutorials ausprobieren
• Guides lesen
TECHNOLOGIEN
● Nach der ersten Einarbeitung kann das Gelernte
auf den eigenen Anwendungsfall übertragen

werden
● Dokumentation der Technologie sollte dabei
immer als wichtige Referenz dienen

● Bei tiefergehenden Fragen kann man sich zumeist
auf Entwickler-Communities wie Stackoverflow

stützen
AKTUELLE TRENDS IN DER

SOFTWAREENTWICKLUNG
FRAGEN?
Koppe, Timo
+49 6151 16-25754

IT-PROJEKTEN
LEHRVERANSTALTUNG
Stakeholder
• wichtige Meta-Skills für die Einarbeitung und Bearbeitung von
Programmierprojekten im Rahmen des IT-Praktikums zu kennen
• verschiedene Datenbanktechnologien und ihre Anwendungen
zu kennen

Steuerung abschluss
ment
Projektteam
W
ie
de
rh
ol
WICHTIGE META SKILLS
un
g
• Die Wahl der Programmiersprache und
Entwicklungsumgebung
• Code lesen und verstehen
• Einarbeitung in neue Technologien
• Aktuelle Trends in der Softwareentwicklung
❏ Pragmatic Programmer von Andy Hunt und Dave Thomas

❏ What Every Developer Should Learn Early On (https://stackoverflow.blog/2019/08/07/what-every-developer-should-learn-early-on/)
❏ 2020 Stack Overflow Developer Survey (https://insights.stackoverflow.com/survey/2020)
❏ Clean Code von Robert C. Martin
W
ie
de
rh
ol
un
g
“In general, language choice is usually one of the least important issues for a project. (...) There’s only one non-
negotiable rule I have. I refuse to use languages that don’t have most of the problems I will encounter,
directly solved on StackOverflow.”
https://stackoverflow.blog/2019/08/07/what-every-developer-should-learn-early-on/
W
ie
de
rh
ol
WAHL DER
un
g
PROGRAMMIERSPRACHE
• Über die Wahl der richtigen Programmiersprache werden regelrechte “Glaubenskriege” geführt
• Programmiersprachen sollten als Tools gesehen werden, wobei jedes Tool bestimmte Vor- und Nachteile hat
• In den meisten Fällen ist die Wahl der Programmiersprache nicht ausschlaggebend für den Projekterfolg
• Zu berücksichtigende Aspekte:
• Verfügbarkeit von Online-Ressourcen (z.B. StackOverflow, Dokumentation)
• Fehlertoleranz im Anwendungsfall (z.B. typisierte vs nicht typisierte Sprachen)
• Qualität und Breite bereitgestellter Pakete (z.B. Standardbibliothek)
• Erforderliche Performance
• Verfügbarkeit von Entwicklern mit erforderlichen Kenntnissen
W
ie
de
rh
ol
CODE LESEN UND VERSTEHEN
un
g
“Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are
constantly reading old code as part of the effort to write new code. …[Therefore,]
making it easy to read makes it easier to write.” (Robert C. Martin)
• Jeder Programmierer entwickelt über die Zeit seinen eigenen Stil

(z.B. Benennung von Variablen, Architekturentscheidungen)
• Das macht es oftmals schwierig, den Code anderer Programmierer
nachzuvollziehen
• Den Code anderer zu lesen verbessert die eigenen Coding-Fähigkeiten
• Übung: Code interessanter Open Source-Projekte lesen und nachvollziehen
W
ie
de
rh
ol
un
g
TECHNOLOGIEN
• Neue Projekte erfordern oft die Einarbeitung in neue Technologien (z.B.
Programmiersprachen, Bibliotheken oder SDKs)
• Effiziente Einarbeitung ist eine essentielle Fähigkeit, um schnell erste Erfolge im Projekt
vorweisen zu können (→ IT-Projekt)
• Vorgehen bei der Einarbeitung:
• Dokumentation finden
• Installationen durchführen
• Tutorials ausprobieren
• Guides lesen
W
ie
de
rh
ol
un
g
TECHNOLOGIEN
● Nach der ersten Einarbeitung kann das Gelernte auf den
eigenen Anwendungsfall übertragen werden
● Dokumentation der Technologie sollte dabei immer als
wichtige Referenz dienen
● Bei tiefergehenden Fragen kann man sich zumeist auf
Entwickler-Communities wie Stackoverflow stützen
W
ie
de
rh
ol
AKTUELLE TRENDS IN DER
un
g
SOFTWAREENTWICKLUNG
DATENHALTUNG UND
DATENMANAGEMENT
DATENHALTUNG UND DATENMANAGEMENT
DATENMANAGEMENT UND BIG DATA
Das weltweite Datenvolumen verdoppelt sich laut aktuellen Prognose zum weltweit generierten Datenvolumen 2025
Berechnungen alle zwei Jahre à „Big Data“
200
• Ein Begriff, der die technologischen Entwicklungen im Bereich der 181
Datensammlung und –verarbeitung zusammenfasst 180
160
• Große Datenmengen und unterschiedliche Formate können in
Datenvolumen in Zettabyte
140
kurzer Zeit verarbeitet werden
120
100
Kaum eine Anwendung kommt ohne Datenbanken aus 80
64,2
• ERP-Systeme 60
40
• Warenwirtschaftssysteme
20 6,5
• Datenbanken von Onlineshops
0
• … 2012 2020 2025*
Hinweis(e): Weltweit, Quelle(n): IDC; ID 267974
Ex
ku
r s
FERTIGUNGSDATEN EXPLODIEREN IN
ALLEN UNTERNEHMENSFUNKTIONEN
22ZB Equipment Sensor Data Sales and Pricing Analytics Engineering Simulations
Predictive Maintenance Inventory Optimization Supply Chain Insights
Digital Asset and Process

Real-Time Machine Data …
Twin
4ZB
1% 75% 18
2018 2025
Of data gathered Of IoT Months recommended
is properly initiatives target paypack period3
Manufacturing Datasphere
Growth4
analyzed1 are failing2
Source: Google Cloud
20.06.23 FB01 | Software

1: Straight Talk About Big Data, McKinsey , 2: 75% of IoT projects are failing&due
Digital Business
to lack | Dr. rer.
of expertise, pol. Timo
Business Koppe3: Internet of Things Primer 2018, Gartner, 4: IDC Data Age 2025 study (2018)
Journal, 12
GRUNDBEGRIFFE DER
DATENORGANISATION
• Datenfeld oder Datenelement: Kleinste logische Dateneinheit, auf die zugegriffen wird.
• Inhaltlich zusammenhängende Datenfelder werden zu Datensätzen zusammengefasst.
• Alle gleichartigen Datensätze werden in einer Datei gespeichert.
Datei
Datensatz Artikelnummer Artikelname Warengruppe Artikelpreis
Datenfeld Quelle: Mertens et al. (2012), S. 39
DATEIVERARBEITUNG
• „Traditionelle“ Dateiverarbeitung als „alternative“ der

Datenbanktechnik ist die
• Anwendungsprogramme greifen auf Dateien zu, in denen die zu
verarbeitenden Daten enthalten sind. (Dateisystem)
• Datenverwaltung wird vollständig im Rahmen der
Anwendungsprogramme durchgeführt, beispielsweise Einfügen, Apps Services
Löschen oder Ändern von Daten, Speicherverwaltung etc.
• Datenbanken erlauben eine „anwendungsübergreifende“ Nutzung

der Daten über eine Schnittstelle.
DATENBANKSYSTEME
• Relationale und nicht-relationale Datenbanken sind zwei Hauptkategorien von

Datenbanksystemen, die zur Speicherung und Verwaltung von Daten verwendet werden.
• Es gibt auch hybride Datenbanken, die Elemente von relationalen und nicht-relationalen
Datenbanken kombinieren. Viele der Begriffe sind nicht klar voneinander zu trennen…
Beispiele:
Non-Relational Databases
In- Data
Relational Databases …
memory warehouse Column-
Document Key-value Graph
oriented
Traditional Mainly Cloud-native/Distributed
Ex
ku
sr
DATABASE-AS-A-SERVICE
Caching
Manage
Relational
Block
Database- Storage
as-a
Service
Manage
Data Object
Storage
Warehouse
NoSQL NoSQL
(Keyvalue) (Indexed)
The Forrester Wave™: Database as a Service, Q2 2019. The Forrester Wave™ is copyrighted by
Forrester Research, Inc. Forrester and Forrester Wave™ are trademarks of Forrester Research, Inc. The Forrester
Wave™ is a graphical representation of Forrester's call on a market and is plotted using a detailed spreadsheet with
exposed scores, weightings, and comments. Forrester does not endorse any vendor, product, or service depicted in
the Forrester Wave. Information is based on best available resources. Opinions reflect judgment at the time and are
subject to change.
DATENHALTUNG UND DATENMANAGEMENT - RELATIONALE DATENBANKSYSTEME
GRUNDLAGEN RELATIONALER
DATENBANKSYSTEME
• Geht zurück auf die Entwicklung von Edgar Codd aus 1970
à Ist aber immer noch „State of the art“!
• Daten werden in zweidimensionalen Tabellen (=Relationen) dargestellt
die eine feste Anzahl von Spalten und eine beliebige Anzahl von Zeilen
haben können.
Begriff Bedeutung (nicht formal)

Attribut Spalte einer Tabelle
Wertebereich Mögliche Werte eines Attributs (auch Domäne)
Attributwert Element des Wertebereichs
Relationsschema Menge von Attributen
Tupel Zeile einer Tabelle
Relation Menge von Zeilen einer Tabelle Quelle der Tabelle: Heuer, A.; Saake, G. (2008): Datenbanken:
Konzepte und Sprachen, 3. Auflage, mitp-Verlag, S. 115.
BEGRIFFE AM BEISPIEL EINER

RELATION KUNDE
Relationenname Attribute
Kunde
Kunden-
nummer
Name Str. PLZ Ort Kontonr. BLZ Rabatt
in % Relations-
25 Honeywell Lindenstr. 1 08150 Adorf 0312951252 50070010 20 schema
64 IBM Buchenstr. 2 12345 Berlin 3251880820 12070000 10

Tupel
34 Sony Eichenweg 3 67895 Frankfurt 2365800150 50040000 23
54 Schenker Eschenplatz 4 15007 Ratingen 0254650500 61011000 0
23 Epson Kaktusallee 5 32489 München 1259025000 51090024 NULL
53 Microsoft Tulpengasse 7 15894 Hamburg 1584034500 75030000 10

SPEZIELLER ATTRIBUTTYP:
SCHLÜSSEL
• Schlüssel: Minimale Menge von Attributen, deren Kunde
Werte ein Tupel einer Tabelle eindeutig Kunden-
nummer
Name Str. PLZ Ort Kontonr. BLZ Rabatt
in %
identifiziert.
25 Honeywell Lindenstr. 1 0815 Adorf 0312951252 50070010 20
• Primärschlüssel: Ein beim Datenbankentwurf 0
ausgezeichneter Schlüssel. In unserem Beispiel 64 IBM Buchenstr. 2 1234

5
Berlin 3251880820 12070000 10
ist die Kundennummer Primärschlüssel der 34 Sony Eichenweg 3 6789 Frankfurt 2365800150 50040000 23
5
Relation Kunde (Kennzeichnung durch
Unterstreichung).
• Fremdschlüssel: Attributmenge, die in einer
BLZ Name der Bank
anderen Relation ein Primärschlüssel ist.
Bank
• Zusammengesetzte Primärschlüssel: 50070010 Deutsche Bank
Kombination aus mehreren zusammengesetzten 12070000 Deutsche Bank
Attributen (eindeutig identifizieren).

50040000 Commerzbank
NORMALISIEREN VON RELATIONEN
Eine Relation entspricht einer Normalform, wenn sie bestimmte „Universum“ der Relationen
Bedingungen erfüllt: ersten Normalform (1NF), 2NF,… 5NF 1NF
2NF
Vorteile / Ziele der Normalisierung: 3NF
• Redundanzfreie Speicherung: Jedes Faktum ist nur einmal in der BCNF
Datenbank gespeichert 4NF
• Generierung von "lesbaren" Relationen à Normalisierung wird 5NF
durch Zerlegung von Relationen erreicht.

Nachteile der Normalisierung:
• Normalisierungsaufwand
• Schlechteres Laufzeitverhalten bei der Zusammenfügung (Join)
mehrerer Relationen
ACID
ACID ist ein Akronym für Atomicity, Consistency, Isolation und Durability und
repräsentiert eine Reihe von Eigenschaften, die in relationalen Datenbanken
traditionell gefordert werden:
• Atomicity: Eine Transaktion wird entweder vollständig ausgeführt oder gar nicht
(keine teilweise Transaktionen)
• Consistency: Eine Transaktion bringt die Datenbank von einem konsistenten
Zustand in einen anderen konsistenten Zustand (Integritätsregeln)
• Isolation: Jede Transaktion einzeln und unabhängig von anderen Transaktionen
ausgeführt (bspw. bei mehreren Nutzern)
• Durability: Änderungen bleiben dauerhaft in der Datenbank erhalten, auch bei
einem Systemausfall
DATENHALTUNG UND DATENMANAGEMENT - ERM
DATENMODELLIERUNG MIT ERM
§ Entity-Relationship-Modell (ERM)
§ vorgeschlagen von Peter Chen 1976
§ Quasi-Standard zum Entwurf von Datenbanken
§ Abbildung eines Realitätsausschnittes mittels

eines ERM basiert auf folgenden Elementen:
Peter Chen
§ Entity (Entität)
§ Relationship (Beziehung)
§ Property (Attribut, Eigenschaft)
ELEMENTE EINES ERM
• Entity-Typen:
• Objekt (real oder abstrakt), von dessen Art Informationen zu speichern sind.
• Darstellung: Rechteck
• Beispiele: Kunde oder Artikel
• Relationship-Typ:
• Beziehung zwischen Entity-Typen (n ≥ 2)
• Darstellung: Raute
• Beispiel:
Kunde bestellt Artikel
ELEMENTE EINES ERM
• Property:
A# V# Datum Gehalt
• Eigenschaft von Entities oder Beziehungen
• Properties besitzen einen Wertebereich
• Darstellung (hier): Rechteck mit abgerundeten Ecken Angestellte/r hat Arbeitsvertrag
• Schlüssel in ERMs:
A-Name
• Für Entity-Typen kann analog zu Relationen ein
Primärschlüssel als (minimal) identifizierende Attributmenge
definiert werden.
• In der graphischen Darstellung werden die entsprechenden
Attribute unterstrichen.
• Fremdschlüssel und andere Attribute erhalten keine spezielle
Kennzeichnung
KARDINALITÄT EINES
RELATIONSHIP-TYPS
Die Kardinalität eines Relationship-Typs gibt an, in welchem
Verhältnis die Entities der beteiligten Entity-Typen
zueinander in Beziehung stehen.
Notation im Diagramm durch Beschriftung der Kanten mit 1,

m und n:
• eins-zu-eins (1:1),
• eins-zu-viele (1:n)
• viele-zu-viele (m:n)
Es gibt andere Darstellungen und zahlreiche Erweiterungen.
Ü
bu
ng
BEISPIEL ZUR ERM-MODELLIERUNG
Folgender Sachverhalt beschreibe die Verhältnisse in einer Bibliothek:
• In einer Bibliothek befinden sich zahlreiche Bücher, die jeweils von einem
oder mehreren Autoren verfasst wurden. Von einigen Autoren existieren
bereits verschiedene Bücher.
• Jedes Buch stammt von einem bestimmten Verlag (wobei die Verlage
natürlich mehrere Bücher veröffentlicht haben) und befindet sich an einem
definierten Standort. Ein (Regal-)Standort umfasst allerdings mehrere
Bücher.
• Entliehen werden die Bücher von Kunden, die mehrere Bücher ausleihen
können.
Ü
bu
ng
BEISPIEL ZUR ERM-MODELLIERUNG
Autoren# Buch#
A_Name A_Vorname
1 m
Verlag verlegt bei verfasst von Autor
n n
Verlag# V_Name Autoren#
Buch# Ersch_Jahr
Buch
Titel Auflage
Leihfrist Kunden#
n n
Standort steht an entliehen von Kunde
1 m
Buch# Name Vorname

Standort# Gebäude
Kunden# Datum
DATENHALTUNG UND DATENMANAGEMENT – ERM
ABLEITUNG VON RELATIONEN AUS

ERM-DIAGRAMMEN
• Aus einem n:m-Relationship-Typ wird eine zusätzliche Relation.
• Die resultierende Relation enthält die Primärschlüssel der beteiligten Entity-
Typen als Attribute und zusätzlich die Attribute des Relationship-Typs.
Datum Menge
K# … A# …
n m

K# … K# A# Datum Menge A# …
DATENHALTUNG UND DATENMANAGEMENT - NICHT RELATIONALE DATENBANKEN
NICHT RELATIONALE DATENBANKEN
• Nicht relationale Datenbanken (oft als NoSQL-Datenbanken bezeichnet) gibt es in verschiedenen Typen, die
jeweils für bestimmte Anwendungsfälle und Datenstrukturen optimiert sind.
• Nicht relationale Datenbanken sind in der Regel schema-flexibel oder schema-los, was bedeutet, dass sie
keine festgelegte Struktur für die Daten haben, die sie speichern.
• Sie unterstützen eine Vielfalt von Datenstrukturen, sind i.d.R. für horizontale Skalierbarkeit und hohe
Schreibdurchsätze optimiert und verwenden oft eigene Abfragesprachen oder APIs.
Non-Relational Databases
In- Data
Relational Databases …
memory warehouse Column-
Document Key-value Graph
oriented
Beispiele:
Traditional Mainly Cloud-native/Distributed

NICHT RELATIONALE DATENBANKEN
Hauptkategorien von nicht relationalen Datenbanken:

1. Dokumentenorientierte Datenbanken: Daten in Dokumenten, die meistens im JSON- oder BSON-
Format vorliegen
2. Schlüssel-Wert-Datenbanken: Daten als Schlüssel-Wert-Paare, bspw. nützlich für Caching, Session-
Management
3. Spaltenorientierte Datenbanken: Speicherung in Spalten anstatt in Reihen bspw. für
Analyticsanwendungen
4. Graphdatenbanken: Beziehungen zwischen Datenpunkten als Graphen, bspw. für soziale Netzwerke
5. Zeitreihen-Datenbanken: Speicherung von zeitlich geordneten Daten entwickelt, wie Messdaten,
Börsenkurse,…
6. Objektorientierte Datenbanken: Speicherung von Objekten wie in objektorientierten
Programmiersprachen modelliert
Ex
ku
sr
DAS CAP-THEOREM
• Das CAP-Theorem ist eine wichtige Konzeption in der Datenbankwelt, insbesondere

in Bezug auf verteilte Systeme und Cloud-Datenbanken.
• Es besagt, dass es in einem verteilten System unmöglich ist, gleichzeitig die
folgenden drei Eigenschaften vollständig zu gewährleisten:
• Konsistenz (Consistency): Alle Knoten/Replicate im System sehen immer die
gleichen Daten zur gleichen Zeit (bspw. nach einer Transaktion)
• Verfügbarkeit (Availability): Das System kann Anfragen in akzeptablen
Antwortzeiten bearbeiten.
• Partitionstoleranz (Partition Tolerance): Das System bleibt betriebsbereit, auch
wenn die Kommunikation zwischen den Knoten teilweise ausfällt.
• Beispiele: Banking-Anwendungen (CP), Domain Name System (AP),…
• „BASE“-Prinzip (= Basically Available, Soft state, Eventual consistency) bei vielen
NoSQL-Datenbanken
MANDATENFÄHIGKEIT
• Mandantenfähigkeit (auch als Multi-Tenancy bezeichnet) bezieht sich auf die Fähigkeit eines
Software-Systems mehrere unabhängige Instanzen oder „Mandanten“ (z.B. Organisation, eine
Abteilung, ein Benutzer, …) innerhalb eines einzigen gemeinsamen Systems zu unterstützen.
• In einem mandantenfähigen System teilen sich mehrere Mandanten dieselbe Anwendung oder
Datenbank, aber ihre Daten und Konfigurationen sind isoliert (kein Zugriff auf andere Mandanten)
• Mandantenfähigkeit ist besonders wichtig in Cloud-Anwendungen (z.B. SaaS) und anderen
Umgebungen, in denen viele Benutzer oder Organisationen auf ein zentrales System zugreifen.
Single-Tenancy Multi-Tenancy Multi-Tenancy
FRAGEN?
Koppe, Timo
+49 6151 16-25754
ORGANISATION UND CONTROLLING

VON SOFTWARE- UND
DIGITALPROJEKTEN
ORGANISATION UND CONTROLLING VON SOFTWARE- UND DIGITALPROJEKTEN

LEHRVERANSTALTUNG
• die Kern-Begriffe des IT-Projektportfoliomanagements zu kennen

• die Anbahnung und Planung von IT-Projekten zu verstehen
• Prinzipien der IT-Projektergebnisrechnung verstehen
• Besonderheiten von Open Source Software und Projekten zu kennen
IT-PROJEKT
PORTFOLIOMANAGEMENT (IT-PPM)
Hintergrund:
• Perspektive eines Großunternehmens / Konzerns
• Teilweise mehrere hundert IT-Vorhaben gleichzeitig
• Oftmals mehrere Tausend Projektmitarbeiter
• I. d. R. knappe Ressourcen
ð Auswahl der durchzuführenden Projekte und Programme

ð Fortwährende Steuerung und Überwachung der laufenden Projekte und Programme
Grobe Abgrenzung:
Projektmanagement Projektportfoliomanagement
Projekte richtig durchführen Die richtigen Projekte durchführen
PPM - DEFINITION
Projektportfolio:
“A project portfolio is a group of projects that are carried out under the sponsorship and/or management
of a particular organization. These projects must compete for scarce resources (people, finances, time,
etc.) available from the sponsor, since there are usually not enough resources to carry out every
proposed project which meets the organization’s minimum requirements on certain criteria such as
potential profitability, etc.”
(Quelle: Archer; Ghasemzadeh (1999), S. 207.)
Projektportfoliomanagement:
“PPM is defined in the literature as a dynamic decision process where a list of new projects are
evaluated, selected, and prioritized, while existing projects are accelerated, or terminated and resources
are allocated or de-allocated among those projects […].”
(Quelle: Ajjan; Kumar; Subramaniam, (2008), S. 3.)
PROZESSSCHRITTE IM IT-PPM
ð Prozess ist idealtypisch

ð In der Praxis häufig strikte
Trennung der Phasen
(Quelle: Archer und Ghasemzadeh (1999), S. 211)
BEISPIEL: HERAEUS
W
ie
de
rh
ol
un
g
EINFLUSSFAKTOREN AUF DIE

PROJEKTPRIORITÄT
Strategische Monetärer
Bedeutung Wert
Politische Projekt- Relativer

Motive Priorität Vergleich
Projekt- Projekt-
Risiko und Interdepen-
Flexibilität denzen
Quelle: Kunz (2007b), S. 112.
MONETÄRER WERT - VERFAHREN

ZUR BEWERTUNG DES PROJEKTES
• Rentabilitätsrechnung (ROI)1)
ROI = Gewinn / investiertes Kapital
• Payback-Verfahren2)
Payback-Periode = gesamte Investitionen / jährliche Einsparungen
• BCR-Verfahren (Benefit/Cost Ratio)3)
BCR = Nutzen des Projektes / Kosten des Projektes
• Kapitalwertverfahren4)
• Verfahren des Internen Zinsflusses5)
• Argumentenbilanz 1) Quelle: Gabler (1997), S. 3270.
• Nutzwertanalyse 2) Quelle: Phillips, J.J. u.a. (2002), S. 172.
3) Quelle: Phillips, J.J. u.a. (2002), S. 169f.
4) Quelle: Bitz, M. (1998), S. 116.
5) Quelle: Bitz, M. (1998), S. 121ff.
VORGEHENSWEISE BEI DER

VORHABENSELEKTION
Auswahlverfahren:
• Entscheidungsunterstützungssysteme
• Scoring-Verfahren
• Mathematische Optimierungsverfahren (z. B. unter Berücksichtigung von
Kapitalwerten, Risiken und Realoptionen)
• …
AUFGABENGEBIETE DES
MULTIPROJEKTMANAGEMENTS
Strategische Ausrichtung und Bewertung und Priorisierung Kontrolle von
Festlegung des von Projekten der
Budgetrahmens Projektportfolios Projektportfolios
• Strategische Ausrichtung von • Sicherstellung einer objektiven • Kontrolle der strategischen

Projektportfolios Projektbewertung Angemessenheit von
• Ausrichtung der Projektbewertung Projektportfolios
• Festlegung eines auf die
strategische Ausrichtung auf strategische Erfordernisse • Kontrolle der
abgestimmten Budgetrahmens • Bewertung von Projekt- Projektdurchführung in den
• Ermittlung von strategisch Interdependenzen bzw. – einzelnen Projektportfolios
bedeutsamen Mindestkriterien synergien • Kontinuierliche Ermittlung von
für die Projektbewertung • Ermittlung von möglichst projektbezogenen Daten
eindeutigen Projektprioritäten • Sicherung von projektbezogenem
• Zusammenstellung der Erfahrungswissen
einzelnen Projektportfolios
Quelle: Kunz (2007a), S. 436.

RESSOURCENMANAGEMENT
• Neben den finanziellen Ressourcen sind vor allem auch die personellen
Ressourcen zur Realisierung von IT-Projekten begrenzt
• Systematische Zuordnung von Mitarbeitern auf Projekte erforderlich
• Projektmitarbeiter sind häufig in einer Matrixstruktur organisiert
ð Neben Projektaufgaben müssen Linienaufgaben wahrgenommen werden
ð Konfliktpotential zwischen Linienvorgesetzten und Projektleitern
• Die Realisierbarkeit vieler Projekte hängt von der Verfügbarkeit der
benötigten Mitarbeiter ab
• Gewisses Maß an Flexibilität durch Einbeziehung externer Projektressourcen
möglich
• Ein guter Überblick über die verfügbaren und verplanten Ressourcen ist von
entscheidender Bedeutung!
• In modernen Projektorganisationen ergibt sich die Tendenz, Fähigkeiten der

Mitarbeiter (Skills) systematisch zu erfassen und in (Skill-) Profilen
nachzuhalten
• Reine Projektorganisation als Alternative zur Matrixorganisation
• Ziele:
• Flexible, effektive und effiziente Zuordnung von Mitarbeitern auf Projekte
• Vermeidung von Konflikten und internen Lobby-Aktivitäten durch
transparente Regelungen
• Systematische Personalentwicklung
Grundprinzip der reinen Matrixorganisation Grundprinzip der reinen Projektorganisation
(Quelle: Kunz (2007b), S. 221 - 223)
RESSOURCENKONFLIKTE
Projektmanagement bedeutet auch Kampf um die, für das Projekt

notwendigen Ressourcen.
Es können Konflikte zwischen

§ Abteilungen,
§ Projekten,
§ Teilprojekten,
§ Arbeitspaketen und mit der Linie
entstehen.
>> Am Projektanfang schriftliche Vereinbarungen treffen!
PROJEKTANBAHNUNG (ANGEBOT
UND AKQUISE)
• Bid or no bid
• Grobkonzept
• Erste Projektplanung
• Ermittlung der Projektkosten
• Kalkulation
• Erstellung der Angebotsunterlagen
• Angebotspräsentation beim Kunden
Projekt- ja ja ja Projekt-
Ressourcen? Know-how? Gewinn?
angebot start
nein nein nein

Projekt-
abbruch
ANGEBOTSPLANUNG -
PROBLEMSTELLUNG
Detaillierte, planbasierte Kostenschätzung aus Aufwandsgründen erst nach
Entscheidung für das Projekt sinnvoll
Erfahrungs-
werte
zu hoch Projektabbruch û
û Erfahrungsschatz ist durch hohen Innovations-
charakter von Projekten begrenzt
ü
detaillierte, realistisch
Go durch
planbasierte Kosten? Projektdurchführung
Auftraggeber
Kostenschätzung
û Zeitrahmen für Kostenschätzung ist

regelmäßig eng begrenzt
verfügbare
Zeit
zu niedrig Probleme im Projekt,
Imageschaden û
W
ie
de
rh
ol
SCHÄTZUNG AUF BASIS VON APS
un
g
Projektstrukturplan
Bottom-Up Vorgehensweise
§ Schätzung über Art und Menge der
benötigten Input-Faktoren für alle
Arbeitspakete
AP AP
§ Schätzung der Mengen durch
AP AP Bottom-Up Aggregation
§ Schätzung der Kosten durch
Bewertung der Mengen mit Preisen
Personalkosten
Betriebsstoffe Informationsgewinnung durch Expertenschätzung:
Betriebsmittel
Werkstoffe
! •
•
Mengen: Ingenieure
Kosten: Kaufleute
PREISMODELLE FÜR
PROJEKTAUFTRÄGE
Festpreisprojekt = Werkvertrag nach § 631 BGB: Aufwandsprojekt = Dienstvertrag nach § 611 BGB: Sonderfall: Aufwandsprojekte mit Obergrenze
Vertragstypische Pflichten beim Werkvertrag Vertragstypische Pflichten beim Dienstvertrag • Schlimmste Form der Projektdurchführung
(1) Durch den Werkvertrag wird der Unternehmer (1) Durch den Dienstvertrag wird derjenige, • Alle Risiken beim Dienstleister
zur Herstellung des versprochenen Werkes, welcher Dienste zusagt, zur Leistung der
• Upsidepotential existiert nicht mehr
der Besteller zur Entrichtung der vereinbarten versprochenen Dienste, der andere Teil zur
Vergütung verpflichtet. Gewährung der vereinbarten Vergütung
verpflichtet.
(2) Gegenstand des Werkvertrags kann sowohl die
Herstellung oder Veränderung einer Sache als (2) Gegenstand des Dienstvertrags können
auch ein anderer durch Arbeit oder Dienste jeder Art sein.
Dienstleistung herbeizuführender Erfolg sein.
Aufwandsprojekte lohnen sich immer dann, wenn

Festpreisprojekte lohnen sich immer dann, wenn • Anforderungen unklar und sukzessive entwickelt
• Anforderungen recht klar sind, z.B. bei einer werden sollen
Anwendungsmodernisierung bzw. Migration, • Innovative Technologien zur Evaluierung auf dem
• genaue Vorgaben bestehen (Pflichtenheft) Prüfstand stehen
• feste Budgets vorgegeben sind • Das Vorgehen bewusst iterativ und evolutionär
sein soll
SOFTWAREENTWICKLUNG ALS
AGENCY-PROBLEM
Literaturhinweis (klausurrelevant): Kapitel 2.5 „Softwareentwicklung als Agency-
Problem: Anreizkompatible Entlohnung und effiziente Kontrolle“, Seite 51-58 in
Buxmann, P.; Diefenbach, H.; Hess, T. (2015): Die Software-Industrie, 3. Aufl.,
Berlin, Springer.
OPEN SOURCE PROJEKTE

§ Unter Open-Source-Software
werden Programme verstanden,
die insbesondere die freie
Nutzung, Weitergabe und
Modifikation der Software bzw.
des Quellcodes erlauben.
§ Open Source ist sowohl eine

Entwicklungsmethode als auch
eine Lizenzierungsform für
Software.
DER OPEN SOURCE-BEGRIFF (OS)
§ Der Begriff Open Source entstand erst im Jahr 1998 mit der Gründung der Open Source
Initiative (OSI)
§ Vorher: "Free Software"
§ Eric S. Raymond: "The Cathedral and the Bazaar"
§ Kernziel der OSI-Gründer:

Richtungsänderung der Freien-Software-Bewegung und Erleichterung der Zusammenarbeit
mit Softwareunternehmen
à "Free Software" und "Open Source Software" wird überwiegend synonym verwendet
DAS COPYLEFT-PRINZIP
§ Das Copyleft erzwingt, dass eine Software auch nach Veränderung oder Erweiterung der gleichen Lizenz unterliegt.
§ Verwendet das Urheberrecht als Grundlage, um Beschränkungen bzgl. Benutzung, Modifikation und Weitergabe der Software
ausdrücklich aufzuheben.
§ Copyleft gilt als „Business-unfriendly“ da es Nutzungseinschränkungen nicht zulässt.
§ Ursprünglich wurde die "Public Domain", der Verzicht auf ein Urheberrecht, als Gegenstück zum Copyright gesehen.
(Ist im deutschen Recht nicht möglich. §29 UrhG)
§ Problem sogenannter "Public Domains": Schon eine kleine Änderung einer Public Domain Software kann bewirken, dass der
ändernde Autor das Copyright auf die Software beanspruchen kann.
§ Das Copyleft-Prinzip wird nicht nur für Software verwendet:

§ Wikipedia verwendet Lizenzen mit Copyleft-Prinzip (Creative Commons; GNU Free Document License)
§ Creative Commons ist ein Projekt zur Schaffung von Lizenzen für sämtliche Medientypen (z.B. Bücher, Filme, Musik)
SOFTWARELIZENZEN
Open Source ≠ Kostenlos
In Anlehnung an http://www.gnu.org/philosophy/categories.html und Grassmuck (2004), S. 278f
LIZENZEN IM GNU-PROJEKT
§ GNU General Public License (GPL):

§ Merkmale:
§ freier Zugang zum Quellcode
§ Recht, die Software zu kopieren und weiterzugeben
§ Freiheit, das Programm zu ändern
§ Möglichkeit, das veränderte Programm – allerdings unter denselben Bedingungen – zu verbreiten
§ Umsetzung des Copyleft-Prinzips -> Gewährleistung der Freiheit der Software auf Dauer
§ Andere Projekte, die Quellcode eines GPL-Projektes aufnehmen oder eine Programmbibliothek verlinken,
die unter der GPL steht, müssen ebenso unter die GPL Lizenz gestellt werden
§ GNU Lesser General Public License (LGPL):

§ Im Gegensatz zur GPL dürfen andere Programme gegen eine LGPL-lizenzierte Software dynamisch linken,
ohne dass das entsprechende Programm ebenfalls unter der LGPL freigegeben werden müsste.
ENTSTEHUNG VON OPEN SOURCE
§ Der Entwicklungsprozess bei Open Source Software unterscheidet sich

grundlegend von den Vorgehensweisen in kommerziellen Softwareprojekten
§ Grundprinzipien:
§ Evolutionär und verteilt: Die Entwickler arbeiten parallel an Modulen, die in schnellen
Abfolgen in Form von Releases weiterentwickelt und getestet.
§ Es gibt keine Projektleiter und Modulverantwortliche im klassischen Sinne, die
Entwicklungsziele vorgeben
§ Raymond bezeichnet diesen Entwicklungsprozess als "Basar-Modell" und stellt diesem das
sog. "Kathedralen-Modell" gegenüber, das er als Synonym für die klassische
Softwareentwicklung sieht. (Raymond 1999)
§ Teilelemente des Open Source-Entwicklungsprozesses wurden mittlerweile in Form

von Methoden der agilen Softwareentwicklung von Unternehmen aufgegriffen.
PROJEKT-GOVERNANCE
ERFOLGREICHER OS-PROJEKTE
Ziel ist die Schaffung einer Organisationsstruktur, die sowohl für Betragende attraktiv ist
Typ 1) „Rentensucher“ (Motiv: Netto-Nutzenzuwachs erzielen bspw. durch Reputation, oder Know-how):
§ Können ihre Reputation steigern, da durch die Offenheit des Quellcodes ihre Programmierbeiträge sichtbar
und belegbar sind
§ Insbesondere bei größeren Projekten führt ein Markierungssystem für Entwicklerbeiträge ("history files",
"maintainer files" und "credit files") zu Anerkennung über verschiedene Versionen hinweg
§ Reputationshebel über Beförderungs- und Abwahlmechanismus:
§ Programmierer mit guter Reputation können Unterprojekte anlegen
§ Bei erfolgreicher Projektarbeit und Anziehung fähiger Programmierer profitieren sie von den Beiträgen aller
Beteiligten
§ Abwanderung zu anderen Projekten, falls Projektleiter gute Beiträge unterdrückt oder Freunde bevorzugt
Typ 2) „Spender“ (Motiv: Informationsfreiheit, Unterstützung der "Open-Source-Idee“, Antikapitalismus, …)
ENGAGEMENT VON UNTERNEHMEN

IN OS-PROJEKTEN
§ Bei weitem nicht alle Open-Source-Projekte sind Projekte von
Hobbyentwicklern.
§ Es gibt eine Reihe von Open-Source-Projekten, in denen

Programmierer und weitere Spezialisten als Angestellte von
Unternehmen mitwirken.
§ ca. 30% der Entwickler der Open-Source-Plattform "SourceForge.net" wurden
für ihre Entwicklungsarbeit bezahlt
§ Nicht selten entsteht die Initiative zu einem Open-Source-Projekt aus

einem Unternehmen heraus:
§ Die Initiatoren des Apache-Projekts waren Mitarbeiter von Unternehmen, die
dort für den Betrieb von Web-Servern verantwortlich sind
KLAUSURHINWEISE
KLAUSURHINWEISE
KLAUSURTERMIN
STAND 26.06.23
• 26.07.2023 um 8:00-10:00 Uhr, S101/A1
• Hilfsmittel nicht erlaubt! (Ausnahme: Taschenrechner)
KLAUSURHINWEISE
KLAUSURRELEVANTE INHALTE
• Grundsätzlich sind alle Vorlesungsinhalte klausurrelevant!

• Alle Vorlesungsfolien sind klausurrelevant
• Alle drei Gastvorträge sind klausurrelevant
• Zusätzlich klausurrelevante Pflichtliteratur (Verweise auf Moodle):
• Der Scrum Guide
• Kapitel 2.5 Softwareentwicklung als Agency-Problem: Anreizkompatible Entlohnung und effiziente Kontrolle aus Peter Buxmann, Heiner
Diefenbach, Thomas Hess (2015): Die Softwareindustrie: Ö̈ konomische Prinzipien, Strategien, Perspektiven, 3. Auflage, Springer (Verfügbar als
Ebook bei der ULB)
• Git - the simple guide: https://rogerdudler.github.io/git-guide/
• Web application architecture: Definition, models, types, and more: https://hackr.io/blog/web-application-architecture-definition-models-types-and-
more
• How to become a full stack web developer in 2020: https://www.freecodecamp.org/news/how-to-become-a-full-stack-web-developer-in-2020/
KLAUSURHINWEISE
ÜBUNGSAUFGABE NR. 1
Themenbereich: Einführung in das IT-Projektmanagement – Vorgehensmodelle
Frage: Nennen Sie jeweils zwei Vor- und Nachteile von sequentiellen Vorgehensmodellen, die
Sie in der Vorlesung kennengelernt haben. (4 Punkte)
Sequentielle Vorgehensmodelle - Lösung: (je Stichwort = 1 Punkt; max. ∑ 4 Punkte)

Vorteile:
…
…
Nachteile:
..
..
KLAUSURHINWEISE
Sequentielle Vorgehensmodelle - Lösung: (je Stichwort = 1 Punkt; max. ∑ 4 Punkte)

Vorteile:
Gute Planbarkeit durch klare Struktur
Effektiv bei stabilen Anforderungen
Nachteile: (2 von 3)
Einbezug der Anwender lediglich zu Beginn und Ende
Auf Änderungen kann während des Projektzeitraums nur schwer reagiert werden
Lange Zeitdauer zwischen Projektidee und Inbetriebnahme
KLAUSURHINWEISE
Themenbereich: Organisation und Controlling von IT-Projekten
Aufgabe:
Wann ist ein Projekt in Schieflage? Bitte nennen Sie die vier Kriterien.
Kriterien Lösung: (je Stichpunkt 1 Punkt;)

1. …
2. …
…
KLAUSURHINWEISE
Lösung: (je Stichpunkt 1 Punkt; Bedingung 1 Punkt = max. ∑ 5 Punkte)

Gute Kundenbeziehung
Kriterien
1. Fehlen wesentlicher Funktionen, Leistung/ Funktionalität
die für die Erreichung der Projektziele notwendig sind +
2. Verfehlen der angestrebten Qualität
3. Überschreitung von Terminen (Zeit)
4. Überschreitung der Ressourcen (Kosten)
Zeit (Termine)
+ + Projektressourcen
(Kosten)
+
Qualität
KLAUSURHINWEISE
Themenbereich: Ausgewählte Technologien für die Softwareentwicklung in IT-Projekten
Frage: Welche Bereitstellungsmodelle von Cloud Computing existieren? Bitte nennen Sie die
vier Bereitstellungsmodelle, die Sie in der Vorlesung kennen gelernt haben.
Bereitstellungsmodelle - Lösung: (je Bereitstellungsmodell 1 Punkt = max. ∑ 4 Punkte)

1. …
2. …
…
KLAUSURHINWEISE
Bereitstellungsmodelle - Lösung: (je Bereitstellungsmodell 1 Punkt = max. ∑ 4 Punkte)

1. Private Cloud
2. Public Cloud
3. Community Cloud
4. Hybrid Cloud
RÜCKBLICK
ÜBERBLICK ZUR VERANSTALTUNG
Organisation
Steuerung abschluss
Projektmanage-
Projekt ment
FRAGEN?
Koppe, Timo
+49 6151 16-25754

ITP Merged

Uploaded by

Copyright:

Available Formats

You might also like

ITP Merged

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ITP Merged

Uploaded by

Copyright:

Available Formats

Management of

Machine Learning Products

Dr. Adrian Engelbrecht

› Goals of B2B Software Vendors

› Products over Projects

Scalability Target Markets

Products over Projects

Product Management Project Management

› In product management, there are two

„The most important thing is

Based on Inspired by Marty Cagan (2018)

Risks are mostly tackled in product discovery, which

Based on Inspired by Marty Cagan (2018) https://www.gv.com/sprint/

› Developing new vs. Extending existing Products

› Machine learning products are more than just

"One big category that I think could be massively affected

› Serviceware enables customers to use state-of-the-art models with minimal efforts

› General Purpose Models vs. Specific Models

› Combining Data to Feed Your LLM:

Business value: Reduces volume of incoming service requests and

› Coding becomes more efficient „AI will probably most likely

Phase 1: Phase 2: Phase 3:

DEV OPS DEV OPS DEV OPS

Deliver Value Faster, Safer, Happier

Tomorrow: Project - Product

MANAGEMENT VON SOFTWARE-

VORLESUNG UND PRÜFUNG

S 103 / 123 Ankündigungen

VORLESUNG UND PRÜFUNG

Anmeldung zur Vorlesung und Klausur

• Grundlagen der Wirtschaftsinformatik in den Bereichen

AUFBAU DER VERANSTALTUNG

1 Einführung in das Management von Software-

2 Grundlagen Informationssysteme und 7 Software Development - Praktiken, Tools,

IT Organisationen und Betriebswirtschaftliche Software Development - Build, Operate und

Projektmanagement von Software- und Management von Software- und

5 Agiles Projektmanagement 10 Software Development - Datenhaltung und

ZIELSETZUNG DER HEUTIGEN

• eine Einordnung und Erläuterung des Begriffs "Projekt" geben zu können,

Software birgt aufgrund ihrer Immaterialität,

Welche der folgenden Beispiele sind Projekte?

Betreuung der Kunden eines Marktsegments

Verwaltung einer Immobilie

Verwaltung einer Menge von Aktien

Welche der folgenden Beispiele sind Projekte?

Projekt Portfolio-Management Service

Einführung einer betrieblichen

Erstellen einer Bachelorarbeit

Ein Programm ist eine Menge von miteinander in Beziehung stehenden

WAS VERSTEHT MAN UNTER

• Projektführung im Sinne von Planung, • Projektführung

Stakeholder sind Individuen und Organisationen, die entweder aktiv in

• Sie haben Einfluss auf die Projektziele und -ergebnisse

• Das Projektmanagementteam sollte die Anforderungen und Erwartungen der

Projekt- Beteiligte Projekt-

Öffentlichkeit Politik Betriebsrat ...

PROBLEME BEI IT-PROJEKTEN

Viele IT-Projekte werden nicht erfolgreich abgeschlossen