Benutzer-Werkzeuge

Webseiten-Werkzeuge


se:projektmanagement

**Dies ist eine alte Version des Dokuments!**

Projektmanagement

Einführung

Übung 1.1

Gründe, warum IT-Projekte scheitern

Übung 1.2

Das Thema Projektmanagement sollte einen hohen Stellenwert bei der Entwicklung von Software vor allem bei der Teamarbeit einnehmen. Aber auch bei Soloprojekten sollte sich der Entwickler von Anfang an Gedanken über eine sinnvolle Planung und Durchführung seiner Aufgaben machen. Insbesondere auf Grund der zahlreichen Entwicklungsmethoden und Lösungsansätze für die Unterstützung der reinen Programmierung, ist es wichtig, sich gleich zu Beginn für die passende (!) Vorgehensweise zu entscheiden und diese auch im Verlauf des Projekts zu befolgen. Dadurch kann verlorene Arbeitszeit vermieden werden, die zu Lasten eines fehlenden "roten Fadens" ginge, und die Vorteile der jeweiligen Methode kommen zum Tragen.

Übung 1.3

Definitionen des Begriffs "Projekt"

  • Ein Projekt ist ein zeitlich begrenztes Vorhaben zur Schaffung eines einmaligen Produktes, einer Dienstleistung oder eines Ergebnisses. (Projekt: Eine Definition)
  • Ein zeitlich befristetes, komplexes Vorhaben, das einen übergreifenden hauptamtlichen Personaleinsatz erfordert. Es sollte deshalb in besonderer Projektorganisation außerhalb der normalen Struktur (= Aufbauorganisation) durchgeführt werden. (Projekt / Projektmanagement)
  • Ein Projekt ist ein einmaliges Vorhaben auf Zeit. (Projekt)
  • abgrenzbares Einzelvorhaben mit definiertem Anfang und Ende (Ziel), neuartig: Vorstoß an Grenzen des Machbaren, risikoreich (technisch, wirtschaftlich, terminlich), komplex, im Laufe der Abwicklung sich ändernde organisatorische Bedürfnisse, große Bedeutung für Unternehmen / Organisation, Termindruck (Projekte: Definition und Nutzen)
  • Ein Projekt ist ein Vorhaben basierend auf der Planung einer Problemlösestrategie, um effektiv und effizient zu einem vorher definierten realistischen Ziel (bzw. Unterziel) innerhalb eines (festgelegten) zeitlichen Rahmens zu gelangen. Projekte werden auch definiert als Vorhaben, die durch eine zeitliche Befristung, eine relative Neuartigkeit und Komplexität sowie durch eine interdisziplinäre Aufgabenstellung gekennzeichnet sind. Die Neuartigkeit dieser Projekte kann sich sowohl auf das Vorgehen bei der Problemlösung als auch auf das gewünschte Ergebnis beziehen. Die Projektarbeit erstreckt sich meist über verschiedene Hierarchieebenen und bindet dabei mehrere Abteilungen ein. Dies führt zu einer hohen Komplexität der Projektarbeit. (ProjektManagement)

Gemeinsamkeiten der Definitionen

  • zeitlich begrenzt
  • einmalig
  • interdisziplinar

Unterschiede

  • weit gefasste Definitionen <> sehr spezifische Definitionen
  • Komplexität
  • Definition von Zielen
  • Agilität

Übung 1.4

Die Phasen eines Softwareprojekts:

  1. Initiative
  2. Planung
  3. Durchführung, Steuerung
  4. Abschluss
  5. Betrieb

Übung 1.5

Wer tritt bei einem Projekt mit wem in Interaktion?

  • Projektmitarbeiter untereinander
  • Projektmitarbeiter und -leiter
  • Projektleiter und Kunde
  • (optimalerweise) Projektmitarbeiter und Kunde bei konkreten Fragen

Übung 1.6

In welcher Phase des Software-Projekt-Lebenszyklus werden die Kosten für den gesamten Lebenszyklus festgelegt und in welcher fallen die höchsten Kosten an?

  • Die Gesamtkosten sollten in der Planungsphase ermittelt (geschätzt) und als Richtlinie für den weiteren Projektverlauf vorgegeben werden.
  • Die höchsten Kosten dürften nach Fertigstellung der Software anfallen, also während des Betriebs (durch Wartung, Optimierung etc.).

