Beschaffung vom Informationssystemen - Projektphasen • … · 2014-04-24 · beim...

Wirtschafts- undVerwaltungsinformatikProf. Busbach-RichardSS 2012Hochschule Kehl

Seite 1

• Grundlegende Definitionen• Technik• Beschaffung vom Informationssystemen

- Ausgangspunkt- Projektphasen- Analyse & Anforderung- Einführung

• Datenorganisation• Kommunikation


Seite 2

Ziel dieses Vorlesungsabschnitts:- kennen und verstehen der konkreten Vorgehensweisen

beim Projektmanagement in der IT Beschaffung- kennen und verstehen der spezifischen Probleme bei

der IT Beschaffung- erkennen und reflektieren der Problematik von

Akzeptanzproblemen bei der IT-Einführung- erkennen von Risiken der IT Beschaffung und

reflektieren, wie diese minimiert werden können


Seite 3

Ausgangspunkt:

Typische Problemaussagen?


Seite 4

Typische Problemaussagen

„Projekt zu teuer, dauert zu lang, es bewegt sich nichts“„Mitarbeiter verstehen nicht, akzeptieren nicht“„Informationen sind zur falschen Zeit am falschen Platz“„Besitzstandswahrung“ (Informelle Strukturen bleiben

bestehen oder fallen weg)„Sachen bleiben liegen, Doppelarbeit, Missverständnisse“

(Aufgabenteilung unklar)„Inseldenken“„Gewohnheiten sind manifest“„Unsere Mitarbeiter sind überfordert“ (Druck zu hoch)„Die Prioritäten sind falsch und es wird nicht an einem

Strang gezogen.“ (Verzettelung)


Seite 5

Studie Projekterfolg

Quelle: Standish Group

?


Seite 6

Studie Projekterfolg I - S

Quelle: Standish Group

• Projekt verschleppen sich – finden keinen Abschluss

• Erfolge verpuffen

• Viele Projektziele werden nicht erreicht

• Die erreichten Projektziele werden nicht nachhaltig erreicht


Seite 7

Studie Projekterfolg II - S


Seite 8

Studie Projekterfolg III - S

Durchschnittliche Verfehlung der Projektziele in %

189

222

61

0

50

100

150

200

250

Zeitüberschreitung Budgetüberschreitung Realisierte Features


Seite 9

Situation Technik• Hardware Chip-Leistungssprünge in ~ 6 Monatszyklen

• Software durchdringt kontinuierlich fast alle wesentlichen Industriebereiche

• Ende der 80‘ er-, Anfang der 1990‘ er-Jahre hat ein Verdrängungswettbewerb für Büroanwendungen stattgefunden (z.B. Textverarbeitung, Mail, Terminkalender, ...), 2010 Anwendungen und Daten in der „Cloud“

• Internet, Web, Web 2.0, Mobiles Internet etc.

• Dezentralisierung/Zentralisierung der Server


Seite 10

Situation Technik

• Zunehmende Qualitätsanforderungen an Software z.B. Software kann Menschenleben gefährden (Züge, Röntgengerät, Flugzeug, ...)

• Trend, Software-Entwicklungen durch Software Häuser (weltweit) entwickeln zu lassen („Outsourcing“, „Offshoring“)=> z.B. deutsche Softwareentwickler konkurrieren mit indischen Entwicklern

• Trend, Standard-Software für die verschiedenen Industriebranchen & öffentlichen Verwaltungen zu entwickeln („keine“ bzw. weniger Individual-SW)


Seite 11

Aber

• Software Komplexität nimmt weiter rasant zu

• Neue Software-Technologien und -anwendungen entstehen mit enormer Geschwindigkeit

Beherrschbarkeit einer Technik

100%

10%

Zeitdauer in Monaten

LernkurveNeue Technologien


Seite 12

Aber

• Termine werden nicht gehalten• Z.T. erhebliche Softwarequalitätsprobleme (z.B.Programmabstürze; Anforderungen, die nicht den Anwender-/Kundenwünschen entsprechen)• Die Softwarekosten dominieren inzwischen die Kosten für Hardware bei weitem

1


Seite 13

Warum ist Software eigentlich so schwer zu entwickeln?


Seite 14

Warum ist Software so schwer zu entwickeln? - S

• Immaterielles Produktman kann SW nicht „anfassen“,

nicht „sehen“nur Dokumentation beschreibt

die Software• Unterliegt keinem VerschleißProgramme können beliebig oft ablaufen„klassische Wartung“ nicht erforderlich•Keine ErsatzteileProgramm wird nur einmal entwickelt

