Projektplanung


Facharbeit (Schule), 2000

20 Seiten, Note: 1


Gratis online lesen

Inhaltsverzeichnis

Einleitung

Abweichung

Function Points

Allgemeines:
Voraussetzungen :
Vorteile :
Nachteile :

Vorgehensweise der Methode:
1. Quantifizieren des Funktionsumfanges
2. Bewertung des Schwierigkeitsgrades durch ,,Points"
Eingabedaten
Ausgabedaten
Abfragen
Datenbestände
Referenzdaten
3. Analyse der Einflussfaktoren
4. Berechnung der bewerteten Function - Points
5. Ermittlung des Aufwandes
Aufwandschätzung (Formular)
Umrechnungstabelle: Function Points - Mannmonate

COCOMO (Constructive Cost Model)
Einfache Projekte (Organic Mode oder Anwendungsprogramme)
Mittelschwere Projekte (Semidetached Mode oder Programmsysteme)
Komplexe Projekte (Embedded Mode oder eingebettete Systeme)
Produktmerkmale
Rechnermerkmale
Personalmerkmale
Projektmerkmale

Unterschied zwischen Function Points und COCOMO Quellenverzeichnis:

Verwendete Links:

Einleitung

Die Aufwandschätzung hat das Ziel, die im Verlauf des gesamten Projekts auftretenden Aufwände vorauszuplanen und festzuhalten.

Dabei sind im wesentlichen folgende Faktoren (Aufwandtreiber) zu berücksichtigen:

- Leistungsumfang
- Qualität
- Termin
- Produktivität

Die Aufgabe dabei ist die Hauptaufwandstreiber zu identifizieren, geeignete Maßzahlen für jeden Aufwandtreiber zu finden und deren Einfluss auf den Aufwand zu eruieren.

Bei der Auswahl von geeigneten Aufwandschätzmethoden müssen daher folgende Punkte berücksichtigt werden:

- Frühzeitige Verwendbarkeit der Methode · Abdeckung der Hauptaufwandtreiber
- Erhebbarkeit der notwendigen Schätzfaktoren (z.B. Ein-/Ausgaben bei Function Points)
- Aufwand für Schätzung ist zumutbar

Abweichung

Aufwandschätzungen finden unter Ausnutzung des jeweiligen Kenntnisstandes zu mehreren Zeitpunkten im Projekt statt, wobei das Ergebnis dann auf der einen Seite die aktualisierte Gesamtschätzung - etwa aufgrund geänderter Projektziele oder eingetretener Schwierigkeiten - und auf der anderen Seite die Detailschätzung der nächsten Aufgaben ist. Wie die Abbildung verdeutlicht, nehmen in der Regel die Abweichungen der Schätzungen über den Projektablauf ab, die Genauigkeit der Schätzungen verbessert sich also.

Abbildung in dieser Leseprobe nicht enthalten

Function Points

Allgemeines:

Die Methode wurde 1979 von einen Mitarbeiter von IBM namens Allan Albrecht entwickelt.

Die Function Point - Methode basiert auf Zählungen der Externbeziehungen des Systems (Eingaben, Ausgaben, Abfragen) und der logischen Datenbestände, sowie der Bewertung von Einflussfaktoren (Komplexität, Qualität, Projektdauer, Produktivität).

Aus der Zahl der Externbeziehungen und Datenbestände, sowie den Wert der Einflussfaktoren werden die Function Points errechnet.

Voraussetzungen :

- Einheitliche Vorgangsweise bei der Projektierung
- Klare Definitionen aller Anforderungen an das Projekt
- Gleicher Ausbildungs- und Kenntnisstand der Benutzer
- Exakte und einheitliche Abgrenzung bei der Klassifizierung

Vorteile :

- Erste Schätzung bereit in der Planungsphase möglich
- Festgelegte methodische Schritte
- Leicht erlernbar
- Benötigt nur geringen Zeitaufwand
- Gute Transparenz
- Gute Schätzgenauigkeit
- Werkzeugunterstützung verfügbar