Übung 1.7

Wie wenden Sie die vier Seiten der Kommunikation (Inhalt, Beziehung, Selbstoffenbarung, Appell) im Projekt an?

  • Kommunikation sollte möglichst sachlich (inhaltliche Ebene) erfolgen, um missverständliche Aussagen zu vermeiden.
  • Man sollte sich stets aller Wirkungen seiner Aussagen bewusst sein, sich in den Gesprächspartner hineinversetzen und überlegen, wie er die Nachrichten auffassen könnte.
  • Appelle müssen auch als solche verstanden werden, wenn es um die Delegierung von Aufgaben geht.
  • Für eine optimale, offene Kommunikation sollte die Beziehungsebene stets mit einbezogen werden, um die Gespräche nicht zu "kühl" und distanziert wirken zu lassen.
  • Hat man das Gefühl, das Gesagte könnte falsch verstanden werden, sollte offen auf einer Metaebene über das Gespräch geredet und die eigenen Ziele verdeutlicht werden.

Übung 1.8 und 1.9

Zeitfresseranalyse (1 = fast nie, 2 = angemessen, 3 = zu oft)

  • Telefon 2
  • Besprechungen 2
  • Besucher 1
  • Kleinigkeiten 3
    • Sammeln kleiner, nicht dringender Aufgaben und abarbeiten zu einem festen Termin
  • Unvorhergesehenes 1
  • Posteingang 2
  • Ordnung 1
  • Informationsfluss 1
  • Delegation 1
  • Anfragen 3
    • Abwägen der Dinglichkeit und Wichtigkeit der Anfragen und ggf. ablehnen von Aufgaben unter Verweis auf wichtigere Tätigkeiten

Übung 1.10

Initiierung

Übung 2.1

Projektfragebogen: Master of Engineering

Übung 2.2

Bearbeitete Projekte

  • Studium an der FHWT
  • Auftritte mit der Band
  • Programmierprojekte
  • etc.

Übung 2.3

Liste offener Punkte → GTD

Übung 2.4

Der Projektauftrag sollte in Form einer Beratung geklärt werden. Der Berater muss hierzu über Fachkompetenz verfügen, die er benötigt um dem Kunden Hilfestellung bei der Entscheidung für bestimmte Produkte oder Lösungen geben zu können (Was ist machbar? Was sind die jeweiligen Vor- und Nachteile?). Aber auch Methoden- und Sozialkompetenz ist wichtig, um die korrekten Informationen bzgl. der Wünsche des Kunden erarbeiten zu können. Der Berater steht mit seinen Fähigkeiten dem Kunden zur Seite und hilft ihm bei der exakten Formulierung von Anforderungen (etwa mit Hilfe von UML oder BPMN), um späteren Missverständnissen vorzubeugen. Nur auf Basis einer fundierten Anforderungsanalyse kann ein Projekt erfolgreich durchgeführt werden.

Übung 2.5

Eine Vorstudie ist bei jedem Projekt nötig, um abzuklären, ob dieses überhaupt durchzuführen ist. Je nach Umfang des Projekts kann sich die Vorstudie zwar auf einige kurze Überlegungen beschränken, dennoch ist sie stets Teil des Projektverlaufs.

Übung 2.6

Der Grobplan des Projektverlaufs enthält analog zur Grobgliederung einer Diplomarbeit o.ä. lediglich die zentralen Punkte des Projekts, etwa wichtige Meilensteine. Er dient als Basis für die detaillierte Feinplanung und kann im Extremfall sogar komplett umgeändert werden, wenn sich Anforderungen ändern. Auch bei der Erstellung eines Grobplans ist stets der Umfang des Projekts zu berücksichtigen (bei größeren Projekten wird der Grobplan im Verhältnis zu kleineren natürlich viel oberflächlicher sein).

Übung 2.7

Checkliste für eigene Präsentationen (wichtige Dinge, die es zu verbessern gilt)

  • Zuhörer- und Situationsanalyse
  • Angemessener Umfang der zu vermittelnden Informationen
  • Ziele des Vortrags und Nutzen für Zuhörer klar herausarbeiten (im Fazit noch einmal aufgreifen)
  • Großen Wert auf einen guten Beginn und Schluss legen
  • Langsamer sprechen
  • Zusätzliche Medien einsetzen
  • Zuhörer aktiv einbinden (direkt ansprechen, Aufgaben lösen lassen etc.)

