Benutzer-Werkzeuge
se:projektmanagement
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung | Nächste Überarbeitung Beide Seiten der Revision | ||
|
se:projektmanagement [2009-04-13 18:46] stefan |
se:projektmanagement [2009-04-13 18:46] stefan |
||
|---|---|---|---|
| Zeile 707: | Zeile 707: | ||
| * eigene Aufzeichnungen während der Vorlesung anschauen | * eigene Aufzeichnungen während der Vorlesung anschauen | ||
| * Beispielfragen durchgehen | * Beispielfragen durchgehen | ||
| - | |||
| - | |||
| - | |||
| - | |||
| - | |||
| - | |||
| - | |||
| - | |||
| - | |||
| - | |||
| - | |||
| - | |||
| - | |||
| - | |||
| - | |||
| - | |||
| - | |||
| - | |||
| - | |||
| - | |||
| - | |||
| - | |||
| - | |||
| - | ===== 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. ([[http://www.saar.de/~awa/verfein.htm|Strukturierte Programmierung]]) | ||
| - | * Programme werden modularisiert | ||
| - | * Nur bestimmte Kontrollstrukturen sind erlaubt: Sequenzen, Schleifen, Bedingte Verzweigungen | ||
| - | * Grafisches Hilfsmittel: Struktogramm/Nassi-Shneiderman-Diagramm ([[http://www.mi.uni-koeln.de/c/mirror/f7alpha1.informatik.fh-muenchen.de/~schieder/programmieren-1-ws96-97/struktpgm.html|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. ([[http://ivs.cs.uni-magdeburg.de/~dumke/UML/index.htm|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. ([[http://www.torsten-horn.de/techdocs/uml.htm|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. ([[http://www.bpmn.org/Documents/FAQ.htm|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. | ||
| - | * [[http://www.omg.org/docs/dtc/06-02-01.pdf|Spezifikation]] | ||
| - | * 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. ([[http://de.wikipedia.org/wiki/Prototyping_%28Softwareentwicklung%29|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. ([[http://www.usabilitynet.org/tools/rapid.htm|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. ([[http://en.wikipedia.org/wiki/Agile_software_development|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. ([[http://www.computerworld.com/softwaretopics/software/appdev/story/0,10801,67950,00.html|Extremely Agile Programming]]) | ||
| - | * AP is a collection of principles and techniques that try to overcome the inflexibility of the strictly-design-based development cycle. ([[http://www.codeproject.com/gen/design/agileprogramming.asp|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. ([[http://help.sap.com/printdocu/core/Print46c/de/data/pdf/PSPRG/PSPRG.pdf|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 | ||
se/projektmanagement.txt · Zuletzt geändert: 2014-04-05 11:42 (Externe Bearbeitung)
Seiten-Werkzeuge
Falls nicht anders bezeichnet, ist der Inhalt dieses Wikis unter der folgenden Lizenz veröffentlicht: CC Attribution-Noncommercial-Share Alike 4.0 International
