Sie sind auf Seite 1von 2

Aufgabe 1: size = 4500 (Vorgabe) Wir entschieden uns fr die Kategorisierung Organic, da wir von einem zwei Mann

Team ausgehen. Product Attributes: mode = 1.05 Required Reliablility = 1.00 Nominal: Wir entschieden uns fr Nominal, da bei einem Ausfall zwar Unannehmlichkeiten, aber kein nennenswerter Wirtschaftlicher Schaden entstehen kann, da es nach wie vor Ausweichplattformen gibt (zB schwarzes Brett) Database Size = 0.94 Low: Wir entschieden uns fr Low, da die Datenbankeintrge (bei automatischer lschung abgelaufener Angebote) in berschaubarer Grenordnung bleiben. Product Complexity = 0.85 Low: Zwar besteht das Produkt aus zwei scheinbar getrennten Systemen (Server, Onlinemaske) aber die Entwicklung luft parallel und ist jeweils nicht sonderlich komplex. Computer Attributes: Execution Time Constraints = 1.00 Very Low: Moderne Computer rechnen die notwendigen Kalkulationen in Threads und bentigen einen Bruchteil ihrer Leistung. (Dies gilt fr Server wie fr Client) Main Storage Constraint = 1.00 Very Low: Es wird nur ein geringer Speicher seitens des Clients bentigt um die Suchergebnisse anzuzeigen. Der Server verwaltet die Eintrge in einer Datenbank. Auch hier wird nicht viel Speicher bentigt. Virtual Machine Volatility = 0.87 Low: Das Zusammenspiel von Server und Client hngt mon mehreren Systemen ab deren Ausfallsicherheit zwar nicht garantiert, aber in der berwiegenden mehrzahl der Flle angenommen werden kann. Computer Turnaround Time = 0.87 Low: Die Kompilation des Projektes ist bei 4500 SLOC recht gering und kann innerhalb weniger Sekunden durchgefhrt werden, weshalb ein Test umgehend mglich ist. Personnel Attributes: Analyst Capability = 1.00 Nominal: Da wir die Analysen etc. selbst durchfhren ist nicht auszuschlieen, dass mit Verzgerungen bzw Kostenverschiebungen zu rechnen ist. Applications Experience = 1.00 Nominal: Unser Projektteam ist mittelmig erfahren mit der Entwicklung von Systemen dieser Grenordnung. Programmer Capability = 0.86 High: (offensichtlich ) Virtual Machine Experience = 1.00 Nominal: Der Umgang mit Html-Servern und SQL-Datenbanken ist kein groes Problem. Programming Language Experience = 0.95 High: Das Projektteam kennt sich mit der verwendeten Programmiersprache gut aus. Project Attributes: Modern Programming Practices = 0.91 High: Wir halten uns an die in den Fchern SQ und EST vermittelten Praktiken und schtzen unsere Codequalitt daher hoch ein. Use of Software Tools: = 1.00 Nominal: Die Verwendung von IDEs und Test-Tools

Required Developement Schedule = 1.00 Nominal: Das Projektteam kann in den meisten Fllen recht frei Programmieren. Es gibt kaum Einschrnkungen was APIs angeht und daher sollte es hier keine Probleme geben. Berechnung: Aufwand E = M * 3,2 (S/1000) 1,05

M = 0,94 * 0,85 * 0,87 * 0,87 * 0,86 * 0,95 * 0,91 = 0,44962 1,05 E = 0,44962 * 3,2 * 4,5 = 6,98 PM

Aufgabe 2:

Unsere Zeit- und Kostenschtzung stimmt mit der von COCOMO81 berein. Der Unterschied zwischen COCOMO und dem Function Point - Verfahren (FPA) wird deutlich, wenn man sich beide Verfahren einmal genauer ansieht. FPA basiert auf den zu erwartenden Funktionen und Daten, whrend COCOMO auf die geschtze Anzahl an Code - Zeilen basiert. Aufgrund dieser Grundlage eignen sich beide Anwendungsgebiete fr unterschiedliche Verfahren. FPA eignet sich sehr fr bspw. Software, die Daten von einer Datenbank abfragt, Usereingaben verwaltet oder Berechnungen archiviert (wie z.B. Software fr Banken, Warenhuser, etc.). Ein weiterer Vorteil des FPA ist, dass man schon in frhen Stadien des Projekts eine relativ gute Einschtzung der Personenmonate errechnen kann. Sobald jedoch ein nichttrivialer Algorithmus entworfen oder implementiert werden muss kann die Bearbeitungszeit dessen nicht mit FPA erfasst werden. Da ist dann das COCOMO Modell genauer und bezieht diese Algorithmen mit den geschtzten Codezeilen mit ein. Das Fazit: FPA ist bei funktionalen und Datenbankprojekten sehr schnell, es werden wenige Daten gebraucht (eben die Funktionen und Eingaben etc). Man sollte jedoch bei wissenschaftlichen Projekten (Entwicklung neuer Algorithmen, Berechnung von Werten ber komplexe Formeln, etc.) doch lieber zu COCOMO greifen.

Aufgabe 3:

Moderator: Stephanie Lange Notar: Viktor Gutachter: Janis Schck Gutachter: Eric Seiz Gutachter: Michael Schrder Gutachter : Manuel Ross