Übung 2.8

  • EDV-Abteilung
    1. Kontakt: (wochen)täglich
    2. Zeitraum: mehrere Jahre (?)
    3. Struktur: Hierarchie abhängig von Positionen (Abteilungsleiter etc.)
    4. Regeln: Stellenbeschreibungen, Anweisungen von Vorgesetzten, Absprachen etc.
    5. Wir-Gefühl: Auftreten als Abteilung
  • Studenten SE
    1. Kontakt: Internet, Mail, regelmäßige Treffen vor Ort
    2. Zeitraum: 2 Jahre
    3. Struktur: muss sich noch entwickeln
    4. Regeln: Studienordnung
    5. Wir-Gefühl: Studenten eines Jahrgangs

Übung 2.9

Team zur Durchführung einer Vorstudie zur Entwicklung einer Projektmanagement-Software

  • Softwareentwickler, da letztendlich eine Software zu erstellen ist
  • Projektleiter/-mitarbeiter, die praktische Erfahrung mit der Durchführung von Projekten haben und Hilfestellung bei der Anforderungsanalyse geben können
  • Zukünftige Benutzer der Software, da sie am ehesten die Zwischenergebnisse auf Tauglichkeit bewerten können

Übung 2.12

Worauf ist bei der Übernahme von Projekten in funktionalen Unternehmen besonders zu achten?

  • Kompetenzgerangel: Abteilungsleiter <> Projektleiter
  • Die Projektmitarbeiter sind meist noch im Tagesgeschäft eingespannt
  • Geschäftsleitung ist unbedingt einzubinden und muss hinter dem Projekt stehen
  • Mitarbeiter sind evtl. mit der Projektorganisation nicht vertraut (an Abteilungsdenken gewöhnt)

Übung 2.13

Was bringt der Einsatz von Prozessbeschreibungsstandards für die Softwareentwicklung und die Informationstechnologie?

  • Eindeutige Prozessbeschreibungen mit weniger Interpretationsspielraum als bei Freitext
  • Erstellte Prozessbeschreibungen können evtl. zur automatischen Codegenerierung verwendet werden oder sind als Software lauffähig (z.B. in einer SOA)
  • Grafische Prozessbeschreibungen sind von den Mitarbeitern meist einfacher und schneller zu verstehen und zu erfassen
  • Bei der Modellierung von Prozessen mit Hilfe von Prozessbeschreibungssprachen muss von Anfang an eindeutig und umfassend modelliert werden, was die Qualität der Modelle erhöht

Übung 2.14

Was ist die Hauptaufgabe des Projektleiters in prozessorientierten Unternehmen?

  • Der Pojektleiter ist in der bereits gut auf Projektarbeit vorbereiteten prozessorientierten Unternehmenskultur hauptsächlich für die Rahmenbedingungen (z.B. Arbeitsräume, Werkzeuge aber auch Kenntnisse von Methoden) zuständig.
  • Des Weiteren hält er Kontakt zur übergeordneten Führungsebene und steuert das Projekt in die richtige Richtung.

Planung

Übung 3.1

Warum ist ein gut moderiertes Kick-Off-Meeting wichtig für das Projekt?

  • Das Projektteam muss auf das gemeinsame Ziel eingeschworen werden
  • Die Teilnehmer lernen sich besser kennen
  • Alle Teilnehmer bedürfen klarer Anweisungen bzgl. ihrer Aufgaben
  • Die Formalien (Protokolle, Besprechungen etc.) müssen verbindlich festgelegt werden
  • Die Vorgehensweise wird zusammen erarbeitet (Grobplan durchgehen, Feinplan aufstellen)

Übung 3.3

Warum stellt man einen Projektplan auf, anstatt einfach loszulegen?

  • Eine Planung der benötigten Zeit und Ressourcen, sowie der Kosten ist ohne Projektplan nicht möglich.
  • Ein Projektplan weist jedem Projektmitarbeiter seine Aufgaben zu. Nur so ist eine spätere Kontrolle der erreichten Ziele möglich.
  • Der Projektplan bietet stets eine gute Übersicht zum aktuellen Stand des Projektes (wenn er gut gepflegt wird) und zeigt eventuelle Engpässe auf.
  • Nur mit Hilfe eines zentralen Projektplans lassen sich die zu erledigenden Aufgaben der einzelnen Projektmitarbeiter so abstimmen, dass nicht redundant gearbeitet oder etwas vergessen wird.
  • Auf Basis eines Projektplans, der vom Team gemeinsam erstellt und verabschiedet wird, ist eine optimale Zusammenarbeit ohne Interessens- oder Kompetenzkonflikte möglich.