Software HardwareBeispiel:

• Materielles Produkt

• Unterliegt einem VerschleißNach 200000 KM ist der Motor defekt• ErsatzteileNeuer Motor kann eingebaut werden


Seite 15

Warum ist Software so schwer zu entwickeln? (Forts.) - S

Software

•Schwer zu „vermessen“ Qualität zu definieren und zu

messen äußerst schwierig• AltertHW-Leistungen und SW-Techniken ändern sich ständig• Im allgemeinen (!!) leichter und schneller änderbar

Hardware

•Einfach zu „vermessen“

Ob die Schraube für die Radbefestigung passt oder nicht, kann mit einer Schieblehre festgestellt werden

• Altert• hoher ÄnderungsaufwandÄnderung der Kofferraumgröße erfordert die Konstruktion neuer Werkzeuge für die Produktion


Seite 16

Beispiel: Bau einer Hundehütte

Herausforderung für ? Person

Erfordert:

? Planungsaufwand

? Prozesse

? Werkzeuge


Seite 17

Beispiel: Bau einer Hundehütte - S

Herausforderung für eine Person

Erfordert:

minimalen Planungs-aufwand

einfache Prozesse

einfache Werkzeuge


Seite 18

Beispiel: Bau eines Hauses

Herausforderung für ?Erfordert

? Planungsaufwand? Prozesse? Werkzeug


Seite 19

Beispiel: Bau eines Hauses - S

Herausforderung für ein ganzes TeamErfordert

großen Planungsaufwand definierte Prozesse komplexe Werkzeug


Seite 20

Beispiel: Bau eines Hauses


Seite 21

Definition Software Entwicklung/Engineering

Software Engineering (dt. „Software-Technik“)Bereitstellung und systematische Verwendung von Methoden, Notationen und Werkzeugen für die teamorientierte, ingenieurmäßige Entwicklung und Anwendung von umfangreichen Software-Systemen unter Berücksichtigung von Kosten, Zeit und Qualität.

SystementwicklungEntwicklung von Systemen, die aus Hard- und Software Komponenten bestehen


Seite 22

Software Beschaffung/Entwicklung und Software-Lebenszyklus

-eine Einführung


Seite 23

?

Welche Phasen gibt es in der Software-Beschaffung (-Entwicklung)?

Von der Idee zum Produkt

Software Beschaffungs-prozess


Seite 24

PhasenJeder Phase umfasst • Tätigkeiten und• ErgebnisseLastenheft

Anforderungsspezifikationen

Architektur- und Entwurfs-beschreibungen

Programme

Testprogramme, getesteteProgramme, Abnahmeprotokolle,Installation der SW

Korrigierte und/oder erweiterteneue Version des Software-Produkts

Anforderung & Analyse

Planung

Entwurf

Implementierung & Test

Test & Einführung

Wartung

vage

präzise


Seite 25

Planung

Ziel: Grobe Beschreibung des geplanten Softwareprodukts

• Bereich festlegen, der unterstützt werden soll• Marktanalysen (welche Produkte gibt es, wie sind die Anbieter am Markt positioniert?,...)• Anwenderbefragungen (was ist dem Anwender wichtig, was ist unwichtig?)• Festlegen der funktionalen Hauptanforderungen• Personalressourcen und Kompetenzen• Zielbestimmung

Typische Tätigkeiten :


Seite 26

Planung • Festlegen der technischen Anforderungen • Festlegen wichtiger Qualitätsanforderungen (Können

Menschenleben in Gefahr sein; Erfüllung gesetzlicher Bestimmungen?)

• Aufwandsschätzung für die Anforderungsphase und Haupt-Meilensteinen

• Prüfen personeller Verfügbarkeit (wie viel und welche Mitarbeiter?)

• Wirtschaftlichkeitsrechnung (Projekt- & Folgekosten)• Machbarkeitsanalyse => Risikoanalyse • Make-or-Buy Entscheidungen


Seite 27

Ergebnisse Planung - S

• Lastenheft (Synonyme: (grobes) Pflichtenheft oder System Requirement Specification)

=> Grobe Auswahlkriterien bestimmt

• Grober Projektplan mit ersten (Haupt-)meilensteinen1

• Go oder No-Go-Entscheidung für die Fortführung des Projekts

1 Ein Meilenstein ist ein Datum, an dem überprüfbare Teilergebnisse vorliegen müssen


Seite 28

Grober Projektplan

Anforderung & Analyse

Planung

Entwurf

Implementierung

Test & Einführung

