Content deleted Content added
No edit summary |
|||
Line 15:
[[Object Management Group|OMG]], an open membership and not-for-profit computer industry standards consortium, has adopted the Automated Function Point (AFP) specification led by the [[CISQ|Consortium for IT Software Quality]]. It provides a standard for automating the Function Point counting according to the guidelines of the International Function Point User Group ([[IFPUG]]) However, the current implementations of this standard have a limitation in being able to distinguish External Output (EO) from External Inquiries (EQ) out of the box, without some upfront configuration.<ref>OMG/CISQ Specification "Automated Function Points",February 2013, OMG Document Number ptc/2013-02-01 http://www.omg.org/spec/AFP/1.0</ref>
== RPURE tools <ref>{{cite journal|last1=Adem|first1=Noureldin|title=Automating Function Points analysis based on functional and non functional requirements text|journal=IEEE|date=26-28 Feb. 2010|doi=10.1109/ICCAE.2010.5451322|accessdate=9 April 2010}}</ref>==
also there are many automaton tools that used to calculate FPA automatically one of this tools is RPURE tools which is used with natural text requirement at the early of software development and it contributes in establishing the link between goal and scenario based requirements and cost.
the following figure<ref>{{cite journal}}</ref>
== Introduction ==
Function points were defined in 1979 in ''Measuring Application Development Productivity'' by Allan Albrecht at [[IBM]].<ref>A. J. Albrecht, "Measuring Application Development Productivity," Proceedings of the Joint SHARE, GUIDE, and IBM Application Development Symposium, Monterey, California, October 14–17, IBM Corporation (1979), pp. 83–92.</ref> The [[functional requirements|functional user requirements]] of the software are identified and each one is categorized into one of five types: outputs, inquiries, inputs, internal files, and external interfaces. Once the function is identified and categorized into a type, it is then assessed for complexity and assigned a number of function points. Each of these functional user requirements maps to an end-user business function, such as a data entry for an Input or a user query for an Inquiry. This distinction is important because it tends to make the functions measured in function points map easily into user-oriented requirements, but it also tends to hide internal functions (e.g. algorithms), which also require resources to implement.
| |||