Übung 3.4

Mögliche Vorgehensweisen/Hilfsmittel zur Modellierung.

Strukturierte Programmierung

  • Größere Probleme werden in mehreren Schritten in Teilprobleme zerlegt. Verfeinere diese Teilprobleme weiter (eventuell mehrfach), bis nur noch elementare algorithmische Grundstrukturen vorliegen: Top-Down-Vorgehen. (Strukturierte Programmierung)
  • Programme werden modularisiert
  • Nur bestimmte Kontrollstrukturen sind erlaubt: Sequenzen, Schleifen, Bedingte Verzweigungen
  • Grafisches Hilfsmittel: Struktogramm/Nassi-Shneiderman-Diagramm (Strukturierte Programmierung)
  • Vorteile
    • Programmierung von Bibliotheken, Modulen
  • Nachteile
    • schwierige Fehlerbehandlung und Datenmodellierung
  • Einsatzgebiet: Einfache Programme, prozedurale Programmierung

UML

  • Die Unified Modelling Language ist eine Sprache zur Spezifikation, Visualisierung, Konstruktion und Dokumentation von Modellen für Softwaresysteme, Geschäftsmodelle und andere Nicht-Softwaresysteme. Sie bietet den Entwicklern die Möglichkeit, den Entwurf und die Entwicklung von Softwaremodellen auf einheitlicher Basis zu diskutieren. Die UML wird seit 1998 als Standard angesehen. Sie lag und liegt weiterhin bei der Object Management Group (OMG) zur Standardisierung vor. (Unified Modelling Language)
  • UML ist keine Methode, sondern definiert eine Notation und Semantik zur Visualisierung, Konstruktion und Dokumentation von Modellen für die Geschäftsprozessmodellierung und für die objektorientierte Softwareentwicklung. (UML Unified Modeling Language)
  • Grafische Hilfsmittel: Mehrere (13) Diagrammtypen für unterschiedliche Anforderungen
  • Vorteile
    • Quasi-Standard, leicht zu verstehen/erlernen
    • Diagramme können zur Codegenerierung verwendet werden
  • Nachteile
    • Nicht alle Anforderungen der Objektorientierung werden abgedeckt (aber durch die leichte Erweiterbarkeit von UML sind eigene Erweiterungen möglich)
  • Einsatzgebiet: Objektorientierte Programmierung, Entwurf umfangreicher Software

BPMN

  • The Business Process Modeling Notation (BPMN) is a graphical notation that depicts the steps in a business process. BPMN depicts the end to end flow of a business process. The notation has been specifically designed to coordinate the sequence of processes and the messages that flow between different process participants in a related set of activities. (Business Process Modeling Notation (BPMN) Information)
  • The unified modelling language (UML) takes an object-oriented approach to the modeling of applications, while BPMN takes a process-oriented approach to modelling of systems.
  • Vorteile
    • kann in BPEL umgewandelt werden → lauffähige Prozesse
    • was UML für die Objektorientierung, ist BPMN für Prozessorientierung
  • Einsatzgebiet: Definition und Automatisierung von Geschäftsprozessen, SOA

Rapid Prototyping

  • Das Prototyping ist eine Methode der Softwareentwicklung, die schnell zu ersten Ergebnissen führt und frühzeitiges Feedback bezüglich der Eignung eines Lösungsansatzes ermöglicht. (Prototyping (Softwareentwicklung))
  • In rapid prototyping interactive prototypes are developed which can be quickly replaced or changed in line with design feedback. This feedback may be derived from colleagues or users as they work with the prototype to accomplish set tasks. (Rapid prototyping)
  • Vorteile
    • Schnelle Ergebnisse und Anpassbarkeit während der Erstellung
  • Nachteile
    • Gefahr, "unsauber" zu programmieren
    • oftmals mangelnde Dokumentation, da Konzentration auf Entwicklung
  • Einsatzgebiet: Maschinenbau, jegliche Programmierung (nicht praktikabel für große Anwendungen)

