Home

Transferarbeit Urs Zihlmann · HSLU iPMT

1. Stakeholder Analyse Firma Beispiel AG Projekt Golfplatz Alte M hle Projektleiter R Schindler Stand 12 02 2008 g nstige Konditionen Pr sident und K Spielf hrer 4 einheimisch hohe Akzeptanz beider j 3 000 Einwohnern ristik g modern viele f r sich und Familie geschlossen werden onst kein Weiterbau l chen verpachten BUND Naturschutz fkooperativ spielt selbst Golf i wenn der Umsatz stimmt Golfelubs sollen im Handwerker berh hte wischen den Firmen 2 Rechnungen sind hoch nicht solen Abbildung 7 Stakeholder Analyse W hrend der Projektdurchf hrung sollte die Stakeholder Anaylse sinnvollerweise immer wieder berpr ft werden da die relevanten Stakeholder sowie ihre Macht und Verbindungen sich im Laufe des Projekts ver ndern k nnen 4 Gregorc amp Weiner 2005 4 Siehe https www openpm info display openPM Stakeholderanalyse 21 07 2013 Burghardt 2012 S 546 Transferarbeit Urs Zihlmann Seite 29 v C HOCHSCHULE LUZERN Technik amp Architektur Stakeholder Management Ein aktives professionelles Stakeholder Management erschliesst enorme Projektpotenziale Empfehlungen f r ein erfolgreiches Stakeholder Management a Die Identifikation wichtiger Stakeholder erfolgt bereits in der der Projektvorbereitung Effizientes Stakeholder Management konzentr
2. What the stakeholders want What the Scrum Master does Result of the first Sprint After second Sprint Product as ordered Abbildung 42 The Scrum Cartoon Der Product Owner der Vision r Der Product Owner repr sentiert den Kunden und somit den Anforderer Er verf gt ber das notwendige Wissen um Anforderungen zu formulieren und Detailfragen beantworten zu k nnen Der Product Owner ist der fachliche Projektleiter und f r den Gesamterfolg des Projekts verantwortlich Er arbeitet auf t glicher Basis mit dem Team trifft zeitnah die notwendigen Entscheidungen und arbeitet kontinuierlich am Product Backlog und dem Releaseplan Das Entwicklungsteam die Lieferanten Das Team ist f r die erfolgreiche Umsetzung der Anforderungen eines Sprints verantwortlich Es steuert die Arbeitsmenge selbst die es bew ltigen kann Daf r tr gt es aber auch die Verantwortung f r die Qualit t der Lieferung 120 Wirdemann 2011 S 29 121 Siehe http www steffen persiel de 2009 the scrum cartoon 24 09 2013 Transferarbeit Urs Zihlmann Seite 87 C C HOCHSCHULE LUZERN Technik amp Architektur Der ScrumMaster der Change Agent Der ScrumMaster ist f r die Einf hrung und Umsetzung von Scrum zust ndig Er coacht das Team gibt aber keine Handlungsanweisungen oder weist Aufgaben zu Ein ScrumMaster ist kein Vorgesetzter Er r umt Hindernisse aus dem Weg sorgt f r optimale Arbeitsbedingungen und h lt dem Team den R cken
3. pc Abbildung 26 Abbildung 27 Abbildung 28 Abbildung 29 Abbildung 30 Abbildung 31 Abbildung 32 Abbildung 33 Abbildung 34 Abbildung 35 Abbildung 36 Abbildung 37 Abbildung 38 Abbildung 39 Abbildung 40 Abbildung 41 Abbildung 42 Abbildung 43 Abbildung 44 Abbildung 45 Abbildung 46 Abbildung 47 Abbildung 48 Abbildung 49 Abbildung 50 Abbildung 51 Abbildung 52 Abbildung 53 Abbildung 54 Abbildung 55 Abbildung 56 Transferarbeit Urs Zihlmann Lucerne University of Applied Sciences and Arts HOCHSCHULE LUZERN Technik amp Architektur Software Modultest im V Modell 2u 4404444400Hn non nnnnnonnnnnnnnnnnnnnnnnnnnnnnnnennsnnnnnnnnnernnnnennnsnenen 70 Abdeckungskriterien CO C1 und CH 71 Funktionaler amp nicht funktionaler Test im V Modell 72 Testwiederholung im FehlermanagementprozesS sssseesesssnrteesttnntsetttrnsrtnnnnnsernn nn nnse ennenen 74 alte g E3 1 e a 51 1 1 WPPENNRIERSET ESEL PETER ENENEBEEENNBLETEERBEERIECSECEEREHHRIEEREEHREEFEREFBEEREENFPECRERNFIESEPEFUEEETTREPEEANESEBFTERBER 74 Aktivit ten Rollen und Status im Fehlermanagement Bug Lifecycle AAA 75 Software Abnahmetest im V Modell A 76 Phasen bei sequentiellen Vorgehensmodellen sssnsssssssnnesessnnnnrssrnnrrnsrennnrtesennnnnnernnnnnennnnn ensenen 79 VUEN ET ue TEE 79 VE leie TT Dilbert Agile Programming Traditionell ys Agile iise eeneiige eaae a a elelnsleieenan 82 Prescr
4. Continuous Integration ist ein Prozess des kontinuierlichen Builds amp Testen einer Software und ein integraler Bestandteil agiler Entwicklungsmethoden Inhalt und Zweck o Kontinuierliches Einbringen von Software nderungen in das Konfigurationsmanagement Automatische statische Code Analyse Pr fung gegen Coding Guidelines Code Metriken Automatisches Build des Gesamtsystems nach Einbringen einer Software nderung Automatische Testausf hrung Modultests Automatisierte Erstellung des Installers und Deployment in der Zielumgebung Automatisierte und manuelle Ausf hrung der systemspezifischen Tests Transferarbeit Urs Zihlmann Seite 66 Lucerne University of C C HOCHSCHULE LUZERN Technik amp Architektur Software Modultest QA Plan Testkonzept Testplan Templates Zusammenh nge und Inhalte von Qualit tssicherungsplan Testkonzept und Testplan verstehen Kemtrage Wie sehen Inhalt und Struktur eines Testplans aus Qualit tssicherungsplan Review Definition Im Qualit tssicherungsplan werden die Ergebnisse der Qualit tsplanung dokumentiert Ein Qualit tssicherungsplan beinhaltet folgende Themen Was muss gesichert werden Wann muss gesichert werden Wie muss gesichert werden Von wem muss gesichert werden Die folgende Grafik zeigt ein Gliederungsschema nach dem IEEE Standard 730 84 Qualit tssicherungsplan Gesamtheit der qualit tssichernden Massnahmen in der Software Entwic
5. blicherweise oft k nnte sollte darf im Allgemeinen Eine Satzschablone Requirements Template ist ein Bauplan f r die syntaktische Struktur einer einzelnen Anforderung Die rechtliche Verbindlichkeit wird mit sogenannten Modalverben ausgedr ckt Karol Fr hauf empfiehlt nur Muss Anforderungen zu schreiben weil Modalverben wie sollte kann und wird nicht verbindlich sind und somit einen Widerspruch darstellen 2 lt Wem gt x die M glichkeit bieten SN lt Prozesswort gt 7 f hig sein lt Prozesswort gt Abbildung 15 Umfassende Satzschablone 83 Fr hauf IV 2013 S 13 84 Pohl 2012 S 57 85 Fr hauf V 2013 S 12 86 Fr hauf V 2013 S 11 Transferarbeit Urs Zihlmann Seite 52 C C HOCHSCHULE LUZERN Technik amp Architektur Modellbasiertes dokumentieren In der modellbasierten Dokumentation von Anforderungen werden typischerweise die drei Perspektiven Funktion Struktur und Verhalten unterschieden F r jede dieser drei Perspektiven existieren jeweils geeignete Modellierungssprachen um die Informationen zweckm ssig zu dokumentieren Ein Modell ist ein abstraktes Abbild einer existierenden oder einer noch zu schaffenden Realit t Funktionsperspektive Funktionsperspektive Sa Set SE diagramm Die Modelle der Funktionsperspektive dokumentieren welche Funktionen ein System bereitstellen muss In diesem Zusammenhang wird dargestellt welche Date
6. Personen die ein Interesse am Projekt haben oder vom Projekt in irgendeiner Weise betroffen sind Stakeholder Analyse Vorgehen Identifizierung der Stakeholder Analyse der Stakeholder inkl Kraftfeldanalyse Aus 1 und 2 die Frage beantworten Wer kann wie das Projekt zum Scheitern bringen Ableitung von Konsequenzen f r das Stakeholdermanagement und Massnahmen f r das Risikomanagement definieren Die Stakeholderanalyse fokussiert auf die Ermittlung von Interessentr gern Stakeholder einer Sache sowie der Art ihrer Beziehung zu dieser Sache Typische Stakeholder eines Unternehmens sind beispielsweise Lieferanten Kunden Mitarbeiter Management Eigent mer Beh rden Konkurrenten etc 7 8 Siehe https www openpm info display openPM Stakeholderanalyse 21 07 2013 Transferarbeit Urs Zihlmann Seite 28 LUZERN Technik amp Architektur C p C HOCHSCHULE Die Stakeholder k nnen geordnet werden nach o Ihrem Einfluss auf andere Stakeholder Ihrem Entscheidungspotenzial finanziell technisch politisch etc Ihrer Einstellung zum Projekt Gegner Konkurrent Bef rworter neutral Ihrer Rolle im Projekt Ihren Beziehungen untereinander Tabelle 10 Stakeholder Identity Matrix Card Die Analyse ist die Grundlage daf r Stakeholder gezielt in einem Kommunikationsplan adressieren zu k nnen und die Kommunikation mit den Stakeholdern sowie das Verst ndnis ihrer Interessen zu verbessern 28
7. anzuwenden Die Kursteilnehmenden kennen die Probleme die beim Einzelnen oder in Gruppen beim Lernen auftauchen k nnen Sie erkennen gruppendynamische Prozesse und k nnen mit Widerstand konstruktiv umgehen Sie gewinnen Sicherheit im Unterrichten und sind f hig ihre Rolle als Superuser Ausbildner zu reflektieren Die KursteilnehmerInnen werden mit dem Mittel der simulierten Kommunikation auf schwierige Gespr che vorbereitet In einer gesch tzten Atmosph re k nnen zusammen mit professionellen SchauspielerInnen optimal individuelle Gespr chstechniken und Deeskalationsmethoden ausprobiert werden Im Rahmen dieses Kurses lernen die Seminarteilnehmerlnnen ihr kommunikatives Potential und ihre Grenzen besser kennen Die Teilnehmenden o k nnen mit Kommunikationsproblemen die in tempor r zusammengestellten Teams auftreten besser umgehen erkennen die Konfliktpotentiale die sich aus Kommunikationsschwierigkeiten ergeben und wissen welche Verhaltensweisen eskalierend oder deeskalierend wirken sind besser bef higt unpopul re Entscheide durchzusetzen ohne die Mitarbeitenden zu demotivieren Wer Teamleiterin oder Gruppenleiter wird oder vor kurzem geworden ist muss ganz neue Aufgaben bernehmen Wer seine F hrungsrolle professionell aus ben will sollte ber entsprechendes Knowhow verf gen In f nf Tagen k nnen die wichtigsten F higkeiten einer berzeugenden F hrungsperson einge bt werden Tages Themen sind Selbstkennt
8. Technik amp Architektur Coding Standards amp Coding Guidelines 64 Statische Code Analyse mit Code Metriken 65 Continuous Integration 66 SOFTWARE MODULTEST 67 QA Plan Testkonzept Testplan Templates 67 Testprozess 69 Arten von Fehlern in der Software 69 Struktureller Test White Box 70 C0 C1 Abdeckung 71 FUNKTIONALER UND NICHT FUNKTIONALER SOFTWARE TEST 72 Funktionaler Test Black Box 72 Testmethoden quivalenz Grenzwert Zustand 72 Regression und Automatisierung 74 Fehlermanagement 75 SOFTWARE ABNAHMETEST 76 TRANSFER IN DIE BETRIEBLICHE UMGEBUNG eg Wie machen wir es heute 77 Umsetzungsm glichkeiten im Betrieb 77 7 VORGEHENSMODELLE BEI DER SOFTWAREENTWICKLUNG 78 BERBLICK VORGEHENSMODELLE 8 Die wichtigsten Vorgehensmodelle 79 AGILE MODELLE 81 Probleme traditioneller Methoden 81 Das Agile Manifest 82 berblick Agile Modelle 83 Vergleich Agile und Lean 83 SCRUM 85 Scrum Flow 86 Rollen 87 Meetings 88 Die Artefakte 91 Scrum ersetzt nicht das Projektmanagement 92 CHANGE MANAGEMENT 92 BERBLICK VON VORGEHENSMODELLEN IN DER IT 93 TRANSFER IN DIE BETRIEBLICHE UMGEBUNG 94 Wie machen wir es heute 94 Umsetzungsm glichkeiten im Betrieb 94 8 F HRUNG IM PROJEKT 96 TEAMROLE 00000 97 Teamentwicklungsuhr 97 Belbin 99 KONFLIKT MANAGEMENT JD Merkmale 100 Chancen in Konflikten 101 Konfliktarten 102 Konflikttypen 103 Konflikte austragen 103 Konflikt Eskalation 105 Konflikt Gespr ch 106 Transferarbeit
9. bung Alien Race entgegenkam Diese bung wiederspiegelt das 6 Phasen Modell Problemfindung Ideengenerierung Entscheidung Umsetzung Implementierung Routine und mir pers nlich hat die bung grossen Spass gemacht obwohl es immer wieder frustrierende Momente gab In diesem Spiel lernte man nicht nur das Team sondern auch sich selber besser kennen o Welche Teamfunktion nehme ich ein o F hre ich diese Funktion auch aus o Bringe ich aktiv Ideen ein oder setze ich nur meine Pflichten um o Bin ich beeinflussbar oder beeinflusse ich andere im Team o _ Verbreite ich positive oder negative Stimmung o Wie gehe ich mit negativen Emotionen um o Gebe ich zu fr h auf oder suche ich bis zum Schluss nach einer L sung In der anschliessenden Reflektions Aufgabe besprachen wir die bung und es war interessant die Erlebnisse mit den anderen zu diskutieren Meine wichtigsten Erkenntnisse aus dieser bung sind o Fokus auf Metakommunikation G rtli Denken berwinden o Maske 23 anwenden Wo ist die Systemgrenze Was ist das Thema Wichtigkeit der Pr senz einer F hrungsperson o Projekte sind nie linear Als n chstes besch ftigten wir uns mit den Teamrollen und der Teamentwicklungsuhr Wir arbeiteten in kleinen Gruppen und kamen schlussendlich zum Ergebnis dass unsere Klasse immer noch in der Phase 1 forming ist Zur Vorbereitung des Seminars haben wir die Selbsteinsch tzung nach Belbin ausgef llt Belbin zeigt a
10. Coding Guidelines T Software Quellcode Statische Code Analyse Code Metriken Modultest vs Code Modul Ill Inspection Software Modultest IN Sn ee Ge D er QA Plan Testkonzept Testplan Templates Testprozess Arten von Fehlern in der Software Struktureller Test C0 C1 Abdeckung White Box Abbildung 18 berblick der Software Qualit ts Module Transferarbeit Urs Zihlmann Seite 59 LUZERN Technik amp Architektur Lucerne University of Applied Sciences and Arts r DC HOCHSCHULE Verifikation von Software Anforderungsspezifikationen Grundlage Software Verifikation Ziel Review der Software Verifikationsmassnahmen automatische Analysen Metriken Test in der bersicht darstellen Kernfrage Welche Verifikationsmassnahmen werden heute bei uns eingesetzt und welche sollten wir in Zukunft verwenden Die Verifikation befasst sich mit dem Messen und Untersuchen von Merkmalen einer Einheit o Vergleichen mit festgelegten Forderungen o Feststellen der Konformit t f r jedes Merkmal Review o Vermeidung von Fehlermultiplikationseffekten durch fr hzeitiges Review von Spezifikationen o Sinnvolle Methoden f r ein Review des Codes o Review der Testspezifikationen auch Projektpl ne Automatische Analysen o Erh hung der Lesbarkeit und Wartbarkeit von Code o Identifizierung m glicher Problembereiche o Einsatz von Software Tools f r die Pr fung der Konformit t des Codes mit Coding Standards und Guid
11. Ein und Ausgabeger te Hardware und Software Screen und GUI Design Softwareentwicklung Screen und GUI Design Accessibility Usability vizrt Grafiksystem Screendesign Echtzeit Grafiken Informationsvermittlung durch grafische Elemente visuelle Kommunikation Es ist seit l ngerer Zeit ein Thema bei eMedia die Kompetenzen im Bereich Grafik auszubauen Im Moment werden f r unsere Produkte wenig Ressourcen f r Design grafische Arbeiten Informations Architektur Usability und Accessibility eingeplant 70 Siehe http www buerowelten ch de 201 1 04 kreativitat kann man kreativitat lernen 12 07 2013 C C HOCHSCHULE LUZERN Technik amp Architektur In der Softwareentwicklung werden Templates verwendet so dass unsere Web Applikationen ein einheitliches Erscheinungsbild haben Es gibt allerdings keine Guidelines zur Navigations und Informationsgestaltung Der Softwareentwickler setzt diese Aspekte nach bestem Wissen und Gewissen um Umsetzungsm glichkeiten im Betrieb Probleml sungsprozess Verbesserungspotential sehe ich insbesondere bei der L sungssuche Wie oben beschrieben befasst sich der Projektleiter mit den m glichen L sungen und gibt dem STEA eine Empfehlung ab Das Anwenden von Kreativmethoden im Team h tte zum Vorteil dass ganz neue L sungen zum Vorschein k men Eine Risikoanalyse w rde ausserdem den STEA bei der L sungsentscheidung unterst tzen Diese beiden Optimierungsmassnahmen w rden d
12. Gemeinsam in den Abgrund Lucerne University of Applied Sciences and Arts HOCHSCHULE LUZERN Technik amp Architektur Unterschiedliche gegenseitig nicht nachvollziehbare Auffassungen Verletztende usserungen Imponiergehabe und Schwarz Weiss Denken Nonverbales Verhalten Blockaden Misstrauen und Projektionsmechanismen Feindseligkeit Abwertung der Gegenpartei aussenstehende Verb ndete gewinnen Feindbild Gesichtsverlust wird provoziert Unterstellung falscher Werte Strafen Vergeltungsmassnahmen Horrorszenarien Ultimaten Einsch chterung Sabotagen kein Zuh ren Zuf gen von Sch den lose lose Versuch Gegenpartei handlungs und steuerungsunf hig zu machen kein Zur ck Vernichtung steht im Vordergrund eigene Niederlage als Genugtuung zum Beweis der Schlechtigkeit der Gegenpartei Um einen Konflikt zu l sen braucht es Handwerkszeug Eine gute Vorbereitung ist die halbe Miete und sie hilft Ihnen sich sicher zu f hlen 15 Phase Vorbereitung Einstieg Kl rung L sung Abschluss 1 Schritt Eigene Bed rfnisse Gef hle Ziele kl ren Kontakt Hersteller Konflikte konstruktiv ansprechen L sungsideen sammeln Kl ren ob alles besprochen wurde 2 Schritt In meinen Konflikt partner hineinversetzen Anlass und Ziel des Gespr chs nochmals nennen Auf Konfliktpartner eingehen W nsche und Bed rfnisse ussern Gespr ch gemeinsam reflektieren 151 Siehe
13. Konflikte austragen Konflikte finden immer auf zwei Ebenen statt auf der Sach und auf der Beziehungsebene Die Sachebene ist deutlich im konkreten Verhalten und in den ge usserten Argumenten der Konfliktparteien erkennbar Auf der Beziehungsebene spielen sich versteckt die Wahrnehmungen in der Gef hlswelt und im Denken ab Das Eisbergmodell zeigt diese ungleiche Verteilung zwischen der Sach und der Beziehungsebene auf 1 142 Siehe http www workforlife ch konfliktmanagement 30 10 2013 1483 Kaspar 2012 S 30 14 Siehe http www soft skills com sozialkompetenz konfliktkompetenz konflikte arten php 30 10 2013 148 Siehe http www soft skills com sozialkompetenz konfliktkompetenz konflikte arten php 30 10 2013 14 Kaspar 2012 S 35 Transferarbeit Urs Zihlmann Seite 103 Lucerne University of Applied Sciences and Arts C C HOCHSCHULE LUZERN Technik amp Architektur Ziele Ziele Aufgaben Aufgaben Positionen Positionen Standpunkte Standpunkte SACHEBENE Abbildung 45 Eisbergmodell Oft sind beide Parteien der Meinung friedliebend zu sein und doch m chten sie beide den Sieg davon tragen Diese zwei Grundtendenzen widersprechen sich Entweder sollte ich mich zur cknehmen oder in die Offensive gehen und meinen Standpunkt vertreten Karl Berkel Psychologe Theologe Karl Berkel nennt f nf Konfliktverhaltensstile Frieden vs Sieg 1 9 9 9 Nachgeben gemeinsames Probleml sen 5 5 Komp
14. Lucerne University of Applied Sciences and Arts C DC HOCHSCHULE Kundenzufriedenheit Kundenzufriedenheit messen e Nutt der Kunde das Produkt erfolgreich e Kommt der Kunde mit Folgeauftr gen e Gespr ch mit Kunden vor und nach dem Projekt e R ckfrage bei Service Desk gibt es viele Reklamationen Je nachdem was ich wissen will muss die passende Frage gestellt werden Die passende Frage bzgl Kundenzufriedenheit W rden Sie dieses Projekt nochmals mit uns durchf hren W rden Sie ein weiteres Projekt mit uns machen L uft alles zu Ihrer Zufriedenheit W rden Sie uns weiterempfehlen Net Promoter Score Der Net Promoter Score NPS ist ein Index der hoch mit dem Unternehmenserfolg korreliert Wie gross ist auf einer Skala von 0 bis 10 die Chance dass Sie mich unsere Firma dieses Produkt einem Freund oder pers nlichen Bekannten weiterempfehlen w rden Promotoren Passive y Net Promoter Score Promotoren Anteil Kritiker usserst unwahrscheinlich wahrscheinlich Abbildung 56 Net Promoter Score e Die Promotoren werben unaufgefordert f r das Produkt Die Passiven sind mit dem Produkt zufrieden werben aber nicht aktiv daf r e Die Kritiker sind eher unzufrieden mit dem Produkt Das kann dazu f hren dass sie die negativen Erfahrungen mit dem Produkt auch unaufgefordert weitererz hlen Die folgenden Zusatzfragen k nnen je nach Situation gestellt werden e Welcher ist
15. desto wichtiger wird die Kreativit t bei der L sungserarbeitung Vor allem bei Entwicklungsprojekten ist die Bandbreite m glicher L sungen meist gross Kreativmethoden Es gibt jede Menge von Kreativmethoden Die beliebtesten welche auch in der Praxis sehr oft eingesetzt werden sind die folgenden drei Methoden Brainstorming Durch spontane Ideen usserung ohne ablehnende Kritik wird eine grosse Anzahl an Ideen zu einer gegebenen Problemstellung entwickelt und gesammelt Methode 635 Brainwriting Technik zur Erzeugung neuer ungew hnlicher Ideen und oder deren systematischen Weiterentwicklung in einer Gruppe Morphologischer Kasten Alternative Bestandteile eines Produktes in einer visuellen Darstellung neu kombinieren P Bewertung der L sungen Die Kernaufgaben o _Nutzwertanalysen o Zielerreichung und Risiken statt Pro und Contra o Risiko absch tzen Die Bewertung f r die richtige Wahl einer L sung sollte m glichst umfassend alle Parameter Kosten Nutzen Zeit Risiken usw mit der richtigen Gewichtung ber cksichtigen Dazu eignet sich die Nutzwertanalyse welche die St rken und Schw chen der L sung transparent macht und eine sachliche Diskussion ber Vor und Nachteile erm glicht 5 Scheuring 2013 S 171 60 Siehe http www designmethodenfinder de brainstorming s1 16 07 2013 6 Siehe http www designmethodenfinder de method 635 s1 16 07 2013 2 Siehe http www designmethodenf
16. systematischen Organisieren aller T tigkeiten im Bereich Service Management und Service Support f r Informationssysteme Einsatzbereiche 128 Siehe http www kotterinternational com our principles changesteps 14 11 2013 Transferarbeit Urs Zihlmann Seite 93 v C HOCHSCHULE LUZERN Technik amp Architektur o IT Betrieb operativer Bereich PRINCE2 PRINCE2 Projects in Controlled Environments bezeichnet ein prozessorientiertes und frei skalierbares Projektmanagementmodell welches erstmals im Jahre 1989 ver ffentlich wurde PRINCE2 kann unabh ngig von Projektart Projektgr sse Organisation und Kultur angewandt werden Einsatzbereiche o Jede Art von Projekten Transfer in die betriebliche Umgebung machen wir Wie bereits im Kapitel Projektplanung und Controlling beschrieben befasst sich meine Vertiefungsarbeit mit Scrum und dessen Einf hrung in unserer Abteilung anhand der Umsetzung eines Projekts Bis vor einem halben Jahr haben die Softwareentwickler nach einem Art 5 Phasen Modell gearbeitet wobei die Anforderungen der Stakeholder nie in Stein gemeisselt waren Mit der Zeit wurden die Projekte immer gr sser und leider auch die damit verbundenen Probleme unseres Vorgehensmodells Projekte konnten nicht mehr termingerecht abgeschlossen werden das Budget wurde berschritten und auch bei der Qualit t mussten wir Einbussen hinnehmen Aus meiner Sicht sind agile Vorgehensmodelle sehr gut f r die Sof
17. 1 6 Betrieb Dokumentation m m 1 3 1 1 1 1 Server 1 1 2 Clients 1 2 1 Server 1 2 2 Clients ScheduAll RES gt anbinden tpc Tac 1 1 Windowd 1241 12 21 1 3 2 7 2 Server R2 1 1 2 1 Physik Server Beschaffung MS Exchange eric Admin gt FH Windows 7 oder VM Screens amp Clien anbinden tpc Users 64Bit installiere bereitstellen PC leist f hi 1 1 1 2 MSSQL EE 1 3 3 en 7 3 Datenbank 1 212 RSS Feeds ei Admin gt installieren 1 1 2 2 Zi anbinden tpc Support DigitalSignage dae 5 gie DDS Client 11 19 installieren Netzwerk und 1 3 4 DigitalSignage Lieferant Strom zu Clientd Shares VENUS einrichten Watchfolder Soare i einrichten installieren H Lieferant einrichten BEE Montage 1 1 1 4 IIS Clients Screen Webserver installieren 37 Abkl mit 1 1 1 5 Opt Feuerpolizei Excel und Powerpoint installieren GR Monitoring Backup einrichten Abbildung 8 Beispiel eines Projektstrukturplans bei eMedia Das Erstellen eines Projektstrukturplans ist aufw ndiger als es auf den ersten Blick erscheinen mag Man muss sich mit dem gesamten Projekt befassen und obwohl noch viele Fragen offen sind versuchen die einzelnen Arbeitspakete zu definieren strukturieren und zu einem ersten Gesamtbild zu formen Viele Fragen kamen erst auf nachdem ich mich mit dem Projektstrukturplan und dessen Struktur befasst hatte Sp testens in diesem Moment wurde mir klar dass ich den Projektstrukturplan auch im n chsten Projekt wieder anwende
18. 118 Siehe http theses ulaval ca archimede fichiers 24937 ch04 htmi 02 10 2013 117 Wintersteiger 2013 S 25 Transferarbeit Urs Zihlmann Seite 85 Lucerne University of L C HOCHSCHULE LUZERN Technik amp Architektur Scrum Flow Im Mittelpunkt von Scrum steht das selbstorganisierte Entwicklerteam das ohne Projektleiter auskommt Um dem Team eine st rungsfreie Arbeit zu erm glichen gibt es den ScrumMaster der als Methodenfachmann daf r sorgt dass der Entwicklungsprozess nicht zerbricht Der ScrumMaster stellt auch die Schnittstelle zum Produktverantwortlichen Product Owner dar dem die Aufgabe zukommt Anforderungen zu definieren zu priorisieren und auch zu tauschen Allerdings ist in Scrum klar geregelt wann der Produktverantwortliche neue oder ge nderte Anforderungen beauftragen darf so gibt es ungest rte Entwicklungszyklen von 2 4 Wochen Sprints w hrend denen ihm untersagt wird das Entwicklerteam zu st ren W hrend eines Sprints wird der Product Owner deshalb seine Vorstellungen von der weiteren Entwicklung ins Product Backlog eintragen und so f r kommende Sprints einplanen 119 Product RO NEN aY AA RE Ke N hd a N 2 E Si Pei Product Revi ew Owner CH ef Idea 9222 DER Sprint Retrospective CH ef SEIT ES DES BASS Za Product Daily Scrum Meeting Backlog S 5 Taskboard to do in progress done User Stories Impediment Backlog Burndown Chart Var en sum ET E cru
19. Das Selected Product Backlog entsteht im Sprint Planning Meeting 1 Es enth lt die Backlog Items die das Team bis zum Ende des Sprints liefern kann Das Selected Product Backlog orientiert sich am Sprint Goal Die Aufgaben Tasks Mit Aufgaben oder Tasks bezeichnen wir alles was getan werden muss um das Ziel des Sprints zu erreichen und die geforderten Funktionalit ten zu entwickeln 124 Siehe http borisgloger com scrum scrum flow die scrum artefakte 14 10 2013 125 Schwaber amp Sutherland 2011 S 5 Transferarbeit Urs Zihlmann Seite 91 C C HOCHSCHULE LUZERN Technik amp Architektur Sprint Backlog Im Sprint Planning 2 entsteht die Liste der Aufgaben die das Team abarbeiten muss um das Sprint Goal zu erreichen Diese Liste nennen wir Sprint Backlog Sie wird t glich berarbeitet und aktualisiert Das Team f gt neue Aufgaben hinzu und hakt die abgeschlossenen Aufgaben t glich ab Das Sprint Backlog schafft einen berblick wer was gerade tut und was noch getan werden muss Der Releaseplan Der Releaseplan zeigt an in welchem Sprint welches Backlog Item vom Team geliefert werden kann Er ist kein Instrument um einem Team zu sagen was es wann zu liefern hat sondern zeigt nur an wann das entsprechende Backlog Item vom Team zu erwarten ist Somit ist er ein Informationsinstrument und kein Planungsinstrument im klassischen Sinn Das Impediment Backlog Das Impediment Backlog ist die Liste aller Blockaden
20. Feedbacks geben Grundregeln beim Feedback Gespr ch Konstruktives Feedback geben Klar trennen zwischen Wahrnehmung Gef hl und Vermutung ICH Botschaften formulieren Nur feedbacken was auch ver nderbar ist Feedback konkret und genau formulieren Bespiele angeben Aktuelle Feedbacks sind wirkungsvoller Senden Sie Feedbacks so wie Sie sie gerne entgegennehmen Keine Verallgemeinerungen Vagheiten man m sste oder Man sollte Feedback empfangen Grundregeln beim Feedback empfangen 1 Zuh ren Feedback anh ren entgegennehmen schweigen Kein Rechtfertigen keine Begr ndungen H chstens nachfragen wenn etwas nicht verstanden wurde F r das offene Feedback danken Selbst entscheiden was man beibehalten was man ver ndern oder weiter beobachten m chte Dem Feedbackgeber sagen was das Feedback bewirkt hat Siehe http www rhetorik ch Johari Johari htmi 06 07 2013 10 J ggi amp Z ger 2011 S 55 11 SRF tpc Ausbildung Feedback Regeln 2013 Transferarbeit Urs Zihlmann Seite 11 LUZERN Technik amp Architektur C Lk C HOCHSCHULE Pr sentation Eine Pr sentation ist dann berzeugend wenn Sie das was Sie dem Publikum vermitteln wollen mit Ihrer Art zusammen passt und wenn Ihre pers nliche Ausstrahlung authentisch zum Tragen kommt berzeugend wirken Sie wenn das Gesagte Ihre Worte und das Gezeigte Bilder mit Ihrer K rpersprache Ihrer Stimme und Ihrem usser
21. Inputs Entgegen meiner Erwartung waren ihnen nicht alle Risiken bewusst gewesen was eine interessante Diskussion ausl ste Dadurch kamen weitere bisher unbekannte Anforderungen und Erwartungen zum Vorschein Ich werde versuchen die Liste w hrend des Projekts aktuell zu halten und dem STEA bei jeder Gelegenheit pr sentieren 168 Zihlmann 2014 16 Siehe http www pm schluessel com downloads download_risiko bewertungstabelle xIs 18 12 2013 d 10 INNOVATIONS SCHUTZ VERTR GE BESCHAFFUNG Co 16 11 12 12 2013 12 12 2013 Andreas Kurmann Marcel A Bieri 170 Kurmann 2013 Transferarbeit Urs Zihlmann Lucerne University of Applied Sciences and Arts HOCHSCHULE LUZERN Technik amp Architektur Im ersten Unterrichtsteil bei Andreas Kurmann behandelten wir die Evaluation von Standard Software Am Beispiel eines ERP Systems haben wir die einzelnen Evaluations Themen besprochen Als Beispielprojekt haben wir ein ERP System evaluiert Im zweiten Teil 12 Dezember konnten wir das Gelernte gleich versuchen am Beispiel einer Buchhandlung anzuwenden Besonders n tzlich sind die Evaluations Vorlagen die uns Andreas Kurmann zur Verf gung gestellt hat Die Folien waren sehr strukturiert und der rote Faden durchwegs erkennbar was die Arbeit f r die Zusammenfassung nat rlich vereinfachte So habe ich gleich die Struktur aus den Folien bernommen F r jeden Prozessschritt im Eval
22. Principles 14 Principles Abbildung 39 Lean und Agile im Vergleich RUP RUP ist zwar keine agile Methode soll zum Vergleich aber trotzdem erw hnt werden damit der Unterschied zu den agilen Methoden besser sichtbar wird Ein Hauptunterschied zwischen Scrum und RUP ist dass Sie in RUP zuviel bekommen 30 Rollen 20 Aktivit ten 70 Artefakte und Sie sollen das wegnehmen was Sie nicht brauchen In Scrum bekommen Sie zuwenig und Sie sollen hinzuf gen was fehlt eXtreme Programming XP XP gibt es seit 1998 und diese Methode war fr her deutlich bekannter als Scrum Wie der Name vermuten l sst hat eXtreme Programming seinen Schwerpunkt in den Praktiken der Softwareentwicklung definiert aber auch einen Ablauf wie die folgende Grafik aufzeigt Zu den Praktiken geh ren unter anderem testgetriebene Entwicklung kontinuierliche Integration inkrementeller Entwurf r umliche N he Pair Programming kollektive Verantwortung f r den Code etc Diese Praktiken geh ren heute zum guten Ton bei der agilen Entwicklung und haben damit f r das berleben von XP gesorgt XP hatte immer einen st rkeren Fokus auf die Praktiken und weniger auf den Prozess 113 Wintersteiger 2013 S 30 114 Siehe http www infog com resource news 2010 01 kanban scrum minibook en resources KanbanAndScrum German pdf 02 10 2013 115 Wintersteiger 2013 S 23 Transferarbeit Urs Zihlmann Seite 84 C C HOCHSCHULE LUZERN Techn
23. Quality Gate Start des Software Inkrements bzw Releases inkl Testplanung Quality Gate Ende des Software Inkrements bzw Releases inkl Testplanung Zeit Abbildung 25 Prozess Schritte in einem Testprozess Am Ende eines Inkrements Quality Gate wird die Software bewertet und entschieden ob sie ausgeliefert werden kann Dieser Schritt wird in der Praxis h ufig vergessen bzw ignoriert Arten von Fehlern in der Software Gemeinsames Verst ndnis ber die Grundlage des Fehler Begriffs beim Testen von Software entwickeln Welche Konsequenzen ergeben sich f r das Software Testen aus dem Zusammenhang von Ursache und Wirkung eines Fehlers Bei jeder Art von Fehler wird zwischen Fehlerzustand und Fehlerwirkung unterschieden Der Fehlerzustand ist ein innerer Fehler engl fault und tritt aufgrund nicht korrekter Instruktionen oder Datendefinitionen z B lt statt lt auf Die Fehlerwirkung wird als usserer Fehler engl failure bezeichnet und tritt bei nicht korrektem Verhalten oder Ergebnis auf Der Fehlerzustand ist die Ursache f r die Fehlerwirkung Der Tester entdeckt in der Regel die Fehlerwirkung Transferarbeit Urs Zihlmann Seite 69 Lucerne University of Applied Sciences and Arts C C HOCHSCHULE LUZERN Technik amp Architektur Fehlermaskierung Zwei oder mehrere Fehlerzust nde Die erfolgreiche Durchf hrung eines usseren kompensieren sich so dass keine Tests ist
24. S 156 Transferarbeit Urs Zihlmann Seite 111 LUZERN Technik amp Architektur C Lk C HOCHSCHULE Risikomanagement Das Risikomanagement sollte in einem Projekt ein kontinuierlicher Prozess sein Es gen gt nicht Risiken zu Beginn eines Projekts zu identifizieren und Gegenmassnahmen festzulegen Der Projektleiter muss das Risikomanagement als eine seiner Kernaufgaben ber die gesamte Projektdauer begreifen Was ist ein Risiko Risikoarten Was gef hrdet den Fortbestand Welche Gefahren f r Mensch und Was hindert mich daran mein des Unternehmens Umwelt treten w hrend Bau Projekt erfolgreich zu machen Einsatz und Entsorgen auf Tabelle 26 Risikoarten Risiken identifizieren Um die Gefahren einsch tzen zu k nnen die zum Ausfall eines Gesch ftsprozesses f hren k nnen m ssen die Risiken die auf ihn einwirken sorgf ltig analysiert werden Um m glichst alle relevanten Risiken in die Betrachtung einzubeziehen sind ein systematisches Vorgehen und der Einsatz von Methoden und Hilfsmittel erforderlich 19 Projektbezogene Hilfsmittel Fragenkataloge Kernrisiken Liste Erfahrung aus anderen Projekten Studium hnlicher Projekte Besichtigungs und Organisationsanalyse Anforderungs und Dokumentationsanalyse Brainstorming Sitzung FMEA Fehlerm glichkeits und Einflussanalyse Tabelle 27 Risiken identifizieren Kernrisiken Risiken die im jeweiligen Fachgebiet immer auftreten k nnen egal um welch
25. Szene wie Kent Beck dazu P berblick Agile Modelle Die Modelle lassen sich am besten anhand der Anzahl der Vorgaben bzw Regeln vergleichen Je adaptiver eine Methode Framework ist desto weniger Regeln schreibt sie vor 6 0 More Adaptive RUP XP Scrum Kanban Do P Whatever More Prescriptive Abbildung 38 Prescriptive vs Adaptive Vergleich Agile und Lean Agile ist etwas das man ist und nicht etwas das man tut Viele Ideen von Lean und agiler Softwareentwicklung berlappen sich bzw erg nzen sich sehr gut So finden wir in Scrum und in Lean gleichermassen die kontinuierliche Verbesserung Kaizen die Selbstreflexion Hansei sowie den Fokus auf die Entwicklung von selbstorganisierenden Teams aus Lean XP und Scrum sind prim r als Inkarnation der agilen Philosophie zu verstehen berlappen sich aber ebenso Kanban ist als eine Inkarnation einiger weniger Ideen aus Lean zu sehen und berlappt sich ein wenig mit Scrum und den zugrunde liegenden Ideen aus Agile 109 Siehe http scrum master de Scrum Glossar Agiles Manifest 14 10 2013 110 Kniberg A Skarin 2010 111 Wintersteiger 2013 S 28 41 112 Wintersteiger 2013 S 28 30 Transferarbeit Urs Zihlmann Seite 83 C C HOCHSCHULE LUZERN Technik amp Architektur 5 Rules Agile N 5 Values 14 Principles 5 Values 13 Practices 4 Value Pairs 3 Roles 8 Roles 4 Ceremonies 12 Principles N 3 Artifacts 9 Management 2 Pillars
26. Teams haben Der kollegiale respektvolle und lockere Umgang im Team deuten ebenfalls darauf hin dass eine Scrum Einf hrung bei eMedia nicht nur Wunschdenken ist Das Ziel meiner Vertiefungsarbeit ist das Team und das Management von einem Scrum Pilotprojekt zu berzeugen und Scrum in Zukunft bei neuen Software Projekten einzusetzen Ob eine Scrum Einf hrung in anderen Abteilungen von eMedia ebenfalls sinnvoll sein k nnte m sste in einer anderen Arbeit analysiert werden Da die anderen Teams eher an Kleinprojekten mit vielen Schnittstellen zu anderen Abteilungen arbeiten eignen sich andere Vorgehensweisen vermutlich besser In der Vertiefungsarbeit habe ich 11 Gr nde aufgelistet warum Scrum f r eMedia die richtige Wahl und MediaConnector Phase Il das passende Projekt sein k nnten 1 10 11 Transferarbeit Urs Zihlmann Die Aufw nde u a f r die Systemanbindungen k nnen noch nicht im Detail spezifiziert und gesch tzt werden Fertiggestellte Funktionen definition of done k nnen bereits in der produktiven Umgebung eingef hrt werden da es sich um eine Weiterentwicklung handelt Dies soll erm glichen dass Redaktionen Sendungen noch w hrend der Phase 2 auf MediaConnector umsteigen k nnen Quick Wins Der Kunde kann w hrend den Entwicklungsphasen Priorit ten ndern In der Regel l sst sich nicht voraussagen welche Redaktionen wann migriert werden Hohe Komplexit t des Projekts erfordert mehre
27. Tier und wer eher ein Mitl ufer oder Beobachter Typ ist Ich pers nlich w rde mich wie ich auch erwartet habe als Beobachter Typ einstufen Dem Thema Lampenfieber wurde viel Zeit gewidmet Die darauffolgenden Vortr ge und Pr sentationen der Teilnehmer waren nicht nur inhaltlich interessant sondern zeigten auch dass die anderen Teilnehmer mit dem Lampenfieber genauso zu k mpfen haben Die Vortr ge wurden auf Video aufgenommen und f r mich war es wie f r den gr ssten Teil der Klasse brigens auch das erste Mal dass ich bei einem Vortrag gefilmt wurde Die Videos wurden nach dem Unterricht auf der HSLU Plattform ILIAS abgelegt so dass wir unsere Vortr ge nochmals anschauen konnten Seite 7 LUZERN Technik amp Architektur Lucerne University of Applied Sciences and Arts v DC HOCHSCHULE Kommunikation amp Pr sentation Begriff Kommunikation bezeichnet auf der menschlichen Alltagsebene den wechselseitigen Austausch von Gedanken welche durch die innere Einstellung gepr gt sind und in Sprache Mimik und K rpersprache ausgedr ckt werden F nf Axiome der Dialog Theorie nach Watzlawick 1 Man kann nicht nicht kommunizieren Man kann nicht nicht kommunizieren denn jede Kommunikation nicht nur mit Worten ist Verhalten und genauso wie man sich nicht nicht verhalten kann kann man nicht nicht kommunizieren Jede Kommunikation hat eine Sach und eine Beziehungsebene Jede Kommunikation hat einen Inh
28. frei Eine seiner Hauptaufgaben besteht darin alle am Projekt beteiligten Personen so zu schulen dass sie ihre Rolle verstehen und aus ben k nnen Die Scrum Teamumgebung Auch wenn das Scrum Team isoliert arbeitet so ist es doch in eine Umgebung eingebettet die weitere Rollen kennt Der Manager der Bereitsteller Das Management stellt die Ressourcen und die Richtlinien innerhalb einer Organisation zur Verf gung Es schafft den Rahmen in dem sich das Team der Product Owner und der ScrumMaster bewegen Oft l st das Management die vom ScrumMaster identifizierten Probleme Der Kunde der Finanzierer Der Kunde ist Anforderer des Projekts er kauft es oder hat es in Auftrag gegeben Typischerweise sind das Executive Manager in Organisationen die Softwareentwicklungen bei externen Firmen einkaufen In einem internen Projektentwicklungsteam ist der Projektverantwortliche in der Rolle des Kunden Der Anwender der Nutzer Der Anwender des Produkts ist eine wesentliche Informationsquelle f r das Scrum Team Er ist es der sp ter die usable Software benutzen wird Daher bezieht das Scrum Team den Anwender in die Produktentwicklung mit ein Beim Sprint Planning definiert er gemeinsam mit dem Product Owner die Anforderungen Sp ter wird er als Anwender mit dem Team daran arbeiten die Anwendung nutzbar zu machen 177 Meetings Ein Sprint umfasst maximal einen Zeitraum von 30 Tagen und wird durch eine Reihe von Meetings unterte
29. ge Test Guidelines Dokumentation und Schulungsunterlagen Sp tere Absicherung der erfolgten Leistungen Erreichbarkeit der Ziele berpr fen Konflikte werden ersichtlich Ziele beschreiben was mit einem System erreicht werden soll Anforderungen beschreiben was mit einem System gemacht werden soll und in welcher Qualit t dies geschehen muss Eine Anforderung wird dazu ben tigt ein oder mehrere Ziele zu erreichen bzw zu erf llen Anforderungen ermitteln Damit eine Software dem Wunsch des Kunden entspricht ist es notwendig die Anforderungen die vom Kunden an die Software gestellt werden genau zu kennen Die Aufgabe des Requirements Engineers ist es zun chst die Quellen zu identifizieren und anschliessend Ziele sowie funktionale und nichtfunktionale Anforderungen systematisch zu erheben Quellen der Anforderungen Stakeholder o Benutzer Auftraggeber Manager o Betreiber Entwickler Architekten Tester Dokumente o Gesetze Normen o Konzepte Ver ffentlichungen Kataloge Fehlermeldungen Systeme o _Vorg ngersyteme o _Umsysteme o _Konkurrenzsysteme 3 75 Fr hauf 2013 S 4 Transferarbeit Urs Zihlmann Seite 48 Lucerne University of Applied Sciences and Arts HOCHSCHULE LUZERN Technik amp Architektur C x Ein Stakeholder eines Systems ist eine Person oder Organisation die direkt oder indirekt Einfluss auf die Anforderungen des betrachteten Systems hat P S
30. http www workforlife ch konfliktmanagement 30 10 2013 152 Kaspar 2012 S 69 3 Schritt Rahmen gestalten Vorgehensweise miteinander abstimmen verlangsamten Dialog f hren Vereinbarungen treffen Positiven Abschluss finden r C HOCHSCHULE LUZERN Technik amp Architektur Scheinl sungen enthalten neue Konflikte 127 o Verzicht auf L sung Durch Vermeiden einer Konfliktl sung Irrationale L sung Magische L sung Zufall Los oder v llig unrealistische Voraussetzungen Verbindung mit Dritten Die Konfliktpartner reden nicht miteinander Unterst tzung durch Dritte Verschiebung auf neues Ziel Neues attraktives Ziel soll vom alten Zielkonflikt ablenken Schaffen eines neuen Konflikts Lenkt vom alten Konflikt ab und dispensiert die L sungssuche Dominanz Zielkonflikt wird durch Macht entschieden Beseitigung des Konfliktpartners Exilierung oder Diskriminierung Echte L sungen konsensf hig 19 o Integration Alle Elemente der Ziele sind in der L sung realisierbar Synthese Unter Modifikation sind die wesentlichen Elemente der Ziele realisierbar Kompromisse Teilweiser Verzicht auf urspr ngliche Zielelemente Kompensation Einzelne Zielelemente werden abgegolten Experte Konfliktpartner akzeptieren Autorit t eines Beraters und dessen Entscheide Trennung Die Partner trennen sich zur Verfolgung der Ziele Die 5 Antreiber Erfahrungen aus unserer Jugend mit unseren Eltern Verwandten und Bekannte
31. jedem Punkt einige Gedanken notiert werden was gut geklappt hat und was verbessert werden k nnte Verst ndlichkeit Klar deutlich und einfach Theorie Nur das Notwendige Fachjargon So wenig wie m glich keine Angeberei mit Fachbegriffen Interesse Wo steht der Auszubildende Was braucht er Hat er verstanden Loyalit t Gegen ber Unternehmen sich Rolle als Ausbildner bewusst sein Vorbild Enthusiasmus vermitteln gut vorbereitet sein eigene Fehler Nichtwissen eingestehen k nnen Selbstverst ndnis Ich will andere bef higen Lernziele setzen Teilnehmende sollen nach dem Kurs dieses und jenes wissen Tabelle 8 Superuser Regeln Transferarbeit Urs Zihlmann Seite 16 C C HOCHSCHULE LUZERN Technik amp Architektur Checkliste f r die Gestaltung von Kursen Diese Liste hilft beim Planen eines Kurses H lt man sich an diese Liste so wird ein Kurs gestaltet der nicht nur einen erkennbaren roten Faden aufweist sondern auch sauber strukturiert und passend f r die Teilnehmer aufbereitet ist Zielgruppe Leitung Lernziel Inhalte Methoden Rahmenbedingungen Durchf hrung Zeitplan amp Ablauf Feedback Nachbearbeitung Do Oo oO Do oO E m m m Checkliste f r den Trainer Die Anforderungen an einen guten Trainer sind gross Diese Liste sollte ein Trainer versuchen zu verinnerlichen so schwierig dies auch sein mag Wenn die Teilnehmer w hrend des Trainings mit einer Aufgabe besch f
32. keine besonders grosse Achtung geschenkt Auch eine Stakeholder Analyse wie wir sie im Unterricht ge bt haben wurde bisher noch nie gemacht Die Stakeholder werden beim Erreichen der Meilensteine ber das Projekt informiert allerdings werden dazu keine speziellen Analysen erstellt und gepflegt Umsetzungsm glichkeiten im Betrieb Start Brainstorming Von der Wichtigkeit des Start Brainstormings wurde ich sp testens bei den bungen im Unterricht berzeugt Zu welchen Themen ein Start Brainstorming gemacht werden soll h ngt unter anderem auch vom Projekt ab Unabh ngig vom Projekt sollten Start Brainstormings aber mindestens zu folgenden Themen gemacht werden e Maske 23 e Das0 Gebot e Erfolgsfaktoren e Visionen e Fragen fehlende Informationen Selbstverst ndlich m ssen die Informationen aus den Start Brainstormings mit ins Projekt einfliessen Dies geh rt zu den Aufgaben eines Projektleiters Transferarbeit Urs Zihlmann Seite 31 C C HOCHSCHULE LUZERN Technik amp Architektur Projektstrukturplan und Arbeitspakete Nach diesem Unterrichtsblock wurde ich mit dem Projekt Digital Signage konfrontiert und dies war gleich eine Gelegenheit das Gelernte in die Praxis umzusetzen Bevor ich zum Definieren und Ausarbeiten der Arbeitspakete kam wurde das Projekt aus Kostengr nden leider gestoppt 1 Digital Signage Bebe 1 3 System 1 4 1 5 Design P 1 7 Schulung eier EES Anbindungen Konfiguration Templates
33. keine Routine Transferarbeit Urs Zihlmann Seite 33 v C HOCHSCHULE LUZERN Technik amp Architektur Wenn man als Projektleiter ausgew hlt wurde sollten zuerst einmal die Fakten durchgegangen und berpr ft werden ob die Ranmenbedingungen stimmen Diese Liste hilft bei der Entscheidung ob das Projekt angenommen oder abgelehnt werden soll Lehnen Sie das Projekt ap e wenn ihr Arbeitgeber und Sie das Projektziel nicht so wiedergeben k nnen dass ein Dritter jeweils dasselbe darunter versteht wenn der Auftraggeber und andere Stakeholder nicht ein gewisses Mass an Grundvertrauen aufbringen wenn Sie kein Budget haben ber das Sie relativ frei verf gen k nnen wenn Sie kein Projektteam haben oder Gr sse und ungef hre Zusammensetzung weder kennen noch selbst bestimmen k nnen wenn Ihnen oder Ihrem Auftraggeber nicht klar ist wann das Projekt beginnen und wann es enden soll wenn Sie Gr sse und Komplexit t des Projekts berhaupt nicht absch tzen k nnen Projektorga Die Projektorganisation beinhaltet abgeleitet vom Grundbegriff Organisation die Struktur Gestaltung Regeln und Hilfsmittel f r die systematische Durchf hrung von Projekten P Tipps f r eine erfolgreiche Projektorganisation e Seien Sie bei ewigen Neinsagern hartn ckig Versuchen Sie das Eis zu brechen Vielleicht haben Sie ein gemeinsames Hobby oder k nnen Ihren Humor einsetzen Je besser ihr Einf hlungsverm gen i
34. llt 1 F r n chste Version geplant 2 Anpassung oder work around erforderlich 3 Erf llt die Anforderung weitgehend 4 Erf llt die Anforderung vollumf nglich Betriebssystem Spielt keine Rolle L uft nur auf Windows L uft auf Windows und Mac L uft auf Windows Mac und Linux L uft unabh ngig vom Betriebssystem Randbedingungen festlegen e Randbedingungen mit Einfluss auf Anforderungen sind bekannt e Fakten ermitteln die nicht ge ndert werden sollten e Einfluss der Fakten auf den Anforderungskatalog erfassen und auswerten e Gegebenenfalls Anforderungen anpassen oder neue hinzuf gen e Liste der Randbedingungen Die Randbedingungen sollten nicht zu eng definiert werden um den L sungsraum nicht zu stark einzuschr nken Pflichtenheft erstellen e Gewichteter Kriterienkatalog und Pflichtenheft e Gewichteter Kriterienkatalog erstellen o Granularit t von grob bis fein und Priorit t o Wann ist eine Anforderung erf llt Erf llungsgrad Pflichtenheft erstellen e Review des Pflichtenheftes durch die Steuerungsgruppe Phase 2 Papier Evaluation Phase Il Papier Evaluation L sungen Lieferanten Hersteller Abbildung 52 Phase Il Transferarbeit Urs Zihlmann Seite 121 LUZERN Technik amp Architektur C p C HOCHSCHULE Markt bersicht verschaffen e Informationen ber grunds tzlich in Frage kommende Softwarepakete zusammenstellen Sinnvolle Vorauswahl treffen Long List
35. nicht hinreichend f r eine fehlerfreie Fehlerwirkung auftritt Software ohne innere Fehler Fehlhandlung Fehlerhafte menschliche Bedienung Die Durchf hrung von funktionalen Tests ist der Software die zu einem inneren nicht hinreichend f r die Beurteilung des Fehler f hrt Reifegrads einer Software Ausfall Versagen Aussetzten der Ausf hrung einer festgelegten Aufgabe Abweichung Ein definierter Sollwert Ergebnis oder Mangel Verhalten wird nicht angemessen oder nur teilweise erf llt Tabelle 18 Arten von Fehlern Struktureller Test White Box Spezifikation Test Software Kundenanforderung Abnahmetest Funktionaler amp nicht Softwareanforderungen funktionaler Test Software Integrationstest Software Quellcode Abbildung 26 Software Modultest im V Modell Software Architektur Beim Software Modultest wird jedes Modul isoliert betrachtet und vom Entwickler getestet Test des Quellcodes mit der gr ssten Detaillierung Das Abgrenzen der Module Scope wird vom Entwickler oder im Team gemacht In der Regel besteht ein Modul aus einem Set von Klassen oder Methoden Welche Elemente des Software Designs werden gepr ft o Struktur und Kontrollfluss Datenfluss und Datenverarbeitung im Modul O o Ausnahmebehandlungen Fehlersituationen o Performance Transferarbeit Urs Zihlmann Seite 70 C C HOCHSCHULE LUZERN Technik amp Architektur C0 C1 Abdeckung Abdeckungskriterien f r den Quel
36. oder gewohnte Abl ufe nicht aufgeben wollen Tabelle 9 Rollen bersicht 37 Scheuring 2013 S 73 38 Scheuring 2013 S 75 Transferarbeit Urs Zihlmann Seite 26 C C HOCHSCHULE LUZERN Technik amp Architektur Verantwortung und Befugnisse Wer ist f r das Erreichen der Projektziele verantwortlich Bei dieser Frage gehen die Meinungen der Projektmanagement Experten auseinander W hrend Roland Haas die Meinung vertritt dass der Projektleiter f r die Zielerreichung nicht verantwortlich sei schreibt Heinz Scheuring diese Verantwortung dem Projektleiter zu Einig sind sie sich hingegen bei den Projektleiter Befugnissen und darin dass der Projektleiter bei Problemen und Abweichungen die bergeordneten Instanzen umgehend zu informieren und geeignete Massnahmen vorzuschlagen hat Zu den Projektleiter Befugnissen geh ren o Informationsrecht Mitspracherecht F hrungskompetenzen innerhalb der Projektorganisation Auftragserteilung und erf llungs berpr fung Fristgerechte Entscheide erwirken Einspruchsrecht Anforderungen an Projektleiter Den perfekten Projektleiter gibt es nicht Die Anforderungen und Aufgaben des Projektleiters sind extrem vielf ltig und variieren je nach Unternehmen und Projekt CIO com hat langj hrige und erfolgreiche Projektleiter innen und Vorgesetzte befragt was die sieben wichtigsten F higkeiten von IT Projektleitern sind Die Resultate der Umfrage wurden im Januar 2013
37. oder in kleineren Teams umsetzen befassen wir uns vor allem mit dem WIE und selten bzw zu wenig mit dem WAS Die Folge ist dass wir zwar schnell L sungen erarbeiten danach aber oft wieder ein paar Schritte zur ck gehen m ssen bis die L sung den Vorstellungen des Kunden entspricht Bei den meisten Projekten handelt es sich um interne Projekte und so geh rt das Zusammenstellen der Projektorganisation und teams das Definieren der Projektrollen und der Stakeholder zu den einfacheren Aufgaben in einem Projekt Grunds tzlich schaut man dass Leute im Team sind e mit denen bereits Projekte erfolgreich umgesetzt wurden 4 Scheuring 2013 S 85 48 Scheuring 2013 S 84 Transferarbeit Urs Zihlmann Seite 30 C C HOCHSCHULE LUZERN Technik amp Architektur e zu denen man einen guten Draht hat e die freie Ressourcen haben und e motiviert sind Wenn diese Punkte alle erf llt sind stehen die Zeichen gut dass die Zusammenarbeit im Projektteam erfolgreich wird und die Ziele erreicht werden Je weniger Punkte zutreffen desto schwieriger wird das Projekt und umso mehr Zeit wird ben tigt das Team in die Performing Phase zu bringen hnlich verh lt es sich mit den Stakeholdern Je weniger Bremser dabei sind desto schneller werden Ziele erreicht Nach einigen Projekten weiss man in der Regel welche Stakeholder sich f r ein Projekt eignen In meinen bisherigen Projekten wurde dem Stakeholder Management
38. und abgeleiteten Tests als Basis f r e Abkl rung und Analyse bei 3rd Party Referenzsystem e Diskussionspunkte bei Produktpr sentation Demo Evaluationsbericht erstellen e Entscheid ber Kauf und Einf hrung f llen e Testergebnisse der getesteten Softwarepakete zusammenfassen e Hauptkritikpunkte erfassen e Empfehlung an den Auftraggeber formulieren e Entscheid ber Kauf und Einf hrung durch Auftraggeber Gesch ftsleitung abgesegnet Software beschaffen Mit der Beschaffung der Software ist der Evaluationsprozess beendet Transferarbeit Urs Zihlmann Seite 124 LUZERN Technik amp Architektur C p C HOCHSCHULE Juristische Aspekte Das folgende Modell zeigt die vier Phasen und Tools welche jeweils angewendet werden Grunds tzlich geht es darum dass die Wunschvorstellung der Realit t entsprechen sollte Wie sollte die Realit t aussehen Tool 1 Wer will was von wem woraus _Awill Geld von B B hat Forderungen an A Tool 2 Haftpflicht besteht bei Schaden Widerrechtlichkeit Vertragsverletzung Ad quater Kausalzusammenhang Verschuldung Tool 3 An Beweislast denken Klare Vertr ge Vertragsanpassung Ab Best tigungsschreiben Tool 4 Insolvenz Risiko Bewusstsein Vertragspartner pr fen Sicherheiten verlangen Vorauszahlung Bankgarantie etc Risiko begrenzen Teillieferungen Zwischenrechnung etc
39. und haben dieses im Detail ausgearbeitet Danach pr sentierten alle Gruppen Ihre Projekte und bekamen von den anderen Gruppen Feedback was allenfalls noch verbessert werden k nnte Die Start Brainstormings haben wir mit den gleichen Gruppen und dem gleichen Projekt gemacht wie bei Roland Haas Dass es effektiver ist einzelne Brainstormings zu verschiedenen Themen zu machen als ein Brainstorming zu allen Themen war f r mich neu und ich bin seit der praktischen bung von dieser Vorgehensweise voll berzeugt insbesondere vom 0 Gebot und der Maske 23 Im n chsten Thema Projektplanung und risiken haben wir die verschiedenen Planungsmethoden besprochen und diskutiert Ausserdem besch ftigten wir uns mit dem Projekt Controlling und dessen Planungsphasen Interessant war auch die Frage wann ein Projektleiter sein Projekt im Griff hat und wie ein Projektleiter mit Risiken und Chancen umgehen soll Im f nften Block ging es um die Aufgaben und Rollen eines Projektleiters die mir bereits gr sstenteils bekannt waren Eine spannende Frage ist wer f r die Zielerreichung verantwortlich ist Roland Haas vertritt die Meinung dass die Verantwortung beim Auftraggeber liege Diesen Punkt werde ich beim n chsten Projekt mit meinem Auftraggeber besprechen Als letztes Thema behandelten wir die Projektorganisation und Stakeholder In unserem Betrieb arbeiten wir haupts chlich in einer niederkar tigen Projektorganisation wo d
40. von extern o berpr fung der von On Air Design und On Air Promotion geforderten Workflows o berpr fung der Migration der Kinderwelt Zambo Produktionsumgebung o Performance Tests Vergleich zu Avid und Final Cut Server Aufgrund der Ergebnisse soll ber den Einsatz bei den genannten Produktionsinseln entschieden werden k nnen Zudem sollen mit den gewonnenen Erkenntnissen auch Aussagen zu einem allf lligen Einsatz als 2 Produktionssystem nebst SONAPS im Bereich Dokumentation Unterhaltung und Kultur BN3 gemacht werden k nnen Die erste Planung und Bewertung Die Planung am Ende der Projektvorbereitung verfolgt zwei Zwecke 1 eine erste bersicht ber das gesamte Projekt Vorgehen Beteiligte Termine Aufw nde Kosten und Nutzen sowie Risiken Daraus folgend der Entscheid ob das Projekt berhaupt weiterverfolgt werden soll 2 Detailplanung des Projekts Projektauftrag Interessant zum Thema Projektauftrag ist die Sichtweise von Matthias Geirhos H ten Sie sich davor den Projektauftrag zu bertreiben Wer noch vor der Projektplanung die Projektphasen benennen kann der ist entweder ein Genie ein Prophet oder ein Scharlatan Es ist nicht das Ziel des Projektauftrags die Planung vorwegzunehmen sondern die Planung darauf zu begr nden Zum Projektauftrag geh ren die folgenden Angaben o Projektkategorie Gesetzliche Rahmenbedingungen Ersatzinvestitionen Kundenbed rfnis Kosteneinsparung Ertragsste
41. wahrnehmen und akzeptieren Gef hle zulassen Dieser Test kann online ausgef llt werden 17 Transfer in die betriebliche Umgebung Bei der Abteilung eMedia arbeiten zu d rfen ist ein Privileg Zum einen liegt das an den spannenden Projekten zum anderen aber auch am tollen Team eMedia besteht aus 15 MitarbeiterInnen die wiederum in drei Bereiche Grafiksystem vizrt Softwareentwicklung Solutions unterteilt sind Obwohl oder vielleicht weil wir 15 gr sstenteils ganz verschiedene Charaktere sind funktioniert die Zusammenarbeit sehr gut Genau so gut ist auch die Stimmung im Team In den letzten Jahren kamen durchschnittlich zwei neue Mitarbeiter pro Jahr ins Team und bisher konnten sich alle sehr schnell integrieren Nach dem 4 Phasen Modell von Tuckman schaffen es eMedia bzw die einzelnen Abteilungen jeweils in schneller Zeit in die Performing Phase Das gr sser werden hat aber auch seine Nachteile Von den 15 Mitarbeitern weiss ich vermutlich knapp von der H lfte an was sie gerade arbeiten wie es um ihre Motivation steht wo sie in den Ferien 156 Siehe http www lutzpickhardt com index cfm pagelD 83 12 11 2013 C C HOCHSCHULE LUZERN Technik amp Architektur waren oder was sie im Moment besch ftigt Da ich kein Teamleiter bin sehe ich es auch nicht als meine Pflicht an f r das Wohlergehen der Mitarbeiter zu sorgen Allerdings bin ich ein Mensch der in der Regel Stimmungsschwankungen und sonstige
42. zuzuordnen Dies ist mir erst gelungen als ich f r die Transferarbeit den ganzen Foliensatz nochmals durchgearbeitet und strukturiert habe Auch wenn die Unterlagen nicht meinen Erwartungen entsprachen so empfand ich den Unterricht als sehr interessant und informativ Insbesondere die Themen rund um die Anforderungen haben mich interessiert und daher werde ich den Fokus dieses Kapitels vor allem darauf legen Zweck und Inhalt Ein professionelles Requirements Engineering stellt sicher dass erstellte L sungen und Produkte den mit den verschiedenen Stakeholdern vereinbarten Anforderungen entsprechen Requirements Engineering umfasst alle T tigkeiten zur o Erhebung Dokumentation in Prosa oder mit Hilfe von Modellen O o Pr fung auf Vollst ndigkeit Korrektheit Konsistenz Eindeutigkeit Testbarkeit etc o Verwaltung Ver nderung von Anforderungen in den Projektablauf einbringen etc von Anforderungen 7i Ott S 1 Transferarbeit Urs Zihlmann Seite 45 C C HOCHSCHULE LUZERN Technik amp Architektur Warum IT Projekte scheitern Mangelhaftes Requirements Engineering geh rt noch immer zu den Hauptursachen f r das Scheitern von IT Projekten o 1 3 aller unternehmensweiten Softwareprojekte werden fr hzeitig abgebrochen 1 2 aller Projekte kosten doppelt bis dreifach so viel wie veranschlagt 2 3 aller IT Projekte erf llen die Erwartungen nicht 2 3 berschreiten das finanzielle Budget 3 4 ber
43. zwischenmenschliche Probleme schnell wahrnimmt und ich sehe dass bei mehr als 10 Personen im Team dies nicht mehr so einfach m glich ist Dank der offenen Art und Weise wie wir unter und miteinander umgehen werden Konflikte m glichst fr h angesprochen und gekl rt so dass es zumindest nach meinem Wissen noch zu keinen Eskalationen kam Die Mitarbeiter von tpc bekamen vor einem Jahr das Buch Entdecken Sie Ihre St rken jetzt geschenkt Den Fragebogen zur Erstellung eines pers nlichen Profils nach dem Gallup Prinzip konnte jeder Mitarbeiter online ausf llen Das Ziel von tpc ist dass Vorgesetzte besser auf Mitarbeiter und deren St rken eingehen k nnen Ich war von dem Gallup Test begeistert und sehe in ihm eine gute Erg nzung zum Belbin Test den wir vor diesem Unterrichtsblock ausgef llt hatten Die letzte Personalumfrage Dezember 2013 bei eMedia zeigte dass auf einer Skala von 1 bis 5 die 12 Fragen im Schnitt folgendermassen bewertet wurden o 4 83 Sind meine Kollegen bestrebt Arbeit von hoher Qualit t zu leisten o 4 50 Habe ich die Materialien und Arbeitsmittel um meine Arbeit richtig zu machen o 4 33 Interessiert sich mein e Vorgesetzte r oder eine andere Person bei der Arbeit f r mich als Mensch 4 25 Weiss ich was bei der Arbeit von mir erwartet wird 4 25 Hatte ich bei der Arbeit Gelegenheit Neues zu lernen und mich weiter zu entwickeln 4 17 Habe ich den Eindruck dass bei der Arbeit meine Meinungen und
44. 0 C C HOCHSCHULE LUZERN Technik amp Architektur Chancen in Konflikten UNS fehlt es an einer positiv besetzten Streitkultur die den Konflikt nicht meidet sondern nutzt Dr Reinhard Sprenger Das chinesische Zeichen f r Krise bedeutet gleichzeitig Chance und bringt damit neben den negativen auch die erw hnten positiven Aspekte von Konflikten zum Ausdruck Das scheinbare Fehlen von Konflikten ist ein Symptom daf r dass sich eine Organisation oder eine Gruppe nicht weiterentwickelt nicht ver ndert nicht anpasst und somit keine Fortschritte macht oder anders formuliert Kein Konflikt ist auch ein Konflikt Zw lf Iohnende Gr nde einen Konflikt einzugehen Konflikte sch rfen das Problembewusstsein Konflikte st rken den Willen zur Ver nderung Konflikte erzeugen Druck Probleme aktiv anzugehen Konflikte vertiefen zwischenmenschliche Beziehungen Konflikte festigen den Zusammenhalt Konflikte gestalten das Leben interessanter Konflikte bewirken die Vertiefung von F higkeiten und Kenntnissen Konflikte f rdern Kreativit t Im Konflikt lernen wir uns und andere besser kennen 10 Konflikte f hren zu besseren Entscheidungen 11 Konflikte f rdern die Pers nlichkeitsentwicklung 12 Konflikte k nnen Spass machen 14 Kaspar 2012 S 64 14 Kaspar 2012 S 9 10 Transferarbeit Urs Zihlmann Seite 101 pc Konfliktarten Lucerne University of Applied Sciences and Arts HOCHSCHULE LUZERN Tech
45. 8 Siehe http www designmethodenfinder de brainstorming s1 16 07 2013 19 Scheuring 2013 S 51 Transferarbeit Urs Zihlmann Seite 20 C C HOCHSCHULE LUZERN Technik amp Architektur Den Auftrag hinterfragen die Maske 23 Die Maske 23 hat den Namen aus einem Beispiel f r diese Methode bernommen Sie steht f r die Haltung bei Projektbeginn schlicht alles inklusive nichts zuzulassen Gelebtes Maske 23 Denken hat auf das Resultat und den Erfolg des Projekts in vielen F llen die mit Abstand gr ssten Auswirkungen berhaupt Denken in anderen Dimensionen macht auch erheblichen Spass Gr nde dieses Brainstorming nicht durchzuf hren gibt es keine Das 0 Gebot Hier wird konsequent nach positiven und negativen Erfahrungen und Knowhow nach Projekten und Personen gesucht die f r das Projekt n tzlich sein k nnen Die Praxis zeigt dass immer wieder naheliegende Quellen bersehen oder ignoriert werden die mit einem Minimum an Aufwand sehr wertvolle Impulse liefern zus tzlichen Nutzen generieren vor gravierenden Fehlern bewahren oder gar zur direkten bernahme von L sungen f hren k nnen Weitere Themen Nebst den beiden Themen Maske 23 und Das 0 Gebot sollte das Start Brainstorming weitere Themen abdecken Je nach Projekt kann auch das eine oder andere Thema weggelassen oder ein anderes dazugenommen werden Zu viele Themen k nnen die Teilnehmer auch demotivieren und erm den Daher
46. Couto danilo couto gmx ch Zorica Dimitrova zorica dimitrova lonza com Reto Eggenschwiler retoeggenschwiler opacc ch Roland F hndrich rof team ch Transferarbeit Urs Zihlmann Thorsten Fritsch fritsch_germany gmx net Claudio Ganassi claudio ganassi ew luzern ch Maurizio Giunca maurizio giunca triemli zuerich ch Alejandro Gualtieri info beonsoft it Raul Guirao raul guirao fides ch Beat Hinnen beat hinnen gia ch Tino Karlen tino karlen hotmail com Marco Maurizi marco maurizi swisscom com Lucerne University of Applied Sciences and Arts HOCHSCHULE LUZERN Technik amp Architektur Marco Meier marco_meier edwards com Christoph Sch fer christoph schaefer sbb ch Patrick Schmid ps grp ing ch Reto Steck reto steck drwaguenther ch Roman Widmer roman widmer assaabloy ch Ivan Wyssen ivan wyssen hslu ch Urs Zihlmann urs zihlmann tpcag ch Seite 137
47. Fehlersuche reduziert die Kosten und verringert die Fehlermultiplikation in anschliessenden Entwicklungsphasen Software Fehler in Abnahme und Betrieb verursachen die h chsten Kosten und sind mindestens durch einen vollst ndigen funktionalen und nichtfunktionalen Test zu reduzieren Review als Verifikationsmethode Ziel Darstellen der verschiedenen Typen von Reviews deren Anwendbarkeit und Vorgehensweise Kernfrage Welche Typen von Reviews sollten wir f r unsere Arbeitsprodukte verwenden Mindestqualit t Bevor das Arbeitsprodukt zum Review gegeben wird muss eine Mindestqualit t eingehalten werden Diese Mindestqualit t kann beispielsweise in Form einer Checkliste definiert werden und ist die Grundlage f r ein effizientes Review Themen welche in der Mindestqualit t Dokumentation enthalten sein sollten Anforderungs Architektur und Designspezifikationen Programmcode Testspezifikationen auf den einzelnen Testebenen Qualit tssicherungsplan Testkonzept Testplan Benutzerhandbuch Transferarbeit Urs Zihlmann Seite 61 C C HOCHSCHULE LUZERN Technik amp Architektur Review Typen Review Typen Formale Typen Abbildung 19 Review Typen Informelle Typen Informelles Review Walkthrough Prinzipien aller Review Typen o Verfahren pers nliche Analyse Pr fung Begutachtung Ziel Identifikation von Fehlern Inkosistenzen und Unvollst ndigkeiten Teilnehmer kleine Gruppen von Spezialisten mit defin
48. HSCHULE LUZERN Technik amp Architektur Diese acht Schritte zum Ver nderungserfolg empfiehlt Kotter 179 1 Bewusstsein f r die Dringlichkeit schaffen Verantwortliche mit Ver nderungsbereitschaft gewinnen und zusammenbringen Die Zukunftsvision ausformulieren und eine Strategie entwickeln wie Sie dort hinkommen Die Zukunftsvision bekannt machen Handeln im Sinne der neuen Vision und der Ziele erm glichen Kurzfristige Erfolge planen und gezielt herbeif hren Erreichte Verbesserungen systematisch weiter ausbauen Das Neue fest verankern berblick von Vorgehensmodellen in der IT SE ist ein interdisziplin rer Ansatz um komplexe technische Systeme in grossen Projekten zu entwickeln und zu realisieren Einsatzbereiche o Grosse Projekte o komplexe Systeme o Neuentwicklungen in der Industrie Das IT Projektf hrungsmodell der Schweizer Bundesbeh rden seit 1970 Offener Standard zur F hrung und Abwicklung von Informatikprojekten Einsatzbereiche o Projektf hrungsinstrument der Bundesverwaltung o Verbindlich f r alle Informatikprojekte des Bundes CobifT ist ein international anerkanntes Framework zur Kontrolle und Steuerung der IT CobiT schreibt 34 Prozesse in 4 Gruppen Planung Entwicklung Betrieb Monitoring vor Einsatzbereiche o Compliance Projekte Richtlinie Nachweis o Medizintechnik Flugzeugindustrie ITIL Information Technology Infrastructure Library ist eine Sammlung von Best Practice Methoden zum
49. KLASSENLISTE 137 Transferarbeit Urs Zihlmann Seite 5 C C HOCHSCHULE LUZERN Technik amp Architektur MANAGEMENT SUMMARY Diese Transferarbeit sehe ich als eine Zusammenfassung des Unterrichtsstoffes Ich habe ganz bewusst zus tzliche Quellen ber cksichtigt damit ich diese Arbeit auch als Nachschlagewerk verwenden kann Ein weiteres Ziel dieser Arbeit war die optimale Vorbereitung f r die Abschlusspr fung des CAS Ich habe jeweils gleich nach dem Unterrichtsblock mit dem Zusammenfassen des Unterrichtsstoffes begonnen und f r die eigentliche Vorbereitung der Pr fung nur noch diese Arbeit verwendet Dadurch wurde die Arbeit zwar deutlich umfangreicher und dicker als ich beabsichtigt habe daf r beinhaltet sie alle relevanten Unterrichtsinhalte Jedes Kapitel beginnt mit einem R ckblick auf den Unterricht mit Informationen zum Unterrichtsinhalt wie ich ihn erlebt habe und wo es allenfalls Verbesserungspotential g be Danach folgt die eigentliche Zusammenfassung des Unterrichtsstoffes und zum Schluss jedes Kapitels beschreibe ich den Transfer in den Betrieb wie wir es heute machen und wo es Optimierungsbedarf gibt Von den Unterrichtsmodulen war ich gr sstenteils begeistert Die Dozenten kamen fast ausschliesslich aus der Praxis und man merkte dass Ihnen das Unterrichten und Vermitteln ihres Wissen Freude bereitet Grunds tzlich h tte ich mir bei den fachspezifischen Unterrichtsmodulen zur Informatik mehr Informationen zu agi
50. LE LUZERN Technik amp Architektur e bergang in n chste Phase testen kaufen und einf hren e Oder Abbruch der Beschaffung weil keine geeigneten und bezahlbaren Kandidaten gefunden wurden e Der Auftraggeber hat das Vorgehen genehmigt Hier kann der Entscheid f r die Entwicklung von Individualsoftware fallen Phase III gilt nicht f r diesen Fall Phase 3 Testen amp Use Case Evalutation Phase Ill Testen kaufen installieren und einf hren Evaluationsbericht Entscheid ber Kauf Einf hrung oder neue Iteration Abbildung 53 Phase Ill Art der Hands On Evaluation e Entscheid ber die Art der Hands On Evaluation e Abkl ren welche Evaluationsart f r das jeweilige Paket m glich ist o Evaluation auf eigenem Testsystem o Evaluation extern in Auftrag geben o 3rd Party Evaluation o Produktpr sentation e Je nach Budget Zeitrahmen und personellen Ressourcen entscheiden e Entscheid durch Auftraggeber abgesegnet Anwendungsf lle zusammenstellen e _Anwendungsf lle f r die Hands On Evaluation definieren e _Anwendungsf lle abkl ren o Typische h ufige o Kritische ben tigte Ressourcen Business Impact e Daraus Testf lle generieren e Liste von Anwendungsf llen mit Testbetrieb Transferarbeit Urs Zihlmann Seite 123 LUZERN Technik amp Architektur C p C HOCHSCHULE Evaluation durchf hren Sollte die Implementation nicht auf dem Testsystem erfolgen dienen die Use Cases
51. LUZERN Technik amp Architektur Lucerne University of Applied Sciences and Arts v DC HOCHSCHULE Projektmanagement Informatik Autor Urs Zihlmann Zihlmattweg 6005 Luzern Lehrgang CAS iPM Informatik Projektmanagement Datum 31 01 2014 C C HOCHSCHULE LUZERN Technik amp Architektur INHALTSVERZEICHNIS MANAGEMENT SUMMARY 6 1 KOMMUNIKATION 7 KOMMUNIKATION amp PR SENTATION 8 Begriff 8 Sach und Beziehungsebene 8 Grundhaltung 9 Fragetechnik 9 Aktives Zuh ren 10 Tods nden 10 FEEDBACK GESPR CH 0000 11 Der Zweck von Feedback 11 Feedbacks geben 11 Feedback empfangen 11 PR SENTATION 22 12 berzeugen 12 Vollst ndige Information 12 Rhetorische Gestaltungsmittel 12 TRANSFER IN DIE BETRIEBLICHE UMGEBUNG l 13 Wie machen wir es heute 13 Umsetzungsm glichkeiten im Betrieb 16 2 PROJEKTSTART UND GESTALTUNGSRAHMEN 18 PROJEKTVORBEREITUNG 19 Herausforderung Projektstart 19 Die Idee Ausgangspunkt f r das Projekt 19 Phase 0 19 Start Brainstorming 20 Kl rungsprozess mit dem Auftraggeber 21 Projektdefinition und erste Zielformulierung 21 Die erste Planung und Bewertung 22 Projektauftrag 22 PROJEKTSTRUKTURIERUNG 23 Projektstrukturplan 23 Arbeitspakete 24 PROJEKTORGANISATON 24 Team Struktur 24 Projektorganisation 25 Rollen im Projekt definieren 26 Verantwortung und Befugnisse 27 Anforderungen an Projektleiter 27 Stakeholder 28 TRANSFER IN DIE BETRIEBLICHE UMGEBUNG 30 Wie machen wir es heute 30 Umsetzungsm glic
52. N Entspricht die Realit t der gew nschten Realit t A l l l l l l l l l l I l l l l l l l I l l l l l l l l l l l l I l l I l I l l Abbildung 54 Die vier Tools nach Marcel Bieri Transferarbeit Urs Zihlmann Seite 125 C C HOCHSCHULE LUZERN Technik amp Architektur Transfer in die betriebliche Umgebung Wie machen wir es heute Evaluation In den vergangenen Jahren wurden einige Systeme angeschafft die sich trotz sorgf ltiger Evaluation nicht bew hrt haben Deshalb f hren wir vermehrt Proof of Concepts durch Das bedeutet dass der Lieferant oder der Schweizer Vertreter uns ein System zur Verf gung stellt welches wir ber eine gewisse Zeitdauer testen d rfen Im Dezember 2013 habe ich die Projektleitung f r einen solchen PoC bernommen bei dem berpr ft werden soll ob Adobe Anywhere bestehende Editing Systeme abl sen k nnte Die Firma Dr W A G nther stellt uns f r drei Monate ein komplettes und vorkonfiguriertes System ins Haus In diesen drei Monaten versuchen wir unsere Workflows abzubilden die Performance zu testen und Schwachstellen ausfindig zu machen Aktuell laufen bei tpc vier solche Proof of Concepts Diese Art von Evaluation hat sich bew hrt da die Schwachstellen beim Testen schnell ersichtlich werden Bei kleineren Systemen verl uft die Evaluation in hnlichen Schritten wie wir es im Unterricht gelernt haben Besonders beliebt sind i
53. OCHSCHULE LUZERN Technik amp Architektur W Gregorc K L Weiner Claim Management Ein Leitfaden f r Projektmanager und Projektteam Publicis Erlangen 2005 Matthias Geirhos IT Projektmanagement Galileo Computing 1 Auflage 2011 Roland Haas Projektstart und Gestaltungsrahmen 2013 Roland Haas Il Gemeinsames Projektverst ndnis 2013 Roland Haas Ill Projektabschluss amp Lessons Learned 2013 Martin Iseli Industriedesign als Probleml sungsprozess 2013 Susanne J ggi und Rita Maria Z ger Kommunikation und Information Leadership Basiskompetenz compendio Bildungsmedien 3 Auflage 2011 Gabriele Kaspar und Compendio Autorenteam Konfliktmanagement compendio Bildungsmedien 2 Auflage 2012 Gabriele Kaspar Il Handout Teamrollen 2013 Gabriele Kaspar Ill Kommunikation und Pr sentation 2013 H Kniberg M Skarin Kanban and Scrum making the most of both 2010 Sven Koos Software Qualit t und Konfigurationsmanagement bbv Software Services AG 2013 d Andreas Kurmann Evaluation von Standard Software November 2013 Roman Lobsiger Software Entwicklung Vorgehensmodelle amp Change Management 2013 Bernd L bach Industrial Design Grundlagen der Industrieproduktgestaltung 1976 Devamani Ott Requirements Engineering Barometer FHS St Gallen Klaus Pohl Basiswissen Requirements Engineering 2012 Chris Rupp Requirements Engineering dpunkt verlag 3 Auflage 2012 Daniel Schal
54. RN Technik amp Architektur sich gut zu organisieren und n tzliche Feedbackmechanismen einzuf hren ideenreich und flexibel an die Arbeit zu gehen sowie offen hilfsbereit und solidarisch mit Kollegen umzugehen fm HI nlh k af Ai u Der Engl nder Meredith Belbin untersuchte in den 1970er Jahren die Auswirkungen der Teamzusammensetzung aus verschiedenen Pers nlichkeitstypen auf die Teamleistung Ausgehend von der Annahme dass das Pers nlichkeitsprofil eines Menschen auf unterschiedlich stark ausgepr gten Eigenschaften beruht analysierte Belbin die Ergebnisse von unterschiedlichen Teams und identifizierte so neun verschiedene Teamrollen welche sich aus den Verhaltensmustern der Mitglieder ergeben Teamrolle Neuerer Erfinder Wegbereiter Weichensteller Koordinator Integrator Macher Beobachter Teamarbeiter Mitspieler Umsetzer Perfektionist Spezialist Rollenbeitrag bringt neue Ideen ein entwickelt Kontakte f rdert Entscheidungsprozesse hat Mut Hindernisse zu berwinden untersucht Vorschl ge auf Machbarkeit verbessert Kommunikation baut Reibungsverluste ab setzt Pl ne in die Tat um vermeidet Fehler stellt optimale Ergebnisse sicher liefert Fachwissen u Information 132 Tuckman 1965 Charakteristika unorthodoxes Denken kommunikativ extrovertiert selbstsicher vertrauensvoll dynamisch arbeitet gut unter Druck n chtern strategisch kritisch kooperati
55. Tagungen und Fachmessen besuchen Informieren bei Firmen aus der gleichen Branche Experten beiziehen Entscheidungshilfen im Internet nutzen Evaluationsreports studieren e Long List Liste der n her zu analysierenden Softwarepakete o Enth lt Informationen zu Softwarepaketen und deren Lieferanten und Hersteller o Informationen in Form von Referenzen auf entsprechende Quellen und Unterlagen Filterung der Long List e Reduktion der Long List auf wenige 2 3 Kandidaten e Muss Anforderungen auswerten Umgekehrte Pyramide von grob bis fein e Kann Anforderungen auswerten Klar abgeschlagene L sungen nicht weiter analysieren e Long List erg nzt mit Ausschlussentscheid oder Bewertung Offerten einholen und beurteilen e Grundlage f r Beschaffungsentscheid schaffen e Bewertung mit effektiven Beschaffungs und Betriebskosten erg nzen e Abgleich von Pflichtenheft Anforderung und Offerte e Priorisierte Offerten Offerte kann auf verschiedene L sungsformen hinzielen e Alle Anforderungen erf llende Paketl sung e Paketl sung mit spezifischen Erweiterungen Anpassungen e Extremfall Neuentwicklung Individuall sung Entscheid ber weiteres Vorgehen e _ Entscheid ber das weitere Vorgehen Be e Empfehlungen an den Auftraggeber Gesch ftsleitung abgeben e Gesch ftsleitung diskutiert ber Vor und Nachteile und validiert die Transferarbeit Urs Zihlmann Seite 122 C C HOCHSCHU
56. Test gegen die impliziten Erwartungen des Auftraggebers Test der Benutzerakzeptanz mit Use Case orienterten Testabl ufen Pr fung der vertraglichen Akzeptanz definierte Abnahmekriterien 102 Spillner amp Linz 2004 S 62 63 Transferarbeit Urs Zihlmann Seite 76 C C HOCHSCHULE LUZERN Technik amp Architektur Transfer in die betriebliche Umgebung Wie machen wir es heute Da ich kein Softwareentwickler bin kenne ich mich mit den Methoden Frameworks und Testumge bungen nur begrenzt aus In der Regel wird das Produkt von den Personen getestet die den Code geschrieben haben Daneben kommen autom Tests wie auch Tests der Use Cases zum Einsatz Im Dezember 2013 haben wir ein gr sseres Projekt mit 7 Softwareentwicklern gestartet Bei diesem Projekt versuchen wir eine neue Herangehensweise und zwar werden alle abgeschlossenen Stories von einem anderen Softwareentwickler getestet Wir haben im Moment noch keine Definition of Done aber ich hoffe dass wir diese sp testens f r das n chste Projekt definieren werden In dem erw hnten Projekt wird der Tester die Story lesen und versuchen zu verstehen was die Aufgabe und der Zweck des zu testenden Moduls sind Er bekommt so viel Zeit wie n tig um die Funktionalit ten zu testen Wenn die Tests erfolgreich sind wird die Story geschlossen ansonsten muss der Entwickler die Fehler so rasch wie m glich korrigieren In diesem und bei den meisten anderen Projekten arb
57. Urs Zihlmann Seite 4 C C HOCHSCHULE LUZERN Technik amp Architektur Scheinl sungen und echte L sungen 107 DIE 5 ANTREIBER 107 TRANSFER IN DIE BETRIEBLICHE UMGEBUNG JD Wie machen wir es heute 108 Umsetzungsm glichkeiten im Betrieb 109 9 UMGANG MIT NDERUNGEN 110 NDERUNGEN MANAGEN 110 PROJEKT ERFOLGSMANAGEMENT 111 CLAIM MANAGEMENT 111 as ist ein Risiko FMEA Failure Mode and Effect Analysis Unsicherheiten Quantifizieren Risikomanagement Prozess TRANSFER IN DIE BETRIEBLICHE UMGEBUNG Wie machen wir es heute Umsetzungsm glichkeiten im Betrieb 10 INNOVATIONS SCHUTZ VERTR GE BESCHAFFUNG 117 EVALUATION VONSTANDARD SOFTWARE 00000 118 Phase 1 Anforderungen und Pflichtenheft 119 Phase 2 Papier Evaluation 121 Phase 3 Testen amp Use Case Evalutation 123 JURISTISCHE ASPEKTE 125 TRANSFER IN DIE BETRIEBLICHE UMGEBUNG 22 2 2 0 0 0 0 00 126 Wie machen wir es heute 126 Umsetzungsm glichkeiten im Betrieb 126 11 PROJEKTABSCHLUSS UND LESSONS LEARNED 127 MARKTEINF HRUNG PRODUKT BERGABE 0 000127 AIDA 127 Marketingstrategie 128 PROJEKTABSCHLUSS UND NEUANFANG 128 KUNDENZUFRIEDENHET 0000 180 Net Promoter Score 130 TRANSFER IN DIE BETRIEBLICHE Uergel Wie machen wir es heute 131 Umsetzungsm glichkeiten im Betrieb 131 VERZEICHNISSE amp QUELLEN 132 VOLLST NDIGKEITSHINWEIS ZU DEN QUELLEN 132 ABBILDUNGSVERZEICHNIS 132 TABELLENVERZEICHNIS 134 LITERATURVERZEICHNIS 135
58. Verf gung zu haben So k nnen die einzelnen Tests auf den passenden Umgebungen getestet werden Ein Integrationstest w re beispielsweise auf der Entwicklungsumgebung nicht m glich da die Anbindungen zu anderen Systemen nicht vorhanden sind F r die Abnahme sollte ausserdem mit Produktionsdaten getestet werden um den Systemzustand des Live Systems m glichst genau nachzubilden Entwicklungsumgebung Testumgebung Integrationsumgebung Stabil Snapshot Projekt Analog zur Live Umgebung Modultests Funktionale Tests Nichtfunktionale Tests Performance etc 3rd Party Integrationstests Testdaten Testdaten Produktionsdaten Abnahme End To End Test Tabelle 17 Testumgebungen Transferarbeit Urs Zihlmann Seite 68 LUZERN Technik amp Architektur C p C HOCHSCHULE Testprozess Le Testprozess mit allen notwendigen Schritten darstellen Welche Testschritte m ssen f r einen erfolgreichen Test durchlaufen werden o Testplanung Testspezifikation Testausf hrung Test Reporting Testbewertung er ner O O Testprozess Testplanung Testspezifikation Testausf hrung Test Reporting Testbewertung Detaillierte Entwurf der Testf lle Techn Ausf hrung Zusammenstellung Bewertung der Planung der gem festgelegten der definierten der Testergebnisse Testergebnisse auf Prozessschritte Techniken Testf lle ber alle Testebenen Basis des kumulierten Testkonzept Testreports Inkrement 1a Inkrement 1c Release 1
59. Vorstellungen z hlen o 3 92 Gibt es bei der Arbeit jemanden der mich in meiner Entwicklung unterst tzt und f rdert o 3 67 Geben mir die Ziele und die Unternehmensphilosophie meiner Firma das Gef hl dass meine Arbeit wichtig ist o 3 50 Habe ich bei der Arbeit jeden Tag die Gelegenheit das zu tun was ich am besten kann 3 42 Habe ich in den letzten sieben Tagen f r gute Arbeit Anerkennung und Lob bekommen 2 83 Habe ich innerhalb der Firma einen sehr guten Freund 2 75 Hat in den letzten sechs Monaten jemand mit mir ber meine Fortschritte gesprochen Umsetzungsm glichkeiten im Betrieb Eine Umsetzungsm glichkeit sehe ich vor allem bei Bewerbern so dass diese in Zukunft den Gallup und oder den Belbin Test ausf llen damit wir ein m glichst klares Bild von den Kandidaten erhalten Mich haben alle Tests auch die 5 Antreiber positiv berrascht und ich bin der Meinung dass solche Methoden nicht nur in Schulen sondern auch im Gesch ft eingesetzt werden sollten F r das Thema Konfliktmanagement sehe ich im Moment keinen Umsetzungsbedarf Es w re jedoch w nschenswert dass die eMedia Teammitglieder dieses Kapitel zumindest einmal gelesen haben und sich der Wichtigkeit des Konfliktmanagements bewusst sind co Transferarbeit Urs Zihlmann Seite 10 C C HOCHSCHULE LUZERN Technik amp Architektur 9 UMGANG MIT NDERUNGEN C 19 09 2013 Heinz Scheuring Bei Heinz Scheuring behandelten wir im ersten Tei
60. a arrroteusi raro vatum VO V 2019 eitung Urs Zihlmann Stefan Steinmann Vanessa Freudrich Ort Z rich Leutschenbach der Eveline Ritter Die Veranstaltung war f r meine Arbeit n tzlich und lehrreich Bemerkung Der Praxisbezug war f r mich deutlich erkennbar Ke Bemerkung 1 Der Inhalt wurde attraktiv vermittelt x Bemerkung Die Leitung war fachlich kompetent Le Bemerkung i De Infrastruktur war geeignet x Bemerkung 1 Dieses Ziel habe ich erreicht A d r E Kaze kl Bessere Vers kandus fe S Na au Y d S 7 d AIR 77 or Si ler allas I AhNietuu y ij deeg lo Mad p Ich nehme folgende Erkenntnis se mit und setze ae um A A SL x 4 bk F e AS lan be K Onpufled a und wo Kouwen f und Produ lehen fer Lotus Au cas SMW unlik Le a Das hat mir bosondors gefallen Hands o Das hat mir weniger gefallen hat mich ge rgert oder gest rt 0 Was ich sonst noch sagen wollte Ove uoh pi Foiulozu aset Qey Fa und Seule Faste p r rk Ze 1 Welchen Gesamteindruck habe ich von der Veranstaltung Von 6 sehr gut bis 1 schlecht Name CH ame Abteilung Redaktion H A 6 L ei JS k I 0 ISRF inc Ausbildung Die Kurse der Ausbildung SRF sind Eduqua zertifiziert Abbildung 2 Feedback Formular bei SRF und tpc Transferarbeit Urs Zihlmann Seite 15 LUZERN Technik amp Architektur Lucerne University of Applied Sciences and Arts v DC HOCHSCHULE Umsetzungsm glichkeiten im Betrieb K
61. alts und einen Beziehungsaspekt wobei letzterer den ersten bestimmt Jede usserung enth lt eine Beziehungsaussage Kommunikationsabl ufe werden unterschiedlich strukturiert Entscheidend ist was beim Empf nger ankommt nicht was gesendet wird Kommunikation erfolgt digital oder analog Der Sender ist verantwortlich daf r dass er so verstanden wird wie er es meint Kommunikation verl uft symmetrisch und oder komplement r Die Kommunikation beruht immer auf einem Dialog zwischen einem Sender und einem Empf nger Sach und Beziehungsebene Albert Mehrabian 55 38 7 Regel Ein Modell zum Verst ndnis der Bedeutung von nonverbaler Kommunikation ist die 55 38 7 Regel von Albert Mehrabian In einer Studie konstatiert der Forscher dass bei Pr sentationen vor Gruppen 55 Prozent der Wirkung durch Ihre K rpersprache bestimmt wird das heisst K rperhaltung Gestik und Augenkontakt 38 Prozent des Effekts erzielen Sie durch Ihre Stimmlage und nur 7 Prozent durch den Inhalt Ihres Vortrags Sachebene Sachebene U RE o Zur Sachebene geh ren die Inhalte einer Nachricht in Form von Zahlen Fakten Daten Gedanken und W nschen GX L I ennn geg 38 Botschaft Beziehungsebene o Die Beziehungsebene bezieht sich auf die zwischenmenschlichen Aspekte Hier unterscheidet man zwischen verbalem und nonverbalem Verhalten Beziehunasebene Abbildung 1 Sach und Beziehungsebene 1 Kaspar III 2013 S 7 The Journal o
62. anagement bedeutet nicht dass Projekte zwingend realisiert werden m ssen Ein laufendes Projekt abzubrechen kann ebenfalls PEM sein Neben den Kernfragen zum Projektstatus m ssen im Projekt immer wieder auch weiterf hrende tiefer greifende Fragen gestellt werden und dies mit der n tigen Distanz zur Tagesaktualit t 7 PEM Fragenkatalog Welches sind aus heutiger Sicht die Erfolgsfaktoren f r das Projekt Auf welche Teile Resultate des Projektes kann verzichtet werden Wer ist mit einem hnlichen Vorhaben gescheitert K nnen wir daraus lernen Kennen wir den Einfluss unseres Projekts auf andere Projekte und Systeme Wer k nnte sonst noch einen Nutzen aus dem Projektresultat ziehen Erfolgsmanagement im Projekt ist wesentlich mehr als Zielfindung und die Steuerung des Projektes in Richtung Ziel PEM bedeutet das permanente und weitsichtige Optimieren des Projektes im Dienste der Projektziele und der bergeordneten Strategie Auch die Ziele selber werden dabei nicht als statische Gr sse betrachtet Sie zu hinterfragen und gegebenfalls anzupassen ist Teil dieses Prozesses Claim Management Beim Claim Management geht es darum durch pr zise Vertragsgestaltung offene Kommunikation mit dem Kunden und pr zise Dokumentation des Projektgeschehens Konflikte bei der Vertragserf llung zu vermeiden und Abweichungen fr hzeitig zu erkennen 158 Scheuring 2013 S 124 189 Scheuring 2013 S 127 160 Scheuring 2013
63. anspruchsvoll und entscheidend f r den Projekterfolg Die Ziele der Phase 0 sind einerseits der Go Nogo Entscheid andererseits das Abstecken des Rahmens die erste Formgebung des Projektes sowie die Schaffung der notwendigen inhaltlichen und organisatorischen Voraussetzungen f r das Projekt 14 Siehe http www designmethodenfinder de card sorting s1 14 07 2013 15 Scheuring 2013 S 47 190 191 16 Scheuring 2013 S 48 49 Transferarbeit Urs Zihlmann Seite 19 C C HOCHSCHULE LUZERN Technik amp Architektur Projektvorbereitung Projekt entstehung Auftraggeber Gespr ch mit _ Auftraggeber Start Brainstorming Projektleiter team provisorisch 7 Projekt bearbeitung Auftrag zur Projekt vorbereitung Entwurf Projekt Definition Projektauftrag Abbildung 3 Prozess der Projektvorbereitung Start Brainstorming Eine fachlich m glichst breite Zusammensetzung des Brainstorming Teams ist sehr erw nscht Ein Start Brainstorming besteht aus mehreren kleinen Brainstormings zu verschiedenen Themen Erfolgsfaktoren Ko Visionen Stakeholder Fragen fehlende Informationen Das 0 Gebot mare g 2 Resultate Bed rfnisse Sachgebiete Ziele Bef rchtungen Risiken Abbildung 4 Das Start Brainstorming zu verschiedenen Themen J 17 Scheuring 2013 S 49 1
64. as eenn Eesen 12 Tabelle 5 Mit Rhetorik berzeugen 2 na ne allen 13 Tabelle 6 Ausbildungen bei SRF und pc 14 Tabelle 7 Feedback nach Carmen Thomas 14 Tabelle 8 Superuser Regaln 22 u 2 nk a nun 16 RER Rollen bersicht E 26 Tabelle 10 Stakeholder Identity Matrix Card 29 Tabelle 11 Instrumente der Situationsanalyse AA 37 Tabelle 12 Instrumente der Situationsanalyse AA 38 Tabelle 13 Nutzwertanahse AA 40 Tabelle 14 Designaspekte bei eMedia A 42 Tabelle 15 berblick Erbebungestechniken ennenen nne 49 Tabelle 16 Kano Modell u u ee nn en aaa EECH 50 Tabelle 17 Testumgeb ngen 4 2 8242 a denen SEN deed ege 68 Tabelle 18 Arten von Fehlern Sasse Han en a a aan manga ee EEN 70 Tabelle 19 Vorgehensmodellen in der TT 94 Tabelle 20 Teamentwicklungsuhr nach Tuckman nsen nnnnnnenn nnmnnn ennn 98 Tabelle 21 Teamrollen nach Belbin 4444440444HaBRRnnnan nn nnnnnnnnnnnnnnnonnnennnnnnnsnnenennnnnnnonnennnsnennnenrnrsonnennannenen 99 Tabelle 22 Die acht K nfliktarten u 2 es ae ea an aa naar 103 Tabelle 23 Eskalationstreppe nach Glas 106 Tabelle 24 Konflikt Gespr ch in f nf Phasen 106 Tabelle 25 Die f nf Antreiber u 4m40u444nnnn nennen nun nennnnnennnnnernnnnnnnennennnnnennnonnnnnsnnennnnnnnnnonnnnnsnnerenennnn nen 108 Tabelle 26 Risikoarten EE 112 Tabelle 27 Risiken identifizieren u nennen rider 112 Tabell
65. beide Metriken vereint darstellt Mithilfe dieser Grafik IEEE Standard 1061 Transferarbeit Urs Zihlmann Seite 65 e HOCHSCHULE LUZERN Technik amp Architektur werden auch die kritischen Bereiche Modul Funktion dargestellt In der Guideline wird definiert wie die einzelnen Bereiche zu berpr fen sind Cyclomatic Complexity Punkte Module in diesem Bereich haben eine hohe Pro Funktion oder Modul ber das ganze Projekt Fehlerwahrscheinlichkeit und m ssen besser getestet werden Empfohlene Tests Code Module Dependency eLoC CC Analyse Review amp Unit Tests Punkte Module in diesem Bereich haben eine tiefe Fehlerwahrscheinlichkeit Empfohlene Tests Review amp Unit Tests Komplexit t 1000 eLoC 1500 Lines of Code elo Abbildung 22 Cyclomatic Complexity Je h her eLoC Zahl und CC Wert sind desto h her ist die Fehlerwahrscheinlichkeit einer Funktion F r diese Funktionen w rde man z B eine Code Analyse ein Code Review und einen Unit Test durchf hren Bei weniger kritischen Funktionen hingegen w rde ein Code Review ausreichen Die Grenze wie welche Bereiche getestet werden muss f r jedes Arbeitsprodukt individuell definiert werden Continuous Integration Ziel Konzept der permanenten Software Integration und deren Unterst tzung bei der Verifikation von Software Modulen darstellen Kernfrage Welche verifizierenden Massnahmen werden im Continuous Integration Server durchgef hrt
66. bt Iterationen nur zwischen zwei aufeinanderfolgenden Phasen und durchl uft relativ starr sequentiell die folgenden Phasen Abbildung 34 Wasserfallmodell 103 Siehe http www torsten horn de techdocs sw dev process htm 02 10 2013 Transferarbeit Urs Zihlmann Seite 79 Lucerne University of Applied Sciences and Arts C C HOCHSCHULE LUZERN Technik amp Architektur Auch f r Nichtexperten verst ndlich Anforderungen m ssen zu 100 vollst ndig sein Einfache Meilensteinplanung Entwicklungsrisiken werden sp t erkannt Begrenzter Managementaufwand Lauff hige Version erst am Ende der Entwicklung RUP RUP Rational Unified Process ist eine Vorgehensweise beim Softwareentwicklungsprozess mit eher schwergewichtiger Methodologie vielen formalen Definitionen und Dokumenten iterativ architekturzentriert Use Case getrieben wohldefiniert und sehr strukturiert Sehr gut erprobt Recht komplex Geeignet f r komplexe Softwareentwicklungsprojekte Iterationsl nge zu lang Gute Unterst tzung durch zahlreiche IBM Tools Hoher Initialaufwand f r Projektbeteiligte V Modell Das V Modell ist ein Vorgehensmodell f r den Softwareentwicklungsprozess Es ist ein wenig mit dem Wasserfallmodell vergleichbar allerdings werden fr he mit sp ten Phasen ber Testdaten verbunden V f rmig Es ist auch iterativ anwendbar Phasen und zeitliche Abl ufe stehen nicht im Vordergrund Es ist sehr stark formalisiert und dokumentenzentriert und mu
67. chluss gibt es in Scrum keine fixen Anweisungen und Vorgaben Artefakte Das Verrechnen der Arbeitsstunden muss genauso erledigt werden wie das Schreiben eines Abschlussberichts unabh ngig davon ob Scrum oder ein Phasenmodell eingesetzt wurde Insofern sehe ich im Moment nur bei der Kommunikation Optimierungsbedarf damit alle Projektmitglieder wissen wann ein Projekt abgeschlossen ist und ob die Ziele erreicht wurden Wa Q D adi Wa Transferarbeit Urs Zihlmann v C HOCHSCHULE LUZERN Technik amp Architektur VERZEICHNISSE amp QUELLEN Vollst ndigkeitshinweis zu den Quellen Textpassagen und Zitate deren Ursprung entweder unbekannt ist oder deren Quellen trotz sorgf ltiger Recherche nicht eruiert werden konnten gelten als zitiert Abbildungsverzeichnis Abbildung 1 Sach und Beziehungsebene su 4440urnnsonnnnnannennnnnnnnnnnnennnnnnnnnennennsnnennnonnennsnnensnonnnrnonennnsnrensann 8 Abbildung 2 Feedback Formular bei SRF und pe 15 Abbildung 3 Prozess der Projektvorbereitung sssssssrssesssrnrnssrrnnrststttnntsrrttnnnennnnnnstnnnnneetnnn nnne nnnnn nanenane nsen e nnn 20 Abbildung 4 Das Start Brainstorming zu verschiedenen Themen 20 Abbildung 5 Projekt Stakeholder und ihre m glichen Mehrfachrollen A 25 Abbildung 6 Projekt rganisation nn ee E A AEAN ENE re aa a Aaina 25 Abbildung 7 Stakeholder Analyse u 240um44440n4neannnnnnnnnnnnnnnennnnnnennnnnnnnnnnennn
68. d beispielsweise der Software Quellcode mit dem Software Modultest gepr ft Ist dieser erfolgreich werden Software Architektur und Design mit dem Software Integrationstest das Pflichtenheft mit dem funktionalen amp nicht funktionalen Test und das Lastenheft mit dem Software Abnahmetest gepr ft Software Quellcode Coding Standards amp Coding Guidelines Ziel Grundlagen der Entwicklung eines Regelwerkes f r die Programmierung verstehen Kernfrage Welche Anforderungen werden an einen Programmcode gestellt der lesbar wartbar robust und ist Coding Standards sind nur allgemeine Standards f r die Erstellung von Quellcode die im Unternehmen spezifisch angepasst werden m ssen Inhalt von Coding Standards o Quelltextformatierung Coding Style Checker u o Programmierregeln Branchen und sprachenspezifisch Coding Rule Checker o Programmiierstil e Anwendung von Entwurfsmustern e Einsatz passender API Komponenten Transferarbeit Urs Zihlmann Seite 64 C C HOCHSCHULE LUZERN Technik amp Architektur Typisierung Wahl des Typs f r ein Symbol Vermeidung von Redundanz und Entfernung berfl ssiger Programmteile Wiederverwendbarkeit des Quellcodes Modularit t nderbarkeit Wartbarkeit des Quellcodes Robustheit durch Fehler und Ausnahmebehandlung Kommentierung Die berpr fung des Programmierstils erfolgt in der Regel mit Code Review Coding Guidelines enthalten nicht nur die Programmierregeln i
69. d analysieren Befragung von Mitarbeitern Kunden Lieferanten Markt amp Konkurrenz analysen Analysen best Studien Abweichungsursachen und Ursachen Wirkungs Kette Input Output Hintergr nde analysieren O Modell Interviews Workshops Prognosen erstellen Di e Analyse bestehender Studien Statistiken abelle 11 Instrumente der Situationsanalyse 5 Scheuring 2013 S 163 54 Scheuring 2013 S 164 165 5 Scheuring 2013 S 165 Transferarbeit Urs Zihlmann Seite 37 Lucerne University of Applied Sciences and Arts HOCHSCHULE LUZERN Technik amp Architektur Die Kernfragen o Was genau m sste sein o Woran sollen L sungen gemessen werden Die Zielfindung ist ein wiederkehrender Prozess der sich ber mehrere Projektphasen erstrecken kann Die Ziele werden dabei laufend konkreter und detaillierter Bei der Erarbeitung der Projektziele sind zwei F lle zu unterscheiden o Ziele aus einem unbefriedigenden Ist Zustand mit mehr oder weniger grossen Problemen o Ziele aus einer Idee vielleicht sogar aus einer Vision f r etwas Neues Die Unterscheidung von Muss Zielen und Soll Zielen kann in vielen Projekten hilfreich sein Muss Ziele k nnen auch als Ranmenbedingungen bezeichnet werden Ziele sollen o vollst ndig sein d h alle wesentlichen Anforderungen abdecken o erreichbar sein unrealistisch hohe oder gar unerreichbare Ziele bewirken das Gegenteil von dem was angestrebt wird die Motivation g
70. dentifiziert Performanz Funktionalit t Usability Portabilit t Sicherheit Um konkrete nichtfunktionale Anforderungen zu spezifizieren m ssen diese abstrakten Attribute in detaillierte messbare Qualit tsattribute verfeinert werden Ein Beispiel hierf r ist wie schnell genaue Zeitangabe in Sekunden ein System auf Benutzereingaben reagieren soll Ziel ist es klare Qualit tsvorgaben an die systemunterst tzten Gesch ftsprozesse und Benutzeraufgaben zu erheben und schliesslich umsetzen zu k nnen Ein System kann s mtliche funktionalen Anforderungen perfekt abdecken wenn jedoch die nicht funktionalen Anforderungen z B Benutzbarkeit Antwortzeitverhalten etc nicht korrekt ber cksichtigt sind wird das System vom Benutzer Kunden nicht akzeptiert werden Nichtfunktionale Anforderungen haben ein grosses Wiederverwendungspotential Daher ist es sinnvoll eine Standard Gliederung Qualit tsmodell oder eine Referenzdatenbank einzusetzen H Siehe http www dpunkt de pdf Broschueren Rupp RE 3A_WA pdf 26 08 2013 9 Siehe http www sga net iso9126 html 04 09 2013 92 Siehe http www re wissen de Wissen Anforderungserhebung Praktiken Nichtfunktionale Anforderungen _erheben htmi 04 09 2013 7 Siehe http www anforderungsmanagement ch in_depth_vertiefung funktionale nicht funktionale anforderungen index html 24 08 2013 Transferarbeit Urs Zihlmann Seite 54 v C HOCHSCHULE LUZERN Tech
71. der Hauptgrund f r die Bewertung die Sie uns gegeben haben e Falls Bewertung lt 9 Welches ist die wichtigste Verbesserung nach der Ihre Bewertung n her an der 10 liegen w rde 174 Haas III 2013 S 13 Transferarbeit Urs Zihlmann Seite 130 C C HOCHSCHULE LUZERN Technik amp Architektur Transfer in die betriebliche Umgebung Wie machen wir es heute Projektabschluss Wie ein Projekt abgeschlossen wird h ngt von der Auffassung und Umsetzung des Projektleiters ab Wir haben keine Liste welche Arbeiten erledigt werden m ssen Einige Aufgaben geh ren dennoch zur Pflicht wie z B das Ab und Verrechnen der Aufw nde die bergabe an den Support mit entsprechenden Schulungen und das Erstellen einer Dokumentation Bei gr sseren Projekten mit entsprechendem Budget findet h ufig ein gemeinsames Nachtessen statt Auch wenn die meisten Projekt Mitarbeiter bereits an neuen Projekten arbeiten sollten solche Social Anl sse nicht vernachl ssigt werden Zu diesem Zeitpunkt hat das Team schon ein wenig Distanz zu dem Projekt und nicht selten entstehen an solchen Events neue und spannende Ideen wie das Projekt in einer n chsten Phase verbessert oder ausgebaut werden k nnte Eine grosse Herausforderung beim Projektabschluss ist die bergabe an den Kunden bzw Betrieb Wir arbeiten vor allem an internen Projekten und so kommt es leider h ufig vor dass der 1st Level Support bergangen wird und Probleme direkt an uns in d
72. die einem Team aus dem Weg ger umt werden m ssen damit es produktiver werden kann Das Produkt Inkrement usable Software Das Team strebt danach am Ende eines Sprints etwas zu liefern das man pr sentieren kann Die Funktionalit ten die am Ende des Sprints pr sentiert werden m ssen tats chlich in einem auslieferbaren Zustand sein Scrum ersetzt nicht das Projektmanagement Scrum ersetzt das herk mmliche Projektmanagement nicht Scrum ist eher eine Methode der agilen Softwareentwicklung eine Vorgehensweise ein Modell wie die Entwicklung ablaufen k nnte Scrum gibt einen Rahmen vor verr t uns aber zum Beispiel wenig zu Fragen des Projektcontrollings zur Aufwandsch tzung oder zur L sung von Ressourcenkonflikten 1 Change Management Change Management hat sich in wenigen Jahren zu einem Schl sselbegriff der Managementdiskussion entwickelt St ndiger und immer schnellerer Wandel erh ht die Zahl der Change Management Projekte die in Unternehmen oft gleichzeitig verfolgt werden Auch wenn inzwischen ein deutlicher Erfahrungszuwachs aus der Praxis heraus die Kompetenz zum Change Management gef rdert hat scheitern Studien zufolge bis zu 70 aller Changeprojekte 7 126 Geirhos 2011 S 183 127 Siehe http www jp consulting de Managementberatung Fachinformation Change Management acht Schritte zum Veraenderungserfolg nach John Kotter E1156 htm 14 11 2013 Transferarbeit Urs Zihlmann Seite 92 C C HOC
73. e 28 Kernrisiken E 113 Tabelle 29 Auszug der Risiko Bewertungstabelle f r PoC Adobe Anywhere AA 116 Tabelle 30 Das Priortt ten Ert ilungsorad Modell 120 Tabelle 31 Markteinf hrung nach AIDA 22uuussssssnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnennnnnnnnnnnnnnnnnnnnnen 127 Tabelle 82 Die 4 EE 128 Transferarbeit Urs Zihlmann Seite 134 pc Literaturverzeichnis Alfred Aschmann Markteinf hrung 2013 Marcel A Bieri IP Vertr ge Software Evaluation und Beschaffung Dezember 2013 Manfred Burghardt Projektmanagement SIEMENS 9 Auflage 2012 Manfred Burghardt II Einf hrung in Projektmanagement SIEMENS 1 Auflage 1995 Karol Fr hauf Projektmanagement Informatik und Technik Stakeholder Analyse 2013 Karol Fr hauf Il Projektmanagement Informatik und Technik Anforderungen ermitteln 2013 Karol Fr hauf Ill Projektmanagement Informatik amp Technik Anforderungen modellbasiert dokumentieren 2013 Karol Fr hauf IV Projektmanagement Informatik und Technik Anforderungen dokumentieren 2013 Karol Fr hauf V Projektmanagement Informatik und Technik Anforderungen nat rlichsprachig dokumentieren 2013 Karol Fr hauf VI Projektmanagement Informatik und Technik Anforderungen pr fen 2013 F Glasl Konfliktmanagement Ein Handbuch f r F hrungskr fte Beraterinnen und Berater 2004 Transferarbeit Urs Zihlmann Lucerne University of Applied Sciences and Arts H
74. e Form des Projektes es sich handelt heissen Kernrisiken Diese sollten immer mit ber cksichtigt werden da sie quasi Erfahrungsberichte einer grossen Menge von Projekten darstellen 161 Siehe http www pm handbuch com planung risikoanalyse 15 12 2013 162 Siehe https www bsi bund de DE Themen ITGrundschutz ITGrundschutzSchulung Webkurs 1004 4_RisikenAnalysieren 1_ Risiken 20identifizieren Risikenldentifizieren_node html 15 12 2013 163 Siehe http www profv de uni Risikomanagement Risikomanagement pdf 15 12 2013 Transferarbeit Urs Zihlmann Seite 112 Lucerne University of Applied Sciences and Arts HOCHSCHULE LUZERN Technik amp Architektur e Fehlerhafter Zeitplan e Fehlendes Know how e Inflation der Anforderungen e Fehlinterpretation der Anforderungen e Mitarbeiterfluktuation e Arbeitsumgebung Arbeitsger te e Spezifikationskollaps e Preissteigerungen Lieferverzug e Mangelnde Arbeitsleistung e Fehler in Modulen Tabelle 28 Kernrisiken Strategien zur Risikobew ltigung o _ Eintretenswahrscheinlichkeit des Risikos durch vorbeugende Massnahmen vermindern Auswirkungen von Ereignissen vermindern z B alternative Lieferanten Konsequente berwachung und Steuerung des Projektes Partner und Lieferanten die Risiken teilweise mittragen lassen Risiken versichern Projekt gar nicht starten FMEA Failure Mode and Effect Analysis FMEA ist eine analytische Methode zur Er
75. e die funktionellen Anforderungen erf llt e _ zum Unternehmen passt e Ihre Prozesse unterst tzt finanziell tragbar ist Phase I Anforderungen und Pflichtenheft erarbeiten Ermittlung der Evaluationskosten An die L sung Bewertungmetrik Infrastruktur Beteiligten und Termine An den Lieferanten KO Wish list Know how Betroffenen Priorit t Vorschriften Erf llungsgrad Phase Il Papier Evaluation KO Kriterien zuerst Grundlage Kosten Lieferanten Top Down vom beurteilung Hersteller Groben zum Detaillierten Phase Ill Testen kaufen installieren und einf hren Art der Hand on Anwendungsf lle Evaluation gt zur Cache auan E Sotware kaufen festlegen zusammenstellen un ron SE SC Intern Extern typische Evaluationsbericht Demo h ufige Entscheid ber Kauf Firmenbesuch kritische Einf hrung oder neue Iteration Abbildung 50 Die drei Phasen der Evaluation Transferarbeit Urs Zihlmann Seite 118 LUZERN Technik amp Architektur C p C HOCHSCHULE Phase 1 Anforderungen und Pflichtenheft Phase I Anforderungen und Pflichtenheft erarbeiten Ermittlung der Evaluationskosten An die L sung Bewertungmetrik Infrastruktur beteiligten und Termine An den Lieferanten KO Wish list Know how betroffenen Priorit t Vorschriften Erf llungsgrad Abbildung 51 Phase I Beschaffungsteam bilden e Personen f r das Beschaffungsteam sind bestimmt e Anforderungen an Mitglieder definieren e Gee
76. eholder haben nicht nur das Ziel Ihres Projektes im Kopf sondern sind gleichzeitig f r die Erreichung von anderen Vorhaben verantwortlich Ein Ignorieren dieser Fakten bringt Projekte schnell in Schieflage 5 Eine Liebe f rs Detail Im Projektmanagement dreht sich alles um Details Dabei sind erfolgreiche Projektleiter akribisch im Managen von Details Kleine Details k nnen pl tzlich sehr wichtig werden Details k nnen in einem Projekt zum Erfolg oder zum Misserfolg f hren 6 Schnelles Erkennen und L sen von Problemen In jedem Projekt gibt es Phasen wo Probleme und Hindernisse auftauchen diese ben tigen schnellstm gliche L sungen Ein guter Projektmanager zeichnet sich dadurch aus wie er dieses Problem handhabt 7 Technisches Sachverst ndnis Als guter Projektmanager ben tigen Sie solides technisches Wissen ber die Plattformen Software L sungen und Programme in ihrer Firma auch wenn Ihr eigener Job gar nicht technisch ist bernehmen Sie selber Projektaufgaben und erledigen Sie diese erfolgreich und zeitgerecht damit gewinnen Sie den Respekt Ihres Teams was Ihnen wiederum dabei hilft Ihr Projektteam zum Erfolg zu f hren Diese Umfrage zeigt dass nicht nur messbare Faktoren wie Kosten und Termine wichtig sind sondern auch die weichen Skills wie Motivation Team F hrung Widerst nde oder fehlendes Knowhow Stakeholder Die Definition von Stakeholdern nach ISO 10006 Stakeholder eines Projekts sind alle
77. eht verloren o widerspruchsfrei sein hoch gesteckte inhaltliche Ziele widersprechen oft gleichzeitig erhobenen engen Termin oder Kostenzielen o m glichst grossen Gestaltungsspielraum bei der L sungssuche gew hrleisten also l sungsneutra l sein Eine weitere Aufgabe der Zielfindung besteht darin die identifizierten Ziele zu gewichten beispielsweise mit einem Wert zwischen 1 und 10 Um herauszufinden ob sich diese Ziele mit den bergeordneten Unternehmenszielen vertragen empfiehlt sich die Ziel Stakeholder Matrix Das Einnehmen anderer Perspektiven insbesondere jener wichtiger Stakeholder kann zu neuen Schlussfolgerungen und Priorit ten f hren Stakeholder K nstler Stiftung Besucher Projektziele berzeugender K nstler 0 zu ei berzeugende Auswahl der Ausstellungsobjekte Sch nes Ambiente und Pr sentation Ach Hohe Besucherzahl Ach Tiefe Gesamtkostsen 0 0 5 Scheuring 2013 S 166 57 Scheuring 2013 S 169 170 5 Scheuring 2013 S 170 KEE EE be Fila ER ransferarbeit Urs Zihlmann Sei C C HOCHSCHULE LUZERN Technik amp Architektur L sungssuche Die Kernfragen und aufgaben o Welches sind die verschiedenen L sungen o Anwenden von Kreativmethoden In machen Projekten insbesondere bei Kundenprojekten mit vordefinierten Abl ufen und Muster liegt die L sung auf der Hand und erfordert keine breit angelegte Variantensuche und Auswahl Je innovativer das Projekt
78. eidungsfindung ohne klare Regeln und Methoden fast nicht m glich ist Unsere Gruppe hat sich f r die Nutzwertanalyse entschieden die ich im Betrieb in Zukunft auch fters einsetzen m chte Nach der Entscheidungsfindung muss zwingend das ganze Team hinter dem Entscheid stehen auch wenn die gew hlte L sung nicht von allen favorisiert wurde Ein Praxisbeispiel von Roland Haas hat genau eine solche Situation beschrieben bei der ein hochrangiger Milit rmitarbeiter mit der Entscheidungsfindung nicht zufrieden war sich dazu allerdings nicht mit Worten ge ussert hatte bis es zum kl renden Gespr ch kam Dieses Beispiel zeigte wie wichtig f r einen Projektleiter die Kommunikation und vor allem auch die Soft Skills in diesem Beispiel vor allem Einf hlungsverm gen sind Martin Iseli hat uns interessante Einblicke in die Welt des Industrial Design gegeben Der kurzweilige Unterricht und die Art und Weise wie Martin Iseli seine Geschichten und Erfahrungen mit viel trockenem Humor erz hlt hat kam bei mir sehr gut an Als besonders interessant empfand ich die Erfahrungen welche Martin Iseli bei den SBB Projekten sammeln konnte Das waren sch ne Beispiele daf r wie mit benutzerfreundlichem Design Probleme gel st werden k nnen Der dritte Teil zu den 7 Problembereichen konnte mich leider nicht berzeugen Die praktische bung welche fast den ganzen Morgen in Anspruch nahm wurde weder verst ndlich erkl rt noch habe ich au
79. eite 43 C C HOCHSCHULE LUZERN Technik amp Architektur 4 PROJEKTPLANUNG UND CONTROLLING pem sen ewsiennunsuen E 04 07 Manfred Stania Der Unterricht bei Manfred Stania war f r mich eines der Highlights 15 11 2013 dieses CAS Mit seinem Wissen und langj hrigen Erfahrungen in unglaublich spannenden Unternehmungen wie der NASA konnte er usserst unterhaltsame Geschichten und Beispiele aus der Praxis erz hlen Der Unterricht war jedoch keine Geschichtsstunde sondern wir gingen in relativ kurzer Zeit die wichtigsten Themen der Projektplanung durch und arbeiteten auch in kleineren Gruppen an Beispielen aus der Praxis z B Arbeitspakete und Projektstrukturplan Der Unterricht war eher auf die Technik und weniger auf die Informatik ausgerichtet trotzdem konnte Manfred Stania mich mit seinem Unterricht restlos begeistern Mit einfachen Worten schaffte er es komplexe Dinge simpel darzustellen und so hat er auch die Themen rund um die Projektplanung einfach und verst ndlich erkl rt Vertiefungsarbeit Die Vertiefungsarbeit ist die zweite schriftliche Arbeit in diesem CAS Dieses Thema wird wie der Name schon verr t in der Tiefe behandelt weshalb eine Zusammenfassung in der Transferarbeit nicht verlangt wird Ein Schwerpunkt der Vertiefungsarbeit ist die praktische Umsetzung im Betrieb damit die neuen Erkenntnisse aus dem Unterricht gleich in das gesch ftliche Umfeld einfliessen Ich habe mich f r das Thema Projektp
80. eiten wir mit zwei Umgebungen Einerseits haben wir die Test und andererseits die Live Umgebung Eine Integrationsumgebung gibt es im Moment nicht Dies bedeutet dass wir nach dem Release noch einmal viel Zeit aufwenden m ssen um die Funktionalit ten am produktiven System zu testen Im schlimmsten Fall und das kommt leider immer wieder vor treten Fehler nur in der produktiven Umgebung auf In diesen F llen m ssen die Fehler auch gleich in der Produktionsumgebung behandelt werden In unserer Abteilung gibt es keine professionellen Tester Die Softwareentwickler f hren bei uns mehrere Rollen aus unter anderem auch diejenige des Testers Die Abnahme erfolgt durch den Kunden nachdem er das Produkt auf der produktiven Umgebung getestet hat Da wir fast ausschliesslich an internen Projekten arbeiten ist der Kunde bei Fehlern die erst sp ter und in der produktiven Umgebung auftreten sehr kulant Wenn wir unsere Produkte an externe Firmen verkaufen w rden w re der Optimierungsbedarf bei der Software Qualit t noch gr sser als er jetzt schon ist Umsetzungsm glichkeiten im Betrieb Das Verbesserungspotential in diesem Gebiet w re gross Die Massnahmen m ssten mit dem Abteilungsleiter Softwareentwicklung definiert werden Ich denke dabei vor allem an folgende Optimierungen e Code Test und Dokumentation Guidelines erstellen e Aufbau einer Integrationsumgebung mit m glichst vielen Umsystemen e Weiterbildung der Software
81. elines Software Messung Metriken o Analyse von Fehlerrisiken und Testpriorisierung o Beispiele Komplexit t einer Funktion Methode Service etc Testen unter definierten Bedingungen zur Pr fung gegen spezifizierte Sollwerte auf den verschiedenen Testebenen Modul Integration Funktion Feature Abnahme mit dem Ziel Fehler zu finden Transferarbeit Urs Zihlmann Seite 60 LUZERN Technik amp Architektur C P C HOCHSCHULE bersicht Software Fehler Ziel Verst ndnis f r die Ursachen Folgen und Kosten von Software Fehlern vermitteln um m glichst gezielt testen zu k nnen Kernfrage Kennen wir heute die Ursachen unserer Software Fehler Fehlerursachen Zu den gr ssten Fehlerursachen geh ren Stress Termindruck und M ngel in der Kommunikation Die Fehlerentstehung kann durch eine zielgerichtete Entwicklungsplanung und ein ensprechendes Management begrenzt werden Weitere Fehlerquellen entstehen durch ein nicht konsequent umgesetztes Requirements Engineering Beispiele hierf r sind missverst ndliche Anforderungen unzutreffende Annahmen und fehlerhafte Spezifikation der Software Schnittstellen Qualit tsmassnahmen Die Qualit tsmassnahmen QM werden in konstruktive QM Fehlervermeidung und analytische QM Fehlerfindung unterschieden Dieses Kapitel besch ftigt sich ausschliesslich mit der Fehlerfindung Als Verifikationsmethoden werden Review Analyse Metriken und Test behandelt Fehlerkosten Eine fr he
82. ement Bug Lifecycle Inhalt einer Fehlermeldung o Identifikation der getesteten Software und Komponente des Testers und Testfalls Kurzbeschreibung Ausf hrliche Beschreibung der Abweichung oder des fehlerhaften Verhaltens Angaben zur Testumgebung Schweregrad des potentiellen Fehlers Weitere Informationen zur Reproduktion Lokalisierung und Behebung Logs Traces etc Transferarbeit Urs Zihlmann Seite 75 C C HOCHSCHULE LUZERN Technik amp Architektur Software Abnahmetest Bei den bisher beschriebenen Teststufen handelt es sich um Testarbeiten die in Verantwortung des Herstellers oder der entwickelnden Projektgruppe durchgef hrt werden bevor die Software an den Kunden bergeben wird Vor Inbetriebnahme der Software erfolgt nun als abschliessender Test ein Abnahmetest auf der Integrationsumgebung des Kunden Hierbei stehen die Sicht und das Urteil des Kunden im Vordergrund Der Abnahmetest ist unter Umst nden der einzige Test bei dem der Kunde direkt beteiligt und verantwortlich ist 10 Spezifikation Funktionaler amp nicht Softwareanforderungen funktionaler Test Software Architektur Software Integrationstest Software Design Software Modultest Software Quellcode Abbildung 32 Software Abnahmetest im V Modell Merkmale eines Software Abnahmetests Test unter Beteiligung des Auftraggebers und der Anwender der Software Test gegen die expliziten Anforderungen Spezifikation des Auftraggebers
83. en Echte Konflikte zeichnen sich dadurch aus dass das Ziel ist in einer Sache Recht oder Unrecht zu bekommen und damit als Sieger oder Verlierer dazustehen Wohingegen nach einer Panne durch Kl rung des Missverst ndnisses oder Entschuldigungen die Panne behoben ist Wiederholen sich Pannen oft scheint etwas Tieferes zugrunde zu liegen 177 Pannen allt gliche Missverst ndnisse oder Fehler bei denen es weder Sieger noch Verlierer und weder Schuldige noch Opfer gibt Konflikte haben eine Vorgeschichte es geht dabei um Recht oder Unrecht Sieg oder Niederlage Wichtige Anzeichen f r einen Konflikt 72 o _Kommunikationsbeziehung verschlechtert sich Verschiedene Vorstellungen ber gemeinsame Probleme entwickeln sich Entscheide werden auf Grundlage unvollst ndiger und falscher Informationen gef llt Wachsendes Misstrauen kleine Sticheleien und Feindseligkeiten Man streitet sich auf Nebenschaupl tzen Bei Problemen sucht man nach Schuldigen statt nach L sungen 135 Siehe http bildungsserver berlin brandenburg de fileadmin bbb unterricht faecher naturwissenschaften informatik didaktik_der_ infor matik rollen pdf 29 10 2013 136 Siehe http teamentwicklung lab de belbin teamrollen 29 10 2013 137 Siehe http www workforlife ch konfliktmanagement 30 10 2013 138 Kaspar 2012 S 18 139 Siehe http www workforlife ch konfliktmanagement 30 10 2013 Transferarbeit Urs Zihlmann Seite 10
84. en bereinstimmen Vollst ndige Information Die sechs W Fragen dienen als Vorgehensraster f r die Vorbereitung einer Mitteilung Was e Was ist das Informationsthema e Um was geht es Was ist die Situation die Ausgangslage das Problem oder die Entscheidung e Was ist nun zu tun Wer e Wer ist betroffen e Wer war der Urheber oder Ausl ser e Wer ist verantwortlich wer muss was tun e Wer bietet welche Unterst tzung Wozu e Welchem Zweck dient die Information Wann e Wann ist etwas passiert e Wann wird etwas passieren Wann ist mit weiteren Informationen zu rechnen Wie e Wie ist vorzugehen e Wie sind welche Vorgaben oder Spielregeln einzuhalten Wo e Wo ist etwas passiert e Wo wird etwas passieren Tabelle 4 Die sechs W Fraaen apbelle 4 DIE SECHS ech d Rhetorische Wir alle nutzen st ndig etliche der unterschiedlichen rhetorischen Stilmittel ohne es zu merken Eine der Hauptaufgaben dieser Mittel ist es Sachverhalte so zu vermitteln dass der Kommunikationspartner den Sinn so versteht wie wir ihn verstanden wissen wollen Die Betonung und die Satzstruktur spielen dabei ebenso eine Rolle wie der Inhalt selbst und oftmals werden die angewandten Techniken im Schreibstil oder in der Sprechweise nicht einmal bewusst wahrgenommen Die wichtigsten M glichkeiten per Rhetorik zu berzeugen sollen dies ndern 12 J ggi amp Z ger 2011 S 78 79 13 Siehe http kunst kultu
85. en Probleml sungsprozess deutlich verbessern Designaspekte im Projekt In diesem Bereich g be es noch grosses Optimierungspotential Dazu m ssten wir bei eMedia wie bereits angedacht ein Graphics Team zusammenstellen wobei die Leute in diesem Team aus verschiedenen Abteilungen stammen k nnten Matrix Organisation Bei neuen Projekten w rde jeweils eine Person aus diesem Team das Projekt begleiten und die grafischen und konzeptionellen Arbeiten ausf hren Bei einer Web Applikation w ren dies beispielsweise folgende Tasks e Produkt Erkennung Name Logo Slogan e Screen Design e Navigationsstruktur mit naming convention e Bedienungselemente Struktur und Art der Bedienung e Usability amp Accessibility e Ber cksichtigung weiterer Ausgabeger te Crossmedia Publishing e Vorlagen f r Dokumentationen und Marketing Unterlagen Die Leute im Graphics Team w ren Personen mit einer kreativen Ader und genau solche Leute sind auch bei Start Brainstormings gefragt Kreativit t verbindet man normalerweise mit Grafik Kunst aber auch f r ganz normale L sungsfindungen sind kreative K pfe bestens geeignet auch wenn sie ber keine vertieften Kenntnisse des zu erstellenden Produkts verf gen Ich denke hier besonders an die Maske 23 siehe oben Da ich eine grafische Vergangenheit als Mediendesigner und Fotograf habe w re ich sehr daran interessiert in einem solchen Team mitzuwirken Transferarbeit Urs Zihlmann S
86. en Rupp_RE_3A_WA paf 26 08 2013 82 Fr hauf IlI 2013 S 9 Transferarbeit Urs Zihlmann Seite 51 LUZERN Technik amp Architektur Lucerne University of Applied Sciences and Arts C DC HOCHSCHULE Merkmale einer guten Anforderung abgestimmt von allen Stakeholdern akzeptiert bewertet Wichtigkeit rechtliche Verbindlichkeit Priorit t eindeutig alle Leser interpretieren sie gleich konsistent Aussage ohne Widerspruch zu anderen Anforderungen pr fbar das Erf llen der Anforderungen kann nachgewiesen werden realisierbar innerhalb definierter Ranhmenbedingungen umsetzbar vollst ndig das was gefordert wird ist vollst ndig spezifiziert verst ndlich in Sprache Notation die dem Leserkreis gel ufig ist go a E 0 amp e Nat rlichsprachig dokumentieren Die Anforderungen werden oft unter Verwendung der nat rlichen Sprache dokumentiert Diese Art der Dokumentation ist vor allem f r nicht technische Leser geeignet und kann von allen Stakeholdern gelesen und verstanden werden Weil diese Texte h ufig mehrdeutig interpretierbar sind sollten gewisse Regeln f r den Satzaufbau eingehalten werden Zu vermeiden im freien Text o Redundanzen z B Floskeln wie Im Falle dass Sp t abends Nebens tze D o Mehrdeutigkeiten z B das selbe System ein sichtbares Signal Koppeln von Anforderungen Satz mit Ausnahmen z B ausser mit Ausnahme Schwafeln z B
87. en und Ressourcen einplanen Immer den kritischen Pfad im Auge behalten regelm ssige Meilensteinkontrolle Die ME ist wie ein Theater Die Erstauff hrung ist Monate im Voraus festgelegt und der Projektleiter ist der Regisseur T tigkeiten bei der Projektabschluss Phase Dokumentation erstellen Schulung End User und Support bergabe an Betrieb Know how Transfer Wissensdatenbank 171 Siehe http www mindtools com pages article newSTR_94 htm 13 12 2013 172 Siehe http www worldsites schweiz ch glossar produkt promotion placement preis htm 14 12 2013 Transferarbeit Urs Zihlmann Seite 128 Lucerne University of Applied Sciences and Arts HOCHSCHULE LUZERN Technik amp Architektur Lessons Learned Retrospektive Schlussabrechnung Terminierung der M ngelliste Abschlussbericht f r Stakeholder Kommunikation Newsletter Intranet Die Herausforderung ist dass diese Aufgaben auch wirklich umgesetzt werden auch wenn der Projektleiter bereits in neuen Projekten involviert ist Er sollte die Projektabschluss Phase initiieren und daf r sorgen dass f r diese Phase auch noch gen gend Budget und Zeit vorhanden sind A Ergebnisse und Erfolgsbewertung B Analyse u Bewertung F hrungsprozess C Konsequenzen f r Nachfolgeprojekte Projekt bergabe D Sicherstellung der Erfahrungen Definitive Projekt Abnahme erfolgreiche Projekte Definitiver Abgleich der Claims abgebrochene Projekte E Vertei
88. entwickler im Bereich Software Qualit t und Test driven Development e Die Tests sollen dokumentiert werden Transferarbeit Urs Zihlmann Seite 77 LUZERN Technik amp Architektur Lucerne University of Applied Sciences and Arts C DC HOCHSCHULE 7 VORGEHENSMODELLE BEI DER SOFTWAREENTWICKLUNG in jew Jeaeneamegg 20 09 Roman Lobsiger In den vorherigen Vorlesungen lag der Fokus jeweils auf der 14 11 2013 herk mmlichen Projektplanung sequentiell nach Phasen Roman Lobsiger zeigte uns auch die Vorteile von Agilen Frameworks In den praktischen bungen haben wir die Funktionsweise von solchen Methoden gleich versucht umzusetzen Die Einf hrungen in Scrum und XP warfen bei mir aber auch viele Fragen auf Was f r einen Einfluss hat das Arbeiten nach agilen Methoden auf die Software Qualit t Requirements Engineering oder auf die herk mmliche Projektplanung und Controlling Braucht es berhaupt noch eine Projektplanung wie wir es in den vorherigen Vorlesungen gelernt haben Gleichzeitig erkannte ich aber auch dass Scrum sehr gut zu unserer Abteilung passen w rde Nach diesem Unterricht und einigen gelesenen B cher zu Scrum war mir klar in welche Richtung meine Vertiefungsarbeit gehen w rde und dass sich die beiden Kapitel Projektplanung amp controlling und Vorgehensmodelle Softwareentwicklung zwar berschneiden aber auch gut erg nzen k nnen Mein einziger Kritikpunkt gilt leider auch in dieser Vor
89. er Entwicklungsabteilung gemeldet werden Dies behindert uns wiederum bei der Arbeit und der Entwicklung von neuen Projekten Nachdem das Projekt bergeben wurde und in Betrieb ist erscheint im w chentlichen hausinternen Newsletter einen Bericht mit den wissenswertesten Informationen und einem kurzen Interview mit den Projektbeteiligten Kundenzufriedenheit Weil unser gr sster Kunde SRF im gleichen Haus ist und wir eng miteinander in unterschiedlichsten Projekten zusammenarbeiten bekommt man rasch mit wenn der Kunde nicht zufrieden ist Wenn uns der Kunde seine Unzufriedenheit nicht direkt kommuniziert erfahren wir es sp testens an einem Ap ro oder auf der Piazza Kaffeebar Es kommt jedoch deutlich h ufiger vor dass der Kunde f r unser Produkt Werbung macht und dadurch neue Interessenten schafft Umsetzungsm glichkeiten im Betrieb In meiner Vertiefungsarbeit befasse ich mich mit der Einf hrung von Scrum anhand eines Projekts Bei Scrum findet am Ende jedes Sprints eine Retrospektive statt bei der es um die lessons learned innerhalb des Entwicklerteams geht Das Team reflektiert dabei jeweils die letzten drei Wochen und es werden sowohl die guten als auch die schlechten Fakten auf den Tisch gelegt Ziel ist es m glichst rasch aus den Fehlern zu lernen und m gliche Probleme aus dem Weg schaffen zu k nnen Sp testens in der n chsten Retrospektive sollte dann eine Verbesserung sichtbar sein Zum eigentlichen Projektabs
90. er Projektleiter auch selber Arbeitspakete ausf hrt und f r diese zust ndig ist Seite 18 C C HOCHSCHULE LUZERN Technik amp Architektur Projektvorbereitung Herausforderung Projektstart Jedes Projekt hat seine eigenen Herausforderungen Daher sollte bei jedem Projekt eine Auslegeordnung z B mit einer Kartenabfrage gemacht werden um welche Herausforderungen es sich handelt und welche die kritischsten sind Die gr ssten Herausforderungen bei einem Projektstart sind Gemeinsames Projekt und Zielverst ndnis Ist Problem verstehen Knowhow und Informationen beschaffen Umgang mit Widerst nden Risikomanagement Abh ngigkeiten und Komplexit t Projektorganisation und Rollen Ressourcen und Rahmenvorgaben Methoden und Tools Si ei N Enn ii Stakeholder Management Die Idee Ausgangspunkt f r das Projekt Bei jedem projektartigen Vorhaben steht zu Beginn die Idee die Mutter des Projektes Ideen zu entwickeln zu f rdern zu sichten und die besten daraus der Projektvorbereitung zuzuf hren ist die Aufgabe jeder einzelnen Organisationseinheit Anstoss f r ein bewusstes Ideen Management TI o Ideenreichtum und Kreativit tspotenzial aller Mitarbeiter aussch pfen Ideen systematisch erzeugen Kreativit tstechniken O o Markt und Kunden als Ideen Lieferanten nutzen o Ideen dokumentieren und zug nglich machen Phase 0 Der Prozess von der Idee bis zum klar umrissenen Projekt die Phase 0 ist
91. erden Allgemeine projektbegleitende T tigkeiten wie Projektverwaltung Projektdokumentation Hilfsdienste sollte man als eigene Aufgabe definieren Projektorganisation Die Projektorganisation ist ein Abbild der Projektstruktur sie bildet den Rahmen f r organisierte Projektarbeit innerhalb des Teams sowie gegen ber internen und externen Auftragnehmern Jedes Projekt erfordert eine massgeschneiderte flexible Projektorganisation mit klar definierten Rollen Verantwortungen und Rechten Bei der Wahl des geeigneten Projektleiters sind Kompromisse nicht zul ssig 7 Die Projektorganisation umfasst Team Struktur Projektorganisation Rollen im Projekt Verantwortung und Befugnisse Anforderungen an Projektleiter Projektorganisation designen Stakeholder Management Team Struktur F r die Bearbeitung eines Projektes ist in der Regel ein ganzes Projektteam erforderlich Den Mitgliedern des Teams wird die Verantwortung f r die Ausf hrung verschiedener Arbeitspakete oder ganzer Teilprojekte bertragen wobei nicht jeder Arbeitspaket Verantwortliche gleich Mitglied des 3 Burghardt 2012 S 182 31 Burghardt 2012 S 287 32 Scheuring 2013 S 70 33 Stania 2013 S 14 Transferarbeit Urs Zihlmann Seite 24 C C HOCHSCHULE LUZERN Technik amp Architektur Projektteams sein muss ber das Projektteam hinaus geh ren auch externe Dritte die bei einem Projekt aus fachlichen Gr nden oder zur Erg nzung der int
92. eresse des Kunden zu gewinnen Auf das Produkt aufmerksam machen e Werbung Internet Brosch ren e Empfehlung e Produkt erleben Das Interesse des Kunden steigern e _Ansprechendes Design e Probleml sung Effizienzsteigerung e _Statussymbol Marke Die Nachfrage steigern e Erfolgsstories erz hlen e Beeinflusser Presse Fachgremien e Attraktiv im Vergleich zu Mitbewerbern Kaufentscheidung e Online Shop one click buying e Vertriebspartner lokale Pr senz e Beratung Nutzen Probleml sung Tabelle 31 Markteinf hrung nach AIDA Transferarbeit Urs Zihlmann Seite 127 v C HOCHSCHULE LUZERN Technik amp Architektur Marketingstrategie Das Marketingkonzept legt die Vermarktungsstrategie fest und umfasst alle Aspekte der 4 P s Product Price Place Promotion e _Produktvariationen e Produktdifferenzierung e _Produktinnovation e _Produktelimination e _Kostendeckungspreis e Penetrationspreis e _Absch pfungspreis e Distributionskanal e Direktverkauf e _Indirekter Absatz e E Commerce Individualkommunikation e _Massenkommunikation e Marke e Corporate Identity Tabelle 32 Die 4 Dia Grunds tze der Markteinf hrung Die Herausforderung der Markteinf hrung ME ist dass nach den gesetzten Zielen alles zum vereinbarten Zeitpunkt bereit ist Reserven einplanen oft wird die Vorbereitung der ME untersch tzt Bei der Planung alle beteiligten Parteien fr hzeitig involvier
93. ern limitierten Kapazit ten mitarbeiten Die folgende Grafik zeigt die Komplexit t der Beziehungen zwischen Projektmitgliedern und teams und deren m glichen Interessenkonflikte auf Stakeholder N tragg b bi kt L nkungsau ee LD Start 7 Brainstorming men ti E Bremser und Verhinderer Abbildung 5 Projekt Stakeholder und ihre m glichen Mehrfachrollen Projektorganisation Grunds tzlich verbleiben die Arbeitspakete von Routinefunktionen in der Linienorganisation w hrend innovative Aufgaben sowie die Projektleitungsfunktionen innerhalb der Projektorganisationen abgedeckt werden Projekt Kunstausstellung Datum 8 4 07 Intern Extern Beteiligte Beteiligte Auftraggeber Stifftungsvorstand Sponsoren Projektleiter R Schmidt WR Assistenz K nstler A Pichler EU U Ressort j Mitglieder Lieferanten e Logistik Austellung Marketing amp PR Event Agentur S Pitschi C Columna P Mahlzahn _ Medien Abbildung 6 Projektorganisation 34 Scheuring 2013 S 70 3 Scheuring 2013 S 71 38 Scheuring 2013 S 73 Transferarbeit Urs Zihlmann Seite 25 C C HOCHSCHULE LUZERN Technik amp Architektur Zur Darstellung der Projektorganisation eignet sich das Projektorganigramm nach Scheuring Neben den Projektteam Mitgliedern werden darin die weiteren ins Projekt eingebundene
94. es Gegen bers zu erfassen und auf den Punkt zu bringen M gliche usserungsformen Darf ich kurz wiedergeben was ich von dir geh rt habe Ich verstehe dich so dass Gef hle verbalisieren Ich spreche aus welche Gef hle ich beim Gegen ber wahrnehme M gliche usserungsformen Und nun sind Sie entt uscht und verletzt Tods nden Als Tods nden bezeichnet Kornelia von Vacano gewisse Verhaltensweisen welche fast schon automatisch zu Missverst ndnissen rger Frust und Gespr chsabbr chen f hren Tods nden in der Kommunikation 1 Herablassung zeigen 2 Aktive und passive St rsignale setzen 3 Killerphrasen einbringen J ggi amp Z ger 2011 S 28 7 J ggi amp Z ger 2011 S 29 8 Von Vacano 2001 Transferarbeit Urs Zihlmann Seite 10 v C HOCHSCHULE LUZERN Technik amp Architektur Feedback Gespr ch Der Zweck von Feedback Im Umgang mit Menschen m sste uns wichtig sein zu erfahren ob uns das Gegen ber so verstanden hat wie wir es gemeint haben Wir m chten auch wissen wie wir wahrgenommen werden In einem sogenannten Feedback melden wir dem Gespr chspartner was wir verstanden und wahrgenommen haben Ausserdem dient das Feedback dazu die Codierung der Gespr chspartner aufeinander abzustimmen Missverst ndnisse in der Kommunikation aufzudecken M glichkeiten zur Korrektur zu erkennen und den weiteren Gespr chsverlauf zu steuern
95. et genug dass sich daraus die n chsten Schritte ableiten lassen Risiken Projektrisiken k nnen alle Phasen eines Projekts betreffen und in allen Phasen auftreten Wie erkennt man Risiken Eine Anforderung wird immer wieder verschoben warten auf ein Wunder oder einen Selbstheilungsprozess Die Anforderungen sind weder klar noch verst ndlich Keine Erfahrungswerte und fehlendes Knowhow Ist es berhaupt machbar Das Wissen wird nur von einer einzigen Person getragen Tipps f r den Umgang mit Risiken und Unsicherheiten im Projekt Planen Sie Puffer Zeit und Budget f r Risiken ein Beziehen Sie immer den Auftraggeber mit ein Legen Sie sich einen Plan B zurecht falls Plan A nicht realisierbar sein sollte Vermeiden Sie das Hinausschieben von Anforderungen Definieren Sie einen Zeitpunkt bis wann Klarheit ber das Risiko bestehen muss 52 Geirhos 2011 S 34 Transferarbeit Urs Zihlmann Seite 35 inc Lucerne University of Applied Sciences and Arts HOCHSCHULE LUZERN Technik amp Architektur 3 GEMEINSAMES PROJEKTVERST NDNIS pew Jaen Jomes 14 06 2013 14 06 2013 15 06 2013 Roland Haas Martin Iseli Thomas Haas Roland Haas Transferarbeit Urs Zihlmann Der praxisorientierte Unterricht von Roland Haas zum Thema Probleml sungsprozess gab mir wertvolle Tipps rund um dieses anspruchsvolle Thema Die Gruppen bung Planung eines sozialen Team Anlasses hat gezeigt dass eine Entsch
96. f nf Schritten 165 Siehe http www buchhandel de WebApi1 GetMmo asp Mmold 1635663 amp mmoType PDF 15 12 2013 166 Siehe http www palisade com risk de monte Carlo simulation asp 15 12 2013 167 Siehe http wst univie ac at topics RisikoManagement index php m D amp t info amp c show amp CEWebS what P ERT 32 28Program 32 Evaluation 32 and 32 Review 32 Technique 29 15 12 2013 Transferarbeit Urs Zihlmann Seite 114 C C HOCHSCHULE LUZERN Technik amp Architektur Transfer in die betriebliche Umgebung Wie machen wir es heute Projekt Erfolgsmanagement Wir f hren in unserer Abteilung kein Projekt Erfolgsmanagement PEM durch wie wir es in der bung praktiziert haben F r mich als Projektleiter ist es selbstverst ndlich dass ich mich mit solchen Fragen Siehe PEM Fragenkatalog auseinandersetze auch wenn ich meine Erkenntnisse nicht auf Papier niederschreibe und in sp teren Projektphasen wieder herbeiziehe um R ckschl sse zu ziehen Wenn ein anderes Projekt zu einem hnlichen Thema bereits gescheitert ist w rde es mich als Projektleiter auf jeden Fall interessieren was die Gr nde f r das Scheitern waren Solche Abkl rungen geh ren f r mich genauso zu einem erfolgreichen Projektstart wie das Wissen um zus tzliche Nutzer Claim Management Das Claim Management war f r mich bisher noch kein Thema Das liegt m glicherweise daran dass wir f r die meistens internen Kunden mit Standardvertr
97. f Counselling Psychology 31 1967 S 248 252 Transferarbeit Urs Zihlmann Seite 8 pc Lucerne University of Applied Sciences and Arts HOCHSCHULE LUZERN Technik amp Architektur Dazu geh ren Gef hle Emotionen innere Werte Pr gung ngste verdr ngte Konflikte und Pers nlichkeitsmerkmale Man geht davon aus dass weit mehr Entscheidungen auf der Beziehungsebene als auf der Sachebene gef llt werden Grundhaltung Das Verhalten l sst sich einfacher ndern als die Einstellung Ausdruck der Grundhaltung Was hat die Reaktion mit meinem Verhalten zu tun Die Grundhaltung der gegenseitigen Wertsch tzung Ich bin ok du bist o k beeinflusst das Gespr chsklima die Beziehung der Gespr chspartner und den Gespr chsverlauf positiv Sie ist eine wichtige Voraussetzung f r ein erfolgreiches Gespr ch Offene Diskussion Offene Kritik Entspannte Atmosph re Reger Gedankenaustausch Viele Fragen Z gige Abwicklung Fehler d rfen sein Humor e Viele Killerphrasen Provokationen Schuldzuweisungen Zurechtweisungen Abwertungen Viele Unterbrechungen Pers nliche Bewertungen Macht aus ben Tabelle 1 Ausdruck der Grundhaltung ich bin ok du bist o k Fragetechnik Gedr ckte Atmosph re Wenige R ckfragen Verdeckte Kritik Passivit t Abwarten Fehler d rfen nicht sein Sich unterordnen Konfliktvermeidung Ja Sager Abwerten der Gruppe Obstruktives Verhalten Apathie Chaotische Dis
98. ftware Modultest Software Quellcode Abbildung 28 Funktionaler amp nicht funktionaler Test im V Modell Die Software wird als Black Box betrachtet Dem Tester muss die interne Programmstruktur nicht bekannt sein weshalb funktionale Tests in der Regel auch von speziellen Test Teams durchgef hrt werden Testmethoden quivalenz Grenzwert Zustand Ein Test mit allen m glichen Eingabedaten und deren Kombinationen w re ein vollst ndiger Test Dies ist aber wegen der grossen Zahl von m glichen Eingabewerten und Kombinationen unrealistisch F r eine sinnvolle Auswahl der m glichen Testf lle gibt es mehrere Verfahren die im Folgenden vorgestellt werden quivalenzklassenmethoden Bei den quivalenzklassenmethoden werden alle m glichen Eingabe und Ausgabedaten in g ltige und ung ltige Klassen zerlegt Man geht bei dieser Methode davon aus dass alle Werte einer Klasse ein identisches funktionales Verhalten der Software verursachen 101 Spillner amp Linz 2004 S 98 Transferarbeit Urs Zihlmann Seite 72 LUZERN Technik amp Architektur C Lk C HOCHSCHULE Beispiel f r die Pr fung eines Wertebereichs Tage des Monats 2 stellig o G ltige Klasse 01 28 Ung ltige Klassen 00 32 99 o _Sonderbehandlungen 29 30 31 Grenzwertanalyse Die Grenzwertanalyse identifiziert und testet die Werte an und auf den Grenzen der g ltigen und ung ltigen quivalenzklassen Denn Fehlerzust nde in Programme
99. gen Trotzdem konnte ich viel profitieren und habe nach diesen drei Bl cken das Gef hl dass ich zumindest die Grundlagen des Software Qualit tsmanagements verstanden habe Der Unterrichtsstil von Sven Koos kam mir entgegen Das hohe Tempo und die vielen Folien machten es zwar nicht einfach dem Unterricht zu folgen aber sein Stil seine Sprache und seine Art zu sprechen empfand ich als sehr angenehm Man merkte dass Sven Koos aus der Praxis kommt und sich jeden Tag mit diesen Themen besch ftigt Unsere Fragen konnte er kompetent beantworten und mit passenden Beispielen aus der Praxis untermauern F r die Zusammenfassung habe ich mich an die Unterlagen aus dem Unterricht gehalten Seite 58 C C HOCHSCHULE LUZERN Technik amp Architektur berblick der Module Testwerkzeuge auf A Review als Verifikationsmethode Review der Software D iere Typen Durchf hrung Rollen Spezifikation Template und Checkliste Software Abnahme als Quality Gate D X Fehler Ursachen Folgen Fehlerkosten Review von Software Testprinzip schrie und Sie A femplate und Checkliste bersicht Software Verifikation vs Verifikation Validierung Entwicklungsmodelle V Modell als Basis Modul VI Software eisechiieeeng Testpriorisierung Risikoanalyse auf Basis von Software Metriken Jemen Kosten vs Zeit vs Qualit t Verifikationsmethode Vertikale Traceability Analyse tmetl Software Luk Qualit t Coding Standards amp Modul Il
100. gen der SRG arbeiten Risikomanagement eMedia betreibt bisher kein Risikomanagement Das liegt einerseits daran dass wir selten an Grossprojekten mit entsprechend grossen Risiken arbeiten und andererseits daran dass es prim r interne Projekte mit eher geringen Risiken sind Das gr sste Risiko sehe ich bei Abg ngen von Mitarbeitern so dass das Wissen rund um Projekte Software Tools und Infrastruktur verloren gehen k nnte Dieses Risiko betrifft nicht nur einzelne Projekte sondern die ganze Abteilung bzw Firma Ein Negativbeispiel gab es vor zwei Jahren in der IT Abteilung wo innert kurzer Zeit einige Mitarbeiter gek ndigt hatten Die Folge war dass wir unser System berwachungssystem und weitere Services nicht mehr betreiben konnten da niemand die Systeme kannte Dieses Risiko war eindeutig untersch tzt worden und es dauerte viele Monate bis wir die Abg nge und deren Wissen kompensieren konnten Umsetzungsm glichkeiten im Betrieb Projekt Erfolgsmanagement Beim Projekt Erfolgsmanagement w rde das Start Brainstorming zum Thema Maske 23 nicht nur zum Beginn eines Projekts sondern auch w hrend eines Projekts immer wieder angewendet Ich kann mir gut vorstellen je nach Projekt ein iteratives Brainstorming im Team zu machen Eine gr ssere Herausforderung als das Brainstorming an sich w re vermutlich die neuen Informationen ins Projekt einfliessen zu lassen ohne das Projekt auf den Kopf zu stellen Transferarbeit Urs Z
101. generierung anpassen 31 05 2013 10 55 1350 Feature New Normal Tr geretikettendruck integrieren Abl sung MAZ Kartenprogramm 17 05 2013 14 41 1346 Feature New Normal Erweiterung MC Log 16 05 2013 15 55 1345 Feature New Normal Anpassung Verantwortliche Personen 16 05 2013 15 51 Abbildung 16 Anforderungen im redmine Das modellbasierte Dokumentieren findet wenn berhaupt nur bei Grossprojekten in Form von Skizzen statt Diese dienen allerdings nur als Planung f r die Entwicklung z B in Form eines Klassendiagramms und nicht als Massnahme des Requirements Engineerings Eine Abnahme der Anforderungen wurde bisher noch nicht praktiziert Umsetzungsm glichkeiten im Betrieb Optimierungsbedarf sehe ich vor allem bei der Vorbereitung des Requirements Engineerings Mir f llt auf dass Kunden grosse M he haben Anforderungen zu stellen wenn noch kein Produkt vorhanden ist Zum einen hat dies damit zu tun dass der Kunde sich erst am Requirements Meeting zum ersten Mal mit den Anforderungen befasst und in der Regel dann auch keine n tzlichen Informationen herauskommen Andererseits w rden solche Voraussetzungen f r SCRUM sprechen welches wir bisher noch nicht oder zumindest nicht konsequent einsetzen Unabh ngig von den eingesetzten Entwicklungsmethoden m ssen wir in Zukunft unbedingt sicherstellen dass sich der Kunde im Voraus Gedanken macht und in seinem Team die Anforderungen sammelt bevor das erste Requirments Meeting sta
102. hitektur gew hlt werden muss welche Interfaces geschrieben werden sollen ob bereits Test Cases erstellt und geschrieben werden sollen kurz Sie besprechen detailliert was getan werden muss Am Ende dieses Meetings liegt eine Liste aller notwendigen Aufgaben vor Das Sprint Backlog Timebox 15 Minuten Verantwortlicher Team Teilnehmer Team ScrumMaster G ste z B von anderen Scrum Teams Output am Ende Das Team weiss was heute zu tun ist Jeden Tag treffen sich die Teammitglieder zur gleichen Zeit am selben Ort f r 15 Minuten zu einem vom ScrumMaster moderierten Meeting In diesem Meeting sprechen sich die Teammitglieder ab wer an diesem Tag welche Aufgabe bernimmt Dabei w hlen die Teammitglieder selbst die Aufgabe aus die sie als N chstes bernehmen wollen Die Teammitglieder informieren den ScrumMaster ber Blockaden und Probleme damit dieser so schnell wie m glich zu deren L sung beitragen kann Das Daily Scrum sollte nicht l nger als 15 Minuten dauern In der Regel findet es direkt am Scrum Board statt Jedes Teammitglied beantwortet kurz drei Fragen 1 Was habe ich seit dem letzten Daily Scrum getan 2 Was hat mich dabei behindert 3 Was werde ich bis zum n chsten Daily Scrum tun ation Mee Estin N gt Iransferarbeit Urs Z hlman Lucerne University of Applied Sciences and Arts HOCHSCHULE LUZERN Technik amp Architektur 2 Stunden Product Owner Team Product Owner Aktualisier
103. hkeiten im Betrieb 31 Transferarbeit Urs Zihlmann Seite 2 C C HOCHSCHULE LUZERN Technik amp Architektur 3 GEMEINSAMES PROJEKTVERST NDNIS 36 PROBLEML SUNGSPROZESS_ 37 Situationsanalyse 37 Zielfindung 38 L sungssuche 39 Bewertung der L sungen 39 Entscheid 40 DESIGNASPEKTE IM PROJEKT ll 40 Industriedesign als Probleml sungsprozess 40 Kreativit t 41 le machen wir es neute Umsetzungsm glichkeiten im Betrieb 43 4 PROJEKTPLANUNG UND CONTROLLING 44 VERTIEFUNGSARBEIT 0000000020000 aa 5 REQUIREMENTS MANAGEMENT INFORMATIK 45 ZWECK UND INHALT 45 WARUM IT PROJEKTE SCHEITERN 46 KOMMUNIKATIONSPROBLEME 47 ANFORDERUNGSERHEBUNG 48 ANFORDERUNGEN ERMITTELN 0000000000000 48 Quellen der Anforderungen 48 Erhebungstechniken 49 ANFORDERUNGEN DOKUMENTIEREN 50 Nat rlichsprachig dokumentieren 52 Modellbasiertes dokumentieren 53 Verhaltensperspektive 54 Nichtfunktionale Anforderungen spezifizieren 54 ANFORDERUNGEN FROEN 55 Validieren 55 Verifizieren 55 ANFORDERUNGEN VERWALTEN 55 ANFORDERUNGEN AN DEN REQUIREMENTS ENGINEER 55 TRANSFER IN DIE BETRIEBLICHE UMGEBUNG 000000000 56 Wie machen wir es heute 56 Umsetzungsm glichkeiten im Betrieb 57 6 SOFTWARE QUALIT T 58 BERBLICK DER MODULE 59 VERIFIKATION VON SOFTWARE ANFORDERUNGSSPEZIFIKATIONEN ll 60 Grundlage Software Verifikation 60 Review als Verifikationsmethode 61 Entwicklungsmodelle 63 SOFTWARE QUELLCODE 64 Transferarbeit Urs Zihlmann Seite 3 C C HOCHSCHULE LUZERN
104. i der Einstufung eines Konflikts geht es darum die Symptome festzustellen und zu bewerten Damit wird die Grundlage f r die Entwicklung von L sungsstrategien geschaffen denn die am Konflikt Beteiligten m ssen dort abgeholt werden wo sie aktuell stehen Auch geht es darum zu verhindern dass die Konfliktparteien eine Stufe weiter geraten Eskalationstreppe Friedrich Glasl Die neun Stufen sind in drei Phasen mit jeweils drei Stufen unterteilt win win Wohlergehen aller Beteiligten win lose Gewinner Verlierer Situation und schlussendlich nur noch lose lose beide verlieren Ab der zweiten Phase sollte eine professionelle Unterst tzung z B eines Moderators hinzugezogen werden und ab der dritten ein Mediator oder vielleicht sogar ein Richter 1 win win win lose lose lose Abbildung 47 Konflikteskalation nach Glasl Die Steigerung der Konfliktintensit t erfolgt stufenweise Jede Stufe wird durch einen Wendepunkt markiert der von der Konfliktpartei als kritische Schwelle erlebt wird Die drei beschriebenen Phasen lassen sich weiter unterteilen nach Friedrich Glas gibt es insgesamt neun Eskalationsstufen 148 Siehe http www workforlife ch konfliktmanagement 30 10 2013 14 Kaspar 2012 S 43 150 Glasl 2004 Transferarbeit Urs Zihlmann Seite 105 d 1 Verh rtung 2 Debatte 3 Taten 4 Koalititonen 5 Demaskierungen 6 Drohstrategien 7 Begrenzte Vernichtungsschl ge 8 Zersplitterung 9
105. ie zu einem reifen effektiven Team wird 170 129 Kaspar II 2013 S 1 130 Strobel 2003 S 10 Transferarbeit Urs Zihlmann Seite 97 Lucerne University of Applied Sciences and Arts HOCHSCHULE LUZERN Technik amp Architektur 12 6 Abbildung 43 Teamentwicklungsuhr nach Tuckman In seiner Teamuhr unterscheidet Bruce W Tuckman vier Phasen die Teams regelm ssig durchlaufen ideenreich h flich flexibel unpers nlich offen gespannt leistungsf hig vorsichtig solidarisch und hilfsbereit Entwicklung neuer Umgangsformen unterschwellige Konflikte Entwicklung neuer Verhaltensweisen Konfrontation der Person en Feedback Cliquenbildung Konfrontationen der Standpunkte m hsames Vorw rtskommen Gef hl der Ausweglosigkeit Tabelle 20 Teamentwicklungsuhr nach Tuckman 131 Tuckman 1965 Transferarbeit Urs Zihlmann Seite 98 pc Wie lange ein Team in einer Phase ist unterscheidet sich je nach Team und dessen F hrung Das Ziel ist ein Team m glichst rasch in die performing Phase zu bringen In einer Scrum Umgebung w re dies die Aufgabe des ScrumMasters Jede nderung im Team bewirkt dass es wieder in der Phase 1 startet Das Tuckman Phasenmodell hilft Teams und F hrungskr ften dabei o Teambuilding zu erleichtern und Orientierung zu erhalten zu verstehen wie wichtig konstruktiv gef hrte Konflikte sind Lucerne University of Applied Sciences and Arts HOCHSCHULE LUZE
106. ieren Einerseits ist er sehr zackig und kommt schnell auf den Punkt andererseits schaffte er es aus meiner Sicht nicht eine angenehme und lernf rderliche Stimmung aufzubauen wie es z B bei Gabriele Kaspar oder auch bei vielen anderen Dozenten der Fall war nderungen managen nderungen in Projekten sind W nsche oder Erfordernisse die in den Projektzielen nicht vorgesehen sind und die im aktuellen Projektplan nicht ber cksichtigt wurden Werden diese W nsche umgesetzt erfordert dies eine Anpassung des Projektplans nicht selten aber auch eine Anpassung der Projektziele 77 Aufgaben f r ein wirksames nderungswesen o geordnetes Erfassen von nderungsw nschen und erfordernissen 157 Scheuring 2013 S 128 129 Transferarbeit Urs Zihlmann Seite 110 v C HOCHSCHULE LUZERN Technik amp Architektur Regelung der Prozesse und Zust ndigkeiten f r deren Beurteilung und Umsetzung Einf hrung eines sogenannten Design Freeze des Einfrierens der Spezifikationen oder technischen Konzepte Dokumentation der nderungen Projekt Erfolgsmanagement Das Projekt Erfolgsmanagement PEM beginnt bereits in der Projektvorbereitung und wird in den sp teren Phasen weitergef hrt Ein zentraler Punkt beim PEM ist die Maske 23 welche auch ein wichtiger Bestandteil des Start Brainstormings ist Beim PEM wird diese Methode jedoch immer wieder angewendet und nicht nur in der Startphase des Projekts Erfolgsm
107. iert sich auf die wichtigen Anspruchsgruppen und verliert sich nicht in der Breite Ein Projekt darf sich nicht durch die Liste m glicher negativer Stakeholder l hmen lassen Stakeholder Management zwingt dazu den Projektnutzen klar herauszuarbeiten und zu kommunizieren Stakeholder sollten sich verstanden und ernst genommen f hlen Stakeholder Management hat sehr viel mit Beziehungsarbeit zu tun Das Stakeholder Management ist eine permanente Projektmanagement Aufgabe Wie machen wir es heute A N o Ein Projekt beginnt bereits vor dem Projektauftrag und diese allerersten Schritte wie in diesem Kapitel beschrieben werden bei uns noch nicht konsequent durchgef hrt Ich war schon bei einem Projekt dabei bei dem ein gemeinsames Start Brainstorming ein Brainstorming zu allen Themen durchgef hrt wurde aber in der Regel finden solche Projektvorbereitungen nicht statt Stattdessen wird der Projektauftrag von einer Person Steuerungsmitglied Auftraggeber oder Projektleiter erstellt und im Kick Off Meeting dem ganzen Projektteam vorgestellt Der Projektauftrag wird mit dem Feedback aus dem Kick Off erg nzt woraus die finale Version entsteht Dieses Dokument wird vom Auftraggeber Steuerungsausschuss und Projektleiter unterzeichnet Ein Projektstrukturplan wie wir ihn im Unterricht kennengelernt und angewendet haben wurde zumindest in unserer Abeilung bisher noch nicht erstellt Da wir Projekte gr sstenteils selber
108. ierten Rollen Verantwortung durch die Gruppe f r die Qualit t des gepr ften Arbeitsproduktes Dauer mindestens 15 des Erstellungsaufwandes Planung Reviews m ssen geplant werden Verantwortlich ist der Autor Tracking Ergebnisse des Reviews m ssen konsequent bearbeitet dokumentiert werden Nutzen Fr hzeitige Reviews sparen Kosten in nachfolgenden Entwicklungsphasen Die folgende Grafik gibt einen Anhaltspunkt wann welcher Review Typ eingesetzt werden soll Document Control hoch Intensive Inspection Erfahrung der Reviewer mittel gering Komplexit t des Arbeitsproduktes Abbildung 20 Formale Review Typen Situationen und Anwendungen Transferarbeit Urs Zihlmann Seite 62 LUZERN Technik amp Architektur C P C HOCHSCHULE Document Control Document Control wird bei bekannten Aufgabenstellungen mit geringer Komplexit t angewendet Da es die einfachste Form eines Reviews ist wird sie am h ufigsten eingesetzt Vorgehen 1 Die Reviewer pr fen einzeln das Arbeitsprodukt 2 Die Findings werden in Review Protokollen festgehalten und an den Autor gesendet 3 Der Autor fasst die Findings zusammen und l dt zum Review Meeting ein 4 Im Review Meeting werden die Findings diskutiert und Entscheidungen getroffen Fehler Hinweis Zur ckweisung Der Autor erstellt ein Review Protokoll Der Autor dokumentiert den Erledigungsstand der berarbeiteten Arbeitsprodukte Der Autor publiziert das abgeschl
109. igerung Strategieumsetzung IST Zustand Ausgangslage und Problemstellung Ziele Erwarteter Nutzen Nicht Ziele Abgrenzung Rahmenbedingungen Schnittstellen Abh ngigkeiten Meilensteine Termine Organigramm Rollenbeschreibung Kosten amp Ressourcen 24 Scheuring 2013 S 59 235 Geirhos 2011 S 50 51 Transferarbeit Urs Zihlmann Seite 22 LUZERN Technik amp Architektur Lucerne University of Applied Sciences and Arts v DC HOCHSCHULE Projektstrukturierung Unter Projektstrukturierung versteht man das Zerlegen des Projektes in klar fassbare und eindeutig abgrenzbare Bausteine Die Dimension und Komplexit t des Projektes wird damit auf berschaubare so genannte Arbeitspakete reduziert Zweck der Projektstrukturierung Festlegen der internen und externen Projektorganisation Zuteilung der Aufgaben an die Projektbeteiligten Projektablauf und Teminplanung Aufwandsch tzung und Kostenplanung Ressourceneinsatz Planung Kostenplanung Berichterstattung Projektdokumentation und Ablageorganisation Nicht nur das Projekt soll strukturiert werden sondern auch die gesamte Projektplanung und f hrung Dazu geh ren auch die Projektrahmenbedingungen und die Strukturierung des Planungsablaufs Projektstrukturplan Die aufgabenm ssige Gliederung des Projekts wird im Projektstrukturplan PSP festgelegt er enth lt alle Projektaktivit ten die in den einzelnen Entwicklungsphasen durchzuf hren s
110. ignete Personen benennen max 8 Personen o Auftraggeber Steuerungsgruppe Projektleiter Know how Tr ger Endbenutzer amp Beschaffungsteam nimmt T tigkeit auf e Kosten und Zeitrahmen f r Durchf hrung der Evaluation definiert e Ressourcen und Kapazit ten erfassen e Evaluationsvorgang planen e kosten der Planungseinheiten absch tzen e Genehmigter Kostenrahmen und Terminplan D D 5 5 Anforderungen ermitteln e Anforderungen an die Software und an den Lieferanten schriftlich festlegen IST Zustand erfassen Allgemeine und softwarespezifische Checklisten konsultieren Workshops mit Business Seite durchf hren Anforderungskatalog erstellen o Nach Detailgrad strukturieren umgekehrte Pyramide erm glicht schnellen Ausschluss mit geringem Aufwand o Muss und Kann Anforderungen separieren e Ausgef llter Anforderungskatalog Transferarbeit Urs Zihlmann Seite 119 C C HOCHSCHULE LUZERN Technik amp Architektur Beispiel ERP System Bei der Evaluation eines ERP Systems w rden sich die Anforderungen beziehen auf Funktionen Daten Mengen max Kosten Performance Bedienung Sicherheit und Kompatibilit t Konfigurationsaufwand Anpassungsaufwand Investitionssicherheit Qualit t Serviceleistungen Die Bereiche der Anforderungen k nnen unterteilt werden nach Functional Fit So wenig Funktionalit t wie m glich so viel Funktionalit t wie n tig Flexibility Integra
111. ihlmann Seite 115 pc Lucerne University of Applied Sciences and Arts HOCHSCHULE LUZERN Technik amp Architektur In der Softwareentwicklung werden wir das n chste gr ssere Projekt MediaConnector Phase Il mit Scrum versuchen umzusetzen Bei Scrum w re das Projekt Erfolgsmanagement Teil der beiden Events Retrospektive und Sprint Planning Wir analysieren dabei den letzten Sprint und erhalten gleich die Gelegenheit es beim n chsten Sprint besser zu machen Bei Scrum besteht weniger die Gefahr dass die Vision und die Projektziele aus den Augen verloren werden weil sich das Team im 3 Wochen Rhythmus trifft und das Projekt bespricht Mit dabei sind auch der Product Owner und der Scrum Master Die oben erw hnten Risiken bez glich Abg ngen von Mitarbeitern versuchen wir zu vermeiden indem mehrere Personen im Team an Projekten arbeiten und weniger Einzelprojekte verrichtet werden Einen weiteren Optimierungsbedarf sehe ich bei den Dokumentationen Dabei m ssen insbesondere nderungen an Projekten nachgef hrt werden so dass die Dokumentationen auf dem gleichen Stand sind wie die Software F r ein aktuelles Projekt bei dem ich Projektleiter bin habe ich anhand der Vorlage von Scheuring die Risiken und deren Auswirkungen versucht zu eruieren Die folgende Tabelle zeigt einen kleinen Auszug der Risiko Bewertungstabelle Ereignis Kosten f r Storage werden durch PostProduction nicht getragen K
112. ik amp Architektur Test Scenarios New User Story Requirements Project Velocity ee ES E Release Plan Latest Version Customer Approval Uncertain Confident Estimates Estimates Next Iteration Abbildung 40 Extreme Programming XP Scrum Im Gegensatz zu XP findet man bei Scrum keinen Schwerpunkt auf technische Praktiken Scrum legt deutlich mehr Wert auf die geregelte Zusammenarbeit in selbstorganisierten Teams Es definiert dazu drei Rollen vier Meetings und drei Artefakte Um Scrum erfolgreich in der Praxis umzusetzen ben tigt man gute Entwicklungstechniken z B die aus XP bekannten technischen Praktiken Lean und Kanban Neben der agilen Bewegung hatte sich ein anderer Trend in die Softwarebranche bewegt der urspr nglich aus dem Management von Produktionsunternehmen Toyota stammt Kanban ist eine Change Management Methode mit wenigen Vorgaben Dazu geh ren das Visualisieren des Arbeitsablaufs das Limitieren des WIP work in progress und das Messen der Durchlaufzeit um ein Arbeitspaket abzuschliessen cycle time Im Gegensatz zu agilen Vorgehensweisen beschr nkt sich Kanban nicht auf eine Iteration sondern kennt viele Iterationen in denen verschiedene Aktivit ten geschehen Der Begriff Scrum kommt aus dem Rugby Sport und bedeutet Gedr nge Gemeint ist die im Rugby bliche Bewegung des gesamten Teams als Einheit um den Ball aus der eigenen Seite hinauszudr ngen
113. ilt Sprint Planning 1 Sprint Planning 2 Daily Scrum Estimation Meeting Sprint Review und Sprint Retrospektive 17 Sprint Planning 1 Timebox 4 Stunden oder 1 Stunde pro Sprint Woche Verantwortlicher Product Owner Teilnehmer Team ScrumMaster Product Owner Output am Ende Selected Product Backlog 122 Siehe http borisgloger com scrum scrum flow rollen 10 10 2013 1233 Siehe http borisgloger com scrum scrum flow meetings in scrum 13 10 2013 Transferarbeit Urs Zihlmann Seite 88 LUZERN Technik amp Architektur Lucerne University of Applied Sciences and Arts r DC HOCHSCHULE In diesem ersten Meeting eines Sprints sind der Product Owner das Team und der ScrumMaster anwesend Der Product Owner erl utert die Product Backlog Items und definiert gemeinsam mit den Teammitgliedern das Ziel f r den anstehenden Sprint Dann werden die Backlog Items ausgew hlt die zu diesem Ziel passen und die das Team schaffen kann So entsteht das Selected Product Backlog Wichtig Das Team alleine bestimmt wie viele Backlog Items es ausw hlt nt Dlann nn 9 nt F lanning L Timebox 4 Stunden oder 1 Stunde pro Sprint Woche Verantwortlicher Team Teilnehmer Team ScrumMaster Product Owner sollte abrufbar sein Output am Ende Sprint Backlog Hier planen die Teammitglieder wie sie das im Sprint Planning 1 Meeting vereinbarte Ziel erreichen wollen Dazu beraten sie miteinander wie die Applikation aufgebaut sein soll welche Arc
114. ind Der PSP bildet das Fundament f r die gesamte Projekt und Produktplanung sowohl f r die Planung der Termine Kosten und Einsatzmittel als auch f r die Festlegung der Leistungsmerkmale Von ihm gehen alle wesentlichen Projektpl ne aus er bildet damit auch die Basis f r die Auftragserteilung und die sp tere Projektkontrolle Zum Erstellen eines Projektstrukturplans geh ren folgende Schwerpunkte gt o Sammeln aller durchzuf hrenden Aktivit ten o Anordnen in einer hierarchischen Struktur o Definieren der Arbeitspakete 26 Scheuring 2013 S 62 27 Stania 2013 S 22 8 Burghardt 2012 S 182 29 Burghardt 2012 S 285 Transferarbeit Urs Zihlmann Seite 23 LUZERN Technik amp Architektur Lucerne University of Applied Sciences and Arts C DC HOCHSCHULE Arbeitspakete Der Grad der Detaillierung des PSP h ngt von der Gr sse und Komplexit t des Projekts ab Die auf der untersten Ebene nicht weiter aufgeteilten Aufgaben also die Endpunkte der Struktur stellen die Arbeitspakete dar 7 Beim Spezifizieren der Aufgaben sollten einige Regeln beachtet werden Bereichs berschreitende Aufgaben sind zu vermeiden besser ist eine zus tzliche Aufgabenteilung Jede Aufgabe kann wohl mehrere Bearbeiter sollte aber immer nur einen Verantwortlichen haben Eine Aufgabenplanung sollte vollst ndig sein und sei es mit Hilfe von Platzhaltern Jede Aufgabe muss in ihrem Arbeitsvolumen genau beschrieben w
115. inder de morphological charts s1 14 07 2013 Scheuring 2013 S 176 177 Transferarbeit Urs Zihlmann Seite 39 LUZERN Technik amp Architektur Lucerne University of Applied Sciences and Arts C DC HOCHSCHULE 2 8 4 16 Eignung Bauland 4 Lage zu Verladestation 4 4 16 3 12 Lage zum Flughafen 2 4 8 2 4 Arbeitskr ftepotenzial 8 5 40 3 24 Landpreise 5 ql 5 5 25 Steuerbelastung 4 3 12 4 16 Zusammenarbeit Beh rde 3 3 9 4 12 Total 30 98 109 Tabelle 13 Nutzwertanalyse Entscheid Die Kernaufgaben o keine Systematik ersetzt einen unternehmerischen Entscheid o Neben Empfehlungen auch Hauptgr nde f r die Verwerfung der naheliegenden Alternativen aufzeigen Nachdem die L sungen bewertet wurden folgt der Entscheid Dieser wird normalerweise von einer Gruppe z B Stakeholder gef llt Ob man f r oder gegen diese L sung war spielt ab sofort keine Rolle mehr Der Entscheid ist gef llt und muss von allen Beteiligten getragen werden Eine Spaltung der verschiedenen Interessengruppen k nnte verheerende Auswirkungen auf den weiteren Verlauf des Projekts haben Hier soll und muss der Projektleiter allenfalls auf seine Kommunikationsf higkeiten zur ckgreifen und die Wogen gl tten Designaspekte im Projekt Alles sollte so einfach wie m glich gemacht werden aber nicht einfacher Albert Einstein Industriedesign als Probleml sungsprozess Jeder Designprozess ist sowohl ein kreativer Prozess a
116. ing und nat rlich auch die Vorgehensmodelle in der Softwareentwicklung Zuletzt m chte ich mich noch bei meinem Arbeitgeber daf r bedanken dass er mich w hrend der Ausbildung unterst tzt hat sowie bei der Schule f r die vielen interessanten Vorlesungen bh e E EE EE ba GEN Qait Transferarbeit Urs Zihlmann Seite d 1 KOMMUNIKATION Datum Dozent R ckblick auf den Unterrieht 02 03 05 2013 Gabriele Kaspar Transferarbeit Urs Zihlmann Lucerne University of Applied Sciences and Arts HOCHSCHULE LUZERN Technik amp Architektur Meine Erwartungen an diesen Unterrichtsblock wurden deutlich bertroffen Mit dem Thema Kommunikation hatte ich mich bereits in anderen Weiterbildungen auseinandergesetzt Trotzdem habe ich in diesem Block viele neue Erkenntnisse gewonnen Gleich zu Beginn des Unterrichts hat uns Gabriele Kaspar darauf hingewiesen dass dieser Unterrichtsblock eine Art Labor sei Wir wurden ermutigt Dinge auszuprobieren und Fragen zu stellen die man sonst eher f r sich beh lt und die in der Regel unbeantwortet bleiben Dadurch war der Unterricht sehr offen und spontan und Gabriele schaffte es eine angenehme und motivierende Stimmung zu erzeugen In besonders guter Erinnerung sind mir die praktischen Gruppen bungen geblieben Beim Colour Blind hat man wunderbar die Wichtigkeit der klaren Kommunikation gesehen und wie berall in Gruppenarbeiten erkennt man relativ schnell wer ein Alpha
117. ipse Auch die Paralipse begegnet uns t glich Wir behaupten etwas nicht anzusprechen nur um es dann eben doch zu tun Mit allem geb hrenden Respekt oder auch Ohne Ihnen zu nahe treten zu wollen wird gerne als Absicherung vorweg geschickt wenn man im Begriff ist mit seinem Folgesatz pers nlich zu werden Rhetorische Der Sprecher erwartet keine Antwort auf seine Frage denn er setzt voraus dass sein Frage Gegen ber seinen Standpunkt kennt und teilt Transfer in die betriebliche Umgebung SRF und tpc Ausbildung bieten diverse interne Ausbildungen zum Thema Kommunikation an Diese finden in regelm ssigen Abst nden statt und k nnen von allen Mitarbeitenden besucht werden Kursthemen Zielsetzungen Inhalte Auftreten und Sie formulieren und trainieren ein professionelles individuell optimiertes Pr sentieren Auftrittsverhalten Sie entwickeln Freude am Auftreten vor Publikum Sie k nnen ihr Publikum nicht nur informieren sondern auch berzeugen Train the Trainer Der Kurs bietet eine Einf hrung und ein Training f r die Aufgaben im Unterricht Vorbereitung Durchf hrung Auswertung von Unterrichtslektionen Umgang mit Gruppen Die Teilnehmenden sind in der Lage Lernziele zu formulieren Unterricht Coaching nach didaktisch methodischen Gesichtspunkten vorzubereiten durchzuf hren und zu evaluieren sowie Hilfsmittel richtig Lucerne University of Applied Sciences and Arts HOCHSCHULE LUZERN Technik amp Architektur
118. iptive vs Adaptive san ans han a aa arini a anii 83 tean opd Aale Vergleich ae Ee dees EE NAS 84 Extreme Programming XP 4 ee een ebene leisen 85 Scrum Flw mm1 Scrum Posten Bean 86 Ria Bee e EE 87 Teamentwicklungsuhr nach Tuckman ssssssssensssssnrrnssrtnntrssttnnnrerttnnnnsttntnnnstnnnnnnsennn nennen ennenen ne 98 Die acht Kontlikt arten nase ae E E E N A Aaa 102 Seene 104 Konfliktverhaltensstile nach Karl Berkel AAA 104 Konflikteskalation nach Glas 105 Phasenmodell DAMUK 2 een 113 Risikomanagement Prozess in f nf Gchrttten A 114 Die drei Phasen der Evaluation uuusrrssnennsnennnnnnnnennnnnnnnnnnnnnnnennnonnnnnonnennnnnensnnnrerennnenrnnnnnnn 118 NN 20er eisen Ea Eea EEKE SEE 119 SN LE 121 Phaselll asess eer reegen dE 123 Die vier Tools nach Marcel Diet 125 Projektabschluss im berblick uucuaeaeeeneenennennnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnannnnnnnnennnnenennnnnn 129 Net Promoter SC r asus 4er rasant EEEEEEEEEE ERR anne 130 v C HOCHSCHULE LUZERN Technik amp Architektur Tabellenverzeichnis Tabelle 1 Ausdruck der Grundhaltung ich bin ok du bist oke 9 Tabelle 2 Offene und geschlossene Fragen 10 Tabelle 3 Drei Stufen des aktiven Zuh rens 2s20um4440nrennnonnnnnnnennnnnnennnonennnnnennnnnennnennnennnennsonnnnnsnrernnorernsonnn 10 Tabelle 4 Die sechs AN Fragens tett tnnneretnn Ensen E Enese EEEE Eeo tnn nnen enn
119. ist ob es verstanden wurde St rungen gehen vor Egal ob es das klingende Handy ist oder tuschelnde Teilnehmer innen Sprich es sofort an schaff es aus der Welt Gib gen gend Raum f r Gespr che lass sie aber nicht ausufern z B zeitlich terminieren Schaffe einen klaren Schluss gemeinsam mit deinen Teilnehmer innen Bedanke dich am Ende eines Kurses IMMER f r die Aufmerksamkeit OLIO D oO Do Do Do OI RS E m OI D Transferarbeit Urs Zihlmann Seite 17 inc Lucerne University of Applied Sciences and Arts HOCHSCHULE LUZERN Technik amp Architektur 2 PROJEKTSTART UND GESTALTUNGSRAHMEN z n Teaser 13 06 2013 13 06 2013 14 06 2013 Roland Haas Heinz Scheuring Roland Haas Transferarbeit Urs Zihlmann Zum Thema Projektstart haben wir in 4er 5er Gruppe gearbeitet und uns Gedanken dazu gemacht was die Schwierigkeiten bei Projekten sind Wie erwartet haben alle Gruppen die mehr oder weniger gleichen Gr nde angegeben Roland Haas zeigte uns die Kartenabfrage und sortiertechnik was dank den praktischen Beispielen sehr verst ndlich vermittelt wurde Beim zweiten Thema Ihre Projekte und deren Ziele arbeiteten wir wiederum in 4er 5er Gruppen und w hlten ein reales Projekt aus dem Umfeld eines Teammitglieds aus F r dieses Projekt erstellten wir eine Auslegeordnung aus welcher wir die Projektstruktur definierten Aus dem Projektstrukturplan w hlten wir ein Arbeitspaket aus
120. kennung Entdeckung und Vermeidung von Fehlern Das DAMUK Phasenmodell ist das klassische Vorgehensmodell wie FMEA umgesetzt werden kann Phasenmodell DAMUK Vorgehen Teambildung funktions bergreifend Betrachtungsabgrenzung Funktionsbetrachtung arten Ursachen und Fehler entdeckung Erneute Risikoabsch tzung Umsetzung er m Abbildung 48 Phasenmodell DAMUK Beurteilung des Risikos Verbesserungsmassnahmen festlegen Eine Vorlage f r das FMEA Formblatt mit Beispielen und Bewertungskriterien gibt es auf der Seite www riskmanager org 164 Siehe http risikomanager org 2009 07 30 fmea formblatt vorlage 15 12 2013 Transferarbeit Urs Zihlmann Seite 113 C C HOCHSCHULE LUZERN Technik amp Architektur Unsicherheiten Quantifizieren Unter Risikoquantifizierung versteht man zusammenfassend die quantitative Beschreibung eines Risikos durch eine geeignete Wahrscheinlichkeitsverteilung sowie die Bewertung des Risikos durch ein geeignetes Risikomass Das Quantifizieren von Risiken beinhaltet o Projekt beurteilen o Risiken erfassen und gruppieren o Unsicherheit quantifizieren in Zeit und oder Geld Einzelne Risiken ergeben kombiniert das Gesamtrisiko e Monte Carlo e PERTT bei Manfred Stania Betha Methode Risikomanagement Prozess Give us the tool and we will finish the job Winston Churchill Abbildung 49 Risikomanagement Prozess in
121. klung Software Design Security Review Distribution of Level object reviewed object and protocol SWD Each Il All review particip WT normal review method SWAD SWA Autor i S Il for most ess parts of ER ECH u Sg SEN en Safety SWD Each Il All review particip WT normal review method SWA Autor release WT incl optional ones Il for most ess parts of SWFR the SWAD Abbildung 23 Beispiel einer Review Definition 100 Siehe http wwwswt informatik uni rostock de deutsch Mitarbeiter michael lehre Usab_WS2000 Vortrag11 vortrag htm 11 09 2013 Transferarbeit Urs Zihlmann Seite 67 LUZERN Technik amp Architektur C p C HOCHSCHULE Teststrategie Die Teststrategie ist beim Testen von Embedded Software entscheidend Sie betrifft Modul Softwareintegration Funktionale amp Nichtfunktionale sowie Abnahme Tests Die Details zu diesen Tests Voraussetzungen Verfahren Testumgebung etc werden in der Testspezifikation beschrieben Qualit tssicherungsplan Gesamtheit der qualit tssichernden Massnahmen in der Software Entwicklung Testkonzept Teststrategie Gesamtheit der Testaktivit ten in der Software Entwicklung Testaktivit ten auf den einzelnen Testebenen Software Software Funktionale Nichtfunktionale Integrationstets nn Testeingangs Testende bedingungen ern Abbildung 24 Beispiel eines Testkonzepts Testumgebungen Es empfiehlt sich f r das Testen mehrere Testumgebungen zur
122. kussion Androhung von Abbruch Zynische Kommentare Effiziente Gespr che bestehen aus 80 offenen und 20 geschlossenen Fragen vermeiden versuchen 3 J ggi amp Z ger 2011 J ggi amp Z ger 2011 5 J ggi amp Z ger 2011 S 13 S 23 S 31 Transferarbeit Urs Zihlmann Offene Fragen ermutigen den Gespr chspartner sich umfassend mitzuteilen Man nennt sie auch W Fragen weil sie mit einem W beginnen Was wie wo wann wozu womit wer wen wem Warum und weshalb Fragen betreffen normalerweise die Vergangenheit weshalb sie zu Erkl rungen und Rechtfertigungen tendieren was wir zu Seite 9 C C HOCHSCHULE LUZERN Technik amp Architektur Geschlossene Fragen kann man mit einem Ja oder Nein oder mit Ich weiss nicht beantworten Sie sind n tzlich wenn eine klare Stellungnahme gew nscht wird Tabelle 2 Offene und geschlossene Fragen Aktives Zuh ren Am besten berzeugt man andere mit den Ohren indem man ihnen zuh rt Dean Rusk 1909 1994 ehemaliger US Aussenminister Aktives Zuh ren erfordert mehr als ein offenes Ohr es fordert alle Sinne P Tabelle 3 Drei Stufen des aktiven Zuh rens Beziehungsebene definieren Ich teile meinem Gegen ber mit dass ich mich diesem Gespr ch mit ungeteilter Aufmerksamkeit und voller Pr senz widme M gliche usserungsformen Blickkontakt Nicken Gestik Inhalt verstehen Ich versuche die Kernaussage d
123. l das Thema rund um das Management von nderungen Im zweiten Teil ging es um das Projekt Erfolgsmanagement Zu diesem Thema machten wir in kleineren Gruppen bungen und versuchten aufgrund eines realen Projektes Erfolgskriterien und deren Massnahmen zu definieren Ich empfand diesen Block als sehr theoretisch und ich kann mir schwer vorstellen dass in der Praxis das Projekt Erfolgsmanagement in dieser Tiefe angewendet wird 19 09 2013 Daniel Schaller Der Unterricht bei Daniel Schaller war das Kontrastprogramm zum Unterricht von Heinz Scheuring So erz hlte er vor allem aus seinen Erfahrungen mit Projekten die nicht nur spannend sondern auch am sant und mit viel schwarzen Humor erz hlt wurden Die Vorlesung w rde auch ins Kapitel Globale Projekte passen Zu berlegen w re hier auch die Trennung der beiden Fachrichtungen da der Unterricht wenig mit Informatik zu tun hatte Insbesondere das Claim Management hatte sehr wenig Bezug zur Informatik 13 12 2013 Peter Sollberger Im dritten Teil dieses Unterrichtsblocks besch ftigten wir uns w hrend zwei Lektionen mit Risikomanagement Nach einigen Grundlagen Was ist ein Risiko Arten von Risiken etc zeigte uns Peter Sollberger die FMEA Methode das DAMUK Phasenmodell sowie die Monte Carlo und PERT Methoden mit denen sich das Gesamtrisiko kombiniert aus einzelnen Risiken abbilden l sst ber den Unterrichtsstil von Peter Sollberger kann man diskut
124. lanung und Controlling entschieden weshalb dieses Thema in dieser Arbeit nicht weiter behandelt wird Meine Vertiefungsarbeit geht allerdings eher in Richtung Vorgehensmodelle in der Softwareentwicklung was sich aber leider erst nach dem Einreichen des Vertiefungsthemas herausgestellt hat Aus meiner Sicht ist das Kapitel Projektplanung und Controlling die Essenz des Projektmanagements weshalb ich dieses Kapitel aus zeitlichen Gr nden erst nach dem Abgabetermin zusammenfassen werde so dass die Transferarbeit alle Themen abdecken und meinen Anspr chen an ein kleines Projektmanagement Nachschlagewerk gen gen wird Transferarbeit Urs Zihlmann Seite 44 C C HOCHSCHULE LUZERN Technik amp Architektur 5 REQUIREMENTS MANAGEMENT INFORMATIK Datum Dozent R ckblick auf den Unterricht OOO O O 05 07 Karol Fr hauf Der Unterricht bei Karol Fr hauf war stark an den Unterlagen 22 08 2013 orientiert Zwischendurch haben wir Beispiele aus der Praxis beigezogen und Praxis bungen gemacht um die eher theoretischen Themen besser verstehen zu k nnen Karol Fr hauf ist ein grosser Fachexperte und schon viele Jahre auf diesem Gebiet t tig weshalb er zu jedem Thema interessante Beispiele aus der Praxis erz hlen konnte Insbesondere sein trockener Humor kam bei mir sehr gut an Die Folien empfand ich als unstrukturiert so dass es schwierig war dem Inhalt zu folgen und das aktuelle Thema einer Logik Inhaltsverzeichnis
125. lcode durch Modultests erl utern Welches Code Abdeckungskriterium ist f r ein konkretes Projekt sinnvoll und geeignet Anweisungen Zweige Pfade Bedingungen co c1 c2 Alle Anweisungen des Alle Zweige Pfade des Bedingungen in allen zu testenden Software zu testenden Software Varianten des zu Moduls werden im Moduls werden testenden Software Modultest mindestens mindestens einmal Moduls pr fen einmal ausgef hrt durchlaufen Abbildung 27 Abdeckungskriterien CO C1 und C2 Eignung der Abdeckungskriterien o CO Anweisungsabdeckung zwingend e Modultests in Driver Stub Umgebungen e _Software Module ohne funktionale Sicherheit o C1 Zweig Pfadabdeckung zwingend e Modultest Frameworks e Software Module mit funktionaler Sicherheit C1 o C2 Bedingungsabdeckung nur kritische Bereiche e Sehr hoher Aufwand auch mit Modultest Frameworks e Alternative Code Review intensive inspection der kritischen Teile Transferarbeit Urs Zihlmann Seite 71 C C HOCHSCHULE LUZERN Technik amp Architektur Funktionaler und nicht funktionaler Software Test Funktionaler Test Black Box Beim funktionalen Test wird das gesamte System in seiner vollst ndigen Umgebung nicht nur Software verifiziert Die Testf lle werden aus den funktionalen Anforderungen der Software Anforderungsspezifikation abgeleitet Spezifikation Test Kundenanforderung Pe Software Architektur Software Integrationstest Software Design So
126. leich mit der Auswertung starten konnten Gabriele erw hnte was die einzelnen Anteiber bedeuten und wies auch auf Gefahren hin Grunds tzlich sollte kein Antreiber die rote Linie berschreiten was bedeuten w rde dass dieser Antreiber im ungesunden Bereich ist Bei meiner Analyse lag der Schwerpunkt 1 Punkt ber der roten Linie bei mach es allen recht Die n chsten drei Antreiber sei perfekt mach schnell streng dich an sind ausgewogen und knapp unter der roten Linie Der Antreiber sei stark liegt etwas abgeschlagen an letzter Stelle Diesen gilt es deshalb in Zukunft zu verst rken und gleichzeitig soll der Antreiber mach es allen recht minimiert werden Dies setze ich mir zum Ziel bei den n chsten Projekten Teamrolle Teamrolle ist die Bezeichnung f r die Funktion Position oder Aufgabenstellung die ein Teammitglied innerhalb einer Arbeitsgruppe zugewiesen bekommen hat oder die sich auf Grund bestehender Eignungs und Leistungsschwerpunkte im Laufe einer Team oder Gruppendynamik innerhalb des Teams herausgebildet hat Teamentwicklungsuhr Teams entstehen nicht zuf llig Sie erfordern eine Entwicklung ber einen Zeitraum Eine Gruppe die zum Team wird durchl uft ganz bestimmte vorhersehbare Stufen So wie Menschen erst zu Erwachsenen werden wenn sie Kleinkindalter Kindheit und Jugend durchlaufen haben beginnt ein Team als eine Gruppe von Menschen die bestimmte Stufen absolvieren muss bevor s
127. len Entwicklungsmodelle und dazu gew nscht was f r Einfl sse diese Arbeitsweise auf das Requirements Engineering auf die Software Qualit t oder auf die herk mmliche Projektplanung und das Controlling haben Im August mussten wir uns f r ein Vertiefungsthema entscheiden Dieses wird in einer separaten Arbeit behandelt und geh rt nicht zur Transferarbeit Ich habe mich f r das Modul Projektplanung und Controlling entschieden Zwei Monate sp ter als wir bei Roman Lobsiger das Thema Vorgehensmodelle in der Softwareentwicklung behandelten wurde mir bewusst dass mein Vertiefungsthema besser zu diesem Modul gepasst h tte Grunds tzlich geht es bei beiden Modulen um Projektplanung allerdings werden andere Vorgehensmodelle eingesetzt Auf jeden Fall m chte ich die Zusammenfassung des Moduls Projektplanung und Controlling von Manfred Stania auch nach dem Abgabetermin der Schule nachholen damit diese Arbeit alle wichtigen Informationen der Ausbildung enth lt und meinen Anspr chen an ein Projektmanagement Nachschlagewerk gerecht wird Die Transferarbeit werde ich meinem Arbeitgeber abgeben und die Inhalte falls gew nscht an unseren Betrieb anpassen Bis jetzt existiert noch kein Corporate Project Handbook und das eine oder andere Kapitel k nnte man durchaus in den Betrieb bernehmen Ich denke da besonders an das gemeinsame Projektverst ndnis den erfolgreichen Projektstart Software Qualit t Requirements Engineer
128. ler Risk amp Claim Management im Anlagenbau 2013 Heinz Scheuring Der www Schl ssel zum Projektmanagement orell f ssli 6 Auflage 2013 Heinz Scheuring Il Die Welt des Projektmanagers Mai 2013 Heinz Scheuring Ill nderungen managen Stakeholder Management Projekt Erfolgsmanagement September 2013 Ken Schwaber und Jeff Sutherland The Scrum Guide Scrum org 2011 Transferarbeit Urs Zihlmann Lucerne University of Applied Sciences and Arts HOCHSCHULE LUZERN Technik amp Architektur Peter Sollberger Umgang mit nderungen und Stakeholder Risikomanagement 2013 Andreas Spillner und Tilo Linz Basiswissen Softwaretest dpunkt verlag 2 Auflage 2004 Manfred Stania Projektmanagement Projektplanung und Controlling 2013 Manfred Stania Il Projektmanagement Methoden und Werkzeuge 2013 Heinz Strobel Teamarbeit VOGB AK plus 2003 Bruce W Tuckman Development Sequence in Small Groups Psychological Bulletin 63 1965 Andreas Wintersteiger Scrum Schnelleinstieg 2013 Ralf Wirdemann SCRUM mit User Stories Hanser Verlag 2 Auflage 2011 Kornelia von Vacano Seminar Professionelle Gespr chs und Verhandlungsf hrung 2001 Urs Zihlmann Vertiefungsarbeit HSLU iPMT 2014 Seite 136 pc Klassenliste Stefan Achermann stefan achermann gmx ch Tobias Blum tobias blum basenet ch Sabine Busslehner sabine bussiehner mammut ch Dominic Cotter dominic cotter tv Danilo
129. lesung den Folien Diese sind aus meiner Sicht nicht selbsterkl rend und so stellte sich das Schreiben einer Zusammenfassung aufgrund der Folien als sehr schwierig heraus Aus diesem Grund habe ich f r diese Zusammenfassung gr sstenteils andere Quellen verwendet Hilfreich w re auch ein Rollenspiel in welchem die Scrum Artefakte und Prinzipien nachgespielt und auf ein vereinfachtes Projekt angewendet w rden berblick Vorgehensmodelle Wozu Vorgehensmodelle o _Softwareentwicklungsprozess wird transparenter und somit e planbar e nachvollziehbar e kontrollierbar e lehrbar o f r das Softwareprodukt bedeutet das e h here Qualit t e effizientere Produktion e bessere Wartbarkeit o und somit e schnellere Fehlerbehebung und erh hte nderungsfreundlichkeit Transferarbeit Urs Zihlmann Seite 78 C C HOCHSCHULE LUZERN Technik amp Architektur Die wichtigsten Vorgehensmodelle Sequentielle Modelle Ein sequentielles Modell gruppiert logisch und zeitlich verkn pfte Projektvorg nge in einzelne Projektphasen die durch Meilensteine getrennt werden Meilensteine dienen unter anderem dazu festzustellen ob und wann eine Projektphase als abgeschlossen gelten kann Abbildung 33 Phasen bei sequentiellen Vorgehensmodellen Vielseitiges Modell Streng sequentiell keine Iterationen Zahlreiche Modellvarianten Zeitanteil der einzelnen Phasen ist fix definiert Wasserfallmodell Das klassische Wasserfallmodell erlau
130. ls auch ein Probleml sungsprozess D Scheuring 2013 S 177 65 Haas II 2013 Transferarbeit Urs Zihlmann Seite 40 v C HOCHSCHULE LUZERN Technik amp Architektur Das Spezifische am Designprozess ist die Bem hung des Industrial Designers durch Entwerfen eines Industrieproduktes mit entsprechenden Eigenschaften eine Probleml sung zu finden durch deren Gebrauch menschliche Bed rfnisse dauerhaft gedeckt werden k nnen Der Design Prozess setzt sich aus den folgenden 5 Schritten zusammen Analyse Konzeption Entwurf Realisierung Kommunikation F r Gert Hildebrand Chef Designer BMW Mini bedeutet gutes Design dass ein Produkt Begehrlichkeit ausl st Der Kunde sieht ein Auto und hat unmittelbar den Wunsch Das m chte ich haben Er muss sich in Sekunden in das Produkt verlieben ohne dass der Verk ufer viel erkl ren muss Wenn Sie ein Auto erl utern m ssen haben Sie verloren Kreativit t Kreativit t ist die sch pferische F higkeit Neues zu erschaffen das in irgendeiner Art und Weise Nutzen oder Sinn hat also tats chlich zu kreieren oder auch nur zu erdenken Die meisten Menschen verbinden Kreativit t mit den K nsten Kreativit t beschr nkt sich aber nicht nur auf Malen Musizieren oder Schauspielern Kreativit t wird berall dort gebraucht wo es darum geht neue Wege neue L sungen oder neue Ideen zu finden Wir brauchen Kreativit t in allen m glichen Bereichen z B o Inder Produkte
131. lung noch offener Punkte Offene Rechnungen 5 F Emotionaler Abschluss Danksagungen Projektteam Projektausschuss Projektauftraggeber evtl Kunden Themen Formales Projektende Dokumentation d Teilnehmende Idealer bergabe Zeitpunkt Abschluss Abnahme Claim Mgmt evtl 2 Sitzungen nur interne Teilnehmende i mit Kunden Was Bis wann Teamaufl sung Verantwortlich letzter gemeinsamer Event virtuelle Teams letzter Fort schrittsbalken i f Nachkalkulation Information an Stakeholder f i Kosten Termine Umfang Je nach Fragen Zeitpunkt Ge o Projektauftraggeber Projektteam ausgew hlte Stakeholder vorl ufiger Bericht Abschlussaufgaben gegen ber Stakeholdern Aufgaben Stakeholder f r das Projekt Kundenzufriedenheit Chancen und Risiken j Info Stakeholder ber P Abschluss N definitiver Bericht plus Anh nge mit Details Management Summary Projektverlauf Projektergebnisse i j Offene Punkte Was Wann Wer Kosten Termine Leistungen Spezielle Ereignisse Lessons Learned N chste Schritte Was hat jedes Teammitglied gelernt Welche Erkenntnisse sind f r die Organisation wichtig Positive Erfahrungen f r weitere Projekte nderungen f r weitere Projekte Abbildung 55 Projektabschluss im berblick Seite 129 173 Haas III 2013 S 7 10 Transferarbeit Urs Zihlmann LUZERN Technik amp Architektur
132. m Sinne der Coding Standards sondern auch Vorgaben f r die praktische Umsetzung unter Ber cksichtigung der Anwendung entsprechender Werkzeuge Ein Beispiel f r die praktische Umsetzung einer Guideline w re die Dokumentation nicht automatisch pr fbarer Programmierregeln in Code Review Checklisten Statische Code Analyse mit Code Metriken Ziel Code Analysen Rules und Code Metriken Quantitative Aussage zur Pr fung des Programmcodes ohne Ausf hrung verwenden Kernfragen Welche Schlussfolgerungen kann ich aus der gemessenen Komplexit t des Programmcodes schliessen o Wie viele Ablaufpfade gibt es o Welche Pfade sollen getestet werden o Wie sollen die Testf lle priorisiert werden Eine Code Metrik ist eine Funktion die eine Software Einheit in einen Zahlenwert abbildet Dieser berechnete Wert ist interpretierbar als der Erf llungsgrad einer Qualit tseigenschaft der Software Einheit Cyclomatic Complexity CC Die Anzahl der unabh ngigen Ablaufpfade durch eine Funktion oder Methode Zyklomatische Komplexit t Anzahl der Kanten Anzahl der Knoten 2 Effective Lines of Code eLoC Die Anzahl der echten Code Zeilen einer Funktion oder Methode Zusammenhang von CC und eLoG Die Grenzwerte dieser Metriken werden in der Coding Guideline definiert Wirklich hilfreich sind die beiden Metriken jedoch erst wenn sie zusammen betrachtet werden Die folgende Grafik zeigt ein Modul Dependency eLoc CC welches
133. m roduc Master D CA CL Owner ES ees Sprint anne 1 amp 2 Abbildung 41 Scrum Flow mm1 Scrum Poster 118 Siehe http www it agile de scrum htmi 10 10 2013 119 Siehe http mm1 consulting de mm1 consulting management veroeffentlicht einfach verstaendliches scrum plakat 24 09 2013 Transferarbeit Urs Zihlmann Seite 86 C C HOCHSCHULE LUZERN Technik amp Architektur Das Prozessmodell von Scrum steckt den Rahmen ab in dem alle Aktivit ten der Produktentwicklung ablaufen Die Produktentwicklung wird in Scrum in klar abgegrenzte Intervalle meist 2 bis 4 w chige Sprints aufgeteilt Am Ende jedes Sprints muss das Team auslieferbare Software liefern die f r sich allein lauff hig w re auch wenn man die weitere Produktion einstellen w rde Der Ablauf eines Sprints und die darin vorkommenden Rollen Meetings und Artefakte werden auch Scrum Flow genannt Im Zentrum steht bei der Abfolge der Meetings der Gedanke der st ndigen Verbesserung Rollen Im Zentrum eines Scrum Projekts stehen das Team der ScrumMaster und der Product Owner Diese drei Rollen bilden zusammen das Scrum Team und teilen sich die gesamte Management verwantwortung des Projekts Es gibt keinen Chef Projektleiter oder sonst jemanden der den anderen vorschreibt wie sie zu arbeiten haben Alle Beteiligten haben das gleiche Ziel vertrauen einander und mischen sich nicht in die Verantwortungsbereiche der jeweils anderen Rollen ein
134. mann Seite 90 C C HOCHSCHULE LUZERN Technik amp Architektur Die Artefakte Als Artefakte bezeichnen wir in Scrum die Resultate des Scrum Prozesses Vision Eine Vision ist ein klares deutliches attraktives und emotionalisierendes Bild des angestrebten Produkts Product Backlog Item In Scrum bezeichnen wir die zu liefernden Funktionalit ten die in einem Product Backlog aufgelistet werden als Product Backlog Items Product Backlog Das Product Backlog ist eine Liste von Product Backlog Items die vom Product Owner nach ihrer Bedeutung f r den Projekterfolg priorisiert werden Der Product Owner ist als einzige Person f r die Verwaltung des Produkt Backlog verantwortlich 15 Die Verwaltung des Product Backlogs beinhaltet Die klare Formulierung der Eintr ge Die Anordnung der Eintr ge ordering in der gew nschten Fertigstellungsreihenfolge Die Sicherstellung der Wertsch pfung des Entwicklungs Teams Die Sicherstellung dass das Produkt Backlog f r alle Beteiligten einsehbar transparent und klar ist und dass es anzeigt woran das Scrum Team als n chstes arbeiten wird Die Sicherstellung dass das Entwicklungs Team die Eintr ge des Product Backlogs versteht Sprint Goal Der Product Owner legt gemeinsam mit dem Team das Sprint Goal das Ziel des Sprints fest Es fokussiert alle Anstrengungen des Scrum Teams und des Product Owners hinsichtlich dieses miteinander vereinbarten Punkts Selected Product Backlog
135. n unserer Branche die Besuche von Messen So finden jeweils im Fr hling die NAB in Las Vegas und im September die IBC in Amsterdam statt Die letzte IBC durfte ich ebenfalls besuchen und man entdeckt unglaublich viele neue Produkte die in der Regel auch gleich pr sentiert werden Wir informieren uns auch h ufig bei unseren Partnern ZDF ARD ORF etc oder beanspruchen externe Broadcast Beratungsfirmen die uns bei der Evaluation unterst tzen Eine zus tzliche Herausforderung die es vor einigen Jahren in dieser Intensit t noch nicht gab sind die Harmonisierungsbestrebungen der SRG Dabei geht es darum dass alle Tochtergesellschaften der SRG unter anderem SRF tpc RTS RSI und RTR die gleichen Produkte beschaffen Auch wenn dies auf den ersten Blick sinnvoll erscheinen mag so ist es in der Realit t eine grosse Herausforderung Juristische Aspekte Bei meinen Projekten hatte ich bisher noch keine Ber hrungspunkte mit juristischen Aspekten wie wir sie im Unterricht kennengelernt haben Deshalb ist dieser Teil auch nur auf einer Seite und in einer Grafik zusammengefasst Umsetzungsm glichkeiten im Betrieb Einen Optimierungsbedarf sehe ich bei der Dokumentation der Evaluationsphase Ich war vor ca vier Jahren in einem Evaluierungsteam wo es darum ging einen WAN Beschleuniger anzuschaffen Drei Jahre sp ter w re ich froh gewesen h tten wir unsere Besprechungen Konferenzen und Workshops besser dokumentiert denn das System wurde
136. n ausgegangen dass s mtliche Anforderungen vor der Realisierung bekannt sind Eine weitere Annahme ist dass sich die diese Anforderungen w hrend der gesamten Projektlaufzeit nicht oder zumindest kaum ver ndern Um nach diesem Modell arbeiten zu k nnen m ssen s mtliche Anforderungen bis ins Detail verstanden und teilweise auch antizipiert werden Treten Probleme auf werden dadurch oft teure Mehraufw nde verursacht die sich h ufig negativ auf Kosten Zeit und Qualit t auswirken P 105 Siehe http dilbert com strips comic 2007 11 26 01 10 2013 106 Siehe http www modusnext ch agil vs wasserfall eine sichtweise 02 10 2013 Transferarbeit Urs Zihlmann Seite 81 C Traditionelle Methoden 50 fertig 0 einsetzbar Agile Methoden Zeit MRAM MRH HIN d i 25 fertig 100 einsetzbar Lucerne University of Applied Sciences and Arts HOCHSCHULE LUZERN Technik amp Architektur Abbildung 37 Traditionell vs Agile Gr nde f r Agile Methoden o Kunde weiss nicht genau was er braucht Nicht alle Anforderungen und Stakeholder bekannt Kunde hat widerspr chliche Anforderungen Auftragnehmer versteht nicht genau was der Kunde will Auftragnehmer untersch tzt bersch tzt Aufw nde nderungen in den Priorit ten Gesch ftsprozessen etc w hrend des Projektes Projekt in komplexe Projektlandschaft eingebunden Das Agile Manifest Der kleinste gemeinsame Nenner aller agilen Vo
137. n internen und externen Stellen sowie auftragnehmende und beratende Stellen und Personen eingetragen die in einer losen Form ans Projekt gebunden sind Diese Darstellung hilft zu einem fr hen Zeitpunkt m gliche Informationspannen aufzudecken 77 Rollen im Projekt definieren Wie viele unterschiedliche Rollen in einem Projekt vorkommen h ngt vor allem von der Linienorganisation des Unternehmens ab Die folgende Tabelle beschreibt einige Rollen die in den meisten Projekten vorkommen Zweck bzw wichtigste Aufgaben Initiiert das Projekt und ist dessen Tr ger Tr gt die unternehmerische Verantwortung f r das Projekt Trifft die Grundsatzentscheide bzgl Ziel und Auftrag des Projektes Plant berwacht und steuert das Projekt F hrt das Projektteam Verantwortlich nach innen und aussen Plant berwacht und steuert einen in sich geschlossenen Teil des Projektes Setzen die Vorgaben f r Projektaufgaben um F hren definierte Aufgaben im Rahmen des Projektes durch Treffen Entscheide bez glich des Ressourceneinsatzes Unterst tzung in fachlicher Hinsicht Ist f r den korrekten Betrieb des eingef hrten Systems zust ndig Gegen ber Benutzern verantwortliche Stelle Personen die als prim re Adressaten das Projektresultat nutzen K nnen Nutzniesser aber auch Bremser sein Personen die vom Projektresultat profitieren jedoch nicht die prim re Zielgruppe darstellen Mitarbeiter die um ihren Arbeitsplatz bangen
138. n pr gen unser Erwachsenenleben Auch im reifen Alter befolgen wir diese Gebote und Verbote Wenn sie aus einem wohlwollenden Elternteil stammen wie zum Beispiel Lass dich nur nicht unn tig hetzen sind sie durchaus hilfreich Andere dagegen sind belastend einengend und blockierend Ziel der pers nlichen Entwicklung sollte es sein dass wir mit unserem Erwachsenen Ich entscheiden k nnen ob eine solche Botschaft sinnvoll oder stressausl send ist Die Amerikaner Kahler und Capers haben f nf grundlegende elterliche Forderungen herausgearbeitet die sie als Antreiber und Blockierer bezeichnen 17 Sei immer perfekt Perfektionismus und das Verlangen nach Vollkommenheit Ziele werden bertroffen Toleranz ist verd chtig Fehler werden zur Trag die Positive Energien Gr ndlichkeit Pr zision Detailorientierung Abgr nde berforderung Scheitern Ungen gen Frustration Erlauber Sei Du selbst Offenheit Spontaneit t Humor Nat rlichkeit Authentizit t Mach immer schnell Alles wird im Handumdrehen erledigt Hohe Effizienz Ein Aufruf zur Hektik und eine verborgene Warnung vor der N he zum Anderen Positive Energien Effizienz Dynamik und Tempo Abgr nde Nicht abschalten k nnen Hektik Ungeduld nicht im Hier und Jetzt Kaspar 2012 S 69 70 154Kaspar 2012 S 70 155 Siehe http www lutzpickhardt com index cfm pagelD 83 12 11 2013 r C HOCHSCHULE LUZERN Technik amp Architektur leben k n
139. n treten h ufig an den Grenzbereichen der quivalenzklassen auf da hier fehlertr chtige Fallunterscheidungen in den Programmen vorzusehen sind An jedem Rand werden der exakte Grenzwert und die beiden benachbarten Werte getestet Zustands bergangsanalyse Die Zustands bergangsanalyse bildet das Verhalten einer Softwarekomponente bei Zustands nderungen ab Diese Analyse kann f r strukturelle White Box Software Design und funktionale Black Box Anforderungsspezifikation Tests angewendet werden Identifikation der Zust nde States in denen sich die Software befinden kann m glichen berg nge Transitions zwischen den Zust nden Ereignisse Events Trigger die einen Zustands bergang ausl sen Wirkungen Actions die aus einem Zustands bergang resultieren F r jeden Zustands bergang soll mindestens ein Testfall definiert werden Transferarbeit Urs Zihlmann Seite 73 LUZERN Technik amp Architektur C p C HOCHSCHULE Regression und Automatisierung Fehlermanagementprozess Testwiederholung Abbildung 29 Testwiederholung im Fehlermanagementprozess Regressionstest Ein im Vorfeld festgelegtes Subset von Testf llen wird wiederholt um sicherzustellen dass mit der Fehlerbehebung in der zu testenden Software Version keine neuen Fehler entstanden sind Dieses Subset deckt alle grundlegenden Funktionen der Software ab Grunds tzlich gilt dass kein bereits behobener Fehler ein zweites Mal auf
140. n und Informationen vom System als Ein und Ausgaben Systemschnittstellen genutzt und in welcher Art und Weise diese konkret verarbeitet werden Strukturperspektive Strukturperspektive UML Entity Relationship Klassendiagramm Diagram Diese Perspektive beschreibt eine statische Sicht auf das System Modelle der Strukturperspektive formen dabei ein rein statisches Abbild des Systems ohne auf dynamische Aspekte wie Abl ufe oder Zustands nderungen einzugehen 7 87 Pohl 2012 S 67 88 Siehe http www dpunkt de pdf Broschueren Rupp_RE 3A_WA pdf 26 08 2013 3 Siehe http www dpunkt de pdf Broschueren Rupp RE 3A_WA pdf 26 08 2013 Transferarbeit Urs Zihlmann Seite 53 C C HOCHSCHULE LUZERN Technik amp Architektur Verhaltensperspektive Verhaltensperspektive Zustandsdiagramm Der Blick auf ein System aus der Verhaltensperspektive heraus betrachtet gezielt die Zust nde bzw Zustandswechsel die ein System dessen Komponenten und Objekte einnehmen k nnen 27 Nichtfunktionale Anforderungen spezifizieren Im Gegensatz zu funktionalen Anforderungen die beschreiben WAS ein System leisten soll funktional geben nichtfunktionale Anforderungen an WIE GUT ein System etwas leisten soll qualitativ Die nichtfunktionalen Anforderungen an ein System k nnen unterschiedlichster Art sein Im Rahmen des ISO Standards 9126 wurden folgende Typen von nichtfunktionalen Anforderungen Qualit tsattribute i
141. n w rde Transferarbeit Urs Zihlmann Seite 32 C C HOCHSCHULE LUZERN Technik amp Architektur Stakeholder Management Ebenfalls f r das Digital Signage Projekt erstellte ich eine bersicht der verschiedenen Stakeholder Diese Informationen trug ich aus diversen Gespr chen mit Auftraggebern und Teammitgliedern zusammen Kunden e BENO e Programmleitung TV e Communication amp P Services Dn Design Grafik e Roman Lehmann e Urs Zihlmann e SRF Grafik Feuerpolizei Support e Mediadesk Projektleiter e U Zihlmann e BENO Support Lieferanten e Leafit GmbH MEE e SRG ScheduAll Daten e Hardware z B ARP Bn CSP Netzerk Abbildung 9 Beispiel Stakeholder Analyse F r eine ausf hrliche Stakeholder Analyse wie wir sie im Unterricht behandelt hatten empfand ich dieses Projekt als zu klein Bei einem gr sseren Projekt w rde ich eine solche Analyse gerne einmal versuchen umzusetzen Ich bin jedoch eher skeptisch dass sich dadurch neue oder wichtige Erkenntnisse ber die Stakeholder ermitteln lassen und sich der hohe Aufwand lohnt Weitere Tipps f r einen erfolgreichen Projektstart In den folgenden Kapiteln habe ich einige Merkmale und Tipps f r einen erfolgreichen Projektstart zusammengetragen Ich setze mir zum Ziel diese Liste jeweils durchzuarbeiten wenn ich mit neuen Projekten konfrontiert werde Bevor Sie ein Projekt annehmen Projekte sind etwas Besonderes und
142. nen Erlauber Nimm dir Zeit Ruhe Besonnenheit Ausgeglichenheit in der Gegenwart leben Streng dich immer an Leistung und Fleiss ist alles Leistung z hlt mehr als das Resultat Lass dich ja nicht gehen Geniessen ist verd chtig Positive Energien Ausdauer Pflichtbewusstsein Fleiss und Einsatz Abgr nde Ineffizienz vergebliches Abm hen falsche Priorit ten unersetzlich sein Versager ngste Erlauber Tue es gelassener Entspanntheit Optimismus positives Denken loslassen k nnen Mach es immer allen Der andere ist wichtiger als ich Sei friedlich und freundlich Meide Konflikte und recht halte deine eigenen Bed rfnissen zur ck Der ewige Zweite meint es gut wird uninteressant und berfl ssig Positive Energien R cksichtnahme Loyalit t Freundlichkeit Bescheidenheit Diplomatie Abgr nde Unterw rfigkeit Profillosigkeit mangelndes Selbstbewusstsein mangelnder Respekt vor sich selber Erlauber Bejahe dich selber Selbst ndigkeit eigene Bed rfnisse erkennen den eigenen Weg gehen R cksichtnahme auf sich selber Selbstverantwortung Bestimmtheit Sei in jeder Lage stark Gib dir keine Bl sse sein ein Vorbild Zeige keine Gef hle und sei nicht traurig Sei ein Held Positive Energien Durchhalteverm gen H rte Durchsetzungsverm gen Abgr nde Einsamkeit Gef hle verschaffen sich unbewusst und unkontrolliert Ausdruck Erlauber Respektiere dich selbst sich selber
143. nik amp Architektur Anforderungen pr fen Wenn die Anforderungen die n tige Qualit t aufweisen k nnen diese f r die weiteren Entwicklungsaktivit ten Entwurf Realisierung und Test freigegeben werden Diese Entscheidung erfolgt anhand von definierten Pr f und Abnahmekriterien Validieren und Verifizieren sind die Schl ssel um Fehler in Anforderungen zu finden doing the right things Bauen wir das richtige System Validieren heisst pr fen ob die Anforderungen eine annehmbare Darstellung des Systems sind und die Bed rfnisse der Stakeholder richtig wiedergegeben werden 27 V Le r ifiz en 1 Ae doing things right Bauen wir das System richtig Verifizieren heisst pr fen ob mit der gew hlten L sung die Anforderungen erf llt werden k nnen 7 Anforderungen verwalten Ziel des Verwaltens von Anforderungen ist es die dokumentierten Anforderungen sowie andere relevante Informationen bis hin zu vollst ndigen Anforderungsdokumenten ber den gesamten Lebenszyklus des Systems bzw Produkts hinweg persistent verf gbar zu machen und sinnvoll zu strukturieren Anforderungen an den Requirements Engineer Der Requirements Engineer als Projektrolle steht h ufig im Mittelpunkt des Geschehens Er pflegt in der Regel als Einziger direkten Kontakt zu allen Stakeholdern und hat die Chance und Verantwortung sich ausreichend in das Fachgebiet der Stakeholder einzuarbeiten sowie die Sprache in den ve
144. nik amp Architektur Menschen die miteinander zu schaffen haben machen einander zu schaffen Friedemann Schulz von Thun Konflikte werden in acht typische Konfliktarten unterteilt Mobbing Organisations Pers nliche konflikte Rollen konflikte Wahrung zum Geg Wenn Zu 1 Su SED Transferarbeit Urs Zihlmann Konflikte Kont i kt Zwischen menschliche arten Konflikte Verteilungs konflikte Abbildung 44 Die acht Konfliktarten Innere Konflikte der Umgang mit Selbstzweifeln der eigenen Interessen und Pers nlichkeit Identit t vs Beziehung en ber Explosiver wird das Gemisch wenn eine dritte Person hinzukommt und ein Dreieckskonflikt entsteht geh rigkeit Gemeinsamkeiten und Loyalit t in Frage gestellt werden Sechs Unterarten Untergruppenkonflikt Wenn Mitglieder ausgeschlossen werden Rangkonflikt Verteilung der R nge neue Mitglieder kommen dazu Normierungskonflikt Mitglied verst sst gegen die Spielregeln Integrationskonflikt Neues Mitglied wird nicht richtig eingef hrt Substitutionskonflikt Ersatzprobleme werden geschaffen Loyalit tskonflikt Angriff von aussen gegen ein Mitglied Zwei oder mehrere Parteien wollen dasselbe erhalten Seite 102 C C HOCHSCHULE LUZERN Technik amp Architektur Zielkonflikt Mit einer Sache oder einem Vorhaben werden widerspr chliche Ziele verfolgt Rollenkonflikt Neuverteilung von Kompetenzen Organisationskonflikte S
145. nis Selbstmanagement Teamf hrung Kommunikation sowie Konfliktmanagement a iil a d Tabelle 6 Ausbildungen bei SRF und tpc Ich habe den Kurs Train the Trainer besucht bevor ich ca sechs Schulungen durchgef hrt habe Die internen Ausbildungen werden von sehr kompetenten KursleiterInnen durchgef hrt und entsprechend werden diese Trainings auch sehr gut besucht Feedback nach Carmen Thomas Diese Feedback Technik haben wir im Kurs Train the Trainer kennengelernt Mindestens 1 Teilnehmer f llt w hrend des Trainings die Feedback Tabelle im Uhrzeigersinn aus Das Feedback wird dem Trainer direkt nach dem Training bergeben damit noch Zeit f r allf llige Fragen bleibt 1 Wichtig 2 Offen 4 Erfreulich 3 St rend Tabelle 7 Feedback nach Carmen Thomas Feedback Formular f r Kurse Transferarbeit Urs Zihlmann Seite 14 Lucerne University of Applied Sciences and Arts HOCHSCHULE LUZERN Technik amp Architektur Bei Trainings und Kursen verwenden SRF und tpc Ausbildung ein Formular welches jeder Teilnehmer nach dem Kurs ausf llt Die Formulare werden zusammengetragen und dem Trainer ein paar Tage sp ter zugestellt Bei neu erstellten Kursen werden die Feedbacks in kleinen Gruppen Trainer und Ausbildungsverantwortliche besprochen um den Kursablauf allenfalls anzupassen Daher kann das Feedback der Teilnehmer grossen Einfluss auf die n chsten geplanten Kurse haben reranstanung Eintunrung Upen Me
146. ntwicklung bei strategischen berlegungen eines Unternehmens beim L sen von konkreten Problemstellungen privat oder in Ihrem Unternehmen bei der Planung unseres Urlaubs zum einfachen Fragenstellen bei der L sung eines Kundenproblems und bei sehr vielem mehr Ich glaube nicht dass Kreativit t die Gabe einer guten Fee ist Ich glaube sie ist eine Fertigkeit die wie Autofahren ge bt und gelernt werden kann Wir halten die Kreativit t nur f r eine Gabe weil wir uns nie bem ht haben sie als Fertigkeit zu ben Kreativit t lernen Alle Menschen haben die Anlage dazu kreativ zu sein Unterschiedlich ist allein wie stark oder schwach diese Anlage ausgepr gt ist Wenn Sie Ihre Kreativit t steigern wollen setzen Sie sich ein Ziel Denn ohne das Ziel hat das Unterbewusstsein keinen Grund kreativ zu sein In der Gruppe ist 66 L bach 1976 67 Siehe http www netzwerk design at 305_DEU_HTML php 12 07 2013 68 Siehe http www zeitzuleben de 2452 kreativitat was ist das eigentlich 12 07 2013 Edward de Bono Kreativit tscoach Transferarbeit Urs Zihlmann Seite 41 LUZERN Technik amp Architektur C Lk C HOCHSCHULE man meist kreativer als alleine denn mehr K pfe generieren auch mehr Ideen z B Brainstorming Die besten Ideen entstehen meist nicht im Sitzungszimmer sondern an Orten wo wir uns wohl f hlen besser entspannen und den Gedanken freien Lauf lassen Eine weitere wichtige Vora
147. ommunikation in Projekten In unserer Abteilung versuchen wir klar und vor allem h ufig zu kommunizieren Trotzdem kommt es immer wieder vor dass Teammitglieder ber laufende Projekte schlecht informiert sind oder interne Abl ufe nicht kennen Eine weitere Herausforderung ist dass wir als technische Abteilung auch oft in Fachsprache kommunizieren und zu wenig nachfragen ob das Gesagte oder das Geschriebene auch wirklich verstanden wurde Diese Tipps helfen Missverst ndnisse und Fehler zu vermeiden Rufen Sie an wenn etwas besonders wichtig ist Fassen Sie Telefonate in wenigen Worten zusammen Schicken Sie diese Ihrem Kommunikationspartner zur Kenntnisnahme Eine Outlook Lesebest tigung bedeutet nicht dass die Person ihre Mail gelesen und verstanden hat Fragen Sie nach wenn Sie eine Best tigung brauchen Setzen Sie nichts voraus und machen Sie auch keine allgemeinen und logischen Annahmen Wenn es ganz heikel wird sollte der Gespr chspartner mit seinen Worten das Besprochene nochmals wiedergeben Dies ist besonders bei unterschiedlichen Kulturen und Sprachen hilfreich Seien Sie nicht geizig mit Lob Bleiben Sie freundlich und zeigen Sie Humor Pr sentationen Trainings und Kurse Die 7 Superuser Regeln Aus den internen Kursunterlagen habe ich die sieben wichtigsten Regeln notiert Diese Regeln sollen in zuk nftigen Trainings ber cksichtigt werden Insbesondere bei der Vor aber auch bei der Nachbearbeitung sollen zu
148. onnnnnsnnennnnnnrnnnnennsorennnnnnrsonnennnnnnnnn 29 Abbildung 8 Beispiel eines Projektstrukturplans bei eMecdia nesen nnn 32 Abbildung 9 Beispiel Stakeholder Analyse AA 33 Abbildung 10 Der Probleml eungstprozess tare rennnneeene nnmnnn ennnen nenn 37 Abbildung 11 Warum IT Projekte scheitern 2244400444444400nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn 46 Abbildung 12 Kommunikationsprobleme beim Requirements Engineering essssesessssreesssernnrsrrrrnrnserrnnnnnserennnn 47 Abbildung 1 3 El ee TEE 50 Abbildung 14 Die Essenz des Requirements Engineering 51 Abbildung 15 Umfassende Satzschablone AAA 52 Abbildung 16 Anforderungen im reclmmlnes tunnet nnnnnnsenn nnet rnnn terene nn nnseene mnnn n nennen ennn 57 Abbildung 17 Anforderungen mit Gatzschablone 57 Abbildung 18 berblick der Software Qualit ts Module s s se snsersisr1siststtsteitstsitstsitsinitnnsientsiennatansnenesnnnenen nne 59 Abbildung 19 Review Typen u n u 0ee aan ea 62 Abbildung 20 Formale Review Typen Situationen und Anwendungen nme 62 Abbildung 21 Entwicklungsmodell V Modelt A 64 Abbildung 22 Cyclomatic Complex yiera rra anea aE a ENEE ENET 66 Abbildung 23 Beispiel einer PHeview Definttlon 67 Abbildung 24 Beispiel eines Testkonzepts nossnnessosseneneeeeennteeernnteteetnntseennnnnnsennn neet rnnnnnetennnnseene mnane enn ennenen 68 Abbildung 25 Prozess Schritte in einem TestprozesS A 69 129
149. ossene Review Protokoll f r die Reviewer Walkthrough Der Ablauf bei einem Walkthrough ist hnlich wie beim Document Control mit dem Unterschied dass am Schluss eines Reviews nicht nur die Findings besprochen werden Der Walkthrough wird bei komplexen technischen Fragstellungen eingesetzt Inspection Die Methode Inspection wird beim Review von kritischen Teilen eines Arbeitsprodukts z B funktionale Sicherheit eingesetzt Es wird ein vollst ndiges Review durchgef hrt das heisst dass der Aufwand sehr hoch ist und nur in Ausnahmef llen gemacht wird z B 50 eLoC h Entwicklungsmodelle Ziel Verst ndnis f r die Zusammenh nge der Arbeitsprodukte in einem definierten Entwicklungsmodell entwickeln Kernfragen Welches Entwicklungsmodell verwenden wir Wie wird dieses Entwicklungsmodell gelebt Entwicklungsmodelle stellen die verschiedenen Phasen von Software Entwicklung und Tests sowie deren Beziehungen Software Entwicklungszyklus dar Das V Modell ist ein Entwicklungsstandard bei welchem die Aktivit ten und Ergebnisse definiert werden Eine strikte zeitliche Abfolge wird im Gegensatz zu den klassischen phasenorientierten Vorgehensmodellen nicht gefordert Transferarbeit Urs Zihlmann Seite 63 C C HOCHSCHULE LUZERN Technik amp Architektur Arbeitsprodukte Pr fmassnahmen Abbildung 21 Entwicklungsmodell V Modell F r jede Software Entwicklungs Phase werden spezifische Pr fmassnahmen angewendet So wir
150. osten von WAG zu hoch Netzwerk Impacts wegen schlechter VPN oder Proxyserver Performance Projektverz gerung durch lange Entscheidungswege Netzwerk Storage Prozesse Use Cases Use Cases k nnen in 3 Monaten nicht abgebildet werden A Auswirkung von 1 sehr gering bis 5 sehr kritisch bg M gliche Auswirkungen PP erw gt Projektausstieg Projekt wird abgebrochen Use Cases k nnten nicht bzw nur beschr nkt umgesetzt werden Projekt ger t in Verz gerung PoC Ziel verfehlt PoC ist nicht aussagekr ftig f r weitere Entscheidungen iisiko Bewertungstabell 20 40 60 90 40 W Wahrscheinlichkeit in 40 200 240 270 160 Vorbeugende Massnahmen Unterst tzung durch STEA Kosten auf Kostestellen aufteilen Projektbudget falls m glich erh hren STEA Aktive Unterst tzung durch CSP Corporate Service Provider SRG Druck durch STEA Termine m ssen von allen Projektbeteiligten eingehalten werden Allenfalls Stellvertreter miteinbeziehen Ressourcen fr h planen und einhalten Gute und klare Use Cases Ziele definieren Techn Infrastruktur vor Umsetzung der Use Cases kontrollieren und abnehmen B Bewertung A x W Die Liste habe ich kurz darauf beim STEA Meeting pr sentiert und erst an dieser Sitzung wurden mir der Sinn den Zweck und die Wichtigkeit dieser Liste wirklich bewusst Die STEA Mitglieder gingen die einzelnen Punkte durch und gaben hilfreiche
151. r germanblogs de die 10 wichtigsten rhetorischen stilmittel bedeutung und verwendung 14 11 2013 Transferarbeit Urs Zihlmann Seite 12 v C HOCHSCHULE LUZERN Technik amp Architektur Anapher Mittels Anapher kann man sehr einfach den Punkt seiner Aussage unterstreichen Hierbei wird ein Wort oder eine Wortgruppe am Anfang jedes Satzes wiederholt Ein ber hmtes Anapher Beispiel von Winston Churchill We shall go on to the end We shall fight in France we shall fight on the seas and oceans we shall defend our island Alliteration Bei einer Alliteration werden W rter wiederholt wiedergegeben wenn sie mit dem gleichen Buchstaben anfangen wie in der Wortgruppe mit w in diesem Satz Meistens soll damit ein Gef ge ein Zusammenhalt zwischen den W rtern bei einer Aufz hlung etwa verdeutlicht werden Die Sonne stand gelb gross und gleissend am Firmament Hyperbel Bei der Hyperbel wird stark bertrieben um die Aussage zu kr ftigen und dazu noch ein Vergleich in sich bereits ein rhetorisches Mittel angestellt ich bin todm de oder auch er f hrt im Schneckentempo sind typische Beispiele hierf r Metapher Eine Metapher verbildlicht eine Eigenschaft Das Erz hlte Geschriebene wird mit etwas Bekanntem verglichen und damit auf oder abgewertet zumindest aber bildlich vorstellbar gemacht Er k mpfte wie ein L we soll also das gleiche zum Ausdruck bringen wie er k mpfte mutig Paral
152. re SW Entwickler Requirements und Quality Engineer Tester Das Team ist bereits eingespielt organisiert sich selber und performt gut Die Grundfunktionalit ten u a auch System amp Datenbankarchitektur wurden bereits in Phase 1 realisiert Es sind prim r End to end Funktionalit ten welche in Phase 2 entwickelt werden wenig Schnittstellen zu anderen Teams Projekt hat eine hohe Wichtigkeit und wird vom ganzen tpc Management unterst tzt Das Team steht hinter dem Projekt und ist motiviert diesen Schritt mit diesem Projekt zu machen Die Phase 2 sollte bis Fr hling 2014 abgeschlossen sein und passt somit gut in den Zeitplan nach Abgabe der Vertiefungsarbeit Gute Voraussetzungen schaffen f r Phase 3 Einf hrung eines professionellen Management Frameworks bei eMedia We D D co inc Lucerne University of Applied Sciences and Arts HOCHSCHULE LUZERN Technik amp Architektur 8 F HRUNG IM PROJEKT Datum Dozent R ckblick auf den Unterricht 25 26 10 2013 Gabriele Kaspar Roland Haas Herbert K ng Transferarbeit Urs Zihlmann Seit ein paar Jahren h rt man vermehrt von Seminaren in den Bergen mit Gruppenspielen und Team bungen Diesen Kaderanl ssen mit Teambildungseffekt stand ich jeweils kritisch gegen ber Das zweit gige Seminar auf dem Bramboden hat mich allerdings eines Besseren belehrt Dazu beigetragen hat unter anderem auch das Wetter was uns besonders bei der Outdoor
153. rgehensmodelle ist das Agile Manifest Ins Deutsche bersetzt besagt es Folgendes Wir suchen nach besseren Wegen Produkte zu entwickeln indem wir es selbst praktizieren und anderen dabei helfen dies zu tun Individuen und Interaktionen haben Vorrang vor Prozessen und Werkzeugen Funktionsf hige Produkte haben Vorrang vor ausgedehnter Dokumentation Zusammenarbeit mit dem Kunden hat Vorrang vor Vertragsverhandlungen Das Eingehen auf nderungen hat Vorrang vor strikter Planverfolgung Verallgemeinerungen im Vergleich zum Originaltext 1 Produkte hiess urspr nglich nur Software 2 Funktionsf hige Produkte hiess urspr nglich nur lauff hige Software 107 Siehe http de slideshare net dimka5 introducing agile scrum xp and kanban 01 10 2013 108 Siehe http agilemanifesto org iso de 10 10 2013 Transferarbeit Urs Zihlmann Seite 82 C C HOCHSCHULE LUZERN Technik amp Architektur Diese Verallgemeinerungen sollen deutlich machen dass agile Werte nicht nur auf Software Entwicklung anwendbar sind sondern auch auf andere Projekte bzw Produktionsprozesse Nicht von ungef hr kommen die Parallelen von Scrum zur Schlanken Produktion lean production bzw zum Toyota Produktionssystem Kanban Zu den Unterzeichnern des Agilen Manifests geh ren unter anderem Ken Schwaber Mike Beedle und Jeff Sutherland drei der Begr nder von Scrum Daneben geh ren auch bekannte Vertreter der XP
154. romi 1 1 9 1 Flucht Machtstrategie Orientierung an den Zielen der Gegenpartei Orientierung an den eigenen Zielen und Belangen Abbildung 46 Konfliktverhaltensstile nach Karl Berkel 1 1 Konflikte nicht wahrhaben wollen verdr ngen vertagen nichts h ren und sehen 1 9 Nachgeben um des lieben Friedens willen unterordnen anpassen aushalten opportunistisch das kommt schon gut die Beziehung steht im Vordergrund eigene Position verloren Beziehung vermeintlich gerettet 5 5 Kompromiss aushandeln lose lose akzeptable L sung f r beide Seiten jeder kann das Gesicht wahren verhandeln Patt Situation 9 1 Eigene Absichten durchsetzen Der Sieg wird mit allen Mitteln und auf Kosten der Gegenpartei errungen Agression Kampf Verteidigung Bestrafung Macht 147 Siehe http www proziel de mediation01 htm 30 10 2013 Transferarbeit Urs Zihlmann Seite 104 LUZERN Technik amp Architektur C Lk C HOCHSCHULE 9 9 Gemeinsame Probleml sung win win Verst ndnisvoller respektvoller Austausch mit dem Ziel ein Ideal f r beide Parteien anzustreben miteinander reden kooperieren vorbeugen vorausschauen Beizug einer Drittperson Moderator Konflikt Eskalation Um einen Stein zu zertr mmern braucht man einen Hammer um eine kostbare Vase zu zerbrechen gen gt eine fl chtige Bewegung aber um das Herz eines Menschen zu treffen gen gt oft ein einziges Wort Eugen Drewermann deutscher Theologe Be
155. rschiedenen Fachgebieten zu erlernen und zu verstehen Er ist derjenige der die Bed rfnisse hinter 4 Fr hauf VI 2013 S 2 5 Fr hauf VI 2013 S 2 P Siehe http www dpunkt de pdf Broschueren Rupp RE 3A_WA pdf 06 09 2013 Tanafararha Ire Zihlmanr Qaita EE Transferarbeit Urs Zihlmann Seite 55 C C HOCHSCHULE LUZERN Technik amp Architektur den Aussagen der Stakeholder erkennen und so aufbereiten muss dass fachfremde Architekten und Entwickler sie verstehen und umsetzen k nnen Zu den wichtigsten Talenten eines Requirements Engineers geh ren o Analytisches Denken Empathie Einf hlungsverm gen Kommunikationsf higkeit Moderationsf higkeit Selbstbewusstsein berzeugungsf higkeit Transfer in die betriebliche Umgebung Wie machen wir es heute Unsere Abteilung hat einen hervorragenden Ruf in der Firma und dies hat vor allem damit zu tun dass wir es immer wieder schaffen den Auftraggeber zu begeistern Kano Modell Wir versuchen grunds tzlich immer ein Goodie mitzugeben in Form eines Features einer Zusatzleistung oder eines h bschen Designs Ein angenehmer Nebeneffekt eines solchen Goodies ist dass der Kunde auch mal ein Auge zudr ckt wenn ein Termin nicht eingehalten werden kann oder ein Bug auftritt Das Erfassen der Anforderungen wird in der Regel von den Software Entwicklern ausgef hrt Der Auftraggeber trifft sich mit dem Entwickler und zusammen besprechen sie das Projekt
156. s der anschliessenden Besprechung neue Erkenntnisse gewonnen Seite 36 LUZERN Technik amp Architektur C Lk C HOCHSCHULE Probleml sungsprozess Der Probleml sungsprozess beschreibt die Arbeitsschritte die notwendig sind um zu einer L sung zu gelangen Er ist nicht nur bei der Gestaltung des Projektgegenstandes anwendbar sondern dient mit leichten Anpassungen auch zur Bew ltigung von Problemen im Projekt insbesondere bei inhaltlichen terminlichen oder Kostenabweichungen 7 Situationsanalyse Zielfindung Situationsanalyse L sungssuche Die Kernfragen o Was genau ist das Problem o Was dessen Ursachen Erna der lungen o Mit welchen Einfl ssen SAS Za Die Situationsanalyse ber cksichtigt nicht nur das was bisher war und heute ist sondern auch die erwartete Zukunft zeigt Trends auf und beinhaltet Prognosen Sie ist ausserdem offen und neutral bez glich der Ziele und L sungen In der Vorstudie werden weniger Informationen ben tigt als in der anschliessenden Konzeptphase 7 Variante 1 Variante 2 Variante 3 Abbildung 10 Der Probleml sungsprozess Elemente der Situationsanalyse Problem Neuge Methoden l sung staltung Bestehendes zu ver nderndes O Befragung Interviews System erfassen Beobachtungstechniken Bestehendes zu ver nderndes Prozesschemas Organigramme System beschreiben darstellen O Produktmerkmale Situationspl ne SWOT bewerten Analyse verbale Beschreibung Projektumfel
157. schreiten die zeitlichen Vorgaben Unklare Anforderungen und Ziele Fehlende Ressourcen bei Projektstart Politik Egoismen Kompetenzstreitigkeit Fehlende PM Erfahrung auf Leitungsebene Unzureichende Projektplanung Schlechte Kommunikation Mangel an qualifizierten Mitarbeitern Fehlende PM Methodik z B kein Risikomanagement Mangelhaftes Stakeholder Management Fehlende Unterst tzung des Top Managements 0 10 20 30 40 50 60 70 80 90 100 Abbildung 11 Warum IT Projekte scheitern Je sp ter ein Fehler in den Anforderungen im Verlauf des Entwicklungsprojekts behoben wird desto h her sind die damit verbundenen Kosten So wird beispielsweise f r die Beseitigung eines Anforderungsfehlers der erst beim Programmieren entdeckt wird ein um 20 mal h herer Aufwand angenommen f r die Fehlerbeseitigung in der Abnahmephase geht man vom Faktor 100 aus Ziel des Requirements Engineering ist es m glichst vollst ndige Kundenanforderungen in guter Qualit t zu dokumentieren und dabei Fehler m glichst fr hzeitig zu erkennen und zu beheben Warum ist Requirements Engineering schwierig _ Kunde kennt die Anforderungen selber nicht genau bzw kann sie nicht formulieren Falsche Annahmen durch Auftragnehmer O o Kunde geht davon aus dass die Anforderungen klar sind keine Abnahme der Anforderungen durch Kunden 72 Siehe http omis ch up 9 pdf 24 08 2013 73 Gesellschaft f r Projektmanagement Zei
158. sollte zuerst gut berlegt werden welche Themen f r das Projekt den gr ssten Nutzen bringen Weitere Start Brainstorming Themen Visionen Fragen Bed rfnisse Ziele Risiken Bef rchtungen Erfolgsfaktoren Kl rungsprozess mit dem Auftraggeber Die Verarbeitung des Start Brainstormings bringt Fragen und Vorschl ge f r das Gespr ch mit dem Auftraggeber hervor Die urspr nglichen Vorstellungen zum Vorhaben und zum Vorgehen k nnen dabei nochmals deutlich korrigiert werden Projektdefinition und erste Zielformulierung Die Kl rung der Ausgangslage der Rahmenbedingungen und der Projektabgrenzung f hrt zur ersten Projektdefinition der groben Umschreibung des Projektgegenstandes und der zu erf llenden bergeordneten Ziele Scheuring 2013 S 53 55 21 http www scheuring ch index php option com_content amp view article amp id 81 amp Itemid 129 17 07 2013 7 Scheuring 2013 S 57 7 Scheuring 2013 S 57 Transferarbeit Urs Zihlmann Seite 21 LUZERN Technik amp Architektur Lucerne University of Applied Sciences and Arts C DC HOCHSCHULE Beispiel einer Projektdefinition bei tpc Bei diesem Projekt Proof of Concept Adobe Anywhere sollen verschiedene Workflows auf deren praktische Einsatzm glichkeiten gepr ft werden o Vernetzung der f nf Basic Schnittpl tze o Zugriff von fliegenden Journalisten auf Archiv Material sowie bermittlung von Halb und Fertigprodukten Zugriff
159. sp ter von einigen Personen in Frage gestellt und diese wollten die Informationen aus der Evaluierungsphase einsehen Leider konnten wir nur wenige Dokumente vorzeigen was verst ndlicherweise f r weiteren Unmut sorgte 0 Transferarbeit Urs Zihlmann Seite 12 LUZERN Technik amp Architektur Lucerne University of Applied Sciences and Arts v DC HOCHSCHULE 11 PROJEKTABSCHLUSS UND LESSONS LEARNED Datum leen R ck ickautsenuntemicht TUT 13 14 12 2013 Roland Haas Zu Beginn des Unterrichts wurde die Klasse in zwei Gruppen Alfred Aschmann aufgeteilt und wir diskutierten wie Projekte in unseren Firmen abgeschlossen werden Es spielt eigentlich keine Rolle ob es sich um Bau Produkt oder Softwareprojekte handelt Der Projektabschluss ist immer eine schwierige und heikle Phase Wie der Projektabschluss bei der Grossfirma Kaba gemacht wird hat uns Alfred Aschmann erz hlt Dabei ging er vor allem auf das Thema Markteinf hrung ein An verschiedenen Beispielen erkl rte er uns das AIDA Prinzip wie auch die Wichtigkeit von Design und die Vermarktung durch Emotionen Markteinf hrung Produkt bergabe Die Markteinf hrung e ist der Zeitpunkt ab dem ein Produkt f r den Vertrieb Kunden bereit steht e beinhaltet s mtliche Anstrengungen eines Unternehmens den wirtschaftlichen Erfolg eines Produkts oder einer Dienstleitung am Markt zu erzielen AIDA Die Markteinf hrung ist ein Event um das Int
160. ss vor der Anwendung angepasst werden Tailoring Die einzelnen Tests im V Modell werden im Kapitel Requirements Engineering beschrieben Spezifikation Test Abbildung 35 V Modell 104 Siehe http www torsten horn de techdocs sw dev process htm 02 10 2013 Transferarbeit Urs Zihlmann Seite 80 Lucerne University of Applied Sciences and Arts C C HOCHSCHULE LUZERN Technik amp Architektur Umfassendes Modell Zu allgemein und generisch Integriert viele Aspekte des Entwicklungsprozesses Nicht f r kleine Projekte geeignet Erweiterbar und anpassbar Ben tigt unbedingt gute CASE Tools in der Softwareentwicklung Wieso so viele verschiedene Modelle Grunds tzlich hat jedes Vorgehensmodell seine Daseinsberechtigung Je nach Projekt Branche Umfang und gesetzliche Rahmenbedingungen muss die passende Methode ausgew hlt werden Agile Modelle THAT MEANS NO MORE PLANNING AND NO MORE DOCUMENTATION JUST START WRITING CODE AND COMPLAINING WERE GOING TO TRY SOMETHING CALLED AGILE www dilbert com scottadams aol com 0 2 0 2007 Scott Adams Inc Dist by UFS Inc Abbildung 36 Dilbert Agile Programming Probleme traditioneller Methoden F r viele Unternehmen war es lange Zeit undenkbar sich von klassischen Vorgehensweisen zu verabschieden Das Vorgehen ist dabei immer hnlich So wird bei klassischen Vorgehensweisen die auf der Genauigkeit der Planung basieren unter anderem davo
161. st desto besser stehen Ihre Chancen den harten Kern zu brechen Finden Sie die richtigen Leute die richtigen Dienstleister und die richtigen Produkte Alles wird einfacher wenn f hige Mitarbeiter an den entsprechenden Hebeln sitzen Informieren Sie sich zuerst ber die Auslastung der Kollegen Die Auswahl der Mitarbeiter erfolgt in Zusammenarbeit mit den Vorgesetzten der Linienorganisation Achten Sie darauf dass das Team auch menschlich funktioniert Investieren Sie gen gend Zeit in den Aufbau und die Pflege von Beziehungen Passen Sie das Team an ver nderte Ziele und Bed rfnisse w hrend der Projektabwicklung an finition Das Ziel ist der erste Schritt hin zum Projekterfolg Tipps f r die Zieldefinition mit dem Auftraggeber e Beginnen Sie mit Ihrem Projekt erst wenn Sie sich mit Ihrem Auftraggeber auf ein Ziel verst ndigt haben e Ist das nicht m glich dann kann es auch ein Ziel sein zun chst den Projektauftrag als solchen zu Geirhos 2011 S 16 50 Siehe http de wikipedia org wiki Projektorganisation 25 11 2013 51 Geirhos 2011 S 27 Transferarbeit Urs Zihlmann Seite 34 v C HOCHSCHULE LUZERN Technik amp Architektur erarbeiten Das w re selbst wiederum ein Projekt Lassen Sie sich vom Auftraggeber das Ziel erkl ren Erkl ren Sie selbst dem Auftraggeber das gesteckte Ziel Er sollte es dann zweifelsfrei wiedererkennen k nnen Eine gute Zielbeschreibung ist konkr
162. tabile Gruppe oder Abteilung wird mit einer anderen konfrontiert bergeordnete Ziele auch Herrschaftskonflikte zwischen Hauptsitz und Tochtergesellschaften oder Filialen Mobbing Grobes Fehlverhalten gegen eine Person gerichtete Angriffe ber eine l ngere Zeit hinweg Tabelle 22 Die acht Konfliktarten Konflikttypen Das richtige Erkennen eines Konflikttyps ist eine wichtige Voraussetzung f r die Konfliktbew ltigung Bei beiden Typen geht es um die dominierenden Verhaltensweisen das heisst wie die Parteien einen Konflikt miteinander austragen 17 Heisse Konflikte Heisse Konflikte sind offen ausgetragene und offen erkennbare Konfrontationen die vor allem dadurch gekennzeichnet sind dass eine Partei die jeweils andere von ihrem Standpunkt berzeugen oder zu einer jeweils pr ferierten L sung dr ngen m chte Heisse Konflikte haben den Vorteil dass sie erkennbar und damit auch leichter zu handhaben und zu l sen sind Kalte Konflikte Kalte Konflikte sind weitgehend unsichtbare und mit subtilen Mitteln der Sabotage Blockade und Verz gerung gef hrte Auseinandersetzungen in denen es oft prim r nur noch darum geht die andere Partei zu sch digen Kalte Konflikte sind oft das Ergebnis fr herer heisser Konflikte bei denen es zu keiner oder zu keiner befriedigenden L sung gekommen ist und die Beteiligten daher vor allem frustriert und desillusioniert sind was die M glichkeit einer einvernehmlichen L sung angeht
163. takeholder sind neben weiteren Faktoren eine wichtige Quelle f r Anforderungen Das bersehen von Stakeholdern hat h ufig zur Konsequenz dass Anforderungen an das System l ckenhaft sind oder g nzlich fehlen Stakeholder sind also alle diejenigen Personen oder Organisationen die Anforderungen in irgendeiner Weise beeinflussen 7 NDoak meante DOKU HIGI Eine weitere Anforderungsquelle sind Dokumente wie z B Normen Standards branchen organisationsspezifische Dokumente oder auch Fehlerberichte von bestehenden Systemen Alt Vorg nger oder auch Konkurrenzsysteme k nnen ebenfalls als Anforderungsquelle dienen Die Erhebungstechniken dienen dazu das Wissen und die Anforderungen der Stakeholder zu ermitteln Die folgende Tabelle enth lt die g ngigsten Techniken wobei je nach Projekt auch eine Kombination von Ermittlungstechniken angewendet werden kann Technik Interview Fragebogen Kreativit tstechniken Beobachtungstechniken Dokumentenzentrierte Techniken Wiederverwendung Vorteile Eignung viele Informationen richtiges Verst ndnis berpr fbar spezifische und aktuelle Ergebnisse grosse Teilnehmerzahl erreichbar Erstellung braucht grosses Vorwissen viele Ideen in kurzer Zeit geeignet f r Vision Features identifizieren zeigt aktuelle Situation selbstverst ndliches wird festgehalten Wissen wird bewahrt Informationssammlung ohne Mitarbeit von Stakeholdern Reduzierter Aufwand Rad m
164. tes Sprint Backlog a Is d Product Owner und Teammitglieder aktualisieren mindestens einmal im Sprint das Product Backlog Dabei werden Backlog Items mit neuen Sch tzungen versehen und neue Backlog Items in das Product Backlog aufgenommen Gleichzeitig wird die Reihenfolge der Backlog Items angepasst indem die neuen Informationen ber cksichtigt werden Dieses Meeting dient auch dazu den Releaseplan des Projektes zu aktualisieren und zu vervollst ndigen Sprint Review 4 Stunden Team Team ScrumMaster Product Owner G ste Stakeholder andere Scrum Teams Pr sentation der Funktionalit ten Am Ende des Sprints pr sentiert das Team die erarbeiteten Funktionalit ten Das Team zeigt nur die Funktionalit ten die so weit sind dass sie sofort produktiv eingesetzt werden k nnten Nicht getestete oder instabile Funktionalit ten werden nicht gezeigt und gelten als nicht geliefert Sprint Retrospektive 3 Stunden ScrumMaster Team ScrumMaster Product Owner Optional Impediment Backlog Die Sprint Retrospektive erm glicht dem Team systematisch zu lernen Hier wird analysiert welche Arbeitsprozesse verbessert werden m ssen damit das Team effektiver arbeiten kann Die Resultate aus der Retrospektive werden im Impediment Backlog festgehalten und lassen sich so als Verbesserungsvorschl ge in das Sprint Planning einbringen Fragen o Was haben wir gelernt o Was l sst sich verbessern Transferarbeit Urs Zihl
165. tigt sind lohnt es sich einen Blick auf die Liste zu werfen und gleich zu versuchen einige Punkte anzuwenden Verlier das Kurs Trainings ziel nie aus den Augen Schaffe einen klaren und attraktiven Einstieg gib den Teilnehmer innen einen Ausblick Roadmap Respektiere ihre anf ngliche Unsicherheit und nimm dich ihrer an Behandle die Teilnehmer innen mit H flichkeit und Aufmerksamkeit Tritt korrekt gekleidet und gepflegt auf Du hast einen Auftritt Behalte die Zeit im Auge und verhandle sie flexibel Hetze nicht auch nicht dich selber Zwischenfragen zulassen und wenn immer m glich sofort beantworten Immer wieder nachhaken ob es noch Fragen gibt Strukturiere den Kurs bersichtlich und transparent niemand schwimmt gern im Ungewissen Rede deutlich laut und klar Wende dich dem Publikum immer zu wenn du sprichst Geduld Geduld Geduld Du hast den Stoff schon verstanden deine Teilnehmer innen noch nicht Nicht alle lernen gleich schnell Sei wachsam und behalte ALLE im Auge deiner Aufmerksamkeit Gibt es Teilnehmer innen die du nicht m gen solltest lass sie es nicht merken Gibt es schwierige Teilnehmer innen bleib freundlich best tige lass dich nicht provozieren F rdere St rken und hacke nicht auf Schw chen herum Lass die Teilnehmer so viel wie m glich selber erkennen lernen und ausprobieren Wann immer m glich schaffe Erlebnisse f r alle Sinne der Teilnehmer innen Frag nach wenn du nicht sicher b
166. tionsf higkeit sowie den zu betreibenden Anpassungsaufwand Maturity Ausgereiftheit eines Produktes Erfahrungen des Herstellers des Lieferanten Support Leistungen seitens des Herstellers Lieferanten Continuity Technologische und wirtschaftliche Stabilit t Beurteilungskriterien aufstellen Ziel e Rating aus Anforderungen Beurteilungskriterien L sungen Vorgehen e Beurteilungsverfahren festlegen e Dokumentation Ergebnis e Beurteilungsverfahren Beurteilungstabelle Das Priorit ten Erf llungsgrad Modell Bei diesem Modell wird die Priorisierung mit dem Erf llungsgrad multipliziert Die Summe aller Anforderungen ergibt den Erf llungsgrad Wenn sich die Werte nicht massiv unterscheiden eignet sich dieses Modell nur bedingt In diesem Fall m sste die Priorisierung angepasst werden damit es einen eindeutigen Gewinner gibt oder man grenzt die Anforderungen so ein dass beispielsweise nur die h her gewerteten Anforderungen ber cksichtigt werden P Software 1 Software 2 Software 3 Software 4 Anforderung 1 4 2 2 2 1 Anforderung 2 4 3 2 1 1 Anforderung 3 2 1 1 2 2 Anforderung 4 1 1 1 2 2 Total 23 19 18 14 Tabelle 30 Das Priorit ten Erf llungsgrad Modell Erf llungsgrad F r jeden Bereich sollte die Begr ndung der Anforderung in Bezug auf den Erf llungsgrad angepasst werden Transferarbeit Urs Zihlmann Seite 120 LUZERN Technik amp Architektur C p C HOCHSCHULE Generelle Struktur 0 Nicht erf
167. treten darf Testautomatisierung Regressionstests der Software werden in der Regel viele Male wiederholt Um den Aufwand so gering wie m glich zu halten sollten diese Tests automatisiert ausgef hrt werden Testprozess Testplanung Testspezifikation Testausf hrung Test Reporting Inkrement 1a Inkrement 1b Inkrement 1c LET Wa 1 Test aller sicherheits relevanten Funktionen Test der grundlegen den Software Funktionen Zeit Test aller behobenen Software Fehler Abbildung 30 Regressionstest Transferarbeit Urs Zihlmann Seite 74 C C HOCHSCHULE LUZERN Technik amp Architektur Fehlermanagement Ziel Aktivit ten und Rollen im Fehlermanagement gestalten Kernfrage Wer ist f r die Schliessung einer Fehlermeldung nach einer erfolgreichen Behebung verantwortlich Jedes unerwartete Ereignis eng incident das w hrend des Testens auftritt und weitere Analysen und Korrekturen nach sich zieht wird als Fehlermeldung erfasst Informations Neue Nach anforderung Marola Zuweisung arbeitung een Tester Tester Task Force Change Control Entwickler Tester Test Manager Board Test Manager N N getestet entdeckt gt erfasst gt anaysiet gt zugewiesen e gel st geschlos sen zur ckgewiesen zur ckgestellt weitergeleitet Verfolgung Messung Reporting Quality Manager Abbildung 31 Aktivit ten Rollen und Status im Fehlermanag
168. tschrift IT Business 3 2005 74 Siehe http www dpunkt de pdf Broschueren Rupp_ RE 3A_WA pdf 26 08 2013 Transferarbeit Urs Zihlmann Seite 46 Lucerne University of Applied Sciences and Arts HOCHSCHULE LUZERN Technik amp Architektur Kulturelle Differenzen Es sind nicht alle Stakeholder bekannt Zielkonflikte Systemgrenze nicht klar Kommunikationsprobleme Bei einem Projekt treffen mindestens vier verschiedene Welten aufeinander So gibt es auf der Anwendungs und L sungsseite jeweils eine System und Prozesssicht f r den Projekt Beginn und das Projekt Ende In diesen vier Welten muss der Requirement Engineer denken schreiben und sprechen k nnen How the customer explained it understood it How the project leader How the programmer How the business wrote it consultant described it How the project was What operations installed How the customer was How it was supported What the customer really documented billed needed Abbildung 12 Kommunikationsprobleme beim Requirements Engineering Transferarbeit Urs Zihlmann Seite 47 LUZERN Technik amp Architektur Lucerne University of Applied Sciences and Arts v DC HOCHSCHULE Anforderungserhebung Wozu brauchen wir Anforderungen Damit das Vorhaben Soll Zustand bekannt ist Wissen und verstehen was zu tun ist Gemeinsames Projektverst ndnis Grundlage f r Aufwandsch tzung Risikoanalysen Projektpl ne Entwicklungsauftr
169. ttfindet Der erste Satz von Anforderungen muss unbedingt die Basisfunktionalit ten des Produkts abdecken so dass m glichst fr h mit der Entwicklung gestartet werden kann Sp tere Anforderungen w rden in einem anderen Release ber cksichtigt werden Beim Erfassen und Definieren von Anforderungen sollen Satzschablonen helfen einfach zu verstehende Anforderungen zu schreiben Eine Abnahme durch den Kunden halte ich im Moment nicht f r zwingend erforderlich In einem aktuellen Projekt hat ein Mitarbeiter die folgende Schablone eingesetzt und dies scheint mir ein guter Weg zu sein wie in Zukunft alle Anforderungen geschrieben werden k nnten 2339 UseCase New Normal ich m chte Termine auch nicht ganztags machen k nnen 2338 UseCase New Normal Ich m chte Mandanten verwalten 2335 UseCasse New Normal Ich kann sehen wie H ufig ein Projekt pro Ressource in der angzeigten Periode verwendet wurde Abbildung 17 Anforderungen mit Satzschablone Transferarbeit Urs Zihlmann Seite 57 inc 6 SOFTWARE QUALIT T Datum Dozent R ckblick auf den Unien 22 24 08 2013 21 09 2013 Sven Koos 8 Koos 2013 Transferarbeit Urs Zihlmann Lucerne University of Applied Sciences and Arts HOCHSCHULE LUZERN Technik amp Architektur Der Unterricht bei Sven Koos war anspruchsvoll aber sehr interessant Da ich bisher noch fast keine Erfahrungen in diesem Gebiet sammeln konnte hatte ich teilweise M he dem Unterricht zu fol
170. twareentwicklung geeignet Ich war noch in keinem Projekt dabei bei dem der Kunde bei Projektstart exakt formulieren konnte was er berhaupt wollte und wie er sich das Produkt vorstellte Wenn die Anforderungen flexibel sein m ssen dann sollte es der restliche Teil der Projektplanung auch sein Von den anderen Vorgehensmodellen ist mir nur ITIL ein Begriff Diese Methode versuchen wir bei uns einzuf hren allerdings bin ich an diesem Projekt nicht direkt beteiligt Die Apollo Schulung zu ITIL hat aber auf jeden Fall Spass gemacht Die restlichen Vorgehensmodelle Hermes Prince2 CobiT etc kannte ich bisher nicht Sie konnten mich im Unterricht zumindest im Hinblick auf die Gegebenheiten in unserer Abteilung aber nicht berzeugen Von den Themen in dieser Arbeit sehe ich bei den Vorgehensmodellen das gr sste Umsetzungs Potential weshalb in meiner Vertiefungsarbeit die Themen rund um Scrum und XP behandelt werden Der Bereich Softwareentwicklung w rde die Anforderungen f r eine Scrum Einf hrung sehr gut erf llen Zum einen erstellt dieses Team gr sstenteils End to end Funktionalit ten und andererseits nehmen die Projekte mit komplexen Anforderungen an Funktionsumfang und Technologien stetig zu Weitere Vorteile sind dass die Softwareentwickler sehr offen gegen ber neuen Technologien und Arbeitsweisen sind und diese Projekte wenige Schnittstellen zu anderen x C HOCHSCHULE LUZERN Technik amp Architektur
171. uationsvorgehen wurden die Ziele das Vorgehen und das Ergebnis in wenigen Worten erkl rt S mtliche Informationen stammen aus den Folien von Andreas Kurmann Ein Kritikpunkt gilt der Aktualit t des Unterrichtsstoffes So stammen einige Grafiken aus den Jahren 2004 oder fr her Marcel Bieri hat uns in einem halben Unterrichtstag ber die juristische Aspekte und Vertr ge aufgekl rt Der Unterricht orientierte sich an vier Tools die uns helfen sollen dass die Wunschvorstellung m glichst nahe an die Realit t herankommt Diesen Prozess bzw Ablauf werde ich in dieser Zusammenfassung versuchen verst ndlich darzustellen Die Folien bestehen gr sstenteils aus Grafiken und Schemas Normalerweise begr sse ich es wenn wenig Text auf Folien ist aber in diesem zumindest f r mich fremden Gebiet w re es w nschenswert gewesen dass die juristischen Fachbegriffe jeweils besser erkl rt w rden Den Unterricht habe ich als interessant und abwechslungsreich empfunden Die eher trockene Materie hat uns Marcel Bieri mit vielen Beispielen aus der Praxis sehr verst ndlich vermittelt Bei den bungen zum Schluss des Unterrichts konnten wir einige F lle anhand der vier Tools und des OR versuchen zu l sen Seite 117 LUZERN Technik amp Architektur Lucerne University of Applied Sciences and Arts C DC HOCHSCHULE Evaluation von Standard Software Die richtige Software ausw hlen heisst ein Produkt zu finden welches
172. uf welche Teamrollen am besten zu einem passen Bei mir war die Teamrolle Spezialist am ausgepr gtesten Die Teilnehmer mit den gleichen Auspr gungen besch ftigten sich daraufhin mit den Fragen o Welche Schwierigkeiten hat diese Rolle Was w re ein m glicher L sungsansatz Was sind die Herausforderungen f r den Vorgesetzten Anregungen an andere Rollentypen Si E Am zweiten Tag gab uns Gabriele eine Einf hrung in Konfliktmanagement Besonders interessant war die praktische bung Sie schilderte uns verschiedene Situationen und wir mussten schweigend entscheiden ob es sich um einen Konflikt Seite 96 v C HOCHSCHULE LUZERN Technik amp Architektur handelt oder nicht Es kam nur einmal vor dass alle die gleiche Wahrnehmung hatten und auf der gleichen Seite standen Wir besch ftigten uns auch mit den Merkmalen Chancen und den unterschiedlichen Typen von Konflikten Im n chsten Teil arbeiteten wir mit der Analyse der Eskalationsstufen Diese drei Phasen und neun Stufen helfen Konflikte besser verstehen und messen zu k nnen um allf llige Auswirkungen vorauszusehen Ein Video mit einem Streitgespr ch zwischen drei Gesch ftsabteilungen bot uns die Gelegenheit die Phasen und Stufen anzuwenden Hier tendierten die meisten zur berbewertung Im Durchschnitt lagen wir 1 2 Stufen zu hoch Das n chste Thema waren die f nf Antreiber Psychohygiene Diese Analyse haben wir im Voraus ausgef llt so dass wir g
173. und dessen Anforderungen Wenn ein Projektauftrag erstellt wird je nach Projektgr sse werden die Ziele ausformuliert und vom Auftraggeber unterschrieben F r das Erfassen von Anforderungen benutzen wir fast ausschliesslich die nat rlichsprachige Dokumentation welche leider auch Missverst ndnisse und somit Fehler in den Anforderungen mit sich bringt Dies sieht man besonders oft wenn der Auftraggeber und der Entwickler auf einer anderen Ebene miteinander kommunizieren Je weniger der Entwickler von der Arbeit den Prozessen des Auftraggebers versteht oder je weniger der Auftraggeber von der Technik versteht desto gr sser ist die Gefahr von falsch erfassten Anforderungen Deshalb ist es hilfreich wenn Entwickler auch die Produktions und Arbeitsprozesse der Arbeitgeber kennen und ihre Sprache verstehen und sprechen k nnen Damit der Kunde die ausformulierten Anforderungen versteht werden diese in Business Sprache erfasst und sollten keine technischen Fachbegriffe enthalten Die dokumentierten Anforderungen fliessen in unser Ticketsystem redmine Eine Anforderung wird somit durch mindestens ein Arbeitspaket abgebildet 97 Siehe http www dpunkt de pdf Broschueren Rupp RE 3A_WA pdf 26 08 2013 Transferarbeit Urs Zihlmann Seite 56 Lucerne University of Applied Sciences and Arts HOCHSCHULE LUZERN Technik amp Architektur 1352 Feature New Normal Einbindung Onairdesign 27 06 2013 15 43 1351 Feature New Normal Dateinamen
174. uss nicht immer neu erfunden werden Nachteile hoher Aufwand beschr nkte Zahl von Teilnehmern h ufig schlechter R cklauf ungeeignet f r offene Fragen nicht geeignet f r komplexe Probleme und pr zise Anforderungen hoher Aufwand Veraltetes wird hin bergerettet Aktualit t und Vollst ndigkeit nicht immer gew hrleistet Aufwand Investition in Anforderungen guter Qualit t in Projekt 76 Siehe http www dpunkt de pdf Broschueren Rupp RE 3A_WA pdf 26 08 2013 77 Siehe http www dpunkt de pdf Broschueren Rupp RE _3A_WA pdf 26 08 2013 78 Fr hauf II 2013 S 23 LUZERN Technik amp Architektur C p C HOCHSCHULE Kano Modell Die Methode des Kano Modells zeigt auf wie sich die Zufriedenheit der Stakeholder zusammensetzt Dazu werden die Anforderungen der Stakeholder in drei Gruppen strukturiert um so ihren Einfluss auf die Zufriedenheit zu bestimmen unterbewusstes sind selbstverst ndlich vorausgesetzte Wissen Systemmerkmale bewusstes Wissen sind die explizit geforderten Systemmerkmale unbewusstes Wissen sind Systemmerkmale die der Stakeholder nicht kennt und erst w hrend der Benutzung als angenehme und n tzliche berraschungen entdeckt Tabelle 16 Kano Modell 8 Begeisternde Mit der Zeit werden Zufriedenheit Faktoren _ begeisternde Faktoren zuLeistungsfaktoren _ und schlie lich zu Basisfaktoren Leistungs faktoren Erf llungsgrad
175. ussetzung f r Kreativit t ist Selbstvertrauen Trauen Sie sich kreativ zu sein Konkurrenz und Zeitdruck sowie schlechte Rahmenbedingungen sind Kreativit tskiller 2 Transfer in die betriebliche Umgebung Aha var chen wil Jedes Projekt durchl uft mindestens einmal den Probleml sungsprozess Wie die einzelnen Schritte in diesem Prozess Problem Aufgabenstellung Situationsanalyse L sungssuche Bewertung der L sungen und Entscheid bearbeitet werden h ngt stark vom Projekt und dessen Projektleiter ab Meine Erfahrungen waren jeweils dass die ersten drei bis vier Schritte in kurzer Form beschrieben und dem Steuerungsausschuss STEA pr sentiert wurden Diese Schritte erarbeiteten wir selten in Gruppen sondern sie wurden alleine durch den Projektleiter niedergeschrieben Der Entscheid wurde durch den STEA gef llt und hinter diesen Entscheid musste sich das ganze Projektteam stellen War dies nicht der Fall lag es am Projektleiter die Unstimmigkeiten zu kl ren damit es nicht zu Unruhen im Projekt kam Nach dem Unterricht bei Martin Iseli machte ich mir Gedanken wie und wo unsere Abteilung mit Designaspekten zu tun hat und ich war selber berrascht dass es nahezu in allen Bereichen von eMedia Ber hrungspunkte gibt Die folgende Tabelle verdeutlicht dies an einigen Beispielen Multimedia Screen und Verpackungsdesign Navigationskonzepte z B DVD Menu Usability Hardwareentwicklung Div
176. v diplomatisch diszipliniert verl sslich effektiv gewissenhaft p nktlich selbstbezogen engagiert Fachwissen z hlt 133 Siehe http teamentwicklung lab de belbin teamrollen 29 10 2013 134 Kaspar II 2013 S 1 zul ssige Schw chen oft gedankenverloren oft zu optimistisch kann als manipulierend empfunden werden ungeduldig neigt zu Provokationen mangelnde F higkeit zur Inspiration unentschlossen in kritischen Situationen unflexibel ber ngstlich delegiert ungern verliert sich oft in technischen Details C C HOCHSCHULE LUZERN Technik amp Architektur Der Belbin Test kann als PDF heruntergeladen werden Was bringt die Zuordnung zu den Belbin Teamrollen Menschen lernen wie sie mit anderen Typen besser umgehen und kommunizieren k nnen sie lernen wer sie sind und wie wichtig Vielfalt im Team ist sie verstehen warum Vielfalt Menschen Stress bereiten kann und wie man trotzdem gut miteinander arbeiten kann F hrungskr fte k nnen die Teammitglieder ad quater einsetzen die F hrungskraft kann in Einstellungsverfahren auf die richtigen bzw die noch fehlenden Rollen achten Teams k nnen leistungsf higer werden Teammitglieder erhalten einen umfangreichen Eindruck ihrer St rken und Schw chen Werden Theorie Test und Auswertung gut eingef hrt erhalten sie auch hilfreiche Hinweise zu ihren Entwicklungspotentiale Merkmale Unterschied zwischen Pannen und Konflikt
177. ver ffentlich 1 Perfekte Projektorganisation und Multitasking Wo Projektleiter ihre Zeit haupts chlich damit verbringen wichtige Informationen zusammenzusuchen anstatt ihre Projekte effektiv und effizient zu managen ist der Misserfolg vorprogrammiert 2 Verantwortung und Projektf hrung bernehmen In Projekten geht es darum s mtliche Projekt Stakeholder zum Projekterfolg zu f hren Dabei m ssen Risiken und Widerst nde bewusst gemacht im Auge behalten und wo m glich eliminiert neutralisiert werden Erfolgreiche Projektleiter schaffen es eine Zukunftsvision zu gestalten und ihr Team daf r zu begeistern 3 Gute und effiziente Kommunikation Gute Projektkommunikation stellt sicher dass s mtliche Projektmitarbeitenden mit derselben Vision auf die gleichen Projektziele hinarbeiten Sie kommunizieren Status nderungen gute wie auch schlechte Nachrichten Sie f rdern generell den Informationsfluss im Projektteam wie auch zu s mtlichen Stakeholdern und kommunizieren die Inhalte zielgruppengerecht t 42 3 Haas 2013 S 74 Scheuring 2013 S 78 Haas 2013 S 76 42 Siehe http www cio com article 726888 7_ Must Have Project Management Skills for_IT_Pros 24 07 2013 Transferarbeit Urs Zihlmann Seite 27 C C HOCHSCHULE LUZERN Technik amp Architektur 4 Erfolgreiches Verhandeln zur richtigen Zeit Projektmitarbeitende arbeiten oft in mehreren Projekten gleichzeitig mit mehreren Projektmanagern Stak
178. vollst ndig CT Basisfaktoren Zeit Erf llungsgrad v llig unzureichend v llig unzufrieden z i Abbildung 13 Kano Modell Anforderungen dokumentieren Was sind die wesentlichen Gr nde f r die Dokumentation von Anforderungen Anforderungen o sind Basis f r die Systementwicklung o sind rechtlich relevant 79 Siehe http kunden zufriedenheit messen de analysieren php 28 08 2013 30 Siehe http www sophist de uploads RTEmagicC_Kano Modell jpg ipg 28 08 2013 Transferarbeit Urs Zihlmann Seite 50 Lucerne University of Applied Sciences and Arts C C HOCHSCHULE LUZERN Technik amp Architektur o sind komplex je nach Projekt o sollten allen Beteiligten zug nglich sein Diese Grafik zeigt die Essenz des Requirements Engineering Am Anfang steht der Stakeholder mit seinen Interessen und Ideen f r das Projekt Daraus leiten sich die Ziele ab und ber die definierten Ziele entsteht der Anforderungskatalog Kontext Enakan Kontextdiagramm Endknoten 4 Endknoten 2 Stakeholder Endknoten 5 Ss Attribute NS des Objekts N D Anfor e Seia Gesch fts Klassendiagramm Akteur objekt A Gesch fts funktionale Gesch fts ZE Anforderungen N objekt B Use Case Use Case b Use Case Dynamik Zustandsdiagramm Zustand 1 Use Case Use Case Diagramm Abbildung 14 Die Essenz des Requirements Engineering 81 Siehe http www dpunkt de pdf Broschuer

Transferarbeit Urs Zihlmann · HSLU iPMT

Contents

Download Pdf Manuals

Related Search

Related Contents

Transferarbeit Urs Zihlmann &middot; HSLU iPMT

Contents

Download Pdf Manuals

Related Search

Related Contents

Transferarbeit Urs Zihlmann · HSLU iPMT