Betreuer:
Jörg Czeranski,
Raum 2.129
Jeweils donnerstags von 13:15 bis 14:45 Uhr in Raum 1.026.
| Termin | Vortragender | Thema |
|---|---|---|
| 8.11. | Felix Kunze-Concewitz | Prozessmodelle |
| 15.11. | Habib Frad | Kostenschätzung |
| 22.11. | Carsten Bube | Projektkontrolle / Planung |
| 29.11. | Anastasios Kozas | Risikomanagement |
| 6.12. | Johannes Enge | Configuration Management |
| Jochen Noller | Revision Management | |
| 13.12. | Kolja Wohlbold | Test |
| 20.12. | Reinhard Keil | Dokumentation |
| 10.1. | Holger Cermann | Requirements Engineering |
| 17.1. | Stephan Wannenwetsch | Produktlinien |
| 24.1. | Daniel Raichle | Bug-Tracking |
| 31.1. | Ning Dou | Kommunikation |
| 7.2. | Marc Reiter | Standards zum Projektmanagement |
| 14.2. | Martin Schwenk | CASE-Tools |
Es soll ein Überblick über die für Softwareentwicklung gebräuchlichen Prozessmodelle gegeben werden und auf Besonderheiten eingegangen werden.
Literatur: Balzert98 (LE 4), siehe auch: Balzert96, Humphrey90, Fuggetta00
Abzuschätzen, wie lange ein Projekt laufen wird und welche Kosten es verursachen wird, ist eine der schwierigsten Fragen des Software Enginnerings. Erfahrungen zu sammeln dauert lange (mehrere Projekte), falsche Antworten sind höchst problematisch und gefährden den Erfolg eines Projektes. Ohne Erfahrungen über ein unbekanntes Problemfeld Schätzungen abzugeben ist fast unmöglich. Es gibt verschiedene Ansätze, die Kostenschätzung durchzuführen, u.a. basierend auf Function Points und auf LOC.
Literatur: Albrecht83, Boehm81, Burghardt95
Wie kontrolliert man Software-Entwicklungsprojekte? Anhand der vorgebenen Literatur soll erläutert werden, wie Software mit Qualität produziert werden kann und wie man die Qualität überprüft.
Ohne Planung der Zeit geht der Überblick verloren. Damit ein Projekt nicht aus dem Ruder läuft, sollen hier Vorgehensweisen erläutert werden, die die persönliche Zeitplanung unterstützen. Das Testen der Software muss mit entsprechendem Aufwand geschehen, ebenso wird Zeit für die Qualitätssicherung und Dokumentation (intern und extern) verbraucht.
Literatur:
Eine wichtige Aufgabe des Projektmanagements liegt darin, Risiken jeder Art zu erkennen und zu überwachen, um bei Bedarf geeignete Gegenmaßnahmen zu ergreifen. Fairleys Artikel beschreibt einen mehrstufigen Prozess des Risikomanagements und erläutert das Verfahren anhand einer Anwendung.
Unter Configuration Management versteht man die Verwaltung und Kontrolle (auch zeitlich) variierender Produktkonfigurationen. Es umfaßt unter anderem Revision Management, Release Management, Change Management, Build Management. Dieser Vortrag soll einen Überblick über das Thema geben.
Literatur: Compton94, Berlack92, Tichy94, Whitgift91 (Kapitel 12), siehe auch: Westfechel91
Revision Management ist ein wichtiger Bestandteil des Configuration Management. Es beschäftigt sich mit der Verwaltung von zeitlich aufeinanderfolgenden Änderungen an Quelltexten und anderen Dokumenten.
Wichtige Probleme und Arbeitsabläufe (z.B. Verzweigungen in der Entwicklung, Zugriff auf alte Versionen, konkurrierende Änderungen) und deren Lösung bzw. Unterstützung durch Werkzeuge sollen erläutert werden.
Literatur: Bolinger95, Tichy94, Whitgift91, Silverberg92 (Kapitel 1 und 12), siehe auch: Westfechel91 (Kapitel 3.2), Fogel99
Wie testet man Software? Wie kann man den Kunden von der Korrektheit der Entwicklung überzeugen?
Literatur: Balzert98 (LE 14ff), Harrold00
Dokumentation ist ein wesentlicher Bestandteil eines Produkts. Sie dient sowohl dem Anwender bei der Benutzung als auch den Entwicklern bei der Wartung und Weiterentwiclung der Software. Bestandteile der Dokumentation können beispielsweise Benutzerhandbuch und Online-Hilfe sein.
Literatur: Balzert96, Sommerville92, Hilera98, siehe auch: Parnas94
Falsch verstandene Anforderungen des Kunden sind wohl der häufigste Grund für das Scheitern von Projekten. Deshalb kommt dem Requirements Engineering, dem Einholen und Verwalten (auch dem Formalisieren) von Kundenanforderungen zentrale Bedeutung zu.
Literatur: Davis93, Sommerville97, Thayer90 (Kapitel 1), Jackson95
Entwickelt eine Firma für verschiedene Kunden Software mit unterschiedlichem, aber stark überlappendem Funktionsumfang, empfiehlt es sich, Produktlinien (auch: Produktfamilien) einzusetzen.
Dieser Ansatz erlaubt es, gemeinsame Anteile der Produkte nur einmal zu entwickeln und trotzdem auf individuelle Anforderungen von Kunden oder Kundengruppen einzugehen. Während ein analoger Ansatz in der fertigenden Industrie seit langam Standard ist, wurde er in die Softwareentwicklung erst in neurer Zeit eingeführt.
Literatur: Bosch00, Bass98 (Kapitel 15)
Siehe auch die Web-Seiten des Software Engineering Institute zu Produktlinien
Fehler beim Entwickeln von Programmen sind unvermeidlich. Nicht selten werden jedoch entdeckte Fehler wieder vergessen, anstatt behoben zu werden, oder bereits behobene Fehler später wieder eingebaut, zum Beispiel durch neu hinzugekommene Entwickler.
Um diese Probleme zu vermeiden, verwendet man Bug-Tracking-Systeme, die eine Protokollierung der bekannten Fehler, ihre Priorisierung und die Dokumentation der Lösung erlauben. Durch den letzten Punkt stehen sie auch in Beziehung zum Configuration Management.
Literatur: Dunn84, Whitgift91 (Kapitel 9)
Siehe auch die online-Dokumentation zum Bug-Tracking-Tool GNATS
Die Entwicklung nichttrivialer Softwaresysteme ist unmöglich ohne Kommunikation der Entwickler untereinander, der Projektleitung mit den Entwicklern, des Kunden mit der Softwarefirma. Effektive und effiziente Kommunikation kann einen großen Teil zum Gelingen des Projekts beitragen.
Randbereiche der Kommunikation sind die Dokumentation als eine schriftliche Form der Kommunikation und das Programmieren als Medium der Kommunikation unter Entwicklern. Diese sollen nicht Thema des Vortrags sein.
Literatur: Hansel93, siehe auch: Zobel97
Zum Software-Entwicklungsprozess gibt es Normen, von denen die bekanntesten zur ISO9000-Reihe gehören. Diese Normen zielen vor allem darauf ab, durch einen dokumentierten und dadurch wiederholbaren Prozess eine hohe Qualität des Projektergebnisses sicherzustellen.
Durch die Wahl eines nach diesen Normen zertifierten Auftragnehmers soll dem Auftraggeber ermöglicht werden, das Risiko eines Scheiterns des Projekts oder des Enwickelns eines minderwertigen Produkts zu reduzieren.
Literatur: Balzert98 (LE 12)
Nichts ist naheliegender, als die Softwareentwicklung ihrerseits durch Software-Werkzeuge zu unterstützen. Solche Werkzeuge sind mittlerweile recht weit verbreitet und unterstützen neben dem eigentlichen Programmieren auch einige Aspekte des Projektmanagements, die in diesem Seminar vorgestellt wurden.
Dieser Vortrag soll einige CASE-Tools vorstellen und auf ihren Bezug zum Projektmanagement eingehen.
Literatur: Balzert98 (LE 21)
[Albrecht83] A. J. Albrecht, J. E. Gaffney, Software Function, Lines of Code and Development Effort Prediction: A Software Science Validation, Vol. 9, No. 6, pp. 639-647, IEEE Transactions Software Engineering, 1983.
[Balzert96] Helmut Balzert, Lehrbuch der Softwaretechnik, Spektrum Akademischer Verlag, 1996, 1. Software-Entwicklung.
[Balzert98] Helmut Balzert, Lehrbuch der Softwaretechnik, Spektrum Akademischer Verlag, 1998, 2. Software-Management, Software-Qualitätssicherung, Unternehmensmodellierung.
[Bass98] Len Bass, Paul Clements, Rick Kazman, Software architecture in practice, Addison-Wesley, 1998, 0-201-19930-0.
[Berlack92] H. Ronald Berlack, Software configuration management, Wiley, 1992
[Boehm81] Barry Boehm, Software Engineering Economics, Prentice-Hall, 1981.
[Boehm89] Barry Boehm, Software Risk Managment, IEEE Computer Society Press, 1989, 0-8186-8906-4.
[Bolinger95] Don Bolinger, Tan Bronson, Applying RCS and SCCS, O'Reilly, 1995, 1-56592-117-8.
[Bosch00] Jan Bosch, Design and use of software architectures, Addison-Wesley, 2000, 0-201-67494-7.
[Burghardt95] Manfred Burghardt, Projektmanagement, Publicis-MCD-Verlag, 3. Auflage, 1995.
[Compton94] Stephen B. Compton, Guy R. Conner, Configuration management for software, Van Nostrand Reinhold, 1994.
[Davis93] Alan M. Davis, Software requirements: objects, functions, and states, Prentice Hall, 1993, 0-13-805763-X.
[Dunn84] Robert H. Dunn, Software defect removal, McGraw-Hill, 1984, 0-07-018313-9.
[Fairley94] R. Fairley, Risk Management for Software Projects, IEEE Software Magazine, Mai 1994, pp. 57-67.
[Fogel99] Karl Fogel, Open source development with CVS, The Coriolis Group, 1999, 1-576-10490-7.
[Fuggetta00] Alfonso Fuggetta, Software Process: A Roadmap, International Conference on The Future of Software Engineering 2000, June 2000, IEEE, pp. 25-34.
[Hansel93] Jürgen Hansel, Gero Lomnitz, Projektleiter-Praxis, Springer, 1993.
[Harrold00] Mary Jean Harrold, Software Testing: A Roadmap, International Conference on The Future of Software Engineering 2000, June 2000, IEEE, pp. 61-72.
[Hilera98] Jose R. Hilera, Leon A. Gonzalez, Jose A. Gutierrez, J. M. Martinez, Software Documentation as an Engineering Process, ACM Software Engineering Notes, Vol. 23, No. 5, 1998, pp. 61-64
[Humphrey90] Watt S. Humphrey, Managing the Software Process, Addison-Wesley, 1990.
[Jackson95] Michael Jackson, Software requirements and specifications: a lexicon, Addison-Wesley, 1995, 0-201-87712-0.
[MB96] Philip W. Metzger und John Boddie, Managing a Programming Project: People and Processes, Prentice-Hall, 3rd Edition, 1996, 0-13-554239-1.
[Parnas94] David L. Parnas, Jan Madey, Michal Iglewski, Precise Documentation of Well-Structured Programs, IEEE Transactions on Software Engineering, Vol. 20, No. 12, 1994, pp. 948-976
[Silverberg92] Israel Silverberg, Source file management with SCCS, Prentice-Hall, 1992, 0-13-829771-1.
[Sommerville92] Ian Sommerville, Software Engineering, 4th edition, Addison-Wesley, 1992.
[Sommerville97] Ian Sommerville, Pete Sawyer, Requirements Engineering: a good practice guide, Wiley, 1997, 0-471-97444-7.
[Thayer90] Richard H. Thayer, Merlin Dorfman, System and software requirements engineering, IEEE Computer Society Press, 1990, 0-8186-8921-8.
[Tichy94] Walter F. Tichy (ed.), Configuration management, Wiley, 1994, 0-471-94245-6.
[Westfechel91] Bernhard Westfechel, Revisions- und Konsistenzkontrolle in einer integrierten Softwareentwicklungsumgebung, Springer, 1991.
[Whitgift91] David Whitgift, Methods and tools for software configuration management, Wiley, 1991, 0-471-92940-9
[Zobel97] Justin Zobel, Writing for computer science, Springer, 1997, 981-3083-22-0.