Nachteile :

- Sie ist keine Wirtschaftlichkeitsrechnung
- Sie ist nicht anwendbar bei Kommunikations-Software oder systemähnlichen Software-Systemen
- Nur Gesamtschätzung

Vorgehensweise der Methode:

1. Quantifizierung des Umfangs - Ermitteln von ,,Functions"

2. Bewertung des Schwierigkeitsgrades der Functions durch ,,Points"

3. Analyse der Einflussfaktoren von 7 vorgegebenen Faktoren

4. Berechnung der bewerteten Function - Points

5. Ermittlung des Aufwandes mittels historischer Daten

1. Quantifizieren des Funktionsumfanges

1. Quantifizieren des Funktionsumfanges

Dieser Umfang kann aus dem Datenfluß abgelesen werden. Betrachtet werden alle Prozesse einer Ebene (2. oder 3. Ebene der Dekomposition bzw. des zugehörigen Datenflusses) sowie alle an diesen anliegenden Flüsse. Jeder Fluß entspricht dabei einer Function (einer vom System zu bearbeitenden Aufgabe).

2. Bewertung des Schwierigkeitsgrades durch ,,Points"

Jeder dieser Flüsse wird in eine der folgenden Gruppen eingeordnet und anhand der Flussbeschreibung (ERD oder Flow-Expression) bewertet (komplex, mittel oder einfach). Damit wird die in den einzelnen Gruppen angeführte Punktezahl (,,Points") ermittelt und aufsummiert.

Die Bewertung besteht aus:

- Eingabedaten
- Ausgabedaten
- Abfragen
- Datenbestände
- Referenzdaten

Eingabedaten

Dateneingaben können sein:

Bildschirm-Eingaben

Abbildung in dieser Leseprobe nicht enthalten

Ausgabedaten

Datenausgaben können sein:

Bildschirm - Ausgaben

Berichte in Listenform oder Formulare

Ausgabe auf Micro - Fiche und Micro - Film

Interface - Daten an andere Anwendungen

Druckerausgaben dezentral auf Terminaldrucker

Abbildung in dieser Leseprobe nicht enthalten

Abfragen

Zu zählen ist jede Abfrage, die zu einem Suchen nach Informationen in einem Datenbestand führt und bei der das Ergebnis dem Benutzer sichtbar gemacht wird. Gezählt wird jeweils jede unterschiedlich formatierte Online-Eingabe. Nicht gezählt werden Abfragen durch Endbenutzersprachen. Abfragen mit vielen Verarbeitungsschritten, Zugriff auf mehrere Dateien, evtl. Zwischenverarbeitung mit Speicherung und/oder Sortierung, zählen nicht als Ausgaben, sondern als Eingaben und als Ausgaben.

Abbildung in dieser Leseprobe nicht enthalten

Datenbestände

Zu zählen ist jeder Datenbestand, der von der Anwendung "gewartet" (update, insert, delete) und/oder betreut wird (Security, Recovery). Gezählt wird jeweils jede logische Datengruppe, die in der Anwendung verwendet wird (Zwischendateien, Sortdateien werden nicht gezählt). Die Einteilung in logische Datengruppen geschieht nach organisatorischen - nicht technischen

- Gesichtspunkten.

Abbildung in dieser Leseprobe nicht enthalten

Referenzdaten

Zu zählen ist jeweils jede Datei, die in der Anwendung als Informationsträger benötigt wird, z.B.: Tabellen, Read - Only - Dateien. Jene Tabellen, die nur aus technischen Gründen benötigt werden, werden nicht berücksichtigt.

Bei Read-Only-Dateien wird jeweils jede logische Datengruppe gezählt und nach folgenden Kriterien klassifiziert:

Abbildung in dieser Leseprobe nicht enthalten

Bei Tabellen (jede Tabelle wird gezählt) werden folgende POINTS verwendet:

Abbildung in dieser Leseprobe nicht enthalten

3. Analyse der Einflussfaktoren

Der Entwicklungsprozess wird zusätzlich zu den Function - Points noch von weitern Faktoren beeinflusst. Folgende Einflussgrößen werden berücksichtigt:

1. Verflechtung mit anderen Verfahren

2. DDP-Konzept

Verwaltung der Daten oder die Verflechtung wird dezentral durchgeführt (Distributed Data Processing - Konzept)

3. Transaktionsrate

Die Anwendung hat eine so hohe Transaktionsrate, dass besondere Maßnamen bei Design, Programmierung und Systemtest zu ergreifen sind.

4. Verarbeitungslogik

5. Wiederverwendung in anderen Verfahren

6. Datenbestandkonvertierung

Für die Datenbestandkonvertierung sind besondere Maßnahmen bei Design, Programmierung und Systemtest zu ergreifen

7. Parametrisierbarkeit durch den Benutzer

Design und Programmierung der Anwendung sehen

Einrichtungen vor, die den Benutzer die Bedienung und den Wechsel bei Änderungen erleichtern.

Alle Einflussgrößen werden auf einer Skala von 0 bis 5 geschätzt außer die Verarbeitungslogik.

Die Verarbeitungslogik erhält 0-30 Punkte und summiert sich aus den

Größen:

- schwierige/komplexe Rechenoperationen: 0-10 · umfangreiche Kontrollverfahren: 0-5 · viele Ausnahmeregelungen: 0-10 · schwierige, komplexe Logik: 0-5

Die Wiederverwendung in anderen Verfahren gibt an, wie stark eine Wiederverwendung der Programme in anderen Anwendungen zu berücksichtigen ist:

Abbildung in dieser Leseprobe nicht enthalten

Die Einflussfaktoren können das Ergebnis um +/-30% verändern.

4. Berechnung der bewerteten Function - Points

Die Summe der bewerteten Function - Points wird gemäß folgender Formel berechnet:

BFP=FP * (0,7 + EF * 0,01)

BFP = Summe der bewerteten Function Points

FP = Summe der Bewertung des Schwierigkeitsgrades EF = Summe der Analyse der Einflussfaktoren

EF liegt im Bereich 0 - 60. Der Klammerausdruck liefert also einen Wert zwischen 0.7 und 1.3; d.h. die Einflussfaktoren können den Wert FP um 30% verändern. Liefert der Klammerausdruck 1, so liegt kein besonderer Einfluss vor.

5. Ermittlung des Aufwandes

Um jetzt den Aufwand in Form von Mannmonaten zu bekommen muss man geeignete Umrechnungstabellen erstellen. Normalerweise hat man durch die Praxis im Betrieb ausreichende Erfahrung gesammelt mit denen man leicht eine solche Tabelle erstellen kann.

Weiters kann es vorkommen, dass der Betrieb schon über eine geeignete Tabelle verfügt. Diese Tabelle dient dann nur als Richtwert, da jeder, der eine Aufwandschätzung vornimmt anders bewertet. In diesem Fall ist es besser eine eigene Tabelle zu erstellen und die daraus resultierende Kurve (x = BFP; y = Mannmonate) an die Betriebseigene anzugleichen. Die eigene Tabelle sollte außerdem laufend aktualisiert werden, d.h. die Erfahrungen abgeschlossener Projekte sollte laufend integriert werden.

Sind beide Möglichkeiten nicht vorhanden so kann man die IBM-Tabelle als Vorlage hinzuziehen. Diese Tabelle kann aber nur als Richtwerttabelle verwendet werden, da sie auf Assembler Programmierung aufgebaut ist.

Aufwandschätzung (Formular)

Eingabedaten Ausgabedaten Datenbestände

Abbildung in dieser Leseprobe nicht enthalten

Einflussfaktoren

1) Verflechtung mit anderen Verfahren [0..5] =

