aus Wikipedia, der freien Enzyklopädie

Management von Softwareprojekten

[Bearbeiten] 1. Einleitung und Grundlagen

[Bearbeiten] 1.1 Motivation

Viele Softwareprojekte schlagen fehl, nur 2% werden ohne größere Probleme eingesetzt (US-Regierung, 90) und nur 12% haben keine Kostenabweichungen (Feyhl u. Feyhl, 96). 84% der Projekte entsprechen nicht den Anforderungen (Standish Group, 97). 94% bedürfen eines neuen Anlaufs (Glass, 99).

Ziel des Kurses: Was ist gutes Projektmanagement

[Bearbeiten] 1.2 Überblick über den Aufbau des Kurses

[Bearbeiten] 1.3 Zum Begriff des Softwareprojektes

[Bearbeiten] 1.3.1 Was ist ein Projekt

• zeitliche Begrenzung
• klare Aufgabendefinition
• hohe Komplexität
• Konkurrenz um begrenzte Mittel
• mehrere beteiligte Stellen
• vorgegebener Kostenrahmen
• Lösbarkeit der Aufgabe

[Bearbeiten] 1.3.2 Was ist ein Softwareprojekt?

• Neuentwicklung: Unterarten:
  • Einzelentwicklung
  • Entwicklung für eine kleine Anwendergruppe
  • Entwicklung für einen anonymen Markt

• Auswahl und Anpassung von COTS-Software

• Prozessanalyse

• Wartung, Weiterentwicklung, Integration

[Bearbeiten] 1.3.3 Was sind die Unterschiede zu anderen Projekten

• Aufwands- und Kostenschätzungen sind schwierig
• Der Entwicklungsfortschritt ist schwer abzuschätzen
• Eine projektbegleitende Qualitätssicherung ist schwierig
• Ergebnisse und insbesondere Zwischenergebnisse sind für IT-Laien oft nicht nachvollziehbar
• Der Zusammenhang zwischen Anforderungen und Kosten ist Anwendern schwer zu vermitteln
• Unteilbarkeit der Arbeit bei der Softwareentwicklung
• Softwareprojekte sind durch einen hohen Grad der Abstraktion bei geringer Normierung gekennzeichnet
• Die Anforderungen ändern sich fortlaufend

Spannungsfeld eines Projektes Projekt - Kosten, Qualität, Zeit

[Bearbeiten] 1.4 Ziele des Managements von Softwareprojekten

Aus dem Spannungsfeld ergeben sich:

• Termine einhalten
• Kostenrahmen einhalten
• erforderliche Qualität sicherstellen

[Bearbeiten] 1.5 Teilaufgaben des Managements von Softwareprojekten

Grafik: Umfeld eines Projektes

Grafik: Ständige Managementaufgaben eines Projektleiter

• Ziele setzen und Planen
• Entscheiden
• Delegieren
• Organisieren
• Koordination
• Steuern
• Kontrollieren
• Motivieren
• Informieren und Kommunizieren

[Bearbeiten] 1.6 Vorgehensmodelle für Softwareprojekte

Grafik: Ein einfaches Vorgehensmodell

[Bearbeiten] 1.6.1 Grundidee der Vorgehensmodelle

Die Grundidee liegt in der Strukturierung von SW-Projekten, die hierarchisch gegliedert oder ablauforientiert erfolgt. Mit der Modellierung des Ablaufs der Gesamtaufgabe wird die Planung und Überwachung des Projekts gefördert.

[Bearbeiten] 1.6.2 Einordnung von Vorgehensmodellen

Vorgehensmodelle können nach ihrer erforderlichen feinschrittigen Modellierung eingeordnet werden. Das Ziel ist eine rechnergestützte Abwicklung des Entwicklungsprozesse. Beispiele sind

• Wasserfallmodell
• Spiralmodell
• V-Modell (Modell der deutschen Bundesverwaltung)

[Bearbeiten] 1.6.3 Das klassische Wasserfallmodell

Phasen:

• Analyse und Definition
• Entwurf
• Implementierung
• Test
• Einsatz und Wartung

Probleme:

1. weiterhin problematische Kontrolle des Projektfortschritts
2. Zusammenhänge zwischen Phasen werden unzureichend abgebildet
3. Testaktivitäten werden zu sehr als Phase gedacht
4. bei großen Projekten vergeht viel Zeit, bis das erste System erstellt wird

[Bearbeiten] 1.6.4 Das Wasserfallmodel mit Rücksprüngen

Gründe für Rücksprünge:

• Es werden Fehler in der vorherigen Phase entdeckt, die eine Korrektur erforderlich machen.
• Es treten neue Anforderungen an das System ein, die eine Anpassung der Ergebnisse bereitsabgeschlossener Phasen erfordern.

[Bearbeiten] 1.6.5 Projektbegleitende Qualitätssicherung

Das Wasserfallmodell nach Boehm (Boehm 1981) berücksichtigt in jeder Phase die Qualitätssicherung durch Verifikation und Validierung.

Verifikation bedeutet in diesem Kontext, die Prüfung, ob das zu entwickelnde Produkt die Sollwerte erreicht hat. Validierung meint dagegen die allgemeine Prüfung des Prüfgegenstandes im Hinblick auf den angestrebten Zweck.

[Bearbeiten] 1.6.6 Prototyping

Durch Entwicklung eines Prototypen wird frühzeitig ein lauffähiges - aber nicht einsatzfähiges - System erstellt.

• Prototyping (Softwareentwicklung): Der Prototyp wird solange erweitert, bis die Anforderungen feststehen. Anschließend wird der Prototyp verworfen. Problem: Auftraggeber sieht schon "fertiges System", weshalb noch immer so viel Aufwand?
• Evolutionäre Softwareentwicklung: Experimentelles oder exploratives Vorgehen während der Systementwicklung. Serie von Prototypen, die in die Produktivversion konvergieren. Vorteil: Benutzer aktiv integriert, Nachteil: Dokumentation muss auch mitaktualisiert werden.
  • horizontaler Prototyp: z.B. nur Benutzeroberfläche
  • vertikaler Prototyp: gesamter Ablauf für einen Teilaspekt

Achtung: Prototyping wird oft als Ausrede für unstrukturiertes Vorgehen verwendet!

[Bearbeiten] 1.6.7 Das Spiralmodell

Metamodell, welches für die einzelnen Phasen im Projektablauf wiederum einen allgemeinen Ablauf definiert.

Grafik: Grundgedanke des Spiralmodells

1. Phase: Ziele Alternativen, Rahmenbedingungen
2. Phase: Evaluierung der Alternativen und Reduktion der Risiken
3. Phase: Realisierung und Überprüfung des Zwischenprodukts
4. Phase: Planung der Projektfortsetzung

[Bearbeiten] 1.6.8 Das V-Modell

Entwicklungsstandard für IT-Systeme des Bundes. Beschreibt sehr detailliert das Vorgehen bei der Entwicklung von IT-Systemen, sowohl HW als auch SW. Unterteilung in Submodelle: Systemerstellung (SE), Qualitätssicherung (QS), Konfigurationsmanagement (KM) und Projektmanagement (PM). "V" steht für Vorgehensmodell, für die Struktur des Modells selber und für "Validierung und Verifikation"

[Bearbeiten] 1.6.9 Rational Unified Process (RUP)

Konzepte:

1. die iterative Softwareentwicklung
2. das Management der Anforderungen
3. die Verwendung komponentenbasierter Architekturen
4. die visuelle Modellierung der Software
5. die Qualitätssicherung
6. die Kontrolle der Änderungen der Software

Grafik: Überblick über die Phasen und Aktivitäten im Rational Unified Process

Phasen:

• Konzeptphase (Inception phase): Anforderungen erheben, Umfang definieren, Systemexterne Stellen und Geschäftsvorfälle identifizieren, kritische Erfolgsfaktoren, Projektrisiken, erste Aufwandsschätzung, erster Terminplan
• Ausarbeitung (Elaboration phase): Fortführung der Analyse, grobe Systemarchitektur, Projektplan, Eliminierung bedeutendster Projektrisiken, Ergebnis ist ein ausführbarer Prototyp
• Konstruktion (Construction phase): Erstellung des Systems
• Übergang in den Betrieb (Transition phase): Inbetriebnahme

Arbeitsabläufe (Workflows):

• Geschäftsprozessmodellierung (Business Modelling)
• Anforderungen (Requirements)
• Analyse und Design
• Implementierung
• Test
• Inbetriebnahme (Deployment)
• Projektmanagement
• Konfigurationsverwaltung (Configuration- & Change Management)
• Umgebung (Environment)

[Bearbeiten] 1.6.10 Extreme Programming

stark auf die Implementierungsaktivitäten konzentrierter Ansatz, der mit einigen Annahmen und Vorstellungen des klassischen Software Engineering bricht. Evolutionärer Prozess in kleinen Schritten

• Kleine Releases
• Planspiel (Planning Games): Planung der Releases
• Tests: automatisches Testen
• Systemmetapher
• Einfacher Entwurf
• Refaktorisierung
• Dokumentation
• Programmieren in Zweierteams
• Gemeinsames Code-Eigentum
• Kontinuierliche Code-Integration
• Geregelte Arbeitszeiten
• Kundenvertreter im Team
• Programmierrichtlinien

[Bearbeiten] 2 Die organisatorische Seite eines Projektes

siehe auch Aufbauorganisation, Ablauforganisation

[Bearbeiten] 2.1 Motivation und Einführung

• Aufbauorganisation

Verschiedene Formen: funktionsorientierte Organisation, produkt- oder branchenbezogenen Organisation

• Ablauforganisation

[Bearbeiten] 2.2 Grundlagen der Aufbauorganisation

[Bearbeiten] 2.2.1 Arten der Koordination

Koordination durch:

1. gegenseitige Abstimmung
2. persönliche Weisung
3. Standardisierung der Arbeitsprozesse
4. Standardisierung der Arbeitsprodukte
5. Standardisierung der Qualifikation der Mitarbeiter

[Bearbeiten] 2.2.2 Prozess des Bildens der Aufbauorganisation

Vorgehensweise zur Definition einer Aufbauorg.: zuerst Aufgabenanalyse, dann Aufgabensynthese

Aufgabenanalyse-Merkmale:

• Verrichtung
• Objekt
• Rang
• Phase
• Zweckbeziehung

Stellenbildung, Stellenplan

[Bearbeiten] 2.3 Die Organisation des Unternehmens

Zentralisierung nach Verrichtung oder Zentralisierung nach Objekt. Organisation nach Produkten ermöglicht Profit-Center und Outsourcing.

[Bearbeiten] 2.4 Einordnung des IT-Bereichs in die Aufbauorganisation

IT-Abteilung hat bereichsübergreifenden Charakter. Daher Einordnung neben den Produkt/Funktionsbereichen, je nach strategischer Bedeutung der IT als eigene Abteilung oder etwa unter "Verwaltung".

Zentralisierung/Dezentralisierung. Verschiedene Trends je nach verfügbarer Hardware, Sicherheitsstandard, Integrationsstand, ...

[Bearbeiten] 2.5 Interne Aufbauorganisation des IT-Bereichs

strategische Aufgaben, Entwicklung und Betrieb von HW und SW, Informationsmanagement

[Bearbeiten] 2.5.1 Chief Information Officer (CIO)

Rolle: "ist verantwortlich für unternehmensweite IV-Strategien, -Standards und -Koordination sowie für die Personalführung im IV-Bereich [...]. Rollen des CIO werden u.a. als Futurist, Stratege, Innovator, Technologe, aktiver Veränderer und Führungskraft umschrieben", Qualifikation: Technologie, Management, Fachwissen aus den Abteilungen.

[Bearbeiten] 2.5.2 Hauptabteilungen

Grafik: Aufbauorganisation der IV-Abteilung

Systembetrieb, Systementwicklung, Benutzer-Servicezentrum

[Bearbeiten] 2.5.3 Sonstige IT-Abteilungen

Datenbank-Administration, Methoden und Verfahren, Standardisierung, Telekommunikation und Netze, Technologische Strategie und Innovationen, IV-Controlling, Qualitätssicherung

[Bearbeiten] 2.5.4 Organisation eines Softwarehauses

Funktions- und Branchenorientierte Organisation

[Bearbeiten] 2.6 Integration von Softwareprojekten in die Aufbauorganisation

[Bearbeiten] 2.6.1 Reine Projektorganisation

Mitarbeiter sind fachlich und disziplinarisch dem Projektleiter unterstellt. Vorteile/Nachteile

[Bearbeiten] 2.6.2 Einfluss-Projektorganisation

Projektleiter hat nur koordinierende Funktion.

[Bearbeiten] 2.6.3 Matrix-Projektorganisation

"Die Projektleitung ist für die Projektplanung, -überwachung und -steuerung verantwortlich (Vorgehensverantwortung); für die projektbezogenen fachlichen Aufgaben sind die Linieninstanzen verantwortlich. Die Projektmitarbeiter werden temporär in die Projektgruppe delegiert; sie unterstehen fachlich der Projektleitung, disziplinär ihrem Linienvorgesetzten."

[Bearbeiten] 2.6.4 Zwischenformen der Projektorganisation

Ausgleich durch gezielte organisatorische Mittel, etwa Kontaktpositionen. Arbeitskreise, ständige Ausschüsse, Perojektlenkungsausschuss, Beauftragter.

[Bearbeiten] 2.6.5 Integration der Auftraggeber

[Bearbeiten] 2.7 Projektinterne Aufbauorganisation

Bei größeren Projekten nötigt. Typische Gruppengröße: sieben Mitarbeiter

[Bearbeiten] 2.7.1 Projektleiter und Projektadministrator

Grafik: Spannungsfeld des Projektleiters

Anforderungen:

• Projektleiter <-> Kunde
• Projektleiter <-> Benutzer
• Projektleiter <-> Management
• Projektleiter <-> Mitarbeiter

Aufgaben:

• Planung, Steuerung und Kontrolle des Projektes
• Erstellung des Projekthandbuches und -plans (Aufwand, Termine und Einsatzmittel) basierend auf den Projektzielen und den organisatorischen Rahmenbedingungen
• Vorbereitung und Durchführung von Ausschreibungen
• Überwachung der Vertragserfüllung
• Durchführung von Kosten-Nutzenanalysen
• vorbereitung und Begleitung von Durchführungsentscheidungen
• Erkennen möglicher Risiken im Projekt und einleitung geeigneter Maßnahmen
• Beauftragter der Projektmitarbeiter
• Berichterstattung gegenüber dem Projektmanager und gegebenenfalls weiteren Lenkungsgremien

Geforderte Kenntnisse und Fähigkeiten:

• Erfahurng in der Projektabwicklung
• Verständnis von betriebswirtschaftlichen Zusammenhängen
• Kenntnis über Anwendung und Einsatzgebiete des Systems
• Kenntnis über die Entwicklungsumgebung
• Kenntnis über Methoden und Werkzeuge
• Durchsetzungsvermögen und Akzeptanz bei den Projektmitarbeitern
• Fähigkeit zur Führung, Motivation und Moderation
• Fähigkeit zu Organisation und Kommunikation

Abnahme von Tätigkeiten durch einen Projektadministrator/Projektsekretär ist möglich.

[Bearbeiten] 2.7.2 Rollen im Projektteam

Rollen im V-Modell: ein Manager, ein Verantwortlicher und mind. ein Durchführender pro Submodell RUP: verschiedene Workers

[Bearbeiten] 2.7.3 Stellenbeschreibungen

Stellenplan beschreibt Stellen: Aufgaben, Ziele, Kompetenz und Verantwortung. Außerdem: Dauer, nötige Qualifikation, nötige Erfahrung, Aufgabe, Arbeitsmittel, organisatorische Einordnung, Stellvertretung, Teilzeit?

[Bearbeiten] 2.7.4 Projektinterne hierarchische Struktur

Bei Projekten mit mehr als 7 Mitarbeitern ist Aufteilung nötig. Aufteilung entweder in Teilprojekte oder Workflows.

[Bearbeiten] 2.8 Zusammenfassung

[Bearbeiten] 3 Das Softwareprojekt als Investition

Entscheidung über die Durchführung. Betrachtung der Entscheidung als Investitionsentscheidung. Aspekte:

1. Die mit einen Softwareprojekt verbundenen Kosten- und Nutzenarten
2. Verfahren der Investitionsrechnung
3. Entscheidungstechniken

[Bearbeiten] 3.1 Vorbemerkungen

Entscheidungssituationen:

1. Wahlentscheidungen
2. Programmentscheidungen

[Bearbeiten] 3.2 Kosten- und Nutzenarten

[Bearbeiten] 3.2.1 Betriebliche Kostenrechnung

Arten der Kostenrechnung:

1. die entscheidungsorientierte Zukunftsrechnung
2. die kontrollierende Vergangenheitsrechnung (Soll-Ist-Vergleich)

relevante Kosten, Kosten - Aufwand, kalkulatorische Kosten, variable Kosten - fixe Kosten, Herstellungskosten, Deckungsbeitrag, Gemeinkosten, Vollkostenrechnung, Deckungsbeitragsrechnung.

[Bearbeiten] 3.2.2 Kosten eines Software-Entwicklungsprojektes

Kostenarten nach der Art der verbrauchten Produktionsfaktoren oder Kostenarten nach betrieblichen Funktionen

Aufteilung nach Produktionsfaktoren

• Personalkoksten: Softwareentwicklung, Schulung, Administration und Wartun
• Sachkosten: HW, SW, Anteilig Gebäude und Büroeinrichtung
• Kapitalkosten: kalkulatorische Zinsen
• Kosten für Dienstleistungen Dritter
• Kosten für Steuern, Gebühren und Beiträge

Problem: Schätzung des Entwicklungsaufwandes

[Bearbeiten] 3.2.3 Nutzen eines Software-Entwicklungsprojektes

Kostenersparnis, Produktivitätsverbesserung, strategische Wettbewerbsvorteile.

[Bearbeiten] 3.2.3.1 Rationalisierungsprojekte

• Personaleinsparungen
• Einsparungen beim Material- und Zinsaufwand
• bessere Skontoausnutzung
• Produktivitätserhöhung

[Bearbeiten] 3.2.3.2 Der Aufbau von Informationssystemen

• bessere Transparenz in Abläufen
• Verkürzung von Durchlaufzeiten
• Stärkung der Ertragskraft
• bessere Controllingmöglichkeiten von Geschäftsprozessen und Abläufen
• mehr und bessere Informationen über die Mitbewerber
• besserer Kundenservice und innovative Serviceleistungen

[Bearbeiten] 3.2.3.3 Infrastrukturmaßnahmen

Vorhanden EDV-Infrastruktur an den "Stand der Technik" anpassen.

• leichtere Wartbarkeit der Systeme
• bessere Skalierbarkeit der Systeme (d.h. eine einfachere Anpassung beim Wachsen des Unternehmens)
• verringerte Entwicklungsaufwände bei künftigen Softwareprojekten, die die neue Infrastruktur nutzen können
• eine langfristige zukunftssichere Systembasis
• flexiblere Abfragemöglichkeiten

[Bearbeiten] 3.2.4 Zusammenfassung der Kosten- und Nutzenarten

[Bearbeiten] 3.3 Das Projekt als Investitionsentscheidung

Investitionsentscheidungen sind wichtige Entscheidungen,

• weil es regelmäßig um viel Geld geht (hohe Kapitalbindung)
• weil Investitionsentscheidungen nicht kurzfristig revidiert werden können (langfristige Kapitalbindung)
• weil Investitionsentscheidungen meistens Folgewirkungen für andere Planungsbereiche der Unternehmung (Finanzen, Fertigung, Personal, Absatz, usw.) mit sich bringen (Interdependenz)

Hohe Kapitalbindung, Langfristigkeit und Interdependenz sind die drei Gründe, welche dazu zwingen, Investitionsentscheidungen, besonders aufmerksam vorzubereiten. Das erfordert einen gut durchdachten Entscheidungsprozess, bei dem es darauf ankommt, die späteren Konsequenzen der sich heute bietenden Investitionsmöglichkeiten genau zu beurteilen und sorgfältig abzuwägen.

Investitionsrechnungen sind Methoden, mit denen die erwarteten Konsequenzen von Investitionen in Bezug auf quantifizierbare Interessen beurteilt werden können.

[Bearbeiten] 3.3.1 Arten von Investitionsentscheidungen

• Wahlentscheidungen
• Investitionsdauerentscheidungen
• Programmentscheidungen
• Simultane Investitions- und Finanzentscheidungen

[Bearbeiten] 3.3.2 Die Voraussetzung sicherer Erwartungen

zwei Probleme durch deterministische Investitionsrechnung:

1. Der Anwender muss möglichst genaue Schätzungen über die zukünftigen Folgen der Investitionsmöglichkeiten erarbeiten.
2. Die berechneten Ergebnisse müssen sehr vorsichtig interpretiert werden.

[Bearbeiten] 3.3.3 Die klassischen Verfahren für Wahlentscheidungen

[Bearbeiten] 3.3.3.1 Statische Verfahren

• Kostenvergleichsrechnung (Kosten)
• Gewinnvergleichsrechnung (Kosten und Erträge)
• Rentabilitätsvergleichsrechnung (Rentabilität = Gewinn / durchschn. Kapitaleinsatz * 100%)
• Amortisationsvergleichsrechnung (Wiedergewinnungszeit = Anschaffungswert / (jährl. Gewinn + Abschreibung) )

Statische Verfahren sind für die Beurteilung von SW-Projekten weniger geeignet.

[Bearbeiten] 3.4 Entscheidungstechniken

[Bearbeiten] 3.4.1 Vorgehen bei Entscheidungen

1. Zielbildungsprozess
2. Informationsprozess
3. Auswahlprozess

Phasen nach Feyhl und Feyhl:

1. Problemdefinition und Zielfixierung
2. Situationsanalyse
3. Erarbeiten von Alternativen und Vorauswahl der Alternativen
4. Bewerten der Alternativen
5. Entscheidung

[Bearbeiten] 3.4.2 Die Vollkommenheit des Informationssystems

Arten von Entscheidungen:

• Entscheidung unter Sicherheit
• Entscheidung unter Risiko
• Entscheidung unter Ungewissheit

[Bearbeiten] 3.4.5 Entscheidungen bei Unsicherheit

• Maximin-Regel
• Maximax-Regel
• Pessimismus-Optimissmus-Regel
• Regel des kleinsten Nutzenverlustes
• Laplace-Regel

[Bearbeiten] 3.4.6 Das Software-Nutzen-Portfolio

Gegenüberstellung von quantitativem und qualitativem Nutzen. (wirtschaftlicher Nutzen und strategischer Nutzen)

siehe auch Entscheidungstheorie

[Bearbeiten] 3.5 Zusammenfassung

[Bearbeiten] 4 Verfahren zur Aufwandsschätzung

[Bearbeiten] 4.1 Motivation und Abgrenzung

Basis der Investitionsentscheidung, Basis der Ressourcenplanung.

• Welchen Aufwand verursacht das Projekt
• Welche Dauer ist für das Projekt zu erwarten

[Bearbeiten] 4.2 Arten von Verfahren

1. Expertenschätzungen
2. Prozentsatzverfahren auf der Basis eines Vorgehensmodells
3. Einzelschrittschätzungen auf der Basis eines Vorgehensmodells
4. Verfahren auf der Basis des geschätzten Programmumfangs
5. Verfahren auf der Basis früherer Analyseergebnisse

[Bearbeiten] 4.3 Prozentsatzmethode

[Bearbeiten] 4.3.1 Annahmen und Vorgehen der Prozentsatzmethode

Annahme: Wasserfallmodell, Verteilund des Aufwands auf die Phasen über Projekte hinweg konstant

[Bearbeiten] 4.3.2 Einordnung der Prozentsatzmethode

Vorteile: leich zu verstehen und anzuwenden. Nachteile: projektspeczifische Einflussfaktoren werden nicht berücksichtig, "self fulfilling prohpecy", die erste Phase wird auf die gewünschte Schätzung "getrimmt"

[Bearbeiten] 4.4 Arbeitsschrittschätzung

erfordert detailliert ausgearbeitetes Vorgehensmodell.

[Bearbeiten] 4.5 COCOMO

"COnstructive COst Model" (COCOMO), Schätzung des Programmumfangs, Möglichkeit der Berücksichtigung zusätzlicher Einflussfaktoren.

Abgrenzung:

• Welche Befehle sind auszuführende Source-Befehle?
• Welche Personenmonate werden berücksichtigt?
• Welche Phasen sind Teil der Entwicklung?
• Welche Projektarten sind abgedeckt?

[Bearbeiten] 4.5.1 COCOMO-Basismodell

Beruht auf KDSI "kilos of delivered source instructions"

Weitere Schätzung: TDEV "time for development"

[Bearbeiten] 4.5.1.1 Verfeinerung nach Entwicklungsarten

1. Organisch: kleines Team, vertraut mit Werkzeugen/Umgebung
2. Eingebettet: komplexes Umfeld, Echtzeitanforderungen, nicht vertraut
3. Teilintegriert: Zwischenstufe

[Bearbeiten] 4.5.2 COCOMO-Zwischenmodell

Erweiterungen in zwei Richtungen: zusätzliche Merkmale mit Hilfe von Korrekturfaktoren, Schätzung nach Komponenten unterteilt

[Bearbeiten] 4.5.2.2 Die Weiterentwicklung existierender Software

In COCOMO Berücksichtigt die Einführung der Kennzahl EDSI, äquivalent zu KDSI. Faktoren:

• ADSI: Adapted DSI
• DM: Percent Design Modified
• CM: Percent Code Modified
• IM: Percent of Integration Required for Modified Software

[Bearbeiten] 4.5.2.3 Schätzung des Aufwands auf Komponentenebene

komponentenspezifische Werte für die Korrekturfaktoren

[Bearbeiten] 4.5.5 Anpassung an das jeweilige Unternehmen

Basisformel und Multiplikatoren für die Einflussfaktoren müssen angepasst werden. Auch eine Anpassung an die Phaseneinteilung des Vorgehensmodells ist erforderlich.

[Bearbeiten] 4.5.6 Einordnung von COCOMO

Nachteile:

• Bezug auf die Anzahl der Programmzeilen in der Ausgangsformel ist zumindest problematisch
• Der Einfluss der Korrekturfaktoren kann zu stark sein
• Die Einordnung in organisch, teilintegriert oder eingebettet ist in der konkreten Situation oft willkürlich
• COCOMO ist in seiner Grundform an ein wasserfallartiges Vorgehensmodell zur Softwareentwicklung gebunden

Stärken:

• konkrete Hilfe zur Schätzung der Parameter, Schätzung dadurch transparent und nachvollziehbar
• Schätzung kann während des Projektfortschritts konkretisiert werden
• kann für Projekte verschiedenster Größe verwendet werden
• unterstützt in besonders fundierter Form die Schätzung der Projektdauer und der Verteilung des Aufwands auf die Phasen des Projektes
• ermöglicht Sensitivitätsanalysen und Kosten-Nutzen-Analysen für Investitionen in Schulungen, CASE-Tools, ...
• betrachtet nicht nur die Entwicklung der Software, sondern auch die Schätzung des Wartungsaufwandes
• gut ausgearbeitetes Verfahren, gut dokumentiert

