GUIMARÃES, Valéria Aparecida [1]
LARA, Alexander Prado [2]
PUTTINI, Ricardo Staciarini [3]
GUIMARÃES, Valéria Aparecida; LARA, Alexander Prado; PUTTINI, Ricardo Staciarini. Point Analysis Anwendung für Service in SOA-Projekten. Magazin multidisziplinären wissenschaftlich Knowledge Center. Ausgabe 08. 02 Jahr, Vol. 01. S. 88-102, November 2017. ISSN:2448-0959
Zusammenfassung
Schätzen Sie die Größe einer Software zur Entwicklung von entscheidender Bedeutung ist eine verlässliche Schätzung der Kosten und Zeit zu erhalten. Eines der am häufigsten verwendeten Messverfahren und dokumentiert die Größe einer Software zu erhalten, ist die Function Point Analysis (FPA), die jedoch ihre Anwendbarkeit auf Projekte hat, die den Ansatz verwenden Oriented Architecture Service (SOA) oft in Frage gestellt. Dieser Beitrag stellt das Ergebnis auf einem System die APF Anwendung vollständig mit dem SOA-Ansatz entwickelt, der von APF mit Aufwand, Zeit und die tatsächlich Projektkosten produzierten eine weiteren Vergleich der Schätzungen erlaubt.
Stichwort: Software Estimation, Software Metering, APF, SOA.
1. Einführung
Schätzen Sie die Größe einer Software entwickelt werden, wesentlich ist, eine verlässliche Schätzung der Kosten und Zeit (WILKIE 2011) zu erhalten, aber richtig diese Art der Schätzung durchführt, indem die Literatur als eine der größten Herausforderungen für Manager in diesem Bereich (Pressman konfrontiert ernannt 2011; WILKIE 2011; Kaur 2016). Dies zeigt sich zum Beispiel Roetzheim (2000), der seit 18 Jahren geführt, umfangreiche Forschung, die festgestellt, dass die Hauptursachen für Software-Projekt Ausfälle zu schlechten Kosten verbunden sind Schätzungen und Umsetzungszeitplan, und nicht auf technische Probleme, politische oder Entwicklungsteam.
Obwohl keine exakte Wissenschaft, da der Einfluss der menschlichen Variablen, technischen, ökologischen und politischen (SOARES 2013), Messtechnik (und Metriken) Software kann von mehr durchsetzungs Schätzungen wesentlich zur Erzeugung beitragen, die verringert sich die Diskrepanz zwischen dem, was geschätzt wurde und was durch die Bereitstellung einer effizienteren Kostenkontrolle, Risikoreduzierung, Verbesserung der Qualität und gewährleisten, dass die Geschäftsziele erreicht und Probleme, um Trends zu erkennen und antizipieren erreicht (FLORAC 1997 wurde ; Pressman, 2008; Tichenor, 2013; SOARES 2013).
Eines der am häufigsten verwendeten Messverfahren und dokumentiert die funktionale Größe einer Software zu erhalten, ist APF (die Abkürzung in Englisch FPA Function Point Analysis) (IFPUG 2010; WILKIE 2011; SOARES 2013). Diese Methode wurde erstmals Mitte der 70er Jahre von Allan Albrecht (ALBRECHT, 1984) und verbessert die von der Internationalen Function Point Users Group (IFPUG) veröffentlicht und ist bereits gut etabliert und weit auf der ganzen Welt (IFPUG 2010; CALAZANS 2011; SISP, 2015). Das Verfahren verwendet Funktionspunkte (PF) als Maß Einheit (IFPUG, 2010).
Trotz der Konsolidierung der APF als eine Technik zur Auslegung der funktionale Größe von Software (Lindskoog, 2009; IFPUG, 2010) und die fortgesetzten Bemühungen zur Verbesserung und Weiterentwicklung des Verfahrens gibt es Szenarien, in denen ihre Annahme leitet nicht. Software-Projekte, die folgen-orientierte Architektur-Ansatz (SOA) – Architektur für die Softwareentwicklung, dessen Grundprinzips ist wiederverwendbar und interoperable Dienste (ERL 2005) zu bauen, einen Teil der Einstellungsliste ist, wo die Anwendung von APF in Frage gestellt wird .
Diskussionen über die Anwendbarkeit des Verfahrens für SOA-Projekte waren konstant und bleiben viele Herausforderungen für die Annahme zu überwinden. (Gencel, 2008; Lindskoog, 2009; Gomes, 2012). Diese Schwierigkeit ergibt sich aus mehreren Faktoren ab, in denen wir die Tatsache hervorheben, dass in SOA-Projekten werden viele Funktionen für die Wiederverwendung konzipiert, die für den Rahmen eines Projektes brechen den Funktionsumfang der Anwendung entwickelt es üblich macht ( ERL, 2005). Darüber hinaus SOA, müssen komplexe Systeme aufgeteilt in Dienstleistungen und ein großer Teil der Anstrengungen der Analyse und Design ist genau auf den Zersetzungsprozess und die anschließende Wiederherstellung der Dienste verknüpft. Dieser Prozess erfordert die explizite Anwendung von Methoden und Prinzipien lose Kopplung, Zusammensetzung Fähigkeit, Standardisierung und Transaktions Vermittlung zu erreichen, unter anderem, die in der Entwicklung herkömmlicher Software nicht vorhanden sind (ERL 2008). So für die traditionelle Entwicklung verwendet Metriken und Aufwandsschätzung Benchmarks konnte nicht direkt in SOA-Projekten (; Farrag 2015 Lindskoog, 2009) angewendet werden.
In diesem Zusammenhang stellt dieser Artikel die Ergebnisse einer Fallstudie die Messung beteiligt, durch die APF, eine voll entwickelte Software des SOA-Ansatz für die späteren Vergleich mit dem Aufwand, Zeit und tatsächlich Kosten entfallen bei der Implementierung der Software. Die Arbeit wurde aus Daten von einem realen Projekt gesammelt entwickelt, die die Autoren vollen Zugang hatten.
Dieser Artikel ist wie folgt aufgebaut: Abschnitt 2 fasst die grundlegenden Konzepte im Zusammenhang mit PF-Analyse und SOA sowie wichtige wissenschaftliche Arbeit, die den Vorschlag geführt. In Abschnitt 3 werden die Arbeitsmethodik angenommen, während Kapitel 4 die erhaltenen Ergebnisse präsentiert. Schließlich Abschnitt 5 bringt die wichtigsten Schlussfolgerungen und abschließende Bemerkungen.
2. Konzepte
2.1 Function Point Analysis (FPA)
Wie bereits erwähnt, die APF ist eine Technik zur Messung von Software oder Projektentwicklung / Wartungssoftware von der International Function Point Users Group (IFPUG) gehalten und das die funktionellen Größe „Funktion zielt darauf ab, Punkte auf der Erlangung „(PF), die Benutzer-Sicht unter Berücksichtigung (IFPUG, 2010). Die IFPUG veröffentlichen und aktualisiert Zählen Practices Handbuch halten (CPM – Zählen Practices Manual), die die Regeln und das Verfahren enthält befolgt werden, konsistentere Ergebnisse bei der Anwendung von APF (IFPUG, 2010) zu gewährleisten.
Organisationen können diese internationale Norm gilt für die Größe einer Software zu messen, um: (i) zu schätzen, Aufwand, Kosten und Zeitaufwand für die Entwicklung, Erhaltung und Verbesserung der Software; (Ii) bieten Unterstützung für die Analyse der Qualität und der Produktivität; (Iii) einen Normierungsfaktor für den Vergleich von Software (IFPUG, 2010). Seine Verwendung hat viele Vorteile, darunter: Ziel Zählregeln, die Unabhängigkeit der technologischen Lösung und Programmiersprache und die Möglichkeit Generation bereits in den frühen Phasen des Software-Lebenszyklus (SISP, 2015) zu schätzen.
Die Anwendung des Verfahrens umfasst die folgenden Schritte durchgeführt wird, detailliert in der CPM (2010): (i) erhält die verfügbare Dokumentation; (Ii) identifizieren, den Zweck und die Art der Partitur, bestimmen den Umfang der Zählung und die Grenze der Anwendung; (Iii) Messdaten-Funktionen, die die funktionalen Anforderungen der Nutzer in Bezug auf die Lagerung und / oder Wiederherstellung von Daten und klassifiziert in logische Datei Internal (ALI) – Logische Datengruppen innerhalb der Anwendung Grenze beibehalten, und External Interface File (IEA) – sind nur durch die Anwendung verwiesen gemessen wird; (Iv) Messen der Transaktionsfunktionen, die für die Datenverarbeitung für den Benutzer bereitgestellt sind Funktionen, die von einer Anwendung und werden klassifiziert in (a) Externe Eingänge (EE) – verantwortlich für die Datenverarbeitung oder Steuerinformationen, die ihren Ursprung haben, die außerhalb Anwendung der Grenze; (B) Outpatients (EG) – verantwortlich für das Senden von Daten oder Steuerinformationen, die aus der Anwendung der Grenze kommen; (C) Externe Ausgänge (SE) -, die für das Senden von Daten oder Steuerinformationen, die aus der Anwendung der Grenze kommen, einschließlich zusätzlicher Verarbeitungslogik neben dem in einer Ambulante identifiziert; (V), um die funktionale Größe berechnet wird; (Vi) Dokument und die Berichterstattung über die Zählung. Das heißt, von der Design-Dokumentation oder Software und wird unter dem Punkt Benutzer-Sicht (funktionale Anforderungen) abgeleitet PF in Bezug auf die Funktionen angeboten und beteiligt Daten. Nachdem die Menge an PF und anhand von Modellen wie dem vereinfachten Modell Schätzungen (Vazquez, 2012) oder das Modell COCOMO II (Boehm, 2009), aus dem Aufwand, Zeit und Kosten eines Projekts abgeleitet.
2.2 Service Oriented Architecture (SOA)
SOA ist ein architektonisches Konzept für Software-Entwicklung, deren Grundprinzip ist wiederverwendbar und interoperable Dienste (ERL 2005) zu bauen. Nach ERL (2005), Der Service ist die grundlegende Einheit der serviceorientierten Logik (Logik der Lösung), dh die Funktionen der Anwendung in Form von Service zur Verfügung.
Eine Logik gilt, wenn einige Service-orientierten Prinzipien, wie SOA-Prinzipien bekannt zu einer signifikanten Verlängerung der Lösung aufgebracht werden (ERL 2005). Nach ERL (2008) sind acht dieser Grundsätze: (i) Vertrag Standardisierung; (II) lose gekoppelte Dienstleistungen; (III) -Dienst Abstraktion; (IV) -Dienst Wiederverwendung Kapazität; (V) -Dienst Autonomie; (VI) Dienstzustand der Unabhängigkeit; (VII) Servicetransparenz (Capability Discovery); und (VIII) Servicekapazität der Zusammensetzung.
SOA sucht, durch Anwendung der Grundsätze: die Ausrichtung zwischen Unternehmen zu erhöhen und IT; Föderalisierung (Zugang zu Dienstleistungen ist standardisiert, um die Vision seiner Kunden zu vereinen); Lieferantenvielfalt; die Return on Investment (ROI); und organisatorische Beweglichkeit; und verringert die Belastung der IT in der Organisation (ERL 2008). So SOA ermöglicht es Ihnen, Anwendungen zu erstellen, die schnellen Anforderungen an Unternehmen reagieren, da Dienste in einer einheitlichen Art und Weise aufgebaut sind, (kommunizieren) miteinander in üblichen Weise zusammenarbeiten zu können und transparent, unabhängig von der Plattform, Lieferanten oder Technologien die sie in oder Lauf gebaut.
Obwohl seit einiger Zeit schon hat SOA Bedeutung gewonnen nur aus der Mitte der 2000er Jahre (ERL 2005). rasch Nach jüngster Umfrage (Wintergrün, 2014), wächst der SOA-Markt. Der Forschungsbericht zeigt, dass der SOA-Markt der USA erreichte im Jahr 2013 $ 5,7 Milliarden und könnte bis 2020 US $ 16,4 Milliarden erreichen. Laut der Umfrage, ist dies ein deutliches Wachstum auf die Tatsache zurückzuführen, dass SOA effizientere automatisierte Prozesse bieten und IT die Möglichkeit bieten, mehr des Budgets zu investieren, auf das Geschäft wächst. Darüber hinaus mit entkoppelten Softwarelösungen (parteilos), SOA-Service effizient wiederverwendet werden.
3. Präsentation der Arbeitsmethodik Angenommen
Die Messung durch die Verwendung von PF die funktionalen Größe REFERENCE DESIGN, indem die Zählung festgelegten Regeln in CPM (IFPUG 2010) mit dem Ziel zu identifizieren, durch eine vergleichende Analyse durchgeführt, um zu erhalten, was die Kosten sein würde , Zeit und wirkliche Anstrengung bei der Realisierung des Projekts verzichtet und ergibt sich aus der Anwendung von APF erhalten. So war es möglich, zu beurteilen, ob die Verwendung des APF für die Messung des Projektes geeignet wäre (unter dem SOA-Ansatz entwickelt).
3.1 Projektauswahl
Die Wahl des Designs erfolgte natürlich verwendet werden, da das Unternehmen, in dem Autor Arbeit wurde beauftragt SOA Adoption von einer Organisation für Informationen aus Gründen der Vertraulichkeit zu strukturieren, wird .Die im Laufe dieses Artikels Auftragnehmer genannt werden Projekt zielte darauf ab, im allgemeinen der Struktur der SOA-Einführung durch den Auftragnehmer. Aktivitäten wurden für die Strukturierung, Entwicklung, Umsetzung und Überwachung von SOA Adoption Program durch die Durchführung von Aktivitäten entwickelt, die enthalten sind, entres andere, entwickelte ein System zu schaffen völlig den SOA-Ansatz und REFERENCE DESIGN aufgerufen werden über dieser Artikel.
3.2 Messreferenzdesign
REFERENCE DESIGN durch die Verwendung von PF Messung wurde nach der vollständigen Implementierung und Bereitstellung der Software durchgeführt. Daher haben wir beschlossen, eine detaillierte Zählung durchzuführen, die auch die Höhe der Transaktionsfunktionen betrachtet, die funktionale Komplexität (Niedrig, Mittel, Hoch) jede einzeln Funktion. Sie wurden als Messeingänge verwendet, zusätzlich zu Artefakten bei der Entwicklung des Projekts erzeugt, Zugriff auf die Software ausgeführt wird. Wir zählen auch mit dem Gutachten der Mitglieder des Projektteams.
3.3 Estimating Software-Projekt-Effort
Mehrere Modelle Aufwand von Software-Projekten zu schätzen, basierend auf PF, sind derzeit verfügbar, und die vereinfachten Modelle Schätzungen (Vazquez (2012)) und Modell COCOMO II (Boehm, 2009) die am häufigsten verwendeten (SISP, 2015). In dieser Studie haben wir die vereinfachte Modellschätzungen, die gleiche von der SISP verwendet (2015).
4. experimentelle Ergebnisse
4.1-Referenzdesign
In diesem Abschnitt wird die tatsächlichen Ergebnisse der Umsetzung von REFERENCE DESIGN erhalten, die Informationen über das Projektteam, Aufwand, Zeit und Projektkosten beinhaltet.
4.1.1 Projektteam
Tabelle 1 zeigt die Mitarbeiter an der Entwicklung der Lösung zugeordnet. Sie stellen Informationen über die Zahl der Menschen, die in dem Projekt nach Art der Ressource / Rolle beteiligt, die Rolle der dem Team zugewiesene Ressource mit ihrer jeweiligen porcentam von particação und dem relativen Engagement in Prozent, eine Ressource / spezifischen Rolle über das gesamte Projekt.
4.1.2 Zeit und Aufwand Erreicht
REFERENCE DESIGN dauerte sechs Monate und die wirkliche Anstrengung wurde gemessen, indem Stunden in JIRA Aufnahme, ein Werkzeug, das die Überwachung von Projekten durch die Registrierung Aktivitäten und Reporting ermöglicht. Tabelle 2 zeigt den auszugebende Aufwand bei der Herstellung jeder Projektentwicklung.
Tabelle 2: Referenzdesign Anstrengungen unternommen
| Phase-Projekt | Stunden |
| Business-Modellierung und Analyse | 1076 |
| Implementierung | 826 |
| Thesen und Implementierung | 268 |
| Gesamtstunden | 2170 |
4.1.3 Kosten gehaltene
Die Kosten wurden von Stunden UST Umwandlungseinheit (Technical Services) berechnet, die die medizinische Einheit verwendet, um die Arbeit zu quantifizieren. Das heißt, die Menge an Mannstunden zu UST als vertragliche Definition umgewandelt Kosten abzuleiten. Die Berechnung der UST berücksichtigt die Komplexität der Aktivität durchgeführt (niedrig, mittel und hoch). Tabelle 3 zeigt das Ergebnis der Umwandlung der Stunden / UST für jede Projektphase.
Tabelle 3: Kosten Directed-Referenzdesign
| Phase-Projekt | Stunden | UST |
| Modellierung und Analyse | 1076 | 1765 |
| Implementierung | 826 | 894 |
| Thesen und Implementierung | 268 | 304 |
| Gesamtstunden | 2170 | 2963 |
In Anbetracht der UST vertraglich vereinbarten Höhe von R $ 247,50, hatte das Projekt mit Gesamtkosten von R $ 733,342.50
4.1.4 Allgemeine Ergebnisse
Die Tabelle 4 zeigt die Zusammenfassung der Aufwand, Zeit und Kosten bei der Herstellung des Referenzdesigns verzichtet, die für die vergleichende Analyse mit dem Messergebnis der funktionalen Größe der Software durch die Verwendung mp als Grundlage dienen.
Tabelle 4: Gesamter
| REFERENCE DESIGN | |
| Effort (Stunden): | 2170 |
| Laufzeit (Monate): | 6 |
| Kosten (R $): | R $ 733,342.50 |
4.2 Messung der Größe der Funktions – IFPUG
Die funktionale Messung der Software-Größe von FP mit betrachten die Anwendung als Ganze, mit der funktionalen Sicht auf die Sicht des Benutzers, wie sie in dem Standard-APF IFPUG (IFPUG, 2010) empfohlen. Tabelle 5 zeigt das Ziel (Ziel oder Zweck der Messung) und Messumfang (Satz oder Teilsatz von Anwendungen, die gemessen werden). Tabelle 6 zeigt kurz die Ergebniszähler auf den Wert der funktionellen Größe des Referenz-Designs entsprechen. Das Bypass-Periode Effort Personal und Kosten wurden anhand von vereinfachten Modellschätzungen bestimmt, die in Tabelle 7 dargestellt.
Tabelle 5: Funktions Szenario Maßhinweis DESIGN
| funktionale Szenario | |||
| Zweck der Messung | Funktionale Größenmessung (APF IFPUG) Referenzdesign als Auftragnehmer von SOA Adoption Program entwickelt. | ||
| Scope Mess | Anwendungen Referenz-Design | ||
Count Technik: bestimmt, ob die Zählung indikativen geschätzt oder gebrochen. Die indikative Zählen basieren nur auf Informationen über die Daten-Funktionen, also auf der Anzahl von logischen Dateien (Alis und SIAs). Die geschätzte Zählung hält, in der Datenmenge Funktionen, Informationen über die Transaktionsfunktionen, so dass damit die Anforderungen der Anwender benötigen mehr detailliert. Wie für detaillierte zählt, sowie die Höhe der Transaktionsfunktionen, ist es notwendig, die funktionale Komplexität (Niedrig, Mittel, Hoch) jede einzelne Funktion (NESMA, 2015) zu bestimmen.
Typ-Zähler: drei mögliche Arten des Zählens: (i) Entwicklung: Da die Funktionalität für Benutzer bereitgestellt, um die erste Installation der Software unter Berücksichtigung. (Ii) Verbesserung / Wartung: bedingte Veränderungen, es wird, hinzugefügt, geändert oder gelöscht werden, um eine bestehende Software-Funktionalität. (Iii) Anwendung: Messung von Funktionalität, die eine Anwendung bietet den Anwender. Eine Anwendung ist zusammenhängende Reihe von automatisierten Verfahren und Daten, die ein Geschäftsziel unterstützen soll und besteht aus einer oder mehreren Komponenten, Module oder Subsysteme (IFPUG, 2010).
Funktionale Projektgröße: Bezieht sich auf den Wert der Funktionsgröße von Referenzdesign.
Produktivität Nacht (h): Bezieht sich auf die Anzahl der produktiven Stunden auf einer Person. Diese Arbeit wurde als 6 Stunden / Tag sein, wie sie in der (SISP, 2015) empfohlen.
Productivity Index (Stunden / FP): Bezieht sich auf die Menge an Zeit, um die Produktion von 1 PF gewidmet. den Wert des Produktivitätsindex Bestimmung hängt von mehreren Faktoren ab, die unter anderem die Technologieplattform, Sicherheit, Leistung, Benutzerfreundlichkeit und Projektgröße können, umfassen. Jede Organisation sollte seine eigene Produktivität Tabelle hat, historische Daten aus früheren Projekten berücksichtigen.
Effort (Person / Stunde): Dies bezieht sich auf die Anzahl der Stunden in der Projektabwicklung oder Lieferung bestimmter funktioneller Größe verzichtet werden. Es basiert auf dem funktionalen Design und Größe des Produktivitätsindex (Größe (PF) x Productivity Index (HH / FP)) berechnet.
Umwelt: Bezieht sich auf die Exponenten in der Formel verwendet werden, um die empfohlene Laufzeit zu bestimmen. Tabelle 1 zeigt die verfügbaren Optionen. , Die am ehesten die Eigenschaften eines SOA-Projekt entspricht – das war das „Object Oriented System OO System“ ausgewählt.
Andere Zeit: Es wird berechnet nach der Formel Capers Jones[Jones,2007].
Monatlicher Arbeitsaufwand (Stunden): Bezieht sich auf die Anzahl der Arbeitsstunden pro Person im Monat gearbeitet.
Team: Bezieht sich auf die Menge an Ressourcen für die Entwicklung des Projektes erforderlich und soll die prozentuale Aufteilung der Ressource für das Projekt berücksichtigt werden. In dem obigen Ergebnis, das 6.2-Features Design-Team konnte entsprechen, beispielsweise ein Team von 12 Personen mit 50% Zuteilung und Projektleiter mit 20% an dem Projekt zugeordnet.
Informierte Mitarbeiter: Dies bezieht sich auf das Team, das effektiv bei der Entwicklung des Projekts gearbeitet. Es zielt darauf ab, andere Simulationen von Aufwand und Zeit und der Verteilung der Ressourcen im Team zu unterstützen gemäß der Hingabe eines jeden an das Projekt.
Andere Schätzungen Simulationen: andere Simulationen Schätzungen wurden auf dem Team erzeugt basierend informiert und tige Reduktion unter Berücksichtigung. Der Wert der Punktfunktion verwendet wurde, basierend auf historischen Referenzen der Auftragnehmer Unternehmen definiert. Projektkosten wurden ohne Berücksichtigung der Dauer der Reduktion und unter Berücksichtigung der Dauer der Reduktion berechnet.
5. Schlussfolgerungen
5.1 Kritische Analyse des Vorschlags
Aus der Analyse der Ergebnisse durch die Anwendung von APF und Ausführung Referenzdesign erhalten wurde gefolgert, dass die tatsächlich Kosten des SOA Designs und aus der Messung von FP erhalten führten zu einer deutlich unterschiedlichen Werten (tatsächlich Kosten: R $ 733.342 50 und geschätzt Kosten: R $ 349,600.00). Es gab auch einen signifikanten Unterschied zwischen dem Aufwand für die Projektentwicklung und wirkliche Anstrengung (wirkliche Anstrengung: 2170 Stunden und geschätzter Aufwand: 6992 Stunden). Die tatsächlichen Kosten und die geschätzten (tatsächliche Kosten: R $ 733,342.50 im Vergleich zu geschätzten Kosten: R $ 593,620.00) zeigte nur relativ nahe Werte bei der Schätzung Kostenmethode zur Umgehung des Zeitverkürzung für die Projektentwicklung in Bezug auf die Art ideal empfohlen hält ( Echtzeit: 6 Monate im Vergleich zu empfohlenen Zeit: 7,71 Monate).
Daher wurde der Schluss gezogen, dass die APF hatte sehr unterschiedliche Ergebnisse in Bezug auf die tatsächlichen Ergebnisse, und daher nicht geeignet für die Messung von SOA-Projekten. Soma ist auch die Tatsache, dass der APF nicht die nicht-funktionalen Anforderungen in seiner Partitur zählt, die in vielen SOA-Anwendungen üblich sind, wie die Wiederverwendung und Zusammensetzung Dienstleistungen. Neben nicht die fragmentierte Messlösung ermöglicht, dh die Messung individuell für Service. Dies ist ein Merkmal ganz erwünscht, wenn es darum geht, SOA-Projekten zu messen, die den Bau einer kompletten Lösung beinhalten kann oder nur eine Teilmenge dieser Dienste, und auch den Bau von nur einer bestimmten Dienstleistung beinhalten kann.
5.2 Einschränkungen und Ausblick
Die Arbeit wurde nur begrenzt, ein Projekt zu messen. Darüber hinaus verwendet es nur eine Methode für Schätzungen von Aufwand, Kosten und Zeit abzuleiten. In zukünftigen Arbeiten, die Anwendung von APF in einer größeren Vielfalt von Projekten und die Verwendung von anderen Methoden der Schätzungen profitieren können, dass sie eine höhere Zuverlässigkeit in den gezogenen Schlussfolgerungen liefern. Es wird auch von großer Bedeutung sein, ein spezielles Verfahren vorzuschlagen, um die Größe von SOA-Software zu messen, die den reinsten Begriffen IFPUG in Bezug auf die Funktionsmessung zu folgen suchen, sondern auch die Notwendigkeit, stückchenweise Messlösung zu berücksichtigen sowie die Messung von nicht-funktionale Anforderungen.
Referenzen
ALBRECHT, IBM J. Allan Die CIS & Leitlinie 313. AD / M Produktivität 1984.
BÖHM, B. W. Software Kostenschätzung mit COCOMO II. Prentice Hall, New Jersey, 2009.
CALAZANS Angelica; LISSABON Irina; OLIVEIRA Marcelo. Beurteilung der Allgemeinen Merkmale Systeme in Punkt-Analyse-Funktion – APF durch das GQM Anwendung – Ziel, Fragen, Metrics. VII International Symposium on Software Process Improvement. Sao Paulo. November 2011.
ERL, Thomas. Architektur Service-Oriented: Konzepte, Technologie und Entwurf. Crawfords: Prentice Hall PTR, August 2005.
ERL, Thomas. SOA Principles of Service Design. Prentice Hall, 2008.
Farrag, Esraa A. Moawad Ramadan; IMAM, Ibrahim F. Ein Ansatz für Effort Estimation of Service Oriented Architecture (SOA) Projekte. JSW, v. 11, Nr. 1, p. 44-63, 2016.
FLORAC, William A. PARK, Robert E. CARLETON, Anita D. Praktische Mess-Software: Mess für das Prozessmanagement und die Verbesserung. Carnegie Mellon UNIV PITTSBURGH PA-SOFTWARE ENGINEERING INST 1997.
Gencel, Cigdem; DEMIRORS, Onur. Funktionale Größenmessung revisited. ACM Transactions on Software Engineering und Methodik (TOSEM) v. 17, Nr. 3, p. 15, 2008.
GOMES, Yuri Marx Pereira. Funktionale Größe, Aufwand und Kosten für SOA-Projekte mit Funktionspunkten. Nr. LXVIII November 2012.
IFPUG – INTERNATIONAL USER POINT GROUP FUNKTION. Praktiken Handbuch Count Function Points. Version 4.3.1 Januar 2010.
IFPUG – INTERNATIONAL USER POINT GROUP FUNKTION. Beurteilung Practices Handbuch. Version 2.3, Mai 2015.
JONES, C. Estimating Software Kosten. Second Edition, McGraw Hill, 2007.
Kaur Prabhjot. Eine Überprüfung der Software Metric and Measurement. International Journal of Computer Applications & Information Technology, Vol. 9, Nr. 2, p. 187, 2016.
Jeff Lindskoog. Anwenden von Function Points-Umgebung innerhalb des SOA. EDS, an HP Company. St. E. Hoffer 1401 Kokomo, IN 46902. USA. September 2009.
NESMA – Niederlande Function Points Benutzer. Startseite Function Point Analysis. Juli 2015.
Pressman, Roger S. Software Engineering: ein professioneller Ansatz. 7. Auflage. Ed: McGraw Hill, 2011.
ROETZHEIM, William H. Estimating kostet Software. ENTWICKLUNG-SOFTWARE SAN FRANCISCO, v. 8, Nr. 10, p. 66-68, 2000.
SISP. Metrics Script Software SISP: Version 2.1, Ministerium für Planung, Haushalt und Verwaltung. Sekretär für Logistik und Informationstechnologie. Brasilia: MP 2015.
SOARES DOS REIS, Julio Cesar; BARBOSA, Marcelo Werneck. VORSCHLAG FÜR EINE VORANSCHLAG FÜR TECHNISCHE ANFORDERUNGEN. Journal of Systeme und Computer-RSC, v. 3, Nr. 1, 2013.
Charley Tichenor, SNAP-Fallstudie 2 (VSN 1. 0): Wie Function Points und SNAP zur Nutzung der Software Acquisitions Vertrag zu verbessern. IFPUG. Juni 2014.
VAZQUEZ, Carlos E. SIMÕES, Guilherme Siqueira; ALBERT, Renato Machado. Analyse Function Point: Messen, Schätzungen und Verwaltung von Software-Projekten. 12. Ausgabe, Herausgeber Erica Ltda, São Paulo, 2012.
Wilkie George F. et al. Der Wert der Software-Sizing. Informationen und Software Technology, Bd. 53, Nr. 11, p. 1236-1249, 2011.
[1] Master-Abschluss in Elektrotechnik – UNB
[2] Doktor der Ingenieurwissenschaften und Wissensmanagement
[3] PhD in Elektrotechnik von der Universität von Brasilia (2004), wo er seit 1998 Hat Doktor Praktikum bei L’Ecole Supérieure d’Electricité (Supélec), Rennes / Frankreich (2001/2002) und dem Stadium der Post in der Fakultät für Elektrotechnik lehrt Promotion am schwedischen Institut für Informatik (SICS), Stockholm / Schweden (2011). Er war Koordinator des Information Technology Center (NTI) von UnB (2006-2008) und Direktor des Computing Center (CPD) von UnB (2007-2008). Er arbeitet in Forschungsprojekten, technologische Entwicklung und Innovation und Beratung, in Partnerschaft mit mehreren Unternehmen und Regierungsbehörden in Fragen der ICT im Zusammenhang, wo es in der Definition der Strategie Transfer, Governance-Modells, Prospektion Technik und Technologie arbeitet. Seine aktuellen Interessengebiete umfassen: Cloud Computing, serviceorientierte Architektur, Geschäftsprozessmanagement, verteilte Systeme und IT-Anwendungen in Regierungsumgebungen.
