Abstract: For many years traditional software has been your size, effort and cost estimated using Function Point Analysis (FPA). It's the most clear and easier method because is based in the user perceived functionalities of a defined scope. Other techniques are based in mathematical formulas or in the technical factors like lines of code.
User perceived functionalities are identified using requirements description, application GUIs and data models in traditional project, but when we initiate a project we have a business vision of the project only. In this case, we can use the estimated count method, so when the other artifacts are created, we will use detailed count in a new count of the project.
SOA projects in your initial phase use the same documents of the traditional projects to estimate the size, but in the after phases, the artifacts are different. Many SOA projects don't have GUIs or traditional data models, but they have schema files (the data model) and WSDL files (the functionalities perceived by the user of the services).
In this article we will see how we can estimate and count SOA projects using SOA artifacts, like Service Candidate descriptions, WSDL and XSD artifacts.
What's Function Points?
The International Function Points Group (IFPUG) defines functions points as a "measure software size by quantifying the functionality provided to the user based solely on logical design and functional specifications" [REF-1].
The Wikipedia defines a function point as "a unit of measurement to express the amount of business functionality an information system provides to a user. The cost (in dollars or hours) of a single unit is calculated from past projects" [REF-2].
There is a convention in the industry that's consider project with 03 to 500 function points, small projects; projects between 500 and 1000 function points, medium projects; and projects greater than 1000 function points, big projects.
Difference Between Estimation (Estimated Count) and Measure (or Count, or Detailed Count)
We have phases in our projects, but we need know the functional size of the project or service request to know effort, cost and schedule.
In the conception phase we have the list of the functionalities or the list of the candidate services only. In this case, we don't have sufficient elements to measure, to determine the functional size, so we will estimate the project using the estimated count technique, created by the NESMA [REF-3] and presented and adapted to SOA projects in this article.
From the elaboration of the contracts and schema files of the project services, we can use detailed count, to measure, to determine the functional size. This technique is also presented in this article.
How to use the FPA count or estimation
The big question is: How can I use the FPA count?
A FPA count is used to:
- Estimate the functional size of a project before the development phase. If you have a list of the functionalities, using the estimated count method, will be possible to know the functional size of the project with 15% of error margin.
- From the FPA count or estimation derive the effort and cost of the project by roles and disciplines.
- From a final count at the end of a project measure the functional size to determine how many dollars to receive from the client. Many projects in Brazil are based in function points. The companies pay by function points instead by hours. It's good because the client will pay by the size of the functionality, not by the hours or lines of code used to develop it.
- From the count get important KPIs, like historical productivity per function point by technology, by client, by discipline and by role and cost by function points.
Function Points Types
There are two types of functionality - Data Functions to count size of the data part of the project (schema files for SOA projects) and Transactional Functions to count size of the transactional functions of the project (WSDL files for SOA projects).
Data functions are data structures like tables, schema files, text files, any type of data perceived by the user as a repository for your business information.
There are two types of data functions - Internal Logical Files (ILF) to count data functions from the project scope and External Interface Files (EIF) to count data functions from outside scope but used by any transactional function of the project scope.
To determine the total number of function points of a data function, we use a complexity table as follows:
ILF and EIF are composed by RETs and DETs. A RET is a data subgroup and DET is a data element only, a field. In a Person file for example, we can have a subgroup called Address to group the fields Zip Code, Street, City, State and Country. Any elementary field in the File (ILF or EIF) will be a DET, like Person name for example. We will use these tables to count an example in this article.
Transactions functions are functions responsible to do the user functionalities and meet your business requirements. Transaction functions are the operations of the SOA services.
There are three types of transaction functions: External Input (EI), External Output (EO) and External Inquiry (EQ).
EI - External Input
External Inputs are functionalities used to insert or update business information in a one or more data functions. The complexity table to count EI is:
EO - External Output
External Outputs are functionalities used to return derived or calculated business information returned to the user (or consumer of the service). In a return of a group of data, if any DET (field) is a result of a calculation or math operation, the transaction will be an EO. If two or more fields are inserted, merged, processed before return as a result to the user, the transaction will be an EO too. The complexity table to count EO is:
External Inquiries are functionalities used to return the information requested by the user without calculations, transformations or internal processing. The data is returned as is in your data repository. The complexity table to count EI is:
The Architectural SOA Layers Help Us to Count Correctly
A typical SOA architecture has 03 possible layers:
- Utility Layer. This layer is composed by high general and reusable services to do non-business functionalities generally, like extract text files, write log files, connect FTP sites and so on. So this type of functionality is transactional. Services in these layers have your operations counted as transactional functions and your schemas files are used to count FTRs and DETs of the transactional function.
- Entity Layer. This layer is composed by services mapped directly to the user business functions. Your operations are transactional functions and your schema files are data functions, because generally entities services persist and give access to business information required by the user.
- Task Layer. This layer is composed by services that compose other services to provide new business functionalities to the user. The task service operations are transactional functions and each service composed by one transactional operation will be counted as a FTR to determine the complexity of a service. The schema files will be used to determine DETs of the transactional operation.
Count a SOA Project Using Detailed Count
The schema files and contract files from the scope of the SOA project are sufficient to provide the elements necessary to a detailed count. In the example that follows, we will count a small SOA project, with only one service, see.
An Entity Service Project
Scope: Person Service (is a service in the entity layer)
Figure 1 - Schema (Data Structure) of the Person Service
Figure 2 - Contract (Transactional Structure) of the Person Service.
This service is an entity. So we have both types of functions, data and transactional functions. Let's go!
1 - Count the Data Functions:
The Person.xsd has the element person that is the user business data.
This element has 10 DETs (name, birthday, father, mother, maritalStatus, zipCode, street, city, state and country) that are the fields of the data function.
This element has 02 RETs (the element itself it is always a RET and the address subgroup element used to group zipCode, street, city, state and country).
2 - Classify the Data Function Type - ILF or EIF
The project is to build a person service, so person is functionality from the scope of the project, not an external functionality. The function is internal, an ILF.
3 - Apply the Complexity Table to Find the Total fFunction Points to the Data Function:
The person has 10 DETs and 02 RETs, so by the ILF complexity table we have a Low complex function.
We have 07 functions point to this function.
4 - Classify the Transactional Function Type - EI, EO or EQ
The PersonService.wsdl expose 05 operations. See the table:
5 - Count the Transactional Functions:
To count the transactional functions we need to know the type, how many files (ILFs ou EIFs) used by each operation and the quantity of field sent to the operation and returned by the operation. If the same field is used in the input and in the output, count only 1 field, not 2. See the table:
6 - Sum the Data and Transactional Function Points Counted
There are 07 data functions points and 15 transactional function points. The total function points to this project is: 22 functions points.
If your productivity factor is 6 hours by function points your project will have 132 hours of project.
If your hour cost 90 dollars, you project budget will be 11,880 to construct a Person Corporate Service to your client.
Find Your Productivity Factor
Frequently, many project managers and companies have been used function points counts in a wrong way. They don't use their historical project base counts. They use "market productivity" factors to each programming language. For Java projects they use 12-14 hours per function points, to .Net they use 8-10 hours per function point, but this is a mistake, because many others factors, not only programming language, affect the team productivity. Factors like technology architecture, tools, team technical knowledge level, stakeholders commitment, and so on.
The right procedure is count an equivalent or similar project from your developed projects and divides by the total number hours of the project to find how many hours are necessary to develop one function point. Example, if you developed a SOA project using Java and an ESB tool to a client X with 100 functions points with 1000 hours of project, you have 10 function points/hour. Now you have other project with similar characteristics (same client and technology) and you estimate 120 function points to this project, using your historical productivity, you project will have 1200 hours to be built.
If you don't have historical base, use a historical base of the client. Count a similar project built to the client. If the client doesn't have historical projects to use, create a proof of a concept with an important service and count it to get your productivity factor.
Using the Productivity Factor
With your productivity factor defined, count or estimate your project and apply it to find effort. With effort defined, apply hour price by hour and you have your price. Example: the project has 100 function points, your productivity factor is 10 FP/Hour, and your effort will be 1000 hours. If your price per hour is 60 dollars, your project will cost 6,000 dollars.
Many companies use different prices by role. In this case, use your historical base to know how many hours are used by role. Example, in a past project with 1000 hours, your effort per role was:
This technique is great to planning the team allocation too and can be used to estimate how many hours will be used by discipline, but don't forget, get from your history the number of yours used by discipline.
Estimate SOA Projects Using Only Service Candidate List or Functionality List
Project managers have a big problem in your hands always a new project begins. He must plan your project and elaborate your schedule. To do this, generally, he lists the activities of the project and asks to your team the duration in hours. This is a valid, but is based in suppositions only.
Function Point Estimation Method, created by the NESMA [REF-3], gives to manager a new and scientific method to an early estimation of the project.
In begin of a project we don't know how many fields will have the functions, so the estimated count establishes this:
- All data functions will be considered with low complexity.
- All transactional functions will be considered with medium complexity.
Obviously, estimations have error margin, use 15%, but consider past projects to adjust this error margin.
Estimate a SOA Project using Estimated Count - A Sample (Case from the Thomas Erl's book "SOA Principles of Service Design" [REF-4])
The Client - Cutit Saws
In a crowded marketplace of power tool vendors, Cutit Saws has positioned itself as a boutique manufacturer and reseller of hydraulic diamond chainsaws. It has established its models as distinct, high-end saws with chains crafted from a unique, patented blade design capable of cutting through concrete as easily as wood
Scope of the Project
- Everything originates with the manufacturing of chain blades in the Cutit lab, which requires the use of specific materials that are applied as per predefined formulas
- The assembly of chains results in products being added to their overall inventory
- Saws and kits are items Cutit purchases from different manufacturers to complement their chain models
- Notifications need to be issued when stock levels fall below certain levels or if other urgent conditions occur.
- Finally, a periodic patent sweep is conducted to search for recently issued patents with similarities to Cutit's planned chain designs.
Requirements and List of Candidate Service
Scope of the Project
From the analysis of the requirements the following services are defined to the scope of the project:
Estimate Data Functions and Transactional Functions
We have 03 services in the Entity Layer in this case:
Services in the Entity Layer are data functions and your functionalities are transactional functions.
The Run Lab Materials is a service from Task/Orchestration Layer. Services in this layer and in the utility layer have your functionalities as transactional functions. The service itself cannot considered a function to these layers. Only entity layer provides data functions.
With the rules established we have the following list:
A Note about REST SOA Services
REST services don't have contract, but they have operations over HTTP protocol to provide us the necessary information to count it. See the table:
- To know better about function points read the David Street's FPA Manual in http://www.softwaremetrics.com/freemanual.htm
- Download a free spreadsheet to do your FPA count or estimation using Excel in [http address provided by servicetechmag]
[REF-1] IFPUG - About Function Point Analysis http://www.ifpug.org/?page_id=10
[REF-2] Wikipedia - What's Function Points http://en.wikipedia.org/wiki/Function_point
[REF-3] NESMA - Netherlands Function Points Users
[REF-2] Prentice Hall Service Technology Series SOA Principles of Service Design by Thomas Erl