Weiterentwickelt als COCOMO II (http://sunset.usc.edu/COCOMOII/cocomo.html)

[Bearbeiten] 4.6 Function-Point-Analyse

Problem in COCOMO durch Schätzung aufgrund der Zahl der Programmzeilen. Andere Verfahren setzen auf relativ früh zur Verfügung stehenden ersten Analyseergebnissen im Projektablauf.

Vorteile:

1. Durch die Beschaffung der Basisdaten für die Aufwandsschätzung entsteht kein zusätzlicher Aufwand, weil die Analyseergebnisse ohnehin erarbeitet werden müssen
2. Die lästige und unsichere Schätzung der Anzahl der Programmzeilen am Anfang des Projektes entfällt. Damit wird eine viel zu frühe Betrachtung der technischen Realisierung des Systems entbehrlich

Vorgehen: Ermitteln der Roh-Function-Points durch Bewertung der Eingaben, Ausgaben, internen Daten und Schnittstellen des Systems, Bewertung der Systeminfrastruktur und anschließend die Function-Points mit Hilfe einer Umrechnungsformel in eine Aufwandsschätzung umsetzen.

[Bearbeiten] 4.6.1 Ermittlung der Roh-Function-Points

Ausgangspunkt ist das Analysemodell, welches das zu erstellende System fachlich beschreibt.

1. benötigte Elemente aus dem Analysemodell ermitteln:
   1. externe Dateneingaben
   2. externe Datenausgaben
   3. externe Datenabfragen
   4. Operationen am/mit internen logischen Datenbeständen
   5. Operationen am/mit externen Interface-Datenbeständen
2. einordnen in Komplexitätsklassen
3. Aufsummieren der Roh-Function-Points über alle betrachteten Elemente des Analysemodells

Ergebnis ist die Anzahl der Roh-Function-Points für das Gesamtsystem

[Bearbeiten] 4.6.2 Bewertung der System-Infrastruktur

14 Einflussfaktoren auf einer Skala von 0 bis 5.

Aufsummiert ergibt sich eine Gesamtkenngröße zwischen 0 und 70.

Weitere Sets von Einflussfaktoren vorgeschlagen, etwa von IBM.

[Bearbeiten] 4.6.3 Berechnung des Aufwands in PM

Formel: FPs = Roh-FPs * (0,65 + (0,01 * System-Infrastruktur))

[Bearbeiten] 4.6.4 Einordnung der Function-Point-Analyse

häufig eingesetzt, kann im Verlauf des Projektfortschritts kontinuierlich weiterentwickelt weden, Anpassung der Formeln und Faktoren ist möglich.

Unterschied zu COCOMO liegt im Bezug auf die in frühen Analyseergebnissen abgebildete Funktionalität des zu erstellenden Systems.

siehe auch Function-Point-Verfahren

[Bearbeiten] 4.8 Verknüpfung von COCOMO und Verfahren auf der Basis früherer Analyseergebnisse

Verfahren können kombiniert werden um auch bei Anwendung von Function-Point-Analyse zur Ermittlung der geschätzten Projektdauer.

[Bearbeiten] 4.9 Zusammenfassung Aufwandsschätzung

Methoden bieten die Möglichkeit, die Aufwandsschätzung strukturierter und nachvollziehbarer zu gestalten.

mögliches Vorgehen:

1. "Experten" befragen
2. mehrere Schätzverfahren unabhängig voneinander anwenden
3. Vergleich der Ergebnisse

Werkzeuge unterstützen bei der Anwendung von COCOMO oder der Function-Point-Analyse

[Bearbeiten] 5 Projektplanung und Projektcontrolling

[Bearbeiten] 5.1 Motivation

Konkretisierung der Planung, Überwachung und Steuerung des Projektfortgangs.

Planung: nach WÖHE 1996 ist Planung "die gedankliche Vorwegnahme zukünftigen Handelns durch Abwägen verschiedener Handlungsalternativen und Entscheidung für den günstigsten Weg."

langfristige Grob- oder Globalplanung zB

• Erstellung eines Organisationsmodells
• Auswahl eines Vorgehensmodells
• Aufwands- und Kostenschätzung zur Ermittlung des Ressourcenbedarfs
• Aufstellen einer Projektorganisation
• Erarbeiten von Stellenbeschreibungen
• Zuordnen von Stellen und Aufgaben im Gegensatz zu einer kurzfristigen Fein- oder Detailplanung.
• Erstellen einer Tätigkeitsliste
• Erstellen eines Projektablaufplans
• Planung des Aufwands und der Termine mit der Netzplantechnik
• Erstellung eines Kapazitätsplans

Projektplanung: "die gedankliche Vorwegnahme der Projektdurchführung sowie die Festlegung dieser Planungen (z.B. in From der Dokumentation oder von Vereinbarungen mit den Projektmitarbeitern)"

Controlling: "nicht nur Kontrolle, sondern der englischen Bedeutung des Begriffs entsprechend auch Lenkung, Steuerung oder Regelung".

Projektcontrolling ist nach SCHWARZE 1994 eine Maßnahme zur Lenkung, Steuerung, Regelung und Kontrolle eines einzuhaltenden und definierten Systemzustands.

[Bearbeiten] 5.2 Planung

[Bearbeiten] 5.2.1 Planung mit Augenmaß

Oft wird sofort ohne Planung mit den Tätigkeiten begonnen. Als Grund wird angesehen, dass Planung schnell veraltet. Das ist aber eher ein Vorteil, da die Planung relativ leich angepasst werden kann.

Um zu verhindern, dass Planung die Kreativität einschränkt sollen:

1. Ausnahmen möglich sein
2. Planung rollierend erfolgen

Symptome für zu wenig Planung:

• Es werden immer wieder hektisch Aufträge erteilt, deren Ergebnisse später niemanden interessieren
• In Entscheidungssituationen stellt sich immer wieder heraus, dass noch Vorarbeiten erforderlich sind
• Die Arbeitsbelastung im Projektteam ist über die Mitarbeiter und über die Zeit hinweg sehr ungleichmössig verteilt
• Die Mitarbeiter nehmen Vorgaben nicht mehr ernst, weil sie ohnehin nicht "nachgehalten" werden. Viele Aufträge die man erhält erledigen sich "von selbst", weil niemand je nach den Ergebnissen fragt

Symptome für zu viel Planung:

• Zu bearbeitende Aufgaben werden mit einer Genauigkeit von Stunden geplant
• Der Plan kann aufgrund seines Umfangs und seines Detaillierungsgrades nicht aktuell gehalten werden
• Der Überprüfungsaufwand für das Einhalten der Planung steht in keinem Verhältnis zum eigentlichen Entwicklungsaufwand

in der Realität ist eher zu wenig Planung vorzufinden.

Ziele der Planung:

• Unsicherheiten feststellen und klären oder klärbar machen
• Strukturen verdeutlichen
• Komplexität überschaubar und beherrschbar machen
• Bedarfe (Personen, Qualifikationen, Material, Budget, Zeit etc.) feststellen
• Wege zum Ziel definieren
• Meilensteine festlegen und somit Kontrollen im Hinblick auf den Fortschritt ermöglichen
• Aufgaben, Ressourcen und Verantwortungen zuordnen
• Steuerung möglich machen
• Risiken und Engpässe frühzeitig erkennen
• den Beteiligten die Richtung vorgeben

[Bearbeiten] 5.2.2 Differenzierung in Teilpläne

Unterteilung in Teilpläne um Vollständigkeit der Planung kontrollieren zu können.

• Organisationsplanung
• Aufwands- und Terminplanung
• Baselines planen
• Durchfürhrungsentscheidungen planen
• Einsatzmittelplanung

Feinplanung:

• Technisches Tailoring
• Produktstruktur und Ablauforganisation planen
• Aufwands- und Terminplanung
• Ressourcenplanung
• Baselines planen
• Teilprojekte/Unteraufträge

[Bearbeiten] 5.2.3 Vorgehen bei der Planung

Planung in der Reihenfolge: "Was", "Wie", "Wer und Womit", "Wann"

Fragen nach Anforderungen, nach Zielen und nach der erforderlichen Qualität.

• rollierende Planung
• Alternativplanung
• Planänderungen
• Planrevision
• Vorsehen von Planreserven

[Bearbeiten] 5.2.4 Die Netzplantechnik

Projektstrukturplanung - Planung der Aktivitäten/Vorgänge - Planung der verfügbaren Ressourcen - Ablaufplanung - Terminliste & Ressourcenzuordnung

Netzplantechnik: Vorgang: Dauer, Ressourcen, Abhängigkeiten

[Bearbeiten] 5.2.4.1 Arten von Netzplänen

• Vorgangspfeilnetz: Ende-Start, Start-Start, Ende-Ende, Start-Ende
• Vorgangsknotennetz
• Ereignisknotennetz

[Bearbeiten] 5.2.4.2 Verarbeitung des Netzplans

• Vorwärtsrechnung: Ergibt frühestmögliche Start- und Endtermine und kürzestmögliche Gesamtdauer des Projektes
• Rückwärtsrechnung: spätestmögliche Start- und Endtermine

Pufferzeit, Gesamtpufferzeit, freie Pufferzeit, kritischer Pfad

[Bearbeiten] 5.2.4.3 Verarbeitung mit Ressourcen

Beachten des Ressourcenverbrauchs.

Unterschiedliche Eigenschaften von Ressourcen:

• Repetierfaktoren: Verbraucht
• Potentialfaktoren: Gebraucht

Arten, die Termin- und die Ressourcenplanung zu kombinieren:

• einfache Anzeige des Ressourcenverbrauchs
• termintreue Bedarfsoptimierung
• kapazitätstreue Bedarfsoptimierung

Kosten und Einsparungen durch die Netzplantechnik:

• Kosten durch die Einführung der Netzplantechnik: SW, Datenbeschaffung, Erstellung, Aktualisierung
• Einsparungen durch den Einsatz der Netzplantechnik: Zeitersparnis (25%), Kostenersparnis (15%)

[Bearbeiten] 5.2.4.4 Werkzeuge zur Netzplantechnik

meist zu komplex, Anwender sollte entsprechende Teilfunktionalität auswählen.

[Bearbeiten] 5.2.4.5 Anwendung der Netzplantechnik

Nicht zu fein planen! Aus der Projektstrukturplanung mittels COCOMO oder Function-Point-Analyse die Vorgänge finden und anschließend die Planung verfeinern.

[Bearbeiten] 5.3 Steuerung und Kontrolle

Grafik: Wirkungskreislauf des Projektcontrolling

[Bearbeiten] 5.3.1 Metriken

Grafik: Rahmenmodell für Softwarequalitätsmetriken

Aufteilung der Metriken nach Produktqualität, Prozessqualität, Größe (Umfang)

Kriterien für Kennzahlen: quantifizierbar, erhebbar, vergleichbar, relevant und aktuell.

objektive Metriken, subjektive Metriken, Globalmetriken und Phasenmetriken, Zusatzmetriken

produkt- oder projekt-/prozessbezogene Kennzahlen

Anwendung:

• Integration in das Vorgehensmodell
• Projektspezifische Anpassung der Sollwerte
• Erfassung der Ist-Werte
• Analyse der Abweichungen und ihrer Ursache

[Bearbeiten] 5.3.2 Berichtswesen

Regeln von Keller:

1. Jeder holt sich eigenverantwortlich selbst alle notwendigen Informationen
2. Jeder sorgt von sich aus dafür, dass alle anderen im Team alle notwendigen Informationen erhalten.

Berichtsarten:

• Statusbericht: periodisch, Dokumentation der wesentlichen Projektdaten
• Arbeitsbericht oder Tätigkeitsbericht: Tätigkeiten der Mitarbeiter
• Abnahmebericht: Abnahme einer Phase
• Problemmeldung
• Änderungswunsch

[Bearbeiten] 5.3.3 Trendanalysen

Betrachtet Aspekte: Kosten, Termine, Qualität

[Bearbeiten] 5.3.3.1 Kostenanalysen

benötigt solide Kostenplanung und eine fundierte Betrachtung des Kostenanfalls.

Grafik: Vergleich der monatlichen Plan- und Istkosten

Grafik: Vergleich der kumulierten Plan- und Istkosten

[Bearbeiten] 5.3.3.2 Terminanalysen

aufsteigend: Termine werden überschritten

Interpretationen:

• "Normaler" Verlauf
• Trendwende
• "Zick-Zack"-Verlauf
• "Ausufernder" Verlauf

[Bearbeiten] 5.3.3.3 Qualitätsanalyse - Kontrolle des Projektfortschritts

Setzt die tatsächlich erzielten Projektergebnisse zu den geplanten Projektergebnissen ins Verhältnis.

[Bearbeiten] 6 Techniken des Projektmanagements

[Bearbeiten] 6.1 Kreativitätstechniken

• intuitiv-kreative Methoden: Brainstorming, Brainwriting, Synektik
• systematisch-analytische Methoden: Morphologischer Kasten
• Wissens- und Problemstrukturierung und -visualisierung
• Expertenbefragungen/Prognosetechniken
• Effizientes Führen von Gruppengesprächen

[Bearbeiten] 6.1.1 Brainstorming

"freie Assoziation":

• Ideen dürfen nicht kritisiert werden
• Die Ideen der anderen sollen aufgegriffen und weiterentwickelt werden
• Man soll seiner Phantasie ganz bewusse freien Lauf lassen und auch unkonventionelle Ideen einbringen
• Es sollen so viele Ideen wie möglich "erzeugt" werden
• Auch ungewöhnliche und sinnlos anmutende Ideen sollen frei und ungehemmt ausgesprochen werden, weil sie der Inspiration anderer Teilnehmer dienlich sein können
• In einer Brainstorming-Sitzung sind keine Diskussionen erlaubt

[Bearbeiten] 6.1.2 Brainwriting

• Methode 635: 6 Personen, 3 Ideen in 5 Minuten
• Collective-Notebook: Ideenfindung über einen längeren Zeitraum

[Bearbeiten] 6.1.3 Synektik

Versucht, den menschlichen Problemlösungsprozess nachzuempfinden. Vier Phasen:

1. Vorbereitungsphase: intensive Beschäftigung
2. Inkubationsphase: Entfernung vom Stoff, "Sickern lassen"
3. Illuminationsphase: spontane Lösung
4. Verifikationsphase: Ausgestaltung und Prüfung

[Bearbeiten] 6.1.4 Morphologischer Kasten

Lösung durch vollständige Erfassung des Problems und unterschiedliche Kombination der verschiedenen Gestaltungsparameter.

[Bearbeiten] 6.1.5 Mind Mapping

Karte der Gedanken analog zu den Verknüpfungsstrukturen im menschlichen Gehirn.

[Bearbeiten] 6.1.6 Delphi-Methode

Verschiedene Experten unabhängig voneinander befragen, Ergebnisse an alle weiterleiten und jeweils so lange erneut bearbeiten lassen, bis die Experten einig sind.

[Bearbeiten] 6.1.7 Metaplantechnik

Visualisierungstechnik: Pinnwand, Packpapier, Moderationskoffer, farbige Kärtchen, Filzstifte

Interaktionstechnik: 30 Sekunden Sprechzeit, Schriftlich diskutieren, bei Einwänden blitzen, Jeder ist des anderen Butler

Dramaturgietechnik: Einführung, Vertiefung, Abschluss

[Bearbeiten] 6.2 Risikomanagement

[Bearbeiten] 6.2.1 Bedeutung des Risikomanagements

Risiken der Einhaltung der Kosten und Terminpläne sowie Erfüllung der Qualitätsanforderungen an das Produkt.

[Bearbeiten] 6.2.2 Komponent des Risikomanagements

Risikoidentifizierung: potentielle Risiken ermitteln

Risikobewertung: möglicher Schaden, Eintrittswahrscheinlichkeit

Risikovermeidung/Risikoverminderung: entweder Eintrittswahrscheinlichkeit senken oder Schaden begrenzen

Grafik: Einordnung bewerteter Projektrisiken im Risiko-Portfolio

[Bearbeiten] 6.2.3 Arten von Projektrisikien

• Entwicklungsrisiken
  • Applikations-Entwicklungsrisiko: Over-Engineering, unzureichende Dimensionierung,
  • Materialzulieferungs-Risiko: fehlerhaftes zugekauftes Teilsystem
  • Einführungsrisiko: Probleme bei der Inbetriebnahme
• Managementrisiken
  • Projektleitungsrisiken: inkompetente Projektleitung
  • Planungsrisiko: unterschätzte Anforderungen oder Aufwendungen
  • Informations- und Kommunikationsrisiko
  • Koordinationsrisiko
• soziale Risiken
  • Motivationsrisiken
  • politische Risiken
  • Mitarbeiterrisiken

[Bearbeiten] 6.2.4 Techniken des Risikomanagements

• Risikomanagement muß integraler Bestandteil des Software-Entwicklungsprozesses sein
• Im Projektteam muss ein Risikobeauftragter ernannt werden
• Eine Liste der wichtigsten 10 Risiken ist zu führen
• Für jedes identifizierte Risiko ist ein entsprechender Risikomanagementplan zu erstellen
• Ein Kommunikationskanal, auf dem anonym auf mögliche Risiken hingewiesen werden kann, ist einzurichten

[Bearbeiten] 6.2.5 Möglichkeiten zur Risikominimierung

Letzlich ist das gesamte Projektmanagement der Aufgabe der Risikominimierung gewidmet. Daher gutes Projektmanagement primäre Möglichkeit zur Risikominimierung. Jedoch sind einzelne Teilaspekte für spezielle Risiken besonders wichtig:

• Einführungsrisiko: Abstimmung zw. dem Projektteam und den zukünftigen Anwendern durch geeignete Organisationsstrukturen sicherstellen. Veränderungen im Einsatzumfeld des Systems während der Entwicklungszeit verfolgen. Die ermittelten Anforderungen ggf. durch Prototypen validieren. Abnahme der Analyseergebnisse durch den Auftraggeber.
• Applikationsrisiko: Die projektierten Funktionalitäten einzeln hinsichtlich ihrere Kosten/Nutzen-Relation hinterfragen um 150%-Lösungen zu vermeiden. Mit Tests und Benchmarks frühzeitig überprüfen, ob die geforderten Leistungskennzahlen (Datenvolumen, Transaktionsraten, ...) erreicht werden können.
• Materialzulieferungs-Risiko: Genaue Analyse der Funktionalitäten und Schnittstellen im Vorfeld er Kaufentscheidung. Ggf. Einholen von Referenzen . Durchführung von Tests und Benchmarks im Vorfeld
• Projektleitungsrisiko: Einsetzen eines erfahrenen, fachlich versierten Projektleiters mit Managementqualitäten. Treffen von fundierten aber auch eindeutigen Entscheidungen. Delegieren von Aufgaben und Verantwortung innerhalb des Projekts (der Projektleiter muß nicht alles machen!)
• Planungsrisiko: Einsatz von Planungstechniken und Planungswerkzeugen. Regelmäßige Kontroller und Fortschreibung der Pläne. Durchführen von Alternativplanungen für verschiedene denkbare Szenarien
• Informations- und Kommunikationsrisiko: Installation eines zielgerichteten Berichtswesens. Schaffung einer Arbeitsatmosphäre, in der die Weitergabe von Informationen eine Selbstverständlichkeit ist
• Koordinationsrisiko: Einrichtung von entsprechenden organisatorischen Instanzen zur Gewährleistung der Koordination im Projekt und mit dem Projektumfeld.
• Motivationsrisiko: Mitarbeiter gemäß ihren Qualifikationen und ihren Wünschen einsetzen. Die Mitarbeiter über die Hintergründe von Arbeitsaufträgen und Entscheidungen informieren. Harmonierende Teams zusammenstellen. Unrealistische Planvorgaben vermeiden. Eindeutige Definition der Ziele. Mitarbeiter dürfen nicht den Eindruck haben, nur "ein Rädchen im Getriebe" zu sein - ihre Arbeit muss Anerkennung finden
• Politisches Risiko: Im Organisationsmodell alle Stellen, die Interesse an dem Projekt haben könnten, identifizieren und diese entsprechend in das Projekt einbinden. Insbesondere auf eine Einbindung des Managements achten. Ein Erfolg des Projekts muss für alle direkt und indirekt Beteiligten ein Erfolg sein
• Mitarbeiterrisiko: Leistungsgerechte Bezahlung (aller Mitarbeiter). Die Weitergabe von Informationen unter den Mitarbeitern fördern. Fragen der Stellvertretung z.B. für den Krankheits- und Urlaubsfall regeln. Schaffung eines angenehmen Arbeitsklimas im Projektteam

[Bearbeiten] 6.3 Besprechungen

Vorbereitung, Durchführung und Nachbereitung

[Bearbeiten] 6.3.1 Besprechungsvorbereitung

Gegenstand und Teilnehmer ermitteln.

W-Fragen von Feyhl: Was, Welches Ziel, Welche Problempunkte, Welche offenen Punkte, Wie lange, Wann, Wo, Wie, Wer führt Protokoll, ...

[Bearbeiten] 6.3.2 Besprechungsdurchführung

Thema nochmal ansprechen, Ziel skizzieren, Arbeitsregeln, Moderator festlegen (kümmert sich um Teilnehmer, dämpft Gefechte, Ordnet, strukturiert, Ziel nicht verlieren, Zusammenfassung)

[Bearbeiten] 6.3.3 Protokollerstellung und Besprechungsnachbereitung

Fasst Ergebnisse und weitere Schritte zusammen, verschiedene Arten von Protokollen:

• Ablaufprotokolle: Ergebnisse und wesentliche Meinungsäußerungen
• Ergebnisprotokolle: nur Ergebnisse und erforderliche Maßnahmen
• Kurzprotokolle: bei weniger wichtigen Besprechungen, Ergebnisse in wenigen Sätzen ohne detaillierte Begründung

Manipulation der Ergebnisse im Protokoll vermeiden! Daher bei wichtigen Punkten eine Protokollabnahme durchführen!

siehe auch Besprechung, Meetings

[Bearbeiten] 6.4 Projektpräsentationen

spezielle Art von Besprechungen. Stellt verschiedenen Teilnehmern des Projektes den Fortschritt vor. Schönfärberei vermeiden! Häufige/Seltene Projektpräsentationen.

Nutzen:

• für Management/Auftraggeber: Überblick über den Stand des Projektes, können frühzeitig auf Probleme und Missverständnisse hinweisen
• für den Projektleiter: Rückmeldung zu den Ergebnissen, Leistung darstellen, eine Art der "Abnahme"
• für den Projektmitarbeiter: Eindruck, dass das Projekt Beachtung findet, Kontrolle der Ergebnisse

[Bearbeiten] 6.4.1 Inhalte einer Projektpräsentation

• allgemeine Erläuterungen zum Stand des Projektes
• Meilenstein-Trendanalyse
• wichtige Projektergebnisse
• Einsatzplan der Mitarbeiter
• Vergleich der geplanten Aufwände mit den Ist-Aufwänden
• Ausblick auf anstehende Arbeiten

[Bearbeiten] 6.4.2 Regeln für die Gestaltung des Vortrags

• Wortwahl und Abstraktionsniveau
• Einsatz optischer Hilfsmittel: Flipcharts, Overhead-Folien, Wandtafeln, Notebook & Beamer
• Eingehen auf die Interessen der Anwesenden
• Gute Einteilung der Zeit: inklusive Zeit zur Diskussion
• Klare Gliederung des Vortrags: Motivation, inhaltliche Punkte, Zusammenfassung, Überleitung in die Diskussion

Wichtig sind Anfang und Ende!

[Bearbeiten] 6.4.3 Checkliste für den Referenten

• Wie ist mein Auftreten und meine Körperhaltung? Konzentriert?, Ruhig? Aufrecht? Hände aus der Hosentasche! Keine theatralischen Handbewegungen!
• Halte ich Blickkontakt mit den Zuhörern? Alle Zuhörer beachten! Zuhörer ansprechen!
• Wie ist meine Sprechtechnik? Normal sprechen, nicht schreien! Tempo richtig! Sprechpausen! Nicht monoton!
• Strahle ich Sicherheit aus und zeige ich Engagement? Nicht nervös oder fahrig! Positive Einstellung zum Thema zeigen!
• Stimmt meine Zeiteinteilung? Noch im Zeitplan? Keine Zeitüberschreitung! Evtl. unwichtige Teile weglassen! Nicht das Tempo steigern!

siehe auch Präsentation, Präsentationsmethode, Präsentationstechnik

[Bearbeiten] 6.5 Dokumentation

verschiedene Zielgruppen:

• für das Projektteam
• für die Wartungsphase
• für die Anwender
• für die Installation und Administration der SW

[Bearbeiten] 6.5.1 Dokumentation für die Entwicklungs- und Wartungsphase

Dient zur Verfügbarkeit und Nachvollziehbarkeit aller Arbeitsergebnisse. Erleichtert Wartungsphase, neue Mitarbeiter, ...

Vermeide technische Probleme: nicht zu wenig und nicht zu viel Dokumentation! Nicht nur aus Entwicklersicht! Kein "Projektjargon".

Lösung: Vorgehensmodell definiert Teildokumente, Qualitätssicherung der Dokumente, Augenmerk des Projektmanagements auf Dokumentation.

[Bearbeiten] 6.5.2 Dokumentation für die Anwender der Software

Dokumentieren das System für spezielle Zielgruppen.

• Installations- und Wartungshinweise
• Einführung in das System für Erstanwender
• vollständige Referenz der Funktionen
• Glossar

Entlastung der Softwareentwickler durch Einsatz eines technischen Dokumentierers.

[Bearbeiten] 6.5.3 Dokumentation für die Installation und Administration

Nötig, falls sich dezidiertes Personal um Installation und Administration kümmert.

siehe auch Dokumentation, Softwaredokumentation, Dokumentation (Technik)

[Bearbeiten] 6.6 Versions- und Konfigurationsmanagement

Problem mit "einfacher Dateispeicherung": Kein Rückgriff auf vorherige Versionen möglich, mehrere Dokumente passen nicht zueinander

Versionierung, Versionsmanagement, Variante, Konfiguration, Konfigurationsmanagement inklusive Build-Steps

Ziel des Versions- und Konfigurationsmanagements besteht darin, sicherzustellen, dass die entwickelten Dokumente und Komponenten jederzeit in einem wohldefinierten Zustand verfügbar sind. Dabei soll auch die Historie der Dokumente erhalten und verfügbar bleiben. Zu diesem Zweck etabliert das Versions- und Konfigurationsmanagement eine systematische Kontrolle der Änderungen an den Dokumenten und Komponenten während der Entwicklung und der Nutgzung des Systems. In vielen Anwendungsbereichen ist dies auch deshalb notwendig, weil aus rechtlichen Gründen nachweisbar sein muss, wann welche Software wo im Einsatz war, z.B. bei der Zahlungsverkehrsabwicklung im Bankenbereich oder bei der Flugsicherung.

[Bearbeiten] 7 Die menschliche Komponente

• Leistungsfähigkeit: Mitarbeiter auswählen (7.4), schulen (7.5)
• Leistungsmöglichkeit: Information, Infrastruktur und Arbeitsplatz bereitstellen
• Leistungsbereitschaft: Motivation sicherstellen (7.1), negative Gruppenprozesse vermeiden (7.2), klare und angemessene Führung (7.3)

[Bearbeiten] 7.1 Bedürfnisse, Motive und Motivation

[Bearbeiten] 7.1.1 Einflussfaktoren für die menschliche Leistungsbereitschaft

Anfang des 20. Jhds: Taylor: rational ökonomisch orientierter Mensch, wird durch materielle Anreize gesteuert, führte zu Fließbandarbeit und Akkordlohn

Späte 20er Jahre: Gegenströmung, die die Zufriedenheit mit den sozialen Beziehungen und den sozialen Bedinungen im Arbeitsumfeld als primäre Leistungsdeterminate betrachtete. Gruppe, sozialle Normen, Führung, Führungsstil

50er Jahre: Bedürfnishierarchie nach Maslow:

5. Bed. nach Selbstverwirklichung 4. Ich-Bedürfnisse 3. Soziale Bedürfnisse 2. Sicherheitsbedürfnisse 1. Physiologische Bedürfnisse

Neuere Ansätze, z.B. ERG-Theorie nach Alderfer/Alderfer: Existenzbedürfnisse, Beziehungsbedürfnisse, Wachstumsbedürfnisse

[Bearbeiten] 7.1.2 Abgrenzung zwischen Motiven und Motivation

Problemgebiete der Motivation:

1. Die Frage nach den Motiven
2. Die Frage nach der Motivation
3. Die Frage nach der Volition: Intentionsbildung, Handlungsinitiierung

Beim Umgang mit Mitarbeitern im Projektteam müssen deren längerfristige Motive ebenso berücksichtig werden wie das konkrete Umfeld in der aktuellen Arbeitssituation, sowie die Möglichkeit, dies auch in eine konkrete Handlung umzusetzen.

[Bearbeiten] 7.1.3 Die Prozesssicht der Motivation

Grafik: Leistungsdeterminanten-Konzept nach Berthel

[Bearbeiten] 7.1.4 Aktiv motivieren oder nur nicht demotivieren?

These: Anstatt ständig zu motivieren, darauf konzentrieren, nicht zu demotivieren.

[Bearbeiten] 7.1.5 Pragmatische Ansätze zur Erhöhung/Erhaltung der Motivation

• Maßnahmen kritisch hinterfragen
• Motivationsfaktoren:

1. 1. Erfolgserlebnis, Anerkennung für geleistete Arbeit
   2. Anspruchsvolle, interessante Aufgabenstellung und selbständige Arbeitsabwicklung
   3. Horizonterweiterung und Weiterbildungsmöglichkeiten
   4. Sicherheit der Position, Aufstiegsmöglichkeiten, Gehaltsentwicklung
   5. Kollegiale Atmosphäre in der Arbeitsgruppe, kooperativer Führungsstil und angenehme Arbeitsbedingungen

[Bearbeiten] 7.2 Zusammenarbeit in der Gruppe

Grafik: Merkmale der Gruppenarbeit

In einer Arbeitsgruppe arbeiten mehrere Personen an einer Aufgabe, die in Teilaufgaben zerlegt werden kann. Sie verfolgen dabei zumindest hinsichtlich dieser Aufgabe gemeinsame Ziele.

[Bearbeiten] 7.2.1 Warum Gruppenarbeit?

Vorteile:

• hoher Problemlösungsgrad bei schwierigen Problemen
• unterschiedliches Know-How der Teammitglieder wird genutzt
• die Gefahr, in eine Sackgasse zu geraten, ist geringer als bei Einzelarbeit
• gegenseitige Anregung und Verstärkung
• hohe Arbeitszufriedenheit

Nachteile:

• hoher Kommunikations- und Koordinationsaufwand bei großen Teams
• lange Diskussionen und verzögerte Entscheidungsfindungen sind möglich
• Konkurrenzdenken und individuelle Profilierung können Leistung verringern
• Es können schwer kontrollierbare gruppendynamische Prozesse ablaufen
• Gruppendruck kann bei Teammitgliedern zu verringerter Leistungsbereitschaft führen

Projektmanagement muß Vorteile nutzen und Nachteile so gering wie möglich halten.

[Bearbeiten] 7.2.2 Gruppenprozesse und Gruppenentwicklung

Grafik: Phasen-Modell der Gruppenentwicklung

1. Abtastphase (Forming): suche nach Platz und Rolle in der Gruppe, allgemeine Unsicherheit, Aufbruchsstimmung, Begeisterung
2. Konfrontationsphase (Storming): offene und unterschwellige Konflikte, Versuche, Position in der Gruppe zu festigen, Macht- und Positionskämpfe
3. Organisationsphase (Norming): gemeinsame Regeln für die Arbeit und den Umgang, gemeinsames Anliegen gefunden
4. Arbeitsphase (Performing): eigentliche Arbeitsphase

Rücksprung ist möglich! Performing ist auf Dauer Unflexibel, daher Dauer der Gruppe beschränken (3-5 Jahre)!

[Bearbeiten] 7.2.3 Rollen in der Gruppe

Positive Rollen: Schlichter, Animator, Fachmann, Moderator, Führer, Ideengeber, Kritiker, Koordinator

Negative Rolle: Störenfried, Rechthaber, Passiver, Nörgler, Alleswisser

[Bearbeiten] 7.2.4 Konflikte in der Gruppe

positive Aspekte:

• ein Konflikt weist auf Probleme hin und regt Interesse an
• ein Konflikt verhindert Stagnation
• ein Konflikt ist die Wurzel für Veränderungen
• ein Konflikt verlangt nach einer Lösung

Bewertungskonflikt, Beurteilungskonflikt, Verteilungskonflikt, Mischformen.

[Bearbeiten] 7.2.4.1 Konfliktdiagnose

manifeste Konflikte und latente Konflikte

[Bearbeiten] 7.2.4.2 Konfliktprophylaxe

• "starker" Projektleiter
• klar definierte Aufgaben und Kompetenzen
• Informationsfluss
• strukturierte Entscheidungen
• klar definierte Ziele
• Förderung der Eigeninitiative und der Eigenverantwortung

[Bearbeiten] 7.2.4.3 Konfliktlösung

Grafik: Verhaltensweisen zur Konfliktdynamik

eskalierend/deeskalierendes Verhalten

Grafik: Formen der Konflikthandhabung

• keine Auseinandersetzung mit dem Konflikt: Umdeuten, Verschieben
• indirekte Auseinandersetzung: in Ruhe lassen, Delegieren,
• direkte Auseinandersetzung: sozialproduktiv (Konsens/Kompromiss) oder sozialreduktiv (Vernichtung, Unterwerfung)

[Bearbeiten] 7.2.5 Umgangsregeln für eine effektive Gruppenarbeit

• Jeder erkennt jeden als vollwertiges Gruppenmitglied an
• Eine Gruppendiskussion ist hierarchiefrei durchzuführen. Ein Status außerhalb des Teams darf sich während der Teamarbeit nicht auswirken, da er den offenen Informatoinsfluss, die Kritikbereitschaft und die Kreativität der Mitarbeiter beeinträchtigt.
• Jeder Teammitarbeiter soll seine Meinung offen vertreten und darf sie nicht verschleiern
• Zur Teamarbeit gehört eine unbedingte Kooperationsbereitschaft
• Jedes Teammitglied ist berechtigt, positive Kritik zu üben, muss jedoch auch sachliche Kritik von anderen entgegennehmen
• Das Team präsentiert sich nach außen als Gesamtheit
• Innerhalb der Gruppe muss ein vollständiger Informationsaustausch erfolgen. Kein Mitarbeiter darf Informationen zurückhalten
• Kein Mitglied des Teams darf die noch nicht gemeinsam abgestimmten Ergebnisse der Teamarbeit an Außenstehende weitergeben
• Durch aktive Einbeziehung in den Meinungsbildungsprozess findet eine Motivation jedes Teammitglieds statt

[Bearbeiten] 7.3 Führung

"Einwirkung auf Mitarbeiter so dass vorgegebene Ziele erreicht werden" (Balzert)

[Bearbeiten] 7.3.1 Führungsaufgaben

Realitätsbereich einer Gruppe:

• die Gruppenaufgabe
• die Gruppenstruktur
• die Gruppenmitglieder
• die Umgebung, in der sich die Gruppe befindet

Führungsaufgaben:

1. Aufgabenbezogene Führungsaufgaben: Problemdefinition, Zielentscheidung, -priorisierung, Lösungsbewertung, Kontrolle von Ergebnissen
2. Koordinative Führungsaufgaben: Planung, Aufgabenverteilung, Schnittstellenmanagement, Kontrolle von Personen
3. Beziehungsorientierte Führungsaufgaben: Schaffen gemeinsamer Akzeptanz, Bindung an das Ziel, Konfliktmanagement
4. Systemexterne Führungsaufgaben: Pflege der Außenbeziehungen, Auftraggeber, Management

[Bearbeiten] 7.3.2 Führungsinstrumente

Grafik: Systematik der Führungsinstrumente

[Bearbeiten] 7.3.3 Führungsstile

Grafik: Führungsstile

autoritär - delegativ

Grafik: Managerial Grid - Verhaltensgitter

Grafik: Merkmale des Führungsverhaltens - Gegensätze autoritär - kooperativ

Führungsmerkmale:

• Delegation
• Partizipation
• Informationen
• Kontrolle
• Vorgaben
• Situation
• Entscheiden

• Management by objectives (MbO): Zielvereinbarungen
• Management by results: Ergebnisse
• Management by delegation: Aufgabenbereiche
• Management by participation: Mitarbeiterbeteiligung
• Management by alternatives: Suche und Bewertung von Alternativen
• Management by exception: greift nur bei Abweichungen ein
• Management by motivation: Bedürfnisse, Interessen, Einstellungen und persönliche Ziele der Mitarbeiter
• Management by decision rules: Entscheidungsregeln

"Management by"-Kategorien betonen bestimmte Aspekte, können daher fast beliebig kombiniert werden. Generell an Mbo orientieren und ergänzen.

Kooperativer Führungsstil is anzustreben, mit Zielvorgaben arbeiten und ein hohes Maß an Delegation, Partizipation und Information anstreben.

[Bearbeiten] 7.4 Einstellen von Personal

Personalauswahl. Interne und externe Rekrutierung.

[Bearbeiten] 7.5 Personalentwicklung

Laufbahnplanung und Mitarbeiterschulung.

[Bearbeiten] 7.5.1 Führungs- und Fachlaufbahn

"Klassische Führungslaufbahn" und Fachlaufbahn.

[Bearbeiten] 7.5.2 Schulung der Mitarbeiter

verschiedene Formen:

• Training on the Job
• Schulung durch Qualitätssicherung
• Externe Vorträge
• Externe Kurse
• Interne Vortragszyklen
• Interne Kurse

Außerdem Nutzung von CBT/WBT.

Am besten abgestimmte Kombination. Schulungen sind keine Incentives!

[Bearbeiten] 7.6 Zusammenfassung

Regeln für eine erfolgreiche Führungskraft

Ziele und Aufgaben definieren

1. Der erfolgreiche Manager entwickelt herausfordernde und erreichbar Ziele für seine Mitarbeiter
2. Legt klare, spezifische Hauptaufgaben und Fähigkeiten für Mitarbeiterpositionen oder Stellen fest
3. Erklärt Aufgaben und projekte verständlich und gründlich
4. Bestimmt messbare, beziehungsweise überprüfbare Kriterien für erforderliche Leistungen
5. Klärt Probleme und ihre Ursachen vollständig ab, so dass Mitarbeiter sie korrigieren können

Beraten und Unterstützen

1. Äußert mehr Anerkennung als negative Kritik
2. Bietet Mitarbeitern Hilfestellung und Unterstützung an
3. Vermittelt hohe persönliche Erwartungen auf informelle Art und Weise
4. Legt Wert auf positive zwischenmenschliche Beziehungen zu seinen Mitarbeitern
5. Gibt Mitarbeitern die Möglichkeit, ihre Fehler selbst herauszufinden und zu korrigieren, anstatt Probleme für sie zu lösen
6. Bezieht Mitarbeiter in Zielfindungs- und Entscheidungsprozesse ein

Leistungen beurteilen

1. Belohnt und fördert Mitarbeiter im Hinblick auf Innovations- und Risikofreudigkeit
2. Bespricht regelmäßig mit Mitarbeitern ihren Leistungsfortschritt und Zielerreichungsgrad
3. Versträkt ausgezeichnete Leistungen seiner Mitarbeiter durch finanzielle und nichtfinanzielle Anreize
4. Bezieht das Gesamtbeurteilungssystem (Belohnung, Beförderung, Anerkennung) nur auf das tatsächliche Leistungsverhalten, nicht auf andere Faktoren (z.B. Dienstalter)

Organisationsentwicklung

1. Entwickelt Strategien und Ziele für die Organisation (Hauptabteilung, Abteilung)
2. Führt Meetings so durch, dass Zusammenarbeit gefördert wird
3. Ermutigt Mitarbeiter, Aufgaben und Projekte, die sie für wichtig halten, zu entwickeln und zu übernehmen
4. Zeigt persönliches Engagement in der Verfolgung übergeordneter strategischer Ziele

[Bearbeiten] 8 Qualität, Qualitätssicherung und Qualitätsmanagement

[Bearbeiten] 8.1 Motivation und Begriffsabgrenzung

Qualität: "Gesamtheit der Merkmale, die eine Einheit zur Erfüllung vorgegebener Forderungen geeignet macht" oder "die Gesamtheit von Merkmalen einer Einheit bezüglich ihrer Eignung, festgelegte und vorausgesetzte Erfordernisse zu erfüllen"

Aspekte:

1. Qualität kann nur anhand vorgegebener Anforderungen beurteilt werden: unterschiedliche Anforderung für unterschiedliche Einsatzszenarien
2. Qualität ist nicht nur im Hinblick auf das zu erstellende Produkt, sondern auch im Hinblick auf den Erstellungsprozess wichtig: Auch der Prozess unterliegt Qualitätsanforderungen

Außerdem Unterscheidung nach Qualität während Entwicklung und Produktion

Qualitätsmanagement: "Alle Tätigkeiten der Gesamtführungsaufgabe, welche die Qualitätspolitik, Ziele und Verantowrungen festlegen sowie diese durch Mittel wie Qualitätsplanung, Qualitätslenkung, Qualitätssicherung und Qualitätsverbesserung im Rahmen des Qualitätsmanagementsystems verwirklichen"

Qualitätssicherung: "Alle geplantent und systematisschen Tätigkeiten, die innerhalb des Qualitätsmanagementsystems verwirklicht sind, und die wie erforderlich dargelegt werden, um angemessenes Vertrauen zu schaffen, dass eine Einheit die Qualitätsforderungen erfüllen wird"

Unterteilung der Qualitätssicherung:

• Qualitätsplanung
• Qualitätslenkung
• Qualitätsprüfung

ursprünglich nur Qualitätskontrolle am Schluss der Fertigung, anschließend Qualitätssicherung während der Fertigung, heute Qualitätsmanagement mit umfassendem Qualitätsbegriff.

[Bearbeiten] 8.2 Qualitätsplanung

Festlegung der Qualitätsmerkmale und Qualitätskriterien lt. allg. Vorgehensmodell. Für das Projekt wird ein Qualitätsplan erstellt, der die Qualitätsziele festhält.

Der Qualitätsplan sollte dokumentiert und abgenommen werden.

[Bearbeiten] 8.2.1 Qualität des Produktes

Merkmale: Änderungsfreundlichkeit, Benutzerfreundlichkeit, Dokumentation, Effektivität, Effizienz, Erweiterbarkeit, Integrität, Korrektheit, kurze Antwortzeiten, Portabilität, Recovery, Robustheit, Testbarkeit, Wartbarkeit, Wiederverwertbarkeit, Wirtschaftlichkeit, Zuverlässigkeit, ...

Als Leitfaden für das Qualitätsmodell kann das FCM-Modell (factor-criteria-metrics) dienen:

• Qualitätsmerkmale (factors): eher Benutzerorientiert
• Qualitätskriterien (criteria): eher Softwareorientiert
• Qualitätsindikatoren und Qualitätsmaße (metrics): konkrete Indikatoren

Resultat ist ein Netz als Qualitätsmodell

Grafik: Softwarequalitätsmerkmale nach DIN ISO 9126

• Funktionalität: Korrektheit/Richtigkeit, Angemessenheit, Interoperabilität, Kompatibilität/Ordnungsmäßigkeit, Sicherheit
• Zuverlässigkeit: Reife, Fehlertoleranz, Wiederherstellbarkeit
• Benutzbarkeit: Verständlichkeit, Erlernbarkeit, Bedienbarkeit
• Effizienz: Zeitverhalten, Ressourcenverbrauch
• Änderbarkeit: Analysierbarkeit, Modifizierbarkeit, Stabilität, Prüfbarkeit
• Portabilität/Übertragbarkeit: Anpassbarkeit, Installierbarkeit, Konformität, Austauschbarkeit

Merkmale stehen teils in konkurrierender und teils in unterstützender Wechselwirkung. Außerdem haben die Kriterien unterschiedliche Bedeutung für verschiedene Gruppen.

[Bearbeiten] 8.2.2 Qualität des Prozesses

Analog zu Qualitätskriterien für das Produkt auch welche für den Prozess:

• Einhaltung von Termin- und Kostenplänen
• geringe Anzahl von Planänderungen
• Zwischenergebnisse hoher Qualität
• vollständige Dokumentation der Arbeitsergebnisse
• zielorientiertes Arbeiten
• Transparenz des Entwicklungsprozesses
• hohe Produktivität
• rechtzeitige Verfügbarfkeit aller erforderlichen "Vorprodukte" für eine Aufgabe
• klare Zuständigkeiten und Kompetenzen
• Anzahl der erforderlichen Änderungen in bereits abgenommenen Vorergebnissen

Generell leicht quantifizierbar

[Bearbeiten] 8.3 Qualitätslenkung

Qualitätslenkung: "Maßnahmen zur Erfüllung vorgegebener Qualitätsanforderungen an Produkte und Prozesse". Läßt sich in die Ausführungsplanung, die Ausführungsüberwachung und die Ausführungskorrektur unterteilen.

Ausführungsplanung: Entwicklungskonventionen für verschiedene Aktivitäten im Rahmen der Projektdurchführung:

• Organisation des Entwicklungsprozesses
• Projekt- und die Produktdokumentation
• Durchführung von Reviews (Inspektionen), mit denen Qualität von Zwischen- und Endergebnissen des Projekts geprüft wird
• Durchführung von Audits
• Konfigurationsmanagement
• Berichtswesen und die Meldung von Fehlern und Problemen
• Beantragung und Durchführung von Änderungen an bereits abgenommenen Zwischenergebnissen
• Erstellung von Qualitätsberichten
• Einsatz von Werkzeugen und Entwicklungsmethoden

Ausführungsüberwachung: prüfen, ob vorgesehene Konventionen eingehalten worden sind. Sind die Maßnahmen zur Qualitätssicherung wirklich durchgeführt werden.

Ausführungskorrektur: Kaum von der Ausführungsüberwachung zu trennen. Gegenstand ist das Veranlassen von Nachbesserungen als Reaktion auf entsprechende Überwachungsergebnisse.

[Bearbeiten] 8.4 Qualitätsprüfung

Prüft, wie weit ein Arbeitsergebnis die vorgegebenen Qualitätsanforderungen erfüllt. Wichtig: Nicht erst die "fertige" Software testen!

Grafik: Fehlerstrom zwischen Entstehungszeitpunkt und Entdeckungszeitpunkt

[Bearbeiten] 8.4.1 Reviews, Inspektionen, Walk Throughs

"Have a close look at the code"

Review als Oberbegriff für Inspektionen und Walk Throughs

Inspektionssitzung (4 - 8 Personen): Moderator, Protokollführer, Autor, Autoren vorhergehender Phasen, Testspezialist, Vertreter des Auftraggebers

Walk Through: Team wie bei der Inspektion. Es werden aber Testfälle bzw. Testszenarien vorbereitet, die durchgespielt werden.

Entscheidend für den Erfolg eines Reviews ist die konstruktive Grundhaltung der Teilnehmer. Kritik muss konstruktiv und darf auf keinen Fall persönlich sein. Der Autor muss den Review als Möglichkeit sehen, sein Arbeitsergebnis zu verbessern. Die Anderen sollen ihm dabei helfen und ihm nicht seine Fehler vorhalten.

Reviews prüfen auch Verständlichkeit der Dokumente und Programmtexte!

[Bearbeiten] 8.4.2 Testen der erstellten Software und ihrer Komponenten

Reviews werden als "statische Testverfahren" bezeichnet. Im Gegensatz dazu ist "dynamisches Testen", wenn das Verhalten des Testgegenstands betrachtet wird. Es werden Unterschiede zwischen dem tatsächlichen Verhalten und dem spezifizierten Verhalten gesucht. Es wird dabei - beim Fehlen entsprechender Unterschiede - die Übereinstimmung des Testgegenstandes mit den Anforderungen nachgewiesen.

Grafik: Wasserfallmodell des Software-Lebenszyklus mit den zugehörigen Qualitätssicherungsmaßnahmen

Mit Testaktivitäten sollte möglichst früh begonnen werden.

• Modultests: Ablaufumgebung, Wahl der Testfälle, Auswertung, Ermittlung der Testqualität
• Integrationstest: Bottom-Up, Top-Down oder Middle-Out
• Systemtest:
• Abnahmetest:

[Bearbeiten] 8.5 Qualitätssicherung nach dem V-Modell

Submodell QS im V-Modell. Qualität: "die Gesamtheit der Merkmale einer Einheit bezüglich ihrer Eignung, festgelegte und vorausgesetzte Erfordernisse zu erfüllen".

[Bearbeiten] 8.6 Qualitätsmanagement

verschiedene Theorien:

• William Edwards Deming-Qualitätskreis: Plane - Führe aus - Prüfe - Korrigiere
• Juran: "fitness for use"
• Crosby:
• Feigenbaum: Total Quality Control
• Japanische Pioniere: Total Quality Management "TQM ist eine auf Mitwirkung aller ihrer Mitglieder beruhende Führungsmethode einer Organisation, die Qualität in den Mittelpunkt stellt und durch Zufriedenstellung der Kunden auf langfristigen Geschäftserfolg sowie auf Nutzen für die Mitglieder der Organisation und für die Gesellschaft zielt. Unter "Mitglieder" wird jegliches Personal in allen Stellen und allen Hierarchieebenen der Organisation verstanden."

Grafik: Konzeptionelle Aspekte des TQM

"TQM ist ein auf der Mitwirkung aller Mitglieder beruhende Führungsmethode einer Organisation, die Qualität in den Mittelpunkt stellt und durch Zufriedenstellung der Kunden auf langfristigen Geschäftserfolg sowie auf Nutzen für die Mitglieder der Organisation und für die Gesellschaft zielt. Unter "Mitglieder" wird jegliches Personal in allen Stellen und allen Hierarchieebeneen der Organisation verstanden"

TQM: Kundenorientierung, Prozessorientierung, Primat der Qualität (Null-Fehler-Prinzip), Zuständigkeit aller Mitarbeiter (Einbeziehung und Qualifizierung der Mitarbeiter), ständige Verbesserung, Verantwortung des Managements (Qualität als Führungsaufgabe), Vorbeugung (statt nachträglicher Prüfung und Korrektur)

[Bearbeiten] 8.7 Qualitätsmanagement nach ISO 9000

Bedeutendster Standard zum Qualitätsmanagement. Normenreihe der International Organization for Standardization (ISO) für Qualitätssicherung und Qualitätsmanagement. Idee: Unabhängiger Dritter prüft Qualitätsmanagement bei Zulieferern und Kunden. Ab ISO 9000:2000 nur mehr ISO 9001 und ISO 9004. ISO 9001 weiterhin stark produktbezogen: "Aufgrund von Beweisen Vertrauen zu erwecken, dass ein Produkt (oder eine Dienstleistung) die gestgelegten Anforderungen erfüllt/erfüllen wird". Dahingegen ISO 9004: "Mittels anhaltender Kundenzufriedenheit einen Nutzen für alle Interessenpartner zu erlangen."

[Bearbeiten] IT-Strategie - Kapitel 3 - 4 Grundlagen der betrieblichen Informationswirtschaft

Operative Aufgaben im Zusammenhang mit der Informationsentstehung und -veränderung, der Informationsbewirtschaftung und dem Informationseinsatz. Darüber hinaus Vorgaben der IV-Strategie durch geeignete Maßnahmen der Planung, Durchsetzung und Kontrolle im betrieblichen Geschehen in die Realität umzusetzen.

Informationswirtschaft

[Bearbeiten] 4.0 Lehr- und Lernziele

[Bearbeiten] 4.1 Entscheidung und Information

Entscheidungsprozesse können nur dann zufriedenstellend gelöst werdne, wenn die benötigten Informationen zum richtigen Zeitpunkt, in der richtigen Ausprägung und Qualität an der richtigen Stelle bereitstehen. Verlauf und Ergebnis von Entscheidungsprozessen hängen deshalb wesentlich von der Art der benötigten und verfügbaren Informationen, von den Möglichkeiten ihrer Gewinnung und Verarbeitung und somit letztendlich vom Informationssystem der Unternehmung ab.

Grafik: Einflussgrößen und Phasen des Entscheidungsprozesses ind er Unternehmensorganisation

Information, Entscheidung

[Bearbeiten] 4.1.1 Betriebliche Entscheidungen

Entscheidungsproblem als Ausgangspunkt inklusive der bestehenden Handlungsalternativen (Lösungswege)

Entscheidungsprozesse als Ablauf der Entscheidung

Entscheidungsfeld als Gesamtheit der Faktoren rund um die Entscheidung.

Planung, Implementierung, Realisation und Kontrolle organisatoriscsher Regelungen

Dynamik von Entscheidungsprozessen

[Bearbeiten] 4.1.2 Unsicherheit von Informationen

Unsicherheit durch Unvollständigkeit des Entscheidungsfeldes oder Zeitmangel.

• Informationsüberflutung
• Informationsdefizite
• Fehlerhafte Informationen
• Unsichere Informationen durch Dynamik der Entscheidungsprozesse
• Informationsinterpretation und -bewertung

[Bearbeiten] 4.1.3 Ziele, Zielbeziehungen und Zielerreichung in Entscheidungsprozessen

Weitere Problem durch Komplexität und Vagheit oder Widersprüchlichkeit des betrieblichen Zielsystems.

10 "Dimensionen" der Unternehmensziele

• Gewinnstreben
• Umsatzstreben
• Wirtschaftlichkeitsstreben
• Sicherung des Unternehmenspotenzials
• Sicherung der Liquidität
• Unabhängigkeits- und Vereinigungsstreben
• Prestigestreben
• Machtstreben
• ethische und soziale Bestrebungen
• sonstige Zielvorstellungen

Dimensionen sind nicht unabhängig voneinander!

komplementäre Ziele, konkurrierende Ziele, Zielindifferenz, Zielelastizität, partielle Zielkomplementarität/partielle Zielkonkurrenz, Ober- und Unterziele, Zielhierarchie, Suboptimierung,

Unternehmen verfügen über kein geschlossenes, in sich widerspruchsfreise Zielsystem.

Entscheidung#Entscheidungsprozess, Ziel

[Bearbeiten] 4.2 Grundannahmen über menschliches Verhalten

[Bearbeiten] 4.2.1 Individuelles Entscheidungsverhalten

Grafik: Grundmodell individuellen Verhaltens

Psychosystem: Menge der Faktoren,die die Persönlichkeit eines Individuums ausmachen (Bedürfnisse, Einstellungen und erwartungen, Kenntnisse und Fähigkeiten) sowie die zwischen diesen bestehenden Beziehungen.

Verbindung des Verhaltensmodells mit der Umwelt über drei Feedback-Kreise.

[Bearbeiten] 4.2.2 Individuelles Verhalten und interpersonelle Beziehungen

interpersonelle Kommunikation als Kommunikationsprozesse. Kommunikationsprozess: Individuum A (Sender) überträge über einen Kommunikationskanal Informatoinen an ein Individuum B (Empfänger). Ihr Verhalten wird dabei permanent von eine Netzwerk interpersoneller (Kommunikations-)Beziehungen beeinflusst.

Grafik: Modell der Einflussnahme in einer interpersonellen Beziehung zwischen zwei Personen

Grundlagen der Beeinflussung des Verhaltens von B: positive/negative Sanktionen, Legitimation und Argumente

Direkte Sanktionen:

• Physische Sanktionen
• Materielle Sanktionen
• Symbolische Sanktionen

Indirekte Sanktionen:

• Informationen
• Personen
• Materielle Inputs

Legitimation:

• Positionsspezifische Autorität
• Aufgabenspezifische Autorität
• Personenspezifische Autorität

Argumente:

Unterschiedliche Formen der Einflussnahme:

• Anweisungen: imperativ
• Vorschlagen: Anregung
• Vorleben: Verhaltensweisen

[Bearbeiten] 4.2.3 Gruppenverhalten

Gruppe definiert als eine Struktur, in der:

• mehrere Individuen
• über einen längeren Zeitraum hinweg
• in persönlicher Interaktion miteinander stehen, und
• gemeinsam, d.h. interdependent,
• eine von der Leitung des Sozialsystems
• übertragene Aufgabe erfüllen

Gruppe als Subsystem des Sozialsystems der Unternehmung mit überlicherweise begrenzter zeitlicher Stabilität.

Grafik: Modell des Gruppenverhaltens

Gruppe, Arbeitsgruppe, Soziale Gruppe

[Bearbeiten] 4.3 Informationsbegriff der Betriebswirtschaftslehre

[Bearbeiten] 4.3.1 Daten - Informationen - Wissen

Semiotik: Syntax als Aufbau einer Aussage, Semantik als inhaltliche Bedeutung, Pragmatik als Eignung der Informatoinen zur Vorbereitung von Handlungen und Entscheidungen.

Verschiedene Sichtweisen von Information: menschengebundener Ansatz, ungebundener Ansatz, Individualistisch-subjektiver Ansatz, objektiver Ansatz, wahrheitsunabhängiger Ansatz, wahrheitsabhängiger Ansatz, prozessualer Ansatz, statischer Ansatz

Grafik: Typologie der Informationsbegriffe in Netzdiagrammdarstellung

In der Betriebswirtschaftslehre hat sich ein pragmatisch orientierter Informationsbegriff udrchgesetzt. Information wird hier in der Regel als zweckorientiertes Wissen dargestellt, wobei der Zweck in der Vorbereitung des Handelns liegt.

Daten, Information, Wissen, Semiotik

[Bearbeiten] 4.3.2 Information im System der Wirtschaftsgüter

Abgrenzung zwischen Information und anderen Wirtschaftsgütern.

Grafik: Gütersystem nach Corsten

Merkmale von Information:

• Information ist immateriell, wird nicht verbraucht
• Information ist kein freies Gut, Beschaffung, Produktion, Nutzung und Weiterleitung verursachen Kosten, welche noch immer nicht genau bestimmt werden können.
• Wert der Information ist von ihrer Verwendung abhängig
• Informationen können durch Gebrauch einen Wertzuwachs erfahren
• Bewertungsparadoxon von Informationen erfordert Vertrauen beim Handel mit Information
• Information kann beim Tausch gegen finanzielle oder sonstige Belohnung als Ware auftreten
• Vervielfältigung von Information ist mit geringen Kosten verbunden und einfach realisierbar.
• Käufer erhalten lediglich eine Kopie
• Informationen lassen sich verdichten, die Verdichtung führt in der Regel zu Verlusten
• Informationen können andere betriebliche Ressourcen ersetzen
• Information ist leicht transportierbar
• Information lässt sich zur Verfolgung ökonomischer, organisatorischer, sozialer und politischer Ziele einsetzen

Teilweise werden Informationen auch als Dienstleistungen betrachtet, da sich ihre Entstehung auf einen Dienstleistungsproess zurückführen lässt.

Information weist zwar Gemeinsamkeiten mit herkömmlichen Wirtschaftsgütern auf, unterscheidet sich allerdingt deutlich in einigen Punkten. Daher versagen viele herkömmliche Management- und Planungstechniken beim Faktor Information weitgehend.

Wirtschaftsgut, Produkt, Produktionsfaktor

[Bearbeiten] 4.3.3 Information im System der betrieblichen Produktionsfaktoren

Keine Einigung in der Literatur über Einordnung von Information im System der Produktionsfaktoren.

Produktionsfaktoren: "die für die Unternehmensleitung, die Produktion und den Absatz sowie für die Erhaltung der Betriebsbereitschaft eingesetzten Güter"

Elementarfaktoren: Arbeit, Betriebsmittel, Werkstoffe

Dispositiver Faktor: Betriebs- und Geschäftsleitung, Organisation, Planung

Grafik: Produktionsfaktorsystem nach Kern

Information als Objektfaktor

Information als Betriebsmittel

Informationen des dispositiven Faktors

Grafik: Rollen der Informatoin im Faktorkombinationsprozess

[Bearbeiten] 4.3.4 Information als strategische Ressource

Informationen stellen die zentrale Ressource des dispositiven Faktors dar.

Grafik: Informationsbedarf, -angebot und -nachfrage

[Bearbeiten] 4.4 Informationsbezogene Aktivitäten

Gewinnung, Interpretation und Bewertung, Verarbeitung, Speicherung und Zugriff (ggf. Retrieval) sowie Transport von Informationen.

[Bearbeiten] 4.4.1 Gewinnung von Informationen

Gliedert sich in die Ermittlung des Informationsbedarfs und der Deckung des Informationsbedarfs.

• Originäre Information
• Externe Information
• Interne Information

[Bearbeiten] 4.4.2 Identifikation, Bewertung und Interpretation von Informationen

Spezifikation des Informationsbedarfs und Identifizierung/Selektion der relevanten Informationen

Informationsbewertung

Optimierung von Entscheidungsprozessen

[Bearbeiten] 4.4.3 Verarbeitung von Informationen

drei häufig kombinierte Verfahren:

• Transmission: Transport der Information
• Translation: verändert nur die Form der Informationsdarstellung, jedoch nicht den Inhalt
• Transformation: verändert den Inhalt und Form der Informationen. Prozesse niedriger und höherer Ordnung

Standardisierung und Automatisierung bei der Informationsverarbeitung.

Informationsverarbeitung

[Bearbeiten] 4.4.4 Speicherung und Wiederauffinden von Informationen

Speicherort: menschliches Gedächtnis

Organisatorisches Lernen

Kodifizierung

[Bearbeiten] 4.4.5 Kommunikation und Arbeitsteilung

Kommunikation, Arbeitsteilung

[Bearbeiten] 4.5 Aufgaben und Organisation des betrieblichen Informationsmanagement

[Bearbeiten] 4.5.1 Begriffsbestimmung

Informationsmanagement: bezeichnet die gezielte betriebswirtschaftliche Auseinandersetzung mit der Informatoinswirtschaft zum Zweck der Beschreibung (Modellbildung), Analyse und Prognose sowie Gestaltung des Informationssystems der Unternehmung. Informationsmanagement ist ein integraler Bestandteil der Unternehmensführung und eine Querschnittsfunktion, die unmittelbar mit dem Führungsprozess verbunden ist.

[Bearbeiten] 4.5.2 Ursachen für das Aufkommen des Informationsmanagement

Grafik: Einfluss von Informations- und Kommunikationsaktivitäten auf die Wertschöpfungskette

Grafik: Neuer Wettbewerb durch Informations- und Kommunikationssysteme

[Bearbeiten] 4.5.3 Aufgaben des Informationsmanagement

1. Ebene: Informationsbedarf und seine Deckung für alle wesentlichen betrieblichen Zwecke

2. Ebene: Management der IuK-Systeme

3. Ebene: Systemarchitekturen, Topologie und Leistungsfähigkeit der Rechnernetze, die Rechnerausstattung planen, organisieren und kontrollieren

[Bearbeiten] 4.5.4 Organisation des Informationsmanagement

Fachspezifität versus Technische Spezifität

Technikorientierte versus Kundenorientierte Gliederung des Informationsmanagement

Grafik: Technikorientierte Gliederung des Informationsmanagement

Grafik: Steuerungsorientierte Gliederung des Informationsmanagement

Grafik: Kundenorientierte Gliederung des Informationsmanagement

[Bearbeiten] 4.6 Literaturhinweise

[Bearbeiten] IT-Strategie - Kapitel 6 - 8 Management der IuK-System und der IuK-Infrastrukturen

IuK

[Bearbeiten] 8.0 Lehr- und Lernziele

[Bearbeiten] 8.1 Problemstellung

Bereitstellung der IT-Infrastruktur in skalierbarer Form.

[Bearbeiten] 8.2 Struktur der IuK-Systeme

[Bearbeiten] 8.2.1 Klassifikationskriterien für IuK-Systeme

unterschiedliche Klassifikationskriterien möglich.

nach der Abgrenzung des betrachteten Systems:

• IuK-Systeme im engeren Sinne: HW und SW des betrieblichen Informationssystems
• IuK-Systeme im weiteren Sinn: Auch Menschen sowie Entscheidungs- und Planungsprozesse

nach dem Automatisierungsgrad:

• nicht automatisierte
• teilautomatisierte
• vollautomatisierte IuK-Systeme

nach dem erreichten Integrationsgrad.

Integrationsformen umfassen:

• Datenintegration: Teilaufgaben und Vorgänge die auf gleiche Daten zugreifen, werden zusammengefasst
• Funktionsintegration: Zusammenführung zusammenhängender elementarer Funktionen
• Vertikale versus horizontale Integration: horizontal bezieht sich auf die Verknüpfung von Teilsystemen, bei der vertikalen Integration erfolgt eine Abstimmung und Verknüpfung von Informationssystemen unterschiedlicher Detaillierung.

Grafik: Horizontale und vertikale Integration von IuK-Systemen

Integration, Automation, Automatisierung

[Bearbeiten] 8.2.2 IuK-Systeme und Formen der betrieblichen Koordination

Transaktionskostentheorie: geht davon aus, dass die Organisation des Güteraustausches und damit dessen Koordination wesentlich durch die bei Transaktionsanbahnung und -ausführung anfallenden Kosten bestimmt wird.

Grafik: Transaktionskostentheoretisch abgrenzbare Austauschbeziehungen

Grafik: Koordinationsformen und Makrostrukturen von IuK-Systemen

[Bearbeiten] 8.2.2.1 IuK-Systeme bei hierarchischer Koordination (Feld 1: Hierarchie)

fehlt!

[Bearbeiten] 8.2.2.2 Zwischenbetriebliche Informationsverarbeitung und elektroniscsher Datenaustausch (Feld 3: Strategisches Netz)

fehlt!

[Bearbeiten] 8.2.2.3 IuK-Systeme für marktliche Koordination (Feld 2: Markt)

fehlt!

[Bearbeiten] 8.2.2.4 IuK-Systeme für die gruppenorientierte Aufgabenbearbeitung (Feld 4: Clan)

fehlt!

[Bearbeiten] 8.3 IuK-Infrastrukturen

Man spricht von IuK-Infrastruktur, wenn die betrachteten Komponent eines IuK-Systems nicht nur dazu dienen, eine ganz bestimmte betriebliche Funktion in einem ebenfalls ganz bestimmten betrieblichen Aufgabenkontext zu realisieren.

Schichtenarchitektur:

• HW und HW-Nahe System-SW
• Betriebssysteme für Einzelrechner und die für den Betrieb von Rechnernetzen benötigte HW/SW wie Infrastrukturen für die Datenübertragung, Kommunikationssysteme und sogenannte Netzwerkbetriebssysteme
• Middleware-Plattformen, wie CORBA oder Workflow-Management-Plattformen

[Bearbeiten] 8.3.1 Hardware, Systemsoftware und Rechnernetze

Hardware: Menge aller möglichen Bauteile von EDV-Systemen

Software: Gesamtheit aller Programme, die zur Ausführung auf Rechner-Hardware vorgesehen sind

Drei Klassen von Rechnersystemen:

1. Großrechner (Hosts oder Mainframes) mit hoher bis sehr hoher Rechneleistung
2. Minicomputer (einschließlich Workstations) mit mittlerer Rechenleistung
3. Mikrocomputer (hauptsächlich Personalcomputer und Laptops)

[Bearbeiten] 8.3.2 Middleware

"weiche" Beschreibung: Softwareschicht, welche Dienstleistungen f[r die Integration von Daten und Programmen in einer verteilten, heterogenen Umgebung erbringt."

Umfaßt sehr unterschiedliche Dinge:

• Architekturen & Standards wie CORBA
• Workflow-Management-Systeme
• Intranets und Internet

Grafik: Middleware als Softwareschicht

Middleware ist den Ebenen 5 bis 7 des ISO/OSI-Schichtenmodells zuzuordnen.

Ortstransparenz!

Middleware

[Bearbeiten] 8.3.2.1 CORBA

Standard für Middlewareplattformen. Objektorientiert.

Grafik: OMG-Architekturmodell

Object Request Broker ORB

Grafik: Struktur des ORB

CORBA

[Bearbeiten] 8.3.2.2 Workflow-Management-Systeme

Workflow: Abbildung eines auf der organisatorischen Ebene definierten Arbeitsablaufes in einem DV-System.

Workflow-Management-System: Softwaresystem, welches die informationstechnisched Abbiludng organisatorischer Abläufe und deren teil- und vollautomatisierte Steuerung unterstützt.

drei Stufen:

• Stufe 1: Integration von Anwendungswissen, Ablaufwissen und Daten in monolithischen Softwaresystemen
• Stufe 2: Herauslösung der Datenverwaltung aus Softwaresystemen und Aufbau von Datenbanken (zwei-Schichten-Modell)
• Stufe 3: Trennung von Anwendungswissen, Ablaufwissen und Datenverwaltungskomponente in einem drei-Schichten-Modell

Grafik: Entwicklungsstufen der Architektur betrieblicher Anwendungssysteme

Workflow eignet sich vor allem bei klarer Strukturierung der zu unterstützenden betrieblichen Prozesse. Ist allerdings oft nicht in vollem Umfang umsetzbar, daher mehr und mehr Elemente von semi-strukturierten Prozessen in Workflow-Management-Systemen.

Grafik: Strukturierungsgrad betrieblicher Prozesse

Nach ersten Entwicklungen Zusammenschluß der wichtigsten Hersteller in der Workflow Management Coalition, um Architekturen und Schnittstellen zu standardisieren.

Grafik: Standardisierungsvorschlag der Worklfow Management Coalition für eine Architektur von Workflow-Management-Systemen

Bedeutung haben neben den Spezifikationen der Funktionalität auch die Normierung unterschiedlicher Ebenen der Interoperabilität:

• Level 0: keine Interoperabilität
• Level 1: Coexistence: Koexistenz zweier Workflow-Produkte, d.h. beide sind auf einer gemeinsamen Soft- und Hardwarebasis lauffähig. Schwächste Form der Interoperabilität.
• Level 2: Unique Gateway: Verbindung über ein Gateway, d.h. die Produkte können Arbeitsaufträge (tasks) austauschen.
• Level 2a: Common Gateway API: Gemeinsames Gateway-API. Eine Erweiterung von Level-2-Konsistenz.
• Level 3: Limited Common API: Beide Produkte unterstützen nur eine Teilmenge der Workflow APIs, z.B. Funktionsaufrufe zum Anmelden, für die Anforderungen von Arbeitsaufträgen und für das Melden erledigter Arbeitsaufträge.
• Level 4: Complete Workflow API: Alle Funktionen eines Workflow-Systems werden durch offengelegte APIs abgedeckt. Beide Produkte unterstützen vollständig die Workflow APIs.
• Level 5: Shared Definition Format: Die Produkte können zur Laufzeit die gleiche Prozessdefinition benutzen.
• Level 6: Protocol Compatibility: Protokollkompatibilität, d.h. alle APIs inklusive der Überführung von Prozessdefinitionen und Work Items sowie des Recovery usw. entsprechen dem Standard. Darin eingeschlossen sind auch die Schnittstellen zu den Administrations- und Überwachungswerkzeugen.
• Level 7: Common Look and Feel: Gemeinsame Benutzeroberfläche und Interaktion der beiden Produkte.

Workflow-Management#Workflow-Management-System

[Bearbeiten] 8.4 Realisierung von IuK-Systemen

[Bearbeiten] 8.4.1 Eigenerstellung und/oder Fremdbezug

Make-or-Buy-Problem: Ist Eigenerstellung oder Fremdbezug günstiger. Entscheidung ist sehr schwierig, da Kosten von IuK-Systemen nur sehr schwer geschätzt werden können. Eigenschaften der Entscheidung:

• Unternehmensspezifität
• Strategische Bedeutung
• Unsicherheit
• Häufigkeit

Grafik: Unternehmensspezifität und strategische Bedeutung der System-Aufgaben

Grafik: Matrix mit Normstrategien für Eigenerstgellung versus Fremdbezug

[Bearbeiten] 8.4.2 Aufteilung der Zuständigkeiten zwischen (dezentraler) Fachabteilung und (zentraler) DV-Abteilung

Neben Make-or-Buy ist auch die Frage der internen Zuständigkeit zu klären.

Grafik: Fachspezifität und technische Spezifität

Grafik: Aufgabenzuordnung an Fach- und Zentralabteilung

[Bearbeiten] 8.4.3 Technische Entwicklung von IuK-Systemen und Projektmanagement

Grafik: Zyklisches Vorgehensmodell für die Systementwicklung

[Bearbeiten] 8.5 Gestaltungspotenziale der IuK-Systeme

Faktoren:

• IuK-Technik ist zugleich Produktions- und Organisationstechnik
• IuK-Technik ist dezentral verfügbar
• Offenheit von Hard- und Softwaresystemen
• Werkzeugcharakter der IuK-Technik

[Bearbeiten] 8.5.1 Organisatorische Gestaltungspotenziale

[Bearbeiten] 8.5.1.1 Arbeitsteilung

Arbeitsteilung

[Bearbeiten] 8.5.1.2 Prozessorientierung

Prozess

[Bearbeiten] 8.5.1.3 Veränderung der relativen Effizienz von Koordinationsformen

Grafik: Auswirkungen der IuK-Technik auf Koordinationsformen

[Bearbeiten] 8.5.2 Personelle Gestaltungspotenziale

Personal

[Bearbeiten] 8.5.3 Negative sekundäre Effekte

Gesundheitsschäden, Bildschirmarbeit, Datenschutz

[Bearbeiten] IT-Strategie - Kaptiel 8 - 10 Strategische Ressource Information - Auf dem Weg in die Internet-Ökonomie

[Bearbeiten] 10.0 Lehr- und Lernziele

[Bearbeiten] 10.1 Computernetze als E-Business-Plattform

Computernetz, E-Business, Internet

[Bearbeiten] 10.1.1 Vom geschlossenen System (Großrechner) zum Internet-PC

Problem: fehlende Garantien für Übertragungskapazitäten:

• Kapazität der Backbone-Netze unzureichend
• begrenzte Übertragungsgeschwindigkeit des lokalen Netzzugangs

Grafik: Netzebenen der Datenkommunikation

Gilder's Law, Lösung durch weiteren Ausbau, Proxy- oder Mirror-Server, neue Zugangstechniken, xDSL, UMTS, iMode, Satelliten, Power-Line

Grafik: Projekte für den Aufbau von Satellitennetzen zur breitbandigen Datenkommunikation

Grafik: Geschwindigkeiten verschiedener Datenübertragungsnetze im Vergleich

Grafik: Entwicklung der IT-Industrie

Grafik: Phasen der IT-Marktentwicklung

Grosch's Law - Herbert Grosch - 2*Preis = Leistung*Leistung

Moore's Law - Gordon Moore - Anzahl der Transistoren*2 alle 18 Monate

Grafik: Folgen des Paradigmenwechsels: Spezialisten dominieren die IT-Industrie

Grafik: Marktstruktur bei vertikaler Integration und horizontaler Spezialisierung

Metcalfe's Law - Bob Metcalfe - 3com - Der Wert eines Netzwerks steigt im Quadrat der Anzahl seiner Nutzer ( W = n*n - n )

Großrechner, Mainframe, PC, Internet-PC

[Bearbeiten] 10.1.2 Internet-Wachstum und Netzeffekte

Netzeffekte: Eine neue Technologie setzt sich nur durch, wenn genügend Teilnehmer gewonnen werden können.

Grafik: Prognostiziertes US-Marktwachstum von PCs und Internet-Endgeräten

Grafik: Wachstum der Internet-Browser 1990 bis 2000

Grafik: Netzeffekte als Kreislauf der positiven Feedbacks

Grafik: Auswirkung positiver Feedbacks auf die Konkurrenzverhältnisse

[Bearbeiten] 10.1.3 Fallbeispiel Deutsche Bank AG: Strategische Implikationen von Informations- und Kommunikationstechnologien für das Bankgeschäft

Deutsche Bank AG

[Bearbeiten] Wirkungsfelder der IuK-Technologie im Bankgeschäft

I: Prozessbezogene Wirkungen

II: Produkt/-marktbezogene Wirkungen

[Bearbeiten] Implikationen für das strategische Management

Banken müssen die Technologie zur Steigerung der Wettbewerbsfähigkeit zu identifizieren, ohne potentielle Risiken für die eigene Wettbewerbsposition zu vernachlässigen. Bedingungen:

• Wirksamkeit von Skaleneffekten
• Bedeutung von Infrastrukturen
• Technologiesche Kompetenz als Erfolgsfaktor
• Bedeutung der Kooperationsfähigkeit
• Markttransparenz und Kundenbindung
• Basisdienstleistungen als strategischer Zugang zu Kunden

[Bearbeiten] Grundsätze der strategischen Informationssystem-Planung

[Bearbeiten] 10.2 vom Handel zum Electronic Commerce

Electronic Commerce

[Bearbeiten] 10.2.1 Grundlagen

Traditionelle Wertkette im Handel: Sortimentsgestaltung -> Informationsbeschaffung, -bewertung, -verteilung -> physische Distribution -> finanzielle Transaktionen -> Verbund-Dienstleistungen

Grafik: traditionelle Wertkette im Handel

Grafik: Entbündelung von Handelsfunktionen

Grafik: Umsätze der Internet-Händler im Bereich B2C

Grafik: EC nach Branchen

Grafik: Electronic Commerce in Westeuropa

Grafik: Finanzergebnisse der Online-Händler in Amerika

[Bearbeiten] 10.2.2 Transaktionsmodelle im Electronic Commerce

Vier Phasen der Ausstauschprozesse im Handel: Wissenphase (Informieren) -> Absichtsphase (Ziel definieren) -> Vereinbarungsphase (Verhandeln) -> Abwicklungsphase (Ausführen)

Grafik: Markttransaktionen

• Wissenphase: Informationsaustausch über Produkteigenschaften
• Absichtsphase: Konkrete Transaktionsabsichten in Form von Verkaufsgesprächen und Online-Angeboten
• Vereinbarungsphase: Verhandlungen
• Abwicklungsphase: Erfüllung der beiderseitigen Leistungsversprechen

Vier Ebenen als Grundlagen der Phasen der Markttransaktion im traditionellen und im elektronischen Handel:

• Kommunikationsinfrastruktur
• Marktplatz
• Transaktionsmechanismus
• Logistik

Grafik: Internet als elektronischer Marktplatz

Grafik: Transaktions- und Marktbereiche im Electronic Commerce

Transaktion

[Bearbeiten] 10.2.3 Arten, Ebenen und Ansätze im Electronic Commerce

C-Commerce

Grafik: Arten und Ebenen des Electronic Commerce

Grafik: Selbst bestimmter Electronic-Commerce-Ansatz auf Basis eigener Webseiten

Grafik: Fremd bestimmter Electronic-Commerce-Ansatz auf Basis eines Kundennetzes

Grafik: Fremd bestimmter Electronic-Commerce-Ansatz: Transaktion versus Commerce-Plattform

Grafik: Selbst und fremd bestimmter Electronic-Commerce-Ansatz: Marktplätze

[Bearbeiten] 10.3 Die eXtensible Markup Language (XML)

[Bearbeiten] 10.3.1 Einführung

XML ist eine verkürzte Version der Standard Generalized Markup Language (SGML), welche beschreibt, wie in elektronischen Dokumenten Strukturen und Inhalte beschrieben werden sollen. Zuständig ist das World Wide Web Consortium (W3C).

[Bearbeiten] 10.3.2 Einige Grundbegriffe

[Bearbeiten] 10.3.2.1 Dokumenttyp-Definitionen (DTDs)

Definiert Regeln für den Aufbau von Dokumenten.

DTD, XML-Schema

[Bearbeiten] 10.3.2.2 Elemente

<!ELEMENT autor #PCDATA>

 <autor>Johann Wolfgang von Goethe</autor>

[Bearbeiten] 10.3.2.3 Attribute

<!ATTLIST autor linkshaender (ja|nein) #IMPLIED>

 <autor linkshaender="ja">Friedrich Schilller</autor>

[Bearbeiten] 10.3.2.4 Entities

<!ENTITY fuh "Fern-Universitaet Hagen">

[Bearbeiten] 10.3.2.5 Parser und Anwendung

Aufgaben des Parsers:

• bestimmt, ob das Dokument wohlgeformt ist und gibt eventuell Fehlermeldungen
• Wenn sich das Dokument aus Bestandteilen zusammensetzt, die sich in unterschiedlichen Dateien befinden, führt er die Bestandteile zusammen
• Der Parser erstellt einen Baum, durch den die Inhalte der Elemente für die Anwendung zugreifbar werden

[Bearbeiten] 10.3.2.6 Zwei Arten, ein Dokument zu überprüfen

validierende und nicht-validierende Parser, Gültigkeit, Wohlgeformtheit

[Bearbeiten] 10.3.2.7 Zwei unterschiedliche Arten, ein Dokument zu betrachten

logische und physische Struktur des Dokuments

[Bearbeiten] 10.3.3 Prolog

<?xml version="1.0"?>
 <!DOCTYPE brief SYSTEM "brief.dtd">
 <brief>Hello</brief>

[Bearbeiten] 10.3.3.1 XML-Deklaration

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

[Bearbeiten] 10.3.3.2 Dokumenttyp-Deklaration

<!DOCTYPE brief SYSTEM "brief.dtd">

Interne DTD-Untermenge

Wurzel-Element

[Bearbeiten] 10.3.4 Elemente

[Bearbeiten] 10.3.4.1 Elementtyp-Deklaration

[Bearbeiten] 10.3.4.2 Inhaltsmodelle mit EMPTY und ANY

[Bearbeiten] 10.3.4.3 Element-Inhalt und gemischter Inhalt

[Bearbeiten] 10.3.5 Groß- und Kleinschreibung

[Bearbeiten] 10.3.6 Namen

[Bearbeiten] 10.3.7 Kommentare

Kommentar

[Bearbeiten] 10.3.8 Semantische Tags

[Bearbeiten] 10.3.9 Das Channel Definition Format (CDF)

en:channel Definition Format

[Bearbeiten] 10.4 Hyperlinks

Hyperlink

[Bearbeiten] 10.5 Fallstudie: Smart Tags im Microsoft Internet Explorer 6

Internet Explorer

[Bearbeiten] Wiki-Links

Links zum Thema IT-Management:

• Benutzer:Centic/Managementkonzepte, Kategorie:IT-Management, Kategorie:Projektmanagement

• Vorgehensmodell, Aufbauorganisation, Kosten-Nutzen-Analyse, Aufwandsschätzung, Projektplanung, Projektcontrolling, Controlling, Mitarbeiter, Qs, Qualitätssicherung, QM, Qualitätsmanagement, TQM, Total Quality Management, ISO 9000, Investition, Investitionsentscheidung, Kostenart, Nutzenart, Kostenrechnung, Zukunftsrechnung, Soll-Ist-Vergleich, Deckungsbeitrag, Gemeinkosten, Kostenträger, Einzelkosten, Vollkosten, Vollkostenrechnung, Deckungsbeitragsrechnung, Entwicklungsprojekt, Personal, Sachkosten, Kapitalkosten, Rationalisierung, Informationssystem, Investitionsrechnung, Entscheidungstechnik, Motivation, Prozessmodell (Software)

• Projektmanagement, Softwareprojekt, Strategie, Informationsmanagement, Data-Mining, Wissen, Wissensmanagement, Information, Informationsagent, Unternehmensstrategie, Wertkette, Wertschöpfungskette, Unternehmensstrategie, Organisatorissches Lernen (OL), Organizational Memory (OM), Organizational Memory Information System (OMIS), Organizational Intelligenze, Information und Kommunikation, AnswerGarden, Ontobroker, Data-Warehouse, Agent, Ontologie, Ontologie (Begriffsklärung), Ontologie (Informatik), Michael E. Porter, Software-Agent