2) Dezentrale Verarbeitung [0..5] =

3) Transaktionsrate [0..5] =

4) Verarbeitungslogik Rechenoperationen [0..10] = Kontrollverfahren [0..5] = Ausnahmeregelungen [0..10] = Logik [0..5] =

5) Wiederverwendung in anderen Verfahren [0..5] =

6) Datenbestandskonvertierung [0..5] =

7) Benutzerführung [0..5] =

Summe der 7 Einflüsse = (= E2)

Faktor Einflußbewertung: 0,7 + E2/100 = (= E3) Bewertete Function Points: E1 x E3 = Ergebnis in Mannmonaten:

Umrechnungstabelle: Function Points - Mannmonate

IBM-Tabelle:

Abbildung in dieser Leseprobe nicht enthalten

COCOMO (Constructive Cost Model)

Das COCOMO - Modell ist eineinfaches Verfahren zur Schätzung des Aufwands und der Zeitdauer von Softwareprojekten. Entwickelt wurde das COCOMO - Modell von Barry W. Boehm.

Als wichtigste Ausgangsgröße des COCOMO - Verfahrens ist zunächst vom Bearbeiter die Anzahl der ,,Kilo Delivered Source Instructions" (KDSI) zu schätzen. Hierbei handelt es sich um die Anzahl der im Programm selbst enthaltenen Befehle in 1000. Im Gegensatz zu den ,,Source Lines of Code" (SLOC) werden bei den KDSI Kommentar- und Dokumentationszeilen sowie Hilfsroutinen für Programmtests nicht mitgezählt.

