This lecture I shall discuss:
•
Albrecht function point analysis.•
Function point Mark II.•
Object points.In the previous lecture I had discussed about different tech-niques of project estimation. Today I shall continue with further discussions on more techniques of project estimation, which, I am confident when, you become a project leader, and you will surely use it.
Albrecht Function Point Analysis
This is a top-down method that was devised by Allan Albrecht when he worked for IBM. Albrecht was investigating program-ming productivity and needed some way to quantify the functional size of programs independently of the program-ming languages in which they had been coded. He developed the idea of function points (FPs).
The basis of function point analysis is that computer-based information systems comprise five major components, or external user types in Albrecht’s terminology, that are of benefit to the users:
External input types are input transactions that update internal computer files.
•
External output types are transactions where data is output to the user. Typically these would be printed reports, since screen displays would come under external inquiry types (see below).•
Logical internal file types are the standing files used by the system. The term ‘file’ does not sit easily with modem information systems. It refers to a group of data that is usually accessed together. It might be made up of one or more record types. For example, a purchase order file might be made up of a record type. PURCHASEORDER plus a second that is repeated for each item ordered on the purchase order - PURCHASEORDERITEM.•
External interface file types allow for output and input that might pass to and from other computer applications.Examples of this would be the transmission of accounting data from an order processing system to the main ledger system or the production of a file of direct debit details on a magnetic or electronic medium to be passed to the Bankers Automated Clearing System (BACS). File shared among applications would also be counted here.
•
External inquiry types - note the US spelling of inquiry - are transactions initiated by the user that provide information but do not update the internal files. The user inputs some information that directs the system to the details required.•
The analyst has to identify each instance of each external user type in the project system. Each component is then classified as having high, average or low complexity. The counts of each external user type in each complexity band are multiplied by specified weights (see Table A2) to get FP scores, which are summed to obtain an overall FP count, which indicates the information processing size.Multiplier External user type
Low Average High
One problem with FPs as originally defined by Albrecht was that question of whether the external user type was high, low or average complexity was rather subjective. The International FP User Group (IFPUG) has now promulgated rules on how this is to be judged. For example, in the case of logical internal files, and external interface files, the boundaries. Shown in, Table A3 used to decide the complexity level.
Number of data types No of record
A logical internal file might contain data about purchase orders.
These purchase orders might be organized into s two separate record types: the main PURCHASEORDER details, namely purchase order number, supplier reference and purchase order date and then details for each PURCHASEORDERITEM specified in the order, namely the product code, the unit price and number ordered. The number of record types for that file would therefore be 2 and the number of data types would be 6.
According, to Table A3, this file type would be rated as ‘low’_
This would mean that according to Table A2, the FP count would be seven for this file.
SOFTWARE PROJECT MANAGEMENT Tables A.4 and A.5 are used to allocate scores to external inputs
and external outputs. Each external inquiry has to be counted both as if it were an external input and an external output and whichever score is higher is used.
Table A4 IFPUG External input complexity
Number of data types accessed No of file to be
accessed <5 5 to 15 >15
0 or 1 low low average
2 low average High
>2 average high High
Table A5 IFPUG External Output complexity Number of data types No of record
type <6 6 to 19 >19
0 to 1 low low average
2 to 3 low average High
>3 average high High
Function point analysis now goes onto take into account the fact that the effort required to implement a compute-based information system will relate hot just to the number and complexity of the features to be provided but also to the environment in which the system is to operate.
Fourteen factors have been identified that can influence the degree of difficulty with implementation a system. The list that Albrecht produced related particularly to the concerns of information system developers in the late 1970s and early 1980s.
Some technology that was new and relatively threatening is now well established
The Technical complexity adjustment (TCA) calculation has had lots, of problem. Some have even; found that it produces less accurate estimates than using the unadjusted function point count. Because of these difficulties, we are going to omit further discussion of the TCA.
Tables have been calculated to convert the FPs to lines of code for various languages. For example it is suggested that 91 lines of Cobol are needed on average to implement an FP, while for C the figure is 128 and for QuickBasic is 64
5.9 Function Points Mark II
The Mark II method has been recommended by the CCTA (Central Computer and Telecommunications Agency), which lays down standards for UK govern projects. At one time this Mark II approach seemed to be a good method to use with SSADM but some difficulties are now apparent. The ‘Mark II’
label implies an improvement and replacement of the Albrecht method. The Albrecht (now IFPUG) method, however, has had many refinements made to it and FPA Mark II remains a minority method used mainly in the UK.
As with Albrecht, the information processing size is initially measured in unadjusted function points (UFPs) to which a technical complexity adjustment can then be applied (TCA). The assumption here is that an information system comprises transactions that have the basic structure shown in Figure A2.
Data store
Process
From userInput Output Return to
user Figure A.2 Model of a transaction.
For each transaction the UFPs are calculated:
Wi X (number of input data element types) + We X (number of entity types referenced) + Wo X (number of output data element types)
Here, Wi, We, and Wo are weightings that might be derived by asking developer what proportion of effort has been spent in previous projects developing those parts of the software that deal with processing inputs, accessing and modifying stored data and processing outputs. From this it should be possible to work out the average hours of work generated by instances of each type of element.
The averages are then normalized into ratios, or weightings, which add up to 2.5 If this way of getting hold of the weightings seems too time-consuming then some industry averages are available, which are currently (1999) 0.58 for Wi, 1.66 for We” and 0.26 for Wo.
Example 3
A cash receipt transaction in the IOE maintenance accounts system accesses two entity types - INVOICE and
CASHRECEIPT.
The data elements that are input are:
•
InvoiceNumber•
DateReceived•
CashRece;vedIf an INVOICE record is not found for the invoice number, then an error message is used. If the invoice number is found, then a CASHRECEIPT record is created. The error message constitutes the only output data element that the transaction has to cater for.
The unadjusted function points, using the industry average weightings, for this transaction would therefore be:
(0.58 x 3) + (1.66 x 2) + (0.26 x 1) = 5.32
Mark II FPs follow the Albrecht method in recognizing that one system delivering the same functionality as another might be more difficult to implement (but also more valuable to the users) because of additional technical requirements. For example, the incorporation of additional security measures would increase the amount of effort to deliver the system. The original Albrecht FP method identified
14 Technical complexity adjustment factors-Mark II FPs identify five more factors:
•
Interfaces to other applications•
Special security features•
User training features.•
Direct access for third parties•
Documentation requirements:SOFTWARE PROJECT MANAGEMENT
The additional of other factors to suit local circumstances is encourage,
With. Both the Albnrecht and Symons methods. FPs can be counted for previous projects where actual effort is known. If you have figure for the effort expended on past projects (in work-days for instant) and also the system size in FPs, you should be able to work out the productivity rate. That is:
productivity = size/effort
For pew projects, the function points can be counted and then the effort can be projected using the productivity rate derive above:
Effort=constant1+sizeX constant2
Symons is very much against the idea of using function points to estimate SLOC rather than effort. One finding by Symons is that productivity, that is, the effort per function point to implement a system, is influenced very much by size of the project. In, general, larger projects, up to a certain point tends to be more Productive because of economics of scale, However, beyond a certain size they tend to become less productive because pf additional management overheads.
Some of the rules are weightings used in FP counting, especially in case of The Albrecht flavour, are rather arbitrary and have been criticized by academic writers on this account.
FPs, however, are widely used in. practice because of lack of other methods of gauging the functional size of information systems.
This is review Test for you:
Albrecht function point analysis.
Function point Mark II.
Object points.
Notes
SOFTWARE PROJECT MANAGEMENT
This lecture I shall discuss:
•
Object points.•
Procedural code-oriental approachIn the previous lecture I had discussed about different tech-niques of project estimation. Today I shall continue with further discussions on more techniques of project estimation 5.10 Object Point
This approach was devised at the Leonard N. Stern School of Business, New York University. It has similarities with the FP approach, but takes account of features that might be, more readily identifiable if you are building. a system using a high level application building tool. The reader should be warned that despite its name
The technique has no direct bearing on object-oriented tech-niques. The approach uses counts of the screens reports and 3GL components that an application might possess – it is these that are referred to as objects. Each object has to be classified as one of the following:
•
Simple•
medium•
difficultTable A.6 and Table A.7 show- the scheme used to make this classification: The number of objects at each level are multiplied by the appropriate complexity weighing shown in Table A.8.
The weighted sub-totals are then summed to get an overall score for the application. .”,
Table A.6 Object Points for screens
Number of source of data tables No of
views
contained Total<4 (<2 server
>7 Medium Difficult Difficult Table A.7Object point for report
Number of source of data tables No of
section
contained Total<4 (<2 server
>3 Medium Difficult Difficult
Table A.7Object points complexity weighting Complexity weighting Object type
Simple Medium Difficult
Screen 1 2 3
Reports 2 5 8
3GL component - - 10
Some of these objects might not need to be developed, as there already exist components that can he utilized. The object point score can be adjusted to take this into account. Say that in an application containing 840 object points, 20% can be supplied by using existing components, then the adjusted new object point. (NOP) score would be:
NOP = 840 x (100-20)/100 = 672
Finally a productivity rate (PROD) has to be identified. It would be best if the estimator could use details of past projects to derive this. As an example, the developers of object points have published the details in Table A.9 to calculate PROD. In the situation where this information was gathered, as the CASE tools, features were improving with successive releases, so the experience of the developers with the tool was growing too.
Table A.9 Object point effort conversion Developer's experience
and capability/ICASE maturity and capability
Very low Low Nominal High Very High
PROD 4 7 13 25 50
An estimate of the person-months needed to carry out the project is _then calculated by dividing PROD into NOP; For example, given the 672 new object points above and a develop-ment environdevelop-ment where productivity was nominal, then the estimated effort for the project would be 672/13 = 52 months.
5.11 A Procedural Code- Oriented Approach
The previous approach would be useful at the design stage of a project and where a procedural programming language is not the primary vehicle for development. However how could you estimate the effort to develop an individual software module using a procedural language? An approach might be based on the following steps.
1. Envisage the number and type of programs in the final system
This is easiest where the system is of a conventional and well understood nature Most information systems are built from a small set of system operations, such as insert, amend, update, display, delete, print. The same principle should equally apply to embedded systems, albeit with a different set of primitive functions.