Agile Programming

  • Agile software development is a conceptual framework for software engineering that promotes development iterations throughout the life-cycle of the project. (Agile software development)
  • Although the various agile approaches are different, they have some things in common. They're intended to produce software that can be changed quickly, and all specify short iterations and maximize the amount of time spent face to face. They also focus on team morale. (Extremely Agile Programming)
  • AP is a collection of principles and techniques that try to overcome the inflexibility of the strictly-design-based development cycle. (Agile Programming)
  • Vorteile
    • schnelle Ergebnisse, trotzdem folgt das Vorgehen einem klaren Plan mit bestimmten Methoden
  • Einsatzgebiete: Webentwicklung (Ruby on Rails), Softwareentwicklung

Übung 3.6

  • Entwicklung der Projektmanagementsoftware
    • Planung
      • Fachliche Funktionalitäten festlegen
      • Programmierkonzept festlegen
        • Zu unterstützende Betriebssysteme festlegen
        • Programmiersprache auswählen
        • Groben Aufbau des Programms modellieren
      • Voraussetzungen klären
        • Benötigte Ressourcen ermitteln
        • Benötigte Projektmitarbeiter ermitteln
    • Implementierung
      • Programmierung der Software
      • Erstellen des GUI
    • Dokumenation erstellen
      • Anwenderdokumentation erstellen
      • Technische Dokumentation erstellen
    • Test
      • Automatische (Fehler-)Tests durchführen
      • Fachliche Tests durch Anwender durchführen lassen
      • Usability-Test durchführen
      • Endabnahme durchführen
    • Schulungen
      • Benutzerschulung durchführen
      • Administratorenschulung durchführen
    • Betrieb
      • Installation der Software beim Kunden
      • Parametrisierung vor Ort

Übung 4.1

Möglichkeiten der Fortschrittsermittlung in (Software-)Projekten, ihre Vor- und Nachteile sowie die Art von Projekten, für die sie geeignet sind. (SAP Projektfortschritt)

  • Start-Ende (Vergleich der geplanten Zeiten)
    • Vorteile: schnell, einfach
    • Nachteile: ungenau
  • Meilensteine (Erreichen der geplanten Meilensteine)
    • Vorteile: sehr aussagekräftig, objektiv prüfbar
    • Nachteile: detaillierte Zergliederung der Aufgaben nötig
  • Funktionsumfang (Implementierungsgrad der benötigten Funktionen)
    • Vorteile: objektiv messbar, geringer Planungsaufwand
    • Nachteile: benötigte Zeit je Funktion teils sehr unterschiedlich
  • Schätzen
    • Vorteile: jeder Mitarbeiter kann schätzen, liefert schnell einen ersten Richtwert
    • Nachteile: ungenau, subjektive Werte können erheblich von tatsächlichen abweichen

Übung 4.3

Wieso wird zusätzlich zum Projektplan noch ein Frühwarnsystem benötigt?

  • Der Projektplan behandelt das Ist und die Vergangenheit. Für die Zukunft ist das Frühwarnsystem zuständig.
  • Der Projektplan sollte auf jeden Fall ständig aktualisiert werden, jedoch nicht selbst zum Zeitfaktor werden, was durch eine überbordende Erfassung möglicher Risiken schnell eintreten kann.
  • Ein Frühwarnsystem, das die Projektmitarbeiter einbezieht, fördert deren Kompetenz und Einsatzbereitschaft und gibt ihnen das Gefühl, mitzubestimmen bzw. eine gewisse Kontrolle zu haben.
  • Ein separates Frühwarnsystem entlastet den Projektleiter.

Übung 4.5

Was wirkt motivierend auf Projektmitarbeiter?

  • Interesse am Themengebiet (etwa Programmierung)
  • Der messbare Erfolg beim Erreichen von Zielen
  • Ein methodisch und fachlich fähiger Projektleiter
  • Die gute Zusammenarbeit im Team
  • Anerkennung der erbrachten Leistungen
  • Hoher Grad an Eigenverantwortung

Projektsteuerung und -kontrolle während der Durchführung

Abschluss und Betrieb

Offene Fragen

Links

se/projektmanagement.1192375369.txt.gz · Zuletzt geändert: 2014-04-05 11:42 (Externe Bearbeitung)