Zu Beginn des Projektes ist der Aufwand schwer zu schätzen, am Ende jedoch leicht festzustellen ist. Daraus wird der Aufwand in Bearbeitermonaten mit einer logarithmischen Formel errechnet, in die viele aus abgeschlossenen Projekten gewonnenen Parameter einfließen.

Bevor man mit der Aufwandschätzung beginnt muss man den Schwierigkeitsgrad des Projektes bekannt geben:

Man unterscheidet:

Einfache Projekte (Organic Mode oder Anwendungsprogramme)

Einfache Projekte werden von relativ kleinen Teams in einer vertrauten In-House-Umgebung durchgeführt. Die zu entwickelnde Programme sind meist Stand-Alone-Anwendungen, mit geringen Schnittstellen zu anderen Systemen. Die meisten Mitglieder des Teams verfügen über große Erfahrungen mit ähnlichen Systemen und wissen genau, wie das zu entwickelnde System funktionieren muss, damit es dem

Unternehmen einen hohen Nutzen bringt.

Mittelschwere Projekte (Semidetached Mode oder Programmsysteme)

Mittelschwere Projekte stellen eine Zwischenstufe zwischen einfachen und komplexen Projekten dar. Das Projektteam verfügt bereits über gewisse, wenn auch nicht sehr tiefgehende Erfahrungen mit ähnlichen Systemen und Abläufen. Das System weist viele Schnittstellen zu Nachbarsystemen auf. Typische Beispiele für mittelschwere Projekte sind anspruchsvollere Fertigungssteuerungssysteme.

Komplexe Projekte (Embedded Mode oder eingebettete Systeme)

Das Hauptunterscheidungsmerkmal komplexer Softwareprojekte ist eine enge Verzahlung des zu entwickelnden Softwaresystems mit anderen Hard- und Softwaresystemen und Betriebsabläufen. Typische Beispiele sind eingebettete Echtzeitsysteme zur Flugzeugsteuerung oder zur Telefonvermittlung.

Abbildung in dieser Leseprobe nicht enthalten

Dieses Bild zeigt eine graphische Veranschaulichung der Kosten über der Produktgröße.

Aus dem Grundwert (KDSI) und einer Reihe von Kosten-Multiplikatoren werden Kosten und Durchlaufzeiten berechnet. Die Grundgleichungen lauten:

· Für ,,Einfache Projekte"

MM = 2,4 KDSI [1].[05] (MM = man month) TDEV = 2,5 MM [0],[38] (TDEV= time to develop) · Für "Mittelschwere Projekte"