Meilensteine am Ende einer Phase

Lieferdatum 30.12.012

Ende Implementierung 30.10.12

Ende Entwurf 30.6.12

Ende Anforderung 30.2.12

Ende Planung 30.1.12

?

?

?


Seite 29

Anforderung und AnalyseZiel: Vollständige, konsistente und eindeutige Definition der Anforderungen für das SW-Produkt

Typische Tätigkeiten?


Seite 30

Anforderung und Analyse - STypische Tätigkeiten:

• Anforderungen • ermitteln• konkretisieren• modellieren • priorisieren• festlegen • beschreiben

(was ist dem Anwender wichtig, was ist unwichtig?)=> Analyse


Seite 31

Anforderung und Analyse - STypische Tätigkeiten (Forts.):

• ggf. Prototyp entwickeln (zur Klärung einer Anforderung z.B. die zugehörige Bedienoberfläche zu realisieren?)

• Aufwände detailliert schätzen (Wieviel Wochen-Entwicklungsaufwand kostet die Anforderung XYZ?)

• Projektplanung verfeinern• Detaillierter Anforderungs-/Kriterienkatalog erstellen


Seite 32

Anforderung und Analyse

Ergebnis: PflichtenheftJe nach Projektinstallation entweder

- zwischen Auftraggeber und Auftragnehmer verabschiedetes Pflichtenheft und verfeinerter Projektplan (mit Lieferdatum) – (Ausschreibung bereits nach Planung)

oder- Pflichtenheft als Basis der Ausschreibung und der Auswahl

mit (gewünschten) Zeitverlauf des Projekts aus Sicht des Auftragebers


Seite 33

Entwurf (engl. „Design“)

Ziel: Definition und Implementierung einer Softwarearchitektur, die die funktionalen-, nicht-funktionalen- und Qualitätsanforderungen erfüllt Typische Tätigkeiten: • Zerlegung des Systems in Komponenten und Präzisierung der Beschreibungen aus der Anforderungsphase• Beschreibung der Komponenten mit den Schnittstellen und deren Zusammenspiel („Softwarearchitektur“)• Anpassung und Erweiterung existierender Software-Lösungen

Ergebnis: Architektur- und Entwurfsdokumente


Seite 34

Implementierung

Ziel: Fertigstellung fehlender Implementierungsteile aus der Entwurfsphase

Typische Tätigkeiten:

• Programmieren fehlender Funktionen• Testen einzelner Funktionen• Dokumentation der Programme

Ergebnis: dokumentierter Source Code („Quelltext“) mit einzelnen ablauffähigen Funktionen,aber diese ergeben i.a. noch keinfunktionsfähiges Programm


Seite 35

Test & Einführung

Ziel: Fertigstellung des Tests für alle FunktionenTypische Tätigkeiten:• Entwicklung von Testprogrammen• Sukzessives Hinzufügen einzelner Komponenten und

Testen dieser Teile („Integrationstest“)• Test des Gesamtsystems im Hinblick auf alle Produktan-

forderungen („Systemtest“)• Durchführung von Tests (auch durch den Auftraggeber)• Dokumentation von Fehlern in Testprotokollen

(„Known bug list“)

Ergebnis: getestetes und durch Auftraggeber abgenommenes Softwareprodukt / Anwendungssystem


Seite 36

Wartung

Ziel: Fehler, die im täglichen Betrieb auftauchen, bereinigen und/oder Erweiterungen für neue oder geänderte Anforderungen durchführen

Typische Tätigkeiten:• Fehler (z.B. Programmabstürze, mangelnde

Performanz, zu hoher Speicherbedarf) beseitigen• neue Anforderungen realisieren

Wartung ist der Zeitraum von der ersten Installation bis zum Einsatzende des Anwendungssystems


Seite 37

Wartung

Ergebnis: neue Version des Softwareprodukts/ des Anwendungssystems

Beachten: Bei neuen Anforderungen und/oder Fehlern können alle Phasen wieder durchlaufen werden –abhängig vom Umfang der Anforderungen

Wichtig: Tests sind immer durchzuführen


Seite 38

Was sind die vier wichtigsten Risikokategorien bei der Auswahl von

Anwendungssystemen


Seite 39

Die vier wichtigsten Risikokategorien bei der Auswahl von Anwendungssystemen - S

• AnforderungsrisikenGefahr Anforderungen zu realisieren, die nicht vom Anwender gefordert sind

• Technologische RisikenIhnen ist gesagt worden, dass Sie Java, Web und objektorientiertes Design verwenden sollen. Wie gutfunktionieren diese Techniken für Ihr zu erstellendes Produkt? Lassen sich z.B. die geforderten Performanceanforderungen mit Java realisieren?


Seite 40

• MitarbeiterrisikenHaben Sie die notwendigen Mitarbeiter mit der erforderlichen Erfahrung für Projekt- und Risikomanagement? Werden Mitarbeiter längere Zeit krank?

• Politische RisikenGibt es politische Zwänge, die das Projekt maßgeblich beeinflussen können?

Alle Risikokategorien sind gleich gefährlich

Notwendigkeit einer Risikoanalyse

Die vier wichtigsten Risikokategorien bei der Auswahl von Anwendungssystemen - S


Seite 41

RisikoanalyseDefinition

Eine Risikoanalyse ist die Ermittlung und Einschätzung der einem Projekt drohenden Gefahren

1. Identifikation der RisikoquellenGrundlagen (soweit vorhanden):

• Projektszenario • Lastenheft oder Pflichtenheft • andere Planungsgrundlagen• Erfahrungen


Seite 42

Identifikation der Risikoquellen

Aufgabe: Zusammenstellung der Risikoquellen• die bereits in der Machbarkeitsstudie identifiziert

wurden (Hardware, Software, ...)• Identifikation weiterer Risikoquellen

Beispiele aus dem Mitarbeiterbereich könnten sein:Projektleiter Entwicklungs-"Hero" EntscheiderEndanwender Betriebsrat Datenschutzbeauftragter

Ergebnis:• Liste der Risikoquellen


Seite 43

Identifikation der Risikofaktoren

2. Identifikation der Risikofaktoren (d.h. der Gefahren, die das Projekt bedrohen) Grundlagen:

• Liste der Risikoquellen• Erfahrungen

Aufgabe:• Identifikation von speziellen Risikofaktoren im

konkreten Projekt


Seite 44

Identifikation der Risikofaktoren

Ergebnisse:• Liste der Risikofaktoren• Liste der möglichen Risikoereignisse• Beschreibung der Risikosymptome (z.B. zur

Früherkennung)• Einflüsse auf Prozesse im Projekt


Seite 45

3. Bewertung der Risikofaktoren Grundlagen:

• Risikobereitschaft des Auftraggebers• Liste der Risikofaktoren• Liste der möglichen Risikoereignisse• Kostenschätzungen• Terminschätzungen

Bewertung der Risikofaktoren


Seite 46

Bewertung der RisikofaktorenAufgabe: Für jeden Risikofaktor Bewertung des

entsprechenden Risikos. Bewertung hängt ab von• den Auswirkungen des Risikoereignisses ("Kritikalität")• der Wahrscheinlichkeit, dass ein Risikoereignis eintritt• der Wirksamkeit von Gegenmaßnahmen

Ergebnisse:• Rangfolge der Risikofaktoren• Meilensteine, die besondere Aufmerksamkeit erfordern

und• mögliche Risikofaktoren, die genau beobachtet werden

sollten• Risikoquellen und -faktoren, die ignoriert werden können• Dokumentation, wer diese Entscheidung gefällt hat


Seite 47

Beispiel einer Risikoanalyse

Quelle:[Steinbach 98]


Seite 48

Beispiel einer Risikoanalyse - S


Seite 49

Entwicklung einer Reaktionstaktik

Entwicklung einer ReaktionstaktikGrundlagen:

• Meilensteine, die besondere Aufmerksamkeit erfordern und

• mögliche Risikofaktoren, die genau beobachtet werden sollten

• Risikoquellen und -faktoren, die ignoriert werden können einschließlich Dokumentation, wer diese Entscheidung gefällt hat

Aufgabe: Für die ausgewählten Meilensteine bzw. Risikofaktoren Diagnoseinstrumente, Gegenmaßnahmen und Verfahrensregeln entwickeln


Seite 50

Entwicklung einer Reaktionstaktik

Ergebnisse:• Diagnoseplanung (Berichte, Interviews, ...)• Eskalations- und Maßnahmenplan bei Eintreffen

eines Risikoereignisses• Eingaben für andere Prozesse• Abschätzung verbleibende Reserven• Vorbereitung von Verträgen


Seite 51

Entwicklung einer Reaktionstaktik - Beispiel


Seite 52

Entwicklung einer Reaktionstaktik – Beispiel - S

Beispiele:


Seite 53

Erfolgsfaktoren

Project Success Factors

% of Responses

1. User Involvement 15.9%2. Executive Management Support 13.9%3. Clear Statement of Requirements 13.0%4. Proper Planning 9.6%5. Realistic Expectations 8.2%6. Smaller Project Milestones 7.7%7. Competent Staff 7.2%8. Ownership 5.3%9. Clear Vision & Objectives 2.9%10. Hard-Working, Focused Staff 2.4%Other 13.9%


Seite 54

Clear Statement of Requirements /User Involvement

=>Anforderung und Analyse


Seite 55

Fehlerfortpflanzung


Seite 56

Fehlerfortpflanzung – S

VorstudieSpezifikation

Systementwurf

Realisierung

Integration Korrekte Vorgänge

Korrigierbare Fehler

unkorrigierbare Fehler

verborgene Fehler

Korrekte Programme

fehlerhafte Programme

Programmefür fehlerhaftenSystementwurf

Programme für fehlerhafte Anforderungen

Korrekter Systementwurf

fehlerhafter Systementwurf

Systementwurf für fehlerhafte Anforderungen

KorrekteAnforderungen

fehlerhafteAnforderungen

Anforderungen

Unzureichendes SW-Produkt


Seite 57

SW-Beschaffungsphasen & Fehlerentstehung - S


Seite 58

Ausweg

Modellierung während der AnforderungsphaseDaten (UML, ERM -> Datenorganisation)Prozesse (EPK -> E-Government)

KommunikationQualitätsmanagement


Seite 59

User Involvement =>

Einführungsphase


Seite 60

Ziele von IT Projekten

Wirtschaftliches Interesse:Hinter jeder Investition steht ein wirtschaftliches Interesse. Ziele sind in der Regel Einsparungen oder Umsatz- bzw. Gewinnerhöhung.

Software

Implementiertes System

Return on Invest (ROI)


Seite 61

Erfolgsfaktoren für ein IT System

Erfolgsfaktoren für ein IT-System:•

•


Seite 62

Erfolgsfaktoren für ein IT System - S

Erfolgsfaktoren für ein IT-System:

Die technische Funktionsfähigkeit, d.h. die erfolgreiche Realisierung einer bestimmten Funktionalität schafft ein Potenzial für Verbesserungen.

Der wirtschaftliche Erfolg entsteht jedoch erst durch die effektive Nutzung des Systems (Umsetzung des technischen Potenzials in wirtschaftlichen Erfolg)


Seite 63

Effektive Nutzung - S

Effektive Nutzung:Effektive Nutzung eines IT-Systems bedeutet, dass Menschen dieses System so einsetzen, dass sie ihre Aufgaben innerhalb der Organisation „besser“ (Zeit, Kosten, Qualität) erfüllen können


Seite 64

IT-Einführung

Zusätzliche Aufgaben bei IT-Einführungen:Notwendig ist die Anpassung der Organisation an die neuen Möglichkeiten/Potenziale und die Begleitung des Mitarbeiters in diesem „Change-Prozess“

U‘plan

Geschäftsprozesse

Mensch Maschine

Auswirkungen neuer IT-Lösungen innerhalb der Unternehmensarchitektur


Seite 65

Diskrepanz Methodik

Technischer BereichMeist ausgereifte und detaillierte MethodikModelle bzgl. Vorgehen und StrukturierungWerkzeuge: Checklisten, Formulare, ...

Bereich Mensch/MitarbeiterOft mangelhaft beachteter/ausgeklammerter AspektVielfach technische Sicht auf den Aufgabenträger

Mensch (Schulungen=Update?)Eher Erfahrung bzw. Intuition des Projektleiters statt

methodische Fundierung


Seite 66

Fragen, die oft nicht beantwortet werden

• Wie verändert das Projekt die tägliche Arbeit der Mitarbeiter?

• Wie wird die Zusammenarbeit verändert?• Wie werden diese Veränderungen

aufgenommen?• Wissen die Mitarbeiter, warum das Projekt

notwendig ist?• Ist klar, was passiert, wenn das Projekt nicht

erfolgreich ist? • Was passiert, wenn das Projekt nicht die

notwendige Akzeptanz findet?


Seite 67

Fazit:Phasendenken/Vorgehensmodelle alleine reichen nicht!(sind aber notwendige Voraussetzungen für Erfolg)

Zusätzlich gesamtheitliche Sicht notwendig:- TQM- Change Management- QMS

Kommunikation zwischen Anwender und Entwickler auch in fast allen anderen Phasen

Date post:	01-Aug-2020
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

Beschaffung vom Informationssystemen - Projektphasen • … · 2014-04-24 · beim...

Documents