MM = 3,0 KDSI [1].[12]

TDEV = 2,5 MM [0],[35]

· Für ,,Komplexe Projekte"

MM = 3,6 KDSI [1].[2]

TDEV = 2,5 MM [0],[32]

Die mit den Grundgleichungen ermittelten Nominalwerte können nun noch erheblich genauer gemacht werden, indem man sie mit einer Reihe von Kostenfaktoren multipliziert. Die nächste Seite (Tabelle) zeigt Boehm's Kostenfaktoren-Tabelle.

Die aktuellen Werte aller Kostenfaktoren für ein Projekt werden unabhängig voneinander geschätzt und anschließend alle miteinander multipliziert. Der Nominalwert für den Projektaufwand in Personenmonaten wird dann mit diesem Produktfaktor multipliziert.

MMKorr = Produkt der Kostenfaktoren * MMnominal

Abbildung in dieser Leseprobe nicht enthalten

Unterschied zwischen Function Points und COCOMO

Die Function Point ist besonders für die Aufwandschätzung kaufmännischer Anwendungen geeignet, für technische oder betriebssystemnahe Anwendungen jedoch ungeeignet. Das Verfahren kann nur für gesamte Anwendungen angewendet werden (d.h. nicht nur auf Modul/Programmebene). Das Anwendungssystem ist dabei aus der Sicht des Benutzers zu betrachten.

COCOMO verwendet die Gewichtungsmethode und parametrische Schätzgleichungen, es ist eher für große und sehr große Anwendungen hoher Komplexität geeignet. Für kleine/mittlere bzw. kaufmännische Projekte liefert COCOMO zu hohe Werte.

Quellenverzeichnis:

Felix Schwab, Wilfried Schneider, Ingrid Schwab-Matkovits; EDV - Projektentwicklung. Wien: Manz 1999.

Ernst Denert; Software - Engineering, Methodische Projektabwicklung. Berlin: Springer 1991.

Klaus Gewald, Gisela Haake, Werner Pfadler; Software - Engineering, Grundlagen und Technik rationeller Programmentwicklung. München; Wien: Oldenbourg 1985

Technische Akademie Esslingen. In Zusammenarbeit mit der Gesellschaft für Informatik e.V.; Software-Entwicklung - Methoden, Werkzeuge, Erfahrungen ... ; ... Kolloquium Ostfildern: Techn. Akad. Esslingen 1995

Verwendete Links:

Einführung in Software-Engineering:

http://www2.informatik.uni-erlangen.de:8081/IMMD-II/Lehre/SS98/SE/index.html

COCOMO-Softwarekostenschätzung:

http://www.fh-dieburg.de/HOME/Seibert/cocomo.htm

Skriptum:

http://www.ifi.unizh.ch/groups/req/courses/se_I/#Herunterladen

Entwicklung einer ProjektDatenbank mit MS Access 2.0:

http://www.schwaben.de/home/peterh/projektdb

Promok Georg Seite /13

20 von 20 Seiten

Details

Titel
Projektplanung
Note
1
Autor
Jahr
2000
Seiten
20
Katalognummer
V98449
Dateigröße
489 KB
Sprache
Deutsch
Anmerkungen
informativ, gut ausgearbeiten, genau ins Detail gegangen
Schlagworte
Projektplanung
Arbeit zitieren
Georg Promok (Autor), 2000, Projektplanung, München, GRIN Verlag, https://www.grin.com/document/98449

Kommentare

  • Gast am 1.6.2001

    Projektplanung.

    Diese Arbeit ist für Fachleute sicherlich aufschlußreich, für Fachfremde entstehen in erster Linie nur Fragezeichen im Kopf.

  • Gast am 27.4.2002

    irreführender Titel.

    Der Titel "Projektplanung" lies mich einen anderen Inhalt vermuten. Eigentlich geht es doch aber um die Aufwandschätzung von Softwareprojekten mittels FPU und COCOMO.

Im eBook lesen
Titel: Projektplanung



Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden